[dune-functions] Interface limitations in the functions interface

[Carsten Gräser]

Hi,
these are several extensions. I'll try to comment on them one by one

A)Extend the interface to support signatures of the type
  Range(Domain_1,...,Domain_N)
  * operator() will always take N arguments
  * You can get derivatives with respect to each of the N arguments

    df1 = derivative(f, Component<1>)
    ...
    dfN = derivative(f, Component<N>)

  * Each dfi again depends on N arguments and hat the signature
    DerivativeTraits<Range(Domain_i)>::Range (Domain_1,...,Domain:N)

B)Provide a genaralization of std::bind such that binding a
  differentiable function yields a differentiable function again.

C)Also do A) and B) for grid functions.

D)Support partial derivatives wrt. individual components of
  each Domain_i

Here are my comments on this:

A)I have the impression that it should be not to complicated
  to implement this by extending the current interface with
  varidadic templates. But I'll have to look into the details.
  On thing that I'd really like to avoid is supporting a
  total derivative wrt all domains at one then, because it
  will in general be hard to define a proper range type for this.

B)Unfortunately the standard leaves the result type of std::bind
  open. So we cannot hook into this and would really have
  to write our own bind. I'm a little afraid that this
  may require some deeper variadic template magic. Or
  we restrict ourselves to a subset of the bind functionality
  (e.g. fixing one argument only and keeping the order of the others).
  But perhaps we can rely on std::bind by doing some dectype
  trickery to define derivative.

C)This is really a lot more complicated, if you want to
  do it in a general way, because one would have to specify
  the number of the argument wrt to which you take the local
  view. Think of a function defined on the product of several
  grids where you want to call localFunction(f,Component<i>)
  for different i one after the other.
  However if we restrict ourselves to support localFunction
  only wrt to this first argument, while considering the others
  just as additional parameters, this may be not to complicated.
  For implementing custom bind compatible to this the my arguments
  on B)
D)I'm not sure if you wanted to propose this, or if you just
  meant what I outlined in A) by partial derivatives. I would
  strongly advocate to not open this can of worms. Otherwise
  we'd have to specify what the 'components' of a domain type
  are and how to specify them.

To sum up: A) seems to be viable and implementable.
I'd only consider C) for the special case outlined above.
Implementing derivative/localFunction-aware bind will be hard
but perhaps doable with some restricted functionality.

Best,
Carsten




Am 18.03.2015 um 22:37 schrieb Christian Engwer:
> Dear all,
> 
> when thinking about the PDELab transition, I realized that PDELab
> functions have one particular feature, which we can not handle
> currently. After thinking longer about it I came to the conclusion
> that this could be solved in a very general way, but I'm not sure how
> easy it is to implement this. Let me explain...
> 
> PDELab functions don't only depend on a position in space, but also on
> time, so they mimic something line f(x,t). Instead of making the t an
> explicit parameter PDELab currently has a special method setTime, but
> I wouldn't suggest to introduce this method in our context.
> 
> The first idea which came to my mind was...
> 
> allow multiple parameters like with std::function and fix the t via
> bind...
> 
>       auto f = [](Coord x, double t) -> int { return ...; };
> 
> Now the first thing is we have to reimplement major parts of bind, as
> the returned function must provide more information, because we want
> to be able to to do
> 
>       auto fx = bind(f, 1_, current_timestep);
>       auto flocal = localview(fx);
> 	  flocal.bind(entity);
> 	  u = flocal(x);
> 
> The other question which arises is ... what about
> derivatives. Currently our derivative is the full derivative and not
> partial, but usally you will only want the spatial derivatives.
> 
> An other example might be that you have non-linear function
> 
>       auto f = [](Coord x, double u) -> int { return c(x)*u*u; };
> 
> which depends on the current solution. (Actually this is something
> Sebastian is doing in a simular way currently with PDELab and if we
> implement if as discussed below, his code would be so much easier to
> read ;-)) In this case it would be nice if you could simply write
> something like
> 
>       DiscreteGridFunction<...> u(...);
> 	  auto fx = std::bind(f, _1, std::bind(u,_1));
> 
> then fx(x) would be equivalent to f(x,u(x)).
> But now we want to have derivatives and usually we want the spatial
> derivatives, but perhaps you want, within some optimization the
> derivative with respect to u... Here a nice way of writing it could
> look like this:
> 
>       derivative(f) == derivative(f, DerivativeDirection<1>());
>       auto dfdx == derivative(f, DerivativeDirection<1>());
>       auto dfdx == derivative(f, derivativeDirection::_1);
>       auto dfdu == derivative(f, Component<2>());
>       auto dfdu == derivative(f, derivativeDirection::_2);
> 
> I think we don't want to compute all derivative all the time, in order
> so avoid unnecessary computations and sometimes it is not also not
> easy to define the aproriate derivative in all components.
> 
> So the first question is what would we consider a good interface and
> the second is how would we implement it. The first tricky part is that
> the return type of derivative changes and that the number of
> derivative functions the interface of the polymorphic version changes
> with the number of entries in the Domain... variadic parameter pack.
> We might be able to work around this by using a TMP recursion, similar
> to what we did in the localfunctions interface, but this time we do
> this to loop through the different Domain... parameters and not
> through the different diff-orders.
> 
> Opinions welcome...
> 
> Christian