recent changes to ILUDT and matrix factorization API

Lisandro Dalcin dalcinl at gmail.com
Tue Apr 28 21:03:48 CDT 2009


On Tue, Apr 28, 2009 at 3:00 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>     The LUDT is currently work in progress and will change as you suggest
> once it is close
> to being done.
>

OK, nice to now... The change made petsc4py testsuite segfault, and
then I complained :-) , just in case...

>      Regarding in place factorization. For dense matrices in place makes
> perfect sense and
> in fact is commonly (perhaps overly) used in the NA community.
>

Wow! I just never take into account that PETSc also supports dense matrices :-)

In short, sorry for all the noise...


>
> On Apr 28, 2009, at 12:07 PM, Lisandro Dalcin wrote:
>
>> 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
>
>



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