dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Apr 30, 2007 at 03:59:26PM +0200, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > I have added a simple solver interface solve.h, which supplies a
> > single function
> > 
> >     solve(A, x, b);
> > 
> > This is to make the interface consistent with the assembly, so we have
> > 
> >     assemble(A, ...);
> >     assemble(b, ...);
> >     solve(A, x, b);
> > 
> > Before, we had FEM::assemble() and LU::solve(), but I think the above
> > looks cleaner. We would then have two free functions in DOLFIN, namely
> > assemble() and solve().
> > 
> > The solve() function creates the appropriate LUSolver object and then
> > calls its solve method.
> > 
> > My thinking is that we can provide a very simple interface to just
> > solving a linear system. When using an iterative method, you probably
> > anyway want to specify preconditioners etc, so then the extra step of
> > creating a solver object is not in the way:
> > 
> >     KrylovSolver solver(KrylovMethod::gmres, Preconditioner::ilu);
> >     solver.solve(A, x, b);
> > 
> > If this sounds reasonable, I think we can remove the classes GMRES,
> > LU, LinearSolver, PETScLinearSolver, uBlasLinearSolver.
> >
> 
> We can remove GMRES, but I think that the others need to stay. 
> NewtonSolver, for example, owns a LinearSolver. It's important that 
> NewtonSolver owns its solver to allow for reuse, etc. PETScLinearSolver 
> and uBlasLinearSolver are base classes for anyone wanting to implement 
> their own linear solver.
> 
> Garth

ok, sounds reasonable.

/Anders