[Dune] Returning Geometries As Objects

[Martin Nolte]

Hi Oli,

maybe this piece of information got lost in my rather long explanation. In the 
current version of the branch, Dune::Geometry can either store a reference to 
the implementation of the implementation itself. This is switched by a 
pseudocapability, which I called "Dune::FacadeOptions::StoreGeometryReference" 
and which currently defaults to true (see my original mail from 01/25/2012.

Of course, this pseudocapability is supposed to allow for simple support of 
returning references and objects with the same facade class (avoiding a lot of 
code duplication). Now that we decided that returning references is no longer 
allowed, this "capability" will only exist for a (hopefully short) transition 
period.

I hope this answers the questions.

Best,

Martin



On 02/10/2012 09:10 AM, Oliver Sander wrote:
> 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ö.
>>>
>>
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune

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