BCDFGHKMNOPQRSUVWXYZ
1
ChapterOwnerReviewerPRIssueDoneDocPageLineFlowEditorMPI 4.1MPI 4.2RejectWhatComments / Discussion / Resolution
2
FRONAmitIXXPage 1 : Would it be more appropriate to rewrite "Message Passing Interface Forum" as "Message-Passing Interface Forum"In 1992, it would have been. But this is the proper name and should not be changed.
3
AmitII45XXPage 2, Line 45 : Should we rewrite "University of Tennessee" as " The University of Tennessee"The proper name is just University of Tennessee.
4
AmitIII45XXPage 3, Line 45 : Not a comment, but surprised that version 2.0 came much before version 1.3, as stated on line 40The updates were on independent approval paths
5
AmitIII45XXPage 3, Line 45 : Can we state clearly why version 2.0 and 1.2 (Page 4, Line 4) were released on the same date as July 18, 1987We voted for them at the same meetings, and tried to get them finished together. I don't think this is necessary for the standard document
6
AmitIV21XXPage 4, Paragraphs at Lines 21 and 24 : Delete the paragraphsThese are part of the original text, and all of these descriptions have been left unchanged. We could rewrite the older ones, but that would be a more significant (not 4.1) update
7
AmitXIIIXXPage 13, Tools Support: Should we restate the title as "Tools" rather than "Tools Support". We don't have a "Support" suffix in the I/O chapter as well.This is the chapter title, taken automatically from that chapter. Also, I believe this is more accurate - the purpose of this chapter is to support tool development (especially the original profiling interface), whereas the I/O chapter support I/O directly.
8
AmitXIVXXPage 14 Deprecated Interfaces: Does "Host Rank" has the correct heading format?Yes it is in the correct format, because it is the topic, not a particular MPI item (e.g., not the keyval)
9
AmitXXII16XXPage 22 Line 16-17, Delete the line (the previous lines have already said it) "During the period of development of the Message-Passing Interface (MPI), many people helped with this effort"I disagree. The previous lines talked about subgroups, not the number of members that worked on those groups.
10
AmitXXII22XXPage 22, Line 22 (and several others like this). Should we replace ',' in "Jack Dongarra, David Walker, Conveners and Meeting Chairs" to a ':"We could, but in reviewing all of the places that the current format (using commas) is used, I think this is clear as is.
11
Aurelien923802XXXVI14XPg36 (xxxvi) l14: Isaias Alberto Compres Urena: has inconsistent accents with pp 40 l17Updated, but these really should be done only if the person named requests it.
12
AurelienXL1XXPg 40 (xl) l1: Pedram Mohammadalizadehbakhtevari: looks like name is missing spacesThis is what I received in the list of names.
13
AurelienXL12XXPg 40 (xl) l12: AmirHossein: looks like name is missing spacesThat's how it looks on his web page https://amirsojoodi.github.io/
14
Chap01Benson803324XXMPI_RECV on line 4 of pg 32 could be moved to the end of line 3 of pg 32Claudia: it's "Flow", but page 32 belongs to Chap03 ;)
15
INTROBenson923802537XThe acronym MIMD - Multiple Instance, Multiple Data is not expanded the first time MIMD is used on pg 5 line 37 (same for SIMD, MPMD)Claudia: The standard uses MIMD on pages 5, 25, 326, 1072 (Ref [50]) and MPMD on page 519, SPMD is on pages 5, 41, 519, 542 while SIMD is never used, all of them are never expanded, think this would qualify for "Editor"
16
Chap02Victor9238029XPage 9 line 46: Why initial cap? Action words never have an initial cap.Claudia: good catch and actually I think Victor is right and action words should not have an initial cap - on the other hand it has been with initial cap since the very beginning - this seems to concern the bold words on page 9 lines 46-48 and page 10 lines 1-4 only, think this would quaify for "Editor"
17
TERMSClaudia9238021116X“Fortran” in this document refers to Fortran 90 and higher; see Section 2.6
--> write “Fortran 90 or later” to be consistent with page 22		Claudia: page 11 line 16 instead of "Fortran 90 and higher" write "Fortran 90 or later" to be consistent with page 22 line 33, think this would qualify for "Editor"
18
Claudia8031241XAdditionally, an MPI operation can be collective or noncollective.
--> Can we have some vertical space above this sentence (and maybe a \noindent), it starts discussing a new idea (”subsection”).
19
Claudia1243XXCollective operation: A set of related operations, one per MPI process in a group or groups of MPI processes.
--> Collective operations are a set... 		Claudia: page 12 line 43 - write as a whole sentence & consitent with page 13 line 10, think this would qualify for "Editor". BillG: But this is following the convention above on the same page. I'm leaving it as is.
20
Claudia80312XFigure 2.3 should be on page 12 (instead of page 13) to have the 3 figures and the description in the text on the same page
21
Claudia1310XXNoncollective operation: Noncollective operations are... --> write in a consistent style with aboveClaudia: page 13 line 10 - write consitent with page 12 line 43, think this would qualify for "Editor". BillG: As for collective, this is following the convention in this block of text.
22
Claudia9238021320XEnabled An MPI operation... --> “Enabled:”Claudia: it's just a missing ":", think this would qualify for "Editor"
23
Claudia8031435XThe following are properties of MPI operation-related procedures:
--> Can we have some vertical space above this sentence (and maybe a \noindent), it starts discussing a new idea (”subsection”).		Claudia: this is "Flow" or "Editor"
24
Benson2233X`MPI bindings are for Fortran 90 or later...` should this be `MPI bindings are for Fortran 90 and for Fortran 2008 or later...`Claudia: "Fortran 90 or later" is a catch all and I suggest to leave it as it is for MPI 4.1. In the standard we would never talk about Fortan 2008 alone, it was Fortran 2008 with TS 29113 and now it would be Fortran 2018 and later. The whole Fortran story will change again with Jeff's PRs for the ABI.
25
Claudia2321X2.6.2 Fortran Binding Issues
Originally, MPI-1.1 provided bindings for Fortran 77. These bindings are retained, but they are now interpreted in the context of the Fortran 90 standard. MPI can still be used with most Fortran 77 compilers, as noted below. When the term “Fortran” is used it means Fortran 90 or later; it means Fortran 2008 with TS 29113, which is now an integral part of Fortran 2018 and later if the mpi_f08 module is used.
--> add a comma “later, ...”
or even better rewrite the last part of the sentence: “if the mpi_f08 module is used it means Fortran 2008 ...”		Claudia: think this would qualify for "Editor". BillG: I think the CC should rewrite this text; that goes beyond the editor role at this stage in the process
26
Benson23XXMay want to have Table 2.1 one page earlier on pg 23 where it is first mentioned rather than no pg 24Claudia: yes fully agree; BillG: Moving the table one page up will cause it to appear before the reference to it. The convention is to (to the extent possible) have tables and figures appear after a reference to them - on the same page *if possible*, otherwise on the next page.
27
Claudia23XX(May want to have Table 2.1 one page earlier on pg 23 where it is first mentioned rather than on p 24)
--> Table 2.1 should be on page 23 (instead of page 24)		Claudia: same as line 26 above. BillG: (DUPLICATE)
28
Benson253XMay want to indicate an example mpi.h header file is provided with the standard.Claudia: the header files are part of an implementation not part of the standard
29
Claudia253X2.6.3 C Binding Issue ...
The definition of named constants, function prototypes, and type definitions must be supplied in an include file mpi.h. (May want to indicate an example mpi.h header file is provided with the standard. p 25 line 3)
--> ?		Claudia: same as line 28 above
30
Benson2524XX`an MIMD style` should probably be `a MIMD style` pg 25 line 24Claudia: yes fully agree, think this would qualify for "Editor"
From my non-native English viewpoint the a/an depends on pronounciation and whether the acronym is pronounced as a whole word or as a sequence of letters, so for me it would be "a MIMD" but "an MPMD". BillG: Tough call. Some say Em-eye-em-dee, so "an" is correct; others say "mimdee", so "a" would be correct. I'm sticking with an.
31
Chap03Dan908791X3322X“returned in the detach procedure. The value returned” ->“returned in the detach procedure and the value returned”
32
P2PDan908791X3330XThese procedure will block until” -> “These procedures will delay their return until
33
Dan/Benson3548XXWidow/orphan control for footnote from page 34 , the footnote `extensions commonly accepted by Fortran compilers.` on line 48 of pg 35 is a continuation from page 34, maybe it is better line 48 of pg 35 is a continuation from page 34, maybe it is better to have multiline footnotes so that they are on the same page.BillG: While not great, splitting a minor footnote across two pages is less bad than the alternatives. And a minor change in the text will cause the footnote to fit on a single page.
34
Dan908791X3615XExample 3.12 exhibits incorrect formatting
35
Benson803324XMPI_RECV on line 4 of pg 32 could be moved to the end of line 3 of pg 32Added a bit out of order, replacing a duplicate item
36
Bill W.491XXEnd of page 90/beginning of page 91: the punctuation/whitespace/capitalization/page break combo here is weird and unfortunate. "We use the following terminology. <page break> <lowercase bold unbulleted definition list" would read better as "<force page break>We use the following terminology: <line break> ..."BillG: The page break can't go before the "We" in "We use the ..." because that is in the middle of a paragraph. I think any fix here will make it worse (creating a widow or orphen from the paragraph).
37
Bill W.57XPage 99, "This is illustrated by the examples below." I prefer specific example numbers, especially when it's not clear from the text to what extent 3.8/3.9 as well as 3.10 are intended targets of "below". (Aside: example 3.9 is simply confusing, not in the sense of what it illustrates but why it's present, given the surrounding text; the 3.8/3.10 juxtaposition is well explained and motivated and 3.9 is just...there. Probably not an RC-level fix though.)
38
Bill W.8036333XPage 105, lines 33-35: I was expecting a clearer visual break between the detach and flush families of functions. Should there be whitespace? Have we omitted a (sub^n)section label that should be there?BillG: A better fix might be a sub^n section label. In the short term, I've added the same vertical space I'm using for similar issues in the text.
39
Bill W.6721XXPage 109, lines 21-22, whitespace is unfortunate. Not sure what we can do to fix.BillG: The only way to fix this is to re-write the text. What is here follows the document convention of never hyphenating a routine name.
40
Bill W.908791X689XPage 110, line 9: "case of *an* attached buffer"
41
Bill W.908791X6810Xline 10: "as *would be required* if"
42
Bill W.908791X6839Xline 39: "following code:"; also "pseudocode", "algorithm", or even "steps" would IMO be more accurate here
43
Bill W.908791X6844Xline 44: "number of bytes, n"
44
Bill W.908791X702XPage 112, line 2: I thought "High-quality implementation(s)" was the term of art
45
Brian908791X7837X78 line 37 - “locations In the send buffer” sounds weird. Maybe "data" instead of locations?
46
Brian802X80 line 2 - use of “we”Dan: I’m going to reject row 46 “use of ‘we’” because it is one of many occurrences and every instance requires re-wording to remove “we” (if that is even what we want). We got rid of *gendered* pronouns, but getting rid of *all* pronouns is different, possibly not a bad idea, but definitely a newly-proposed idea
47
Brian908791X8035X80 35 and 39 - "associated operation" maybe "operation associated with the request"?
48
Brian80XExample 3.14 is “strongly discouraged” in the text above so why do we have an example showing it??? (freeing the isend request before waiting). Is it not active at that point still?
49
Brian80XExample 3.15 - why add MPI_ANY_TAG there? It's not necessary and not explained.
50
Brian10243X102 - 43 - should request be different font? It’s the specific request variable is it not?Dan: I also suggest that Bill rejects row 50 “page 102 line 43 should request be different font” because the text is talking about the request, not the handle to the request.
51
Brian10313X103 - line 13 - talking about deprecated send behavior. Very ackward text. Should this move to an advice maybe and get slightly rephrased?Dan: I’m also going to reject row 51 “page 103 line 13 should this [normative text] move to an advice?” because we should debate that for MPI-4.2 or later. The outcome of that discussion will be that no, we should not make it only advice, but maybe we can re-word it a bit.
52
Brian104X104 - advice to implementers does not mention send cancel is deprecated (unlike every other place we discuss send+cancel)
53
Chap04Discussion113xXErrata pr Fix now (if we decide this is what we want) -> add _c also for new functions / esp. Partitioned inits
54
PARTITIONChrstoph
https://github.com/cniethammer/mpi-standard/tree/PRE-4.1-review_CN_pp108-138
1152Xxx- p.115, l.2: Example 8.4: partitions of type int - not MPI_Count [Errata?]
55
Chrstoph
https://github.com/cniethammer/mpi-standard/tree/PRE-4.1-review_CN_pp108-138
116X- p.116, (errata?) MPI_PSEND_INIT needs (_C) version that matches partitioned collectives
56
Chrstoph
https://github.com/cniethammer/mpi-standard/tree/PRE-4.1-review_CN_pp108-138
117X- p.117, (errata?) MPI_PRECV_INIT needs (_C) version that matches partitioned collectives
57
Chrstoph
https://github.com/cniethammer/mpi-standard/tree/PRE-4.1-review_CN_pp108-138
11815X- p.118, l.15: info should be set as \mpiarg here
58
Chrstoph
https://github.com/cniethammer/mpi-standard/tree/PRE-4.1-review_CN_pp108-138
11831X- p.118, l.31: info should be set as \mpiarg here
59
Chrstoph
https://github.com/cniethammer/mpi-standard/tree/PRE-4.1-review_CN_pp108-138
1195Xp.119, l.5-12: Pready indicates readiness of transfer for a partition -> inconsistent with partition is "in-/active", should use common language especially as actice is used as a term for MPI operations
60
Chrstoph
https://github.com/cniethammer/mpi-standard/tree/PRE-4.1-review_CN_pp108-138
12110X- p.121, l.10: use \code for "= true" '/ is inside \mpiarg
61
Chrstoph
https://github.com/cniethammer/mpi-standard/tree/PRE-4.1-review_CN_pp108-138
12117X- p.121, l.17: prevent linebreak inside expression "flag = true"
62
Chrstoph
https://github.com/cniethammer/mpi-standard/tree/PRE-4.1-review_CN_pp108-138
12218xx- p.122, l.18: count should be of type MPI_Count as in the c-API declaration
63
Chrstoph
https://github.com/cniethammer/mpi-standard/tree/PRE-4.1-review_CN_pp108-138
12333xx- p.123, l.33: count should be of type MPI_Count as in the c-API declaration
64
Chap05Chrstoph
https://github.com/cniethammer/mpi-standard/tree/PRE-4.1-review_CN_pp108-138
12745X- p.127, l.45: prevent page break in the middle of \termdef{type map}
65
DATATYPEChrstoph923
https://github.com/cniethammer/mpi-standard/tree/PRE-4.1-review_CN_pp108-138
1285X- p.128, ll.5+8+12 + rest of chapter: Word spacing of Typemap and Typesig are strange. Use \textrm{\itshape{Typemap}}It may be that the words in these math formulas should be set as simply \textrm{xxx}, rather than retaining the italics shape.
66
Chrstoph
https://github.com/cniethammer/mpi-standard/tree/PRE-4.1-review_CN_pp108-138
13142X- p.131, l.42: duplicate "the"
67
Claudia1595Xfor the extent it sometimes says "extent" (e.g., page 201/159 lines 5-8) and sometimes "ex" (e.g., page 184/142 line 43, page 185/143 lines 1-13) - it's always clear what it means, but inconsistent
68
Claudia167Xthe Examples and code snippets for Fortran sometimes use "ierr" (e.g., Example 5.7, 5.10, 5.11) and sometimes "IERROR" (e.g., Example 5.8, code snipped on the bottom of page 209/167 and top of page 210/168) - it's always clear what it means, but inconsistent
69
Dan80316848Xp210 line 48, it would be better to have the page break before the orphaned line "MPI_COMBINER_INDEXED ..."BillG: I've inserted filbreak in a few places. This should be ok (filbreak is only a suggestion to break), but isn't perfect - it may result in a page break where not intended.
70
Dan80316945Xp211 line 45, it would be better to have the page break before the orphaned line "MPI_COMBINER_DARRAY ..."BillG: I've inserted filbreak in a few places. This should be ok (filbreak is only a suggestion to break), but isn't perfect - it may result in a page break where not intended.
71
Dan172Xp214 Example 5.16 title, all other example titles end with "." but this one ends with ":" for no good reason.
72
Dan175Xp215&216 Example 5.17 body, there are double blank lines before some code comments but single blank lines before others; consistency (preferably, single blank line) would look better.
73
Dan17614Xp217 line 14 Example 5.17 body, the indentation of the comment line is one char too few to line up with the comment in the line above.
74
Dan1771Xp219 line 1 Example 5.19 body, the code comment ends with a "." (none of the other comments so far do) and it is a widowed line.
75
Dan17716Xp219 line 16 Example 5.20 title, the spacing from "5.20." to "This" looks bigger than it should be when comparing with other examples.
76
Dan17720Xp219 line 20 Example 5.20 body, the first line of this code comment ends with a "." but the other does not; most code comments so far in this section do not end with "."
77
Dan17723Xp218 line 23 Example 5.18 body, the code comment is missing the trailing space before the close comment symbols.
78
Dan17740Xp219 line 40 Example 5.20 body, the last line of this code comment ends with a "." but most of the other code comments so far in this section do not end with "."
79
Dan177Xp219&220 Example 5.20 body, this example feels cramped compared with the previous examples because it has almost no blank lines.
80
Dan1783Xp220 line 3 Example 5.20 body, the spacing before "malloc" is inconsistent with the previous code line; the choice of line break location is inconsistent with the following code line.
81
Dan17820Xp220 line 20 Example 5.20 body, the text "... other combiner values ..." should be a code comment, rather than a syntax error.
82
Dan17844Xp219 line 44 Example 5.20 body, the text "... else test for other types ..." should be a code comment, rather than a syntax error.
83
Dan1808Xp222 line 8 param "outcount" is described as "(integer)" -- are negative values allowed? The converse "incount" param from MPI_PACK is described as "(non-negative integer)".
84
Dan1817Xp223 line 7 text "the count argument" but the argument name is actually "outcount".
85
Dan18334Xp225 line 34 Example 5.22 body, the code comment is missing the trailing space before the close comment symbols.
86
Dan18543Xp227 lines 43, 47, and 48 these three "(integer)" parameters should probably be "(non-negative integers)"
87
Derek92380222832XThe page number reference on Document page 228, line 32 is wrong (it should be page 842). It looks like it is going to the same reference as "19.3.6", probably which is probably why it says 840. Maybe we could just drop the specific page reference as a whole?This is one reason that I'm opposed to referring to page numbers in the text - these will go to where the label is (or was the last time LaTeX ran). That can make sense for a section (though rarely helpful if you are using the PDF - you can just jump to the section), but they are *wrong* if the jump is to a spot within a section, unless a special label is created.
88
Dan18643Xp228 lines 43, 44, and 47 these three "(integer)" parameters should probably be "(non-negative integers)"
89
Dan18742Xp229 lines 42 and 44 these two "(integer)" parameters should probably be "(non-negative integers)"
90
Chap06Dan18923Xp231 line 23 there is a spurious ", " after "MPI_GATHERV_INIT"
91
COLLTonyDiscussion189xThis call starts a nonblocking variant of MPI_BCAST (see Section 6.4).
-> should be This call initiates a non
-> make it italic to be a term
-> try for MPI 4.1, but could punt for MPI 4.2
-> Tony is doing ticket
92
Tony915797X19746XEditorial fix on one example line with redundant (old) statement should be removed. [Line 484 of chap-coll.tex should be deleted. Line 46 on Page 197 of RC doc.]
93
Derek201XIn GatherV's description on Document page 201, line 27, it uses both "i" and "j" in the MPI_Recv explanation. I think this is wrong, and only one should be used here. Further, I think the text should match the variable used; either use only "i" or only "j". The API description of GatherV uses "i", so that's my personal vote here.
94
Derek210XXA couple of example codes are "1 line too long", and that last line spills on to the next page. These would be easy to fix right NOW (remove a blank line from the example, tweak some text to be shorter, etc), but if anyone else tweaks anything before this section, the figures might shift and make these figures fine, but mess up other figures. I am noting the examples I found, but if it's a "non-issue/won't fix", I totally understand :) 207/Ex6.10 and 212/Ex.6.12BillG: These are hard to fix. Changing the example is a CC thing.
95
Derek215XDocument Page 215, line 16/17 - Allgather description uses "j", but never "i". Technically not wrong, but I think using "i" would be more consistent
96
Derek217XDocument Page 217, lines 7-11 - AllgatherV description also features only "j", but this time the description of the API uses "i"
97
Edgar80323423XExample 6.20, page 276 (234): the comments in line 23, 31, and 34-35 do not start in the same column as the following code. In the vast majority of the examples in MPI document the comment is typically started in the same columns as the code block that it is part of.
98
Guillaume2391XX- two sentences that might require a full stop at the end ( page 281 line 1; page 296 line 28)This is a subsubsection. I plan to change the font of these to make it clear that this isn't regular text
99
Guillaume915797X259XRank/process - p 259, for the description of sendcounts in MPI_Iscatterv
100
Guillaume915797X264XRank/process- p 264, for the description of sendcounts and recvcounts in MPI_Ialltoallv, note that these descriptions are not consistent with the ones used in MPI_Ialltoall