Could you go over this email and let me know if my explanation is correct
and clear?? :-)
Note that I have intentionally *not* mentioned some other things that can
be done (like Bcast on intercomms) for the sake of clarity.
First of all, given that you spawn only one copy of an MPI program at a
time, you might want to use the MPI_Comm_spawn function instead of
MPI_Comm_spawn_multiple. You would typically use MPI_Comm_spawn_multiple
to start multiple binaries or the same binary with multiple sets of
arguments. While it is not wrong to use MPI_Comm_spawn_multiple in your
case, MPI_Comm_spawn is meant exactly for situations like yours.
As described in the MPI standards document:
MPI_Comm_spawn and MPI_Comm_spawn_multiple are collective operations on
the parent communicator (specified by the "comm" argument). Hence, all
the processes in comm *must* call MPI_Comm_spawn* before the call can
return. In your particular case, in the first iteration, only the
"father" calls MPI_Comm_spawn* to spawn child1. At this point, the
"father" and child1 have their own *separate* MPI_COMM_WORLDs.
For the second spawn, depending on the exact nature of your application,
two cases arise:
1) The "father" and "child1" processes created an intracommunicator, say
"intra1", between themselves (using MPI_Intercomm_merge on the intercomm
returned by MPI_Comm_spawn*), and it is this communicator that is used to
2) Only "father" is involved in the second spawn, i.e., "father" calls
MPI_Comm_spawn* on its MPI_COMM_WORLD (the "comm" argument).
In the first case, since MPI_Comm_spawn* is collective on the intra1
communicator, both processes must call MPI_comm_spawn*. Also, "father"
and "child1" must both use the same name for the "command" argument.
Hence, child1 must somehow know the name to be used in the "command"
argument before calling MPI_Comm_spawn*. This can probably be done using
an MPI_Bcast on the intra1 communicator just before calling
In the second case, only the "father" is involved in spawning child2.
Hence, child1 does not call MPI_Comm_spawn*, and therefore need not know
the name of the command.
These two steps can be repeated to ultimately spawn multiple children.
Note that in both cases, if you want the spawned processes to eventually
communicate with each other and with the father using MPI_Send/Recv types
of functions, you will need to merge the intercommunicators (to create an
intracommunicator) at some point of time. The two cases described above
describe two such scenarios: in the first case, an intracommunicator is
created at each stage after a child is spawned. In the second case, the
merging of intercommunicators is postponed till all the children have been
The interface specification for MPI_Comm_spawn* is part of the MPI
standard. So, we do not foresee a change in this interface unless the
standard is changed.
For a detailed discussion of collective operations, intra- and inter-
communicators, and MPI_Comm_spawn*, refer to the MPI standards documents
Hope this helps.
Thus spake Damien Declat, on Jun 25:
>Date: Wed, 25 Jun 2003 15:16:45 +0200
>From: Damien Declat <damien.declat_at_[hidden]>
>Reply-To: General LAM/MPI mailing list <lam_at_[hidden]>
>Subject: LAM: SPAWN_MULTIPLE arguments on processes which are not the
> master process
> I'm using the MPI_COMM_SPAWN_MULTIPLE routine to spawn one
>executable on different nodes. I repeat the operation as long as I have
>to spawn several executables.
> It seems that the LAM implementation needs the name of the
>executable to spawn and the number of processes as input argument of the
>primitive on all the processes that take part of the spawning operation.
>I thought that this name and number of proc input arguments where needed
>only on the master process side and not on the other process side.
> Imagine that program father spawns(with Spawn_multiple) child1. Once
>the intracomm has been set up between father and child1, we would like
>to spawn child2. If I need the child2 exe name to spawn it on child1
>side, father needs to broadcast this name whereas if the father is the
>only one who needs the child2 exe name, this broadcast is not needed.
> Am I right ? Is it something that won't change or does the LAM team
>work on such feature ?
>This list is archived at http://www.lam-mpi.org/MailArchives/lam/