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>
