On Wednesday October 20 2010 14:16:13 Marie Rognes wrote: > On 20. okt. 2010 22:40, Johan Hake wrote: > > On Wednesday October 20 2010 12:54:07 Marie Rognes wrote: > >> On 20. okt. 2010 21:20, Johan Hake wrote: > >>> On Wednesday October 20 2010 10:39:11 Marie Rognes wrote: > >>>> A while back (in connection with the blueprint > >>>> https://blueprints.launchpad.net/dolfin/+spec/solver-interfaces) there > >>>> was a discussion regarding the interface to VariationalProblem. Anders > >>>> and Marie have discussed this a bit further, in particular with regard > >>>> to the adaptive solution of variational problems, and suggest the > >>>> interface outlined below. (This suggestion involves a change in the > >>>> interface, and hence the double post to both the dolfin and > >>>> fenics-mailinglists) > >>> > >>> I guess this discussion comes on top of the previous one? Because that > >>> blueprint mentioned a lot more than what is mentioned here. > >> > >> Yes. > >> > >>> I also assume this is limited to the Python interface as doing stuff > >>> like derivative behind the scene is limited to PyDOLFIN? > >> > >> Yes and no. > >> > >> Using derivative is limited to Python (for now...). However, the > >> suggested change allows a clean common interface for c++ and Python, > >> incorporating the desired implicit derivative for Python users. > > > > Ok. > > > >>>> >From Marie's perspective, the main reasons for changing the interface > >>>> > > >>>>> are > >>>>> > >>>> (a) The current "nonlinear=true" variable seems superfluous and > >>>> > >>>> suboptimal > >>>> > >>>> (b) We should allow for automated computation of the Jacobian > >>>> (when > >>>> > >>>> needed). > >>>> > >>>> For (nonlinear) variational problems, the interface should read > >>>> > >>>> pde = VariationalProblem(Form F, Form jacobian=None, ...) > >>>> pde.solve(u) > >>>> > >>>> where "F" is a Form of rank 1, "jacobian" is a Form of rank 2, and "u" > >>>> is a Function. Such a pde will be treated as a nonlinear variational > >>>> problem. The "jacobian" would be an optional argument. If not given, > >>>> > >>>> jacobian = derivative(F, u) > >>>> > >>>> will be used for the nonlinear solve if needed (for instance as the > >>>> left-hand side of the Newton iteration). > >>>> > >>>> Additionally, we have the interface for linear problems (as before) > >>>> > >>>> pde = VariationalProblem(Form a, Form L, ...) > >>>> pde.solve(u) / u = pde.solve() > >>>> > >>>> where "a" is a Form of rank 2 and "L" is a form of rank 1. Such as pde > >>>> will be treated as a linear variational problem. > >>> > >>> Some wild thoughts... > >>> > >>> Couldn't we just lump a and L into one form F, and let > >>> VariationalProblem then figure out what kindoff problem the user would > >>> like to solve? Basically VariationalProblem then solve F=0. > >>> > >>> Differentiate F if the form is of rank 1, (or take an optional > >>> Jacobian), or split it into a linear problem using lhs and rhs? > >> > >> This is possible in the Python interface with the model suggested above. > >> (Just implies adding a bit more intelligence than indicated) However, > >> for the sake of the c++ interface (and many application codes), not > >> removing the (a, L) option seems like a good idea to me. > > > > Agree. However, I am not using VariationalProblem to anything :) > > > >>>> Philosophical question: Should u be given as an argument to the > >>>> > >>>> VariationalProblem instead of to the call to solve? > >>> > >>> It is more natural to give u to solve, as that is what you solve for. > >>> Then you can differentiate wrt to u in the solve function. However, it > >>> makes it more difficult to make u an optional argument to solve. > >> > >> I'm rather flexible at this point. > > > > Me too. > > > >> Note that u is only an optional argument if the problem is linear, > >> right. For my purposes, no differentiation is needed in such cases (and > >> hence u can be created and not given). > > > > Sure, but how does a VariationalProblem know it is nonlinear so it can > > tell a user to provide u in solve? > > First, currently the VariationalProblem does not tell the user any such > thing (in Python).
Sure, we are talking about a Blueprint. > Second, for the c++ interface (afaik), the u always > needs to be prescribed Third, if we want to tell the Python user, we > could either always require the input u if the > > VariationalProblem(F, ...) > > version is used, or, add some quick UFL magic that checks F for > (non-)linearities and reports back if u is needed. Ok. For curiosity: How could you use ufl to figure out if a form is (non)linear? Johan > -- > Marie _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
