Hi, I'm interested in these types of Shur complement preconditioners as well. I had stopped working with petsc-dev some time back because I wasn't using new functionality. Would this be a good time to start working with petsc-dev in order to start testing these? I'm primarily interested in stokes and navier-stokes type systems but also have some other coupled systems that an "operator-split" preconditioner should work well on.
With regard to testing, I am also looking for a solid parallel direct solver to verify everything from the nonlinear solver up. I have been using superlu in serial and superlu_dist in parallel (through PETSc) but have noticed some reduction in accuracy as I go to more processors with superlu_dist. This may just be a bug in our code, but I thought if I get petsc-dev the new approach to external direct solvers that Barry mentioned earlier might make it easier to look at some other direct solvers. Several years ago I got better results with spooles, but I'd be interested in any current recommendations. Thanks, Chris On 9/5/08 3:56 AM, "Jed Brown" <jed at 59A2.org> wrote: > I'm happy to see this preconditioner going in. > > (I -B inv(A)) ( inv(A) 0 ) (I 0 ) > (0 I ) ( 0 inv(S) ) (-C inv(A) I ) > > S = D - C inv(A) B > > There are some modifications that greatly improves the performance in my > experience. > > First, the `inv(A)' appearing in S need not be the same as the `inv(A)' > appearing explicitly in the preconditioner. I notice that these are > required to be the same in the current implementation. For instance, 1 > V-cycle of AMG works great inside of S, but I find it is frequently > better to make the outer `inv(A)' somewhat stronger (this is relatively > cheap if S is not very well conditioned). > > Also, I have experimented with mixing the full order (matrix-free using > MatShell) operator with low-order preconditioning blocks. That is, if > the global problem is > > J = (A B) > (C D) > > P = (Ap Bp) > (Cp Dp) > > defining the Schur complement as > > S = D - C inv(A) B > > instead of the current > > S' = Dp - C inv(Ap) B > > where inv(A) is solved using Ap for preconditioning [1]. Note that in > practice, I usually use -schur_A_ksp_type preonly, but this allows the > more restrictive formulation to fall out as a special case. > > It is probably important to make it possible to define S in terms of > either D or Dp. In my case, I have D available with a fast matrix-free > application, but with MatMFFD it is much more expensive, hence Dp may be > preferable. > > [1] Bp,Cp,Dp are not used in this case, though perhaps you would use Dp > to precondition S (in this case Dp is not an approximation of D which is > often singular). It's kind of an awkward hack, but an alternative is for > assembly code to > > PetscObjectCompose((PetscObject)Dp,"schur_pc",(PetscObject)Sp) > > where Sp is the mass matrix or whatever. This way other > preconditioners would ignore it, but PC_COMPOSITE_SCHUR would use this > matrix if it was available. > > Just my thoughts, thanks for working on this. > > Jed
