Sounds good, as long as there is also a default option that allows the solver not to be passed if the user does not care or knows enough to choose the solver.
-- Anders mån 27 juli 2015 kl 20:15 skrev Garth N. Wells <gn...@cam.ac.uk>: > On 27 July 2015 at 17:36, Jan Blechta <blec...@karlin.mff.cuni.cz> wrote: > >> 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. > > > I floated the same idea recently (can't recall if it was on Bitbucket or > the mailing list), so I'm all for it. The solver should be passed to the > 'solve§§§§' interface, > > solve (F==0, nonlinear_solver) > > Garth > > >> 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" <gn...@cam.ac.uk> 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 <anders.l...@gmail.com> 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 <gn...@cam.ac.uk>: >> > >> >> > >> 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 >> > >> fenics@fenicsproject.org >> > >> http://fenicsproject.org/mailman/listinfo/fenics >> > _______________________________________________ >> > fenics mailing list >> > fenics@fenicsproject.org >> > http://fenicsproject.org/mailman/listinfo/fenics >> >>
_______________________________________________ fenics mailing list fenics@fenicsproject.org http://fenicsproject.org/mailman/listinfo/fenics
