On Wed, May 12, 2010 at 3:11 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, 12 May 2010 14:13:37 -0400, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> Yes, definitely. I have been too lazy to add names, but this is exactly<br>
> what is needed.<br>
<br>
</div>Okay, so what about naming splits on the command line?  We usually try<br>
to make the command line mimic the API.  Accepting a dict might be neat:<br>
<br>
  -pc_fieldsplit_splits "{'velocity': [0,1,2], 'pressure': [3]}" -fieldsplit_velocity_pc_type ml<br>
<br>
As a possible extension for the options database to more easily support<br>
very complex simulations with many nested objects, and long redundant<br>
prefixes, I've been thinking about YAML support.  YAML files can have<br>
references so you can define a collection of solver profiles, then use<br>
them in multiple places in the same simulation (for instance if you have<br>
two similar systems for which you would want to use the same or similar<br>
solver parameters).  Would anyone else like this feature?  Note that a<br>
YAML parser would also trivially be able to handle the dict string<br>
suggested as a command-line option above.<br></blockquote><div><br></div><div>I guess I have no problem with this if:</div><div><br></div><div>  a) Its completely backwards compatible with the options-style</div><div><br>
</div><div>  b) the YAML part is not going to break the build</div><div><br></div><div>This will likely mean revamping the Options*() API.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Backing up slightly, this thread<br>
<br>
  <a href="http://lists.mcs.anl.gov/pipermail/petsc-dev/2010-March/002439.html" target="_blank">http://lists.mcs.anl.gov/pipermail/petsc-dev/2010-March/002439.html</a><br>
<br>
proposed having the names for field associations on the DM (so that<br>
visualization and other diagnostics could also use names).  In that<br>
case, the DM would have (or be able to provide) the index sets, and<br>
PCFieldSplit would only need to know the names of the groups.  On the<br>
other hand, there are certainly users that don't use DM at all, but<br>
still want to use PCFieldSplit.  One approach would be to have a<br>
super-lightweight DM that just kept a collection of index sets with<br>
names and groupings (assuming no further structure).  The other is to<br>
have PCFieldSplit retain a low-level interface to set the splits.</blockquote><div><br></div><div>I favor the low-level interface to FieldSplit taking a name and IS.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
Jed</font></blockquote></div>-- <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>