This is just at hack to avoid so many changes in PETSc. MatMFFD is truly a matrix (it has matrix vector product). Barry On Aug 8, 2008, at 8:23 AM, Lisandro Dalcin wrote:

Barry, after thinking a bit more, I believe I've found an approach that is not so radical.

Why not to follow the approach for MatMFFD? That is, introduce a new matrix type, instead of a brand new object type. Let me call this new matrix type MATFACTOR. This new matrix type contains a hidden PetscObject, and that object is filled with appropriate methods depending on the MatSolverPackage.

This new way will not introduce a new object type in the user-level API. An I believe that we will still simplify the code. Now a MatSolve in a MATSEQAIJ matrix will fail just because it will not have the operation filled in the 'virtual table'. MATFACTOR will fill the MatXXXFactor{Symbolic/Numeric} options in the vtable, but it will not fill things like MatMult and MatSetValues. This way, we will not need any more to 'check' if a standard matrix type like SEQAIJ, MPIAIJ, etc are or are not factored (and perhaps we can handle dense matrices in a special way, just because inplace factorizations do really make sense). So the all the 'mat->factor' checks can finally go away!

What do you think?

On Thu, Aug 7, 2008 at 5:05 PM, Barry Smith <[email protected]> wrote:

...

On Jul 25, 2008, at 5:47 PM, Lisandro Dalcin wrote:

...

BTW, Have you ever considered the posibility of not using the 'Mat' class for factored matrices?? I believe that normal matrices and factored matrices share very few in common as to being instances of the same class. Looking at the source code in src/mat, there are many checks like 'if (mat-->factor)' or 'if (!mat->factor)' that seems to support my concern. What do you think?

After a (tiny) bit more thought I think we really should make this change:

pros 1) it will simplify the code a good amount hence less bugs 2) conceptually it makes sense cons 1) requires a large reorganization of the Mat code (will introduce bugs) 2) requires the user to deal with one more PETSc object (MatFactor) But since most users deal with SNES/KSP/PC most users will never see this new object.

The question is when/how to make this massive change. It is as big or bigger than the change I already made with MatGetFactor().

Barry

...

On Fri, Jul 25, 2008 at 7:02 PM, Barry Smith <[email protected]> wrote:

...

petsc-dev users,

I have finally completed my changes to PETSc for a new approach to accessing external direct solvers in PETSc like Spooles, MUMPS etc. I will be pushing it to petsc-dev sometime the middle of next week. If you are using the direct solvers you might consider cloning from

http://petsc.cs.iit.edu/hg/petsc/petsc-dev-new-solvers or

ssh://[email protected]//hg/petsc/petsc-dev-new-solvers

and trying it out before then. Please report problem to [email protected] as you hit them.

Barry

From the changes file

The "parallel direct solver" matrix types like MATAIJSPOOLES are ALL gone. Now you use - pc_factor_mat_solver_package spooles etc or PCFactorSetMatSolverPackage() or if working directly with matrices, MatGetFactor(A,MATSPOOLES,...)

-- Lisandro Dalc�n --------------- Centro Internacional de M�todos Computacionales en Ingenier�a (CIMEC) Instituto de Desarrollo Tecnol�gico para la Industria Qu�mica (INTEC) Consejo Nacional de Investigaciones Cient�ficas y T�cnicas (CONICET) PTLC - G�emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

-- Lisandro Dalc�n --------------- Centro Internacional de M�todos Computacionales en Ingenier�a (CIMEC) Instituto de Desarrollo Tecnol�gico para la Industria Qu�mica (INTEC) Consejo Nacional de Investigaciones Cient�ficas y T�cnicas (CONICET) PTLC - G�emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594