Hi,
As you must have guessed, the previous post was not meant to be sent on
this list. Shame on me for the mix-up! Here's the correct version of the
reply to your email.
The "command" , "argv", "maxprocs" and "info" arguments to MPI_Comm_spawn*
are significant only at the root. Hence, to answer your first question, if
the program "father" is the "root" during a spawn, then the name of the
executable need not be broadcast to the other processes in the
communicator. This is what the standard specifies, and this is how it
works in LAM/MPI.
In your follow-up email, you had mentioned that you use
MPI_Comm_spawn_multiple instead of MPI_Comm_spawn to to be able to
explicitly specify the location of the spawned process using info keys.
Note that info keys are implementation-specific, and it is possible that
the native MPI implementations on the NEC and Fufitsu machines support
info keys to do this. LAM does not support such info keys for
MPI_Comm_spawn_multiple. However, in LAM 7.0 there is a
"lam_spawn_sched_round_robin" info key that is supported by MPI_Comm_spawn
(and currently not supported by MPI_Comm_spawn_multiple). This info key
can be used to specify which node to begin spawning the processes on.
You might want to look up the MPI_Comm_spawn(3) manpage for more details
on its usage.
Hope this helps.
--
Sriram Sankaran
email: ssankara_at_[hidden]
http://www.lam-mpi.org/
Thus spake Damien Declat, on Jun 26:
>Date: Thu, 26 Jun 2003 18:43:20 +0200
>From: Damien Declat <damien.declat_at_[hidden]>
>Reply-To: General LAM/MPI mailing list <lam_at_[hidden]>
>To: Sriram Sankaran <ssankara_at_[hidden]>,
> General LAM/MPI mailing list <lam_at_[hidden]>
>Subject: Re: Fwd: LAM: SPAWN_MULTIPLE arguments on processes which are not
> themaster process
>
>
>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/
>
>_______________________________________________
>This list is archived at http://www.lam-mpi.org/MailArchives/lam/
>
|
