On Feb 23, 2012, at 3:08 PM, Jed Brown wrote:
On Thu, Feb 23, 2012 at 13:05, Jungho Lee <[email protected]> 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).