New approach for external direct solvers in PETSc

[Lisandro Dalcin]

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