fenics team mailing list archive

[Marie Rognes <meg@xxxxxxxxx>]

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.


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


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

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