Skip to main content
`Ctrl`+`K`

# PCGetOperators

Gets the matrix associated with the linear system and possibly a different one which is used to construct the preconditioner.

## Synopsis

    #include "petscksp.h"
    PetscErrorCode PCGetOperators(PC pc, Mat *Amat, Mat *Pmat)

Not Collective, though parallel `Mat`s are returned if `pc` is parallel

## Input Parameter

- pc - the `PC` preconditioner context

## Output Parameters

- Amat - the matrix defining the linear system

- Pmat - the matrix from which the preconditioner is constructed, usually the same as Amat.

## Note

Does not increase the reference count of the matrices, so you should not destroy them

Alternative usage: If the operators have NOT been set with `KSPSetOperators()`/`PCSetOperators()` then the operators are created in `PC` and returned to the user. In this case, if both operators mat and pmat are requested, two DIFFERENT operators will be returned. If only one is requested both operators in the PC will be the same (i.e. as if one had called `KSPSetOperators()`/`PCSetOperators()` with the same argument for both Mats). The user must set the sizes of the returned matrices and their type etc just as if the user created them with `MatCreate()`. For example,

             KSP/PCGetOperators(ksp/pc,&Amat,NULL); is equivalent to
               set size, type, etc of Amat

             MatCreate(comm,&mat);
             KSP/PCSetOperators(ksp/pc,Amat,Amat);
             PetscObjectDereference((PetscObject)mat);
               set size, type, etc of Amat

and

             KSP/PCGetOperators(ksp/pc,&Amat,&Pmat); is equivalent to
               set size, type, etc of Amat and Pmat

             MatCreate(comm,&Amat);
             MatCreate(comm,&Pmat);
             KSP/PCSetOperators(ksp/pc,Amat,Pmat);
             PetscObjectDereference((PetscObject)Amat);
             PetscObjectDereference((PetscObject)Pmat);
               set size, type, etc of Amat and Pmat

The rationale for this support is so that when creating a `TS`, `SNES`, or `KSP` the hierarchy of underlying objects (i.e. `SNES`, `KSP`, `PC`, `Mat`) and their lifespans can be completely managed by the top most level object (i.e. the `TS`, `SNES`, or `KSP`). Another way to look at this is when you create a `SNES` you do not NEED to create a `KSP` and attach it to the `SNES` object (the `SNES` object manages it for you). Similarly when you create a KSP you do not need to attach a `PC` to it (the `KSP` object manages the `PC` object for you). Thus, why should YOU have to create the `Mat` and attach it to the `SNES`/`KSP`/`PC`, when it can be created for you?

## See Also

KSP: Linear System Solvers, `PC`, `PCSetOperators()`, `KSPGetOperators()`, `KSPSetOperators()`, `PCGetOperatorsSet()`

## Level

intermediate

## Location

src/ksp/pc/interface/precon.c

## Examples

src/ksp/ksp/tutorials/ex15f.F90

Index of all PC routines
Table of Contents for all manual pages
Index of all manual pages