[Dune] Returning Geometries As Objects

[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.

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