From: Richard Treumann Date: January 29, 2008 11:40:19 AM CST To: "Mailing list for discussion of MPI 2.1" Subject: Re: [mpi-21] MPI_GET_PROCESSOR_NAME Fortran and C Reply-To: "Mailing list for discussion of MPI 2.1" Agreed - the migration and checkpoint/restart issues are already clear in MPI 1.1( ( ( 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@cs.uiuc.edu wrote on 01/28/2008 03:24:32 AM:( ( > 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 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@cs.uiuc.edu 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@hlrs.de( > >> 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@cs.uiuc.edu( > >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21( > ( > ( > ( > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@hlrs.de( > 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@cs.uiuc.edu( > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21_______________________________________________ mpi-21 mailing list mpi-21@XXXXXXXXXXX http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21