fenics team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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