[dune-functions] GridFunction interface

[Carsten Gräser]

Am 20.03.2015 um 13:39 schrieb Christian Engwer:
> Hi Carsten,
> 
>> B)One reason to return LocalFunction as object, is that they
>>   should behave like any other function. However this is
>>   not exactly true for its derivative, because the returned
>>   derivatives are computed wrt. global coordinates for local
>>   coordinate arguments.
>>
>>   For me this is not a real problem. But we must clearly state
>>   this in the docs.
> 
> this is not exactly true. The same problem already occures for the
> value, if you have a vector valued Range. If your Range describes a
> velocity field, or similar, you have to transform the vector to map
> from local valued data to global valued data.
I'm sorry but I don't understand this.

Regarding the derivative I must revert my above statement.
We have a real problem: Until now I only had in mind that
the derivative of a local function is not consistent with
it's values. E.g. you could not apply a generic finite difference
check of the derivative to a local function. But the nasty
thing is, that not even the types match in general.

For a grid function living an a 2d-in-3d grid, the signature
of derivative(localFunction) would be

  DerivativeTraits< Range(Domain) >::Range (LocalDomain)

and not

  DerivativeTraits< Range(LocalDomain) >::Range (LocalDomain)

So we cannot put a LocalFunction in our generic DifferentiableFunction
wrapper. It seems that we have two options, both with their own
drawbacks:

1)Return derivatives wrt global coordinates. Then we must
  introduce some special LocalDerivativeTraits associated
  to the global DerivativeTraits+EntitySet. This would reflect,
  that the derivative is given wrt a non-standard coordinate system.
  However the user would have to specify these traits by hand if he
  wants to wrap a local function in a DifferentiableFunction.

  + This seems to be what we had in mind until now.
  + Perhaps this is what one normally needs
  + derivative(localFunction(f)) == localFunction(derivative(f))
  - Complicates our function concept
  - Complicated to explain
  - More complicated implementation of interface
  - Do we really need this? One can (and would for performance
    reasons) always use localFunction(derivative(f)) for this.
  - LocalDerivativeTraits only encodes that there are non-standard
    coordinates, but not how to transform them.

2)Return derivatives wrt local coordinates. Then all types
  and values are consistent, the above problem would disappear,
  and a local function would be a functions like any other.

  + Keeps concept simple and consistent
  + Straight forward to implement
  + Provides a way to access derivatives in local coordinates,
    the others can already be obtained by localFunction(derivative(f))
  - Perhaps unexpected, but only if you're trained to 1)
  - derivative(localFunction(f)) != localFunction(derivative(f))

I'm undecided about this. Questions? Opinions? Other options?

Best,
Carsten