[petsc-dev] ISGetIndices

[Matthew Knepley]

On Wed, Nov 8, 2017 at 2:09 PM, Munson, Todd <tmunson at mcs.anl.gov> wrote:

>
> > 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.
>

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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20171108/05c1e747/attachment.html>