[Dune] Info GeometryGrid and entity seed

[Agnese, Marco]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20160304/73ff7975/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OutlookEmoji-&#X1f60a.png
Type: image/png
Size: 488 bytes
Desc: OutlookEmoji-&#X1f60a.png
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20160304/73ff7975/attachment.png>