[mpi-21] MPI_GET_PROCESSOR_NAME Fortran and C
Richard Treumann
treumann at [hidden]
Fri Jan 25 14:32:07 CST 2008
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
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-21/attachments/20080125/f99e161d/attachment.html>
More information about the Mpi-21
mailing list