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).
