Comments on the MPI standard should be mailed to mpi-core@mpi-forum.org. Page and line numbers refer to the official MPI-2 document, not the HPCA issue or the 2nd edition of the Complete Reference.
Useful links:
This needs more discussion. The problem is that some of the C++
datatypes have no easily defined counterparts in C or Fortran. The
minimum fix is really a clarification that says that there is no
interlanguage support for the C++ complex types.
Proposed text
MPI-2, page 276, after line 4, addExtending the C++ datatypes to C and Fortran needs to include MPI::BOOL as well as the complex types, and should define what the equivalent types are in C and Fortran. The real issue here is the MPI:F_COMPLEX and completing the list of such routines.
Advice to users.
Most but not all datatypes in each language have corresponding datatypes in other languages. For example, there is no C or Fortran counterpart to the MPI::BOOL or the the MPI::COMPLEX, MPI::DOUBLE_COMPLEX, or MPI:LONG_DOUBLE_COMPLEX. End of advice to users.
MPI-2, page 164, line 16-30 should read:
7.3.5. Generalized All-to-all Functions
One of the basic data movement operations needed in parallel signal processing is the 2-D matrix transpose. This operation has motivated two generalizations of the MPI_ALLTOALLV function. These new collective operations are MPI_ALLTOALLW and MPI_ALLTOALLX; the ``W'' indicates that it is an extension to MPI_ALLTOALLV, and ``X'' indicates that it is an extension to MPI_ALLTOALLW. MPI_ALLTOALLX is the most general form of All-to-all. Like MPI_TYPE_CREATE_STRUCT, the most general type constructor, MPI_ALLTOALLW and MPI_ALLTOALLX allow separate specification of count, displacement and datatype. In addition, to allow maximum flexibility, the displacement of blocks within the send and receive buffers is specified in bytes. In MPI_ALLTOALLW, these displacements are specified as integer arguments and in MPI_ALLTOALLX they are specified as address integer.Rationale. The MPI_ALLTOALLW function generalizes several MPI functions by carefully selecting the input arguments. For example, by making all but one process have sendcounts[i] = 0, this achieves an MPI_SCATTERW function. MPI_ALLTOALLX allows the usage of MPI_BOTTOM as buffer argument and defining the different buffer location via the displacement arguments rather than only via different datatype arguments. (End of rationale.)
Add to page 165, after line 38:
MPI_ALLTOALLX(sendbuf, sendcounts, sdispls, sendtypes, recvbuf, recvcounts, rdispls, recvtypes, comm)
- [ IN sendbuf]
- starting address of send buffer (choice)
- [ IN sendcounts]
- integer array equal to the group size specifying the number of elements to send to each processor (array of integers)
- [ IN sdispls]
- integer array (of length group size). Entry j specifies the displacement in bytes (relative to sendbuf) from which to take the outgoing data destined for process j (array of integers)
- [ IN sendtypes]
- array of datatypes (of length group size). Entry j specifies the type of data to send to process j (array of handles)
- [ OUT recvbuf]
- address of receive buffer (choice)
- [ IN recvcounts]
- integer array equal to the group size specifying the number of elements that can be received from each processor (array of integers)
- [ IN rdispls]
- integer array (of length group size). Entry i specifies the displacement in bytes (relative to recvbuf) at which to place the incoming data from process i (array of integers)
- [ IN recvtypes]
- array of datatypes (of length group size). Entry i specifies the type of data received from process i (array of handles)
- [ IN comm]
- communicator (handle)
int MPI_Alltoallx(void *sendbuf, int sendcounts[], MPI_Aint sdispls[], MPI_Datatype sendtypes[], void *recvbuf, int recvcounts[], MPI_Aint rdispls[], MPI_Datatype recvtypes[], MPI_Comm comm) MPI_ALLTOALLx(SENDBUF, SENDCOUNTS, SDISPLS, SENDTYPES, RECVBUF, RECVCOUNTS, RDISPLS, RECVTYPES, COMM, IERROR) <type> SENDBUF(*), RECVBUF(*) INTEGER SENDCOUNTS(*), SENDTYPES(*), RECVCOUNTS(*), RECVTYPES(*), COMM, IERROR INTEGER (KIND=MPI_ADDRESS_KIND) SDISPLS(*), RDISPLS(*) void MPI::Comm::Alltoallx(const void* sendbuf, const int sendcounts[], const MPI::Aint sdispls[], const MPI::Datatype sendtypes[], void* recvbuf, const int recvcounts[], const MPI::Aint rdispls[], const MPI::Datatype recvtypes[]) const = 0Add to page 312, after line 37:
int MPI_Alltoallx(void *sendbuf, int sendcounts[], MPI_Aint sdispls[], MPI_Datatype sendtypes[], void *recvbuf, int recvcounts[], MPI_Aint rdispls[], MPI_Datatype recvtypes[], MPI_Comm comm)Add to page 322, after line 45:
MPI_ALLTOALLx(SENDBUF, SENDCOUNTS, SDISPLS, SENDTYPES, RECVBUF, RECVCOUNTS, RDISPLS, RECVTYPES, COMM, IERROR) <type> SENDBUF(*), RECVBUF(*) INTEGER SENDCOUNTS(*), SENDTYPES(*), RECVCOUNTS(*), RECVTYPES(*), COMM, IERROR INTEGER (KIND=MPI_ADDRESS_KIND) SDISPLS(*), RDISPLS(*)Add to page 335, after line 19:
void MPI::Comm::Alltoallx(const void* sendbuf, const int sendcounts[], const MPI::Aint sdispls[], const MPI::Datatype sendtypes[], void* recvbuf, const int recvcounts[], const MPI::Aint rdispls[], const MPI::Datatype recvtypes[]) const = 0
This section contains the discussion on these ambiguities and in cases where a consensus emerged, text has been proposed.
Does MPI_ALLOC_MEM return a null pointer when a request for memory cannot be satisfied but a request for a smaller amount may work? The question is really if the user must set MPI_ERRORS_RETURN on MPI_COMM_WORLD before calling MPI_ALLOC_MEM if the user wants to handle "not enough memory for your request" errors.
This may be appropriate for an advice to users, reminding them of the need to set the error handler.
Some names in the MPI Namespace in the C++ binding can conflict with C preprocessor names in standard include files. Examples include MPI:SEEK_SET} (conflicts with SEEK_SET in stdio.h).
There are two different proposals. The Forum should decide, which one is better.
Proposal A
Add in MPI-2.0, page 88, after line 24:
Advice to users. If the non-root processes do not use MPI_ERRCODES_IGNORE, then they have to allocate the appropriate number of entries (see maxproc at root) in the array_of_errcodes although the maxproc argument is unused in non-root processes. It is allowed to use an array_of_errcodes at some of the calling processes and MPI_ERRCODES_IGNORE at some others. (End of advice to users.)
Rationale for this clarification:
It was not clear that maxproc is significant as input argument only at root while it is needed at all processes to define the length of array_of_errcodes. It was not explicitly forbidden that MPI_ERRCODES_IGNORE is used only at some processes. And there isn't a general rule that all arguments must be the same.
Proposal B
MPI 2.0 page 84 line 45 reads (in MPI_COMM_SPAWN):
OUT array_of_errcodes one code per process (array of integer)
but should read:
OUT array_of_errcodes one code per process (array of integer,
significant only at root)
MPI 2.0 page 89 line 42 reads (in MPI_COMM_SPAWN_MULTIPLE):
OUT array_of_errcodes one code per process (array of integer)
but should read:
OUT array_of_errcodes one code per process (array of integer,
significant only at root)
Comment: This proposal modifies the MPI interface. User codes may be broken. Another reason, not to do this modification, is that the non-root processes have no chance (in error-return-mode) to detect an error. And after an error, MPI does not guarantee that MPI communication still works. Only MPI_Abort should be guaranteed to work.
The bindings for predefined types such as MPI::CHAR are const which was fine for MPI-1 but may be inappropriate in MPI-2 since datatypes have names and attributes, both of which can be set.
In addition to changes for MPI::Datatype, add these changes
In the second ballot, we voted to remove const from MPI::Datatype on pages 343, 344, and 345.
If the decision in Change "INOUT" to "IN" for MPI Handle Parameters in several routines is
See also
Mail discussing
of static const in C++ specification of predefined MPI objects
and
Mail discussing
of Use of const,
and
Mail discussing
of Change "INOUT" to "IN" for MPI Handle Parameters in several routines.
See also
Mail discussing
of const in C++ specification of predefined MPI objects (was just datatypes)
and
Mail discussing
of Use of const.
MPI_File_get_view return copies of the datatypes for
the filetype and etype?
The question really is "can (and must) the user free those datatypes"? For other MPI routines, the answer is always yes, but here the original datatype may be a predefined type, which may not be freed.
The request for clarification is related to a multi-threaded execution with concurrent completion of a request in one thread and canceling of the same request in another thread.
MPI_Waitall) with a count of zero
No specific proposal yet.
The text added in MPI 1.1 on the error return for MPI_Waitall etc. is written as if the only error handler is MPI_ERRORS_RETURN.
Status: The authors of the discussion are asked for a proposal. (Pending)
The ISO/IEC Standard for C has added a number of new required and optional datatypes, such as int32_t and _Bool.
const
Add const to the C binding of MPI routines.
See also discussion of const for COMM_WORLD and COMM_SELF.
See also
Mail discussing
of const in C++ specification of predefined MPI objects (was just datatypes)
and
Mail discussing
of static const in C++ specification of predefined MPI objects.
In brief, in some cases when using dynamic processes, an application may need to know when a process, recently disconnected with MPI_Comm_disconnect, has exited. There is no easy way within MPI to do this since MPI_Comm_disconnect doesn't wait for the process to exit (and it shouldn't, of course).
MPI_Reduce_scatter
This proposes an extension to MPI to add a constant block-size version of
MPI_Reduce_scatter, much as MPI-2 added
MPI_Type_create_indexed_block. This allows implementations to
optimize the implementation of this routine. Several uses of
MPI_Reduce_scatter with constant block sizes have recently been
discussed at the Euro PVMMPI meetings.
Status: The authors of the discussion are asked for a proposal. (Pending)
The example appears to make use of data before the necessary
MPI_Win_complete is called to end the exposure epoch.
The use of integers (and even address-sized integers) in MPI routines such as the point-to-point routines and datatype creation can limit the (at least with the natural choice of arguments) size of message that may be sent. Some MPI users now want to send messages greater than 2 GB; the use of MPI datatypes to describe file layouts can also run into trouble on 32-bit systems.
MPI_Type_size returns size as an int:
This is a perenial erratum. However, with file types used for file views, it is not only possible but likely that datatypes will be (in fact, have been) constructed with a size that is greater than 2GB (range of a signed 32-bit int). Since we don't want to change MPI_Type_size, do we need another routine (and deprecate MPI_Type_size)?
This proposes a form of non-blocking connect and accept.
This proposes to remove the restriction that the user may not access a send buffer that is used in a nonblocking send operation
This asks about the reasoning behind the restriction noted in the MPI standard, and may suggest either the addition of a rationale or dropping the restriction.
This proposal suggests a variation on Exscan that also returns the final result (as if an Allreduce was performed with the same data).
This proposal suggests additional operations to support segmented scans and similar computations.
There is a inconsistency between the INOUT description for handle arguments, and their usage in the language independent definitions of MPI-1.1 and MPI-2.0. There are 3 possibilities to solve this. The MPI Forum should decide, which possibility is the best.
Alternative A: (This proposal was chosen by the MPI Forum in the March 2008 meeting)
Proposal: MPI 2.0 Sect. 2.3 Procedure Specification, page 6 lines 30-34 read:
There is one special case - if an argument is a handle to an opaque object (these terms are defined in Section 2.5.1), and the object is updated by the procedure call, then the argument is marked OUT. It is marked this way even though the handle itself is not modified - we use the OUT attribute to denote that what the handle references is updated. Thus, in C++, IN arguments are either references or pointers to const objects.but should read:
There is one special case - if an argument is a handle to an opaque object (these terms are defined in Section 2.5.1), and the object is updated by the procedure call, then the argument is marked INOUT or OUT. It is marked this way even though the handle itself is not modified - we use the INOUT or OUT attribute to denote that what the handle references is updated. Thus, in C++, IN arguments are either references or pointers to const objects.
Change the three inconsistent interface definitions from IN to INOUT in MPI-1.1 - see list of MPI 1.1 routines below.
Rationale for this clarification:
This is the minimal change to remove the existing inconsistency. Only the Fortran interfaces of three deprecated MPI-1.1 routines is modified from IN to INOUT. Due to Fortran call by reference, this has no impact for the applications. In the C interfaces, the handle argument is call by value.
Alternative B:
This proposal was deferred to MPI 2.2.
Keep the argument definition for handling the opaque objects (INOUT) and add the argument definition for the handles as IN.
Proposal: MPI 2.0 Sect. 2.3 Procedure Specification, page 6 lines 30-34 read:
There is one special case - if an argument is a handle to an opaque object (these terms are defined in Section 2.5.1), and the object is updated by the procedure call, then the argument is marked OUT. It is marked this way even though the handle itself is not modified - we use the OUT attribute to denote that what the handle references is updated. Thus, in C++, IN arguments are either references or pointers to const objects.but should read:
There is one special case - if an argument is a handle to an opaque object (these terms are defined in Section 2.5.1), and the object is updated by the procedure call but the handle itself is not modified, then the argument is marked IN/INOUT. We use the first part (IN) to specify the use of the handle and the second part (INOUT) to specify the use of the opaque object. Thus, in C++, IN arguments are either references or pointers to const objects, IN/INOUT arguments are references to const handles to non-const objects.
In the following routines, the INOUT handle declaration (in MPI-2.0) and the IN handle declaration (in MPI-1.1) is modified into a IN/INOUT handle declaration.
MPI 1.1:
MPI_ATTR_PUT, MPI_ATTR_DELETE, MPI_ERRHANDLER_SET
MPI 2.0:
MPI_INFO_SET, MPI_INFO_DELETE, MPI_COMM_SET_ERRHANDLER, MPI_TYPE_SET_ERRHANDLER, MPI_WIN_SET_ERRHANDLER, MPI_GREQUEST_COMPLETE, MPI_COMM_SET_NAME, MPI_TYPE_SET_NAME, MPI_WIN_SET_NAME, MPI_COMM_SET_ATTR, MPI_TYPE_SET_ATTR, MPI_WIN_SET_ATTR, MPI_COMM_DELETE_ATTR, MPI_TYPE_DELETE_ATTR, MPI_WIN_DELETE_ATTR, MPI_FILE_SET_SIZE, MPI_FILE_PREALLOCATE, MPI_FILE_SET_INFO, MPI_FILE_SET_VIEW, MPI_FILE_WRITE_AT, MPI_FILE_WRITE_AT_ALL, MPI_FILE_IWRITE_AT, MPI_FILE_READ, MPI_FILE_READ_ALL, MPI_FILE_WRITE, MPI_FILE_WRITE_ALL, MPI_FILE_IREAD, MPI_FILE_IWRITE, MPI_FILE_SEEK, MPI_FILE_READ_SHARED, MPI_FILE_WRITE_SHARED, MPI_FILE_IREAD_SHARED, MPI_FILE_IWRITE_SHARED, MPI_FILE_READ_ORDERED, MPI_FILE_WRITE_ORDERED, MPI_FILE_SEEK_SHARED, MPI_FILE_WRITE_AT_ALL_BEGIN, MPI_FILE_WRITE_AT_ALL_END, MPI_FILE_READ_ALL_BEGIN, MPI_FILE_READ_ALL_END, MPI_FILE_WRITE_ALL_BEGIN, MPI_FILE_WRITE_ALL_END, MPI_FILE_READ_ORDERED_BEGIN, MPI_FILE_READ_ORDERED_END, MPI_FILE_WRITE_ORDERED_BEGIN, MPI_FILE_WRITE_ORDERED_END, MPI_FILE_SET_ATOMICITY, MPI_FILE_SYNC
Rationale for this proposal:
I have checked the total MPI 1.1 and 2.0 standard to find all routines with an argument specification according to the following declaration pattern:Language independent interface: INOUT handle C interface MPI_handletype handleAll these routines keep the handle itself unchanged, but the opaque object is modified in a way, that with other MPI routines this change can be detected. For example, an attribute is cached or changed, a file pointer is moved, the content of a file was modified.The current specification with IN (in MPI 1.1) or INOUT (in MPI 2.0) is inadequate and led to misinterpretation in the const declarations of the C++ interface.
It is not explicitly mentioned that IN/IN is abbreviated with IN, and OUT/OUT with OUT. (Therefore no change in all routines with pure IN and pure OUT handles/opaque objects.
This proposal changes the Fortran interface, because the handles itself are now declared as IN. The MPI-2.0 did not decide whether they are IN or INOUT. Only C/C++ interfaces specified call by value for the handles itself. This hasn't any impact for applications. It is not expected that it has any impact on any MPI implementation.
Alternative C:
This proposal was deferred to MPI 2.2.
Substitute the argument definition for handling the opaque objects (INOUT) and by the argument definition for the handles (IN).
Proposal: MPI 2.0 Sect. 2.3 Procedure Specification, page 6 lines 30-34 read:
There is one special case - if an argument is a handle to an opaque object (these terms are defined in Section 2.5.1), and the object is updated by the procedure call, then the argument is marked OUT. It is marked this way even though the handle itself is not modified - we use the OUT attribute to denote that what the handle references is updated. Thus, in C++, IN arguments are either references or pointers to const objects.but should read:
There is one special case - if an argument is a handle to an opaque object (these terms are defined in Section 2.5.1), and the object is updated by the procedure call but the handle itself is not modified, then the argument is marked IN. Thus, in C++, IN arguments are either references or pointers to const objects, or references to const handles to non-const objects.
In all MPI-2.0 routines from the list above, the INOUT handle declaration is modified into a IN handle declaration.
Rationale for this proposal:
This proposal is easier, but looses the INOUT information on the opaque object itself.As at Alternative B, this proposal changes the Fortran interface, because the handles itself are now declared as IN. The MPI-2.0 did not decide whether they are IN or INOUT. Only C/C++ interfaces specified call by value for the handles itself. This hasn't any impact for applications. It is not expected that it has any impact on any MPI implementation.
See also Mail discussing of const in C++ specification of predefined MPI objects (was just datatypes). The decision there must be based on the decision to this item.
Open Issues from MPI-2.1 Standardization - As Input For MPI-2.2
-----------------------------------------------------------------------------
(number of entries)
? = should be decided by the MPI Forum ( 25)
R2 = deferred to a second round of modifying the MPI-2.1 document ( 19)
22 = should be deferred to MPI-2.2. (101)
It is mainly a suggestion to the content of MPI and not
to the merging of MPI-1.1 with MPI-2.
-----
(145)
I have sorted the items into 2 categories:
A = Significant enhancement or modification that should be discussed or decided
in the MPI-2.2 process:
These items are handed over to the editor of MPI-2.2, Bill Gropp
(47 Items)
B = Maybe nice to have or maybe already solved:
These items are handed over to originator of the item.
The originator is asked to handle it according the following procedure:
He may re-check the item, add references according to final MPI-2.1 standard
and may discuss it in a smaller group to achive a full and agreed wording
(in the subgroup) before resubmitting it to the whole MPI Forum.
Without resubmission, it is expected that the item is already fixed
or obsolete.
(97 Items)
My apologies if I sorted some items into the wrong category.
Rolf Rabenseifner
*** ====================================================================== ***
*** ========= ========= ***
*** ========= C A T E G O R Y A ========= ***
*** ========= ========= ***
*** ====================================================================== ***
Dries Kimpe, Katholieke Universiteit Leuven, 4 Mar 2008:
========================================================
Chapter 5:
----------
14.a 22 What about the usage of deprecated functions? (for example,
the old attribute functions, old datatype constructors, ...)
Since the code examples were not modified, they often still use
versions that were deprecated in later versions of the standard.
(see pg. 17 in the merged document)
Examples (by no means complete list):
(pg. number in merged document)
MPI_Attr_get: 309, 229, 244
MPI_Attr_put: 409, 227
MPI_Keyval_create : 244, 227
...
Editor's comment:
Nice to have, but should be done with more time, i.e. in MPI-2.2.
David George Solt, HP, 8 Mar 2008:
==================================
Chapter 3:
----------
15.q 22 [[ suggestion ]] Page 50, line 18. "The use of nonblocking sends is
advantageous in these cases [buffered & ready] only if data copying
can be concurrent with computation." I believe this statement is false.
An early call to MPI_Ibsend, for example, can avoid buffering entirely:
SENDER RECEIVER
------ --------
MPI_Ibsend(..., req);
MPI_Recv(...);
MPI_Wait(req); (completes quickly without buffering because the
message has already been transferred)
Compared to:
MPI_Recv(...);
MPI_Bsend(...); (must buffer the message because the sender does not
yet know if a matching receive call has
been made)
Editors note (WDG): MPI_Bsend is not required to buffer, if
it knows that it can complete the send with the appearance
of local completion.
15.w 22 [[ picky suggestion ]] Page 64, line 2.
"source rank, or MPI ANY SOURCE (integer)" The use of MPI_ANY_SOURCE
(same for TAG) is not called out in receive routines, but is here.
There may be some confusion among users if MPI_ANY_SOURCE is allowed
in both cases when looking at just the prototypes.
16.k 22 [[ merge suggestion ]] Page 95, line 1. I would recommend this section
be re-written to present MPI_Type_get_exent explicitly and not in terms
of the deprecated functions.
Editor's comment: See also review item 4.l
16.w 22 [[ merge suggestion ]] Page 105, line 19. Examples should not use
deprecated functions.
Editor's comment: See also review item 14.a
Jesper Larsson Traeff, NEC, Apr 4, 2008
=======================================
Two general consistency things:
24.a 22 0. count, rank, tag - should be "(nonnegative integer)" in all interface
specs (in one-sided it is usually so, in pt2pt sometimes so, sometimes
just "(integer)"
Editor's comment:
Yes for "count", *NO* for "rank, tag".
Most "count" are changed to nonnegative in MPI-2.1.
Chapter 3:
25.b 22 p. 27 [SUGG]: for count, rank, tag arguments, change "(integer)" to
"(nonnegative integer)" in all functions descriptions. At least, it
should be consistent, which is now not the case
Editor (WDG): Note that some of these are non-negative
integer or MPI predefined value; e.g., tags are non-negative
or MPI_ANY_TAG in a receive. Before making these changes,
we need a standardized way to describe this case.
25.l 22 p.58,l.29-30: state explicitly that count is a "(nonnegative integer)".
Same in all array_of_request functions
Chapter 4:
26.g 22 p.128,l.19 [SUGG]: all count arguments explicitly "(nonnegative integer)"
Chapter 10:
28.l 22 p.312,l.15 [COMM]: Note that here it is said that counts are
"(nonnegative integers)";
same should be done also for p2p and collectives, also for
consistency reasons.
Jeff Squyres, CISCO, April 7, 2008:
-----------------------------------
Terms and Conventions
=====================
30.f 22 p9.40-10.10: The C and Fortran language neutral name do not include
the prefix "MPI_", but the C++ bindings include the prefix "MPI::".
Shouldn't the C/Fortran bindings be "MPI_CLASS_ACTION_SUBSET"
(etc.)?
Editor (WDG): Agrees
30.g ? p10.35: due to the decision from last meeting (sort out the
IN/OUT/INOUT mess in MPI-2.2), the language should be softened in
this paragraph and the full paragraph following this one (because
they contradict each other). Specifically, I propose changing:
10.35: Thus, in C++, IN aguments are either references...
to
Thus, in C++, IN arguments are usually either references...
Editor's comment:
Is there an exception from this rule? If yes, then the proposal
is okay.
30.h 22 p11.22: "Fortran in this document refers to Fortran 90". For
MPI-2.1, it is probably suitable to leave this, but we might want to
make a statement (footnote or parenthetical) that it is expected to
be updated in future MPI spec revisions.
Editor (WDG): We need proposed replacement text.
Point-to-Point Communication
============================
30.i 22 p66.33: Why is the request argument to the C bindings MPI_CANCEL
take a pointer? The language neutral binding is IN, and the C++
binding is const. This seems to be a contradiction.
--> This cannot be changed easily because every MPI implementation
uses (MPI_Request *) as the type.
30.k 22 p92.43: mising "const" before "void* location". Adding "const"
will not break any user codes or MPI implementations.
--> This will require a vote.
30.l 22 p95.47-48: remove "const" before lb an extent arguments.
Removing "const" will not break any user codes or MPI
implementations.
--> This will require a vote.
Groups, Contexts, and Communicators
===================================
30.o R2 p186.5: Descriptions for the C++ bindings need to be included here,
since they are different than the C bindings. The text from 13.1.7
would seem to be sufficient. (See also 35.e)
30.p 22 p214.32: Missing "const" before "void* attribute_val_in" (datatype
callback argument is const)
--> This will require a vote.
30.q 22 p214.36: Delete function comm argument should be const (?)
--> This will require a vote.
30.r 22 p219.5: Missing "const" before "void* attribute_val_in" (datatype
callback argument is const)
--> This will require a vote.
30.s 22 p219.9: Delete function win argument should be const (?)
--> This will require a vote.
30.t 22 p221.44: Delete function type argument should be const (?)
--> This will require a vote.
MPI Environmental Management
============================
31.d 22 p255.2: First argument (comm handle reference) to errhandler
function should be const.
--> This will require a vote.
31.e 22 p256.27: First argument (win handle reference) to errhandler
function should be const.
--> This will require a vote.
31.f 22 p257.41: First argument (file handle reference) to errhandler
function should be const.
--> This will require a vote.
Process Creation and Management
===============================
31.o 22 p288.11: Function should be const.
--> This will require a vote.
31.p 22 p288.15: Function should be const.
--> This will require a vote.
External Interfaces
===================
31.q 22 p344.39: Arguments of query_fn, free_fn, and cancel_fn need to have
*'s. This is a consistency issue (the rest of the standard uses
"*" for function pointer parameters), not a correctness issue --
works both ways. Should not break any user code or MPI
implementations.
I/O
===
31.r 22 p419.43: datatype argument should be const
Profiling Interface
===================
32.w 22 p481.4: Delete "const"
--> This may require a vote.
Annex A
=======
33.m 22 p555.45-46: Forgot to mention MPI_ERRCODES_IGNORE,
MPI_F_STATUSES_IGNORE, and MPI_F_STATUS_IGNORE
Rajeev Thakur, ANL, Apr. 16, 2008
---------------------------------
36.b 22 pg 134, ln 32-33: What does matching arguments mean? Does it mean same
arguments? That's not true for the root argument of rooted collectives
on the group containing the root. Maybe just delete the sentence.
Editor (WDG) - I would prefer a more precise statement rather
than leaving it vague.
Torsten Hoefler, UI, Apr. 13, 2008
----------------------------------
with comments from chapter author Adam Moody.
37.i 22 ERR p132. "special communicator must be created" this is wrong,
later (in the bcast section) it is stated differently
... I would just remove this part of the advice or say
"might be created" (see Bcast advice)
Adam: Could you specify the particular advice via page and line numbers?
It's not clear to me what you are referring to here.
Torsten: ups, I forgot the line numbers here - sorry! It's line 1-2. It says that
implementors need to implement a "special communicator". Nobody does
this, most implementations just use special tags. So this advice is also
misleading (actually wrong).
Chapter 4: Datatypes
********************
Jesper Traeff (traeff_chap.3+4_mpi-2.1-reviews.txt)
-------------
(April 27!!!!!, 2008 version)
49.h 22 p.94
MPI_UB, MPI_LB are deprecated, and these sections should probably be
written differently. Consider --> MPI-2.2
Editor (WDG) - Agreed. Volunteers?
Jesper Traeff (traeff_chap.5_mpi-2.1-reviews.txt)
-------------
53.f 22 page 135, lines 42-46
Change wording of intercomm Barrier as suggested by Rajeev
Editor's comment:
I do not have a new wording. As far as I can remember, the Forum
decided that the current wording is clear.
53.k 22 page 144, lines 31-34
Example should NOT use deprecated MPI_UB/MPI_LB
53.n 22 page 146, lines 34-35
Example should NOT use deprecated MPI_UB/MPI_LB
54.c 22 page 165, line 8
Add other C types such as MPI_LONG_LONG, etc (in MPI-2.2!)
Chapter 11: One-sided Communications
************************************
Martin Schulz (schulz_chap.11_mpi-2.1-review.txt)
-------------
62.a 22 p. 319, l. 36 - should this really only apply to static variables?
Vendors should be able to provide "good" memory for
any location if they want to.
62.e 22 p. 351, l. 21 - together with earlier statement (p. 340, l.12) this
prevents the safe use of locks for F77 altogether.
I don't think we want to change this at this point,
but it might be useful to point out this combined
effect to the user.
Chapter 12: External Interfaces
*******************************
Rainer Keller (keller_chap.12_mpi-2.1-review.txt)
-------------
63.j 22 p370, l34: Move the somewhat hidden sentence:
"All routines listed in this section must be supported by all
MPI implementations."
to the clarifications, p368, l7 or to the end of the whole section...
Bronis de Supinski (supinski_chap.12_mpi-2.1-review.txt)
------------------
64.v 22 Wasn't there an an error handler free in MPI-1? What does the sentence
on page 361, lines 34-36 mean ("No functions are provided to free error
handlers or error classes: it is expected that an application will
generate them in significant numbers.")? If the MPI_Error_handler_free
function exists and is not deprecated then need to fix...
WDG - This was partially fixed in 2.1 by deleting "handlers";
however, the correct fix, page 273, line 47, is to change
"classes" to "codes or classes". An item has been added to
the MPI 2.2 wiki for this.
MPI 2.2 Discussion
Chapter 13: MPI I/O *******************
Quicey Koziol (koziol-chapter13-mpi21.txt)
-------------
65.j 22 p415.8: We need to define the length for MPI_WCHAR; must be added after
p415.8
Additional items from the meeting Apr. 28-30, 2008
--------------------------------------------------
Rolf Rabenseifner, HLRS, June 13, 2008
--------------------------------------
74.h 22 Only parts of the tables in Section A.1.1 have information on how to
declare the constants and predefined handles in C++.
To be consistent, this information should be provided for all table
entries.
74.l 22 Predefined callback functions:
- In Sect. 6.7.3/4/5 the fuctions
MPI_{COMM|TYPE|WN}_{NULL_COPY|DUP|NULL_DELETE}_FN are defined
with the *same* name for C, Fortran, and C++ !
Was it intented that we use MPI_... for C++?
- In A.1.1 page 501 line 13-17 (MPI-2.1 Draft June 13, 2008),
the table shows MPI_{NULL_COPY|DUP|NULL_DELETE}_FN,
which are the C++ counterparts for the deprecated ones.
Do we want these?
They are useless, because there isn't a C++ counterpart of
MPI_KEYVAL_CREATE.
- Based on these questions, I have commented out the C++ declarations
in Appendix A.4.4 for
MPI_{COMM|TYPE|WN}_{NULL_COPY|DUP|NULL_DELETE}_FN.
The C and Fortran routines are fully visible in A.2.4 and A.3.4.
------------------------------------------------------------------------
Ballot items that were discussed in the MPI-Forum, but moved to MPI-2.2:
------------------------------------------------------------------------
76.a 22 (originally Ballot 4, Item 7)
-----------------------------
Mail discussion, proposed by Jeff Squyres, Jul 30, 1999, et al.
http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ -
discuss/spawn/
Proposal A
Add in MPI-2.0, page 88, after line 24:
Advice to users. If the non-root processes do not use
MPI_ERRCODES_IGNORE, then they have to allocate the appropriate
number of entries (see maxproc at root) in the array_of_errcodes
although the maxproc argument is unused in non-root processes.
It is allowed to use an array_of_errcodes at some of the calling
processes and MPI_ERRCODES_IGNORE at some others.
(End of advice to users.)
Rationale for this clarification:
It was not clear that maxproc is significant as input argument only
at root while it is needed at all processes to define the length of
array_of_errcodes. It was not explicitly forbidden that
MPI_ERRCODES_IGNORE is used only at some processes. And there isn't
a general rule that all arguments must be the same.
Proposal B
MPI 2.0 page 84 line 45 reads (in MPI_COMM_SPAWN):
OUT array_of_errcodes one code per process (array of integer)
but should read:
OUT array_of_errcodes one code per process (array of integer,
significant only at root)
MPI 2.0 page 89 line 42 reads (in MPI_COMM_SPAWN_MULTIPLE):
OUT array_of_errcodes one code per process (array of integer)
but should read:
OUT array_of_errcodes one code per process (array of integer,
significant only at root)
Comment:
This proposal modifies the MPI interface. User codes may be broken.
Another reason, not to do this modification, is that the non-root
processes have no chance (in error-return-mode) to detect an error.
And after an error, MPI does not guarantee that MPI communication
still works. Only MPI_Abort should be guaranteed to work.
Editor (WDG). Proposal B seems better to me. Are there any
user codes or implementations that will be seriously affected
by this choice?
76.b 22 (originally Ballot 4, Item 22, Alternatives B and C)
----------------------------------------------------
Mail discussion, proposed by J. Squyres & R. Rabenseifner, Jan. 21, 2008
http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ -
discuss/inout/
Problem:
There is a inconsistency between the INOUT description for handle
arguments, and their usage in the language independent definitions
of MPI-1.1 and MPI-2.0. There are 3 possibilities to solve this.
The MPI Forum should decide, which possibility is the best.
Background:
MPI 2.0 Sect. 2.3 Procedure Specification, page 6 lines 30-34 read:
There is one special case - if an argument is a handle to an opaque
object (these terms are defined in Section 2.5.1), and the object
is updated by the procedure call, then the argument is marked OUT.
It is marked this way even though the handle itself is not modified
- we use the OUT attribute to denote that what the handle references
is updated. Thus, in C++, IN arguments are either references or
pointers to const objects.
Example: MPI 1.1, page 171, lines 26-34:
MPI_ATTR_PUT(comm, keyval, attribute val)
IN comm communicator to which attribute will be
attached (handle)
IN keyval key value, as returned by MPI_KEYVAL_CREATE
(integer)
IN attribute_val attribute value
int MPI_Attr_put(MPI_Comm comm, int keyval, void* attribute_val)
Example: MPI 2.0, page 44, lines 36-43:
MPI_INFO_SET(info, key, value)
INOUT info info object (handle)
IN key key (string)
IN value value (string)
int MPI_Info_set(MPI_Info info, char *key, char *value)
Handles "comm" and "info" in these examples:
- Handle with call by value (IN)
- The object behind is modified (INOUT)
List of routines with IN handles and INOUT objects:
MPI 1.1:
MPI_ATTR_PUT, MPI_ATTR_DELETE,
MPI_ERRHANDLER_SET
MPI 2.0:
MPI_INFO_SET, MPI_INFO_DELETE,
MPI_COMM_SET_ERRHANDLER, MPI_TYPE_SET_ERRHANDLER,
MPI_WIN_SET_ERRHANDLER,
MPI_GREQUEST_COMPLETE,
MPI_COMM_SET_NAME, MPI_TYPE_SET_NAME, MPI_WIN_SET_NAME,
MPI_COMM_SET_ATTR, MPI_TYPE_SET_ATTR, MPI_WIN_SET_ATTR,
MPI_COMM_DELETE_ATTR, MPI_TYPE_DELETE_ATTR, MPI_WIN_DELETE_ATTR,
MPI_FILE_SET_SIZE, MPI_FILE_PREALLOCATE,
MPI_FILE_SET_INFO, MPI_FILE_SET_VIEW,
MPI_FILE_WRITE_AT, MPI_FILE_WRITE_AT_ALL, MPI_FILE_IWRITE_AT,
MPI_FILE_READ, MPI_FILE_READ_ALL,
MPI_FILE_WRITE, MPI_FILE_WRITE_ALL,
MPI_FILE_IREAD, MPI_FILE_IWRITE,
MPI_FILE_SEEK,
MPI_FILE_READ_SHARED, MPI_FILE_WRITE_SHARED,
MPI_FILE_IREAD_SHARED, MPI_FILE_IWRITE_SHARED,
MPI_FILE_READ_ORDERED, MPI_FILE_WRITE_ORDERED,
MPI_FILE_SEEK_SHARED,
MPI_FILE_WRITE_AT_ALL_BEGIN, MPI_FILE_WRITE_AT_ALL_END,
MPI_FILE_READ_ALL_BEGIN, MPI_FILE_READ_ALL_END,
MPI_FILE_WRITE_ALL_BEGIN, MPI_FILE_WRITE_ALL_END,
MPI_FILE_READ_ORDERED_BEGIN, MPI_FILE_READ_ORDERED_END,
MPI_FILE_WRITE_ORDERED_BEGIN, MPI_FILE_WRITE_ORDERED_END,
MPI_FILE_SET_ATOMICITY, MPI_FILE_SYNC
Alternative A: (Implemented in MPI-2.1)
---------------------------------------
Keep the argument definition for handling the opaque objects (INOUT) and
add the argument definition for the handles as IN.
Proposal:
MPI 2.0 Sect. 2.3 Procedure Specification, page 6 lines 30-34 read:
There is one special case - if an argument is a handle to an opaque
object (these terms are defined in Section 2.5.1), and the object
is updated by the procedure call, then the argument is marked OUT.
It is marked this way even though the handle itself is not modified
- we use the OUT attribute to denote that what the handle
references is updated. Thus, in C++, IN arguments are either
references or pointers to const objects.
but should read:
There is one special case - if an argument is a handle to an opaque
object (these terms are defined in Section 2.5.1), and the object
is updated by the procedure call, then the argument is marked INOUT
or OUT.
It is marked this way even though the handle itself is not modified
- we use the INOUT or OUT attribute to denote that what the handle
references is updated. Thus, in C++, IN arguments are either
references or pointers to const objects.
Change the three inconsistent interface definitions from IN to INOUT
in MPI-1.1 - see list of MPI 1.1 routines below.
Rationale for this proposal A:
This is the minimal change to remove the existing inconsistency.
Only the Fortran interfaces of three deprecated MPI-1.1 routines
is modified from IN to INOUT. Due to Fortran call by reference,
this has no impact for the applications. In the C interfaces,
the handle argument is call by value.
Alternative B:
--------------
Keep the argument definition for handling the opaque objects (INOUT)
and add the argument definition for the handles as IN.
Proposal:
MPI 2.0 Sect. 2.3 Procedure Specification, page 6 lines 30-34 read:
There is one special case - if an argument is a handle to an opaque
object (these terms are defined in Section 2.5.1), and the object
is updated by the procedure call, then the argument is marked OUT.
It is marked this way even though the handle itself is not modified
- we use the OUT attribute to denote that what the handle
references is updated. Thus, in C++, IN arguments are either
references or pointers to const objects.
but should read:
There is one special case - if an argument is a handle to an opaque
object (these terms are defined in Section 2.5.1), and the object
is updated by the procedure call but the handle itself is not
modified, then the argument is marked IN/INOUT.
We use the first part (IN) to specify the use of the handle and
the second part (INOUT) to specify the use of the opaque object.
Thus, in C++, IN arguments are either references or pointers to
const objects, IN/INOUT arguments are references to const handles
to non-const objects.
In the listed routines, the INOUT handle declaration (in MPI-2.0) and
the IN handle declaration (in MPI-1.1) is modified into a IN/INOUT
handle declaration.
Rationale for this proposal B:
I have checked the total MPI 1.1 and 2.0 standard to find all
routines with an argument specification according to the following
declaration pattern:
Language independent interface:
INOUT handle
C interface
MPI_handletype handle
All these routines keep the handle itself unchanged, but the opaque
object is modified in a way, that with other MPI routines this change
can be detected. For example, an attribute is cached or changed,
a file pointer is moved, the content of a file was modified.
The current specification with IN (in MPI 1.1) or INOUT (in MPI 2.0)
is inadequate and led to misinterpretation in the const declarations
of the C++ interface.
It is not explicitly mentioned that IN/IN is abbreviated with IN, and
OUT/OUT with OUT. (Therefore no change in all routines with pure IN
and pure OUT handles/opaque objects.)
This proposal changes the Fortran interface, because the handles
itself are now declared as IN. The MPI-2.0 did not decide whether
they are IN or INOUT. Only C/C++ interfaces specified call by value
for the handles itself. This hasn't any impact for applications.
It is not expected that it has any impact on any MPI implementation.
Alternative C:
--------------
Substitute the argument definition for handling the opaque objects
(INOUT) and by the argument definition for the handles (IN).
Proposal:
MPI 2.0 Sect. 2.3 Procedure Specification, page 6 lines 30-34 read:
There is one special case - if an argument is a handle to an opaque
object (these terms are defined in Section 2.5.1), and the object
is updated by the procedure call, then the argument is marked OUT.
It is marked this way even though the handle itself is not modified
- we use the OUT attribute to denote that what the handle
references is updated. Thus, in C++, IN arguments are either
references or pointers to const objects.
but should read:
There is one special case - if an argument is a handle to an opaque
object (these terms are defined in Section 2.5.1), and the object
is updated by the procedure call but the handle itself is not
modified, then the argument is marked IN.
Thus, in C++, IN arguments are either references or pointers to
const objects, or references to const handles to non-const objects.
In all MPI-2.0 routines from the list above, the INOUT handle
declaration is modified into a IN handle declaration.
Rationale for this proposal C:
This proposal is easier, but looses the INOUT information on the
opaque object itself. As at Alternative B, this proposal changes
the Fortran interface, because the handles itself are now declared
as IN. The MPI-2.0 did not decide whether they are IN or INOUT.
Only C/C++ interfaces specified call by value for the handles itself.
This hasn't any impact for applications. It is not expected that it
has any impact on any MPI implementation.
Summary:
--------
Proposal A:
Defining only the outcome for the opaque object:
- e.g., INOUT file handle in write routines.
- Text in "Terms and Conventions" is not changed.
- Changes at 3 MPI 1.1 routines (IN --> INOUT)
Proposal B:
Explicitly defining the outcome for handle and opaque object
- e.g., IN/INOUT filehandle in write routines.
- Text in "Terms and Conventions" is changed.
- Changes at 3 MPI 1.1 routines (IN --> IN/INOUT)
and 48 MPI 2.0 routines (OUT --> IN/INOUT)
Proposal C:
Defining only the outcome for the handle itself:
- e.g., IN filehandle in write routines.
- Text in "Terms and Conventions" is changed.
- Changes at 48 MPI 2.0 routines (INOUT --> IN)
76.c 22 (originally Ballot 4, Item 9)
-----------------------------
Mail discussion, by Richard Treumann and Rolf Rabenseifner,
Jun 13 - Jul 26, 2001
http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ -
discuss/cxxconstdtype/
With Item 22.A : INOUT (Variant A/D: Same as voted for Bal. 3)
--------------------------------------------------------------
MPI-2, page 345, line 37: Remove the const from const MPI::Op.
MPI-2, page 346, line 20: Remove the const from const MPI::Group.
MPI-2, page 346, add after line 34:
Advice to implementors: If an implementation does not change the
value of predefined handles while execution of MPI_Init, the
implementation is free to define the predefined operation handles
as const MPI::Op and the predefined group handle MPI::GROUP_EMPTY
as const MPI::Group. Other predefined handles must not be "const"
because they are allowed as INOUT argument in the
MPI_COMM_SET_NAME/ATTR and MPI_TYPE_SET_NAME/ATTR routines.
(End of advice to implementors.)
Reason:
MPI_Init may change the predefined handles, because MPI 1.1,
page 10, lines 9-10 says: "Opaque objects accessed by constant
handles are defined and do not change value between MPI
initialization (MPI_INIT() call) and MPI completion
(MPI_FINALIZE() call)." Therefore they must not be defined as const
in the MPI standard.
This proposal is needed for 76.b, Alternative A:
Alternative A: Keep INOUT for handles with call by value in C/C++.
In this case, the text above should be used (as already proposed for
Ballot 3)
With Item 22.B : IN/INOUT (Variant B: Modifications in Advice)
---------------------------------------------------------------
MPI-2, page 345, line 37: Remove the const from const MPI::Op.
MPI-2, page 346, line 20: Remove the const from const MPI::Group.
MPI-2, page 346, add after line 34:
Advice to implementors: If an implementation does not change the
value of predefined handles while execution of MPI_Init, the
implementation is free to define the predefined operation handles
as const MPI::Op and the predefined group handle MPI::GROUP_EMPTY
as const MPI::Group. (End of advice to implementors.)
This proposal is needed for 76.b, Alternative B:
Alternative B: Change into IN/INOUT (i.e. mark handles as IN and
referenced opaque object as INOUT).
In this case, remove the last sentence from the proposal:
"Other predefined handles must not be "const" because they are
allowed as INOUT argument in the MPI_COMM_SET_NAME/ATTR and
MPI_TYPE_SET_NAME/ATTR routines."
With Item 22.B : IN (Variant C: Modifications in Advice)
--------------------------------------------------------
MPI-2, page 345, line 37: Remove the const from const MPI::Op.
MPI-2, page 346, line 20: Remove the const from const MPI::Group.
MPI-2, page 346, add after line 34:
Advice to implementors: If an implementation does not change the
value of predefined handles while execution of MPI_Init, the
implementation is free to define the predefined operation handles
as const MPI::Op and the predefined group handle MPI::GROUP_EMPTY
as const MPI::Group. (End of advice to implementors.)
This proposal is needed for 76.b, Alternative C:
Alternative C: Change into IN (i.e. mark handles as IN and forget about
referenced opaque object as).
In this case, remove the last sentence from the proposal:
"Other predefined handles must not be "const" because they are
allowed as INOUT argument in the MPI_COMM_SET_NAME/ATTR and
MPI_TYPE_SET_NAME/ATTR routines."
*** ====================================================================== ***
*** ========= ========= ***
*** ========= C A T E G O R Y B ========= ***
*** ========= ========= ***
*** ====================================================================== ***
15.d 22 [[ question ]] Page 28, line 3. Here we claim that the last 3 arguments
Richard Graham, ORNL, 03 Mar 2008:
==================================
Chapter 7:
----------
5.d R2 Page 253 line 14: Do we want to refer to MPI-2 specifically, or just as
extended error handling ?
Editor's comment: Yes, in the 2nd round, this merge should be done.
Rajeev Thakur, ANL, 03 Mar 2008:
================================
Chapter 4:
----------
6.b R2 * The introductory text from the original chapter in MPI-2.0 makes
sense when it is viewed as an extension (add-on) to the chapter in
MPI-1. But that text in its new location in Section 4.3 does not make
sense as it is, because it appears before any of the collective
functions have been introduced. Section 4.3 needs some careful
editing to make it fit in its new position. (Not doing it here.)
Reason for *NO*:
It can be done, if such a text would be written at the
March 2008 meeting. Otherwise, this item is deferred to
MPI-2.2. Current text: 124/12 - 127/38.
Richard Barrett, ORNL, 04 Mar 2008:
===================================
Chapter 6:
----------
8.1 22 1. p231/41: The citation supporting the performance potential of
graph defined topologies is from 1989. Are there more recent citations
to supplement? Similar question for other citations throughout the
chapter.
8.6 22 6. p232/23-29. This seems like unnecessary rationalization. Unless it
can be substantiated (with a citation), it should be removed. How
about, "When the graph structure is regular and can be completely
defined by the number of dimensions and the number of processes in
each coordinate direction, such as rings, two- or higher dimensional
grids, or tori, a simpler description can be made ..." or the like.
And then talk about support for Cartesian topologies, which suddenly
is mentioned on 6.4, line 3
8.7 22 7. p233, line 5. How about, "... are collective, and therefore must
adhere to that category's requirements." Clunky, but the idea ...
8.8 22 8. p233, line 19: "Similar functions are contained in EXPRESS and
PARMACS."
Can we update (or eliminate) this? Sounds like, "All the other kids are
doing it." :)
Jepser Traeff's comment: Would like to eliminate, but have not done
8.9 22 9. p233, line 22-33. Reads clunky. In particular, "foo can be used to"
Implies they are designed primarily for something else. And perhaps
provide a high level sentence regarding the content of the paragraph:
"A variety of inquiry functions are provided."
(Which then calls for a bit of a reorganization of the paragraph,
since sub-setting functionality is discussed as well.
8.10 22 10. p234, line 27. "choose a beneficial" rather than "good". (Could be
great! Or ok, or...)
8.11 22 11. p237, line 19-20. "If a topology has been defined with one of the
above functions ..." How else? Instead: "Information regarding a
process topology can be returned using inquiry functions."
Or something like that.
8.13 22 13. p241, line 15. I prefer, "Suppose this topology is associated with
communicator comm..."
8.c R2 3. Long example, p246. Any verification of correctness available?
David George Solt, HP, 8 Mar 2008:
==================================
Chapter 3:
----------
15.d 22 [[ question ]] Page 28, line 3. Here we claim that the last 3 arguments
"specify" the envelope. But in section 3.2.3, we claim that a message
envelope consists of 4 parts. Perhaps this line should read, "The last
three parameters of the send operation, together with the rank of the
caller, specify the envelope for the message sent."
15.e 22 [[ question ]] Page 28, 3.2, line 28. I never understood why it says
"Initial address". Makes it sound like it could change during the course
of the operation. I like "starting" or "beginning"
15.k 22 [[ suggestion merge ]] Page 35, line 12. "The functions that can be
passed MPI STATUS IGNORE are all the various forms of MPI RECV, MPI TEST,
and MPI WAIT, as well as MPI REQUEST GET STATUS." is semi-redundant with
Page 35, line 2: "... which when passed to a receive, wait, or test
function, inform the implementation that the status fields are not to
be filled in."
I would suggest that line 2 be changed to "which when passed to a
receive, wait, test or the MPI_REQUEST_GET_STATUS function, inform the
implementation that the status fields are not to be filled in." and
then remove the sentence from line 12 completely.
15.l 22 [[ suggestion merge ]] Page 35, line 14. "When an array is" change to
"When an array of statuses is". If the change above is made, then I think
it will read easier to include "of statuses".
15.o 22 [[ question ]] Page 47, line 3,17. I don't understand why "initial" is
used here. I think "starting" or "beginning" would be better than
"initial" for most of the function description, since "initial" implies
it may change during the call. However, in this case, I don't understand
why any descriptor is used before "buffer address".
Editor's comment: I agree. All buffer specifications are using "initial"
instead of "starting", or ... .
15.s 22 [[ picky suggestion ]] Page 55, line 39. "Thus, a blocking Wait can
be easily replaced by a nonblocking Test" changed to "Thus, a blocking
Wait can be easily implemented using a nonblocking Test". The intent is
clearly a loop of nonblocking Test calls, not a direct replacement.
15.t 22 [[ question ]] Page 58, line 14. What is the point to the paragraph.
Q? It has already been stated that even if no completion routine has been
called, that a matched non-blocking call must complete.
What is the point to calling out MPI_Test?
15.u 22 [[ picky suggestion ]] Page 58, line 26. "enabled operations" is unclear.
Maybe "finished operations"?
15.v 22 [[ picky suggestion ]] Page 59, line 4. The attempt to define the
functionality of MPI_Waitany uses the functionality of MPI_Waitany
in the definition. I would not mind, since I think the sentence is
still meaningful, but then on line 39, MPI_Testany is defined more
fully using the phrase "for i=0 ,..., count-1". The description of
MPI_Testany defines the call in terms of the equivalent MPI_Test calls
that we would expect would be used to implement the MPI_Testany call.
However, on line 4, the description of MPI_Waitany is given solely in
terms of the end net effect of the call in comparison to the equivalent
MPI_Wait call. One description is in terms of implementation,
the other in terms of net result.
16.c R2 [[ merge suggestion ]] Page 76, line 39. I don't know what the intended
style is of the merged document, but I would prefer that it refrained
from designating functions as "new". Deprecated functions should be
designated as such, but otherwise my preference is to avoid distinctions
between "new" and "old".
I would title this section "Datatype Manipulation Functions".
Suggested text:
The following sections present type manipulation functions.
These functions use address sized arguments where ever an offset may
be specified, allowing for the passing of offsets greater than 2^32.
Deprecated versions of these functions are listed in Section 2.6.1.
Editor's comment:
I would prefere to keep the text as it is.
It may be modified in MPI-2.2 or MPI-3.0.
Version 2.1 is a merge, but for me, it is okay that the reader can
detect that some functionality was added in MPI-2.
If we want to finish MPI-2.1 in the given timeframe, any modifications
must be decided at the end of the March 2008 meeting.
Editor (WDG): In addition, we must avoid references to
specific datatype sizes, since this text incorrectly assumes
that ints are exactly 32 bits. That's an implementation
choice that is not required in C or Fortran.
16.m 22 [[ merge suggestion ]] Page 96, line 24. Again, my preference towards
removing text such as this.
16.u 22 [[ question ]] Page 104, line 27: "The function MPI ADDRESS returns
a valid address, when passed as argument a variable of the calling
program." Not sure what this is saying. Same for line 29-30.
Alexander Supalov, INTEL, and Rajeev Thakur, ANL, 14 Feb 2008:
==============================================================
18.a 22 15/43 (p. 10, line 43): "defined elsewhere" - should specify where to
make it clear to the reader
Decision: Ignore
Jesper Larsson Traeff, NEC, Apr 4, 2008
=======================================
Two general consistency things:
Chapter 1:
24.d R2 p. 1 [COMM]: In general all the contrasting of MPI-1/MPI-2 reads very
awkward.
24.f R2 p.3,l.16 [TYPO]: Ref to Chapter 3 is wrong
Chapter 2:
24.m R2 p.9,l.16 [SUGG]: Eliminate MPI-1/MPI-2 distinctions, e.g. "MPI Terms and
Conventions Chapter"
24.o ? p.14,l.36 [SUGG]:
shouldn't "inquery function" be "query function"?
Editor (WDG): I don't think so. Other comments?
24.r 22 p.25,l.9 [QUESTION]: Do we really want to stand by this, that the
examples have "not been carefully checked or verified"???
Chapter 3:
25.c ? p.27,l.21 [SUGG]: shouldn't this be "Example 3.1"?
25.e 22 p.28,l.29 [COMM]: here count is "(nonnegative integer)", but this
disappears later, eg. in RECV, p.32,l.4
25.i 22 p.46,l.28 [QUESTION]: Does the Forum realy want to stand to this
(recommendation, almost, of unsafe programming style)??
25.m 22 p.59,l.35 [QUESTION]: or is it intended that WAITSOME/TESTSOME takes
an array of atleast one request?
25.o R2 p.76,l.39 [SUGG]: "New Datatype ..." -> "Additional Datatype..."
25.w 22 p.107,l29 [SUGG]: This example (3.36) could be broken up into smaller
examples
Chapter 4:
26.a R2 p. 121 Chapter 4: This chapter does not work in the merged form.
26.e R2 p.125,l.47 [SUGG]: "additions" is not the right word here (whole
section is VERY problematic, as is this whole chapter)
26.f R2 p.127,l.2 [SUGG]: "being identical" must be rephrased
26.z 22 p.170,l.22[COMMENT]: In my opinion, this example is NOT correct (the
second scenario may hang, process 1 can enter the Bcast which cannot
complete before process 2 enters Bcast, which it cannot before the Send
has completed - as in example 4.25)
Editor's comment:
Yes, Jesper, you are right.
If Bcast uses buffered send from rank 0 to 2 and from 2 to 1,
and if explicit MPI_Send is synchronous,
and 1st MPI_Recv receives the message from rank 2,
then the program is in a deadlock.
Chapter 5:
27.a R2 p. 173 Chapter 5: This chapter does not work in the merged form.
27.c R2 p.175,l.18 [SUGG]: "dealt with so far"... is no longer true
27.g ? p.184,l.22-23 [QUESTION]: Is this advice to implementers needed anymore?
27.l 22 p.199,l.28 [SUGG]: "the above examples is really three examples"
- why not split? The example is too long
27.p ? p.201,l.38 [QUESTION]: what does "the same algorithm is appropriate..."
mean?
27.q 22 p.205, Example 1 [SUGG]: very long...
27.r' 22 Example is excessively long!
Chapter 6:
28.b ? p.232,l.17 [SUGG]: remove PARMACS rationale, seems obsolete nowadays
28.c ? p.233,l.19 [SUGG]: remove EXPRESS/PARMACS rationale
Chapter 8:
28.f R2 p.373,l.10 [SUGG] Rename chapter to
"Controlling the functionality: The info object"
or something like this. Any better/good suggestions?
28.g R2 p.271,l.14 [SUGG]: Remove this line
Chapter 10:
28.o ?_ p.330,l.10 [QUESTION]: what is the state of Fortran compilers at
this time of writing?
Dick Treumann, IBM, Apr. 7, 2008:
---------------------------------
29.a 22 p.193,l.1-4 In the description of MPI_COMM_FREE we presently give the
following advise to implementors.
A reference-count mechanism may be used: the reference count is
incremented by each call to \func{MPI\_COMM\_DUP}, and decremented by
each call to \func{MPI\_COMM\_FREE}. The object is ultimately
deallocated when the count reaches zero.
I do not think it can ever be valid to implement MPI_COMM_DUP by simply
returning a new handle for an existing communicator object while bumping
its reference count because the output communicator must have a
different context than the original. Assuming I have not missed
something, it seems this advise is nonsense.
Is removing this the kind of change that should go on the MPI 2.2 list?
I will be surprised if anyone offers a rationale for keeping the advise
but I am also not quite comfortable that it fits within the "clean up"
rules for MPI 2.1 at this late stage.
Jeff Squyres, CISCO, April 7, 2008:
-----------------------------------
April 7 2008
Comments on MPI-2.1 April 1, 2008 document
(notation: pX.Y = page X, line Y)
Overall
=======
30.b ? Some function pointer typedefs are "_function", others are "_fn"
We should be consistent throughout the text.
Editor's comment: I'll check how complicated this change may
be
Editor (WDG): We could add typedefs to make these uniform,
but in MPI 2.2 we cannot remove any of the existing
typedefs. This may be better left to MPI 3.
Intro chapter
=============
30.c ? p5.2: Two open source MPI implementations are cited that are no
longer relevant. This entire sentence should be removed. Indeed,
the language in the overall paragraph is forward-looking -- it
should probably be re-worked to be in the present tense.
Editor's comment: should be done by the Forum
Editor (WDG): The historical context is important. Rather
than remove this, it should be updated.
Language Bindings
=================
32.j' ? Which names should be visible in the Index for Dup and Clone?
TODO
32.k R2 p445.36-38: Remove this entire paragraph ("Compilers that do not
support..."). This feature has been a part of C++ since C++98, and
exists in all modern C++ compilers.
32.n 22 p450.26-44: The bullet list is wholly redundant with section 2.6.2.
Editor's comment:
Was decided by MPI-2 Forum as it is.
32.o 22 p456.27-29: VOLATILE is in Fortran 200x; reword first sentence from:
"In the longer term, the attribute VOLATILE is under
consideration for Fortran 2000 and would give the buffer or
variable the properties needed, but it would inhibit
optimization of any code containing the buffer or variable."
to
"The VOLATILE attribute, available in later versions of Fortran,
would give the buffer or variable the properties needed, but it
would inhibit optimization of any code containing the buffer or
variable."
32.r 22 p463.17-18: Delete first sentence; delete "In MPI-2,"
32.v ? p470.46: Change sentence from:
"It is important to note that all C++ objects and their
corresponding C handles..."
to
"It is important to note that all C++ objects with
corresponding C handles..."
I.e., this sentence is referring only to C++ handles that actually
have corresponding C handles (e.g., not
MPI::ERRORS_THROW_EXCEPTIONS).
Annex A
=======
33.l 22 p554.41: Do we need an empty deprecated functions section?
Editor's comment:
May be, I can resolve this after the next meeting.
Currently, it is automized and only empty in C++.
33.n R2 p556.bottom: Missing prototypes for the MPI::Exceptions class
Editor's comment:
What is needed in the Annex?
Only a copy of p.446.7-17?
David Solt, HP, April 10, 2008
------------------------------
34.d 22 Page 288, Would like to remove the text
"(which is likely to be (char ***)0 in C)"
as it adds no useful information and only encourages the writing of
non-portable code. However, I don't believe such a change is
appropriate for this round of edits.
34.f 22 Page 302, "An implementation must document how MPI_UNIVERSE_SIZE is set.
An implementation may not support the ability to set MPI_UNIVERSE_SIZE,
in which case the attribute MPI_UNIVERSE_SIZE is not set."
It is still unclear to me after reading the chapter again,
whether MPI_Attr_get(MPI_COMM_WORLD, MPI_UNIVERSIZE_SIZE, &out, &flag),
must set flag=1. I would like to see this clarified.
Must the implementation provide this attribute or is it optional?
Dick Treumann, IBM, Apr. 8, 2008 with comments from Bill Gropp, April 9, 2008
--------------------------------
Chapter 5 - items needing Forum feedback (references are to Apr.1 draft)
35.a R2 1) 171:28-29 We point to a couple 15 year old papers to give background
on using MPI to write libraries. It seems to me the concepts no longer
require this backup. They have been around for long enough to be
current practice. Is there a reason to keep the pointers?
Bill's comment:
I think we should edit and add to this, not drop it. I still hear
people say that "MPI was derived from PVM," which is not true and
which this historical context makes clear.
35.b 22 2) 192:8-13 Bogus advise about just playing with the reference count
to implement MPI_COMM_DUP (I think Rolf has already captured this
for MPI 2.2)
Bill's comment: Agreed.
Editor's comment: See 29.a
35.c ? 3) 202:31-35 The wierd suggestion that intercommunicator groups may
not be required to be disjoint should come out. Everything else is
pretty clear that they ARE disjoint. As far as I can see this
statement falls into the catagory of "We could have made a different
choice when we wrote MPI-1". The decision was made that the groups
are disjoint so this editorial aside should be removed.
Bill's comment:
This needs to be removed because it is one of the adopted errata.
No discussion should be needed.
Editor's comment:
Which adopted errata?
All errata should be already implemented in the current tex-source.
Editor (WDG): Where is this in the 2.1 document? Has it
already been fixed?
35.d 22 4) The discussion of attribute caching needs significant rework.
It has paragraphs from when only communicators supported caching
and paragraphs about adding caching support to windows and datatypes.
It should be reworded to describe caching as it applies to all three
object types and explain who there is no WIN_DUP while there is a
TYPE_DUP and a COMM_DUP. (and therefore no attribute copy functions
for windows.)
Bill's comment:
Agreed.
Rajeev Thakur, ANL, Apr. 16, 2008
---------------------------------
36.h 22 pg 163, Sec 5.9.3: Delete the sentence "This is an extension to MPI-1.2,
..." since we are all one now. Merge the next paragraph on heterogeneous
into this one, and fix spelling of "charater" to character.
Torsten Hoefler, UI, Apr. 13, 2008
----------------------------------
with comments from chapter author Adam Moody.
37.f 22 CLAR p131.1 add "with exceptions stated in the following" to
first sentence
Adam:
Do you mean exceptions to the matching of datatypes in sender and receiver?
Are there exceptions to this?
Torsten: The expection is for arguments that are only significant at certain
processes. I.e., not all arguments must match (because they are
ignored). But I guess it's ok and clear as it is - we don't need a
change here.
37.j 22 CLAR p131.37 add "depending on the operation performed" after last
sentence (right now it sounds like ths user is free to
choose which argument to replace)
Adam: Do you mean p132.27 instead? The recommendation doesn't seem to line up
with the document I have.
Torsten: yes, this is line 27, got confused with the line numbers here.
37.n ? EDIT p136.26-31 this paragraph is redundant (it's all already stated
earlier, do we want this redundancy in the standard?)
Adam: I agree that it is redundant, but this emphasis in a particular case may be
useful to get the point across. I'd leave it up to the Forum to vote on this.
Torsten: ok, good idea.
37.r ? CLAR p136.38 "must be consistent with the ..." what does the word
consistent mean in this context? This seems undefined.
I think it means that the signature (size, count) is
the same. We should say this explicitely. The same
term "consistent" is used in all following operations
(I'm not going to add it again)
Adam: I agree that "consistent" is not defined, however, I'm not sure what it
means either. I think this change should be left to the Forum.
Torsten: Yes, I'd just say that this needs to be defined. I can only guess what
it means.
37.v ? EDIT p147.48 the last paragraph is redundant (has been stated
before for all collectives)
Adam: Again, I'll leave this redundancy question to the Forum.
Torsten: ok
37.z 22 EDIT p162.13 state that the example is in Fortran (it's said for
all the C examples before)
Adam: I don't see examples in this chapter that say they are in C either,
or at least, there are many that don't.
Torsten: ok, there are some that do and some that don't. Ah, I don't care ...
people who are not able to recognize the language are not our target
audience anyway (I hope).
38.f 22 EDIT p171.48 state that example is in Fortran
Adam: Again, not sure if this needs to be done?
Torsten: agree - please ignore this
38.i ? EDIT p177.48 move orphaned Example header to next page (might
change after edits though -> check chapter for orphans)
38.j ? EDIT p179.24 the font suddenly changes? (sans-serif)
Adam: Haven't checked these two in the recent document. I suppose some of the
checks will need to wait until the final copy is available for reading.
Torsten: yes, I just wanted to remind us to do it at the end.
38.k ? CLAR p179.27 maybe we should add: "and to ensure appropriate
matching (for deterministic behavior)"
Adam: I'll leave this one to the Forum.
Torsten: ok
Rajeev Thakur, ANL, Apr. 25, 2008
---------------------------------
(references to versions Apr. 19, 2008):
In the backmatter:
------------------
42.k 22 Using all TYPEDEF:MPI.* entries in the Index to build a Typedef Index
It may be possible to add also references to the C types mentioned
at 486/39-48 and 523/14, 525/21-23, and 503/19-32, 507/40
Editor's comment: locations not found. Sorry
Jesper Traeff (traeff_chap.1+2_mpi-2.1-reviews.txt)
-------------
Chapter 2: Terms and Conventions
********************************
46.b 22 p.9, line 15-19: drop (or reformulate)
Editor's comment: It is a historical change-information.
Reformulation does not exist, nor move to Chap. Changes.
Therefore postponed to MPI-2.2
Jesper Traeff (traeff_chap.3+4_mpi-2.1-reviews.txt)
-------------
48.g ? p.55, line 22-24
is this true?
Chapter 10. Process Creation and Management
*******************************************
Dries Kimpe (kimpe_chap.10-mpi-2.1-reviews.txt)
-----------
61.e 22 Maybe references are needed for pg 290 (10.2.1) , line 26-27:
CMOST, POE and p4 are mentioned without explaining what
they are or where to find information about them;
POE is layared software?
p4 is an rsh command?
61.g 22 maybe it is just me, but the 'Catch 22' on pg. 303,l2
is confusing. Maybe this reference is widely known by native
speakers, but I never saw this reference until now.
Does this really need to be in a standard?
If it adds something to the text, than there should be a reference;
If not, it shouldn't be there.
Editor's comment:
My dictionaries tell "Catch-22" and "catch-22", but not "Catch 22".
DONE I decided to correct "Catch 22" into "Catch-22".
22 For MPI-2.2, I propose to substitute "Catch-22" by
"a difficult situation".
Chapter 12: External Interfaces
*******************************
Bronis de Supinski (supinski_chap.12_mpi-2.1-review.txt) ------------------ 64.u 22 Should MPI_Init be deprecated? -> For MPI 3 Decision: Defer to MPI 3 Chapter 13: MPI I/O *******************
Quicey Koziol (koziol-chapter13-mpi21.txt)
-------------
65.g 22 Clarify who the "client" is on p.412, line 21
Editor's comment: --> MPI-2.2
Chapter 16: Language Bindings
*****************************
Puri Bangalore (puri-mpi2.1-chapter16-review.txt)
--------------
68.h 22 p461.40 and p468.31: Do we want to extend the "basic Fortran support"?
Decision: Ignore
Annex B: Change-Log
*******************
Puri Bangalore (puri-changelog-mpi-2.1-review.txt)
--------------
70.e ? Does this list really capture all the major changes?
Editor's comment:
This was my goal and I tried to do my best.
The future will show, whether the list is complete.
Decision: Ignore
70.e' ? Item 1: not sure what this means: "otherwise it is collective
over the union of all processes that have been and continue to be
connected,"
Editor's Comment:
Text is identical to Ballot-text.
Decision: Ignore
Jeff Squyres (jsquyres-for-rolf-2.1.txt)
------------
Examples Index
--------------
71.c ? - There are still a bunch of repeated names, some in all caps, some in
mixed case, etc.
71.d ? - There are some examples listed just by MPI function name (e.g.,
MPI_SEND and MPI_Send) -- are we listing every MPI function in every
MPI example? How was the selection for these example names given?
Editor's comment:
I tried to pick major routines in the examples (sometimes not all).
Additionally, for some examples, I defined titles for the Index.
Constant Index
--------------
71.e ? - The first entry is still "MPI::*_NULL"
71.f ? - Are we listing the C++ constants and Fortran constants here, too?
Or just the C constants? Or just language neutral? (I only see C++
predefined datatypes listed -- should we list all or none of them?)
Declarations Index
------------------
71.h 22 - I don't see the MPI C++ subtypes (e.g., MPI::Intercomm).
Editor (WDG): These are now visible - this item can be removed.
Callback function prototype index
---------------------------------
71.i 22 - C++ types are missing
Editor (WDG): The index is for the C prototypes and points out that
the C++ and Fortran versions are close to the C versions. Do we need
to make any changes here (if we add C++, we must also add Fortran)?
Additional items from the meeting Apr. 28-30, 2008
--------------------------------------------------
74.f 22 Changes in the chapter and section titles need to runs of "make" to
get updated the bookmarklist of mpi-report.pdf. This seems to be a bug
in the Makefile.
Workaround: "make; make" (calling "make" twice)
74.k 22 Bug in the Makefile produces these error lines on stderr:
make: Circular graphics_pdf <- mpi-report.pdf dependency dropped.
make: Circular appLang-CNames.tex <- appLang-CNames.tex dependency
dropped.
--------------------------
Statistics:
grep '^..... OK ' MPI-2.1-reviews_open-issues.txt | wc -l
grep '^.....DONE' MPI-2.1-reviews_open-issues.txt | wc -l
grep '^.....D1.3' MPI-2.1-reviews_open-issues.txt | wc -l
grep '^..... ? ' MPI-2.1-reviews_open-issues.txt | wc -l
grep '^..... R2 ' MPI-2.1-reviews_open-issues.txt | wc -l
grep '^.....DON2' MPI-2.1-reviews_open-issues.txt | wc -l
grep '^..... 22 ' MPI-2.1-reviews_open-issues.txt | wc -l
grep '^..... Q? ' MPI-2.1-reviews_open-issues.txt | wc -l
grep '^.....\*NO\*' MPI-2.1-reviews_open-issues.txt | wc -l
egrep '^..... OK |^.....DONE|^.....D1.3|^..... \? |^..... R2 |^.....DON2|^..... 22 |^..... Q\? |^.....\*NO\*' MPI-2.1-reviews_open-issues.txt | wc -l
Printing of this document:
a2ps --line-numbers=0 -2 -l 83 --prologue=bold --delegate no -o MPI-2.1-reviews_open-issues.ps MPI-2.1-reviews_open-issues.txt
epstopdf --exact MPI-2.1-reviews_open-issues.ps
psselect -p1 -p20-100 MPI-2.1-reviews_open-issues.ps | lpr
1234567890123456789012345678901234567890123456789012345678901234567890123456789012