<div class="gmail_quote">On Wed, Sep 21, 2011 at 01:27, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">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;">
<div id=":15c">MPI_GraphComm_init( ......ownership on each process, indices , ...., &ctx);<br>
<br>
  MPI_GraphComm_start(ctx, pointers to the data, MPI_Datatypes, MPI_reduces, ......);<br></div></blockquote><div><br></div><div>MPI_Graph_create has to do with process topology, not indexing within a process. MPI_Datatype is generally local (though MPI_Type_create_darray offers some parallel semantics).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":15c">
<br>
<br>
   Look at the MPI 3 proposals.</div></blockquote></div><br><div>The neighborhood collectives are the most natural mapping of VecScatter to MPI, but creation is still not as convenient. I think we also want to preserve non-MPI-3 functionality for a while. The neighborhood collectives also don't handle matched layouts between arrays with different base types.</div>
<div><br></div><div>But perhaps we can write something that creates the context (basically just number of entries that need to go each place) by inspecting an MPI_Datatype and then it would be guaranteed to work for other types that have the same layout. Then it would just be a matter of getting the MPI stack to share layout information between an integer and scalar datatype with the same layout.</div>