FieldSplit Schur preconditioner

[Kees, Christopher E]

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