dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Jul 05, 2006 at 10:07:18AM +0200, Garth N. Wells wrote:

> > > One thing - wouldn't it be better if the Krylov solver is preconditioned
> > > by default?
> > > 
> > > Garth
> > 
> > Maybe, but I don't think it's possible. The Krylov solver can only
> > assume that the matrix it gets can do mult() and size(). To create
> > a preconditioner, it normally needs to know more than that. The ILU
> > preconditioner needs to know a whole lot more.
> > 
> 
> Why do we have just one uBlasKrylovSolver::solve() function for both
> sparse and virtual matrices, whereas we have two
> PETScKrylovSolver:solve() functions (one or sparse matrices, one for
> virtual matrices)? What if we had something like
> 
>     uint solve(const uBlasSparseMatrix& A, DenseVector& x, 
>                const DenseVector& b);
> 
>     uint solve(const uBlasKrylovMatrix& A, DenseVector& x, 
>                const DenseVector& b, const uBlasPreconditioner& pc);
> 
> where the first function would apply a default preconditioner.

That might be a good option. I thought about overloading on the matrix
type so we would have a special function for uBlasSparseMatrix that
does preconditioning, but if we also have a function that accepts
a uBlasKrylovMatrix, then that function would always be called.

If we do as you suggest now, that would not be a problem anymore, and
it also solves the problem with having "good" default options.

For uBlasSparseMatrix, we would thus have a simple default solver with
a good default preconditioner, and for more general matrices, one
would need to specify the preconditioner. It would also be easy to fix
and we wouldn't need to duplicate any code. Sounds good.

/Anders


> If we don't precondition by default, I would prefer to remove the
> function
> 
>     uint solve(const uBlasKrylovMatrix& A, DenseVector& x, 
>                const DenseVector& b);
> 
> because it will be useless for 99% of problems and encourages the
> unknowing the use of non-preconditioned solvers.
> 
> > One could argue that the Krylov solver should not precondition by
> > default. A user needs to choose the Krylov method and the
> > preconditioner. The combination of a Krylov solver and preconditioner
> > could be something on top of that. For example, the modules will
> > choose a suitable combination, and the automated solvers (LinearPDE
> > etc) will also choose a suitable combination.
> > 
> 
> This isn't consistent with the approach we've taken with the PETSc
> Krylov solver. I prefer to have "good" default options which can be
> changed if necessary for a particular problem. 
> 
> Garth 
> 
> > We could add an abstraction layer in between, something like
> > LinearSolver that takes a matrix and depending on the matrix type (by
> > overloading) it chooses a Krylov solver and preconditioner or a direct
> > solver if it gets something dense.
> > 
> > One could also argue that maybe the matrix itself could be allowed to
> > suggest a suitable preconditioner. We could add a member function pc()
> > to uBlasKrylovMatrix that returns a suitable preconditioner. This
> > function could be virtual but not pure virtual and return an
> > uBlasDummyPreconditioner by default.
> > 
> > /Anders
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev
>