[Dune] Returning Geometries As Objects

[Oliver Sander]

Hi Martin,

> (b) let the constructor of Dune::Geometry give a deprecation warning, if
> StoreGeometryReference::v is true, thus issueing a warning to the user.
>
Sorry if I missed that: are we introducing a new capability?
What is its semantics?  And will it be permanent or only for a transition
period?
Thanks,
Oliver


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