New approach for external direct solvers in PETSc

[Barry Smith]

     This is just at hack to avoid so many changes in PETSc.
MatMFFD is truly a matrix (it has matrix vector product).

     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
>