| Thread Previous • Date Previous • Date Next • Thread Next |
On 07/11/11 12:51, 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 F, u, bcs, J = 0
Having to provide a list of boundary conditions if none are needed seems more unnecessary to me.
-- Marie
> 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@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
| Thread Previous • Date Previous • Date Next • Thread Next |
