[dune-functions] Interface limitations in the functions interface

[Christian Engwer]

Hi !

>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.

I started a prototype implementation for this... it is feasible, although not totally straight forward

>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)

I think stating that local coordinates are the first argument is totally OK.

>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.

No, I just wanted to take derivatives wrt to one parameter and avoid taking the total derivative.

Christian

>
>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
>
>
>_______________________________________________
>dune-functions mailing list
>dune-functions at dune-project.org
>http://lists.dune-project.org/mailman/listinfo/dune-functions