New approach for external direct solvers in PETSc

[Barry Smith]

    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
>