On Feb 13, 2013, at 7:41 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Wed, Feb 13, 2013 at 7:31 AM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > 1) ISGetIndices(is,int group_number, &indices) gives the indices for a > > group or > > > > So by convention, group 0 is "offset" and group 1 is "size"? > > No, group_number is the number of the clump. and indices are all the > values in that clump > > Then you need to also access the size of the clump, but since the primary > purpose is for indexing into another array, you have to copy out a buffer > (thus requiring a matching Restore). When using (int) -> (offset, size), we > get direct access. It makes this inner loop code a lot simpler and faster. > Consider DMPlexPointLocalRef(), which is effectively You misunderstand me. I am not advocating replacing the more efficient access code using offset plus length to ALWAYS calling ISGetIndices() and using the indices to do the access. I absolutely am not advocating that. Recall we sometimes have subclasses that do not implement (or get used) all the methods of the base class. What I am advocating is recognizing that PetscSection and IS have (in the abstract) very similar jobs and thus organizing the source code (naming, possible methods etc) to reflect this. Rather than having seemingly two completely unrelated classes. For example, and I'm not advocating this naming, we could have a base abstract class of PetscIndex with PetscIndexIS and PetscIndexSection, now people always see the connection. The weakness of this exact approach is though both things are related to indexing, it is not clear they have any common methods (as you both have pointed out) so "deriving" them both from PetscIndex might not be best. Barry > > ierr = > PetscSectionGetOffset(dm->defaultGlobalSection,point,&offset);CHKERRQ(ierr); > *(PetscScalar**)ptr = (start >= 0) ? array + start - dm->map->rstart : NULL; > > This gives read+write access to that piece of the array. If > PetscSectionGetOffset instead returned discontiguous indices, we'd need a > work buffer and copy-back semantics, or we'd need to push that unstructured > indexing burden onto the user.
