I agree with Barry.<div><br></div><div>By "making command line splits permanent" you mean they are not overridden by API splits?</div><div><br></div><div>  Matt<br><br><div class="gmail_quote">On Sat, May 15, 2010 at 5:20 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@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"><br>
On May 15, 2010, at 5:09 PM, Jed Brown wrote:<br>
<br>
> Is there a case for putting a field in more than one split?<br>
<br>
</div>    I believe absolutely. It is like overlapping Schwarz but not with overlapping grid points instead overlapping components.<br>
<font color="#888888"><br>
    Barry<br>
</font><div><div></div><div class="h5"><br>
> The current<br>
> implementation allows this, but it makes it easier to accidentally have<br>
> more splits than you wanted.  The underlying challenge for Doing the<br>
> Right Thing is that the type is not normally set until<br>
> PCSetFromOptions().  Any calls to PCFieldSplitSet* will be ignored prior<br>
> to this.  The problem occurs when the user specifies<br>
> -pc_fieldsplit_*_fields AND the code adds splits with<br>
> PCFieldSplitSet(IS|Fields).  This used to create a bunch of splits which<br>
> is probably not what anyone asked for, I just pushed a some code that<br>
> makes command-line split definitions permanent.  This isn't entirely<br>
> satisfactory because there isn't currently a way to get rid of them, but<br>
> it's better than having lots of spurious splits.<br>
><br>
> Lisandro, let me know if the current code behaves the way you expect.<br>
><br>
> Jed<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>
</div>