[Dune] New subentity numbering

[Oliver Sander]

Hi all!
I just reread the previous discussion and wanted to clarify a few things.

First of all, again, no personal offense was ever intended.

Then, I think, we actually agree on more things than may appear from the
discussion.  Let's see:

Generic geometries: they are great, no discussion

Generic reference elements: same here.  The actual subentity numbering
   comes as a separate point, though.

Subentity numbering of prisms and pyramids:  They were arbitrary in the
  past, and we all agree that they should be changed for increased 
consistency.
  They are rare enough to affect only very few people.

We disagree only on the subentity numbering of simplices and hypercubes.

Hypercubes:  Peter's old implementation is generic, but apparently 
illegible.
Not having looked at the code, though, I must say that I can't really 
believe
that programmers of our level of competence are not able to understand it,
and that it is less work to rewrite a new implementation from scratch.

Simplices: Here there was no generic algorithm, and to have one is an
improvement, albeit, in my opinion, of little practical importance.  4d 
and 5d
simplices are still not widely used in the numerical analysis community.

The problem with the simplex and cube renumbering is, of course, backward
compatibility.  The Dune project has reached a state where several dozens of
people who are not developers use Dune for their everyday work.  It was a
clear intention of Dune to reach that state.  However, with it comes a 
certain
reponsibility, for example, new releases should not screw up existing code
without a very good reason.  I know we agreed on the change at a meeting
in a democratic vote, but now some of us, me included, blame ourselves
for not having considered the implications of the renumbering well enough.

To bring this discussion to a productive conclusion, I make the following
suggestions and I put them to an official vote.

a) I propose to go back to the old hypercube numbering, and Peter documents
    that code.
b) I propose to have the simplex subentity numbering only for simplices
    in 4d and higher.

These are two separate proposals, to be voted separately.


My last point is on the documentation.  This did indeed get me a little 
angry.
We started to implement major changes, that endangered the code of many
people.  We were all very conscious of this danger.  However, it was not
documented at all.  As I stated above, we have many third party users, and
we are proud of that.  But that situation brings responsibility to all core
developers.  You simply cannot work on core modules and not document
the code.  Eventually, that will make Dune unmaintainable.

No doubt that I personally could have written some of the documentation
that is missing.  But some of it could not be written by me simply because
I didn't implement the code in question and I don't know what it does
precisely and how it works.  The implementors had/have to do that.
Upon asking for documentation, several times I got answers along the 
lines of
'sorry, we don't know what's missing, please tell us'.  However, the 
omissions
were so blatantly obvious that at times it sounded like a 'documentation is
no fun, why don't you do it'.  Certainly I can convinced to be wrong.

Dune is a great project, and getting stronger everyday.  Let's work together
to keep it that way.

--
Oliver


Martin Nolte schrieb:
> Hi Peter, hi Christian,
>
> first of all, let me state that (not knowing your discussion), I did not see the 
> point of Sven's mail. Having read your mail, I think I can understand what you 
> mean. And now this is constructive (so no offense taken).
>
> It is correct, that we have to work on documentation a lot before a release 
> (especially the user-oriented part). We also have to state clearly why we 
> changed what and I think we can at least provide some hints there. I also have 
> to admit that we can no longer see many of the problems with this numbering 
> stuff, since we have gone too deep into it. This is exactly where we need help. 
> Ask what you don't understand and then write it in such a way that everybody can 
> understand it. For us this is really hard, since we don't see the problems anymore.
>
> I also admit, that it would have been nice to have a numbering that is nearer to 
> the old one. In fact, we discussed a lot about it and didn't see how. I somehow 
> has a brilliant idea, he should come forward, state it and then implement it. 
> I'm the last guy to say the current implementation cannot be improved. But be 
> warned: The implementation and testing easily swallows months.
>
> As to Christian's remarks about validity of wrong code: This was exactly what we 
> feared, when we suggested a smooth transition. A hard break would have meant 
> that you don't even find the places. Now, you "only" have to be extra careful. 
> Of course, we also have run into this problem. At least, we stand a chance to 
> find the places, now.
>
> I really understand the worries about these changes. Actually, in Heidelberg I 
> had the impression, that I was one of the guys who most feared this change. It 
> is really hard to communicate the problems (especially for the subentity 
> relation, where there was no previous documentation). So, if anybody is unsure 
> how the change will affect his code, feel free to ask us. There is no stupid 
> question with respect to this.
>
> Maybe, we all are also invited to create some documentation page with the common 
> pitfalls. If someone makes a mistake, he could simply add it there.
>
> I hope, this throws some light onto why we always said we needed help with the 
> transition.
>
>
> Yours,
>
> Martin
>
>
>
> Christian Engwer wrote:
>   
>> Hi Martin,
>>
>>     
>>> 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.
>>>       
>> I can only speek for my self, but I doubt that Sven intendet his email
>> to be destructice. There was ne goal to be acieved with te new
>> numbering, namely to be generic. We discussed how to achieve this and
>> we agreed that it must be in a way such that the user doesn't break
>> his code without knowing and such that the user would have to change a
>> few places as possible.
>>
>> Now for the first part, we all failed misserably. That is not
>> particularly cour fault, we all could have helped in improving the
>> documentation, we find it lacking. But I also must state that the
>> amount of work is bigger than I'd expected during the discussion.
>>
>> For the second point we realized during the transition of code in
>> Heidelberg, that it is easy to miss a point where the numbering
>> changed and end up with valid code, but wrong results. I'm sure you
>> made similar experience.
>>
>> Currently we have a bad situation and I'm not sure what is the best
>> solution, but still I think it is a valid to discuss this situation.
>>
>> I wouldn't like to get rid of the generality again, but I also fear
>> the trouble that is still lying in front of us and that that's coming
>> after a release.
>>
>> Lastly I'd like to say, you are right that there is no use just
>> moaning. Either there is a working generic algorithm, or everything
>> has to stay as it is. But this still doesn't answer the (my) question:
>> "should we consider switching to yet an other numbering (before the
>> release) which is consistent with the existing cube and simplex
>> numbering, assuming we would find one?"
>>
>> Please don't take this personal or destructive.
>>
>> Christian
>>     
>
>   


-- 
************************************************************************
* Oliver Sander                ** email: sander at mi.fu-berlin.de        *
* Freie Universität Berlin     ** phone: + 49 (30) 838 75348           *
* Institut für Mathematik      ** URL  : page.mi.fu-berlin.de/~sander  *
* Arnimallee 6                 ** -------------------------------------*
* 14195 Berlin, Germany        ** Member of MATHEON (www.matheon.de)   *
************************************************************************