[Dune] The subentity numbering again...

[Martin Nolte]

Hi Sven, hi all,

there are a few things I would like to add to the discussion (just so we have 
the arguments).

Firstly, I think that the suggested approach can be done. I don't think it to 
be a minor piece of work, though, nor do I see all the implications of it.

It definitely means that every code that has to mimic the generic numbering in 
some way (for example, when writing generic basis functions) will have to 
specialize one extra case (namingly the triangle).

Moreover, it is totally unclear to me whether the suggested change would keep 
the "consistency" of the subentity of subentity numbering. With this I mean 
the following: Let T be the reference tetrahedron and let F be the i-th face 
of T. Take the reference triangle D and imagine it to be mapped to F such that 
the ii-th vertex of D is mapped to vertex subEntity( i, 1, ii, 3 ) of the 
tetrahedron (which is the natural embedding). Let us now consider the j-th 
edge E of F. We can now ask the the k-th vertex of E in two ways:
a) T.subEntity( T.subEntity( i, 1, j, 2 ), 2, k, 3 )
b) T.subEntity( i, 1, D.subEntity( j, 1, k, 2 ), 3 )
With the current implementation of the generic reference element, both 
versions will give the same result. The ways not true for the old Dune 
implementation and I, personally, think this a great advantage. I don't think 
it is easy to find a bug in the subentity numbering. The question is, whether 
the suggested numbering satisfy this property (numbering the edges 
anticlockwise will definitely break this for the tetrahedron)?

Since I believe that we don't want to rename methods anymore, it would mean a 
hard break for everybody using the current development version. We won't have 
any help on where the code might break due to this change.

In the end, I simply don't understand the difference between an opposite 
vertex numbering and the generic one (which is dimension minus opposite 
vertex). Maybe this is a relic from the good old days when only 2d was possible...

Let me also point out that there is an alternative for people who really 
depend on an opposite vertex numbering: Map the subentity numbering to what 
they expect. Especially in the 2d case, this is trivial and the code is 
extremely simple.

Before we vote on this, I would appreciate it if someone implemented this new 
numbering (including the necessary mappings between generic numbering and the 
suggested one) so that it can be tested. I would very much dislike the 
disaster that happened in Heidelberg, where everybody said "sounds good" and 
then later stated: "I had no clue what this would actually mean".

Yours,

Martin


Sven Marnach wrote:
> Hi all,
> 
> last week I had a long phone call with Martin.  Among other things, we
> discussed again the possibilities of changing the subentity numbering.
> 
> After discussion among the people in Heidelberg, we suggest the
> follwoing changes to the current generic numbering:
> 
>  1. The old 2D simplex numbering is recovered by special-casing.  This
>     special case is used as a basis for recursively building higher
>     dimension simplices.  These will be numbered generically according
>     to the rules in 2.
> 
>  2. When recursively building the higher dimension simplex E° from a
>     simplex E, the subentities are numbered in the following way:
> 
>       * First, all subentities of E° which are not part of E get the
>         numbers of the subentities of E which they are based on.
> 
>       * Then the subentities of E° which are contained in E are
>         numbered consecutively in the same ordering as they were
>         numbered before.
> 
>     This will recover opposite-vertex numbering for the faces of a
>     simplex of any dimension, except for the 1D simplex (but in the
>     case of 1D simplces, opposite-vertex numbering would mean that a
>     vertex should get a different number when the vertex is considered
>     as a face).
> 
>  3. The cubes will retain their current generic numbering (i.e. the
>     one introduced by Martin and Andreas).
> 
>  4. The numberings of prisms and pyramids change according to the
>     rules in 2.
> 
> This numbering has the following advantages:
> 
>  1. The numbering in 2D will be completely the same as before.  Many
>     people only have 2D codes, which will essentially work unchanged
>     (of course, method calls have to be changed to the new method
>     names).
> 
>  2. In 3D, the old numbering of vertices and faces is preserved for
>     cubes and simplices.  Only the edge numbering of simplices and
>     cubes will change.  This will not affect as many people as
>     renumbering faces.
> 
>  3. Simplices will retain opposite-vertex numbering.  This is what
>     most people expect because it is already used in school.  It is
>     also more intuitive for P1 finite elements.  (People _really_
>     expect this.  We were already asked why on earth we adopted a
>     numbering which does not have opposite-vertex numbering.)
> 
>  4. The faces of 2D simplices will be numbered anticlockwise, which
>     again is what most people expect.
> 
> Martin thinks that these changes would be possible whith some minor
> changes to the current code.
> 
> What is the opinion of the DUNE developers on this topic?  Who is in
> favor of adopting this proposal?
> 
> Regards from Heidelberg,
>     Sven
> 
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune

-- 
Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5642
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany