[dune-functions] Interface limitations in the functions interface

[Oliver Sander]

Hi Christian,
this all sounds nice and interesting, but it also sounds like a major undertaking.
How about writing a prototype in dune-pdelab using as much from dune-functions as
possible, and then discuss whether we want to move certain parts of it into dune-functions?
Also: Do you need this to be able to do any form of migration to dune-functions?
Can you, as a short-term solution, migrate your current system (with, e.g., the
setTime method) to the new dune-functions infrastructure?
I am not saying your proposals are bad, I'd just rather not have a big complicated
design project block all dune-pdelab migration efforts.
Best,
Oliver

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
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-functions/attachments/20150319/b284bf7b/attachment.sig>