[Dune] How to store entities?

[Bernd Flemisch]

Thank you all for your quick answers! I see clearer now.

And I definitely would be / have been in favor of Steffen's proposal at
users.dune-project.org/doodles/23
which apparently did not receive enough interest and the majority of the four votes was "needs further discussion"

Kind regards
Bernd


On Tue, 09 Dec 2014 15:31:48 +0100
 Martin Nolte <nolte at mathematik.uni-freiburg.de> wrote:
>Hi Carsten, hi Bernd,
>
>there might be a notable difference between entities (or entity pointers) and entity seeds. Like Robert, I would usually recommend entity seeds to "store entities", but this might not be the best choice for all grids implementations and all purposes.
>
>In AlbertaGrid, for example, only stores the macro elements in memory. Each DUNE element holds a stack of all fathers up to the macro level, which might be a waste of memory if you store them. The entity seed, on the other hand, is just two integers, the index of the macro element and some bits encoding the path downward. Decoding the entity seed, however, requires walking down to the element again and is, therefore, of complexity log( n ).
>
>I hope this example sheds some light on the difference. For many grid implementations, however, entity pointers and entity seeds differ only in an additional pointer to the grid.
>
>Best,
>
>Martin
>
>On 12/09/2014 03:07 PM, Carsten Gräser wrote:
>> Since I already typed my (slightly longer) answer:
>>
>> Am 09.12.2014 um 14:59 schrieb Robert Kloefkorn:
>>> Hello Bernd,
>>>
>>>> for some of our models, we store for each vertex all elements that
>>>> share this vertex. We currently use a
>>>> std::vector<EntityPointer> for this. I have a couple of questions
>>>> concerning this:
>>>
>>>> 1. Is this currently a good choice or are there better choices?
>>> No (never has been) and Yes.
>>>
>>>> 2. When would it be safe to store (smart) pointers to
>>>> Entities/EntityPointers/EntitySeeds?
>>> Just don't.
>> With the new copyable entities the answer for all
>> three is, that they are valid as long as the grid is
>> not modified. Before, the Entity was only valid, as
>> long as the EnitityPointer/Iterator containing it
>> was not changed.
>>
>>>> 3. What should I use in the future when EntityPointer is gone?
>>> EntitySeed.
>> Storing EntitySeed will always be the better choice, because
>> this is the reason why it exists. If, for a certain grid
>> manager, the EntityPointer would be the most efficient choice,
>> then it would implement the EntitySeed using the EntityPointer.
>>
>> The main point is that EntitySeed is exactly defined to be memory
>> efficient and will often be just a pointer or index internally,
>> where as EntityPointer may store a pointer to the grid, some
>> cached data (geometry), ... in order to provide efficient access
>> to Entity informaton.
>>
>> Best,
>> Carsten
>>
>>
>> _______________________________________________
>> 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
>
>_______________________________________________
>Dune mailing list
>Dune at dune-project.org
>http://lists.dune-project.org/mailman/listinfo/dune

_______________________________________________________________

Bernd Flemisch                         phone: +49 711 685 69162
IWS, Universitaet Stuttgart              fax: +49 711 685 67020
Pfaffenwaldring 61            email: bernd at iws.uni-stuttgart.de
D-70569 Stuttgart            url: www.hydrosys.uni-stuttgart.de
_______________________________________________________________