New approach for external direct solvers in PETSc

[Barry Smith]

   Keita,

   I don't see anything but very minor fixes to the current config/ 
configure.py and install process.

    Barry


On Aug 18, 2008, at 1:57 PM, Keita Teranishi wrote:

> 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:owner-petsc- 
> dev at mcs.anl.gov] 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@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
>>
>>
>>
>