Hi, May I know if this change will appear in petsc-devel soon? We are trying to interface Petsc to a proprietary direct solver package. If we should expect the change soon, we may consider push back the plan a little bit. Thank you.
regards, shenchen On Tue, Aug 12, 2008 at 12:40 AM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > Mat in PETSc is actually a short hand notation for "Linear > transformation" > http://en.wikipedia.org/wiki/Linear_transformation. Essentially the only > operation defined by a linear transformation is A*x. Matrices are simply > one > way of representing finite dimensional linear transformations. So a > Mat is suppose to ALWAYS provide a MatMult() everything else is optional > :-). > > Now you can certainly say that we should have called linear > transformations > in PETSc something like: LT or LinearTrans or many other things. We chose > Mat since almost everyone understands linear transformations as matrices so > we do not need to provide a high-falutin explanation of LT that would > simply > alienate and scare most potential users. Everyone thinks they understand > Mat immediately. > > > Now back to the issue at hand. You had a very valid point in the previous > email: for a factored matrix if we define MatMult() as the triangular > solves > then the factored matrix defines a linear transformation (whose > representation > is not simply a two dimensional array, but is slightly more complicated > beast). > So we could define a MATFACTOR as a new Mat object, like MatMFFD is > a Mat object and then subclass the various packages factors undernether > it. > > Barry > > > > > > > > On Aug 11, 2008, at 9:11 AM, Lisandro Dalcin wrote: > > On Fri, Aug 8, 2008 at 2:01 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: >> >>> This is just at hack to avoid so many changes in PETSc. >>> MatMFFD is truly a matrix (it has matrix vector product). >>> >> >> Well, I'm not so sure about that. Do it has MatSetValues() ? >> >> >> >> 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 >>>> >>>> >>> >>> >> >> >> -- >> 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 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20080817/15de3f57/attachment.html>
