1) Yes it should be "init(SparseMatrix<T>* matrix) " instead of "init(PetscMatrix<T>* matrix)".

2) I overloaded init() so that there is one that takes a matrix and the original init() that does
not take a matrix as input.  PC() and KSP() still use the original init() with no arguments.  I have
only used the "init(SparseMatrix<T>* matrix) " in the call to solve(...) where I used a matrix that
has been dynamically cast from a SparseMatrix to a PetscMatrix.  Thus there should always there
be a matrix available.

3) If we called KSPSetOperators() before calling init() in solve then that would remove
this odd dependency.  It is still clunky code though.  I could also try to call KSPSetFromOptions()
in solve and get rid of this call in init().


----- Original Message ----
From: Roy Stogner <>
To: Travis Austin <>
Cc: libMesh maillist <>
Sent: Tuesday, January 16, 2007 10:27:17 AM
Subject: Re: [Libmesh-users] Multilevel and multigrid on libMesh

On Mon, 15 Jan 2007, Travis Austin wrote:

> It is probably best to completely replace the init() call with an
> init(PetscMatrix <T>* matrix) call.  Any thoughts on the cleanest
> way to fix this up.

Well, we'd need that to be init(SparseMatrix<T>* matrix) instead for
consistency with other solver implementations...  but then what
happens when we don't have a matrix built when we call init?
In the PETSc methods, pc() and ksp() both call init(); what do we have
them hand in as a matrix?

I'd certainly like algebraic multigrid working, but I don't want to
inadvertently break anything else in the process.  I don't know enough
about the PETSc API, but is there really no way to move the offending
functions from init() to solve() to avoid such an odd matrix

Take Surveys. Earn Cash. Influence the Future of IT
Join's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
Libmesh-users mailing list

We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.