fenics team mailing list archive

[Marie Rognes <meg@xxxxxxxxx>]

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