<div dir="ltr">I would say that IS appears to be a *non-scalable* parallel object, since the only parallel call<br>available for it seems to be ISAllGather (and variants).<br>It also seems to me that the real use for an IS is as input to the ISLocalToGlobalMapping routines and it is <br>
the mapping object that is truly global.  <br><br>As a test for IS being global, can one imagine a circumstance when the same IS <br>can be used with two different mappings which carry different comms?<br><br>I also want to point out that, in retrospect, Sieve is an evolution of the IS/ISLocalToGlobalMapping<br>
set of ideas.<br><br>Dmitry.<br><br><div class="gmail_quote">On Wed, Aug 27, 2008 at 1:16 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Wed, Aug 27, 2008 at 1:08 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> On Aug 27, 2008, at 12:13 PM, Matthew Knepley wrote:<br>
><br>
>> On Wed, Aug 27, 2008 at 12:06 PM, Lisandro Dalcin <<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> So, Do all us agree my proposed fix should be pushed? I'll wait for<br>
>>> Matt comments/complaints...<br>
>><br>
>> I complain that IS is a fake parallel object.<br>
><br>
>  In what way is IS a fake parallel object? Maybe we can resolve<br>
> your concern about it being a fake parallel object.<br>
<br>
</div>I said fake because it has a single collective operation (or even one<br>
with communication).<br>
We even use IS in situations where GetSize() makes no sense, or at least are not<br>
careful about the comm used. Also, none of the other functions work<br>
over the comm.<br>
For instance, the ISIsPermutation() or ISSorted() do not look at the<br>
indices collectively.<br>
<br>
  Matt<br>
<div><div></div><div class="Wj3C7c"><br>
>   Barry<br>
><br>
><br>
>> However, if<br>
>> GetSize/GetLocalSize already<br>
>> do this, then yes we should change the ISBlock version as well.<br>
>><br>
>>  Matt<br>
>><br>
>>> On Wed, Aug 27, 2008 at 1:13 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>>>><br>
>>>> On Aug 27, 2008, at 10:23 AM, Matthew Knepley wrote:<br>
>>>><br>
>>>>> There is no concept of global for IS. They are purely serial. AO is the<br>
>>>>> only<br>
>>>>> global construct with indices.<br>
>>>><br>
>>>>  This is kind of true, and maybe used to be completely true. But IS does<br>
>>>> have a communicator and that communicator can be MPI_COMM_WORLD or<br>
>>>> any parallel communicator.  In other words the IS is evolving to be an<br>
>>>> object<br>
>>>> that can be parallel in the same sense as vecs or mats<br>
>>>><br>
>>>>  There are already ISGetSize() and ISGetLocalSize() so it sure makes<br>
>>>> sense<br>
>>>> to have the same paradgm for the ISGetBlockSize().<br>
>>>><br>
>>>><br>
>>>>  Barry<br>
>>>><br>
>>>> Originally IS had no parallel concept, then we added the<br>
>>>> ISGetSize/LocalSize<br>
>>>> but forgot to do it for the ISBlock...<br>
>>>><br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>> Matt<br>
>>>>><br>
>>>>> On Wed, Aug 27, 2008 at 10:09 AM, Lisandro Dalcin <<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>><br>
>>>>> wrote:<br>
>>>>>><br>
>>>>>> I believe we have to review the interface of ISBlock. Currently,<br>
>>>>>> ISBlockGetSize() return the number of LOCAL block indices. This is not<br>
>>>>>> consistent with other naming conventions for getting local and glocal<br>
>>>>>> sizes. I propose to change this to the following<br>
>>>>>><br>
>>>>>> 1) change: ISBlockGetSize() returns the number global blocks<br>
>>>>>> 2) addition:  ISBlockGetLocalSize() return the number of local blocks<br>
>>>>>><br>
>>>>>> Comments?<br>
>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>> Lisandro Dalcín<br>
>>>>>> ---------------<br>
>>>>>> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)<br>
>>>>>> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)<br>
>>>>>> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)<br>
>>>>>> PTLC - Güemes 3450, (3000) Santa Fe, Argentina<br>
>>>>>> Tel/Fax: +54-(0)342-451.1594<br>
>>>>>><br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> What most experimenters take for granted before they begin their<br>
>>>>> experiments is infinitely more interesting than any results to which<br>
>>>>> their experiments lead.<br>
>>>>> -- Norbert Wiener<br>
>>>>><br>
>>>><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Lisandro Dalcín<br>
>>> ---------------<br>
>>> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)<br>
>>> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)<br>
>>> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)<br>
>>> PTLC - Güemes 3450, (3000) Santa Fe, Argentina<br>
>>> Tel/Fax: +54-(0)342-451.1594<br>
>>><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> What most experimenters take for granted before they begin their<br>
>> experiments is infinitely more interesting than any results to which<br>
>> their experiments lead.<br>
>> -- Norbert Wiener<br>
>><br>
><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class="Wj3C7c">What most experimenters take for granted before they begin their<br>
experiments is infinitely more interesting than any results to which<br>
their experiments lead.<br>
-- Norbert Wiener<br>
<br>
</div></div></blockquote></div><br></div>