[Dune] Returning Geometries As Objects

[Oliver Sander]

Am 10.02.2012 14:08, schrieb 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.
>
It does.  Thank you very much.
--
Oliver


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