[petsc-dev] attaching field information to PetscLayout?

[Jed Brown]

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

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

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110514/a6b095e0/attachment.html>