January 2008 - Mpi-21 - mailman3.cels.anl.gov

Ballot 4 - Re: MPI_Abort nit
by unknown＠example.com 29 Jan '08

29 Jan '08

This is a proposal for MPI 2.1, Ballot 4. I'm asking especially Karl Feind, Bill Gropp, Andrew Lumsdaine, Dick Treumann, the participants of the email-discussion in 2001, to review this proposal. This is a follow up to: MPI_Abort in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… ___________________________________ Proposal: MPI-1.1 Sect. 7.5, MPI_Abort, page 200, lines 23-26 read: This routine makes a "best attempt" to abort all tasks in the group of comm. This function does not require that the invoking environment take any action with the error code. However, a Unix or POSIX environment should handle this as a return errorcode from the main program or an abort(errorcode). but should read (" or an abort(errorcode)" removed): This routine makes a "best attempt" to abort all tasks in the group of comm. This function does not require that the invoking environment take any action with the error code. However, a Unix or POSIX environment should handle this as a return errorcode from the main program. ___________________________________ Rationale for this clarification: POSIX defines void abort(void). The routine void exit(int status) may be used to implement "handle this as a return errorcode from the main program". abort(errorcode) was not substituted by exit(errorcode) because this is technically not enough, if the MPI implementation wants to return it also from mpiexec, see next proposal. ___________________________________ Proposal: Add after MPI-1.1 Sect. 7.5, MPI_Abort, page 200, line 34 (end of rationale): Advice to users. Whether the errorcode is returned from the executable or from the MPI process startup mechanism (e.g., mpiexec), is an aspect of quality of the MPI library but not mandatory. (End of advice to users.) ___________________________________ Rationale for this clarification: The intent of word "should" in "should handle this as a return errorcode from the main program" is only a quality of implementation aspect and not a must. This is not clear and can be misinterpreted. ___________________________________ Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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: Allmandring 30)

1 0

Re: [mpi-21] MPI_FINALIZE
by unknown＠example.com 28 Jan '08

28 Jan '08

Mainly to Jeff Squyres, Hubert Ritzdorf, Rolf Rabenseifner, Nicholas Nevin, Bill Gropp, Dick Treumann This is a follow up to: MPI_FINALIZE in MPI-2 (with spawn) in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… _________________________________________ When I understand correctly, then a clarification is not needed because the MPI standard expresses all, i.e. - MPI_Finalize need not to behave like a barrier - but is allowed to have a barrier inside. - If the user wants to exit one spawned process while the others still continue to work, he/she must disconnect this process before calling MPI_Finalize on it. If somebody wants a clarification to be included into the standard and therefore in Ballot 4, please send me your wording with the page and line references included. If all agree, that no clarification is needed, then I would finish this track. Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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: Allmandring 30)

1 0

Ballot 4 - Re: Re: SEND COUNT and RECEIVE COUNT
by unknown＠example.com 28 Jan '08

28 Jan '08

Bill, please can you forward this to Yukiya Aoyama <aoyama_at_...>, the originator of this track. Thanks, Rolf ___________________________________ This is a proposal for MPI 2.1, Ballot 4. This is a follow up to: Description of the send and receive count arguments to MPI_Alltoallv in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… Based on the questions for clarification, I propose not to include any further clarification into the standard. Reason: MPI-1, Sect. 4.8, MPI_ALLTOALLV, page 112, lines 37-40 clearly states: "The type signature associated with sendcount[j], sendtype at process i must be equal to the type signature associated with recvcount[i], recvtype at process j. This implies that the amount of data sent must be equal to the amount of data received, pairwise between every pair of processes. Distinct type maps between sender and receiver are still allowed." The same text is also used for MPI-2.0, Sect. 7.3.5 MPI_ALLTOALLW, page 165, lines 42-45. Okay? Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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: Allmandring 30)

1 0

Ballot 4 - Why no MPI_INPLACE for MPI_EXSCAN?
by unknown＠example.com 28 Jan '08

28 Jan '08

This is a proposal for MPI 2.1, Ballot 4. This is a follow up to: Why no MPI_INPLACE for MPI_EXSCAN? in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… Bill Gropp has already put a proposal on the web page. I would chang the location: Instead of putting the clarification at the end of the Advice to users, I would add at the beginning of the 2nd paragraph of the Rationale. Proposal for MPI 2.1, Ballot 4: ------------------------------- MPI-2, Sect. 7.3.6, page 167. lines 6-8 read: The reason that MPI-1 chose the inclusive scan is that the definition of behavior on processes zero and one was thought to offer too many complexities in definition, particularly for user-defined operations. (End of rationale.) but should read: No in-place version is specified for MPI_EXSCAN because it isn't clear what this means for the process for rank zero. The reason that MPI-1 chose the inclusive scan is that the definition of behavior on processes zero and one was thought to offer too many complexities in definition, particularly for user-defined operations. (End of rationale.) ------------------------------- Background information: The total rationale On MPI-2 page 167 would be then Rationale. The exclusive scan is more general than the inclusive scan provided in MPI-1 as MPI SCAN. Any inclusive scan operation can be achieved by using the exclusive scan and then locally combining the local contribution. Note that for noninvertable operations such as MPI MAX, the exclusive scan cannot be computed with the inclusive scan. No in-place version is specified for MPI_EXSCAN because it isn't clear what this means for the process for rank zero. The reason that MPI-1 chose the inclusive scan is that the definition of behavior on processes zero and one was thought to offer too many complexities in definition, particularly for user-defined operations. (End of rationale.) Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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: Allmandring 30)

1 0

Re: [mpi-21] MPI_GET_PROCESSOR_NAME Fortran and C
by unknown＠example.com 28 Jan '08

28 Jan '08

Dick, your right and it is already decided: MPI 1.1 Sect. 7.1 page 193, lines 13-14: "This routine returns the name of the processor on which it was called at the moment of the call." And lines 22-25: "Rationale. This function allows MPI implementations that do process migration to return the current processor. Note that nothing in MPI requires or defines process migration; this definition of MPI GET PROCESSOR NAME simply allows such an implementation. (End of rationale.)" I.e., current location, i.e., it may change in case of check point/restart and all the other reasons you mentioned. I would say, that the sentences above are clear enough. Okay? Best regards Rolf On Fri, 25 Jan 2008 15:32:07 -0500 Richard Treumann <treumann_at_[hidden]> wrote: >We also should decide whether every call to MPI_GET_PROCESSOR_NAME across >the life of the task must return the same name. On very large machines >running very large jobs, migration of some tasks off of failing nodes and >on to robust nodes will become more interesting. Checkpoint/restart raises >the same issue. A restarted job will probably not have the same task to >node mapping. > >We can either require the name to remain constant and allow that it might >be a "virtual" name or require that it return an "actual" name but allow it >to change. > > Dick > >Dick Treumann - MPI Team/TCEM >IBM Systems & Technology Group >Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 >Tele (845) 433-7846 Fax (845) 433-8363 > > >mpi-21-bounces_at_[hidden] wrote on 01/25/2008 12:00:42 PM: > >> This is a discussion-point for MPI 2.1, Ballot 4. >> >> This is a follow up to: >> MPI_GET_PROCESSOR_NAME and Fortran >> in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >> errata/index.html >> with mail discussion in >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >> errata/discuss/procname/ >> >> _________________________________________________________________ >> >> MPI_GET_PROCESSOR_NAME and Fortran >> and in C and all MPI_xxxx_GET_NAME routines >> ------------------------------------------- >> >> Summary: Returning strings is defined in MPI_GET_PROCESSOR_NAME >> and MPI_xxxx_GET_NAME quite different. Not all implementations >> are doing the same with zero-filling. And what they do is >> at least with MPI_GET_PROCESSOR_NAME different to what >> the current standard requires. A propose to adapt the standard >> to the common reasonable implementations. >> The very short proposal for clarification can be found at the >> end of this text, see C. Proposal. >> >> A. MPI_GET_PROCESSOR_NAME ... >> B. MPI_COMM_GET_NAME (and other MPI_xxxx_GET_NAME) ... >> C. Proposal: >> ------------ >> >> Add the following sentences to the current interface definitions: >> ------------------ >> In C, a \0 is additionally stored at name[resultlen]. resultlen >> cannot be larger then MPI_MAX_PROCESSOR_NAME-1 >> (or MPI_MAX_OBJECT_NAME-1). In Fortran, name(resultlen+1:) >> is filled with spaces. resultlen cannot be larger then >> MPI_MAX_PROCESSOR_NAME (or MPI_MAX_OBJECT_NAME). >> ------------------ >> >> Typo correction: >> ---------------- >> MPI-1.1 Sect. 7.1, page 193, beginning of line 29 reads >> examine the ouput argument >> But should read (additional t in output) >> examine the output argument >> >> >> Okay? >> _________________________________________________________________ >> >> Best regards >> Rolf >> >> PS: Attached my tests and short protocols >> >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> 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: Allmandring 30) >> [attachment "mpi_get_xxx_name.tar.gz" deleted by Richard >> Treumann/Poughkeepsie/IBM] >_______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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: Allmandring 30)

1 0

Re: [mpi-21] MPI_GET_PROCESSOR_NAME Fortran and C
by unknown＠example.com 25 Jan '08

25 Jan '08

We also should decide whether every call to MPI_GET_PROCESSOR_NAME across the life of the task must return the same name. On very large machines running very large jobs, migration of some tasks off of failing nodes and on to robust nodes will become more interesting. Checkpoint/restart raises the same issue. A restarted job will probably not have the same task to node mapping. We can either require the name to remain constant and allow that it might be a "virtual" name or require that it return an "actual" name but allow it to change. Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 01/25/2008 12:00:42 PM: > This is a discussion-point for MPI 2.1, Ballot 4. > > This is a follow up to: > MPI_GET_PROCESSOR_NAME and Fortran > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/index.html > with mail discussion in > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/discuss/procname/ > > _________________________________________________________________ > > MPI_GET_PROCESSOR_NAME and Fortran > and in C and all MPI_xxxx_GET_NAME routines > ------------------------------------------- > > Summary: Returning strings is defined in MPI_GET_PROCESSOR_NAME > and MPI_xxxx_GET_NAME quite different. Not all implementations > are doing the same with zero-filling. And what they do is > at least with MPI_GET_PROCESSOR_NAME different to what > the current standard requires. A propose to adapt the standard > to the common reasonable implementations. > The very short proposal for clarification can be found at the > end of this text, see C. Proposal. > > A. MPI_GET_PROCESSOR_NAME > ------------------------- > > MPI_GET_PROCESSOR_NAME defines the returned string with several > sentences: > > (1) OUT name A unique specifier for the actual > (as opposed to virtual) node. > (2) OUT resultlen Length (in printable characters) > of the result returned in name > > (3) The argument name must represent storage that is at least > MPI_MAX_PROCESSOR_NAME characters long. > (4) MPI_GET_PROCESSOR_NAME may write up to this many characters > into name. > (5) The number of characters actually written is returned > in the output argument, resultlen. > (6) The user must provide at least MPI_MAX_PROCESSOR_NAME > space to write the processor name â processor names > can be this long. > (7) The user should examine the ouput argument, resultlen, > to determine the actual length of the name. > > I tested 5 implementations with C and Fortran. > > I called MPI_GET_PROCESSOR_NAME with a string (i.e. character > array) with size MPI_MAX_PROCESSOR_NAME+2. > > C-Interface: > ------------ > All tested C implementations returned the processor-name > in name[0..resultlen-1] and a the non-printable character > \0 in name[resultlen]. > All other elements of name were unchanged. > > (1,2,3,4, 6,7) are fulfilled; > (5) are __NOT__ fulfilled, because resultlen+1 characters > are written in name. > > My opinion: The returned name and resultlen is what the user > expects, but the standard needs a clarification. > > Fortran-Interface: > ------------------ > All tested Fortran implementations return in processor-name > in name(1:resultlen) and the rest of the total string is > filled with spaces. > > (1, 3, 6,7) are fulfilled; > (2,4,5) are __NOT__ fulfilled, because > MPI_MAX_PROCESSOR_NAME+2 characters are written in name. > > My opinion: The returned name and resultlen is what the user > expects, but the standard needs a clarification. > > > B. MPI_COMM_GET_NAME (and other MPI_xxxx_GET_NAME) > -------------------------------------------------- > > The string output is defined with different wording: > > (1) OUT comm_name the name previously stored on the > communicator, or an empty string if no > such name exists (string) > (2) OUT resultlen length of returned name (integer) > > (3) name should be allocated so that it can hold a resulting > string of length MPI_MAX_OBJECT_NAME characters. > (4) If the user has not associated a name with a communicator, > or an error occurs, MPI_COMM_GET_NAME will return an empty > string (all spaces in Fortran, "" in C and C++). > > and in the definition of MPI_COMM_SET_NAME: > (5) The length of the name which can be stored is limited > to the value of MPI_MAX_OBJECT_NAME in Fortran and > MPI_MAX_OBJECT_NAME-1 in C and C++ to allow for the null > terminator. > (6) Attempts to put names longer than this will result in > truncation of the name. > (7) MPI_MAX_OBJECT_NAME must have a value of at least 64. > > I called MPI_COMM_GET_NAME with a string (i.e. character > array) with size MPI_MAX_OBJECT_NAME+2. > > C-Interface: > ------------ > All tested C implementations returned the communicator-name > in comm_name[0..resultlen-1] and a the non-printable character > \0 in comm_name[resultlen]. > One implementation filled up the rest until > name[MPI_MAX_OBJECT_NAME-1] with \0. > In all other implementations, all other elements of comm_name > were unchanged. > > (1-7) are fulfilled although the retuned zero-filling in comm_name > depends on the implementations; > > My opinion: A clarification can make the API unambiguous. > > Fortran-Interface: > ------------------ > All tested Fortran implementations return in processor-name > in name(1:resultlen) and the rest of the total string is > filled with spaces. > > (1-7) are fulfilled; > Although it is nowhere specified that the string must be filled > up with spaces, and not only until position MPI_MAX_OBJECT_NAME > but also further spaces until the end of comm_name. > > My opinion: The returned name and resultlen is what the user > expects, but the standard needs a clarification. > > C. Proposal: > ------------ > > Add the following sentences to the current interface definitions: > ------------------ > In C, a \0 is additionally stored at name[resultlen]. resultlen > cannot be larger then MPI_MAX_PROCESSOR_NAME-1 > (or MPI_MAX_OBJECT_NAME-1). In Fortran, name(resultlen+1:) > is filled with spaces. resultlen cannot be larger then > MPI_MAX_PROCESSOR_NAME (or MPI_MAX_OBJECT_NAME). > ------------------ > > Typo correction: > ---------------- > MPI-1.1 Sect. 7.1, page 193, beginning of line 29 reads > examine the ouput argument > But should read (additional t in output) > examine the output argument > > > Okay? > _________________________________________________________________ > > Best regards > Rolf > > PS: Attached my tests and short protocols > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > 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: Allmandring 30) > [attachment "mpi_get_xxx_name.tar.gz" deleted by Richard > Treumann/Poughkeepsie/IBM] _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

Re: [mpi-21] MPI_GET_PROCESSOR_NAME Fortran and C
by unknown＠example.com 25 Jan '08

25 Jan '08

This is a discussion-point for MPI 2.1, Ballot 4. This is a follow up to: MPI_GET_PROCESSOR_NAME and Fortran in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… _________________________________________________________________ MPI_GET_PROCESSOR_NAME and Fortran and in C and all MPI_xxxx_GET_NAME routines ------------------------------------------- Summary: Returning strings is defined in MPI_GET_PROCESSOR_NAME and MPI_xxxx_GET_NAME quite different. Not all implementations are doing the same with zero-filling. And what they do is at least with MPI_GET_PROCESSOR_NAME different to what the current standard requires. A propose to adapt the standard to the common reasonable implementations. The very short proposal for clarification can be found at the end of this text, see C. Proposal. A. MPI_GET_PROCESSOR_NAME ------------------------- MPI_GET_PROCESSOR_NAME defines the returned string with several sentences: (1) OUT name A unique specifier for the actual (as opposed to virtual) node. (2) OUT resultlen Length (in printable characters) of the result returned in name (3) The argument name must represent storage that is at least MPI_MAX_PROCESSOR_NAME characters long. (4) MPI_GET_PROCESSOR_NAME may write up to this many characters into name. (5) The number of characters actually written is returned in the output argument, resultlen. (6) The user must provide at least MPI_MAX_PROCESSOR_NAME space to write the processor name  processor names can be this long. (7) The user should examine the ouput argument, resultlen, to determine the actual length of the name. I tested 5 implementations with C and Fortran. I called MPI_GET_PROCESSOR_NAME with a string (i.e. character array) with size MPI_MAX_PROCESSOR_NAME+2. C-Interface: ------------ All tested C implementations returned the processor-name in name[0..resultlen-1] and a the non-printable character \0 in name[resultlen]. All other elements of name were unchanged. (1,2,3,4, 6,7) are fulfilled; (5) are __NOT__ fulfilled, because resultlen+1 characters are written in name. My opinion: The returned name and resultlen is what the user expects, but the standard needs a clarification. Fortran-Interface: ------------------ All tested Fortran implementations return in processor-name in name(1:resultlen) and the rest of the total string is filled with spaces. (1, 3, 6,7) are fulfilled; (2,4,5) are __NOT__ fulfilled, because MPI_MAX_PROCESSOR_NAME+2 characters are written in name. My opinion: The returned name and resultlen is what the user expects, but the standard needs a clarification. B. MPI_COMM_GET_NAME (and other MPI_xxxx_GET_NAME) -------------------------------------------------- The string output is defined with different wording: (1) OUT comm_name the name previously stored on the communicator, or an empty string if no such name exists (string) (2) OUT resultlen length of returned name (integer) (3) name should be allocated so that it can hold a resulting string of length MPI_MAX_OBJECT_NAME characters. (4) If the user has not associated a name with a communicator, or an error occurs, MPI_COMM_GET_NAME will return an empty string (all spaces in Fortran, "" in C and C++). and in the definition of MPI_COMM_SET_NAME: (5) The length of the name which can be stored is limited to the value of MPI_MAX_OBJECT_NAME in Fortran and MPI_MAX_OBJECT_NAME-1 in C and C++ to allow for the null terminator. (6) Attempts to put names longer than this will result in truncation of the name. (7) MPI_MAX_OBJECT_NAME must have a value of at least 64. I called MPI_COMM_GET_NAME with a string (i.e. character array) with size MPI_MAX_OBJECT_NAME+2. C-Interface: ------------ All tested C implementations returned the communicator-name in comm_name[0..resultlen-1] and a the non-printable character \0 in comm_name[resultlen]. One implementation filled up the rest until name[MPI_MAX_OBJECT_NAME-1] with \0. In all other implementations, all other elements of comm_name were unchanged. (1-7) are fulfilled although the retuned zero-filling in comm_name depends on the implementations; My opinion: A clarification can make the API unambiguous. Fortran-Interface: ------------------ All tested Fortran implementations return in processor-name in name(1:resultlen) and the rest of the total string is filled with spaces. (1-7) are fulfilled; Although it is nowhere specified that the string must be filled up with spaces, and not only until position MPI_MAX_OBJECT_NAME but also further spaces until the end of comm_name. My opinion: The returned name and resultlen is what the user expects, but the standard needs a clarification. C. Proposal: ------------ Add the following sentences to the current interface definitions: ------------------ In C, a \0 is additionally stored at name[resultlen]. resultlen cannot be larger then MPI_MAX_PROCESSOR_NAME-1 (or MPI_MAX_OBJECT_NAME-1). In Fortran, name(resultlen+1:) is filled with spaces. resultlen cannot be larger then MPI_MAX_PROCESSOR_NAME (or MPI_MAX_OBJECT_NAME). ------------------ Typo correction: ---------------- MPI-1.1 Sect. 7.1, page 193, beginning of line 29 reads examine the ouput argument But should read (additional t in output) examine the output argument Okay? _________________________________________________________________ Best regards Rolf PS: Attached my tests and short protocols Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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: Allmandring 30) *

1 0

Proposal: MPI_OFFSET built-in type
by unknown＠example.com 24 Jan '08

24 Jan '08

I hope this is less contentious than adding 'const' keywords... I would like to propose a new built-in type MPI_OFFSET, defined to be a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or MPI_Offset This is a minor addition to the standard, which would have no impact on existing code while serving to simplify code which exchanges file offsets among processes. There is a workaround in the standard: a user can define a type from MPI_BYTE: MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); However, it would clearly be more convienient to operate on built-in types. MPI Datatype: MPI_OFFSET Corresponding C type: long long int Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) Thanks ==rob -- Rob Latham Mathematics and Computer Science Division A215 0178 EA2D B059 8CDF Argonne National Lab, IL USA B29D F333 664A 4280 315B

1 0

Re: [mpi-21] Ballot 4 - 0-dim MPI_CART_CREATE and MPI_CART_SUB
by unknown＠example.com 24 Jan '08

24 Jan '08

On Thu, 24 Jan 2008 21:26:09 +0800 "William Yu" <wyu_at_[hidden]> wrote: >Understood. Nice work. Thanks! Thank you. And here is the proposal to correct all the unclear specifications on Cartesian topologies. This is a proposal for MPI 2.1, Ballot 4. ________________________________________________________________ Proposal about handling zero-dimensional Cartesian communicators that are produced with MPI_Cart_sub if all remain_dims are false. MPI-1.1 Sect.6.5.4, page 187, lines 38-42 (definition of MPI_Cart_sub) reads If a cartesian topology has been created with MPI_CART_CREATE, the function MPI_CART_SUB can be used to partition the communicator group into subgroups that form lower-dimensional cartesian subgrids, and to build for each subgroup a communicator with the associated subgrid cartesian topology. (This function is closely related to MPI_COMM_SPLIT.) but should read If a cartesian topology has been created with MPI_CART_CREATE, the function MPI_CART_SUB can be used to partition the communicator group into subgroups that form lower-dimensional cartesian subgrids, and to build for each subgroup a communicator with the associated subgrid cartesian topology. If all entries in remain_dims are false or comm is already associated with a zero-dimensional Cartesian topology then newcomm is associated with a zero-dimensional Cartesian topology. (This function is closely related to MPI_COMM_SPLIT.) Rationale for this clarification (not to be included into the MPI standard): Several MPI implementations have implemented the MPI-1 standard which requires a "lower-dimensional cartesian" subgrid and that newcomm is "associated" with the "subgrid Cartesian topology". Other MPI implementations did not or only partially. Therefore, a clarification may help that all MPI implementations implment the same interface. ________________________ MPI-1.1 Sect.6.5.4, page 183, lines 29-30 (definition of MPI_Cartdim_get and MPI_Cart_get) reads: The functions MPI_CARTDIM_GET and MPI_CART_GET return the cartesian topology information that was associated with a communicator by MPI_CART_CREATE. but should read The functions MPI_CARTDIM_GET and MPI_CART_GET return the cartesian topology information that was associated with a communicator by MPI_CART_CREATE. If comm is associated with a zero-dimensional Cartesian topology, MPI_Cartdim_get returns ndims=0 and MPI_Cart_get will keep all output arguments unchanged. Rationale for this clarification (not to be included into the MPI standard): Zero-dimensional topologies have zero coords, i.e., do not have coords and therefore also no dims, or periods. ________________________ MPI-1.1 Sect.6.5.4, page 184, lines 17-23 (definition of MPI_Cart_rank) reads For a process group with cartesian structure, the function MPI_CART_RANK translates the logical process coordinates to process ranks as they are used by the point-to-point routines. For dimension i with periods(i) = true, if the coordinate, coords(i), is out of range, that is, coords(i) < 0 or coords(i) >= dims(i), it is shifted back to the interval 0 <= coords(i) < dims(i) automatically. Out-of-range coordinates are erroneous for non-periodic dimensions. but should read For a process group with cartesian structure, the function MPI_CART_RANK translates the logical process coordinates to process ranks as they are used by the point-to-point routines. For dimension i with periods(i) = true, if the coordinate, coords(i), is out of range, that is, coords(i) < 0 or coords(i) >= dims(i), it is shifted back to the interval 0 <= coords(i) < dims(i) automatically. Out-of-range coordinates are erroneous for non-periodic dimensions. If comm is associated with a zero-dimensional Cartesian topology, coord is not significant and 0 is returned in rank. Rationale for this clarification (not to be included into the MPI standard): Zero-dimensional topologies have zero coords, i.e., do not have coords. The communicator has only one process and therefore only the rank 0 is valid. ________________________ MPI-1.1 Sect.6.5.4, page 184, lines 38-39 (definition of MPI_Cart_coords) reads The inverse mapping, rank-to-coordinates translation is provided by MPI CART COORDS. but should read The inverse mapping, rank-to-coordinates translation is provided by MPI CART COORDS. If comm is associated with a zero-dimensional Cartesian topology, coords will be unchanged. Rationale for this clarification (not to be included into the MPI standard): Zero-dimensional topologies have zero coords, i.e., do not have coords. ________________________ Alternative 1: -------------- MPI-1.1 Sect.6.5.5, page 186, after line 47 (end of definition of MPI_Cart_shift), the following paragraph is added: It is erroneous to call MPI_CART_SHIFT with comm that is associated with a zero-dimensional Cartesian topology. Rationale for this clarification (not to be included into the MPI standard): It is impossible to define a correct input for direction because there does not exist any directions in a zero-dimensional topology. (This is currently implemented by several MPI implementations.) Alternative 2: -------------- MPI-1.1 Sect.6.5.5, page 186, after line 47 (end of definition of MPI_Cart_shift), the following paragraph is added: If comm is associated with a zero-dimensional Cartesian topology, then the input arguments direction and disp are ignored and always MPI_PROC_NULL is returned in rank_source and rank_dest. Rationale for this clarification (not to be included into the MPI standard): It is impossible to define a correct input for direction because there does not exist any directions in a zero-dimensional topology. For convenience, the routine returns MPI_PROC_NULL. _______________________ MPI-1.1 Sect.6.5.1, page 179, lines 29-30 (end of definition of MPI_Cart_create) reads The call is erroneous if it specifies a grid that is larger than the group size. but should read The call is erroneous if it specifies a grid that is larger than the group size or ndims is zero or negative. Rationale for this clarification (not to be included into the MPI standard): Although it is allowed to produce zero-dimensional subgrids with MPI_CART_SUB, it makes no sense to establish a zero-dimensional grid a priori with MPI_CART_CREATE. _______________________ MPI-1.1 Sect.6.5.4, page 184, lines 30 (definition of MPI_Cart_coords) reads IN maxdims length of vector coord in the calling program (integer) but should read (missing s at coords) IN maxdims length of vector coords in the calling program (integer) Rationale for this clarification (not to be included into the MPI standard): Typo. _______________________ Best regards Rolf Rabenseifner PS: All background informations with reports from 5 different MPI implementations and their differences have been in my previous mail on Wed, 23 Jan 2008 18:42:43. Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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: Allmandring 30)

1 0

Re: [mpi-21] topo mpi (was Re: Ballot 4 - 0-dim MPI_CART_CREATE an d MP I_CART_SUB)
by unknown＠example.com 24 Jan '08

24 Jan '08

Understood. Nice work. Thanks! ________________ Reply Header ________________ Subject: Re: [mpi-21] topo mpi (was Re: Ballot 4 - 0-dim MPI_CART_CREATE and MP I_CART_SUB) Author: "Rolf Rabenseifner" <rabenseifner_at_[hidden]> Date: January 24th 2008 11:57 am William, yes, I reported the bahavior of 5 different MPI existing MPI implementations. And I attached my test program that calls the MPI topology functions and reports the behavior of the MPI library to which it is compiled and linked. Using this test program, everybody can detect that different MPI implementations are giving quite different answers and therefore, there is a need for clarifying the MPI 1.1 standard. Best regards Rolf On Thu, 24 Jan 2008 05:02:47 +0800 "William Yu" <wyu_at_[hidden]> wrote: >Hi Rolf, > >Just curious. Is this implemented already? Sounds like you have a reference implementation built against different MPIs. > >Thanks. > >________________ Reply Header ________________ >Subject: [mpi-21] Ballot 4 - 0-dim MPI_CART_CREATE and MPI_CART_SUB >Author: "Rolf Rabenseifner" <rabenseifner_at_[hidden]> >Date: January 23rd 2008 5:44 pm > >This is a discussion-point for MPI 2.1, Ballot 4. > >This is a follow up to: > Questions about Graph_create, Cart_crate, and Cart_coords > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… >with mail discussion in > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… > >I'm starting a new 2nd stream for the zero-dim discussion. >------------------------------- > >This report shows significant differences of MPI implementations >in the (extreme) case of zero-dimensional topologies! > >Therefore clarifications may be necessary. >(Although hopefully never an application may produce >zero-dimensional Cartesian topologies!) > >If there are no objections, I would produce clarifications >for MPI-2.1 according to the behavior of mpich2 >and MPI from IBM (except the rank -767705708, see below). > >MPI-1.1 Sect. 6.5.6, page 187, routine MPI_CART_SUB defines >on lines 38-42: > If a cartesian topology has been created with MPI_CART_CREATE, > the function MPI_CART_SUB can be used to partition the > communicator group into subgroups that form lower-dimensional > cartesian subgrids, and to build for each subgroup a > communicator with the associated subgrid cartesian topology. > (This function is closely related to MPI_COMM_SPLIT.) > >The text clearly says, that the new communicator must >(1) have a Cartesian topology associated >(2) be lower-dimensional in the case of a subgrid > >There is no restriction on the input array remain_dims. >Therefore all MPI implementations (that I tested) >allow that all entries in remain_dims are "false". > >I tested several MPI libraries with creating a subgrid >with MPI_Cart_sub(remain_dims=0) from a 1-dim Cartesian >topology. >I tested the subgrid communicator with MPI_Topo_test. >In the case of MPI_CART, I used MPI_Cartdim_get to retrieve >ndims, and MPI_Cart_get for further details: > >- mpich2: MPI_CART, ndims=0, > 1.0.3 MPI_Cart_get works, > but keeps all OUT arguments unchanged > >- IBM: MPI_CART, ndims=0, > (on SP) MPI_Cart_get works, > but keeps all OUT arguments unchanged > >- OpenMPI: MPI_CART, ndims=1, > 1.2.4 MPI_Cart_get works > and returns dims=1, periods=0, coords=0 independent > from process or periods in the original comm. > (may be wrong because (2) is not fulfilled) > >- NEC MP/EX: not MPI_CART > (may be wrong because (1) is not fulfilled) > >- Voltaire: not MPI_CART > (mpich1) (may be wrong because (1) is not fulfilled) > >With the implementations that return a correct zero-dim Cartesian >topology, I tested further usage of this zero-dim communicator: > >- MPI_Comm_size returns 1 and MPI_Comm_rank returns 0 because > this communicator is like MPI_COMM_SELF, but with Cartesian > topology associated. > >- MPI_Cart_rank(IN ZeroDimComm, IN coords=0, OUT rank) > Rationale. A zero-dim communicator has zero coords, > i.e., this routine should not examine the coords > input argument. > --> mpich2: rank = 0 is returned > (may be because this is the only existing rank > in this communicator, this value may make sense, > independent of the coord, that should not be > analyzed) > --> IBM: rank = -767705708 is returned > (strange value, not MPI_PROC_NULL, not MPI_UNDEFINED) > >- MPI_Cart_coords(IN ZeroDimComm, IN rank=0, OUT coords) > Rationale. A zero-dim communicator has zero coords, > i.e., this routine should not return anything > in the coords output argument. > --> mpich2 and IBM: coords is not modified (as expected) > >- MPI_Cart_sub(IN ZeroDimComm, IN remain_dims=0, OUT subsubcomm) > Rationale. A zero-dim communicator has zero dimensions, > i.e., this routine should not examine remain_dims > and the returned communicator should be again > a zero-dim Cartesian communicator. > --> mpich2 and IBM: subsubcomm is a zero-dim Cartesian > communicator (as expected) > >- MPI_Cart_shift(IN ZeroDimComm, IN direction=0, IN disp=1, > OUT src, OUT dest) > Rationale. This call is erroneous because in a zero-dim > communicator, the direction=0 does not exist. > mpich2 and IBM: They detect the error and abort. > >(In OpenMPI, all these calls work as expected on a > 1-dimensional topology on a "MPI_COMM_SELF") > >The last test is not addressed by MPI-1.1: >Is it possible to build a zero-dim Cartesian topology >directly by calling MPI_Cart_create: > > MPI_Cart_create(IN MPI_COMM_SELF, IN ndims=0, IN dims=1, > IN Periods, IN reorder, OUT ZeroDimComm) > >Results: All tested MPI implementations return an error > and abort. > (Same on MPI_COMM_WORLD) > >The latter question was raised by Jesper Traeff. > >Best regards >Rolf > > > >Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >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: Allmandring 30) > > >_______________________________________________ >mpi-21 mailing list >mpi-21_at_[hidden] >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > >_______________________________________________ >mpi-21 mailing list >mpi-21_at_[hidden] >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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: Allmandring 30)

1 0