recent changes to ILUDT and matrix factorization API

[Lisandro Dalcin]

In a recent commit, MatILUDTFactorSymbolic() and
MatILUDTFactorNumeric() were merged in MatILUDTFactor(). However,
MatILUDTFactor() does not do itself the MatGetFactor() call (instead,
that call is hardwired in PCSetUp_ILU()).

IMHO, MatILUDTFactor() (or the type-specific implementations) should
make the call to MatGetFactor(). This is like things work for
MatLUFactor(), for example.

Moreover, I believe PC ILU when "ilu->usedt" is now broken for the
cases "pc->flag != SAME_NONZERO_PATTERN" and "!ilu->reusefill",
because of the MatDestroy() calls.

Finally I would like to point that I'm somewhat -1 in the whole change
merging the calls. Let's take for example LU factorization.

A) If you want to perform LU factorization with "in-place" semantics,
you call MatLUFactor(A). In this case, the "in-place" is just
semantics, as the operation is always truly inplace (certainly not for
SeqAIJ, for example).

B) If you want to perform LU factorization with "out-of-place"
semantics, you call MatGetFactor(A,&fact) +
MatLUFactorSymbolic(fact,A) + MatLUFactorNumeric(fact,A).

I do not see why ILUDT (or even ILU(n) with n>1) should be treated
differently. The only one that could be special cased is ILU(0),
because it can be done truly in-place if the user request it.

Perhaps other option is remove all calls like (A), just because truly
"in-place" cannot be done in practice, and special case ILU(0) and
ICC(0). I mean, the only calls with "in-place" semantics should be
MatILUFactor() and MatICCFactor(), but the fail if the levels of fill
is not zero.




-- 
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