> On Nov 8, 2017, at 10:32 AM, Matthew Knepley <[email protected]> wrote: > > On Wed, Nov 8, 2017 at 11:21 AM, Munson, Todd <[email protected]> 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.
