Hi,
thanks for this quick answer. I might precise why I use the
MPI_COMM_SPAWN_MULTIPLE primitve instead of a simple MPI_COMM_SPAWN to launch
a single executable. First, let's say that the code I'm working with has to
be portable on most of the machines, being able to run with LAM or native MPI
implementations.
What I want to do is to spawn a single executable at some precise
locations (ie on different nodes on the same machines) in order to manage for
exemple the I/O operations using dedicated processors...
If I use MPI_COMM_SPAWN I won't be able to really control where the processes
of my applications will be. But if I use MPI_COMM_SPAWN_MULTIPLE for the same
executable, specifying host name on which the processes should be spawned
through the use of the info arguments (MPI_Info_create and then
MPI_Info_set), I'll be able to control where to spawn my executable. That's
why I use MPI_COMM_SPAWN_MULTIPLE instead of MPI_COMM_SPAWN.
Let's consider the case you described with father and child1 gathered in
the same intra. If you want to spawn child2 from this intra, I agree that
father and child1 are doing a collective call to MPI_COMM_SPAWN_MULTIPLE. But
I was just wondering about the fact that if father is the master process of
the intra why child1 has also to know the command (ie the name of the
executable to spawn). When I run with the native implementation on the
NEC SX5 or the Fujitsu VPP5000, child1 does not need this command as well as
the number of processes. So I just put anything for them and that works.
That's why I was asking if your implementation needs or not the command. It
seems that it does, so I agree when you say that a Broadcast will be the
right way (this broadcast might be internal to the primitive in the NEC and
Fuji implementation ????).
Thanks again. I hope You could understand my explanations. Regards,
Damien
Sriram Sankaran wrote:
> Jeff:
>
> 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.
>
> --Sriram
>
> -------------------
>
> Hi,
>
> 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:
> http://www.mpi-forum.org/docs/mpi-20-html/node95.htm#Node95 and
> http://www.mpi-forum.org/docs/mpi-20-html/node96.htm#Node96
>
> 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
> spawn child2.
>
> 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
> MPI_Comm_spawn*.
>
> 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
> spawned.
>
> 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
> at http://www.mpi-forum.org.
>
> Hope this helps.
>
> --
> Sriram Sankaran
> email: ssankara_at_[hidden]
> http://www.lam-mpi.org/
>
> 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]>
> >To: lam_at_[hidden]
> >Subject: LAM: SPAWN_MULTIPLE arguments on processes which are not the
> > master process
> >
> >Hi all,
> >
> > 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 ?
> > Regards,
> >
> >Damien
> >
> >_______________________________________________
> >This list is archived at http://www.lam-mpi.org/MailArchives/lam/
> >
> _______________________________________________
> This list is archived at http://www.lam-mpi.org/MailArchives/lam/
|
