On Wed, Oct 22, 2008 at 11:52 AM, Jed Brown <[EMAIL PROTECTED]> wrote:
> trying to keep this on -devel...
Oops, yes I will try and do the same.
[snipped]
> The scary thing here would be the implicit cast (creating a new
> PetscMatrix which is a MatShell) occurs when a Matrix (which might even
> be a PetscMatrix) is passed to a Petsc solver. This is why I think it's
> cleaner to put the getter for the PETSc Mat in Matrix since this would
> enable the solvers to take any Matrix. In this case, we'd have
This type of cast is indeed scary, since you cannot tell if it
succeeds by checking the result. If we make use of polymorphism,
through the use of a common, correctly implemented PetscMatrixBase
class, then we can use dynamic_cast to help us, which conveniently
returns a NULL pointer upon failure.
I'm not too worried about supporting *completely* arbitrary
UserShellMatrix objects. It's easy enough, and I think, reasonable,
to have folks derive their UserShellMatrices from NumericMatrix (for
the required interface) and PetscMatrixBase (for the required Mat
object data). This approach also does not preclude them from, in
addition, deriving from (an eventual, correctly implemented)
EpetraMatrixBase and even other types, to allow use of a
UserShellMatrix with the other solver types.
> Mat Matrix::petsc_mat() {
> Mat mat;
> MatCreateShell(comm,B.m,B.n,B.M,b.N,(void*)this,&mat);
> MatShellSetOperation(mat,MATOP_MULT,(void(*)(void))matshell_mult);
> // set wrappers for any other operations supported by B
> return mat;
> }
>
> Mat PetscMatrix::petsc_mat() {
> return _mat;
> }
>
> This is great except for the (small) memory leak. We can wrap the Mat
> object in a reference counted pointer which calls MatDestroy() when
> needed or just put the _mat object in Matrix (which I don't see as a
> huge break in abstraction) in which it is guaranteed to be unique for
> any Matrix.
I'm still just (admittedly stubbornly) against the concept of the
abstract base having anything to do with derived types. 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.
We do rely heavily on Petsc and approximately 100% of the
NumericMatrices used in the code will actually be Petsc matrices, but
we should at least try to keep on pretending that our NumericMatrix
class is linear algebra library independent ;)
--
John
-------------------------------------------------------------------------
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
