dolfin team mailing list archive

[Marie Rognes <meg@xxxxxxxxx>]

On 24. okt. 2010 02:38, Ridgway Scott wrote:
> I would like to add a new suggestion about the language for
> variational forms.
> Attached is a paper
>
> TR-2010-09
> <http://www.cs.uchicago.edu/research/publications/techreports/TR-2010-09>
>     Languages and Compilers for Variational Forms. Robert Kirby
>     <http://www.cs.uchicago.edu/people/kirby>; Matt Knepley; L.
>     Ridgway Scott <http://www.cs.uchicago.edu/people/ridg>. 23
>     October, 2010. Communicated by L. Ridgway Scott
>     <http://www.cs.uchicago.edu/people/ridg>.
>
> that we have prepared on this.
>
> The main point is to have a language for the spaces used to
> incorporate boundary conditions
> while still having spaces needed for boundary conditions.
>


I agree that a way of specifying constrained spaces would be good. We
had some discussion on this point with regard to boundary conditions a
while back, cf:

    https://blueprints.launchpad.net/dolfin/+spec/constrained-spaces

Do you have a concrete suggestion of how you would prefer such a notion 
to be incorporated in the UFL/DOLFIN interface?

--
Marie

> Ridg
>
>
>
>
> On Oct 20, 2010, at 2:16 PM, Marie Rognes wrote:
>
>> 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)
>>>>>> <https://blueprints.launchpad.net/dolfin/+spec/solver-interfaces%29>
>>>>>> 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
>>
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~fenics
>> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
>> <mailto:fenics@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~fenics
>> More help   : https://help.launchpad.net/ListHelp
>>
>