Hi Jeff, Ugh, this whole chapter (not the count ticket itself) needs major editing. It's poorly organized and it talks about and uses deprecated concepts all over the place. I'll work with Quincey to propose a better version (along with a full set of MPI_Count datatype calls). Here are some comments for the count ticket. p 16, line 15 Change "Derived datatypes can be created representing more elements than can be encoded in a C int or Fortran INTEGER. MPI_GET_COUNT, MPI_GET_ELEMENTS, and associated functions cannot properly express these quantities. To overcome this limitation, these quatities are declared to be INTEGER (KIND=MPI_COUNT_KIND) in Fortran. In C, one uses MPI_Count." to "As described above, MPI defines one type to address locations within memory and another type to address locations within a file. However, at times, one needs a single type that can be used to address locations within either memory or a file. Furthermore, one needs this type to also any value stored in a C int or Fortran INTEGER. For this, MPI defines the datatype MPI_Count in C and INTEGER (KIND=MPI_COUNT_KIND) in Fortran." p 16, line 23-24 Change "in a variable of type C int, MPI_Aint, MPI_Offset, or Fortran INTEGER." to "in a variable of type int, MPI_Aint, or MPI_Offset in C and Fortran INTEGER, INTEGER(KIND=MPI_ADDRESS_KIND), or INTEGER (KIND=MPI_OFFSET_KIND) in Fortran." p 99, line 14-18 The whole paragraph is all about the old stuff, which just confuses a new reader. I would just drop it (or move it toward the end), and replace it with something like: "The following functions return the lower bound and the extent of a datatype." If on the otherhand we want to leave, it there are some typos (extra period after MPI_TYPE_EXTENT and "address sized integers" probably means MPI_ADDRESS_KIND, so we should just say "larger sized integers" or something like that): "MPI_TYPE_EXTENT. and also return address sized integers" --> "MPI_TYPE_EXTENT and also return larger sized integers" I vote to just drop and replace it, though. Question: What if MPI_TYPE_GET_EXTENT overflows? p 100, line 48 "MPI_TYPE_GET_TRUE_EXTENT and ..." --> "The functions MPI_TYPE_GET_TRUE_EXTENT and ..." p 105, line 27 "query function MPI_GET_ELEMENTS." --> "query functions MPI_GET_ELEMENTS or MPI_GET_ELEMENTS_X." p 106, line 20 "the MPI_GET_COUNT sets the value of count to" --> "the function sets the value of count to" p 106, line 20 Move sentence about overflow up to other sentence about MPI_UNDEFINED, and reword it a bit. "Furthermore, if the number of basics elements is an integral number of datatype copies but this magnitude of this value exceeds the limits of the count parameter, then the function sets the value of count to MPI_UNDEFINED." -Adam Jeff Squyres wrote:

PDFs have been attached to the 2 MPI_Count tickets for a formal reading at the Chicago Forum meeting in 2 weeks:

- General MPI_Count ticket https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 - "W" versions of some collectives https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/269

Remember that the solution we're proposing here is the "minimal" MPI_Count approach: adding a small number of new functions that take MPI_Count arguments so that MPI can claim to fully support arbitrary-sized counts.

Enjoy your light reading. :-)