On Wed, Oct 22, 2008 at 5:38 AM, Tim Kroeger <[EMAIL PROTECTED]> wrote: > > On Tue, 21 Oct 2008, John Peterson wrote: > >> The attached updated class tree shows how I now >> envision the hierarchy going. > > Your inheritance hierarchy makes user code that uses the shell matrices > functionality solver dependent: The user has to explicitly instantiate e.g. > PetscDyadMatrix. You might later implement shell matrices for other solver > packages, and I would find it more appropriate to have a DyadMatrix class as > the user API and let everything that depends on the solver package be hidden > from the user.
This is a good point and raises the issue of how one will interact with these new matrix types in a general System setting. Up to this point your modifications have been to the PetscLinearSolver but eventually I would like this to work within the confines of the existing ImplicitSystem. My current thought is to extend ImplicitSystem::add_matrix(string) to also take a NumericMatrix* (default NULL). Current users can then continue with the default SparseMatrix::build behavior currently in add_matrix(), while giving the opportunity for other users to attach any other kind of ShellMatrix at the same time. One just needs to remember that the System will finally delete any Matrix added to it. To address the issue of the shell matrices being tied to Petsc, see the attached new class diagram. I think we should continue using the pseudo-virtual-constructor idea which is now employed in SparseMatrix::build() which basically gives you the correct type depending on what solver package you have asked for. All the Petsc types are now multiply derived from (and dynamic_cast'able to) PetscMatrixBase, which will be little more than a C++ wrapper for a Petsc Mat object. There is no need for the multiple-inheritance diamond in this hierarchy. > By the way: What about my question concerning matrix/vector contraining? I > didn't receive any answer to that from any of you guys. I'm not quite sure what the answer is, perhaps someone who understands the constraints better will eventually comment. I think it must depend on what the dyad matrix represents, and how it should be constrained? > By the way: I attached a new version of my patch. I have added the > possibility to use a SparseMatrix as the preconditioning matrix when the > system matrix is a ShellMatrix. Got it, thanks. -- John
<<attachment: sparse_matrix_family_v5.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
