Following your suggestions I've been trying to figure out MPI_COMM_SPAWN, but it's at the edge of my understanding so it's not easy.
I read that the changing of directories can be achieved using info keys, however these are very cryptic: I can't seem to find any precise information anywhere about how to use them. I tried the following:
MPI_ARGV_NULL: there are no arguments to mpitest-2.ex
1: I want to spawn 1 process per original process (the original process sitting idle, maybe waiting for a return parameter from its child - have not figured out how to achieve communication between the two processes yet, but that's the next step)
"wdir ./test-1" (for example): the directory in which the new process should run. I don't think this is correct, but as I say, I can't find precise information about the info keys (at least, in a way that I can understand it) - can anyone help me here?
irank: the current rank of the process, so every process spawns its own process
MPI_COMM_SELF: I assume this is the new name for the child processes, like MPI_COMM_WORLD.
ierr: error value
So it compiles, but crashes once I reach the spawn command.
Can you help? Thank you very much.
> From: firstname.lastname@example.org > Date: Fri, 5 Mar 2010 15:02:57 -0500 > To: email@example.com > Subject: Re: [OMPI users] running externalprogram on same processor (Fortran) > > On Mar 5, 2010, at 2:38 PM, Ralph Castain wrote: > > >> CALL SYSTEM("cd " // TRIM(dir) // " ; mpirun -machinefile ./machinefile -np 1 /home01/group/Execute/DLPOLY.X > job.out 2> job.err ; cd - > /dev/null") > > > > That is guaranteed not to work. The problem is that mpirun sets environmental variables for the original launch. Your system call carries over those envars, causing mpirun to become confused. > > You should be able to use MPI_COMM_SPAWN to launch this MPI job. Check the man page for MPI_COMM_SPANW; I believe we have info keys to specify things like what hosts to launch on, etc. > > >> Do you think MPI_COMM_SPAWN can help? > > > > It's the only method supported by the MPI standard. If you need it to block until this new executable completes, you could use a barrier or other MPI method to determine it. > > I believe that the user said they wanted to use the same cores as their original MPI job occupies for the new job -- they basically want the old job to block until the new job completes. Keep in mind that OMPI busy-polls waiting for progress, so you might actually get hosed here (two procs competing for time on the same core). > > I'm not immediately thinking of a good way to avoid this issue -- perhaps you could kludge something up such that the parent job polls on sleep() and checking to see if a message has arrived from the child (i.e., the last thing the child does before it calls MPI_FINALIZE is to send a message to its parents and then MPI_COMM_DISCONNECT from its parents). If the parent finds that it has a message from the child(ren), it can MPI_COMM_DISCONNECT and continue processing. > > Kinda hackey, but it might work...? > > -- > Jeff Squyres > firstname.lastname@example.org > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > users mailing list > email@example.com > http://www.open-mpi.org/mailman/listinfo.cgi/users
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now