On Aug 27, 2008, at 1:34 PM, Dmitry Karpeev wrote:
I would say that IS appears to be a *non-scalable* parallel object, since the only parallel call available for it seems to be ISAllGather (and variants).
Yes this is non-scalable. Vecs have some nonscalable stuff in them also.
It also seems to me that the real use for an IS is as input to the ISLocalToGlobalMapping routines and it is the mapping object that is truly global.
Actually they were created for VecScatterCreate() and MatGetSubMatrices(), in both these cases it is natural to think of the IS as a parallel object (though I agree you can also think of it as not a parallel object). For ISLocalToGlobalMapping() create, I agree there is nothing that would make one demand that the IS is parallel.
As a test for IS being global, can one imagine a circumstance when the same IS can be used with two different mappings which carry different comms?
I don't understand this test. On the processes that are in both comms you could use the same (sequential) IS, for example, to create a VecScatter. Possible but unliikely. Even if an object (class) has NO collective operations, if, when you use that object, you must have partners are all other processes in a MPI_Comm then I think it is a good approach to have that be a parallel object that shares the comm. Barry
I also want to point out that, in retrospect, Sieve is an evolution of the IS/ISLocalToGlobalMapping set of ideas.
Dmitry.
On Wed, Aug 27, 2008 at 1:16 PM, Matthew Knepley <[email protected]> wrote: On Wed, Aug 27, 2008 at 1:08 PM, Barry Smith <[email protected]> wrote:
On Aug 27, 2008, at 12:13 PM, Matthew Knepley wrote:
On Wed, Aug 27, 2008 at 12:06 PM, Lisandro Dalcin <[email protected]
wrote:
So, Do all us agree my proposed fix should be pushed? I'll wait
for
Matt comments/complaints...
I complain that IS is a fake parallel object.
In what way is IS a fake parallel object? Maybe we can resolve your concern about it being a fake parallel object.
I said fake because it has a single collective operation (or even one with communication). We even use IS in situations where GetSize() makes no sense, or at least are not careful about the comm used. Also, none of the other functions work over the comm. For instance, the ISIsPermutation() or ISSorted() do not look at the indices collectively.
Matt
Barry
However, if GetSize/GetLocalSize already do this, then yes we should change the ISBlock version as well.
Matt
On Wed, Aug 27, 2008 at 1:13 PM, Barry Smith <[email protected]> wrote:
On Aug 27, 2008, at 10:23 AM, Matthew Knepley wrote:
There is no concept of global for IS. They are purely serial.
AO is the
only global construct with indices.
This is kind of true, and maybe used to be completely true. But IS does have a communicator and that communicator can be MPI_COMM_WORLD or any parallel communicator. In other words the IS is evolving to be an object that can be parallel in the same sense as vecs or mats
There are already ISGetSize() and ISGetLocalSize() so it sure makes sense to have the same paradgm for the ISGetBlockSize().
Barry
Originally IS had no parallel concept, then we added the ISGetSize/LocalSize but forgot to do it for the ISBlock...
Matt
On Wed, Aug 27, 2008 at 10:09 AM, Lisandro Dalcin <[email protected]
wrote:
I believe we have to review the interface of ISBlock.
Currently,
ISBlockGetSize() return the number of LOCAL block indices. This is not consistent with other naming conventions for getting local and glocal sizes. I propose to change this to the following
1) change: ISBlockGetSize() returns the number global blocks 2) addition: ISBlockGetLocalSize() return the number of local blocks
Comments?
-- Lisandro Dalc�n --------------- Centro Internacional de M�todos Computacionales en Ingenier�a (CIMEC) Instituto de Desarrollo Tecnol�gico para la Industria Qu�mica (INTEC) Consejo Nacional de Investigaciones Cient�ficas y T�cnicas (CONICET) PTLC - G�emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594
-- 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
-- Lisandro Dalc�n --------------- Centro Internacional de M�todos Computacionales en Ingenier�a (CIMEC) Instituto de Desarrollo Tecnol�gico para la Industria Qu�mica (INTEC) Consejo Nacional de Investigaciones Cient�ficas y T�cnicas (CONICET) PTLC - G�emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594
-- 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
-- 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
participants (1)
-
Barry Smith