[Dune-devel] [Dune] Info GeometryGrid and entity seed

[Martin Nolte]

Hi Macro,

I see your point. As this is getting more involed, I think we should continue 
this discussion on the developer list.

I like the suggestion that entity seeds should be persistent over purely 
geometrycal modifications of the grid. Semantically, the entity generated from 
an entity seed would then return the modified geometry associated with the 
topological entity, now.

Unfortunately, DUNE never enforced the strict separation of geometry and 
topology (e.g., the entity knows its geometry), so there might be some grid 
imlementation that violates this rule (though I seriously doubt it). Anyway, 
clarifying these semantics for all grid impelmentation would require a longer 
discussion.

Do you really need this property from all DUNE grids or are you content with 
specifying this property for GeometryGrid? In the first case, I'd ask you to 
open an issue to discuss the matter. In the second case, would you be so kind as 
to update the documentation of the entity seed for GeometryGrid?

By the way: There is a metagrid called CacheItGrid, which caches the entity 
seeds in a vector and then implements the iterators by traversing the entity 
seeds and obtaining the entity. This is basically what you are already doing. So 
you could use a 'GeometryGrid< CacheItGrid< HostGrid > >' instead of 
'GeometryGrid< HostGrid >'. As the HostGrid does not change, you can be sure the 
caches in CacheItGrid do not need to be rebuild and you're done. But then you 
depend on GeometryGrid not reordering the iteration, which is another property 
we should document.

Best,

Martin

On 03/04/2016 12:50 PM, Agnese, Marco wrote:
> Hi Martin,
>
> for example, in my code, I have created a "sorted leaf view". This view allows
> me to iterate over the elements in a way that two consecutive elements are very
> close spatially. This property speed up the interpolation of a discrete
> function. (I know that is not a very clear explanation&#X1f60a)
>
>
> Creating this custom view comes to a cost, therefore is better to do it only
> once. This is possible because the sorting depends only on the topology of the
> mesh and not on the actual coordinates. Obviously, I have to avoid to traverse a
> grid looking for the element ids otherwise all the speed up gain is completely lost.
>
>
> The only way that I know is to store entity seeds while in the past I was
> storing entity pointers. I don't see any other way to have direct access to an
> entity within DUNE. So I think that it is necessary to assure consistency of the
> entity seed also after a grid modification which doesn't change the topology of
> the grid.
>
>
> It makes sense that the behaviour of entity/geometry is not enforced by the
> interface after a grid modification. For example, a caching process can be
> involved and if you move the grid they still refer to the old grid.
>
>
> So the bottom line is that the interface should assure that entity seed are
> always valid (which now is indeed the case for GeometryGrid).
>
>
> Cheers,
>
> Marco
>
>
>
>
> --------------------------------------------------------------------------------
> *From:* Martin Nolte <nolte at mathematik.uni-freiburg.de>
> *Sent:* 03 March 2016 19:39
> *To:* dune at dune-project.org
> *Subject:* Re: [Dune] Info GeometryGrid and entity seed
> Hi Marco,
>
> as I don't know your exact application, I will hardly be a good advisor.
> Therefore, I stick to the interface.
>
> The answer to your question is: Yes, there is another way. You can store the
> ids, e.g., in a std::set. They are guaranteed to be persistent over grid
> modification. On the downside: You need to traverse the grid to get the entities
> (or entity seeds) back.
>
> That said, as long as you stick to GeometryGrid and keep a keen eye on changes,
> you should be safe reusing the entity seeds after modifying the coordinate function.
>
> Actually, I would not even count on the behavior of an entity. Assume you have
> an entity e and then modify the coordinates. What will be the result of
> e.geometry() afterwards? Right now, it depends on whether you obtained the
> geometry before modifying the coordinate function or not. If you did, you will
> get the old geometry, otherwise the new one. Please note that this behavior
> conforms to the specification, as you are not allowed to keep entities over any
> kind of grid modification.
>
> Best,
>
> Martin
>
> On 03/03/2016 07:48 PM, Agnese, Marco wrote:
>> Hi Martin,
>>
>> thank you for the answer.
>>
>>
>> Right now I am constructing the entity from the entity seed after the
>> GeoemtryGrid has been moved and it works perfectly fine.
>>
>>
>> But what is the alternative? I need to store some entities (or a pointer/ an
>> iterator to them) and retrieve them after the grid has been moved. I thought the
>> only way is to save the relative entity seed. Is there another way to do it?
>>
>>
>> Cheers,
>>
>> Marco
>>
>>
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>>http://lists.dune-project.org/mailman/listinfo/dune
> Dune Info Page <http://lists.dune-project.org/mailman/listinfo/dune>
> lists.dune-project.org
> This is the mailing list for (potential) users of Dune to ask for help.
> Discussion about development happens on dune-devel at dune-project.org. To see the
> collection of ...
>
>
>
>>
>
> --
> 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
>
>

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