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 <bsmith at mcs.anl.gov> > 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 <bsmith at mcs.anl.gov> >>> 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://petsc at petsc.cs.iit.edu//hg/petsc/petsc-dev-new-solvers >>>> >>>> and trying it out before then. Please report problem to >>>> petsc-maint at mcs.anl.gov 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 >