using MUMPS with mg

Barry Smith bsmith at mcs.anl.gov
Mon Jun 23 14:49:23 CDT 2008


   Lisandro,

    The way I see it the problem with the current code is that any Mat  
that one creates
"knows" how to do factorizations. For example it has  
MatCholeskyFactorSymbolic().
Thus if one wants to use a Mumps factorization one needs a different  
matrix class
(MATAIJMUMPS for example), this is difficult for users to understand  
and also
silly since WAY back in the code before I start filling up my matrix,  
the LU I want to
use comes into play.

    The original "fix" I proposed was MatSetSolverType() that would  
allow one to
set the solver type to the matrix LATER. This would have essentially  
been like
calling a MatConvert() on the matrix to a specialized form like  
MATAIJMUMPS.
A major drawback to this approach is that it keeps all the horrible,  
horrible, MatConvert()
code to the specialized type that is ugly, bug ridden and impossible  
to maintain
extend and understand.

    Then I realized a clean solution that eliminates ALL the ugly  
convert code. It
comes with the realization that the factor routines belong as methods  
on the FACTORED
matrix (since it is the factored matrix algorithm and data structures  
that are affected by
the MUMPS, SuperLU etc), not the original matrix. Thus ALL the convert  
crap can be dumped :-).
My current test model is MatGetFactor(Mat  
A,MatSolverType,MatFactorType,Mat *fact);
followed by MatLUFactorSymbolic(fact,A,.....) Once I have it all  
working I am, of course, open
to name suggestions and tweaks. Once you see it you'll like it :-)


    Barry



On Jun 23, 2008, at 2:29 PM, Lisandro Dalcin wrote:

> On 6/23/08, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>>   It will be gone.
>>
>
> Ups! Was this decided in some private discussion? I remember the post
> were you proposed this; I also remember there were some objections,
> but you started it anyway, so I guessed that this was already
> accepted.
>
> IMHO, the whole idea was +1 for me (though I did not commented on
> this). Did you change your mind? Was this rejected for the other
> developers in the PETSc team? Was a better mechanism devised?
>
>
> -- 
> 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
>




More information about the petsc-dev mailing list