On Mon 2008-10-20 12:49, John Peterson wrote:
> On Mon, Oct 20, 2008 at 12:34 PM, Jed Brown <[EMAIL PROTECTED]> wrote:
> > class Matrix {
> > public:
> > // not_implemented for all matrix operations (mult, multtranspose, etc)
> > protected:
> > Mat A_petsc;
> > Epetra::RowMatrix A_epetra;
> > };
>
> I see what you are getting at, but this violates all the encapsulation
> we have worked to achieve in the linear solver interfaces up to this
> point. I'm not saying that's intrinsically bad, it's just not the
> path we've taken. Unless it were absolutely required, I don't think
> the amount of work required for redesigning the whole class hierarchy
> in this way is warranted.It was just thought. But mandating that a PetscLinearSolver needs a PetscMatrix means that your MatShell must derive from PetscMatrix and ::mat() must return a PETSc Mat. This means you can't use the same implementation with a different solver. If you care about supporting different solvers (personally I don't since I'm happy with PETSc's interface to external packages) then you wouldn't want your proposed hierarchy (unless I'm missing some trick). An alternative is to make ShellMatrix a factory, producing a PetscMatrix or EpetraMatrix. This is basically the same, but you'll probably end up duplicating matrix-sized storage in the (rare) case that the matrix is used by a PETSc solver in one place and by a Trilinos solver elsewhere. Jed
pgpMOLnFaQvcO.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
