[Dune] Returning Geometries As Objects

[Martin Nolte]

Hi Jö, hi all,

it looks as though most developers can well live with (b'), i.e., Carsten's 
suggestion. By the way, (b') would actually be (c') in my list, because it is 
more restrictive that (c).

Moreover, with (b) you may not store references to the corners in the geometry 
as they might vanish within the lifetime of the geometry. While (b) may look 
well semantically, I guess grid developers might oversee this issue and store 
such references nevertheless. And, as you pointed out, codes testing this 
feature will be extremely rare, so that the bug would hardly be noticed.

The last issue you describe, i.e., calling global refine in some algorithm and 
wanting to avoid fetching the geometry multiple times, would already be solved 
with (c).

However, I never liked (a) and (b). As a bad compromize, I would have accepted 
(c). For me, (b') is an acceptable compromize. It does still allow for many 
performance optimizations while seemingly being acceptable to those of us who 
value clean semantics over performance.

If I'm not mistaken, the following people have agreed on (b') by now:
Carsten, Jö, Martin, Oliver.
This means, we're still two developers short on an actual decision.

Nevertheless, I will proceed as announced, i.e., change the branch to
(a) documentat that the returned geometry object has to be valid until the 
next grid modification,
(b) let the constructor of Dune::Geometry give a deprecation warning, if 
StoreGeometryReference::v is true, thus issueing a warning to the user.

Afterwards I will silently merge the branch into the trunk this afternoon 
(unless, of course, a developer tells me not to).

Best,

Martin



On 02/09/2012 05:45 PM, Jö Fahlke wrote:
> Am Tue,  7. Feb 2012, 12:07:52 +0100 schrieb Martin Nolte:
>> as far as I understood Christian, he wants the lifetime (I mean the
>> time in which the geometry remains valid) to be unlimited before the
>> next release. Changing the user code to call geometry only once
>> (which would be wise anyway) might take a lot of time and,
>> therefore, I think a longer transition period would be good.
>>
>> Moreover, I'm still not sure on the correct path. I see at least
>> three possibilities:
>>
>> A geometry object is valid
>> (a) for ever (i.e., as long as it exists)
>> (b) as long as the grid, the entity belongs to
>> (c) as long as the entity exists within the grid
>> (d) as long as the corresponding entity pointer is valid (current situation)
>
> I guess I have to propose (b') (same as Carsten):
> (b') A geometry object is valid until the grid changes.
>
> I want either (b') or better (b).  Which one depends on how much effort it is
> to implement (b) compared to (b').  I.e. are there any grids where the
> internal data structures are moved around even for persistent entities during
> grid change?
>
> Rationale: Geometry objects don't look like they keep internal references to
>             the grid (in contrast to iterators, which obviously do).  So I
>             actually would expect a geometry object to be valid for as long as
>             it exists.
>
>             However, I can see the potential for optimization for grids that
>             store parts of the geometry internally anyway.  Plus I would assume
>             that the cases where a geometry isn't re-fetched anyway after a
>             grid change are very rare.
>
>             (b) Would affect only those cases where the user code needs the
>             geometry of a no-longer existing entity, which seems obscure to me.
>             (b') Would also affect cases like computations on multiple
>             refinement levels and doing globalRefine() on demand.
>
> Just my 2¢,
> 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