Subject: [Fenics] VariationalProblem interface(s)

From: Marie Rognes <[email-masked]>
Date: Wed, 20 Oct 2010 19:39:11 +0200

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)

>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.

Philosophical question: Should u be given as an argument to the
  VariationalProblem instead of to the call to solve?

Comments welcome!

--
Marie

---

From: Johan Hake <[email-masked]>
Date: Wed, 20 Oct 2010 12:20:01 -0700

> interface, and hence the double post to both the dolfin and

I guess this discussion comes on top of the previous one? Because that 
blueprint mentioned a lot more than what is mentioned here.

I also assume this is limited to the Python interface as doing stuff like 
derivative behind the scene is limited to PyDOLFIN?

> 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?

>   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.

Johan

> Comments welcome!
> 
> --
> Marie
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp

---

From: Marie Rognes <[email-masked]>
Date: Wed, 20 Oct 2010 21:54:07 +0200

> blueprint mentioned a lot more than what is mentioned here.

Yes.

> 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.

> 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.

> difficult to make u an optional argument to solve.

I'm rather flexible at this point.

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).

--
Marie

---

From: Johan Hake <[email-masked]>
Date: Wed, 20 Oct 2010 13:40:59 -0700

> incorporating the desired implicit derivative for Python users.

Ok.

> > 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?
> 

Agree. However, I am not using VariationalProblem to anything :)

> > 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.
> 

Me too.

> 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

---

From: Marie Rognes <[email-masked]>
Date: Wed, 20 Oct 2010 23:16:13 +0200

On 20. okt. 2010 22:40, Johan Hake wrote:
>>>> >From Marie's perspective, the main reasons for changing the interface
>>>>         
>>>>> are
>>>>>
>>>>>           

First, currently the VariationalProblem does not tell the user any such
thing (in Python). 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.

--
Marie

---

From: Johan Hake <[email-masked]>
Date: Wed, 20 Oct 2010 14:20:19 -0700

On Wednesday October 20 2010 14:16:13 Marie Rognes wrote:
> >>> 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.
> >> 
> >>> 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?
> >> 
> > Sure, but how does a VariationalProblem know it is nonlinear so it can
> > tell a user to provide u in solve?
> 
> thing (in Python). 

Sure, we are talking about a Blueprint.

> Second, for the c++ interface (afaik), the u always

Ok.

For curiosity: 

  How could you use ufl to figure out if a form is (non)linear?

Johan

---

From: Marie Rognes <[email-masked]>
Date: Mon, 25 Oct 2010 14:34:22 +0200

On 24. okt. 2010 02:38, Ridgway Scott wrote:
> I would like to add a new suggestion about the language for
> variational forms.
> Attached is a paper
>
> TR-2010-09
> <http://www.cs.uchicago.edu/research/publications/techreports/TR-2010-09>
>     Languages and Compilers for Variational Forms. Robert Kirby
>     <http://www.cs.uchicago.edu/people/kirby>; Matt Knepley; L.
>     Ridgway Scott <http://www.cs.uchicago.edu/people/ridg>. 23
>     October, 2010. Communicated by L. Ridgway Scott
>     <http://www.cs.uchicago.edu/people/ridg>.
>
> that we have prepared on this.
>
> The main point is to have a language for the spaces used to
> incorporate boundary conditions
> while still having spaces needed for boundary conditions.
>

I agree that a way of specifying constrained spaces would be good. We
had some discussion on this point with regard to boundary conditions a
while back, cf:

    https://blueprints.launchpad.net/dolfin/+spec/constrained-spaces

Do you have a concrete suggestion of how you would prefer such a notion 
to be incorporated in the UFL/DOLFIN interface?

--
Marie

> Ridg
>
>
>
>
> On Oct 20, 2010, at 2:16 PM, Marie Rognes wrote:
>
>>>>>> https://blueprints.launchpad.net/dolfin/+spec/solver-interfaces)
>>>>>> <https://blueprints.launchpad.net/dolfin/+spec/solver-interfaces%29>
>>>>>> there
>>>>> VariationalProblem
>>>>> Jacobian),
>> Mailing list: https://launchpad.net/~fenics
>> Post to     : [email-masked]
>> <mailto:[email-masked]>
>> Unsubscribe : https://launchpad.net/~fenics