[petsc-dev] attaching field information to PetscLayout?

[Barry Smith]

On May 14, 2011, at 3:16 PM, Jed Brown wrote:

> On Sat, May 14, 2011 at 22:06, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > 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.
> 
> 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?

   The user will be composing preconditioners on splits etc using the string name (you cannot type an IS at the command line but you can type "pressure") so I am not sure why you are so focused on "the IS _is_ the thing you need". So I can see the string names as being important.


>  
> 
> >
> > 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. 
> 
> 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.
>  
> 
> >
> > 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.
> 
> That sounds reasonable.

  If we can do it in grungy C :-)