New approach for external direct solvers in PETSc

Sat Aug 16 23:55:05 CDT 2008

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20080817/15de3f57/attachment.html>