[Dune] Returning Geometries As Objects

[Carsten Gräser]

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. Carsten Gräser       | phone: +49-30 / 838-75349
Freie Universität Berlin | fax  : +49-30 / 838-54977
Institut für Mathematik  | email: graeser at math.fu-berlin.de
Arnimallee 6             |
14195 Berlin, Germany    | URL  : http://page.mi.fu-berlin.de/graeser
----------------------------------------------------------------------