Let me rephrase the previous message:
Putting "/bin/sh" in command with info key "ompi_non_mpi" set to ".true."
(if command is empty, mpi_comm_spawn tries to execute ' ') of
mpi_comm_spawn and "-c" "mpirun -n 1 myapp" in args results in
this message:
Putting "/bin/sh" in command with info key "ompi_non_mpi" set to ".true."
(if command is empty, mpi_comm_spawn tries to execute ' ') of
mpi_comm_spawn and "-c" "mpirun -n 1 myapp" in args results in
this message:
/usr/bin/sh: -c: option requires an argument
Putting a single string in args as "-
I don't think this has any chance of working. The redirection is something
interpreted by the shell, and when Open MPI "fork-exec" a process it does
not behave as the shell.
Thus a potentially non-portable solution would be to instead of launching
the mpirun directly to launch it through a shell.
Ralph,
Sorry, "<" as an element of argv to mpi_comm_spawn is interpreted just the
same, as another parameter by the spawnee process.
But I am confused: wouldn't it be redundant to put "mpirun" "-n" "1"
"myapp"
as elements of argv, considering role of the other parameters of
mpi_comm_spawn
like th
Have you tried putting the "<" as a separate parameter? In other words,
since you are specifying the argv, you have to specify each of them
separately. So it looks more like:
"mpirun", "-n", "1", "myapp", "<", "stdinfile"
Does that work?
Ralph
On Wed, Dec 17, 2014 at 8:07 AM, Alex A. Schmidt w
Ralph,
I am afraid I will have to insist on i/o redirection matter
for the spawnee process.
I have a "child" mpi code that do just 2 things: read the 3 parameters
passed to it and print them, and then read data from stdin and show it.
So, if "stdin_file" is a text file with two lines, say:
10
20
Ralph,
I guess you mean "call mpi_comm_spawn( 'siesta', '< infile' , 2 ,...)"
to execute 'mpirun -n 2 siesta < infile' on the spawnee side. That was
my first choice. Well, siesta behaves as if no stdin file was present...
Alex
2014-12-15 17:07 GMT-02:00 Ralph Castain :
>
> You should be able t
You should be able to just include that in your argv that you pass to the
Comm_spawn API.
On Mon, Dec 15, 2014 at 9:27 AM, Alex A. Schmidt wrote:
>
> George,
>
> Thanks for the tip. In fact, calling mpi_comm_spawn right away with MPI
> _COMM_SELF
> has worked for me just as well -- no subgroups
George,
Thanks for the tip. In fact, calling mpi_comm_spawn right away with MPI
_COMM_SELF
has worked for me just as well -- no subgroups needed at all.
I am testing this openmpi app named "siesta" in parallel. The source code
is available,
so making it "spawn ready" by adding the pair mpi_comm_g
Alex,
The code looks good, and is 100% MPI standard accurate.
I would change the way you create the subcoms in the parent. You do a lot
of useless operations, as you can achieve exactly the same outcome (one
communicator per node), either by duplicating MPI_COMM_SELF or doing an
MPI_Comm_split wi
Hi,
Sorry, guys. I don't think the newbie here can follow any discussion
beyond basic mpi...
Anyway, if I add the pair
call MPI_COMM_GET_PARENT(mpi_comm_parent,ierror)
call MPI_COMM_DISCONNECT(mpi_comm_parent,ierror)
on the spawnee side I get the proper response in the spawning processes.
Plea
Alex,
Are you calling MPI_Comm_disconnect in the 3 "master" tasks and with the same
remote communicator ?
I also read the man page again, and MPI_Comm_disconnect does not ensure the
remote processes have finished or called MPI_Comm_disconnect, so that might not
be the thing you need.
George, c
12 matches
Mail list logo
