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
>
