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? > 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. 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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
