On 27 July 2015 at 17:36, Jan Blechta <[email protected]> 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" <[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
