On Fri, Jun 24, 2011 at 05:08:15PM +0200, Marie E. Rognes wrote: > On 06/22/11 22:42, Anders Logg wrote: > >Dear all, > > > >I have now implemented the discussed changes (in the dolfin/logg > >branch). Problems can now be solved in one of two ways. The interfaces > >look very similar in C++ and Python and very similar for linear and > >nonlinear problems (same number of arguments etc). Here's what it > >looks like now. > > > >1. Short option > > > > solve(a == L, u, bc) > > solve(F == 0, u, bc, J=J) > > > >* The bc argument is optional and can be either a single bc or a list. > > > >* The J=J argument is not yet handled. > > > >2. Long (advanced) option > > > > problem = LinearVariationalProblem(a, L, u, bc) > > solver = LinearVariationalSolver(problem) > > solver.parameters[...] = ... > > solver.parameters[...] = ... > > solver.solve() > > > > problem = NonlinearVariationalProblem(a, L, u, bc) > > solver = NoninearVariationalSolver(problem) > > problem.set_jacobian(J) > > solver.parameters[...] = ... > > solver.parameters[...] = ... > > solver.solve() > > > > Is calling NonlinearVariationalSolver with a > LinearVariationalProblem and vice versa allowed? If yes, what > happens then?
Not currently. The NonlinearVariationalSolver only has a constructor for NonlinearVariationalProblem. One can consider extending it so that it may in addition take a LinearVariationalProblem and treat it as a nonlinear problem. One may also consider adding other solver class FooVariationalSolver that implement other strategies like simple fixed-point (Picard) iteration. Anyway, those will just be additions to the current interface and won't require design changes. -- 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