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 F, u, bcs, J = 0 >From the Python side, the empty list syntax is particularly neat, pde = LinearVariationalProblem(a, L, u, []) Garth > -- > Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
