dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Jul 11, 2011 at 11:51:03AM +0100, Garth N. Wells wrote:
>
>
> On 10/07/11 12:45, Anders Logg wrote:
> > On Sun, Jul 10, 2011 at 10:56:02AM +0100, Garth N. Wells wrote:
> >>
> >>
> >> On 10/07/11 10:08, Anders Logg wrote:
> >>> On Thu, Jul 07, 2011 at 02:44:20PM -0700, Johan Hake wrote:
> >>>> On Thursday July 7 2011 12:21:26 Anders Logg wrote:
> >>>>> On Thu, Jul 07, 2011 at 02:20:44PM +0200, Marie E. Rognes wrote:
> >>>>>> Is the plan for 1.0-beta to fix
> >>>>>>
> >>>>>> https://bugs.launchpad.net/ffc/+bug/787010
> >>>>>>
> >>>>>> and then release?
> >>>>>
> >>>>> Yes + decide on the interface for NonlinearVariationalProblem.
> >>>>>
> >>>>> I think that should be all.
> >>>>>
> >>>>> It would be good to hear more comments on the two suggestions:
> >>>>>
> >>>>> 1. (current)
> >>>>>
> >>>>>   NonlinearVariationalProblen(lhs, rhs, u, bcs, [J])
> >>>>>
> >>>>>   This is consistent with LinearVariationalProblem and the solve()
> >>>>>   functions; same order of arguments.
> >>>>>
> >>>>> 2. (Garth)
> >>>>>
> >>>>>   NonlinearVariationalProblen(lhs, u, bcs, [J])
> >>>>>
> >>>>>   This removes the unnecessary rhs argument which always has to be
> >>>>>   zero.
> >>>>>
> >>>>> I think there are good arguments for both but not very strong so it's
> >>>>> a matter of taste.
> >>>>
> >>>> If:
> >>>>
> >>>>   The point is that it makes the interface for all variational problems
> >>>>   (linear or nonlinear) the same:
> >>>>
> >>>> is the only reason, I go with Garth.
> >>>
> >>> Another reason is complications in the implementation, both in C++ and
> >>> the Python layer. Nothing I can't handle but it leads to complications.
> >>> I have started to implement it but it's looking messy.
> >>>
> >>> I also would like to keep the set_jacobian function. The constructors
> >>> will otherwise be a mess: there will be very many constructors with
> >>> varying order of arguments which is both error prone and tedious to
> >>> implement/maintain.
> >>>
> >>
> >> How is it error prone when each argument is a different type and can be
> >> check at compile time?
> >
> > There would still be an error, even if it is caught by a check (at
> > compile-time or run-time depending on whether C++ or Python is used).
> >
> > I claim it's less error prone (=less likely to cause errors, some of
> > which may be caught) since users will learn the one common signature
> > used by both Linear/NonlinearVariationalProblem and the solve() functions:
> >
> >   lhs, rhs, solution, [bcs]
> >
> >>> We would need the following variations of constructors for linear and
> >>> nonlinear variational problems:
> >>>
> >>>   a, L, u
> >>>   a, L, u, bc
> >>>   a, L, u, bcs
> >>>   F, u
> >>>   F, u, J
> >>>   F, u, bc
> >>>   F, u, bc, J
> >>>   F, u, bcs
> >>>   F, u, bcs, J
> >>
> >>> Instead of one common signature:
> >>>
> >>>   lhs, rhs, u, [bcs]
> >>>
> >>> Of course there will still need to be some variations to implement,
> >>> but those are only handling various ways to specify the boundary
> >>> conditions, either none, bc or bcs.
> >>>
> >>> The advantage is clarity: only needing to remember lhs, rhs, u, [bcs].
> >>>
> >>
> >> I would argue the opposite; requiring a pointless function argument is
> >> confusing.
> >>
> >> If it's too greater burden to provide all the above constructors, the
> >> number of constructors can be rationalised.
> >
> > Exactly how do you propose to rationalize it?
> >
>
> Always provide a vector/list of bcs:
>
>   a, L, u, bcs

That seems very clumsy.

>   F, u, bcs, J = 0

That is also clumsy if one needs to supply J as a (shared) pointer.

> From the Python side, the empty list syntax is particularly neat,
>
>   pde = LinearVariationalProblem(a, L, u, [])

>From the Python side we can use default arguments to handle both bcs
and J:

  NonlinearVariationalProblem(F, u, bcs=bcs, J=J)

But I would prefer if we could keep the two interfaces similar.

Maybe we can but it requires adding quite a few different
constructors in C++. It's something we only have to do once so maybe
we can live with it.

--
Anders