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 <knepley at gmail.com>
> wrote:
> On Wed, Aug 27, 2008 at 1:08 PM, Barry Smith <bsmith at mcs.anl.gov>
> wrote:
> >
> > On Aug 27, 2008, at 12:13 PM, Matthew Knepley wrote:
> >
> >> On Wed, Aug 27, 2008 at 12:06 PM, Lisandro Dalcin <dalcinl at gmail.com
> >
> >> 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
> <bsmith at mcs.anl.gov> 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 <dalcinl at gmail.com
> >
> >>>>> 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
>
>
