[dune-functions] Interface limitations in the functions interface

Christian Engwer christian.engwer at uni-muenster.de
Wed Mar 18 22:37:16 CET 2015


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




More information about the dune-functions mailing list