Thank you Jed. After reading ex15, I got some idea of how to define the PCShell with KSP solver. However, I want to verify with you if the following procedure is normally what one should do. 1. Define a ShellPC struct, which includes a MAT object, say Pmat, and a KSP object, say innerKsp. 2. PCSetType(pc, PCSHELL) 3. Create a context for the user defined PC. It is here that we call KSPSetOperators(innerKsp, Pmat, Pmat) 4. Set the user defined routine for applying the preconditioner. It is in this user-define routine that we call KSPSolver(innerKsp, r, y)
I'm wondering the way I set up the inner KSP for the PC is standard? Thank you! ________________________________________ From: Jed Brown [[email protected]] Sent: Wednesday, July 16, 2014 10:16 PM To: Sun, Hui; Dave May Cc: [email protected] Subject: Re: [petsc-users] why a certain option cannot be used "Sun, Hui" <[email protected]> writes: > Dave, and other PETSc users, sorry for bothering you all again. However > continuing this topic, I have another question. Within this ex70.c, there is > a user defined schur complement StokesSetupApproxSchur, defined as > > > /* Schur complement approximation: myS = A11 - A10 diag(A00)^(-1) A01 */ > > The preconditioner here can be written out explicitly as a matrix, and > is not changed between iterations. Each time it is applied to the > residue is simply matrix times vector. However, if I want to define a > preconditioner which is allowed to vary between iterations, for > example, if I need to solve a linear system each time I apply the > preconditioner to the residue, then is there a way I can do this? Any > hint will be greatly appreciated. Thank you very much! You either write your own PCShell or compose a PC from existing components (perhaps via options). In any case, the application of this PC will involve calls to KSPSolve. You can configure those to be iterative if that makes sense for your use case. Note that if you run an inexact inner solve, the outer solves should use a flexible method (e.g., FGMRES or GCR).
