On 21 June 2011 10:37, Anders Logg <l...@simula.no> wrote: > On Tue, Jun 21, 2011 at 10:19:22AM +0200, Marie E. Rognes wrote: >> >> >> On 21. juni 2011, at 09:58, Anders Logg <l...@simula.no> wrote: >> >> > Thanks for looking into this. So it looks like this will work out >> > fine. So are there any objections to changing the VariationalProblem >> > (which depends on the order of arguments) to the more explicit >> > >> > LinearVariationalSolver >> > NonlinearVariationalSolver >> > >> > *solver* classes (instead of problem classes so that it's consistent >> > with the way we treat la), and adding on top of this the free function >> > solve() as a shortcut: >> > >> > solve(a == L, ...) >> > solve(F == 0, ...) >> > >> > If not, I can get started on implementing this. >> > >> >> Very much in favor :) >> >> Where does u enter in the free functions? > > Don't know yet. Suggestions are welcome. My suggestion would be to > follow what Mathematica and swiginac and always include it as the argument > following the equation. We would then have this: > > solve(a == L, u, bc) > solve(F == 0, u, bc, J=J)
Looks good to me. In Python we should check if u is among the coefficients of F, otherwise raise an error. That will cover the bug case of defining F with u1 and providing u2 to solve. In NonlinearVS, I think u should be part of the constructor arguments, so it's not needed by solve: NonlinearVariationalSolver solver(F, u, bcs, ...); NonlinearVariationalSolver solver(F, u, J, bcs, ...); solver.solve(); Martin > The drawback is we can't do > > u = solve(a == L) > > but that's similar to how we handle linear systems where we do > > solve(A, x, b) > > instead of > > x = solve(A, b) > > -- > 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
