Remaining 4.0-RC issues found in chap-coll

[jaegerj]

Problem

Here are the remaining issues found in the 4.0-RC in chap-coll

These should all be chapter committee changes.

The pages/lines reported below are updated to the official MPI 4.0 release

• Subsection title "Gather-to-all" Sec. 6.7: Why not "All-Gather" while we have "All-Reduce" at Sec.6.9.6
• p241, l.44: I think there should be a blank line before the sentence "Reduction operations can be queried for their commutativity."
• p301 l.34): "... so that deadlock will not occur, ..." -> "... so that no deadlock will occur, …"
• p303 l.9: "should" -> "must" was used in all examples before.
• p245 l.31: Add a space after == to have recvcounts[i] == 0 instead of recvcounts[i] ==0
• LIS for MPI_Iscan, MPI_Ireduce, MPI_Iallreduce, MPI_Iexscan (and their counterparts): The count is also the size of recvbuf but can be implied when reading collective descriptions.
• p303 l.32-33: "after the broadcast, and process 2" -> "after the broadcast and process 2" (comma?)
• p303 l.36-38: “This example illustrates the fact that one should not rely on collective communication functions to have particular synchronization effects.” I'm tempted to add "other than MPI_Barrier" somewhere.
• p278 l.11 (and other persistent collective initialization procedures): When describing each persistent collective there is a small sentence like "Creates a persistent collective communication request for the XXX operation". It would have been convenient to add a back-reference to the corresponding collective just as nonblocking collectives (e.g., p253 l.42 for MPI_IBCAST).
• p235 l.34-36: The advice to implementors here is a duplicate of the text before it.
• p236, l.15-35 - Should this be an official "example" as opposed to a code block?
• P231 Example 6.18: Can one use a derived type for Fortran? This would save space.

References and Pull Requests

none yet