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:
**********************************************************
Open MPI does not support recursive calls of mpirun
**********************************************************
Putting a single string in args as "-c mpirun -n 1 myapp" or "-c 'mpirun
-n 1 myapp' "
returns
/usr/bin/sh: - : invalid option
Alex
2014-12-17 21:47 GMT-02:00 Alex A. Schmidt <a...@ufsm.br>:
>
> 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 "-c mpirun -n 1 myapp" or "-c 'mpirun
> -n 1 myapp' "
> returns
>
> /usr/bin/sh: - : invalid option
>
> Alex
>
> 2014-12-17 20:17 GMT-02:00 George Bosilca <bosi...@icl.utk.edu>:
>>
>> 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. Maybe something like
>> "/bin/sh", "-c", "mpirun -n 1 myapp".
>>
>> George.
>>
>>
>> On Wed, Dec 17, 2014 at 5:02 PM, Alex A. Schmidt <a...@ufsm.br> wrote:
>>
>>> 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 the 1st and 3rd ?
>>>
>>> Imho, it seems to me that stdin and stdout should be keys to "info" and
>>> the
>>> respective filenames the values of those keys, if that is possible to
>>> implement...
>>>
>>> Alex
>>>
>>>
>>>
>>> 2014-12-17 15:16 GMT-02:00 Ralph Castain <r...@open-mpi.org>:
>>>>
>>>> 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 <a...@ufsm.br> wrote:
>>>>
>>>>> 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
>>>>>
>>>>> executing "mpirun -n 1 child A B < stdin_file" wiil ouput two lines:
>>>>>
>>>>> [A] [B] []
>>>>> 10 20
>>>>>
>>>>> On the other hand , calling "child" from
>>>>> MPI_Comm_spawn("child",args,...)
>>>>> where
>>>>>
>>>>> args(1) = "A"
>>>>> args(2) = "B"
>>>>> args(3) ="< stdin_file"
>>>>> args(4) = " "
>>>>>
>>>>> will make "child" outputs only 1 line
>>>>>
>>>>> [A] [B] [< stdin_file]
>>>>>
>>>>> and then fails because there is not stdin data to read from.
>>>>>
>>>>> Please, note that surprisingly the whole string "< stdin_file" is
>>>>> interpreted
>>>>> as a third parameter to "child" and not a stdin...
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2014-12-15 17:26 GMT-02:00 Alex A. Schmidt <a...@ufsm.br>:
>>>>>
>>>>>> 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 <r...@open-mpi.org>:
>>>>>>>
>>>>>>> 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 <a...@ufsm.br>
>>>>>>> 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 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_get_parent
>>>>>>>> + mpi_comm_disconnect
>>>>>>>> into the main code can be done. If it works, maybe the siesta's
>>>>>>>> developers can be convinced
>>>>>>>> to add this feature in a future release.
>>>>>>>>
>>>>>>>> However, siesta is launched only by specifying input/output files
>>>>>>>> with i/o redirection like
>>>>>>>>
>>>>>>>> mpirun -n <*some number*> siesta < infile > outfile
>>>>>>>>
>>>>>>>> So far, I could not find anything about how to set an stdin file
>>>>>>>> for an spawnee process.
>>>>>>>> Specifiyng it in a app context file doesn't seem to work. Can it be
>>>>>>>> done? Maybe through
>>>>>>>> an MCA parameter?
>>>>>>>>
>>>>>>>> Alex
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2014-12-15 2:43 GMT-02:00 George Bosilca <bosi...@icl.utk.edu>:
>>>>>>>>>
>>>>>>>>> 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 with the color equal to your rank.
>>>>>>>>>
>>>>>>>>> George.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Dec 14, 2014 at 2:20 AM, Alex A. Schmidt <a...@ufsm.br>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> Please, take a look at the attached toy codes parent.F and
>>>>>>>>>> child.F
>>>>>>>>>> I've been playing with. 'mpirun -n 2 parent' seems to work as
>>>>>>>>>> expected.
>>>>>>>>>>
>>>>>>>>>> Alex
>>>>>>>>>>
>>>>>>>>>> 2014-12-13 23:46 GMT-02:00 Gilles Gouaillardet <
>>>>>>>>>> gilles.gouaillar...@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>> 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, can you please comment on that ?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> Gilles
>>>>>>>>>>>
>>>>>>>>>>> George Bosilca <bosi...@icl.utk.edu> wrote:
>>>>>>>>>>> MPI_Comm_disconnect should be a local operation, there is no
>>>>>>>>>>> reason for it to deadlock. I looked at the code and everything is
>>>>>>>>>>> local
>>>>>>>>>>> with the exception of a call to PMIX.FENCE. Can you attach to your
>>>>>>>>>>> deadlocked processes and confirm that they are stopped in the
>>>>>>>>>>> pmix.fence?
>>>>>>>>>>>
>>>>>>>>>>> George.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Dec 13, 2014 at 8:47 AM, Alex A. Schmidt <a...@ufsm.br>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi
>>>>>>>>>>>>
>>>>>>>>>>>> Sorry, I was calling mpi_comm_disconnect on the group comm
>>>>>>>>>>>> handler, not
>>>>>>>>>>>> on the intercomm handler returned from the spawn call as it
>>>>>>>>>>>> should be.
>>>>>>>>>>>>
>>>>>>>>>>>> Well, calling the disconnect on the intercomm handler does halt
>>>>>>>>>>>> the spwaner
>>>>>>>>>>>> side but the wait is never completed since, as George points
>>>>>>>>>>>> out, there is no
>>>>>>>>>>>> disconnect call being made on the spawnee side.... and that
>>>>>>>>>>>> brings me back
>>>>>>>>>>>> to the beginning of the problem since, being a third party app,
>>>>>>>>>>>> that call would
>>>>>>>>>>>> never be there. I guess an mpi wrapper to deal with that could
>>>>>>>>>>>> be made for
>>>>>>>>>>>> the app, but I fell the wrapper itself, at the end, would face
>>>>>>>>>>>> the same problem
>>>>>>>>>>>> we face right now.
>>>>>>>>>>>>
>>>>>>>>>>>> My application is a genetic algorithm code that search optimal
>>>>>>>>>>>> configuration
>>>>>>>>>>>> (minimum or maximum energy) of cluster of atoms. The work flow
>>>>>>>>>>>> bottleneck
>>>>>>>>>>>> is the calculation of the cluster energy. For the cases which
>>>>>>>>>>>> an analytical
>>>>>>>>>>>> potential is available the calculation can be made internally
>>>>>>>>>>>> and the workload
>>>>>>>>>>>> is distributed among slaves nodes from a master node. This is
>>>>>>>>>>>> also done
>>>>>>>>>>>> when an analytical potential is not available and the energy
>>>>>>>>>>>> calculation must
>>>>>>>>>>>> be done externally by a quantum chemistry code like dftb+,
>>>>>>>>>>>> siesta and Gaussian.
>>>>>>>>>>>> So far, we have been running these codes in serial mode. No
>>>>>>>>>>>> need to say that
>>>>>>>>>>>> we could do a lot better if they could be executed in parallel.
>>>>>>>>>>>>
>>>>>>>>>>>> I am not familiar with DMRAA but it seems to be the right
>>>>>>>>>>>> choice to deal with
>>>>>>>>>>>> job schedulers as it covers the ones I am interested in
>>>>>>>>>>>> (pbs/torque and loadlever).
>>>>>>>>>>>>
>>>>>>>>>>>> Alex
>>>>>>>>>>>>
>>>>>>>>>>>> 2014-12-13 7:49 GMT-02:00 Gilles Gouaillardet <
>>>>>>>>>>>> gilles.gouaillar...@gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>> George is right about the semantic
>>>>>>>>>>>>>
>>>>>>>>>>>>> However i am surprised it returns immediatly...
>>>>>>>>>>>>> That should either work or hang imho
>>>>>>>>>>>>>
>>>>>>>>>>>>> The second point is no more mpi related, and is batch manager
>>>>>>>>>>>>> specific.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You will likely find a submit parameter to make the command
>>>>>>>>>>>>> block until the job completes. Or you can write your own wrapper.
>>>>>>>>>>>>> Or you can retrieve the jobid and qstat periodically to get
>>>>>>>>>>>>> the job state.
>>>>>>>>>>>>> If an api is available, this is also an option.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gilles
>>>>>>>>>>>>>
>>>>>>>>>>>>> George Bosilca <bosi...@icl.utk.edu> wrote:
>>>>>>>>>>>>> You have to call MPI_Comm_disconnect on both sides of the
>>>>>>>>>>>>> intercommunicator. On the spawner processes you should call it on
>>>>>>>>>>>>> the
>>>>>>>>>>>>> intercom, while on the spawnees you should call it on the
>>>>>>>>>>>>> MPI_Comm_get_parent.
>>>>>>>>>>>>>
>>>>>>>>>>>>> George.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Dec 12, 2014, at 20:43 , Alex A. Schmidt <a...@ufsm.br>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gilles,
>>>>>>>>>>>>>
>>>>>>>>>>>>> MPI_comm_disconnect seem to work but not quite.
>>>>>>>>>>>>> The call to it returns almost immediatly while
>>>>>>>>>>>>> the spawn processes keep piling up in the background
>>>>>>>>>>>>> until they are all done...
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think system('env -i qsub...') to launch the third party apps
>>>>>>>>>>>>> would take the execution of every call back to the scheduler
>>>>>>>>>>>>> queue. How would I track each one for their completion?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Alex
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2014-12-12 22:35 GMT-02:00 Gilles Gouaillardet <
>>>>>>>>>>>>> gilles.gouaillar...@gmail.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Alex,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You need MPI_Comm_disconnect at least.
>>>>>>>>>>>>>> I am not sure if this is 100% correct nor working.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you are using third party apps, why dont you do something
>>>>>>>>>>>>>> like
>>>>>>>>>>>>>> system("env -i qsub ...")
>>>>>>>>>>>>>> with the right options to make qsub blocking or you manually
>>>>>>>>>>>>>> wait for the end of the job ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That looks like a much cleaner and simpler approach to me.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Gilles
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "Alex A. Schmidt" <a...@ufsm.br> wrote:
>>>>>>>>>>>>>> Hello Gilles,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ok, I believe I have a simple toy app running as I think it
>>>>>>>>>>>>>> should:
>>>>>>>>>>>>>> 'n' parent processes running under mpi_comm_world, each one
>>>>>>>>>>>>>> spawning its own 'm' child processes (each child group work
>>>>>>>>>>>>>> together nicely, returning the expected result for an mpi_
>>>>>>>>>>>>>> allreduce call).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now, as I mentioned before, the apps I want to run in the
>>>>>>>>>>>>>> spawned
>>>>>>>>>>>>>> processes are third party mpi apps and I don't think it will
>>>>>>>>>>>>>> be possible
>>>>>>>>>>>>>> to exchange messages with them from my app. So, I do I tell
>>>>>>>>>>>>>> when the spawned processes have finnished running? All I have
>>>>>>>>>>>>>> to work
>>>>>>>>>>>>>> with is the intercommunicator returned from the
>>>>>>>>>>>>>> mpi_comm_spawn call...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Alex
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2014-12-12 2:42 GMT-02:00 Alex A. Schmidt <a...@ufsm.br>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Gilles,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Well, yes, I guess....
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll do tests with the real third party apps and let you
>>>>>>>>>>>>>>> know.
>>>>>>>>>>>>>>> These are huge quantum chemistry codes (dftb+, siesta and
>>>>>>>>>>>>>>> Gaussian)
>>>>>>>>>>>>>>> which greatly benefits from a parallel environment. My code
>>>>>>>>>>>>>>> is just
>>>>>>>>>>>>>>> a front end to use those, but since we have a lot of data to
>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>> it also benefits from a parallel environment.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Alex
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2014-12-12 2:30 GMT-02:00 Gilles Gouaillardet <
>>>>>>>>>>>>>>> gilles.gouaillar...@iferc.org>:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Alex,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> just to make sure ...
>>>>>>>>>>>>>>>> this is the behavior you expected, right ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Gilles
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2014/12/12 13:27, Alex A. Schmidt wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Gilles,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ok, very nice!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When I excute
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> do rank=1,3
>>>>>>>>>>>>>>>> call MPI_Comm_spawn('hello_world','
>>>>>>>>>>>>>>>> ',5,MPI_INFO_NULL,rank,MPI_COMM_WORLD,my_intercomm,MPI_ERRCODES_IGNORE,status)
>>>>>>>>>>>>>>>> enddo
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I do get 15 instances of the 'hello_world' app running: 5 for
>>>>>>>>>>>>>>>> each parent
>>>>>>>>>>>>>>>> rank 1, 2 and 3.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks a lot, Gilles.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regargs,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Alex
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2014-12-12 1:32 GMT-02:00 Gilles Gouaillardet
>>>>>>>>>>>>>>>> <gilles.gouaillar...@iferc.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Alex,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> just ask MPI_Comm_spawn to start (up to) 5 tasks via the
>>>>>>>>>>>>>>>> maxprocs
>>>>>>>>>>>>>>>> parameter :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int MPI_Comm_spawn(char *command, char *argv[], int
>>>>>>>>>>>>>>>> maxprocs,
>>>>>>>>>>>>>>>> MPI_Info info,
>>>>>>>>>>>>>>>> int root, MPI_Comm comm, MPI_Comm
>>>>>>>>>>>>>>>> *intercomm,
>>>>>>>>>>>>>>>> int array_of_errcodes[])
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> INPUT PARAMETERS
>>>>>>>>>>>>>>>> maxprocs
>>>>>>>>>>>>>>>> - maximum number of processes to start (integer,
>>>>>>>>>>>>>>>> significant
>>>>>>>>>>>>>>>> only at root)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Gilles
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2014/12/12 12:23, Alex A. Schmidt wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello Gilles,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for your reply. The "env -i PATH=..." stuff seems to
>>>>>>>>>>>>>>>> work!!!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> call system("sh -c 'env -i PATH=/usr/lib64/openmpi/bin:/bin
>>>>>>>>>>>>>>>> mpirun -n 2
>>>>>>>>>>>>>>>> hello_world' ")
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> did produce the expected result with a simple openmi
>>>>>>>>>>>>>>>> "hello_world" code I
>>>>>>>>>>>>>>>> wrote.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I might be harder though with the real third party app I have
>>>>>>>>>>>>>>>> in mind. And
>>>>>>>>>>>>>>>> I realize
>>>>>>>>>>>>>>>> getting passed over a job scheduler with this approach might
>>>>>>>>>>>>>>>> not work at
>>>>>>>>>>>>>>>> all...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have looked at the MPI_Comm_spawn call but I failed to
>>>>>>>>>>>>>>>> understand how it
>>>>>>>>>>>>>>>> could help here. For instance, can I use it to launch an mpi
>>>>>>>>>>>>>>>> app with the
>>>>>>>>>>>>>>>> option "-n 5" ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Alex
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2014-12-12 0:36 GMT-02:00 Gilles Gouaillardet
>>>>>>>>>>>>>>>> <gilles.gouaillar...@iferc.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Alex,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> can you try something like
>>>>>>>>>>>>>>>> call system(sh -c 'env -i /.../mpirun -np 2 /.../app_name')
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -i start with an empty environment
>>>>>>>>>>>>>>>> that being said, you might need to set a few environment
>>>>>>>>>>>>>>>> variables
>>>>>>>>>>>>>>>> manually :
>>>>>>>>>>>>>>>> env -i PATH=/bin ...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and that being also said, this "trick" could be just a bad
>>>>>>>>>>>>>>>> idea :
>>>>>>>>>>>>>>>> you might be using a scheduler, and if you empty the
>>>>>>>>>>>>>>>> environment, the
>>>>>>>>>>>>>>>> scheduler
>>>>>>>>>>>>>>>> will not be aware of the "inside" run.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> on top of that, invoking system might fail depending on the
>>>>>>>>>>>>>>>> interconnect
>>>>>>>>>>>>>>>> you use.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Bottom line, i believe Ralph's reply is still valid, even if
>>>>>>>>>>>>>>>> five years
>>>>>>>>>>>>>>>> have passed :
>>>>>>>>>>>>>>>> changing your workflow, or using MPI_Comm_spawn is a much
>>>>>>>>>>>>>>>> better approach.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Gilles
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2014/12/12 11:22, Alex A. Schmidt wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Dear OpenMPI users,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regarding to this previous
>>>>>>>>>>>>>>>> post<http://www.open-mpi.org/community/lists/users/2009/06/9560.php>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <http://www.open-mpi.org/community/lists/users/2009/06/9560.php>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <http://www.open-mpi.org/community/lists/users/2009/06/9560.php>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <http://www.open-mpi.org/community/lists/users/2009/06/9560.php>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <http://www.open-mpi.org/community/lists/users/2009/06/9560.php>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <http://www.open-mpi.org/community/lists/users/2009/06/9560.php>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <http://www.open-mpi.org/community/lists/users/2009/06/9560.php>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <http://www.open-mpi.org/community/lists/users/2009/06/9560.php>
>>>>>>>>>>>>>>>> from 2009,
>>>>>>>>>>>>>>>> I wonder if the reply
>>>>>>>>>>>>>>>> from Ralph Castain is still valid. My need is similar but
>>>>>>>>>>>>>>>> quite simpler:
>>>>>>>>>>>>>>>> to make a system call from an openmpi fortran application to
>>>>>>>>>>>>>>>> run a
>>>>>>>>>>>>>>>> third party openmpi application. I don't need to exchange mpi
>>>>>>>>>>>>>>>> messages
>>>>>>>>>>>>>>>> with the application. I just need to read the resulting output
>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>> generated
>>>>>>>>>>>>>>>> by it. I have tried to do the following system call from my
>>>>>>>>>>>>>>>> fortran openmpi
>>>>>>>>>>>>>>>> code:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> call system("sh -c 'mpirun -n 2 app_name")
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> but I get
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> **********************************************************
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Open MPI does not support recursive calls of mpirun
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> **********************************************************
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is there a way to make this work?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Alex
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> users mailing listus...@open-mpi.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Subscription:
>>>>>>>>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>>>>>>>>>>> Link to this post:
>>>>>>>>>>>>>>>> http://www.open-mpi.org/community/lists/users/2014/12/25966.php
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> users mailing listus...@open-mpi.org
>>>>>>>>>>>>>>>> Subscription:
>>>>>>>>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>>>>>>>>>>> Link to this
>>>>>>>>>>>>>>>> post:http://www.open-mpi.org/community/lists/users/2014/12/25967.php
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> users mailing listus...@open-mpi.org
>>>>>>>>>>>>>>>> Subscription:
>>>>>>>>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Link to this post:
>>>>>>>>>>>>>>>> http://www.open-mpi.org/community/lists/users/2014/12/25968.php
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> users mailing listus...@open-mpi.org
>>>>>>>>>>>>>>>> Subscription:
>>>>>>>>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>>>>>>>>>>> Link to this
>>>>>>>>>>>>>>>> post:http://www.open-mpi.org/community/lists/users/2014/12/25969.php
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> users mailing listus...@open-mpi.org
>>>>>>>>>>>>>>>> Subscription:
>>>>>>>>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>>>>>>>>>>> Link to this post:
>>>>>>>>>>>>>>>> http://www.open-mpi.org/community/lists/users/2014/12/25970.php
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> users mailing list
>>>>>>>>>>>>>>>> us...@open-mpi.org
>>>>>>>>>>>>>>>> Subscription:
>>>>>>>>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>>>>>>>>>>> Link to this post:
>>>>>>>>>>>>>>>> http://www.open-mpi.org/community/lists/users/2014/12/25971.php
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> users mailing list
>>>>>>>>>>>>>> us...@open-mpi.org
>>>>>>>>>>>>>> Subscription:
>>>>>>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>>>>>>>>> Link to this post:
>>>>>>>>>>>>>> http://www.open-mpi.org/community/lists/users/2014/12/25974.php
>>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> users mailing list
>>>>>>>>>>>>> us...@open-mpi.org
>>>>>>>>>>>>> Subscription:
>>>>>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>>>>>>>> Link to this post:
>>>>>>>>>>>>> http://www.open-mpi.org/community/lists/users/2014/12/25975.php
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> users mailing list
>>>>>>>>>>>>> us...@open-mpi.org
>>>>>>>>>>>>> Subscription:
>>>>>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>>>>>>>> Link to this post:
>>>>>>>>>>>>> http://www.open-mpi.org/community/lists/users/2014/12/25978.php
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> users mailing list
>>>>>>>>>>>> us...@open-mpi.org
>>>>>>>>>>>> Subscription:
>>>>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>>>>>>> Link to this post:
>>>>>>>>>>>> http://www.open-mpi.org/community/lists/users/2014/12/25979.php
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> users mailing list
>>>>>>>>>>> us...@open-mpi.org
>>>>>>>>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>>>>>> Link to this post:
>>>>>>>>>>> http://www.open-mpi.org/community/lists/users/2014/12/25981.php
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> users mailing list
>>>>>>>>>> us...@open-mpi.org
>>>>>>>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>>>>> Link to this post:
>>>>>>>>>> http://www.open-mpi.org/community/lists/users/2014/12/25982.php
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> users mailing list
>>>>>>>>> us...@open-mpi.org
>>>>>>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>>>> Link to this post:
>>>>>>>>> http://www.open-mpi.org/community/lists/users/2014/12/25991.php
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> users mailing list
>>>>>>>> us...@open-mpi.org
>>>>>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>>> Link to this post:
>>>>>>>> http://www.open-mpi.org/community/lists/users/2014/12/26002.php
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> users mailing list
>>>>>>> us...@open-mpi.org
>>>>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>> Link to this post:
>>>>>>> http://www.open-mpi.org/community/lists/users/2014/12/26003.php
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> users mailing list
>>>>> us...@open-mpi.org
>>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>> Link to this post:
>>>>> http://www.open-mpi.org/community/lists/users/2014/12/26010.php
>>>>>
>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> us...@open-mpi.org
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>> Link to this post:
>>>> http://www.open-mpi.org/community/lists/users/2014/12/26011.php
>>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> us...@open-mpi.org
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>>> Link to this post:
>>> http://www.open-mpi.org/community/lists/users/2014/12/26013.php
>>>
>>
>>
>> _______________________________________________
>> users mailing list
>> us...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
>> Link to this post:
>> http://www.open-mpi.org/community/lists/users/2014/12/26014.php
>>
>
