[petsc-dev] ISGetIndices

[Munson, Todd]

> On Nov 8, 2017, at 10:32 AM, Matthew Knepley <knepley at gmail.com> wrote:
> 
> On Wed, Nov 8, 2017 at 11:21 AM, Munson, Todd <tmunson at mcs.anl.gov> wrote:
> 
> I had a question.  There is VecGetArrayRead and VecRestoreArrayRead.  However, the
> sameconcept does not appear with IS.  Is there a reason for not having
> ISGetIndicesRead and ISRestoreIndicesRead?
> 
> Actually, ISGetIndices() is always read-only. Maybe we should change the name?

If you want to be consistent, I would change the name.  However, it looks
like propagating the change would be a headache.

Just to push on some buttons, is there any reason why the user cannot change
the contents of the array?  The documentation just says "should not".

Is there any requirement that the indices be in increasing order?  (Other
than perhaps poor performance.)

I am also wondering if the IS objects should keep track of the space allocated
in addition to the actual amount used.  This would let me create an IS of the
maximum size and update it.  Currently, when using, for example, VecWhichInactive, 
a new IS is always created inside the code.  Inside of TRON, I then need to destroy 
the old IS and create a new one every iteration, rather than reusing the space.  
Is eliminating a free and malloc per iteration worth making changes?

Note: MatMult does not create a new vector for the result when called, so it 
seems a bit inconsistent for VecWhichInactive, etc. to create a new IS for 
the result.

If we keep the code as currently written, should we somehow change the 
name of the methods and the documentation to reflect that the IS
result is created by the method (so a pointer to a NULL object 
should be passed in and the caller is responsible for 
freeing it).


Yes, I should have looked at this a long time ago.  Now index
sets are used all over the place and I do not quite 
understand the design considerations.

Todd.