dolfin team mailing list archive

[Kent-Andre Mardal <kent-and@xxxxxxxxx>]

tir, 01.04.2008 kl. 11.23 +0200, skrev Martin Sandve Alnæs:
> 2008/4/1, Kent-Andre Mardal <kent-and@xxxxxxxxx>:
> >
> >  tir, 01.04.2008 kl. 11.08 +0200, skrev Martin Sandve Alnæs:
> >
> > > I don't see what's the point of that. The only reasons for
> >  > Matrix/Vector are related to having a single LA backend in each
> >  > application run, but a variety of solvers may be used in the same
> >  > application.
> >  >
> >
> >
> > I thought the reason for having Matrix/Vector was to ensure that only
> >  GenericMatrix/GenericVector functionality was used. I guess the PETSc
> >  and the uBlas families now live seperate lives.
> 
> Then why don't you come up with an example of where this makes sense
> for solvers.
> 
> --
> Martin

I'm not sure if it make sense.
The Python Krylov solvers that we have implemented only needs (in
addition to the three functions added to GenericMatrix and GenericVector
yesterday) a preconditioner. 

  class GenericPreconditioner
  {
    public: 

      virtual void update(const GenericMatrix& A) = 0; 
      virtual void apply(const GenericVector& x, GenericVector& y) = 0; 
  };


The name can be something else than GenericPreconditioner. 

(To none-PyCC users: The advantage of the Python Krylov solvers
is that they work on block matrices and block vectors)

Kent