[petsc-users] PCFactorSetMatSolverPackage / PCFactorGetMatSolverPackage

Clemens Domanig clemens.domanig at uibk.ac.at
Wed Aug 3 02:51:10 CDT 2011


Hong,

I already asked at the mumps-user-list (by mistake I told them I want to 
do a Cholesky-decomp.)  There they told me:

 >> Sorry this functionality is not available: the diagonal of the 
decomposition is hidden in internal, distributed, datastructures. 
Furthermore, the diagonal elemens depend on scalings, permutations and 
preprocessing options. Also MUMPS uses LDLt rather than Cholesky, and in 
some cases even LU on part of the matrix, even on symmetric matrices, 
when the last Schur complement is processed using scalapack. <<

But for me petsc's LDLt seem to be fine - I will see what will happen 
when I try the large-size problems.
Thx

Hong Zhang wrote:
> Clemens,
> Petsc's LDLt decomposition is likely different from mumps' LDLt.
> Are you sure you want Petsc's D, but use mumps LDLt?
> 
> I suggest sending a request to mumps developer on how to accessing mumps' D.
> 
> Hong
> 
> On Tue, Aug 2, 2011 at 8:12 AM, Matthew Knepley <knepley at gmail.com> wrote:
>> On Tue, Aug 2, 2011 at 12:53 PM, Clemens Domanig
>> <clemens.domanig at uibk.ac.at> wrote:
>>> Maybe I should describe the hole problem.
>>> I'm using MUMPS to make LDLt decomposition - all from command line.
>>> But sometimes I need the diagonal entries (respectively the number of
>>> negative entries) of the D matrix. But there is no way to get this
>>> information back from MUMPS via petsc ( as far as I found out).
>> Yes, we have no access to MUMPS internal data.
>>
>>> There was the suggestion to use MatGetIntertia but this is only for
>>> off-diagonal-information.
>> I am not sure what you mean by that.
>>
>>> So I used
>>> PCSetType( prec, PCCHOLESKY);
>>> PCFactorGetMatrix( prec, &M);
>>> MatGetDiagonal( M, z);
>>> It only works without MUMPS and gives me the diagonal entries I want in
>>> Matrix M - although the entries are 1/x.
>>> Vector z is full of zeros - only the last entry is the 'same' as in M (x
>>> instead of 1/x).
>>>
>>> So the idea was to somehow turn off MUMPS if I need the diagonal entries
>>> and then turn it on again.
>> Here is the easiest way to do it. Keep two complete solvers
>>   a) KSP with MUMPS
>>   b) KSP with Cholesky, give this one KSPSetOptionsPrefix(ksp, "diag_");
>> That way -diag_pc_type cholesky will work. Then use the solver you want.
>>
>>> The problem with PCFactorGetMatSolverPackage is I didn't manage to use it.
>>>
>>> const MatSolverPackage pack;
>>> PCFactorGetMatSolverPackage( prec, &pack);
>>> PetscSynchronizedPrintf( PETSC_COMM_WORLD, "%s\n", pack);
>>> I expected 'mumps' as output but got 'H??????tdH3%0'
>> It would seem its not yet setup.
>>    Matt
>>
>>> Thx
>>>
>>>
>>>
>>> Matthew Knepley wrote:
>>>> On Tue, Aug 2, 2011 at 9:28 AM, Clemens Domanig
>>>> <clemens.domanig at uibk.ac.at <mailto:clemens.domanig at uibk.ac.at>> wrote:
>>>>
>>>>    Hi,
>>>>
>>>>    usually I'm using MUMPS by puting '-pc_factor_mat_solver_package
>>>>    mumps' into the .petscrc.
>>>>    Now I want to change in runtime between MUMPS and non-MUMPS so I
>>>>    tried to turn it on with
>>>>    PCFactorSetMatSolverPackage( pre, MAT_SOLVER_MUMPS);
>>>>    but I doesn't have any effect.
>>>>
>>>>
>>>> This is complicated because you have to set this at the right time during
>>>> the solver setup process.
>>>> Command line arguments are much easier. However, you should call this
>>>> after the preconditioner
>>>> type is set, but before it is setup.
>>>>
>>>>    I also have a problem with PCFactorGetMatSolverPackage(). How can I
>>>>    get back an output as described in the documentation that has the
>>>>    type 'const'?
>>>>
>>>>
>>>> What is the problem? I do not understand?
>>>>
>>>>    Matt
>>>>
>>>>    Thx - Clemens
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> What most experimenters take for granted before they begin their
>>>> experiments is infinitely more interesting than any results to which their
>>>> experiments lead.
>>>> -- Norbert Wiener
>>
>>
>> --
>> What most experimenters take for granted before they begin their experiments
>> is infinitely more interesting than any results to which their experiments
>> lead.
>> -- Norbert Wiener
>>



More information about the petsc-users mailing list