[Dune] [Dune-Commit] dune-grid r5015 - trunk/grid/test

[Oliver Sander]

Hi Martin!
>
> as far as I remember the decision in Heidelberg (and I understand that 
> Christian remembers the same), the old template method is to be 
> deprecated and removed post 1.3.
Well, great, let's do it!
>
> What confuses me is that you were one of the guys who wanted a hard 
> break in the numbering while you have to change a lot of code. Anyway, 
> I never wanted to offend you; my interest lies solely in a consistent 
> interface. I'm in no way against discussions. But in this case a 
> discussion started over things that we decided upon and the discussion 
> seemed to weaken the interfaces consistency in quite a critical point, 
> namely the subentity numbering.
Apparently a misunderstanding triggered by my weak memory.  Apologies.  
Let's just
continue the transition.
>
> Personally, I would have deprecated the old subIndex / subId methods 
> already. The problem is that many grids don't support the replacement, 
> yet, so people cannot change their code to the new implementation.
In dune-grid it's really only SGrid and YaspGrid.  The ALU-Hack could 
applied there as well
with little effort.

--
Oliver

>
> Maybe we should add FlySpray tasks for all the grids that don't 
> support these methods, yet...
>
> Yours,
>
> Martin
>
> Oliver Sander wrote:
>> Hi Martin, hi all!
>>
>>
>>> ok, I thought yesterday's discussion was quite final. I read Oliver's
>>> statement as "I don't want to do this messy renumbering stuff, can't 
>>> someone
>>> else do it". 
>> Not quite.  I do not want to dodge the numbering stuff (in fact I can't,
>> I maintain quite a lot of code that depends on local edge and face
>> numbers).  My problem was that I don't quite remember what we
>> decided, and I didn't find it written down.  Therefore I took the 
>> conservative
>> point of view and assumed that the old methods would stay.
>> If they stay, though, it's very confusing to have the old methods use
>> a different numbering than the new ones.  That was my point.
>>
>> Now if we have actually decided that the old subIndex methods should
>> disappear (post 1.3) (which I think is a good decision), then I agree 
>> that
>> they can keep the old numbering, but they should be marked as deprecated
>> immediately, in order to avoid consistency issues.
>>
>> -- 
>> Oliver
>>
>>> With this in mind I simply changed things to the state they
>>> should be according to the Heidelberg discussion.
>>>
>>> The only thing left was Peter's argument and (as far as I remember) we
>>> discussed this in Heidelberg and decided that there should be no 
>>> performance
>>> loss due to inlining and compiler optimization.
>>>
>>> If someone wants to reopen the Heidelberg discussion, feel free to 
>>> do so. But
>>> until there is a different decision I think we should stick to what 
>>> we already
>>> decided.
>>>
>>> Yours,
>>>
>>> Martin
>>>
>>>
>>>
>>> Carsten Graeser wrote:
>>>  
>>>> Dear Dune Developers,
>>>> from the messages below the current state on the subIndex method 
>>>> seems to be:
>>>>
>>>> *Oliver wants the template-arg method to have the same numbering
>>>> *Peter wants the template-arg method to remain
>>>> *Sven thinks that having different numbering conflicts with keeping 
>>>> the template-arg method
>>>>  but remembers that is was decided differently
>>>> *Martin thinks that the numbering should be different and changed 
>>>> the test accordingly
>>>>
>>>> So currently there seems to be no definite agreement about this issue.
>>>> Perhaps it would be a good idea to decide this before further 
>>>> changes are
>>>> applied. (Especially for maintainers of a grid implementation like 
>>>> me. ;-) )
>>>>
>>>> Best regard
>>>> Carsten
>>>>
>>>>
>>>> Oliver Sander schrieb:
>>>>   
>>>>> Shouldn't the old method use the new numbering as well?
>>>>> Then the test would be okay as it is.
>>>>>       
>>>> Peter Bastian schrieb:
>>>>   
>>>>>> - Do we keep the old member template methods?
>>>>>>         
>>>>> I would keep it, as it might be more efficient.
>>>>>       
>>>> Sven Marnach schrieb:
>>>>   
>>>>> As I remember the discussion, the idea was to keep the old methods
>>>>> with the old numbering for a smooth transition, providing backward
>>>>> compatibility for one release.  After the transition period, the old
>>>>> methods are to be deleted.
>>>>>
>>>>> That idea somehow conflicts with the idea to keep the old subIndex
>>>>> method with a template codim parameter.
>>>>>       
>>>> mnolte at dune-project.org schrieb:
>>>>   
>>>>> Author: mnolte
>>>>> Date: 2009-04-03 09:43:03 +0200 (Fri, 03 Apr 2009)
>>>>> New Revision: 5015
>>>>> Modified: trunk/grid/test/checkindexset.cc
>>>>> ===================================================================
>>>>> --- trunk/grid/test/checkindexset.cc    2009-04-03 07:40:07 UTC 
>>>>> (rev 5014)
>>>>> +++ trunk/grid/test/checkindexset.cc    2009-04-03 07:43:03 UTC 
>>>>> (rev 5015)
>>>>> @@ -448,9 +448,17 @@
>>>>>                   // the subIndex and the index for subEntity must 
>>>>> be the same          assert( vxidx == lset.index( *vxp ));
>>>>> +        +        typedef GenericGeometry::MapNumberingProvider< 
>>>>> dim > Numbering;
>>>>> +        const unsigned int tid = GenericGeometry::topologyId( 
>>>>> it->type() );
>>>>> +        const int gi = Numbering::template dune2generic< dim >( 
>>>>> tid, i );
>>>>>  
>>>>>          // static and dynamic method must yield the same result
>>>>> -        assert( vxidx == lset.subIndex(*it,i,dim));
>>>>> +        if( vxidx != lset.subIndex( *it, gi, dim ) )
>>>>> +        {
>>>>> +          std::cerr << "Error: subIndex< dim >( entity, i ) != 
>>>>> subIndex( entity, dune2generic( i ), dim )" << std::endl;
>>>>> +          assert( vxidx == lset.subIndex( *it, gi, dim ) );
>>>>> +        }
>>>>>                     // check whether the coordinates are the same 
>>>>>            
>>>>> assert(vertexCoordsMap.find(vxidx)!=vertexCoordsMap.end());
>>>>>       
>>>>     
>>>
>>>   
>>
>>
>


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