On Thu, Jul 8, 2010 at 2:11 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><br></div>  Ok, we need a clear well-defined set of terms for type of function call then.<div><br></div><div>1)   Any process can call it, without regard to other processes calling it, with any legal value.   MatGetLocalSize()</div>
</div></blockquote><div><br></div><div>Yep, Not Collective here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div>
2) All processes must call it with the same legal value for the operation to make mathematical sense   VecScale()</div></div></blockquote><div><br></div><div>Coherent? I like this because you are demanding coherence of the calling parameters.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><br></div><div>3) All processes must call it, but each process returns after only exchange with some other processes called "neighbors"  MatMult()</div>
</div></blockquote><div><br></div><div>Neighbor Collective is good I think. It is collective in the sense I understand it, but with a smaller process group.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div>4) All processes must call it, requires a global synchronization before returning on processes, VecDot()</div></div></blockquote><div><br></div><div>Collective.</div><div><br></div><div>
    Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div>  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</div>
<div><br></div><font color="#888888"><div><br></div><div>   Barry</div></font><div><div></div><div class="h5"><div><br></div><div><br></div><div><br></div><div><br><div><div>On Jul 6, 2010, at 12:07 AM, Matthew Knepley wrote:</div>
<br><blockquote type="cite">This is a different definition of collective I think. I thought we were defining collective in the<div>operational sense, meaning requires synchronization. That is what users need to know, since</div>
<div>they will not check the implementation. I believe users know the semantics up front (why would</div>
<div>semantics change from serial to parallel?)</div><div><br></div><div>    Matt<br><br><div class="gmail_quote">On Tue, Jul 6, 2010 at 6:38 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  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.<br>


<font color="#888888"><br>
   Barry<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener<br>


</div>
</blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>