Repeating a Neighbor in a Graph Communicator Ambiguity with MPI_GRAPH_NEIGHBOR[_COUNT] #3

mpiforumbot · 2016-07-23T22:13:39Z

Originally by jsquyres on 2008-09-05 07:56:36 -0500

Description

Sep 8 2008 Straw Vote

|| Unique || Original || Abstain ||
|| 0 || 25 || 7 ||

MPI-2.1 specifically allows graph communicators to be created by listing a neighbor more than once in the node list. This results in an ambiguity in MPI_GRAPH_NEIGHBORS and MPI_GRAPH_NEIGHBORS_COUNT: should the list/count returned refer to a unique list of neighbors, or the original set of neighbors (including duplicates) that were used to create the communicator?

History

Ambiguity was accidentally introduced in MPI-2.1 (verified in July 2008 Forum meeting).

Proposed Solution

Per straw vote in the September 2008 Dublin Forum meeting, it was decided to return the non-unique list (i.e., the same values that were passed to the constructor). Specifically, remove the current description paragraph (from between MPI_GRAPH_NEIGHBORS_COUNT and MPI_GRAPH_NEIGHBORS) and add a new description paragraph (after MPI_GRAPH_NEIGHBORS) and add a new example explicitly showing the issue:

Remove "MPI_GRAPH_NEIGHBORS_COUNT and MPI_GRAPH_NEIGHBORS provide adjacency information for a general graph topology." from p251:34-35
Add the following after p252:5

MPI_GRAPH_NEIGHBORS_COUNT and MPI_GRAPH_NEIGHBORS provide adjacency information for a general graph topology. The returned count and array of neighbors for the queried rank will both include all neighbors and reﬂect the same edge ordering as was speciﬁed by the original call to MPI_GRAPH_CREATE. Speciﬁcally, MPI_GRAPH_NEIGHBORS_COUNT and MPI_GRAPH_NEIGHBORS will return values based on the original index and edges array passed to MPI_GRAPH_CREATE (assuming that index[-1] effectively equals zero):

• The count returned from MPI_GRAPH_NEIGHBORS_COUNT will be (index[rank] - index[rank-1]).

• The neighbors array returned from MPI_GRAPH_NEIGHBORS will be edges[index[rank-1]] through edges[index[rank]-1].
Add a new example showing the issue (see the tex below, or the attached PDF).

Here's the tex changes:

#!diff
Index: chap-topol/topol.tex
===================================================================
--- chap-topol/topol.tex    (revision 185)
+++ chap-topol/topol.tex    (working copy)
@@ -657,11 +657,6 @@
 \mpicppemptybind{MPI::Graphcomm::Get\_neighbors\_count(int~rank) const}{int}
 \mpiiidotiMergeFromTWOdotZEROend%      MPI-2.1

-\func{MPI\_GRAPH\_NEIGHBORS\_COUNT} and \func{MPI\_GRAPH\_NEIGHBORS} provide
-\mpiiidotiMergeNEWforSINGLEbegin% MPI-2.1 round-two - removed ,
-adjacency information for a general graph topology.
-\mpiiidotiMergeNEWforSINGLEendI% MPI-2.1 round-two
-
 \begin{funcdef}{MPI\_GRAPH\_NEIGHBORS(comm, rank, maxneighbors, neighbors)}
 \funcarg{\IN}{ comm}{ communicator with graph topology (handle)}
 \funcarg{\IN}{ rank}{ rank of process in group of \mpiarg{comm} (integer)}
@@ -676,6 +671,84 @@
 \mpicppemptybind{MPI::Graphcomm::Get\_neighbors(int~rank, int~maxneighbors, int neighbors[]) const}{void}
 \mpiiidotiMergeFromTWOdotZEROend%      MPI-2.1

+\func{MPI\_GRAPH\_NEIGHBORS\_COUNT} and \func{MPI\_GRAPH\_NEIGHBORS} provide 
+\mpiiidotiMergeNEWforSINGLEbegin% MPI-2.1 round-two - removed , 
+adjacency information for a general graph topology. 
+\mpiiidotiMergeNEWforSINGLEendI% MPI-2.1 round-two 
+%
+The returned count and array of neighbors for the queried rank will
+both include {\em all} neighbors and reflect the same edge ordering as
+was specified by the original call to \func{MPI\_GRAPH\_CREATE}.
+%
+Specifically, \func{MPI\_GRAPH\_NEIGHBORS\_COUNT} and
+\func{MPI\_GRAPH\_NEIGHBORS} will return values based on the original
+{\tt index} and {\tt edges} array passed to \func{MPI\_GRAPH\_CREATE}
+(assuming that {\tt index[-1]} effectively equals zero):
+
+\begin{itemize}
+\item The {\tt count} returned from
+  \func{MPI\_GRAPH\_NEIGHBORS\_COUNT} will be ({\tt index[rank]} -
+  {\tt index[rank-1]}).
+\item The {\tt neighbors} array returned from
+  \func{MPI\_GRAPH\_NEIGHBORS} will be {\tt edges[index[rank-1]]}
+  through {\tt edges[index[rank]-1]}.
+\end{itemize}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{example} {\rm
+\label{topol-graph-neighbors-count}
+\exindex{MPI\_GRAPH\_NEIGHBORS\_COUNT}
+\exindex{MPI\_GRAPH\_NEIGHBORS}
+\exindex{MPI\_GRAPH\_CREATE}
+
+Assume there are four processes 0, 1, 2, 3 with the following
+adjacency matrix (note that some neighbors are listed multiple times):
+\\[2.0ex]
+%
+\hspace*{\parindent}
+\begin{tabular}{|c|l|}
+\hline
+process & neighbors \\
+\hline
+0       & 1, 1, 3   \\
+1       & 0, 0      \\
+2       & 3         \\
+3       & 0, 2, 2   \\
+\hline
+\end{tabular}
+\vspace*{2.0ex}
+
+Thus, the input arguments to \func{MPI\_GRAPH\_CREATE} are: \\[2.0ex]
+%
+\hspace*{\parindent}
+\begin{tabular}{ll}
+nnodes = & 4 \\
+index = & 3, 5, 6, 9 \\
+edges = & 1, 1, 3, 0, 0, 3, 0, 2, 2
+\end{tabular}
+\vspace*{2.0ex}
+
+Therefore, calling \func{MPI\_GRAPH\_NEIGHBORS\_COUNT} and
+\func{MPI\_GRAPH\_NEIGHBORS} for each of the 4 processes will return: \\[2.0ex]
+%
+\hspace*{\parindent}
+\begin{tabular}{ccl}
+\multicolumn{1}{c}{\bf Input rank} & \multicolumn{1}{c}{\bf Count} &
+\multicolumn{1}{c}{\bf Neighbors} \\
+\hline
+0 & 3 & 1, 1, 3 \\
+1 & 2 & 0, 0 \\
+2 & 1 & 3 \\
+3 & 3 & 0, 2, 2 \\
+\hline
+\end{tabular}
+\vspace*{2.0ex}
+
+} \end{example}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
 \begin{example} { \rm
 \label{topol-exC}
 \exindex{MPI\_GRAPH\_CREATE}

Impact on Implementations

Implementations will need to ensure that they save the extra information (i.e., nodes listed multiple times) so that they can be counted / returned later.

Impact on Applications / Users

Applications will need to ensure to handle the non-unique list that is returned.

Alternative Solutions

Forum decided that there shouldn't be an alternate solution -- all implementations should do the same thing.

Entry for the Change Log

Section 7.5.4 on page 248. Remove ambiguity regarding duplicated neighbors with MPI_GRAPH_NEIGHBORS and MPI_GRAPH_NEIGHBORS_COUNT.

The text was updated successfully, but these errors were encountered:

mpiforumbot · 2016-07-23T22:13:44Z

Originally by gropp on 2008-10-26 09:43:48 -0500

The October 2008 meeting asked that the proposed text be changed to make even clearer that the same values that were passed to Graph_create are returned by graph neighbor and graph neighbor count, even if those arguments specified duplicates.

mpiforumbot · 2016-07-23T22:13:44Z

Originally by jsquyres on 2008-12-06 11:19:20 -0600

Updated proposal text per Oct 2008 meeting. Attached a PDF so that you can see the proposed changes in the context of the rest of the chapter text.

Needs reviews:

George Bosilca
Rolf Rabenseifner
Bill Gropp
Bronis de Supinski

mpiforumbot · 2016-07-23T22:13:46Z

Originally by bronis on 2008-12-06 13:00:09 -0600

There was an error in the example. Task 0 should return 3 for MPI_GRAPH_NEIGHBORS_COUNT but the example had 2. I fixed it on
the wiki but I did not generate a new PDF. Perhaps Jeff can do that...

Replying to [#3 jsquyres]:

Description

Sep 8 2008 Straw Vote

|| Unique || Original || Abstain ||
|| 0 || 25 || 7 ||

MPI-2.1 specifically allows graph communicators to be created by listing a neighbor more than once in the node list. This results in an ambiguity in MPI_GRAPH_NEIGHBORS and MPI_GRAPH_NEIGHBORS_COUNT: should the list/count returned refer to a unique list of neighbors, or the original set of neighbors (including duplicates) that were used to create the communicator?

History

Ambiguity was accidentally introduced in MPI-2.1 (verified in July 2008 Forum meeting).

Proposed Solution

Per straw vote in the September 2008 Dublin Forum meeting, it was decided to return the non-unique list (i.e., the same values that were passed to the constructor). Specifically, remove the current description paragraph (from between MPI_GRAPH_NEIGHBORS_COUNT and MPI_GRAPH_NEIGHBORS) and add a new description paragraph (after MPI_GRAPH_NEIGHBORS) and add a new example explicitly showing the issue:

Remove "MPI_GRAPH_NEIGHBORS_COUNT and MPI_GRAPH_NEIGHBORS provide adjacency information for a general graph topology." from p251:34-35

Add the following after p252:5

The returned count and array of neighbors for the queried rank will both include all neighbors and reﬂect the same edge ordering as was speciﬁed by the original call to MPI_GRAPH_CREATE. Speciﬁcally, MPI_GRAPH_NEIGHBORS_COUNT and MPI_GRAPH_NEIGHBORS will return values based on the original index and edges array passed to MPI_GRAPH_CREATE (assuming that index[-1] effectively equals zero):

• The count returned from MPI_GRAPH_NEIGHBORS_COUNT will be (index[rank] - index[rank-1]).

• The neighbors array returned from MPI_GRAPH_NEIGHBORS will be edges[index[rank-1]] to edges[index[rank]].

Add a new example showing the issue (see the tex below, or the attached PDF).

Here's the tex changes:
#!diff
Index: chap-topol/topol.tex
===================================================================
--- chap-topol/topol.tex  (revision 185)
+++ chap-topol/topol.tex  (working copy)
@@ -657,11 +657,6 @@
 \mpicppemptybind{MPI::Graphcomm::Get\_neighbors\_count(int~rank) const}{int}
 \mpiiidotiMergeFromTWOdotZEROend%      MPI-2.1

-\func{MPI\_GRAPH\_NEIGHBORS\_COUNT} and \func{MPI\_GRAPH\_NEIGHBORS} provide
-\mpiiidotiMergeNEWforSINGLEbegin% MPI-2.1 round-two - removed ,
-adjacency information for a general graph topology.
-\mpiiidotiMergeNEWforSINGLEendI% MPI-2.1 round-two
-
 \begin{funcdef}{MPI\_GRAPH\_NEIGHBORS(comm, rank, maxneighbors, neighbors)}
 \funcarg{\IN}{ comm}{ communicator with graph topology (handle)}
 \funcarg{\IN}{ rank}{ rank of process in group of \mpiarg{comm} (integer)}
@@ -676,6 +671,78 @@
 \mpicppemptybind{MPI::Graphcomm::Get\_neighbors(int~rank, int~maxneighbors, int neighbors[]) const}{void}
 \mpiiidotiMergeFromTWOdotZEROend%      MPI-2.1

+The returned count and array of neighbors for the queried rank will
+both include {\em all} neighbors and reflect the same edge ordering as
+was specified by the original call to \func{MPI\_GRAPH\_CREATE}.
+%
+Specifically, \func{MPI\_GRAPH\_NEIGHBORS\_COUNT} and
+\func{MPI\_GRAPH\_NEIGHBORS} will return values based on the original
+{\tt index} and {\tt edges} array passed to \func{MPI\_GRAPH\_CREATE}
+(assuming that {\tt index[-1]} effectively equals zero):
+
+\begin{itemize}
+\item The {\tt count} returned from
+  \func{MPI\_GRAPH\_NEIGHBORS\_COUNT} will be ({\tt index[rank]} -
+  {\tt index[rank-1]}).
+\item The {\tt neighbors} array returned from
+  \func{MPI\_GRAPH\_NEIGHBORS} will be {\tt edges[index[rank-1]]}
+  through {\tt edges[index[rank]]}.
+\end{itemize}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{example} {\rm
+\label{topol-graph-neighbors-count}
+\exindex{MPI\_GRAPH\_NEIGHBORS\_COUNT}
+\exindex{MPI\_GRAPH\_NEIGHBORS}
+
+Assume there are four processes 0, 1, 2, 3 with the following
+adjacency matrix (note that some neighbors are listed multiple times):
+\\[2.0ex]
+%
+\hspace*{\parindent}
+\begin{tabular}{|c|l|}
+\hline
+process & neighbors \\
+\hline
+0       & 1, 1, 3   \\
+1       & 0, 0      \\
+2       & 3         \\
+3       & 0, 2, 2   \\
+\hline
+\end{tabular}
+\vspace*{2.0ex}
+
+Thus, the input arguments to \func{MPI\_GRAPH\_CREATE} are: \\[2.0ex]
+%
+\hspace*{\parindent}
+\begin{tabular}{ll}
+nnodes = & 4 \\
+index = & 3, 5, 6, 9 \\
+edges = & 1, 1, 3, 0, 0, 3, 0, 2, 2
+\end{tabular}
+\vspace*{2.0ex}
+
+Therefore, calling \func{MPI\_GRAPH\_NEIGHBORS\_COUNT} and
+\func{MPI\_GRAPH\_NEIGHBORS} for each of the 4 processes will return: \\[2.0ex]
+%
+\hspace*{\parindent}
+\begin{tabular}{ccl}
+\multicolumn{1}{c}{\bf Input rank} & \multicolumn{1}{c}{\bf Count} &
+\multicolumn{1}{c}{\bf Neighbors} \\
+\hline
+0 & 2 & 1, 1, 3 \\
+1 & 2 & 0, 0 \\
+2 & 1 & 3 \\
+3 & 3 & 2, 2 \\
+\hline
+\end{tabular}
+\vspace*{2.0ex}
+
+} \end{example}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
 \begin{example} { \rm
 \label{topol-exC}
 \exindex{MPI\_GRAPH\_CREATE}
Impact on Implementations

Implementations will need to ensure that they save the extra information (i.e., nodes listed multiple times) so that they can be counted / returned later.

Impact on Applications / Users

Applications will need to ensure to handle the non-unique list that is returned.

Alternative Solutions

Forum decided that there shouldn't be an alternate solution -- all implementations should do the same thing.

Entry for the Change Log

Remove ambiguity regarding duplicated neighbors with MPI_GRAPH_NEIGHBORS and MPI_GRAPH_NEIGHBORS_COUNT.

mpiforumbot · 2016-07-23T22:13:46Z

Originally by jsquyres on 2008-12-06 14:05:14 -0600

Thanks for the catch. I'll update the PDF in a bit.

mpiforumbot · 2016-07-23T22:13:47Z

Originally by jsquyres on 2008-12-08 16:36:12 -0600

PDF updated.

mpiforumbot · 2016-07-23T22:13:47Z

Originally by gropp on 2008-12-09 06:44:24 -0600

Review: Why remove lines 660-664 from the topol.tex file? This seems misplaced but there is a need for this top-level text.

mpiforumbot · 2016-07-23T22:13:48Z

Originally by jsquyres on 2008-12-09 07:02:53 -0600

Replying to gropp:

Review: Why remove lines 660-664 from the topol.tex file? This seems misplaced but there is a need for this top-level text.

Agreed; replaced (but I moved the text down below the two functions).

mpiforumbot · 2016-07-23T22:13:48Z

Originally by gropp on 2008-12-09 07:17:03 -0600

Thanks, that looks good. Reviewed and accepted.

mpiforumbot · 2016-07-23T22:13:49Z

Originally by RolfRabenseifner on 2008-12-11 10:08:29 -0600

Review:

In "Proposed Solution", please repeat the sentence from 251:34-35 at the beginning of the new wording after 252:5.
In the attached pdf (p252:37) and on topol.tex line 742 in the ticket above, please substitute "2, 2" by "0, 2, 2"
In the "Entry for the Change-Log", please start with the new line
"Section 7.5.4 on page 248."
Please add \exindex{MPI_GRAPH_CREATE} to your new example, because it also shows that the adjacency matrix needs not to be symetric.

mpiforumbot · 2016-07-23T22:13:50Z

Originally by jsquyres on 2008-12-11 10:43:00 -0600

Replying to RolfRabenseifner:

Review:

In "Proposed Solution", please repeat the sentence from 251:34-35 at the beginning of the new wording after 252:5.

Already done.

In the attached pdf (p252:37) and on topol.tex line 742 in the ticket above, please substitute "2, 2" by "0, 2, 2"

Good catch; thanks. Fixed.

In the "Entry for the Change-Log", please start with the new line
"Section 7.5.4 on page 248."

Done.

Please add \exindex{MPI_GRAPH_CREATE} to your new example, because it also shows that the adjacency matrix needs not to be symetric.

Done.

mpiforumbot · 2016-07-23T22:13:50Z

Originally by jsquyres on 2008-12-11 10:43:26 -0600

Attachment added: graph-neighbors-proposal-render-4.pdf (146.6 KiB)

mpiforumbot · 2016-07-23T22:13:51Z

Originally by jsquyres on 2008-12-16 08:18:38 -0600

Reviewers -- since there were changes to this ticket, it needs to be reviewed again. Please re-submit your review.

Thanks!

mpiforumbot · 2016-07-23T22:13:51Z

Originally by bronis on 2008-12-16 08:35:46 -0600

Reviewed current version; it is fine. The question remains whether the Forum wants to reconsider the solution adopted. I am ambivalent about that. Hopefully, we can settle it once and for all today.

mpiforumbot · 2016-07-23T22:13:52Z

Originally by gropp on 2008-12-16 08:40:11 -0600

The revision is fine with me.

mpiforumbot · 2016-07-23T22:13:52Z

Originally by jsquyres on 2008-12-17 13:03:51 -0600

Added a little text in the proposal text per Rolf's comments
Updated the latex diff; somehow I missed the latest latest latest version that included the \exindex{} notation with MPI_GRAPH_CREATE on [new] line 703.

mpiforumbot · 2016-07-23T22:18:53Z

Originally by bronis on 2008-12-22 10:41:36 -0600

If I follow correctly, the only changes since my last review (please forgive my confusion about whether anything needed to be reconsidered here) are changes to the proposal section that do not require review and the addition of making the index entry for MPI_GRAPH_CREATE reflect the example, which is clearly correct. I think we still need two reviewers for this issue...

mpiforumbot · 2016-07-23T22:18:54Z

Originally by jsquyres on 2008-12-23 11:05:42 -0600

Replying to bronis:

If I follow correctly, the only changes since my last review (please forgive my confusion about whether anything needed to be reconsidered here) are changes to the proposal section that do not require review and the addition of making the index entry for MPI_GRAPH_CREATE reflect the example, which is clearly correct. I think we still need two reviewers for this issue...

Correct on all counts.

mpiforumbot · 2016-07-23T22:18:54Z

Originally by RolfRabenseifner on 2009-01-19 06:28:34 -0600

Okay with me.

mpiforumbot · 2016-07-23T22:18:55Z

Originally by jsquyres on 2009-01-26 15:09:39 -0600

Bill and George -- please review so that we can discuss in San Jose. Thanks!

mpiforumbot · 2016-07-23T22:18:55Z

Originally by gropp on 2009-02-06 14:44:01 -0600

Reviewed and still ok

mpiforumbot · 2016-07-23T22:18:55Z

Originally by bosilca on 2009-02-09 15:31:10 -0600

I definitively prefer this solution to the one in the standard today.

mpiforumbot · 2016-07-23T22:18:56Z

Originally by jsquyres on 2009-02-12 13:01:17 -0600

Need to ensure that Open MPI does it this way to verify the implementation.

mpiforumbot · 2016-07-23T22:18:58Z

Originally by traff on 2009-07-13 10:07:49 -0500

Changes done by chapter author (Jesper), reviewers please see attachment

mpiforumbot · 2016-07-23T22:18:58Z

Originally by RolfRabenseifner on 2009-07-13 12:04:03 -0500

PDF-review:

In ticket3.pdf, page 251 is missing (lines 34-35 should be removed).
I checked it with a newly created mpi-report.pdf:
It is not done.
The sentence

The neighbors array returned from MPI_GRAPH_NEIGHBORS will be edges[index[rank-1]] through edges[index[rank]].

is spelled diffetent in the proposal's text and in the tex-diff of
the ticket. The first version is "to edges" the second
version is "through edges".

Which one is better and should be used?

mpiforumbot · 2016-07-23T22:18:59Z

Originally by traff on 2009-07-14 08:03:48 -0500

Thanks Rolf,

the removal macro for p. 251 was there, but I forgot to comment out the text, sorry
I have kept the "through" wording, which sounds better to my ear. Jeff?
However, I have a problem with the "through edges[index[rank]]" - shouldn't that
be "through edges[index[rank]]-1", the last entry is not included in the list
of edges for rank

An updated pdf has been attached

Jesper

mpiforumbot · 2016-07-23T22:19:00Z

Originally by RolfRabenseifner on 2009-07-14 11:12:50 -0500

Yes, Jesper, you are right: The sentence

The neighbors array returned from MPI_GRAPH_NEIGHBORS will be edges[index[rank-1]] through edges[index[rank]].

is wrong. I checked it with the example MPI-2.1 p247:1-11.
Your proposal "through edges[index[rank]]-1" is also not correct.
I expect that the correct sentence is

The neighbors array returned from MPI_GRAPH_NEIGHBORS will be edges[index[rank-1]] through edges[index[rank]-1].

mpiforumbot · 2016-07-23T22:19:00Z

Originally by traff on 2009-07-14 11:37:13 -0500

Replying to RolfRabenseifner:

Yes, Jesper, you are right: The sentence

The neighbors array returned from MPI_GRAPH_NEIGHBORS will be edges[index[rank-1]] through edges[index[rank]].

is wrong. I checked it with the example MPI-2.1 p247:1-11.
Your proposal "through edges[index[rank]]-1" is also not correct.
I expect that the correct sentence is

The neighbors array returned from MPI_GRAPH_NEIGHBORS will be edges[index[rank-1]] through edges[index[rank]-1].

eeh, yes, of course, that was, somehow what I meant... Jeff, other reviewers, can you check the contents of this?

Jesper

mpiforumbot · 2016-07-23T22:19:01Z

Originally by bronis on 2009-07-16 10:09:57 -0500

Outside the ticket system, Jesper and Rolf have sent the following email thread:

Date: Thu, 16 Jul 2009 11:25:10 +0200
From: "Jesper-Larsson [iso-8859-1] Tr�ff" traff@it.neclab.eu
To: Rolf Rabenseifner rabenseifner@hlrs.de
Cc: jsquyres@cisco.com, wgropp@illinois.edu, bosilca@eecs.utk.edu, bronis@llnl.gov
Subject: Re: Bug in Passed Ticket 3

I fully agree with Rolf. Please have a look; I can do the edit of
the ticket and the pdf

Jesper

On Thu, Jul 16, 2009 at 11:04:52AM +0200, Rolf Rabenseifner wrote:

Jeff, Bill, Georg, and Bronis,

you have been author and reviewers on Ticket #3.
I'm not sure whether you have seen the automatic ticket mail.

Ticket 3 has bug and has already "passed".
All reviewer (including me) said, that the ticket is okay.
Jesper and I are now sure that there is a bug that must be fixed.

Please comment our latest comments.
If we all agree that the ticket must be changed, then
Jeff should cahnge the ticket's solution
and Jesper can implement the "-1".
I would say that it is a minor change that should not reset
the voting procedure.

Best regards
Rolf

Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@hlrs.de
High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
Head of Dpmt Parallel Computing . . . www.*hlrs.de/people/rabenseifner
Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

I have reviewed the issue and agree that it should be "edges[index[rank]-1]".

I feel Bill should comment on whether this should require a vote. I believe
it probably falls under his stated intention that a review of the overall
content of each chapter should occur after the tickets are implemented. It
is not clear to me if he plans for us to vote on changes that emerge from
those reviews. If so, we probably need a ticket per chapter that lists the
changes on a chapter by chapter basis. This would be the first item for the
ticket for chapter 7.

mpiforumbot · 2016-07-23T22:19:01Z

Originally by RolfRabenseifner on 2009-07-16 11:16:51 -0500

I would prefere one summary ticket where all authors and reviewers add changes that have been done after 2nd vote - sorted by page/line according to MPI-2.1.

Discussions should stay in the original tickets.

Example:

-Chap. 5 Collective ...*

MPI-2.1 p158:5-7 and p158:17-19, Ticket #93:

Same text as modified MPI-2.2 text for p156:15-17 and p156:25-27.

-Reason:* Consistency

MPI-2.1 p236:48, Ticket #49:

Sentence "In C, ..." started on a new paragraph.

-Reason:* better formatting, bad readability due to otherwise unfilled lines due to long constant names at end of line.

-Chap. 7. Toplogies*

MPI-2.1 p250:45, Ticket #42:

Solution was not modified, but Extended Scope "MPI-2.1 Errata" was removed.

-Reason:* to keep the MPI-2.1 Errata page small (only one page).

MPI-2.1 p252:5, end of new text from Ticket #3):

"edges[index[rank-1]] to edges[index[rank]-1]" instead of[[BR]]
"edges[index[rank-1]] to edges[index[rank]]"

-Reason:* Without "-1", the text would be wrong.

-Chap. 11. One-sided*

MPI-2.1 p323:38-39 and Ticket #53:

The sentence "Implementors should document ..." is kept as a own paragraph
and not added as last sentence in the paragraph before.

-Reason:* The concatenation of the two paragraphs may not be intented
by the Forum and overseen in the review process.

(That is all that I have been somehow involved)

mpiforumbot · 2016-07-23T22:19:02Z

Originally by gropp on 2009-07-16 15:32:24 -0500

I view the fix for edges[rank-1] etc. to be a simple correction; further, the correction is essential because the text on which we voted was clearly wrong (though not clearly enough for the reviewers :) ).

This change does not require a vote (other than the final votes on the full chapter).

mpiforumbot · 2016-07-23T22:19:03Z

Originally by traff on 2009-07-17 08:30:30 -0500

I have updated the ticket and the pdf. Reviewer's, please have a look

mpiforumbot · 2016-07-23T22:19:03Z

Originally by traff on 2009-07-17 08:34:54 -0500

question on formatting: the line of second bullet-point is too long; where
would be the correct place to put the line-break? before or after edges[index[rank]-1]?

mpiforumbot · 2016-07-23T22:19:04Z

Originally by htor on 2009-07-17 13:20:20 -0500

Reviewed: OK

mpiforumbot · 2016-07-23T22:19:04Z

Originally by jsquyres on 2009-07-20 13:07:16 -0500

PDF review: ok

My $0.02: I'd put the line break before the entire term "edges[index[rank]-1]".

mpiforumbot · 2016-07-23T22:19:04Z

Originally by RolfRabenseifner on 2009-07-21 06:33:35 -0500

PDF review: okay, but I would also prefer a line break before the first term "edges[index[rank-1]]".

This linebreak should be done with {\gb{...}},
i.e., topol.tex, line.699:
[[BR]]
\mpifunc{MPI\_GRAPH\_NEIGHBORS} will be {\gb{\tt edges[index[rank-1]]}}

mpiforumbot · 2016-07-23T22:19:05Z

Originally by traff on 2009-07-21 06:54:29 -0500

Agreed, and done

mpiforumbot · 2016-07-23T22:19:05Z

Originally by traff on 2009-07-21 06:54:57 -0500

Attachment added: ticket3.pdf (34.7 KiB)

mpiforumbot · 2016-07-23T22:19:06Z

Originally by RolfRabenseifner on 2009-07-21 07:12:12 -0500

PDF-review and ticket-review (i.e., the modification since 2nd vote): both okay.

mpiforumbot · 2016-07-23T22:19:06Z

Originally by gropp on 2009-07-22 11:08:25 -0500

WDG - Reviewed and complete.

mpiforumbot · 2016-07-23T22:19:07Z

Originally by traff on 2009-08-30 06:05:50 -0500

As chapter editor, I took the liberty to set this to "complete" (ok, jeff?)

mpiforumbot · 2016-07-23T22:19:08Z

Originally by jsquyres on 2010-09-18 04:56:21 -0500

This ticket is (long-since) complete; marking it closed.

mpiforumbot self-assigned this Jul 23, 2016

mpiforumbot added this to the 2009/06/08 California milestone Jul 23, 2016

mpiforumbot added Text (only) changes Ticket complete MPI 2.2 Text committed labels Jul 23, 2016

mpiforumbot modified the milestones: 2008/12/15 Menlo Park, 2009/06/08 California Jul 23, 2016

mpiforumbot added Waiting for PDF reviews and removed Passed labels Jul 23, 2016

mpiforumbot added Ticket complete and removed Waiting for PDF reviews labels Jul 23, 2016

mpiforumbot closed this as completed Jul 23, 2016

Repeating a Neighbor in a Graph Communicator Ambiguity with MPI_GRAPH_NEIGHBOR[_COUNT] #3

Repeating a Neighbor in a Graph Communicator Ambiguity with MPI_GRAPH_NEIGHBOR[_COUNT] #3

Comments

mpiforumbot commented Jul 23, 2016 • edited Loading

Description

History

Proposed Solution

Impact on Implementations

Impact on Applications / Users

Alternative Solutions

Entry for the Change Log

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

Description

History

Proposed Solution

Impact on Implementations

Impact on Applications / Users

Alternative Solutions

Entry for the Change Log

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016

mpiforumbot commented Jul 23, 2016 •

edited

Loading