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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
