[petsc-dev] attaching field information to PetscLayout?

[Jed Brown]

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?


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