<div class="gmail_quote">On Wed, Sep 21, 2011 at 15:25, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"></div><div class="im">
>   Look at the MPI 3 proposals.<br>
><br>
> The neighborhood collectives are the most natural mapping of VecScatter to MPI, but creation is still not as convenient.<br>
<br>
<br>
</div>    Then they are fucking up MPI-3 and don't know what they are doing. Why not propose to them the correct model?<br></blockquote><div><br></div><div><a href="https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/258/topol.pdf">https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/258/topol.pdf</a></div>
<div><br></div><div>You can see the proposal here, skip ahead to page 24, the red text is new.</div><div><br></div><div>There is no persistent non-blocking operation and setup involves creating a communicator with graph topology and then having the user hold the send and receive buffers. This is fine for implementing our scatter (though I'd prefer a persistent variant), but our scatter is at a much higher level. I don't think it belongs in MPI proper, at least not at this time, and suspect there is little to no hope of getting it in the standard this late even if we had a complete working implementation and full proposal ready for review today.</div>
<div><br></div><div>Perhaps it could go in a thin library on top of MPI, but with no PETSc dependencies.</div></div>