[petsc-dev] meaning of VecScale() if not a collective

Matthew Knepley knepley at gmail.com
Thu Jul 8 03:12:53 CDT 2010


On Thu, Jul 8, 2010 at 2:11 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
>   Ok, we need a clear well-defined set of terms for type of function call
> then.
>
> 1)   Any process can call it, without regard to other processes calling it,
> with any legal value.   MatGetLocalSize()
>

Yep, Not Collective here.


> 2) All processes must call it with the same legal value for the operation
> to make mathematical sense   VecScale()
>

Coherent? I like this because you are demanding coherence of the calling
parameters.


>
> 3) All processes must call it, but each process returns after only exchange
> with some other processes called "neighbors"  MatMult()
>

Neighbor Collective is good I think. It is collective in the sense I
understand it, but with a smaller process group.


> 4) All processes must call it, requires a global synchronization before
> returning on processes, VecDot()
>

Collective.

    Matt


>   In the manual pages I've been calling 1 Not Collective and 2-4
> collective. Suggestions for names? Perhaps 2) Mathematically collective 3)
> Neighbor collective? Once we have good names I can change the manual pages
>
>
>    Barry
>
>
>
>
> On Jul 6, 2010, at 12:07 AM, Matthew Knepley wrote:
>
> This is a different definition of collective I think. I thought we were
> defining collective in the
> operational sense, meaning requires synchronization. That is what users
> need to know, since
> they will not check the implementation. I believe users know the semantics
> up front (why would
> semantics change from serial to parallel?)
>
>     Matt
>
> On Tue, Jul 6, 2010 at 6:38 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>>
>>  I consider that VecScale() has to be considered a collective that
>> requires all processors to pass the same value for the scalar in the same
>> way that VecAXPY() is a collective operation that requires the same value
>> for alpha. The reason is that though you can pass in different values on
>> different processes or not call it on some processes it has no well defined
>> mathematical meaning in that case since there result depends on the vector
>> layout across processors. In fact I'd like to put a error check that does a
>> global collective and make sure that the value pass in on all processes is
>> the same in debug mode.
>>
>>   Barry
>>
>>
>
>
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100708/a8f78715/attachment.html>


More information about the petsc-dev mailing list