[Dune] Storing entity iterators

Martin Nolte nolte at mathematik.uni-freiburg.de
Thu Mar 12 09:44:25 CET 2015


Hi Marco,

your question is not as simple as it might look. Technically, I would consider 
changing the coordinateFunction of GeometryGrid a grid modification. 
Therefore, neither an entity seed, nor an entity, nor a geometry need to 
remain valid after your change. The life time of all these objects is 
specified to end with any grid modification. Note that these life time bounds 
also hold for iterators and entity pointers.

Now, you could have a look at the code and find out what is actually done. But 
that won't give you any guarantees for future changes.

For geometry grid, however, I think it makes sense to assume that the entity 
seed will survive any modification of the coordinate function (producing the 
new coordinates), because internally it is just the entity seed of the host 
grid. If there are no objections, I would add this to the documentation of 
GeometryGrid.

For entity and geometry, I would not make any assumptions. The geometry is a 
MultiLinearGeometry which contains some arbitrary corner container. Depending 
on this container, you would get the old or the new coordinates. So you are 
not safe from minor modifications in GeometryGrid. Similarly, the entity might 
store the geometry (for faster access) or it might not. In the first case, the 
returned geometry would behave as described above. In the latter case, you 
would get a newly computed geometry with the new coordinates. Again, slight 
changes to GeometryGrid would break you code without prior notice, because 
these are implementation details that might change at any point.

As you restrict yourself to a single grid implementation (GeometryGrid), you 
can also do the following. Create yourself a MultiLinearGeometry with a 
std::vector< GlobalCoordinate > as corner storage. Then initialize this 
geometry from the one returned by GeometryGrid. Now you can be sure this 
geometry will survive grid modification (as it is not tied to the grid 
anymore). This copy will, however, generate some overhead which might reduce 
your code performance.

Best,

Martin



On 03/11/2015 07:04 PM, Agnese, Marco wrote:
> Hi Steffen, hi Christian Engwer and hi Oliver,
> thank you for your answers. I wasn't aware that entity iterators were expensive.
> Therefore storing a copy of the entities (or the entity seed) is the correct solution.
> Good news since that was the solution I had implemented :)
>
> Another very quick question.
>
> Let's suppose that I have a GeometryGrid and I store a copy of an entity.
> After that, I move the vertices of my grid (therefore I change the values of the discrete function defined on the host grid which defines my wrapped grid).
> The entity copy extracted before is consistent with the updated GeometryGrid or is consistent with the old one?
> More precisely, if I extract a vertex of the entity copy, the global coordinate will have the same value of the old grid or of the new grid?
> Does it change the behaviour, if I store the entity seed instead of the entity copy?
>
> Thank you very much,
> cheers,
> Marco.
>
> _______________________________________________
> 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




More information about the Dune mailing list