[Dune] Returning Geometries As Objects

[Martin Nolte]

As said in my other mail: I'm basically on your side. I just think there 
should be a transition period.

Best,

Martin

On 01/25/2012 01:51 PM, Carsten Gräser wrote:
> Am 25.01.2012 13:42, schrieb Martin Nolte:
>> Hi Jö,
>>
>> the Geometry may now either hold a reference or a copy. It is possible
>> that boost::ref / std::ref does something similar. However, the design
>> goal was minimal intrusion into the current concept. Therefore, I tried
>> to honor the template list of Dune::Geometry.
>>
>> With respect to lifetime: For now, nothing is changed, i.e., the
>> geometry is guaranteed to live as long as the entity, which in turn
>> lives as long as the entity pointer or iterator pointing to it. In other
>> words: The Geometry now behaves essentially like the geometry reference
>> did before. So, no, this does (for now) not give us a stable way to
>> store geometries. Moreover, geometries can (currently) not be assigned.
> One argument discussion copy vs. refrence discussion was that returning
> a copy instead of a reference 'will eliminate problems related to
> lifetime of a cache object'. Having a copy that is no longer valid
> if, e.g., an iterator is incremented does IMHO increase those problems.
> I'd expect to use reference counting if you want to avoid the
> additional cost.
>
> Best,
> Carsten
>
>>
>> Of course, the geometry may also be freed when the geometry object goes
>> out of scope. This has little impact as long as the geometry is actually
>> a reference (current situation for all grids in dune-grid). If a
>> developer decides to return an actual geometry object, however,
>> expensive computations may now be executed multiple times. This decision
>> is now up to the grid developer.
>>
>> In the long run we can discuss this, of course. The advantage of the
>> current semantics is that both, grids and user codes grids run
>> efficiently without major changes. Moreover, it gives maximal freedom to
>> the developer.
>>
>> With respect to the spurious performance artifacts: I cannot explain
>> them. After all, a reference to a wrapper should behave the same as a
>> wrapper to a reference (in my opinion). The situation looks similar on
>> 2,000,000 elements (current:<900,000). Moreover, similar results are
>> obtained when adding a geometry implementation wrapping the reference
>> and plugging this into the old Dune::Geometry (see revision 7844).
>>
>> I hope I did not omit a question.
>>
>> Best,
>>
>> Martin
>>
>> On 01/25/2012 11:04 AM, Jö Fahlke wrote:
>>> Am Wed, 25. Jan 2012, 09:49:01 +0100 schrieb Martin Nolte:
>>>> Dear all,
>>>>
>>>> as announced in December, there is now an implementation returning
>>>> the geometry as an object and all grid implementations in dune-grid
>>>> have been adapted accordingly. Therefore, I think time has come for
>>>> discussion of the outcome.
>>>
>>> Nice!
>>>
>>>> The changes try to be as uninvasive as possible. However, due to
>>>> code evolution, there are some unnecessary changes left. The
>>>> greatest benefit for a developer is the possibility to create a new
>>>> geometry object whenever the geometry is requested. This gives us
>>>> essentially two types of geometry implementations:
>>>> (a) actually returned geometry implementations,
>>>> (b) references to the actual geometry (as was previously enforced).
>>>
>>> So, in essence, Dune::Geometry may (a) store the actual geometry or
>>> may (b) be
>>> a wrapper class holding a reference/pointer to the actual geometry?
>>>
>>> In case be (b), how long is a geometry object guaranteed to be valid?
>>> Until
>>> the entity/intersection object it was obtained from changes it's value
>>> or is
>>> destroyed?
>>>
>>> This sounds like an application for boost::ref(erence_wrapper) (now also
>>> available as std::ref(erence_wrapper)).  But that is a minor
>>> implementation
>>> detail.
>>>
>>>> Notice that the SPGrid implementation no longer returns the geometry
>>>> by reference, which seems to cause a small performance loss.
>>>> However, this decision is now up to the grid developer!
>>>> Unfortunately, there are some spurious performance gains with
>>>> ALUCubeGrid and SGrid.
>>>
>>> Spurious in the sense that you don't have an explanation for them?
>>>
>>>> Before doing any changes to the actual trunk, I would like to hear
>>>> the opinion of the developers (and users) on this change. I hope the
>>>> impact of the transition and its most important details became
>>>> clear. Questions, suggestions, and hints will be welcome.
>>>
>>> Does this give us a way to get a stable geometry object that can be
>>> copied and
>>> stored, regardless of what the grid does?
>>>
>>> Regards,
>>> Jö.
>

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany