[Dune] New subentity numbering

[Martin Nolte]

Hi,

I don't think we should go onto the road who should have done what again. On of
the greatest things of this project is that so many people are working together
to achieve something. Statements as "I think it is obvious what someone else
should have done" are no good.

As to the documentation of the generic geometries: Is it really so hard to
understand that once you know all the internal stuff you think this to be
trivial? So, please don't say it is obvious but just state plainly what needs to
be documented for you to understand and where you seek to find it. Maybe it is
already there and you just overlooked it.

Moreover, I think the last few month have seen a vary rapid change in the
dune-grid interface. And in several cases, the changes discussed in Heidelberg
were introduced in a very sloppy manner. After they were introduced, people
started saying "Now this is changed and I don't know how". So, if you want to
dictate what we do when, then say what you want done. But don't say it is obvious.

What is really obvious it that we (Andreas and myself) don't work on dune-grid
all day. And I still think that we react quite fast (in comparison to others) on
  understandable requests.

So maybe this discussion starts to take up much time that could be put to useful
things (such as documentation). For example: To properly document the transition
phase it is necessary to completely document the "old" state. As Oliver points
out: This should be an easy task. We will happily contrast this with the "new"
state. By the way: Improved documentation on the "old" state is needed the more
in case we switch back.

As to the point of switching back on behalf of the uses: If I remember
correctly, we clearly warned about it. But, of course, we supported and still
support this change. But I don't support this discussion any longer. It leads
nowhere.

Yours,

Martin

Oliver Sander wrote:
> 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
>>>     
>>
>>   
> 
> 

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