[Dune] Returning Geometries As Objects

[Martin Nolte]

Hi Carsten,

In the long run, I agree that it would be more flexible to always copy the 
geometry, despite the fact that it delegates some performance decisions to the 
user. Most people use DUNE through higher modules, anyway. For now, however, I 
think that this might cause severe performance impacts on our codes, since we 
assume that multiple calls to geometry are not (much) more expensive than a 
single call. We should give our users (read ourselves) some time to adapt our 
application codes to the new situation.

Moreover, in the long run I also think that the geometry should not be 
returned by the entity to disentangle the topological grid and its geometric 
realization.

Anyway, personally I would like to wait with such a discussion until the next 
developer meeting (hopefully somewhen in summer).

Best,

Martin

On 01/25/2012 12:15 PM, Carsten Gräser wrote:
> Hi,
> first of all thank you for your effort, Martin!
>
> Am 25.01.2012 11:04, schrieb Jö Fahlke:
>> 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?
> In my opinion it would be counterintuitive if the object is only
> valid as long as the reference was before.
>
> Wouldn't it be even simpler and more flexible to always store the
> geometry implementation geo_ in the Geometry object? One could still
> use geo_ to redirect the actual work to an object stored somewhere
> else. If one would, e.g., like to implement reference counting
> for those to ensure a proper livetime, it seems that one anyway
> cannot use (b) although one does conceptually store a reference.
>
> Best regards,
> Carsten
>

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