[Dune] New subentity numbering

Wed May 13 23:15:46 CEST 2009

Hi all,

with respect to the subentity numbering of subentities I just added a 
consistency check. The check does the following:

let S be the subentity (i,c) of E. Then, we can map to vertex numbers of any 
subentity (j,cc) of S into E (by the obvious embedding). On the other hand, the 
subentity (j,cc) of S is a subentity (k,cc) of E. Hence we can ask E for the 
vertices of (k,cc) directly. If the numbering is consistent, both ways should 
deliver the same vertex numbers.

If you run the test (dune/grid/common/test/checkrefnumbering), you will see that 
the old 3-dimensional reference elements fail this test (with the exception of 
the cube, which was already generic). So, if you see no reason to change the 
subentity of subentity numbering, then this may provide you with one.

Yours,

Martin

Andreas Dedner wrote:
> Hi,
> 
> I think having a generic grid implementation without a generic subentity
> numbering is not a good thing. So for cubes we can of course go back to the
> old numbering. For simplicies the change for subentity 1 is simple and
> for codim dim non existing. So the disusiion seems to be about edge numbering
> in 3D? I think the old tetrahedral numbering for edges was as arbitrary as the
> one for pyramids/prisms. The edges in triangle in the base of the tetrahedron does not 
> follow opposite vertex numbering or anything else.
> 
> So I would like to know what exactly the problem with the triangle/tetrahedron is?
> Is it also the shift for codim 1 which is causing problems?
> Or is it the subentity of subentites numbering? Where was that documented in the
> old dune versions? I can not find a picture or any other informaion along that line?
> 
> By the way:
> The discussion in Heidelberg half a year ago, came to the following
> conclussion:
>   people using dune use eiter dune-disc or dune-fem, so that the
>   changes to the subentity numbering has to be carried out in these
>   modules and most users will not see it. 
> Apparently this assumption is not valid anymore?
> If really
>> several dozens of people who are not developers use Dune for their everyday work.
> is the case, it is getting time for a "users meeting" as has been 
> proposed for some time, since I would like to meet them and learn what
> they are doing. 
> 
> Greetings
> Andreas
> 
>  
> 
> 
> 
> 
> 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
>>>>     
>>>>       
>>>   
>>>     
>>
>>   
> 
> 
> _______________________________________________
> 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