I wanted to revive this (month-old) thread to try to finalize the API change related to "pivoting" in PCFIELDSPLIT.<br><br><div class="gmail_quote">On Thu, Jun 7, 2012 at 6:42 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><div class="gmail_quote">On Thu, Jun 7, 2012 at 6:34 PM, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Well, the above defines the "pivots"</blockquote></div><br></div><div>Okay, but this is not a "field decomposition". We are extracting sub-problems (maybe overlapping?) that have implicit off-diagonal parts that may also need to be evaluated (how?).</div>

</blockquote><div>I think the overlapping issue is largely orthogonal to whether we are extracting "fields" or "subproblems" (i.e., not necessarily diagonal subblocks of (p)mat).  There seems to be a lot of code</div>

<div>in fieldsplit that seems to assume nonoverlapping decompositions (mostly through the use of INSERT_VALUES inside a scatter), so I don't think overlapping subproblems would work</div><div>correctly out of the box anyway.</div>

<div><br></div><div>As far as off-diagonal parts are concerned, in the Schur variant they are computed (when extracting B and C) via complementing the column indices of A and D, which are already </div><div>separate from the row indices, although there is currently no API to set them separately.  In the non-Schur variants the off-diagonal parts aren't computed explicitly: the residual is updated</div>

<div>using all columns (the row submatrix) corresponding to a field/subproblem, so, again, there is no problem.  We only need to change the PCFieldSplitSetIS() calling sequence to include</div><div>the column IS explicitly.  As Barry suggests above, the "usual" usage is recovered by passing the same IS twice. </div>

<div><br></div><div>Finally, on the DM side we now have different "input" and "output" spaces (even if the subproblem is square, the vector layout may be different).  Should DM have DMCreateGlobalVectors()</div>

<div>in addition to DMCreateGlobalVector()?  These would be the same as those obtained with MatGetVecs() from a Mat created with DMCreateMatrix().</div><div><br></div><div>Any comments?</div><div><br></div><div>Dmitry.</div>

<div><br></div></div><br>