[Dune] New subentity numbering

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

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