dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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