<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Jim,<br>
<br>
General comment: the word "process" in the MPI Standard is not
well-defined. IMHO, it should always be short-hand for "MPI process"
but it is often taken to mean "OS process". Adding a new implicit
meaning, i.e. "endpoint", is not helpful. There is a one-to-many
relationship between OS process and MPI process. There is a
one-to-many relationship between MPI process and endpoint. The term
"process" is used to refer to the child, the parent, or the
grandparent in this hierarchy with the context (hopefully)
determining which meaning is intended.<br>
<br>
I've re-read all of the new text looking for process/rank wording
issues. There are some inconsistencies where "rank" in the parent
communicator is still used.<br>
<br>
Page 244, lines 36-37<br>
%%CURRENT<br>
associated with a single calling rank in parent_comm.<br>
%%SUGGESTION<br>
associated with a single calling process in parent_comm.<br>
<br>
Page 244, line 39<br>
%%CURRENT<br>
at the corresponding rank in parent_comm.<br>
%%SUGGESTION<br>
at the corresponding process in parent_comm.<br>
<br>
Page 244, lines 39-40<br>
%%CURRENT<br>
Ranks associated with a process in parent_comm are numbered
contiguously in the output communicator, and<br>
%%PROBLEM<br>
"process in parent_comm" is intended to refer to "rank in
parent_comm".<br>
Example: create an endpoints communicator, use split to re-order the
ranks then create another endpoints communicator.<br>
The ranks associated with an OS process may not be contiguous - they
may consist of several sub-groups (each of which is internally
contiguous), one per local rank in parent_comm.<br>
%%SUGGESTION1<br>
Ranks in new_comm_handles are numbered contiguously in the output
communicator and<br>
%%SUGGESTION2 (preferred)<br>
Ranks in new_comm_handles are numbered contiguously and<br>
<br>
Page 244, lines 40-41<br>
%%CURRENT<br>
and the starting rank is de fined by the order of the associated
rank in the parent communicator.<br>
%%PROBLEM<br>
"associated rank" is intended to refer to "calling process"<br>
%%SUGGESTION<br>
and the starting rank is de fined by the order of the calling
process in parent_comm.<br>
<br>
Other comments:<br>
<br>
%%PROBLEM<br>
The statements about cached information, valid values for my_num_ep,
and the condition for the error code/class all apply to the
inter-communicator case as well as the intra-communicator case.
Should this be made clearer by moving that text out of the
intra-communicator paragraph and after the inter-communicator
paragraph?<br>
%%SUGGESTION<br>
If parent_comm is an intracommunicator ... sum of the values of
my_num_ep on all calling processes. If parent_comm is an
intercommunicator ... MPI_COMM_NULL is returned in all entries of
new_comm_handles.<br>
<p>No cached information ... this function will return
MPI_ERR_ENDPOINTS at all processes.<br>
<br>
Page 245 line 20<br>
%%CURRENT<br>
Some operations, such as collective operations, cannot be used<br>
%%PROBLEM<br>
A single thread can perform a non-blocking collective even when
there are multiple local endpoints. This would only require
MPI_THREAD_SINGLE.<br>
%%SUGGESTION<br>
Some operations, such as blocking collective operations, cannot be
used<br>
<br>
Cheers,<br>
Dan.<br>
<br>
<div class="moz-cite-prefix">On 01/07/2014 01:45, Jim Dinan wrote:<br>
</div>
<blockquote
cite="mid:CAOoEU4Fe09PXpeG--NSH4ayi9MwPMh_M_m05Fw-B9JLzzCkDzg@mail.gmail.com"
type="cite">
<pre wrap="">All,
Below are two options for the endpoints error text:
%% OLD:
If the MPI implementation is not able to create a new communicator because
of the \mpiarg{my\_num\_ep} argument given by any process, this function
will
return \error{MPI\_ERR\_ENDPOINTS}.
%% Option 2 (Suggested by Pavan):
If a process provides a valid \mpiarg{my\_num\_ep} argument, but the MPI
implementation is not able to create a new communicator because of the
\mpiarg{my\_num\_ep} argument at this process, this function will return
\error{MPI\_ERR\_ENDPOINTS} at all processes.
%% Option 1 (Smallest delta from old text):
If the MPI implementation is not able to create a new communicator because a
valid \mpiarg{my\_num\_ep} argument given by any process, this function will
return \error{MPI\_ERR\_ENDPOINTS} at all processes.
Opinions or suggestions for improvement?
I have attached an updated review document (with option 2 above, but this
is still open for discussion). Please review page 245, lines 7-15. I
removed the use of "endpoint" and replaced it with "rank". I also replaced
instances where we talk about "rank" in the parent communicator with
"process". I think it's clearer now; interested to hear feedback.
Cheers,
~Jim.
On Mon, Jun 30, 2014 at 11:43 AM, Jim Dinan <a class="moz-txt-link-rfc2396E" href="mailto:james.dinan@gmail.com"><james.dinan@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I can attend, but will be 10 minutes late. Attached is an updated copy of
the endpoints proposal with feedback from the Chicago meeting. Let's
review these changes, and we also have an item to discuss from that meeting
with regard to how errors are returned from MPI_Comm_create_endpoints.
On Sun, Jun 29, 2014 at 2:40 PM, Balaji, Pavan <a class="moz-txt-link-rfc2396E" href="mailto:balaji@anl.gov"><balaji@anl.gov></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">All,
This is a reminder that we’ll have our hybrid WG telecon tomorrow (06/30)
at 11am central time.
I’ve made the promised corrections to ticket 411 and uploaded a new draft.
<a class="moz-txt-link-freetext" href="https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/411">https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/411</a>
We can discuss this tomorrow, together with the remaining tickets.
Thanks,
— Pavan
_______________________________________________
mpiwg-hybridpm mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mpiwg-hybridpm@lists.mpi-forum.org">mpiwg-hybridpm@lists.mpi-forum.org</a>
<a class="moz-txt-link-freetext" href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mpiwg-hybridpm mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mpiwg-hybridpm@lists.mpi-forum.org">mpiwg-hybridpm@lists.mpi-forum.org</a>
<a class="moz-txt-link-freetext" href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Dan Holmes
Applications Consultant in HPC Research
EPCC, The University of Edinburgh
James Clerk Maxwell Building
The Kings Buildings
Mayfield Road
Edinburgh, UK
EH9 3JZ
T: +44(0)131 651 3465
E: <a class="moz-txt-link-abbreviated" href="mailto:dholmes@epcc.ed.ac.uk">dholmes@epcc.ed.ac.uk</a>
*Please consider the environment before printing this email.*</pre>
</body>
</html>