dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #19987
Re: VariationalProblem interface(s)
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?
Johan
>
> --
> Marie
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help : https://help.launchpad.net/ListHelp
Follow ups
References