[dune-pdelab] DiscreteGridFunction interface

[Peter Bastian]

Hi all,

sure, adding this functionality sounds like a good idea. And it would
remove some boiler plate code …

Best,

Peter

Am 08.08.2012 um 18:57 schrieb Felix Heimann <felix.heimann at iwr.uni-heidelberg.de>:

> Hallo Everybody,
> 
> I agree, the PDELab GridFunction interface should allow access to the derivatives (preferably of any order) and those implementations that can provide them should do so.
> 
> As those people using finite elements with sophisticated local->global transformations had to write their own grid functions so far, this issue should not prevent us from improving what we have (not saying that it should not be addressed in near future).
> 
> And kudos to him who implements...
> 
> Best regards,
> Felix
> 
> 
> On 08.08.2012 16:37, Jö Fahlke wrote:
>> Am Wed,  8. Aug 2012, 15:57:34 +0200 schrieb Christian Engwer:
>>> On Wed, Aug 08, 2012 at 03:15:29PM +0200, Jö Fahlke wrote:
>>>> Am Wed,  8. Aug 2012, 10:10:53 +0200 schrieb Christian Engwer:
>>>>> I'd like to get a new topic on the never ending
>>>>> interface-discussion-list.
>>>>> 
>>>>> Why doesn't the DiscreteGridFunction allow the evaluation of
>>>>> derivatives?
>>>>> 
>>>>> DiscreteGridFunction is based on the LocalFunctions which allow to
>>>>> evaluate derivatives and tell till which order. If nobody comes up
>>>>> with a good reason not to do it, I'd like to include such
>>>>> functionality in the DiscreteGridFunction. I currently have the
>>>>> problem, that I'd like to implement different kinds of error
>>>>> functionals, some of them work require the gradient, some the function
>>>>> itself and I would prefer not to expose this part to the user.
>>>> 
>>>> One reason is that the GridFunction interface does not include evaluating the
>>>> derivatives.
>>> 
>>> Well, this is not really a reason. The interface in some sense is also
>>> a description of what is there.
>>> 
>>>> Another reason is that the local-valued LocalFiniteElements only provide
>>>> local-valued derivatives.  You still need to know which transformation to
>>>> apply, which (in general) depends on the kind of element.  This is of course a
>>>> non-issue with global-valued finite elements.
>>> 
>>> Again it is not _really_ a reason. It is just that it is somewhat
>>> harder to do it, but doesn't really give a reason why not to do it now.
>> 
>> Rereading your question again I see I gave answers to a slightly different
>> question.  All the reasons mentioned were reasons why nobody had done this up
>> to now.  They're definitely not hard reasons why this shouldn't be done.
>> 
>> As I said, I think it's a good idea to do let the GridFunction provide the
>> derivates, where available.
>> 
>> Regards,
>> Jö.
>> 
>> 
>> 
>> _______________________________________________
>> dune-pdelab mailing list
>> dune-pdelab at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-pdelab
>> 
> 
> -- 
> Felix Heimann
> Universität Heidelberg
> Interdisziplinäres Zentrum für Wissenschaftliches Rechnen
> Arbeitsgruppe Paralleles Rechnen
> IWR 368, Raum 422
> Tel: 06221 / 54 8881
> 
> _______________________________________________
> dune-pdelab mailing list
> dune-pdelab at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-pdelab

------------------------------------------------------------
Peter Bastian
Interdisziplinäres Zentrum für Wissenschaftliches Rechnen
Universität Heidelberg
Im Neuenheimer Feld 368
D-69120 Heidelberg
Tel: 0049 (0) 6221 548261
Fax: 0049 (0) 6221 548884
email: peter.bastian at iwr.uni-heidelberg.de
web: http://conan.iwr.uni-heidelberg.de/people/peter/