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