On 2014-01-28 19:23, Patrick Farrell wrote:
Hi all,
At the highest-level Python interface, the user calls
solve(F == 0, u, bcs, ..).
Lower down, the nonlinear solvers in Dolfin (NewtonSolver and
PETScSNESSolver) take in objects of type NonlinearProblem.
The code that glues these together is NonlinearDiscreteProblem,
which is currently nested within NonlinearVariationalSolver,
and private.
Lately I've been using some advanced nonlinear solver options and
block preconditioning techniques that I can only express by
accessing the underlying SNES object. To set up the solver,
I've had to duplicate the functionality of NonlinearDiscreteProblem
in several different codes.
My question: is there any reason why it's private and hidden?
It looks like it was intended to be just a convenience class to allow
NonlinearVariationalSolver to interface with the nonlinear solvers.
May I make it public, or shall I keep copying & pasting my Python
reimplementation around?
I don't have an objection to it being spun out, but it is of limited
practical use. I'd recommend implementing the NonlinearProblem
interface. A plus of this approach is that if your system is symmetric
you can use CG or MINRES, which you can't with NonlinearDiscreteProblem.
Write a class derived from NonlinearProblem to avoid code duplication.
Garth
Cheerio,
Patrick
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
