-> From: Al Geist <geist@msr.epm.ornl.gov>
-> To: mpi-dynamic@mcs.anl.gov
-> Subject: Re: using MPI_Init() without mpirun
->
-> > From: Gary Oberbrunner <garyo@avs.com>
-> >
-> > If I could start the visual programming environment as usual and have it
-> > "become" an MPI process dynamically
->
-> I think it is a very useful feature to become an MPI process dynamically.
-> And I think we should consider the request to put it in MPI2
-> using MPI_INIT() as the medium.
->
-> I don't see any fundamental problems with defining the behavior of
-> MPI_INIT() when the calling process is not spawned or mpirun.
-> In the absence of set environment variables or "magic args" passed
-> by the mpirun, MPI_INIT() would form a MPI_COMM_WORLD of size one.
-> As Gary points out the behavior in this case is presently undefined.
-> So this proposed change should not break any MPI-1 applications.
-> (a mandate of MPI-2)
->
-> Note this is a little different than Joel's reply about how the Paragon
-> presently works. In his case MPI_INIT() blocks forever
-> if the partition size is 4 and I manually start just one MPI process
-> in this partition (hoping this process would spawn others to fill partition)
-> Did I interpret this correctly, Joel?
->
My main point was that MPI-2 should not specify behavior in the absence of
mpirun since as far as MPI standards are concerned there is no mpirun.
On Paragon, the only things required to create an MPI program as opposed to
an "NX" program is to link with the MPI library and call MPI_Init().
Yes, on the Paragon MPI_Init() is currently a collective operation which
assumes we want to initiate some optimized global operations based on the
the number and position of participating processes.
by Gary's and others discussion of creating singleton MPI processes without
mpirun is to specify that MPI_Init must only be a local operation, cannot be
a collective operation.
joel clark
-> Al "flame bait" Geist
--- End Of Your Message