Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

From: Ralph Castain (rhc_at_[hidden])
Date: 2007-07-27 08:42:14

On 7/26/07 4:22 PM, "Aurelien Bouteiller" <bouteill_at_[hidden]> wrote:

>> mpirun -hostfile big_pool -n 10 -host 1,2,3,4 application : -n 2 -host
>> 99,100 ft_server
> This will not work: this is a way to launch MIMD jobs, that share the
> same COMM_WORLD. Not the way to launch two different applications that
> interact trough Accept/Connect.
> Direct consequence on simple NAS benchmarks are:
> * if the second command does not use MPI-Init, then the first
> application locks forever in MPI-Init
> * if both use MPI init, the MPI_Comm_size of the jobs are incorrect.
> ****
> bouteill_at_dancer:~$ ompi-build/debug/bin/mpirun -prefix
> /home/bouteill/ompi-build/debug/ -np 4 -host node01,node02,node03,node04
> NPB3.2-MPI/bin/lu.A.4 : -np 1 -host node01 NPB3.2-MPI/bin/mg.A.1
> NAS Parallel Benchmarks 3.2 -- LU Benchmark
> Warning: program is running on 5 processors
> but was compiled for 4
> Size: 64x 64x 64
> Iterations: 250
> Number of processes: 5

Okay - of course, I can't possibly have any idea how your application
works... ;-)

However, it would be trivial to simply add two options to the app_context
command line:

1. designates that this app_context is to be launched as a separate job

2. indicates that this app_context is to be "connected" ala connect/accept
to the other app_contexts (if you want, we could even take an argument
indicating which app_contexts it is to be connected to). Or we could reverse
this as indicate we want it to be disconnected - all depends upon what
default people want to define.

This would solve the problem you describe while still allowing us to avoid
allocation confusion. I'll send it out separately as an RFC.


> _______________________________________________
> devel mailing list
> devel_at_[hidden]