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