[Dune] Info GeometryGrid and entity seed

[Carsten Gräser]

Am 04.03.2016 um 12:50 schrieb 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. 
That's a little delicate because the grid interface does not
provide a way to change the grid while keeping the topology. Hence we
would incorporate a guarantee into the interface that only covers
extended non-interface features.

IMHO that's at least problematic. Furthermore a precise definition
of "topology does not change" will be hard. A first guess could
be, that the whole subentity graph and all global and local indices
stay the same. But then a grid could still alter the order of
iteration or the number of subdivions of intersections. Would this
be topological changes, too?

In general an implementation can change the grid in strange ways that
we cannot foresee, making any such definition useless.

In view of this it's in my opinion up to the grid implementation
to give guarantees on extended functionality.

Best,
Carsten
> 
> 
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20160304/d7cafc21/attachment.sig>