So you are suggesting totally removing PCFieldSplitSetSchurPrecondition() and instead having the user call MatSetApproximateSchurComplement() if they wish to provide a matrix?
Sounds ok to me. Barry On Jun 9, 2011, at 4:21 PM, Jed Brown wrote: > I noticed your developer note. The function name was preserved from what > Barry originally wrote when I added alternatives a couple years ago and it > should certainly be changed to include "Set". But I don't know a good name > that isn't a whole sentence. > > I think the root of the problem is that we don't have a systematic way for > PCFieldSplit to decide where to look to find the preconditioning matrix. It's > pretty dirty (and semantically incorrect) to put it into the diagonal block > of the preconditioning matrix. I really don't like the user providing it > through this function because that matrix is something that can change in a > nonlinear or transient solve, and the user should not have to touch the PC in > that context (because it's very ugly for nested solvers, they should only > mess with the PC during configuration). > > > So what about a different API along the lines of > > MatSetApproximateSchurComplement(Mat A,IS row0,IS col0,IS row1,IS col1,Mat S); > > The user would typically call this function on the preconditioning matrix and > PCFieldSplit would look there first. > > The implementation of this function could (at least for now) > PetscObjectCompose() the matrix S and then MatGetSchurComplement() would > return it for the preconditioning matrix. > > Is this nuts?
