On Wed, Nov 8, 2017 at 2:09 PM, Munson, Todd <[email protected]> wrote:
> > > 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. > Its one of those things that is true, but has little upside. > 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". > They are mostly copies, so changing them would have no effect. > Is there any requirement that the indices be in increasing order? (Other > than perhaps poor performance.) > No, but I think that it is assumed for some operations. > 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? > We could consider this, but really IS is intended to be a static object, not a dynamic one. I think Jed's SegBuffer is supposed to be dynamic, and could underlie a dynamic index object. > 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. > Most of the objects in PETSc are fixed size, and when the size changes you recreate it. > 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 agree with that. > 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. IS objects can be views into other memory, so the object could be created but the backing memory could be maintained somewhere else so that there is not a big malloc every time. Matt > > Todd. > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
