VariationalProblem interface is error prone

[Garth Wells]

The VariationalProblem interface distinction between linear and nonlinear problems is opaque and error prone (and it's not just me). It's a common source of questions and confusion from users. The distinction between linear and nonlinear problems needs to be much clearer. Subtly is not a good thing for this type of problem.

[Marie Rognes (meg-simula)]

On 06/08/2011 08:59 AM, Garth Wells wrote:
> Public bug reported:
>
> The VariationalProblem interface distinction between linear and
> nonlinear problems is opaque and error prone (and it's not just me).
> It's a common source of questions and confusion from users. The
> distinction between linear and nonlinear problems needs to be much
> clearer. Subtly is not a good thing for this type of problem.
>
> ** Affects: dolfin
> Importance: Undecided
> Status: New
>

The tons of questions we have been getting about the
VariationalProblem interface are not primarily due to a bug in the
interface, but rather a symptom of the following three "bugs":

1. Lack of documentation of stable versions
2. Lack of documentation of development version
3. Lack of (user-available) documentation of changes in interface
   ("What's new")

Fixing those are therefore higher on my list of priorities ;-)

Some other miscellaneous comments:

(a) I always forgot the nonlinear=True/False parameter with the previous
interface, so that had the same error-prone-ness.

(b) I don't think anyone can say that there is one _true_ order of the
bilinear and the linear form. However, for nonlinear problems, the
Jacobian doesn't really enter in the problem definition. It is rather
a required property of the solution method (Newton). In particular, it
should be perfectly fine to define a nonlinear variational problem
with only the linear variational form and do a default solve by Picard
iteration.

(c) In view of (b), one alternative could be to introduce the Jacobian
in the call to solve instead. Then one could enable automatic
differentiation in the Python interface too.

--
Marie

[Garth Wells (garth-wells)]

On 08/06/11 15:34, Marie Rognes wrote:
> On 06/08/2011 08:59 AM, Garth Wells wrote:
>> Public bug reported:
>>
>> The VariationalProblem interface distinction between linear and
>> nonlinear problems is opaque and error prone (and it's not just me).
>> It's a common source of questions and confusion from users. The
>> distinction between linear and nonlinear problems needs to be much
>> clearer. Subtly is not a good thing for this type of problem.
>>
>> ** Affects: dolfin
>> Importance: Undecided
>> Status: New
>>
>
>
> The tons of questions we have been getting about the
> VariationalProblem interface are not primarily due to a bug in the
> interface, but rather a symptom of the following three "bugs":
>
> 1. Lack of documentation of stable versions
> 2. Lack of documentation of development version
> 3. Lack of (user-available) documentation of changes in interface
> ("What's new")
>
> Fixing those are therefore higher on my list of priorities ;-)
>
> Some other miscellaneous comments:
>
> (a) I always forgot the nonlinear=True/False parameter with the previous
> interface, so that had the same error-prone-ness.
>

I'm not advocating this.

> (b) I don't think anyone can say that there is one _true_ order of the
> bilinear and the linear form. However, for nonlinear problems, the
> Jacobian doesn't really enter in the problem definition. It is rather
> a required property of the solution method (Newton). In particular, it
> should be perfectly fine to define a nonlinear variational problem
> with only the linear variational form and do a default solve by Picard
> iteration.
>

I don't think that this is an issue either.

> (c) In view of (b), one alternative could be to introduce the Jacobian
> in the call to solve instead. Then one could enable automatic
> differentiation in the Python interface too.
>

The Jacobian can be computed by UFL only for a subset of problems. It
would be a nice feature to have, but it would not support all the
necessary cases.

Why I advocate is that the code should be as explicit as possible. We
should make it as hard as possible for a user to screw up by getting the
order of function arguments wrong. I would like to have something like
the the objects

  LinearVariationalProblem

and

  NonlinearVariationalProblem

Garth

> --
> Marie
>

[Martin Sandve Alnæs (martinal)]

On 8 June 2011 17:15, Garth Wells <email address hidden> wrote:
> On 08/06/11 15:34, Marie Rognes wrote:
>> On 06/08/2011 08:59 AM, Garth Wells wrote:
>>> Public bug reported:
>>>
>>> The VariationalProblem interface distinction between linear and
>>> nonlinear problems is opaque and error prone (and it's not just me).
>>> It's a common source of questions and confusion from users. The
>>> distinction between linear and nonlinear problems needs to be much
>>> clearer. Subtly is not a good thing for this type of problem.
>>>
>>> ** Affects: dolfin
>>>       Importance: Undecided
>>>           Status: New
>>>
>>
>>
>> The tons of questions we have been getting about the
>> VariationalProblem interface are not primarily due to a bug in the
>> interface, but rather a symptom of the following three "bugs":
>>
>> 1. Lack of documentation of stable versions
>> 2. Lack of documentation of development version
>> 3. Lack of (user-available) documentation of changes in interface
>>    ("What's new")
>>
>> Fixing those are therefore higher on my list of priorities ;-)
>>
>> Some other miscellaneous comments:
>>
>> (a) I always forgot the nonlinear=True/False parameter with the previous
>> interface, so that had the same error-prone-ness.
>>
>
> I'm not advocating this.
>
>> (b) I don't think anyone can say that there is one _true_ order of the
>> bilinear and the linear form. However, for nonlinear problems, the
>> Jacobian doesn't really enter in the problem definition. It is rather
>> a required property of the solution method (Newton). In particular, it
>> should be perfectly fine to define a nonlinear variational problem
>> with only the linear variational form and do a default solve by Picard
>> iteration.
>>
>
> I don't think that this is an issue either.
>
>> (c) In view of (b), one alternative could be to introduce the Jacobian
>> in the call to solve instead. Then one could enable automatic
>> differentiation in the Python interface too.
>>
>
> The Jacobian can be computed by UFL only for a subset of problems. It
> would be a nice feature to have, but it would not support all the
> necessary cases.
>
> Why I advocate is that the code should be as explicit as possible. We
> should make it as hard as possible for a user to screw up by getting the
> order of function arguments wrong. I would like to have something like
> the the objects
>
>  LinearVariationalProblem
>
> and
>
>  NonlinearVariationalProblem
>
> Garth

I agree with Garth here. I also want to add
that this is not only about getting it right
when writing code. The intuitiveness of an
API is more related to how easy it is to
_read_ than how easy it is to _write_.

A more explicit interface will make easier
the tasks of reading examples and
documentation, reading other peoples code,
reading your own old code, and spotting a
mistake at a glance while debugging.

p1 = VariationalProblem(J, -F, bcs)
p2 = VariationalProblem(F, J, bcs)

The only information here that tells me that
p2 is a nonlinear problem is in my own
variable names. If I use less typical names,
you have to read more code to spot it.

I have also not seen a single feature
mentioned that cannot be done with
the e.g. the ...

[Johan Hake (johan-hake)]

On Wednesday June 8 2011 09:37:46 Martin Sandve Alnæs wrote:
> On 8 June 2011 17:15, Garth Wells <email address hidden> wrote:
> > On 08/06/11 15:34, Marie Rognes wrote:
> >> On 06/08/2011 08:59 AM, Garth Wells wrote:
> >>> Public bug reported:
> >>>
> >>> The VariationalProblem interface distinction between linear and
> >>> nonlinear problems is opaque and error prone (and it's not just me).
> >>> It's a common source of questions and confusion from users. The
> >>> distinction between linear and nonlinear problems needs to be much
> >>> clearer. Subtly is not a good thing for this type of problem.
> >>>
> >>> ** Affects: dolfin
> >>> Importance: Undecided
> >>> Status: New
> >>
> >> The tons of questions we have been getting about the
> >> VariationalProblem interface are not primarily due to a bug in the
> >> interface, but rather a symptom of the following three "bugs":
> >>
> >> 1. Lack of documentation of stable versions
> >> 2. Lack of documentation of development version
> >> 3. Lack of (user-available) documentation of changes in interface
> >> ("What's new")
> >>
> >> Fixing those are therefore higher on my list of priorities ;-)
> >>
> >> Some other miscellaneous comments:
> >>
> >> (a) I always forgot the nonlinear=True/False parameter with the previous
> >> interface, so that had the same error-prone-ness.
> >
> > I'm not advocating this.
> >
> >> (b) I don't think anyone can say that there is one _true_ order of the
> >> bilinear and the linear form. However, for nonlinear problems, the
> >> Jacobian doesn't really enter in the problem definition. It is rather
> >> a required property of the solution method (Newton). In particular, it
> >> should be perfectly fine to define a nonlinear variational problem
> >> with only the linear variational form and do a default solve by Picard
> >> iteration.
> >
> > I don't think that this is an issue either.
> >
> >> (c) In view of (b), one alternative could be to introduce the Jacobian
> >> in the call to solve instead. Then one could enable automatic
> >> differentiation in the Python interface too.
> >
> > The Jacobian can be computed by UFL only for a subset of problems. It
> > would be a nice feature to have, but it would not support all the
> > necessary cases.
> >
> > Why I advocate is that the code should be as explicit as possible. We
> > should make it as hard as possible for a user to screw up by getting the
> > order of function arguments wrong. I would like to have something like
> > the the objects
> >
> > LinearVariationalProblem
> >
> > and
> >
> > NonlinearVariationalProblem
> >
> > Garth
>
> I agree with Garth here. I also want to add
> that this is not only about getting it right
> when writing code. The intuitiveness of an
> API is more related to how easy it is to
> _read_ than how easy it is to _write_.
>
> A more explicit interface will make easier
> the tasks of reading examples and
> documentation, reading other peoples code,
> reading your own old code, and spotting a
> mistake at a glance while debugging.
>
> p1 = VariationalProblem(J, -F, bcs)
> p2 = VariationalProblem(F, J, bcs)
>
> The only information here that te...

[Anders Logg (logg)]

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.

--
Anders

8 jun 2011 kl. 19:06 skrev Johan Hake <email address hidden>:

> On Wednesday June 8 2011 09:37:46 Martin Sandve Alnæs wrote:
>> On 8 June 2011 17:15, Garth Wells <email address hidden> wrote:
>>> On 08/06/11 15:34, Marie Rognes wrote:
>>>> On 06/08/2011 08:59 AM, Garth Wells wrote:
>>>>> Public bug reported:
>>>>>
>>>>> The VariationalProblem interface distinction between linear and
>>>>> nonlinear problems is opaque and error prone (and it's not just me).
>>>>> It's a common source of questions and confusion from users. The
>>>>> distinction between linear and nonlinear problems needs to be much
>>>>> clearer. Subtly is not a good thing for this type of problem.
>>>>>
>>>>> ** Affects: dolfin
>>>>> Importance: Undecided
>>>>> Status: New
>>>>
>>>> The tons of questions we have been getting about the
>>>> VariationalProblem interface are not primarily due to a bug in the
>>>> interface, but rather a symptom of the following three "bugs":
>>>>
>>>> 1. Lack of documentation of stable versions
>>>> 2. Lack of documentation of development version
>>>> 3. Lack of (user-available) documentation of changes in interface
>>>> ("What's new")
>>>>
>>>> Fixing those are therefore higher on my list of priorities ;-)
>>>>
>>>> Some other miscellaneous comments:
>>>>
>>>> (a) I always forgot the nonlinear=True/False parameter with the previous
>>>> interface, so that had the same error-prone-ness.
>>>
>>> I'm not advocating this.
>>>
>>>> (b) I don't think anyone can say that there is one _true_ order of the
>>>> bilinear and the linear form. However, for nonlinear problems, the
>>>> Jacobian doesn't really enter in the problem definition. It is rather
>>>> a required property of the solution method (Newton). In particular, it
>>>> should be perfectly fine to define a nonlinear variational problem
>>>> with only the linear variational form and do a default solve by Picard
>>>> iteration.
>>>
>>> I don't think that this is an issue either.
>>>
>>>> (c) In view of (b), one alternative could be to introduce the Jacobian
>>>> in the call to solve instead. Then one could enable automatic
>>>> differentiation in the Python interface too.
>>>
>>> The Jacobian can be computed by UFL only for a subset of problems. It
>>> would be a nice feature to have, but it would not support all the
>>> necessary cases.
>>>
>>> Why I advocate is that the code should be as explicit as possible. We
>>> should make it as hard as possible for a user to screw up by getting the
>>> order of function arguments wrong. I would like to have something like
>>> the the objects
>>>
>>> LinearVariationalProblem
>>>
>>> and
>>>
>>> NonlinearVariationalProblem
>>>
>>> Garth
>>
>> I agree with Garth here. I also want to add
>> that this is not only about getting it right
>> when writing code. The intuitiveness of an
...