<br><font size=2 face="sans-serif">If I used some mechanism that allows
the MPI launch to give me fewer processes than I asked for and it does
give me less than I asked for, what does this mean? </font>
<br>
<br><font size=2 face="sans-serif">"</font><tt><font size=2>number
of ranks in the communicator regardless of whether they're operational</font></tt><font size=2 face="sans-serif">"</font>
<br>
<br><font size=2 face="sans-serif">It is sort of weird to say that the
processes I was never given are "in the communicator". I can
see the logic in counting a processes that have died as "</font><tt><font size=2>ranks
in the communicator</font></tt><font size=2 face="sans-serif">"</font>
<br>
<br><font size=2 face="sans-serif">I would not count chickens that never
hatched.</font>
<br>
<br>
<br><font size=2 face="sans-serif">Dick Treumann - MPI Team
<br>
IBM Systems & Technology Group<br>
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846 Fax (845) 433-8363<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">"Bronevetsky, Greg" <bronevetsky1@llnl.gov></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">"Bronis R. de Supinski" <bronis@llnl.gov>,
"MPI 3.0 Fault Tolerance and Dynamic
Process Control working Group" <mpi3-ft@lists.mpi-forum.org></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">09/17/2010 10:03 AM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: [Mpi3-ft] Stabilization Updated
& MPI_Comm_size question</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Sent by:</font>
<td><font size=1 face="sans-serif">mpi3-ft-bounces@lists.mpi-forum.org</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>I agree that MPI_Comm_size should return the number
of ranks in the communicator regardless of whether they're operational
or not. However, this just pushes the question further back: if the user
asked for N processes but only M have started up, how many ranks should
MPI_COMM_WORLD have? Either choice is going to be self-consistent from
MPI's point of view. If its N, then some ranks will be dead. If it is M
then the application may not have enough processes to work with. The former
(N) case has property that the user doesn't need to add code to check for
this condition since their existing error checking code will catch this
situation. The latter case (M) is nice because it cheaper to check whether
we got fewer processes than expected than to explicitly try to communicate
with them. <br>
<br>
As such, I don't see a strong motivation for choosing either. However,
we should just pick one and stick with it to avoid unnecessary API divergence.<br>
<br>
Greg Bronevetsky<br>
Lawrence Livermore National Lab<br>
(925) 424-5756<br>
bronevetsky@llnl.gov<br>
</font></tt><a href=http://greg.bronevetsky.com/><tt><font size=2>http://greg.bronevetsky.com</font></tt></a><tt><font size=2>
<br>
<br>
> -----Original Message-----<br>
> From: mpi3-ft-bounces@lists.mpi-forum.org [</font></tt><a href="mailto:mpi3-ft-"><tt><font size=2>mailto:mpi3-ft-</font></tt></a><tt><font size=2><br>
> bounces@lists.mpi-forum.org] On Behalf Of Bronis R. de Supinski<br>
> Sent: Friday, September 17, 2010 5:23 AM<br>
> To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group<br>
> Subject: Re: [Mpi3-ft] Stabilization Updated & MPI_Comm_size question<br>
> <br>
> <br>
> I agree with Rich and Darius.<br>
> <br>
> On Fri, 17 Sep 2010, Darius Buntinas wrote:<br>
> <br>
> ><br>
> > I don't think we should change the standard in this case. For<br>
> MPI_Comm_size to have any useful meaning, it needs to return the size
of<br>
> the communicator: i.e., if comm_size returns N, you should be able
to do a<br>
> send to processes 0 through N-1. Of course if some of those
processes have<br>
> failed, you'll get an error associated with the process failure, but
never<br>
> an error for an invalid rank.<br>
> ><br>
> > As discussed in the section about mpiexec, an implementation
may decide<br>
> to provide a soft process count argument. So "mpiexec -n
10 -soft 5 ./cpi"<br>
> can start any number between 5 and 10 processes. But that does
not affect<br>
> the meaning of the size of MPI_COMM_WORLD: regardless of the number
of<br>
> processes the implementation decides to start, MPI_Comm_size will
return<br>
> the _actual_ number of processes started.<br>
> ><br>
> > -d<br>
> ><br>
> > On Sep 17, 2010, at 11:22 AM, Graham, Richard L. wrote:<br>
> ><br>
> >> We need to clearly define what N or M is and not leave it
to the<br>
> implementation. 100% of the codes that seen over the past 15
years that<br>
> check this value use it to indicate how many process have started.
Any<br>
> thing else is really useless, aside from letting the user find out
how many<br>
> processes actually started up, and then know how many did not start
up.<br>
> >><br>
> >> Rich<br>
> >><br>
> >><br>
> >> On 9/17/10 4:27 AM, "Josh Hursey" <jjhursey@open-mpi.org>
wrote:<br>
> >><br>
> >> So the Run-Through Stabilization proposal has been updated
per our<br>
> discussion in the working group meeting at the MPI Forum. The changes
are<br>
> summarized below:<br>
> >> - Add a Legacy Library Support example<br>
> >> - Clarify new error classes<br>
> >> - Update the MPI_Init and MPI_Finalize wording to be simpler
and more<br>
> direct.<br>
> >> - Fix wording of group creation calls versus communicator
creation<br>
> calls.<br>
> >><br>
> >> </font></tt><a href="https://blockedblockedsvn.mpi-forum.org/trac/mpi-forum-"><tt><font size=2>https://BLOCKEDBLOCKEDsvn.mpi-forum.org/trac/mpi-forum-</font></tt></a><tt><font size=2><br>
> web/wiki/ft/run_through_stabilization<br>
> >><br>
> >><br>
> >> One question that we discussed quite a bit during the meeting
was the<br>
> issue of the return value of MPI_Comm_size() when processes fail during<br>
> launch. I attempted to capture the discussion in the room in the Open<br>
> Question attached to the discussion of MPI_Init:<br>
> >> </font></tt><a href="https://blockedblockedsvn.mpi-forum.org/trac/mpi-forum-"><tt><font size=2>https://BLOCKEDBLOCKEDsvn.mpi-forum.org/trac/mpi-forum-</font></tt></a><tt><font size=2><br>
> web/wiki/ft/run_through_stabilization#MPI_INIT<br>
> >><br>
> >> Open question:<br>
> >> If the user asks to start N processes on the command line,
and only M<br>
> processes were successfully launched (where M < N), then what should
be<br>
> returned from MPI_COMM_SIZE?<br>
> >><br>
> >> The return value must be consistent across all alive members
of the<br>
> group. The issue is if it should return N or M.<br>
> >><br>
> >> The feeling in the room was that since the MPI standard does
not define<br>
> the ability for the user to ask for a specific number of processes
before<br>
> initthen it is hard to define that this is the number it should be.<br>
> >><br>
> >> So it is left to the implementation whether it is M or N.
If it is M,<br>
> then the user has other techniques to find out what it originally
asked for<br>
> (e.g., by passing it as a command line argument to the application
itself).<br>
> >><br>
> >><br>
> >> What do people think about the MPI_Comm_size issue?<br>
> >><br>
> >> -- Josh<br>
> >><br>
> >> ------------------------------------<br>
> >> Joshua Hursey<br>
> >> Postdoctoral Research Associate<br>
> >> Oak Ridge National Laboratory<br>
> >> </font></tt><a href=http://blockedblockedwww.blockedblockedcs.indiana.edu/~jjhursey><tt><font size=2>http://BLOCKEDBLOCKEDwww.BLOCKEDBLOCKEDcs.indiana.edu/~jjhursey</font></tt></a><tt><font size=2><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> mpi3-ft mailing list<br>
> >> mpi3-ft@lists.mpi-forum.org<br>
> >> </font></tt><a href="http://blockedblockedlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><tt><font size=2>http://BLOCKEDBLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</font></tt></a><tt><font size=2><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> mpi3-ft mailing list<br>
> >> mpi3-ft@lists.mpi-forum.org<br>
> >> </font></tt><a href="http://blockedblockedlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><tt><font size=2>http://BLOCKEDBLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</font></tt></a><tt><font size=2><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > mpi3-ft mailing list<br>
> > mpi3-ft@lists.mpi-forum.org<br>
> > </font></tt><a href="http://blockedblockedlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><tt><font size=2>http://BLOCKEDBLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</font></tt></a><tt><font size=2><br>
> ><br>
> ><br>
> _______________________________________________<br>
> mpi3-ft mailing list<br>
> mpi3-ft@lists.mpi-forum.org<br>
> </font></tt><a href="http://blockedlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><tt><font size=2>http://BLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</font></tt></a><tt><font size=2><br>
<br>
<br>
_______________________________________________<br>
mpi3-ft mailing list<br>
mpi3-ft@lists.mpi-forum.org<br>
</font></tt><a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft"><tt><font size=2>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>