dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Wednesday October 20 2010 14:44:45 Marie Rognes wrote:
> On 20. okt. 2010 23:20, Johan Hake wrote:
> > 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.
> 
> Yes, but for there to be purpose to blueprints, some of them actually
> have to be realized, occasionally ;)

:)

> >> 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?
> 
> For the current situation, one could probably just check rank:
> 
>     rank == 1 => non-linear in the sense that u is required (F = F(u; v))
>     max_rank >= 2 => linear in the sense that u is not required (F =
> a(v, u) - L(v)).

Ok, but is it possible to use the derivative function in ufl to figure out if 
it is linear? 

In sympy the expression is changed to the actual derivative. In ufl the 
operation is just added to the abstract tree representation.

Btw: 

Is the rank function in ufl borked:

  mesh = UnitSquare(1, 1)
  V = FunctionSpace(mesh, "CG", 1)
  v = TestFunction(V)
  u = Function(V)
  L = u*v*dx
  rank(L)
  => AttributeError: 'Form' object has no attribute 'shape'

or do I need to preprocess the form first?

Johan

> 
> --
> Marie
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp