[petsc-dev] attaching field information to PetscLayout?

[Barry Smith]

On May 14, 2011, at 12:41 PM, Jed Brown wrote:

> On Sat, May 14, 2011 at 18:51, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
>    I have a proposal for a moderate/major change for how we handle knowledge of subfields/splits in PETSc.
> 
>    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.
> 
> Yes, this is a problem and I generally like the idea.
>  
>   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.
> 
> 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).

   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.

> 
> 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()).

   VecGetSubVector() sucks because it actually returns a vector instead of allowing reuse of one that already exists. This stuff needs rethinking.

> 
> 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.

   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.


   Barry


> 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.
> 
> 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.