[petsc-dev] ISRestoreNonlocalIS?

Jed Brown jed at 59A2.org
Thu Nov 18 15:53:12 CST 2010

On Thu, Nov 18, 2010 at 22:33, Barry Smith <bsmith at mcs.anl.gov> wrote:

> We could bag the in-place  ISSort() and make it return a new IS.

Sounds good to me.

> Could we at least get rid of ISGetTotalIndices() and
> ISGetNonlocalIndices() in favor of ISGetNonlocalIS() followed by
> ISGetIndices(), so that the interface allows working with ISStride and
> ISBlock efficiently?
>   The problem is what is the "meaning" of that new IS? What communicator
> does it live on? It is returning information about a given IS, it really
> isn't an IS at all given my definition of IS from the previous email.  If
> you could come up with proper model for this beast (and have it cached in
> the original IS) then I would be happy if it was an IS and we didn't need
> the GetNonlocalIndices() and GetAllIndices().  With ISAllGather() it returns
> a sequential IS that is then passed in from MatGetSubMatrix_MPIAIJ() to
> MatGetSubMatrix_MPIAIJ_Private() to MatGetSubMatrices() but now you are
> passing a sequential IS to MatGetSubMatrices() while the isrow may be (or
> is) a parallel IS.  Explain this to me and we'll have a good model.

I've chatted with Dmitry about this and I think that MatGetSubMatrices
should produce matrices on the communicator pair (isrow,iscol).  Currently
it only produces serial matrices, in which case both isrow and iscol should
be serial.  But to extract on subcomms, the user would pass in (isrow,iscol)
living on subcomms.  This would actually make MatGetSubMatrix a redundant
API because the user could pass a single global (isrow,iscol) to
MatGetSubMatrices().  Along these lines, it is easy to implement the
trivially cheap ISGetLocalIS() so that, e.g. MatGetSubMatrix_MPIAIJ_Private
doesn't need to do anything weird.

An IS packs a lot of semantic information by having a communicator, some of
the current interfaces ignore this for historical reasons.

>   In the past we did not always wrap "collections of indices" as an IS, I
> think it still exists from that time. If it is never used and will not be
> needed it could be removed.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20101118/6830ba76/attachment.html>

More information about the petsc-dev mailing list