[Dune] How to set boundary ids

[Andreas Dedner]

> - The GridFactory interface gets a lot more complicated
   I do not quite understand:
   we added about four new methods and nothing too complicated.
   If the grid implementation allows to preserve the order of
   insertion in the level zero index then we added:
   View view() { return grid_.levelView<0>(); }
   int operator[](const Entity<0>& en) {
     return grid_.levelIndexSet<0>.index(en); }
   int operator[](const Entity<dim>& vtx) {
     return grid_.levelIndexSet<0>.index(en); }
   int operator[](const Intersection& bnd) {
     return bnd.boundaryIndex(); }

> - In your proposal, the grid factory returns a mapping that does
>   a renumbering from level<0> index to insertion order.
>   This mapping could also be a part of the grid implementation
>   and remain invisible to the user.  Since we are only talking
>   about level 0 the time overhead should not be a problem.
   If the level<0> index set has to be wrapped in the grid implementation
   then probably all level index set have to be wrapped or an if has
   to be used, or virtual methods have to be added.
   Also the renumbering has to be stored during the whole live time of
   the grid and not only during the life time of the factory.
   We should keep in mind that macro grids can have millions of elements!
Best
Andreas
> 
> --
> Oliver
> 
> Andreas Dedner schrieb:
>> Hi,
>> a second suggestion for handling data attached to the initial grid:
>>
>>    For a grid implementation preserving the order of insertion might be
>>    difficult and might require wrapping the level<0> index set of the
>>    grid even after grid creation. Alternatively the grid factory could
>>    provide a mapping from level<0> index to insertion order.
>>    Possible interface:
>>    class Factory < G > {
>>      void insert(entity) {...}
>>      void create() {...}
>>      View view() {...}
>>      int operator[](const Entity<0>& en) { return insertionOrder; }
>>      int operator[](const Entity<dim>& vtx) { return insertionOrder; }
>>      int operator[](const Intersection& bnd) { return insertionOrder; }
>>      G* finalize() { return grid; }
>>    };
>>    Note that create() does not return the grid and does not finalize the
>>    Factory. The old method createGrid() could still be available and
>>    would be equivalent to calling create(); finalize();
>>
>> Greetings
>> Andreas and Martin
>>
>> PS:
>>    do we specify the order in which vertices, elements, and boundary
>>    segments are added to the Factory, e.g., first all vertices and
>>    then the elements, or at least all that all vertices needed for the
>>    inserted element have already been inserted?
>>
>>
>>
>> Oliver Sander wrote:
>>> Dear Dune!
>>> As far as I know the question of who sets boundaryIds and how
>>> is still unsettled.  Two days ago Peter, Christian, Benedikt and me
>>> discussed this issue again.  We came up with a solution that was
>>> acceptable to all four of us and combines (in our view) a consistent
>>> interface with ease of use.
>>>
>>> We propose that boundary ids should be consecutive and starting
>>> from zero.  The user can influence the ordering by calling insert-
>>> BoundarySegment in the desired order.  The second argument
>>> (the segment geometry) will be made optional such that the user can
>>> specify boundary segment orderings and still leave the geometry to the
>>> implementation.I have described the solution in some more detail in
>>> Sections 4.4 and 4.5 of the grid-howto.
>>>
>>> We propose that the behavior described there be part of the official
>>> Dune grid interface.  Please read it carefully and give us feedback.
>>>
>>> Yours,
>>> Oliver
>>>
> 
>