← Back to team overview

dolfin team mailing list archive

Re: VariationalProblem interface

 


On 13/06/11 12:51, 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. 

Which means that the simple call

  u = pde.solve()

will not be possible.

> 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 experience is the complete opposite of this.

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

This might be fine for toy problems, but not for real problems. There is
overhead in a nonlinear solve to check for convergence, which is not
required if the eqn is linear.

Garth


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