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