<div class="gmail_quote">On Sat, May 14, 2011 at 22:06, 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">> 1. In general, I don't want an interface that addresses "blocks" by number because it is fragile when more fields are added. I would expect PCFieldsplit to get the whole table of (name,IS) pairs, then work exclusively with IS (using the names to set prefixes as it currently does).<br>

<br>
</div>   Maybe ok to avoid the number if we can make sure that no string searches or searches on IS are ever needed during numerical intense part of the computation.<br></blockquote><div><br></div><div>I think the IS _is_ the thing you need. The string is one way to look up the IS, but if you already have the IS then I wouldn't think you would need anything else. Am I missing some use case?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
><br>
> 2. Note that VecGetSubVector() already exists and addresses subvectors by IS. Addressing by name (e.g. VecGetSubVectorByName()) could be a handy convenience. (The naive implementation would search the table and find the correct IS, then call the current VecGetSubVector()).<br>

<br>
</div>   VecGetSubVector() sucks because it actually returns a vector instead of allowing reuse of one that already exists. </blockquote><div><br></div><div>VecGetSubVector() is guaranteed non-copy for VecNest and also if the IS describing the subvector is a contiguous subset. When a specialized implementation (e.g. VecGetSubVector_Nest()) is not available, it does currently create a new Vec, but it is still non-copy. There is a comment saying that this should be cached so the reduction (in creating a new Vec) is not needed on future calls for the same subvector. This is related to MatGetSubMatrix() and MatGetLocalSubMatrix() which I would also like to have cache the submatrix. But I think that is not a project to finish for 3.2.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
><br>
> 3. There is still a problem of how to manage composite fields. In some parts of the code, I might want "velocity" to have all 3 compenents held together. In other parts (or with other runtime options), I might want to work with each component separately. I don't know a really elegant way to expose this (PetscLayoutDefineCompositeField()?), but I think that having a way to define composite fields is important.<br>

<br>
</div>   Nesting of IS? That is an IS that can consist of two or more IS? Something like ISGetSubISes() so the vectors and matrices obtained by pulling a subfield (defined by the IS) out of a vector or matrix get assigned the subISes in their PetscLayout.</blockquote>
</div><br><div>That sounds reasonable.</div>