[dune-functions] GridFunction interface

Carsten Gräser graeser at mi.fu-berlin.de
Fri Mar 20 18:31:24 CET 2015


Hi Christian,

Am 20.03.2015 um 17:36 schrieb Christian Engwer:
> Hi Carsten,
> 
>> Lets assume f:\Omega \to V, E a fixed element, R the reference
>> element, and T:R \to E the geomertry map. Now let
>>
>>   g = localFunction(f);
>>   g.bind(E);
>>
>> Then we have g = f \circ T^{-1} : R \to V. But with approach 1)
> 
> I think here is the first place where we see things differently. The
> local function (at least if we do it like Oli proposed) does not
> always fulfill
> 
> g(x) = f(T^{-1}(x))
> 
> Oli proposed to omit the piola transformation, thus the range of f and
> g (possibly) differ. In this case g would be given as
> 
> g(x) = |J| J^-1 f(T^{-1}(x))
> 
>> we would have
>>
>>   derivative(g) = f' \circ T^{-1} != g'
>>
>> and derivative(g)(x) \in L(E,V) instead of L(R,V). In contrast
>> 2) would lead to derivative(g) = g' and derivative(g)(x) \in L(R,V)
>> as expected.
> 
> I always interpreted the local function as a local view. I do not map
> the function, but I restrict it onto the element.
> 
> And there are several practical reason why I don't want to map the
> function...
> 
> * If we consider analytic functions, we will now have to implement the
>   mapping in the other direction, but in this case it is even more
>   complicated to decide which mapping is the correct one.
It's not complicated. Its exactly the geometry mapping, so you have
to multiply by it's Jacobian.

> * If I want to use the functions, I only think about the local element
>   in order to have an efficient way to evaluate my integrals and to
>   make use of sparsity. I always want to map my function values to
>   global space and I also want to evaluate my derivatives with respect
>   to global space.
Again you can have the desired behavior by using
localFunction(derivative(f)) instead.

> * It is not as simple as always multiplying by the inverse of the
>   jacobian, because sometimes (as described earlier) the evaluation
>   has already be transformed in order to get the same result as f(x)
No. It is always as simple as this. That's pure chain rule:
(f \circ T)' = (f'\circ T) T'.

> I agree that local function suggests a different behavior, perhaps we
> should do it the same way as with the basis and call it localView(f)
> instead of localFunction(f)?
I don't have a problem with the name LocalFunction for this and I also
understand that there are reasons why one would like to have this.
I only have a problem with the fact that the result of derivative(g)
is far from being the derivative of g.

We can only argue that it is the derivative in a special sense, e.g.,
wrt a special coordinate system. In the end you need to now that
coordinate system (i.e., that you have a grid function) to interpret
the derivative. But if you know this, you can directly use
localFunction(derivative(f)).

>> As far as I understand you're taking about local E-dependent
>> coordinates for the range V which is orthogonal to the problem
>> mentioned above.
> 
> No, the local function would always have the range, but the range for
> global function and local function differs in the case of vector
> fields. If you think about a more extrem example... RT0 on a surface,
> the local range is R^2 and the global range is R^3.

> Somehow I have the feeling we are talking past each other...
Maybe. So let's sort things out:

For me the local function is given by g = f \circ T.
Then range(g) = range(f) regardless if f is an analytic function,
or Pk or RT0 FE function in flat or curved space.
1) and 2) is only about the derivative. For 2) its just g'
whereas its f' \circ T != g' for 1). But this can still be
interpreted as g' in a special coordinate system.

Notice that, with this definition the local function will be a linear
combination of the local FE, for some FE spaces (like Pk) but not for
others (like RT).

What's your precise definition of a local function?
Since you're taking about a change in the range it must
be different from both, 1) and 2).

Best,
Carsten






More information about the dune-functions mailing list