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.
signature.asc
Description: PGP signature
