On Mon, Oct 20, 2008 at 1:12 PM, Jed Brown <[EMAIL PROTECTED]> wrote: > > 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.
This raises a valid point. In the attached image I've shown another possible hierarchy. (In case it doesn't make it to the list and you want to see, email me.) The idea is that there is now a PetscMatrixBase from which PetscMatrix and PetscShellMatrix are derived. As shown in the figure, PetscMatrixBase implements mat(), so that either can be used with the Petsc solve routines. This image also shows a generic ShellMatrix-derived-from-NumericMatrix as we've been discussing. This allows for the development of future "shell" matrix types which have nothing to do with Petsc. It may be a little confusing that a PetscShellMatrix is-not-a ShellMatrix, but trying to implement multiple inheritance here is asking for trouble because you would have the "dreaded diamond" problem (http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.8) ... -- John
<<attachment: sparse_matrix_family.png>>
------------------------------------------------------------------------- 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
