dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Jun 13, 2011 at 01:51:16PM +0200, Marie E. Rognes wrote:
> On 06/13/2011 10:03 AM, Garth N. Wells wrote:
> >
> >
> >On 12/06/11 22:54, Anders Logg wrote:
> >>On Wed, Jun 08, 2011 at 11:47:10PM +0200, Anders Logg wrote:
> >>>I'm on a cell phone and can't engage in any discussions but I just
> >>>want to throw something in. Marie and I discussed at some point
> >>>another option which is to write everything as F = 0 and let UFL
> >>>compute J even for linear problems. J would be a optional
> >>>variable. Then we could have a common interface and also a common
> >>>solver.
> >>
> >
> >I think that this would be a nice option, but I don't think that it can
> >work without a more elaborate interface than just
> >
> >   pde = VariationalProblem(F, bcs)
> >
> >because UFL cannot know which coefficient in a form is unknown, and
> >therefore which function to compute the linearisation with respect to.
> >Moreover,
> >
> >  - UFL cannot compute the linearisation for all forms
> >  - In some cases it's not desirable to let UFL do the linearisastion
> >
>
> Some specific responses: First, the moment solve is called (with a
> coefficient), which function to compute the linearization with respect
> to, is known. Second, the Jacobian could definitely be provided as an
> optional argument for those cases where it is not feasible/desirable
> for UFL to do the linearization. See below for longer, more general
> rant.
>
> >>Any further thoughts on this? It's important we get this right.
> >>
> >>I can live with
> >>
> >>   LinearVariationalProblem
> >>   NonlinearVariationalProblem
> >>
> >>if everyone else thinks that's the best option,
>
> I don't think it is the best option.
>
> >>but don't really like
> >>it since it's very long.
>
> My reasons do not really relate to the length of the name, but rather
> that I do not see why we should make the difference between linear and
> nonlinear variational problems greater in the _highest level
> interface_ of DOLFIN. I think this just makes things more cumbersome
> (a) in terms of debugging and (b) in terms of explaining how to solve
> variational problems to FEniCS beginners.
>
> My typical pedagogical use case looks something like this (in Python):
> Say you have explained to someone how to solve stationary Stokes with
> Taylor-Hood, and then want to extend to Navier-Stokes. Then ideally
> all that should be necessary is to add the nonlinear term to the
> form(s). But no. In addition, you at least have to replace the
> TrialFunction with a Function (which typically leads to a longer
> discussion on what a TrialFunction represents and why that is used for
> linear problems when the same ansatz is made for the two in most text
> books), and then you have to call solve with the same Function instead
> of just returning it (which is also on my top 3 list of pitfalls). I
> don't see how adding
> LinearVariationalProblem/NonlinearVariationalProblem to the list makes
> it better.  The same (but the other way) goes when wanting to debug
> Navier-Stokes by reducing to Stokes.
>
> In essence, I've started treating all variational problems as
> nonlinear.

I'm also starting to think that is the best option. Some issues to discuss:

1. Is there any additional work involved in treating all linear
problems as nonlinear? At first glance, it looks like it would involve
one additional assembly of the linear form (to check for
convergence). Can it be avoided?

2. What should the C++ interface look like? Should one still
instantiate one bilinear and one linear form? Or should the names
change to Poisson::Residual / Poisson::Jacobian?

--
Anders