Dear all, I have trhee concerns and hopefully resolvable through an errata before second vote. All my references to https://github.com/mpi-forum/mpi-issues/files/5022345/mpi40-report-ticket137... 1. Concern: Sect. 18.2 page 779, lines 32-35 tell: The "_l" suffixed MPI procedure has MPI_Count for all count parameters, MPI_Aint for all parameters that represent byte displacement in memory, and MPI_Count for all parameters that represent byte displacement in fi les. MPI_File_seek with MPI_SEEK_CUR moves the file pointer by an offset in bytes in the default fileview is used. It is also in the _l version defined as MPI_Offset. In MPI_File_set_view, the "MPI_Offset disp" explicitely defines an "displacement" (Sect. 13.3 page 596 line 25). I expect that this is decided (and in my opinion a good decision), but the text in 18.2 should be corrected, for example with an additional sentence like In MPI_File_... procedures, arguments of type MPI_Offset are not changed to MPI_Count although they may contain byte displacements in files. 2. Concern: It is not described in the 18.2, that "byte displacements in files" is related to all MPI_File_... and derived datatype procedures. 3. Concern: I mentioned very early, that the displacement in the derived data type procedures may be used - for relative displacements used for memeory and files, but never in combination with MPI_BOTTOM, or - for absolute displacements in memory in combination with MPI_BOTTOM. int MPI_Type_create_hindexed(int count, const int array_of_blocklengths[], const MPI_Aint array_of_displacements[], MPI_Datatype oldtype, MPI_Datatype *newtype) can be used for relative and absolute displacements, but only with blocklength in int. (A) int MPI_Type_create_hindexed_l(MPI_Count count, const MPI_Count array_of_blocklengths[], const MPI_Count array_of_displacements[], MPI_Datatype oldtype, MPI_Datatype *newtype) can only be used for relative displacements in memory and files, but not for absolute displ in memory with MPI_BOTTOM. This means absolute displacements (i.e. with MPI_Aint) together with MPI_Count blocklength (B) is missing. For a few routines a second interface (B) would have been needed. In my opinion, it is okay to provide A and not B, but this should be clearly documented in 18.2. A simple reason is, that nearly all, what one could do with MPI_BOTTOM, one can also do with normal buffers, and there, A works. And A works also for files, but B not. Summarizing, I expect that the APIs are okay, but 18.2 is missing some short explanations of exceptions and decisions. Best regards Rolf ----- Original Message -----
From: "Main MPI Forum mailing list" <[email protected]> To: "Main MPI Forum mailing list" <[email protected]> Cc: "Anthony Skjellum" <[email protected]> Sent: Tuesday, August 4, 2020 3:33:53 PM Subject: [Mpi-forum] Announcing/Reconfirming 2nd Vote on Ticket #137 - Enbiggenment (Large Counts)
Hi, this is the two-week vote announcement for Ticket #137, which is already on the agenda.
Issue: [ https://github.com/mpi-forum/mpi-issues/issues/137 | https://github.com/mpi-forum/mpi-issues/issues/137 ]
Pull request: [ https://github.com/mpi-forum/mpi-standard/pull/132 | https://github.com/mpi-forum/mpi-standard/pull/132 ]
PDF: [ https://github.com/mpi-forum/mpi-issues/files/5022345/mpi40-report-ticket137... | https://github.com/mpi-forum/mpi-issues/files/5022345/mpi40-report-ticket137... ] One outstanding issue is being discussed, and there may be no-no vote proposed also, tbd.
Thanks, Tony and Puri on behalf of the Large Counts WG.
-- Anthony Skjellum, PhD [ mailto:[email protected] | [email protected] ] Cell: +1-205-807-4968
_______________________________________________ mpi-forum mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 . University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 . Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner . Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) .