[Dune] The subentity numbering again...

[Bernd Flemisch]

Dear Dune,

I did not dare to enter this discussion up to now, since it was heated up and already tagged "leading nowhere." Nevertheless, since you frequently mentioned "user" in this discussion, I just thought that maybe you are interested in some thoughts from a user. If not, please just skip reading.

Not too surprisingly, I would not like to change anything which does not give an improvement. Enhanced consistency, as you call it in your "Recent Changes" for sure is an improvement, easier generalization to higher dimensions is not (at the moment and for us, it sure might be for others). I also consider the renaming of the methods to be quite an improvement, like entity -> subEntity or numberInSelf -> indexInInside.

To me, Sven's proposal seems to fulfill both reasons you mention in "Recent Changes", namely, enhanced consistency and easier generalization. As a user, I especially like that nothing has to be changed for 2D. This is the dimension where we do most of our model/method development and testing. And this is also the dimension where I think that at quite some places we assume a specific subentity numbering, "just to do a quick test and to do it properly later." And once it works this assumption will be in there forever. For 3D, I am pretty sure that we rely on a specific subentity numbering in exactly one of a few hundred files. 

So if Sven's proposal is really possible "with some minor changes" for you, then it would be great if you could go with it! 

All the best 
Bernd 


> 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
>
>   


-- 
_____________________________________________________________________

Bernd Flemisch                               phone: +49 711 685 69162
IWS, Universität Stuttgart                   fax:   +49 711 685 60430
Pfaffenwaldring 61                  email: bernd at iws.uni-stuttgart.de
D-70569 Stuttgart                       url: www.iws.uni-stuttgart.de
_____________________________________________________________________