<div class="gmail_quote">On Sat, Feb 25, 2012 at 12:36, 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 id=":1po">  Jed,  It also makes it impossible to handle bizare things where for one spitting you want a subset of one thing actually in another thing. So why not use IS to define the names, this gives complete flexibility. Also this above is not adding fields: you are just giving names to subsets of fields indicated by the original numbering of fields.  Which is fine, but has confusing names (you are not AddField just naming it).</div>
</blockquote><div><br></div><div>I'm defining collections of fields, then adding/naming field in those collections. You want these collections defined for visualization anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1po"> My suggestion is just a more or less a concise way of doing what you are doing without the need for YET ANOTHER CLASS (fcons).<br></div></blockquote><div><br></div><div>That is just a token, it could be an int. There is a very real concept of multiple (possibly nonlinear) bases for model state. How do you want to refer to these collections? Just strings?</div>
<div><br></div><div>Instead of making these collections, we could just define an arbitrarily large (thus redundant) list of "observables" (quantities that can be computed from model state). Primitive variables are one such collection of observables. Then when asking for splits, the caller could provide the subset that they wanted. This isn't good for automatically ensuring that the bases span and are non-redundant, but it would be the best interface for visualization. I'm not sure how you would want to define the equation of state (which would normally provide all the primitive variables from the state) or its inverse.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1po">
<div class="im"><br>
><br>
> Then PCFieldSplit and eventual nonlinear and time-stepping splitting methods would call<br>
><br>
> DMGetFieldSplitting(dm,&nsplits,&splits);<br>
> // choose split number to use<br>
> split = splits[splitidx];<br>
> DMFieldSplittingGetName(dm,split,&splitname);<br>
> DMFieldSplittingGetFields(dm,split,&pf,&pfinv,&nfields,&isfields,&dmfields);<br>
<br>
</div>I do not like this approach based on requesting by name, just push your name and then pop it. This way something "above" in the call stack can push to the right one then something further down can use it without having to know its name (sort of like your "default" split) but the push allows changing the default. You kind of assume that the guts is suppose to know what name to use?  // choose split number to use how is some PC deep inside suppose to know this?<br>

<br>
  I realize my proposal was not complete on detail.  I'm suggesting changes to your detail.<br></div></blockquote></div><br><div>Push/pop is fine with me. But note that the GUI should be able to get a list of options at any level in which a decision makes sense. It's possible that we would want to split in terms of different variables in that PCComposite+2*PCFieldSplit example.</div>