[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