Hi Barry, I'd like to grab the dev version with new direct solver interface. Just a question. Will the packaging (bmake and configure script) form of the final release be similar to the dev version?
Thanks, ================================ Keita Teranishi Math Software Group Cray, Inc. keita at cray.com ================================ -----Original Message----- From: owner-petsc-dev at mcs.anl.gov [mailto:[email protected]] On Behalf Of Barry Smith Sent: Sunday, August 17, 2008 9:35 AM To: petsc-dev at mcs.anl.gov Subject: Re: New approach for external direct solvers in PETSc We will most definitely make a release by December 1 2008. This means any changes like this will have to be made pretty soon. Any changes will actually have only a small effect on the user interface (but a bigger effect on PETSc's simplicity). Barry On Aug 16, 2008, at 11:55 PM, Chen Shen wrote: > 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 > > >
