<div class="gmail_quote">On Sat, May 14, 2011 at 18:51, 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;">
<br>
    I have a proposal for a moderate/major change for how we handle knowledge of subfields/splits in PETSc.<br>
<br>
    Currently one can call PCFieldSplitSetIS() or PCFieldSplitSetFields() to indicate the splitting of vectors(fields) into subvectors(subfields).  But, in fact, the knowledge of what splits make sense really comes in the generation of the vectors and matrices and it is bad that the user needs to stash that information somewhere and then bring it out and attach it to the PCFieldSplit. It is especially annoying if one is using a fieldsplit inside, say a multigrid preconditioner, and one has to somehow get that information down into the inner PC.<br>
</blockquote><div><br></div><div>Yes, this is a problem and I generally like the idea.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
   I propose an alternative. All Vecs and Mats currently have associated PetscLayouts and when a Vec or Mat is duplicated the new Vec or Mat has that same PetscLayout. I propose each PetscLayout have associated with it an optional set of IS indicating the subfields/subvectors (note that this is sort of already true when you set a blocksize larger than 1 the PCFieldSplit will by default use the strides for subfields). Thus PCFieldSplit can get directly from its matrix the appropriate default splits.   Similarly the VecStrideXXX() operations can be made more general becoming VecSubVecXXX(). We also add VecGetSubVec() to get appropriated sized subvectors easily.<br>
</blockquote><div><br></div><div><div>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).</div>
<div><br></div><div>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()).</div>
<div><br></div><div>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. I envision PCFieldSplit defaulting to using the largest granularity available and forwarding the composite hierarchy on to the next level where it might be used to provide null space information, a special-purpose smoother, or different type of split.</div>
<div><br></div><div>4. Re petsc-3.2: if we can agree on an interface addressing point 3 above, it may be worth implementing this with basic functionality (maybe just PCFieldSplit) for 3.2. Possible helper functions or deeper integration could come later, but having this sooner would enable users to write better structured code now.</div>
</div></div>