[petsc-dev] PCFieldSplitSetFields() API change

[Barry Smith]

On Mar 23, 2012, at 4:56 PM, Jed Brown wrote:

> This changed the API for PCFieldSplitSetFields(), but didn't update the man page, src/docs/website/documentation/changes/dev.html, or the examples that called the function (one of the two examples was updated later).
> 
> http://petsc.cs.iit.edu/petsc/petsc-dev/rev/55721edbdaa2
> 
> But is this even the right thing to do? I always thought that when we talked about non-symmetric pivoting, we were identifying fields in the unpivoted system and that we would implement pivoting internally (restoring the original ordering at the end of preconditioner application).

   That was your proposal :-)


> Is there an example that uses this flexibility so I can understand what's happening?
> 
> I'm very nervous to make the definition of a field a thing that involves both input and output spaces.

   But you are implicitly assuming that for example the first component of input space is "somehow" tied to the first component of the output space etc. I submit this is only true if the user has chosen first component of the input space and output space "correctly" and the user may not have done this. Giving this additional freedom to the PCFieldSplit allows the person defining the components (first etc in the input and output spaces) to not be concerned with how those definitions affect the solver, since the PCFiledSplit stage can correct for dumb choices. 

   In all cases the "original ordering" will appear outside of the PCFieldsplit in the same way that your "pivoting internal"  proposal does.  I happen to think allowing setting both input and output fields is much more natural then having the user indicate some kind of pivoting that you proposed.

   Barry