[petsc-dev] non-symmetric permutation in PCFieldSplit

[Barry Smith]

On Feb 23, 2012, at 3:08 PM, Jed Brown wrote:

> On Thu, Feb 23, 2012 at 13:05, Jungho Lee <julee at mcs.anl.gov> wrote:
> [C D;A B][x;y] = [v;w] (to be able to explore different
> preconditioning strategies), which currently doesn't seem to be
> supported. At first glance it seems like this can be easily solved by
> adding extra IS (is) and PetscInt* (fields) objects in
> _PC_FieldSplitLink, read in integer arrays for rows and columns (the
> symmetric case where the rows and columns have the same indices is
> already handled by -pc_fieldsplit_%d_fields), fill in the extra IS
> object, and allow the user to use these two different IS's in the
> MatGetSubMatrix calls in PCSetUp_FieldSplit. Is it really as simple as
> that, or am I missing something here?
> 
> I suggest leaving the original field ordering. Add a new function PCFieldSplitSetPermutation(PC,const PetscInt *rowperm,const PetscInt *colperm). Then your desired permutation is
> 
> -pc_fieldsplit_permutation_row 1,0
> -pc_fieldsplit_permutation_col 0,1

   I don't understand this. Will this only affect the -pc_fieldsplit_%d_fields and PCFieldSplitSetFields() commands and not PCFieldSplitIS()? What happens if one wants non symmetric access when using IS to provide the parts, won't you still need to provide 2 one for rows and one for columns?

    Barry


> 
> When we refactor this, we have to get rid of the goofy restriction that Schur only works directly on 2x2 block systems, and we should really get rid of the distinction between Schur and relaxation. I think we should be able to select on a block-entry basis whether to use the entry that appears in a relaxation-based method (just that entry of the original matrix) or whether to use the block that appears in a factorization method (most blocks involve a solve or a Schur complement).