On Thu, Jan 22, 2009 at 7:40 PM, Derek Gaston <fried...@gmail.com> wrote: > > We need a Preconditioner class. It will allow you to setup a preconditioner > and use it multiple times with different RHS vectors.
The linear solver interface seems to be already general enough to do this for solves; you can specify a matrix for preconditioning and you can re-use it multiple times. Granted we don't have a separate way of just applying a preconditioner outside of a solve scenario, but this is essentially always a matrix-vector product, or whatever shell routine you have specified to perform that action, and we have generic interfaces for matrix-vector products already. > It should inherit from LinearSolver, using the matrix and rhs vector to This I don't agree with at all, it conflates the idea of an object whose responsibility is to solve a linear system and an object which is a component part of a linear solve. The LinearSolver class has always been intended as a generic interface class for hiding the implementation details of concrete sparse linear solver instantiations (petsc, trilinos, laspack) and I don't think what you are describing "is a" LinearSolver in that sense. > Just to give an example of a Preconditioner: the PetscPreconditioner would > create a PC struct calling PCCreate(), PCSetType() and PCSetOperators() for > you. Then when solve is called it would do a PCApply(pc, rhs, solution). The PCSetType part duplicates existing functionality in the PetscLinearSolver class, but it should be possible to unify that and other duplicated things in a nice way. > Looking over ML (in Trilinos) it would have similar behavior. > To sum up the justification of these classes: I have to do a _lot_ of manual > petsc and libmesh manipulation to setup separate preconditioning systems and > _efficiently_ solve them.... and a lot of that manipulation is going to have > to be duplicated for using ML in Trilinos. > So what do you guys think? If I get the thumbs up I could probably have > something in the repository by the end of the day tomorrow... The functionality you are describing does not appear to me to be too far outside the ShellMatrix interface class we had an extensive thread on previously. Even if you don't want your Preconditioner class to derive from a NumericMatrix of some kind, don't you agree that it will have a lot of "matrix-like" interfaces? In my opinion you should make Preconditioner an abstract base class, and make it usable within the existing LinearSolver interface, not derive from it. -- John ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
