Gets the matrix associated with the linear system and possibly a different one associated with the preconditioner.
Not collective, though parallel mats are returned if pc is parallel
pc - the preconditioner context
Amat - the matrix defining the linear system
Pmat - the matrix from which the preconditioner is constructed, usually the same as Amat.
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
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
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,&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
KSP the hierarchy
of underlying objects (i.e.
Mat) and their livespans can be completely
managed by the top most level object (i.e. the
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
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
it can be created for you?