<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi all,<br>
<br>
At the request of other working group members, I'm re-sending this
email to bring this issue back to life.<br>
<br>
Cheers,<br>
Dan.<br>
<div class="moz-forward-container">-------- Forwarded Message
--------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
</th>
<td>Changing MPI_GROUP|COMM_COMPARE for endpoints</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
<td>Thu, 29 Jan 2015 18:22:29 +0000</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
<td>Daniel Holmes <a class="moz-txt-link-rfc2396E" href="mailto:dholmes@epcc.ed.ac.uk"><dholmes@epcc.ed.ac.uk></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Reply-To:
</th>
<td><a class="moz-txt-link-abbreviated" href="mailto:dholmes@epcc.ed.ac.uk">dholmes@epcc.ed.ac.uk</a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Organization:
</th>
<td>EPCC</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:mpiwg-hybridpm@lists.mpi-forum.org">mpiwg-hybridpm@lists.mpi-forum.org</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
Hi Jim/all,<br>
<br>
I won't be able to attend the next Hybrid WG teleconference (I'm
on holiday from tomorrow until 10th Feb) but that will be the last
opportunity to discuss changes to the endpoints text before it
needs to be sent to the forum mailing list if it is to be in time
to be formally read.<br>
<br>
At the last teleconference, we decided that we should look at a
"minimum change" option and a "maximum readability" or "maximum
de-duplication" option.<br>
<br>
--- exec summary ---<br>
<br>
This is a tricky change with unexpected repercussions to other
areas that needs a lot of careful thought.<br>
It would be unfortunate if that extended effort delayed/derailed
the main endpoints proposal.<br>
We have a very good reason to go for the minimum change option
described below.<br>
<br>
--- option 1 - minimum change ---<br>
<br>
I think that the obvious "minimum change" option is that we
propose not to change MPI_COMM_COMPARE or MPI_GROUP_COMPARE at all
and not add the new result of MPI_ALIASED either. This could be
moved to a separate proposal that would be dependent on #380
passing. Some would claim the new comparison ticket would be
essential if endpoints passes - this is the only good reason to
combine the two changes.<br>
<br>
--- option 2 - maximum readability/de-duplication ---<br>
<br>
This is the current text for MPI_GROUP_COMPARE:<br>
<br>
MPI_IDENT results if the group members and group order is exactly
the same in both groups.<br>
This happens for instance if group1 and group2 are the same
handle. MPI_SIMILAR results if<br>
the group members are the same but the order is different.
MPI_UNEQUAL results otherwise.<br>
<br>
Here's suggested new text for MPI_GROUP_COMPARE:<br>
<br>
Groups are identical if they contain the same group members in the
same order.<br>
Groups are similar if they contain the same group members but not
in the same order.<br>
MPI_IDENT results if the group handles refer to the same group
member in identical groups.<br>
MPI_ALIASED results if the group handles refer to different group
members in identical groups.<br>
MPI_SIMILAR results if the group handles refer to the same group
member in similar groups.<br>
MPI_UNEQUAL results otherwise.<br>
<br>
This is the current text for MPI_COMM_COMPARE:<br>
<br>
MPI_IDENT results if and only if comm1 and comm2 are handles for
the same object (identical<br>
groups and same contexts). MPI_CONGRUENT results if the underlying
groups are identical<br>
in constituents and rank order; these communicators differ only by
context. MPI_SIMILAR<br>
results if the group members of both communicators are the same
but the rank order differs.<br>
MPI_UNEQUAL results otherwise.<br>
<br>
Here's suggested new text for MPI_COMM_COMPARE:<br>
<br>
Communicators are identical if they have identical communication
contexts; this implies that their underlying groups are also
identical.<br>
MPI_IDENT results if the communicator handles refer to the same
rank in identical communicators.<br>
MPI_ALIASED results if the communicator handles refer to different
ranks in identical communicators.<br>
MPI_CONGRUENT results if the two communicators have identical
underlying groups but different communication contexts.<br>
MPI_SIMILAR results if the two communicators have similar
underlying groups.<br>
MPI_UNEQUAL results otherwise.<br>
<br>
--- notes ---<br>
<br>
Talking about same|different *group members* in identical|similar
groups<br>
is preferred over talking about same|different *ranks* because<br>
"same|different rank in similar groups" does not guarantee
"same|different endpoint in similar groups"<br>
which is what we want to say without including the word
"endpoint".<br>
<br>
Talking about ranks in communicators is preferred over group
members<br>
because communicators do not have group members even though their
underlying groups do.<br>
They perhaps have members, i.e. without the "group" qualifier.<br>
<br>
The phrases "same rank" and "different ranks" are only ever
applied to identical communicators<br>
because they are only guaranteed to mean "same endpoint" and
"different endpoint" for identical communicators.<br>
<br>
--- issues ---<br>
<br>
This range of responses is incomplete and therefore inadequate.<br>
Incomplete because, for example in the group comparison:<br>
MPI_SIMILAR_ALIASED results if the group handles refer to
different group members in similar groups.<br>
<br>
Inadequate because it seems that the interesting definition for
the "aliased" property of handles is<br>
whether or not they refer to the same endpoint or different
endpoints. To be able to determinable that<br>
for *any* two group/comm handles, "aliased" must be completely
orthogonal to all the other criteria.<br>
We would need an additional MPI_UNEQUAL_ALIASED response for both
comparison functions<br>
as well as MPI_CONGRUENT_ALIASED for communicator comparison.<br>
This implies that MPI_GROUP_ALIASED(group1, group2) and
MPI_COMM_ALIASED(comm1, comm2)<br>
is a better approach.<br>
<br>
One of the main reasons for needing to know whether or not two
handles refer to the same endpoint<br>
is the proposed restriction on usage of group manipulation
functions, i.e. not allowing aliased handles.<br>
I believe we should define a fix for each of these functions so
that this restriction is not needed.<br>
<br>
--- conclusion ---<br>
<br>
This is a tricky change with unexpected repercussions to other
areas that needs a lot of careful thought.<br>
It would be unfortunate if that extended effort delayed/derailed
the main endpoints proposal.<br>
We have a very good reason to go for the minimum change option.<br>
<br>
Cheers,<br>
Dan.<br>
<br>
<div class="moz-cite-prefix">On 26/01/2015 21:42, Jim Dinan wrote:<br>
</div>
<blockquote
cite="mid:CAOoEU4Euzc578v5Qxci9dVKVeedNK1rmnh2B+Nzwz73UuKuUcg@mail.gmail.com"
type="cite">
<div dir="ltr">All,
<div><br>
</div>
<div>Here is the diff of changes from the December meeting.
There's one spot where a few options for the text are
included and the MPI_ALIASED changes are still pending
(thanks to Dan for leading this tricky task).</div>
<div><br>
</div>
<div>Thanks,</div>
<div> ~Jim.<br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Jan 26, 2015 at 10:53 AM, Jim
Dinan <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:james.dinan@gmail.com" target="_blank">james.dinan@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi All,
<div><br>
</div>
<div>Reminder that there will be a meeting at 11am CT
today.</div>
<div><br>
</div>
<div> ~Jim.</div>
<div><br>
</div>
<div>
<div style="font-size:13px">=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">Meeting Info:</div>
<div style="font-size:13px"><br>
</div>
<a moz-do-not-send="true"
href="https://cisco.webex.com/ciscosales/j.php?ED=236535652&UID=0&PW=NOGE0NDk5MmVh&RT=MiMxMQ%3D%3D"
style="font-size:13px" target="_blank">https://cisco.webex.com/ciscosales/j.php?ED=236535652&UID=0&PW=NOGE0NDk5MmVh&RT=MiMxMQ%3D%3D</a><br
style="font-size:13px">
<br style="font-size:13px">
<a moz-do-not-send="true" href="tel:%2B1-866-432-9903"
value="+18664329903" style="font-size:13px"
target="_blank">+1-866-432-9903</a><br
style="font-size:13px">
<span style="font-size:13px">Meeting ID: 206095536</span>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px"><a moz-do-not-send="true"
href="https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Hybrid"
target="_blank">https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Hybrid</a><br>
</div>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mpiwg-hybridpm mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:mpiwg-hybridpm@lists.mpi-forum.org">mpiwg-hybridpm@lists.mpi-forum.org</a>
<a moz-do-not-send="true" 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
Peter Guthrie Tait Road
Edinburgh
EH9 3FD
T: +44(0)131 651 3465
E: <a moz-do-not-send="true" 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>
<br>
</div>
<br>
<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
Peter Guthrie Tait Road
Edinburgh
EH9 3FD
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>