[Dune] New subentity numbering

Fri May 8 16:36:36 CEST 2009

Hi All,

please let us not (immediately :-) ) get into a discussion about tone
and who did what and what not. Yes, I admit that I did not provide the
generic cube algorithm. I also admit that I forget to write
documentation frequently (that is for the (i,c,ii,cc) stuff).

My impression is that the mail of Sven was meant in a constructive way.
And that is how we discussed it yesterday. We (i) have to tell "the
user" why there is a new numbering (So you say: We need it to have n-D
simplices and it was too complicated to make it agree with the old one
for d<4), (ii) we have to give good documentation how to port user code,
else we will have to answer a lot of questions on the mailing list. So
it has to be done anyway.

@Andreas: Everybody agrees that generic geometries are a very good thing
to have. The discussion is only about whether it would be possible to
have a generic numbering algorithm that coincides with the old one. I
know that you have tried, thus it would be on others to spend some time
thinking on it.

Peter

Am Freitag, den 08.05.2009, 16:11 +0200 schrieb Martin Nolte:
> Hi all,
> 
> obviously, the documentation on the generic geometry stuff is still far from
> perfect. And honestly, neither Andreas nor myself have enough time to provide
> what you guys want. If you don't know what something does you can always ask us,
> but not in this tone.
> 
> As to missing user-visible documentation: Either write it yourself or tell us in
> a friendly tone which important part of the documentation is missing. The
> example of the reference element does not hold water, since it is a 1:1 clone of
> the methods of the old one (and they can be documented by whoever introduced the
> (i,c,ii,cc) notation).
> 
> With respect to changes in the numbering, I can say the following. When the
> introduction was discussed in Berlin (February 2008), Peter was asked to provide
> the formula for the old numbering of cubes. He has not done so. To get to work,
> we tried our best to come as close as possible to the old cube numbering. With
> respect to simplices, there was nothing generic in that numbering (or can
> anybody tell me how the triangle numbering is embedded into the tetrahedron?).
> Moreover, if you consider the line a 1d simplex, opposite-vertex numbering
> definitely will not work.
> 
> I am sure that there are many other possibilities of getting a generic
> numbering. Obviously, there is a generic numbering that is exactly identical to
> the old dune numbering: just start with 4d stuff. I remember that we openly
> discussed in Heidelberg, which of these two ways to go (and everybody who read
> the discussion FlySpray tasks knew what this change meant). So, unless someone
> has a suggestion for a better generic numbering, I would ask him not to mourn
> about our solution.
> 
> If you really think we should switch back to the non-generic numbering (except
> for cubes, where the documentation is also missing), feel free to say so or call
> a vote on this.
> 
> In case this e-mail hurts somebodies feelings, I want to apologize in advance.
> The destructive criticism of the previous mails is not easy to take, if you
> respect the opinion the authors.
> 
> 
> Yours,
> 
> Martin
> 
> 
> 
> 
> 
> Oliver Sander wrote:
> > Hi all!
> > I would like to state my explicit and total agreement with what Sven has
> > written.  If there is no advantage to the new numbering of simplices and
> > cubes (and we have not found any), then I think we should go back to
> > the old numbers.
> > 
> > --
> > Oliver
> > 
> > Sven Marnach schrieb:
> >> Hi,
> >>
> >> yesterday, Peter, Christian, Oliver and me discussed a bit about the
> >> new subentity numbering.
> >>
> >> I spent several days "renumbering" the dune-pdelab code.  After
> >> tedious renaming and some tricky debugging, the code works again --
> >> and does the same as before.  I did not really get the feeling of
> >> having achieved anything -- the code just does the same as before.
> >>
> >> This raises the question: What is the use of the renumbering after
> >> all, especially from a DUNE user's point of view?  If we release the
> >> next version of DUNE, we must tell the users that they have to put a
> >> serious amount of time and energy into making their code do the same
> >> as before, without any discernible advantage.  Hmm.
> >>
> >> We ourselves already spent quite some time for this transition, but
> >> there is still a lot of code out there which is not ported to the new
> >> numbering, and we did not release a DUNE version with the new
> >> numbering.  Things are not beyond remedy up to now.
> >>
> >> Is it really impossible to rewrite the generic geometry stuff in a way
> >> that it preserves the old numbering, at least for simplices and cubes?
> >> The cubes were generated generically before, so this should still be
> >> possible.  And I don't see any reason why it should not be possible
> >> for the simplices.  Prisms and pyramids would probably still need
> >> renumbering, but they are rarely used anyway.  And the effort needed
> >> to adapt the generic geometry implementation is almost certainly less
> >> than the effort needed to port the remaining code.  (Of course we
> >> should have done this right from the start.  It would have saved me
> >> renumbering PDElab.  Well, we didn't.)
> >>
> >> There are other problems about the transition.  The documenatation is
> >> really incomplete.  Just an example from the documentation of the
> >> Mapper class:
> >>
> >> template<int cc>
> >> int map (const typename G::Traits::template Codim<0>::Entity &e, int i) const
> >>     Map subentity i of codim cc of a codim 0 entity to array index.
> >>
> >> int map (const typename G::Traits::template Codim<0>::Entity &e, int i, unsigned int codim) const
> >>     Map subentity i of codim cc of a codim 0 entity to array index.
> >>
> >> Not a single word about the differences, nor about which is the old
> >> and which is the new method, and that it is dangerous to mix the use
> >> of old and new methods.  Furthermore, 95 % of the code in
> >> grid/genericgeometry is without any documentation (not even
> >> comments!).  Even parts of the code that are meant to be directly used
> >> by DUNE users are lacking any documentation (for example
> >> GenericReferenceElements).  And finally, the transition page itself is
> >> all but complete (for example, no word about the orientation changes
> >> of subentities).
> >>
> >> To be clear about this:  I really like that we have generic geometries
> >> now -- they facilitate new grid implementations and reduce code
> >> duplication.  But I can't see any advantages of the new numbering, and
> >> I would like to have documentation for the generic geometry code.
> >>
> >> Greetings from Heidelberg,
> >>     Sven
> >>
> >> _______________________________________________
> >> Dune mailing list
> >> Dune at dune-project.org
> >> http://lists.dune-project.org/mailman/listinfo/dune
> >>   
> > 
> > 
> 
-- 
Peter Bastian
Interdisziplinäres Zentrum für Wissenschaftliches Rechnen
Im Neuenheimer Feld 368
D-69120 Heidelberg
Telefon +49 (6221) 54-8261/8249
Telefax +49 (6221) 54-8884
Email: peter.bastian at iwr.uni-heidelberg.de 