[Dune] Question about the GenericReferenceElements

Martin Nolte nolte at mathematik.uni-freiburg.de
Fri Oct 22 21:44:08 CEST 2010


Hi Andreas,

actually, this is the internal structure of the GenericReferenceElement. In my
opinion, this is a great idea (though it is still possible to confuse i and c --
and I don't mean variable names, here).

Best,

Martin

On 10/22/2010 11:24 PM, Andreas Dedner wrote:
> Hi Martin,
> 
> how about a method
> GenericSubEntity subEntity(c,i)
> return a ''proxy'' or reference with an index method
> index(cc,ii) or something like that, then there should be
> less possibilities to do it wrong and since everything is Cached
> anyway it should be possible to do something like that without
> loss in efficiency?
> 
> Best
> Andreas
> 
> On 10/22/2010 08:23 PM, Martin Nolte wrote:
>> Hi Oliver,
>>
>> when implementing the generic reference element, I implemented all methods of
>> the original ReferenceElement class. Especially, this included the method
>>
>> global ( const FieldVector<  ctype, dim-codim>  &local, int i, int c ) const.
>>
>> When I saw the redundancy, I simply added another method, dropping the redundant
>> argument (for convenience).
>>
>> Back then, I somehow assumed that the interface for the ReferenceElement has
>> been thoroughly discussed. Over time, this impression has changed. Since the old
>> ReferenceElement is now gone, I would be very happy to discuss what methods
>> should be present on the GenericReferenceElement. In particular, I would very
>> much like to get rid of the (i,c,ii,cc) methods. In my mind it is (c,i,cc,ii)
>> and, since the types don't differ, I frequently get weird errors from this.
>>
>> I would very much appreciate, if an "interface" for the reference element could
>> be discussed on the developer meeting in Münster.
>>
>> Best,
>>
>> Martin
>>
>>
>> On 10/22/2010 02:43 PM, Oliver Sander wrote:
>>   
>>> Dear Dune!
>>> I just had a look at the GenericReferenceElement class.
>>> I learned that said class has methods
>>>
>>> template<  int codim>
>>> FieldVector<  ctype, dim>
>>> global( const FieldVector<  ctype, dim-codim>  &local, int i )
>>>
>>> and
>>>
>>> template<  int codim>
>>> FieldVector<  ctype, dim>
>>> global( const FieldVector<  ctype, dim-codim>  &local, int i, int c ) const
>>>
>>> Their documentations appear to be identical, with the exception of a
>>> note saying "The runtime argument c is redundant and must equal codim"
>>> for the second method.  And indeed the method throws an exception
>>> if c!=codim.
>>>
>>>
>>> Why do we have this seemingly pointless method as part
>>> of our grid interface?
>>>
>>> Best,
>>> Oliver
>>>
>>> -- 
>>>
>>> ************************************************************************
>>> * 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)   *
>>> ************************************************************************
>>>
>>>
>>>
>>> _______________________________________________
>>> 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




More information about the Dune mailing list