Interfaces for Schur complements and FieldSplit

Barry Smith bsmith at mcs.anl.gov
Wed May 20 17:47:48 CDT 2009


On May 20, 2009, at 3:47 PM, Jed Brown wrote:

> Do you have a preferred interface for specifying a preconditioning
> matrix for A in Mat_SchurComplement

    I would add a new second argument to MatCreateSchurComplement() Ap
that would be the pmat passed into the KSPSetOperators(). To get the  
current
behavior one would use MatCreateSchurComplement(A,A,....)

> and for the Schur complement in
> PC_FieldSplit?

PCFieldSplitSchurPrecondition() could be modified to take an  
additional argument that is
used as the preconditioner matrix.

>  This is of course possible by retrieving the appropriate
> KSP and setting the operators by hand, but since this is (I think!)  
> the
> usual case, there should be an interface.  To be clear, in my own
> half-assed implementation of this stuff, I never call KSPSetOperators
> with the same operator as preconditioning matrix, so transitioning to
> PC_FieldSplit is looking awkward.
>
> Preconditioning the Schur complement with pmat[1] is not really what  
> we
> want.  In most cases I can think of, the user will have to provide the
> preconditioning matrix, and frequently a PC_Shell.
>

> It looks like I must implement MatGetSubMatrix for my matrix-free
> operators.  This is of course only possible for very special IS.  Is
> there any chance of a higher-level description of the submatrix?  (I'm
> not sure ther is a better way, but as is, both PC_FieldSplit and my
> Mat_Shell already need to have duplicate representations of the
> submatrices but we'll be talking by complementing each IS.)
>
   Not likely. The interface is to provide an IS. It will always be an  
IS, but of course
IS is an abstract base class and perhaps additional ISs could be  
introduced that
are "higher level" but in the end they still have to be an abstract  
representation of
a bunch of integers :-(

>
> Do you have an interface in mind for specifying reduced forms for  
> block
> preconditioners?  For example, Galerkin discretization of  
> incompressible
> flow gives
>
> J = [A  B']
>    [B  0 ]
>
> The reduced forms
>
> [A    ]   or    [A  B']
> [B   S]         [   S ]
>
> are appropriate for left- and right-preconditioned GMRES respectively
> (the preconditioned operator has minimal degree 2 and all unit
> eigenvalues).  Also,
>
> [A    ]
> [    S]
>
> is popular for symmetric problems.
>
>
    Not sure what you mean "specifying". See the manual page for  
Block_Preconditioners
(bottom of fieldsplit.c) where it gives the cases. Sadly it does not  
tell you directly how to run each different
case (It should) but I think you just need to use the proper - 
pc_fieldsplit_type additive,multiplicitive,symmetric_multiplicative
>
> Will I at some point be able to specify a combination of split and  
> Schur
> complement?  For instance, suppose I had a Jacobian like
>
> [A  B'         ]
> [B     C       ]
> [D  E  F  G    ]
> [   H     I    ]
> [K        L  M ]
>
> and wanted to do a multiplicative split except that the indefinite  
> block
> needs the Schur complement version.  Everything in sight would be
> matrix-free, but I would also be providing assembled preconditioning
> matrices for A,F,I,M, and a shell preconditioner for S = -BA^{-1}B^t
> (which involves an auxiliary discretization).  (Sure, I'm most  
> likely to
> be using ksp_type preonly for all the diagonal blocks, but I think  
> it's
> better to get both matrices to the relevant KSP.)

It is intended that you can do that (though as you note the arguments  
to pass in the extra pmat's you want to use, as discussed at the top,  
do not yet exist but are easily added).
Please find out the limitations that stop your from doing this.

None of this is set in stone and lots of people have not used this in  
the comprehensive way you plan to, so we can make changes/additions as  
you need.

   Thanks for your input.

     Barry

>
>
>
>
> This isn't urgent, but I'd like to start a discussion about how to
> handle cases like this.
>
> Jed
>




More information about the petsc-dev mailing list