[Dune] dune-istl solvers and preconditioners

[Markus Blatt]

On Wed, Jul 23, 2008 at 12:20:08PM +0200, Christian Engwer wrote:

> 1) you can't us solver as a preconditioner. If you could so, you could
>    i.e. use not-restarted gmres with m vectors inside a loopsolver and
>    you'd have a restarted gmres. You might also want to use a direct
>    solver as precoditioner for a cg in order to obtain reductions
>    beyond double precision.
> 
>    I suggest to derive solver from precoditioner. The main difference
>    is that a solver is allowed to overwrite the righthand side in
>    order to save memory. An implementation of the precoditioner-apply
>    in the solver base class could just copy the rhs and call the
>    solver apply. This change should not have any impact on the current
>    implementations, but would add extra flexibility.

This breaks the whole design of the parallel ISTL. Currently a solver
can be used in parallel as well as in sequential mode. It just depends
on using the right (matching) scalarproducts, preconditioners, and
operators. 

E.g. if you use sequential versions of these the CGSolver is sequential,
while if you use parallel versions of them your CGSolver is parallel

Your approach would mean that each solver now has to provide at
compile time whether it is sequential or parallel, too. Which with the
current design simply is not possible.

Probably one could easily provid a wrapper that turns a solver into a
preconditioner. 

> 
> 2) while working on the qmr solver I had the following problem. It
>    requires the precoditioner M to be evaluated as M^T. For many of
>    our current preconditioners this would be easy to implement. But
>    currently those preconditioners allow to be executed multiple
>    times. Due to this, it is really hard to implement an
>    applytransposed or such.
> 
>    I'd suggest to add a new base class transposableprecoditioner (or
>    such) which is derived from preconditioner. This class offers the
>    new method applytransposed. The same could be done for the
>    operaters.
> 

Actually one can get rid of using the transposed by using the
transpose-free QMR of Freund. I think this is the way to go. It is not
always possible to calculate the transpose of a matrix as we might
just have an approximation of it.

>    I'd also suggest to remove the run-multiple-times feature from
>    precoditioners like jacobi, gauss-siedel and ilu, in order to allow
>    an easy implementation of the applytransposed. If you want to run
>    the preconditioner multiple times, you could just add the
>    loopsolver(precond) as the precoditioner.
> 

I would second that. But you should ask Peter, too.

Cheers,

Markus