← Back to team overview

dolfin team mailing list archive

Re: VariationalProblem interface

 

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.

--
Marie

Another option (if we don't go for the F = 0
option) is

   VariationalProblem
   NonlinearVariationalProblem


I prefer to the long one. I don't see any advantage in favouring a short
name over a more explicit and readable name.

Garth

--
Anders

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


_______________________________________________
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