I'd like to see this sorted out too. Here is an idea:
1. introduce class GenericNonlinearSolver
2. NewtonSolver, PETScSNESSolver, PETScTAOSolver will subclass 1.
3. introduce GenericLinearAlgebraFactory::create_nonlinear_solver()
4. introduce constructor
NonlinearVariationalSolver::NonlinearVariationalSolver(
std::shared_ptr<NonlinearVariationalProblem>,
std::shared_ptr<GenericNonlinearSolver>)
5. introduce solver accessor
NonlinearVariationalSolver::nonlinear_solver()
It may sound too complicated and not in concert with Garth's goals. But
it is a logical step which allows user to bring his own nonlinear
solver to NonlinearVariationalSolver, and accessing it back using a
method. At the same time it will also solve Garth's original complaint.
Any comments?
Jan
On Thu, 18 Jun 2015 10:43:50 +0100
"Garth N. Wells" <[email protected]> wrote:
> I'll pin it on Patrick :).
>
> It does raise questions around the GenericFoo interface. I don't think
> these are sustainable; linear algebra data structures and solver
> backends are too specialised to use effectively via a generic
> interface.
>
> I would like to see in the linear algebra code that:
>
> - GenericVector/Matrix become as simple as possible to allow common
> assembly code for different backends.
>
> - Remove as many of the generic solver classes as possible.
>
> - Allow solvers to return matrices (PETSc does this), which a user can
> then fill. This is a bit like a factory; the solver is 'top of the
> pile' for linear algebra, so it makes sense that it can provide a
> suitable matrix for the user to fill.
>
> I'm trying to fix
> https://bitbucket.org/fenics-project/dolfin/issue/530, but our
> complicated design is making this difficult. For example,
> PETScKrylovSolver takes a bunch of different operators
> (GenericLinearOperator, GenericMatrix, PETScBaseMatrix, . . . . ), but
> only works with PETSc operators, so it would be better if it only
> accepted PETSc operators.
>
> Garth
>
>
>
> On 18 June 2015 at 10:10, Anders Logg <[email protected]> wrote:
> > From git blame:
> >
> > 61d5036a (Garth N. Wells 2014-02-28 22:11:14 +0000 132) #ifdef
> > ENABLE_PETSC_SNES
> > 676f6644 (Patrick Farrell 2012-10-15 20:41:48 +0100 133) else if
> > (std::string(parameters["nonlinear_solver"]) == "snes")
> > 676f6644 (Patrick Farrell 2012-10-15 20:41:48 +0100 134) {
> > 676f6644 (Patrick Farrell 2012-10-15 20:41:48 +0100 135) //
> > Create SNES solver and set parameters
> > 543a756a (Garth N. Wells 2014-01-22 15:54:46 +0000 136) if
> > (!snes_solver)
> > 676f6644 (Patrick Farrell 2012-10-15 20:41:48 +0100 137) {
> > 676f6644 (Patrick Farrell 2012-10-15 20:41:48 +0100 138) //
> > Create Newton solver and set parameters
> > b50a82eb (Anders Logg 2014-02-10 21:35:33 +0100 139)
> > snes_solver = std::shared_ptr<PETScSNESSolver>(new
> > PETScSNESSolver()); 676f6644 (Patrick Farrell 2012-10-15 20:41:48
> > +0100 140) } 676f6644 (Patrick Farrell 2012-10-15 20:41:48
> > +0100 141)
> > snes_solver->parameters.update(parameters("snes_solver"));
> >
> > --
> > Anders
> >
> >
> > tors 18 juni 2015 kl 10:51 skrev Garth N. Wells <[email protected]>:
> >>
> >> When did PETSc SNES code slip into NonlinearVariationalSolver? It
> >> obviously shouldn't be in there because NonlinearVariationalSolver
> >> is not specific to a linear algebra backend.
> >>
> >> Garth
> >> _______________________________________________
> >> fenics mailing list
> >> [email protected]
> >> http://fenicsproject.org/mailman/listinfo/fenics
> _______________________________________________
> fenics mailing list
> [email protected]
> http://fenicsproject.org/mailman/listinfo/fenics
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
