<div dir="ltr">thomas, today you should start thinking about other possibilities<div>to solve your problem. this mpi rma stuff is crappy.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/21 Thomas Jahns <span dir="ltr"><<a href="mailto:jahns@dkrz.de" target="_blank">jahns@dkrz.de</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
should this be the wrong mailing list[1], I apologize in advance and hope for<br>
directions to the correct place to pose my question.<br>
<br>
>From the wording of the MPI 2.2 and 3.0 standards I can see (first<br>
paragraph of 11.2.1 in MPI 2.2, procedurce specification of<br>
MPI_WIN_CREATE in MPI 3.0) that MPI_WIN_CREATE is only allowed for<br>
intracommunicators.<br>
<br>
I was wondering why this restriction is there, when<br>
<br>
1. cases where an intercommunicator is more clear for point-to-point<br>
   communications, communications using rma would equally gain in<br>
   clarity with an intercommunicator (from my POV at least),<br>
<br>
2. the required resources (because the number of potential<br>
   communication paths would be much lower) could be reduced because<br>
   the intercommunicator not only specifies two groups communicating<br>
   with each other but also not communicating (at least via the<br>
   intercommunicator) within each group. I.e. when it is already known<br>
   that the any two processes within one of the two groups of an<br>
   intercommunicator would not issue RMA calls for the other,<br>
   corresponding resources need not be reserved. Intra-communicator RMA<br>
   on the other hand leaves the possibility of any communication pair<br>
   open.<br>
<br>
   Clearly with two groups of processes of sizes N and M the number of<br>
   potential pairs is N * M where a corresponding intercommunicator is<br>
   concerned but (N * M)**2 for an intracommunicator and<br>
<br>
3. the semantics appropriate for an intercommunicator should be easy<br>
   to emulate with MPI_INTERCOMM_MERGE and MPI_GROUP_TRANSLATE_RANKS.<br>
<br>
Since allowing intercommunicators in MPI_WIN_CREATE would consequently<br>
<br>
1. be aesthetically pleasing,<br>
2. offer increased potential for efficient execution,<br>
3. seem to have an easy proof-of-concept implementation strategy and<br>
4. forms a pattern arising naturally from the rest of the standard in my eyes,<br>
<br>
I'm clearly missing some ambiguity or technical/definition difficulty<br>
here, but can't figure out which, why else would the standard<br>
explicitly restrict MPI_WIN_CREATE to intracommunicators if the above<br>
were the whole story?<br>
<br>
Kind regards,<br>
Thomas Jahns<br>
<br>
[1] I've done some searching and came up with either<br>
<<a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a>> or <<a href="mailto:mpi-comment@lists.mpi-forum.org">mpi-comment@lists.mpi-forum.org</a>><br>
<span class="HOEnZb"><font color="#888888">--<br>
Thomas Jahns<br>
DKRZ GmbH, Department: Application software<br>
<br>
Deutsches Klimarechenzentrum<br>
Bundesstraße 45a<br>
D-20146 Hamburg<br>
<br>
Phone: <a href="tel:%2B49-40-460094-151" value="+4940460094151">+49-40-460094-151</a><br>
Fax: <a href="tel:%2B49-40-460094-270" value="+4940460094270">+49-40-460094-270</a><br>
Email: Thomas Jahns <<a href="mailto:jahns@dkrz.de">jahns@dkrz.de</a>><br>
<br>
</font></span><br>_______________________________________________<br>
mpiwg-rma mailing list<br>
<a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a><br></blockquote></div><br></div>