On Thu 2008-10-23 09:07, John Peterson wrote: > M*N inheritance is unnecessary. The user would implement > UserShellMatrixBase and inherit from all M different solvers they'd > like to use, then they'd derive their N different sub shell matrices > from UserShellMatrixBase. If another linear solver package is added, > UserShellMatrixBase now inherits from M+1 solvers and the children > don't have to change.
There is a diamond inheritance problem here. Each of the solver bases derives singly from MatrixBase and ShellMatrixBase derives (multiply) from all solver bases. Now if I derive MyShellMatrix from ShellMatrixBase, implement mult() (overriding MatrixBase::mult()), and cast to a PetscMatrix, I end up calling MatrixBase::mult(). This in a simple test I cooked up, maybe there's a trick to get around this. If it can't be resolved, then the situation is really terrible, the user's matrix can only work with one solver and you can't use any solvers with a foreign matrix type. If you can resolve the hyper-diamond inheritance, can you make it possible to use an EpetraMatrix with a PetscSolver (without the user manually wrapping it in a shell matrix)? > > The user derives Matrix to implement their shell matrices. > > Right, but I think we already agreed that the interface required by a > shell matrix is a subset of that provided by a full-featured (what we > are now calling) SparseMatrix. This was the rationale for creating a > new base class, smaller than SparseMatrix, which is easier to derive > from. Oh, I didn't realize that had been agreed upon. There's no reason why a shell matrix can't implement everything a first-class matrix can. Many of them won't, but what's the harm in just using not_implemented? Why arbitrarily cripple shell matrices? > >> While there may be no practical problems (or only minor > >> inconveniences, for example, the entire petsc_mat() interface must be > >> #ifdef'd out when LIBMESH_HAVE_PETSC is 0) with this approach, I just > >> think it is bad design. > > > > Why must the interface be #ifdef'd out? There is no chance you would > > end up with a PetscMatrix if it wasn't compiled with PETSc, but there's > > no chance you'd have a PetscSolver either so you'd never try to call > > Matrix::petsc_mat(). If you did, you'd get not_implemented() since the > > implementation would be #ifdef'd out. > > It won't compile if it's not #ifdef'd out when Petsc is unavailable. Because of the existence of the Mat type? It would be common to just use a forward declaration typedef struct _p_Mat *Mat; rather than including petscmat.h, even when PETSc *is* present, so that you don't blast the users namespace with a bunch of implementation that they're never expected to use. The *interface* is fine with or without PETSc. > > Putting one pointer in Matrix per solver package is ugly and avoidable, > > but it's simpler, reduces the number of objects to keep track of, and > > guarantees that shell objects are created at most once. It does mean > > that the user will have to recompile (but not modify!) their code if new > > solver packages are added, but not if existing packages are > > enabled/disabled. > > It's not exactly one pointer/solver package. It's potentially all the > 'private' implementation details of each of the M solver packages. > For example, Epetra needs Epetra_FECrsMatrix*, Epetra_Map*, and > Epetra_CrsGraph*. These could all be encapsulated in yet another > pimpl-like class, and this is a valid design, but I don't think it's > the one we want to take, and it's certainly not one I'm volunteering > to implement... Epetra has (as far as I can tell) terrible support for shell matrices and you may need a wrapper for whatever it needs. It's still just one private pointer and one method in the interface. Jed
pgp32UMchFhiv.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
