Patrick Sanan <[email protected]> writes:

PCMAT seems abstraction-breaking (and the man page even admits it is "strange" :D )

The preconditioner Mat B is thought of as an approximation (maybe a perfect one) to the operator A,

Pmat (B) is just data used to construct the preconditioner.

to be used to construct preconditioners. PCMAT uses B as an approximation to the *inverse* of A (loosely speaking). That's confusing, and worse it ruins a central feature of PETSc, which is the ability to change the preconditioner at runtime; the meaning of B changes depending on which PC implementation you use.

I agree that it cripples the ability to swap PC.

Proposed change: Have PCMAT (like analogous object PCKSP) store its own Mat object and introduce API functions to interact with this internal Mat. To make sure that any user code which happens to use PCMAT doesn't see an unexplained change in behavior, do not set a default internal Mat, and produce an informative error if PCApply_Mat() is called without first calling the new function PCMatSetMat().

Interacting directy with the PC sucks for nested systems. You could have MatSetPC(mat,minv) and have PCMAT (or whatever) pull it out.