Ah - thx for catching that, I'll remove that check. It no longer is
required.

Thx!

On Tue, May 5, 2009 at 7:04 AM, Lenny Verkhovsky <lenny.verkhov...@gmail.com
> wrote:

> According to the code it does cares.
>
> $vi orte/mca/rmaps/rank_file/rmaps_rank_file.c +572
>
> ival = orte_rmaps_rank_file_value.ival;
>   if ( ival > (np-1) ) {
>   orte_show_help("help-rmaps_rank_file.txt", "bad-rankfile", true, ival,
> rankfile);
>   rc = ORTE_ERR_BAD_PARAM;
>   goto unlock;
>   }
>
> If I remember correctly, I used an array to map ranks, and since the length
> of array is NP, maximum index must be less than np, so if you have the
> number of rank > NP, you have no place to put it inside array.
>
> "Likewise, if you have more procs than the rankfile specifies, we map the
> additional procs either byslot (default) or bynode (if you specify that
> option). So the rankfile doesn't need to contain an entry for every proc."
>  - Correct point.
>
> Lenny.
>
> On 5/5/09, Ralph Castain <r...@open-mpi.org> wrote:
>>
>> Sorry Lenny, but that isn't correct. The rankfile mapper doesn't care if
>> the rankfile contains additional info - it only maps up to the number of
>> processes, and ignores anything beyond that number. So there is no need to
>> remove the additional info.
>>
>> Likewise, if you have more procs than the rankfile specifies, we map the
>> additional procs either byslot (default) or bynode (if you specify that
>> option). So the rankfile doesn't need to contain an entry for every proc.
>>
>> Just don't want to confuse folks.
>> Ralph
>>
>>
>>
>> On Tue, May 5, 2009 at 5:59 AM, Lenny Verkhovsky <
>> lenny.verkhov...@gmail.com> wrote:
>>
>>> Hi,
>>> maximum rank number must be less then np.
>>> if np=1 then there is only rank 0 in the system, so rank 1 is invalid.
>>> please remove "rank 1=node2 slot=*" from the rankfile
>>> Best regards,
>>> Lenny.
>>>
>>> On Mon, May 4, 2009 at 11:14 AM, Geoffroy Pignot <geopig...@gmail.com>wrote:
>>>
>>>> Hi ,
>>>>
>>>> I got the 
>>>> openmpi-1.4a1r21095.tar.gz<http://www.open-mpi.org/nightly/trunk/openmpi-1.4a1r21095.tar.gz>tarball,
>>>>  but unfortunately my command doesn't work
>>>>
>>>> cat rankf:
>>>> rank 0=node1 slot=*
>>>> rank 1=node2 slot=*
>>>>
>>>> cat hostf:
>>>> node1 slots=2
>>>> node2 slots=2
>>>>
>>>> mpirun  --rankfile rankf --hostfile hostf  --host node1 -n 1 hostname :
>>>> --host node2 -n 1 hostname
>>>>
>>>> Error, invalid rank (1) in the rankfile (rankf)
>>>>
>>>>
>>>> --------------------------------------------------------------------------
>>>> [r011n006:28986] [[45541,0],0] ORTE_ERROR_LOG: Bad parameter in file
>>>> rmaps_rank_file.c at line 403
>>>> [r011n006:28986] [[45541,0],0] ORTE_ERROR_LOG: Bad parameter in file
>>>> base/rmaps_base_map_job.c at line 86
>>>> [r011n006:28986] [[45541,0],0] ORTE_ERROR_LOG: Bad parameter in file
>>>> base/plm_base_launch_support.c at line 86
>>>> [r011n006:28986] [[45541,0],0] ORTE_ERROR_LOG: Bad parameter in file
>>>> plm_rsh_module.c at line 1016
>>>>
>>>>
>>>> Ralph, could you tell me if my command syntax is correct or not ? if
>>>> not, give me the expected one ?
>>>>
>>>> Regards
>>>>
>>>> Geoffroy
>>>>
>>>>
>>>>
>>>>
>>>> 2009/4/30 Geoffroy Pignot <geopig...@gmail.com>
>>>>
>>>>> Immediately Sir !!! :)
>>>>>
>>>>> Thanks again Ralph
>>>>>
>>>>> Geoffroy
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> Message: 2
>>>>>> Date: Thu, 30 Apr 2009 06:45:39 -0600
>>>>>> From: Ralph Castain <r...@open-mpi.org>
>>>>>> Subject: Re: [OMPI users] 1.3.1 -rf rankfile behaviour ??
>>>>>> To: Open MPI Users <us...@open-mpi.org>
>>>>>> Message-ID:
>>>>>>        <71d2d8cc0904300545v61a42fe1k50086d2704d0f...@mail.gmail.com>
>>>>>> Content-Type: text/plain; charset="iso-8859-1"
>>>>>>
>>>>>> I believe this is fixed now in our development trunk - you can
>>>>>> download any
>>>>>> tarball starting from last night and give it a try, if you like. Any
>>>>>> feedback would be appreciated.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>
>>>>>> On Apr 14, 2009, at 7:57 AM, Ralph Castain wrote:
>>>>>>
>>>>>> Ah now, I didn't say it -worked-, did I? :-)
>>>>>>
>>>>>> Clearly a bug exists in the program. I'll try to take a look at it (if
>>>>>> Lenny
>>>>>> doesn't get to it first), but it won't be until later in the week.
>>>>>>
>>>>>> On Apr 14, 2009, at 7:18 AM, Geoffroy Pignot wrote:
>>>>>>
>>>>>> I agree with you Ralph , and that 's what I expect from openmpi but my
>>>>>> second example shows that it's not working
>>>>>>
>>>>>> cat hostfile.0
>>>>>>   r011n002 slots=4
>>>>>>   r011n003 slots=4
>>>>>>
>>>>>>  cat rankfile.0
>>>>>>    rank 0=r011n002 slot=0
>>>>>>    rank 1=r011n003 slot=1
>>>>>>
>>>>>> mpirun --hostfile hostfile.0 -rf rankfile.0 -n 1 hostname : -n 1
>>>>>> hostname
>>>>>> ### CRASHED
>>>>>>
>>>>>> > > Error, invalid rank (1) in the rankfile (rankfile.0)
>>>>>> > >
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > > [r011n002:25129] [[63976,0],0] ORTE_ERROR_LOG: Bad parameter in
>>>>>> file
>>>>>> > > rmaps_rank_file.c at line 404
>>>>>> > > [r011n002:25129] [[63976,0],0] ORTE_ERROR_LOG: Bad parameter in
>>>>>> file
>>>>>> > > base/rmaps_base_map_job.c at line 87
>>>>>> > > [r011n002:25129] [[63976,0],0] ORTE_ERROR_LOG: Bad parameter in
>>>>>> file
>>>>>> > > base/plm_base_launch_support.c at line 77
>>>>>> > > [r011n002:25129] [[63976,0],0] ORTE_ERROR_LOG: Bad parameter in
>>>>>> file
>>>>>> > > plm_rsh_module.c at line 985
>>>>>> > >
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > > A daemon (pid unknown) died unexpectedly on signal 1  while
>>>>>> > attempting to
>>>>>> > > launch so we are aborting.
>>>>>> > >
>>>>>> > > There may be more information reported by the environment (see
>>>>>> > above).
>>>>>> > >
>>>>>> > > This may be because the daemon was unable to find all the needed
>>>>>> > shared
>>>>>> > > libraries on the remote node. You may set your LD_LIBRARY_PATH to
>>>>>> > have the
>>>>>> > > location of the shared libraries on the remote nodes and this will
>>>>>> > > automatically be forwarded to the remote nodes.
>>>>>> > >
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > >
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > > orterun noticed that the job aborted, but has no info as to the
>>>>>> > process
>>>>>> > > that caused that situation.
>>>>>> > >
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > > orterun: clean termination accomplished
>>>>>>
>>>>>>
>>>>>>
>>>>>> Message: 4
>>>>>> Date: Tue, 14 Apr 2009 06:55:58 -0600
>>>>>> From: Ralph Castain <r...@lanl.gov>
>>>>>> Subject: Re: [OMPI users] 1.3.1 -rf rankfile behaviour ??
>>>>>> To: Open MPI Users <us...@open-mpi.org>
>>>>>> Message-ID: <f6290ada-a196-43f0-a853-cbcb802d8...@lanl.gov>
>>>>>> Content-Type: text/plain; charset="us-ascii"; Format="flowed";
>>>>>>       DelSp="yes"
>>>>>>
>>>>>> The rankfile cuts across the entire job - it isn't applied on an
>>>>>> app_context basis. So the ranks in your rankfile must correspond to
>>>>>> the eventual rank of each process in the cmd line.
>>>>>>
>>>>>> Unfortunately, that means you have to count ranks. In your case, you
>>>>>> only have four, so that makes life easier. Your rankfile would look
>>>>>> something like this:
>>>>>>
>>>>>> rank 0=r001n001 slot=0
>>>>>> rank 1=r001n002 slot=1
>>>>>> rank 2=r001n001 slot=1
>>>>>> rank 3=r001n002 slot=2
>>>>>>
>>>>>> HTH
>>>>>> Ralph
>>>>>>
>>>>>> On Apr 14, 2009, at 12:19 AM, Geoffroy Pignot wrote:
>>>>>>
>>>>>> > Hi,
>>>>>> >
>>>>>> > I agree that my examples are not very clear. What I want to do is to
>>>>>> > launch a multiexes application (masters-slaves) and benefit from the
>>>>>> > processor affinity.
>>>>>> > Could you show me how to convert this command , using -rf option
>>>>>> > (whatever the affinity is)
>>>>>> >
>>>>>> > mpirun -n 1 -host r001n001 master.x options1  : -n 1 -host r001n002
>>>>>> > master.x options2 : -n 1 -host r001n001 slave.x options3 : -n 1 -
>>>>>> > host r001n002 slave.x options4
>>>>>> >
>>>>>> > Thanks for your help
>>>>>> >
>>>>>> > Geoffroy
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > Message: 2
>>>>>> > Date: Sun, 12 Apr 2009 18:26:35 +0300
>>>>>> > From: Lenny Verkhovsky <lenny.verkhov...@gmail.com>
>>>>>> > Subject: Re: [OMPI users] 1.3.1 -rf rankfile behaviour ??
>>>>>> > To: Open MPI Users <us...@open-mpi.org>
>>>>>> > Message-ID:
>>>>>> >        <453d39990904120826t2e1d1d33l7bb1fe3de65b5...@mail.gmail.com
>>>>>> >
>>>>>> > Content-Type: text/plain; charset="iso-8859-1"
>>>>>> >
>>>>>> > Hi,
>>>>>> >
>>>>>> > The first "crash" is OK, since your rankfile has ranks 0 and 1
>>>>>> > defined,
>>>>>> > while n=1, which means only rank 0 is present and can be allocated.
>>>>>> >
>>>>>> > NP must be >= the largest rank in rankfile.
>>>>>> >
>>>>>> > What exactly are you trying to do ?
>>>>>> >
>>>>>> > I tried to recreate your seqv but all I got was
>>>>>> >
>>>>>> > ~/work/svn/ompi/trunk/build_x86-64/install/bin/mpirun --hostfile
>>>>>> > hostfile.0
>>>>>> > -rf rankfile.0 -n 1 hostname : -rf rankfile.1 -n 1 hostname
>>>>>> > [witch19:30798] mca: base: component_find: paffinity
>>>>>> > "mca_paffinity_linux"
>>>>>> > uses an MCA interface that is not recognized (component MCA v1.0.0
>>>>>> !=
>>>>>> > supported MCA v2.0.0) -- ignored
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > It looks like opal_init failed for some reason; your parallel
>>>>>> > process is
>>>>>> > likely to abort. There are many reasons that a parallel process can
>>>>>> > fail during opal_init; some of which are due to configuration or
>>>>>> > environment problems. This failure appears to be an internal
>>>>>> failure;
>>>>>> > here's some additional information (which may only be relevant to an
>>>>>> > Open MPI developer):
>>>>>> >
>>>>>> >  opal_carto_base_select failed
>>>>>> >  --> Returned value -13 instead of OPAL_SUCCESS
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > [witch19:30798] [[INVALID],INVALID] ORTE_ERROR_LOG: Not found in
>>>>>> file
>>>>>> > ../../orte/runtime/orte_init.c at line 78
>>>>>> > [witch19:30798] [[INVALID],INVALID] ORTE_ERROR_LOG: Not found in
>>>>>> file
>>>>>> > ../../orte/orted/orted_main.c at line 344
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > A daemon (pid 11629) died unexpectedly with status 243 while
>>>>>> > attempting
>>>>>> > to launch so we are aborting.
>>>>>> >
>>>>>> > There may be more information reported by the environment (see
>>>>>> above).
>>>>>> >
>>>>>> > This may be because the daemon was unable to find all the needed
>>>>>> > shared
>>>>>> > libraries on the remote node. You may set your LD_LIBRARY_PATH to
>>>>>> > have the
>>>>>> > location of the shared libraries on the remote nodes and this will
>>>>>> > automatically be forwarded to the remote nodes.
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > mpirun noticed that the job aborted, but has no info as to the
>>>>>> process
>>>>>> > that caused that situation.
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > mpirun: clean termination accomplished
>>>>>> >
>>>>>> >
>>>>>> > Lenny.
>>>>>> >
>>>>>> >
>>>>>> > On 4/10/09, Geoffroy Pignot <geopig...@gmail.com> wrote:
>>>>>> > >
>>>>>> > > Hi ,
>>>>>> > >
>>>>>> > > I am currently testing the process affinity capabilities of
>>>>>> > openmpi and I
>>>>>> > > would like to know if the rankfile behaviour I will describe below
>>>>>> > is normal
>>>>>> > > or not ?
>>>>>> > >
>>>>>> > > cat hostfile.0
>>>>>> > > r011n002 slots=4
>>>>>> > > r011n003 slots=4
>>>>>> > >
>>>>>> > > cat rankfile.0
>>>>>> > > rank 0=r011n002 slot=0
>>>>>> > > rank 1=r011n003 slot=1
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>> ##################################################################################
>>>>>> > >
>>>>>> > > mpirun --hostfile hostfile.0 -rf rankfile.0 -n 2  hostname ### OK
>>>>>> > > r011n002
>>>>>> > > r011n003
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>> ##################################################################################
>>>>>> > > but
>>>>>> > > mpirun --hostfile hostfile.0 -rf rankfile.0 -n 1 hostname : -n 1
>>>>>> > hostname
>>>>>> > > ### CRASHED
>>>>>> > > *
>>>>>> > >
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > > Error, invalid rank (1) in the rankfile (rankfile.0)
>>>>>> > >
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > > [r011n002:25129] [[63976,0],0] ORTE_ERROR_LOG: Bad parameter in
>>>>>> file
>>>>>> > > rmaps_rank_file.c at line 404
>>>>>> > > [r011n002:25129] [[63976,0],0] ORTE_ERROR_LOG: Bad parameter in
>>>>>> file
>>>>>> > > base/rmaps_base_map_job.c at line 87
>>>>>> > > [r011n002:25129] [[63976,0],0] ORTE_ERROR_LOG: Bad parameter in
>>>>>> file
>>>>>> > > base/plm_base_launch_support.c at line 77
>>>>>> > > [r011n002:25129] [[63976,0],0] ORTE_ERROR_LOG: Bad parameter in
>>>>>> file
>>>>>> > > plm_rsh_module.c at line 985
>>>>>> > >
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > > A daemon (pid unknown) died unexpectedly on signal 1  while
>>>>>> > attempting to
>>>>>> > > launch so we are aborting.
>>>>>> > >
>>>>>> > > There may be more information reported by the environment (see
>>>>>> > above).
>>>>>> > >
>>>>>> > > This may be because the daemon was unable to find all the needed
>>>>>> > shared
>>>>>> > > libraries on the remote node. You may set your LD_LIBRARY_PATH to
>>>>>> > have the
>>>>>> > > location of the shared libraries on the remote nodes and this will
>>>>>> > > automatically be forwarded to the remote nodes.
>>>>>> > >
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > >
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > > orterun noticed that the job aborted, but has no info as to the
>>>>>> > process
>>>>>> > > that caused that situation.
>>>>>> > >
>>>>>> >
>>>>>> --------------------------------------------------------------------------
>>>>>> > > orterun: clean termination accomplished
>>>>>> > > *
>>>>>> > > It seems that the rankfile option is not propagted to the second
>>>>>> > command
>>>>>> > > line ; there is no global understanding of the ranking inside a
>>>>>> > mpirun
>>>>>> > > command.
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>> ##################################################################################
>>>>>> > >
>>>>>> > > Assuming that , I tried to provide a rankfile to each command
>>>>>> line:
>>>>>> > >
>>>>>> > > cat rankfile.0
>>>>>> > > rank 0=r011n002 slot=0
>>>>>> > >
>>>>>> > > cat rankfile.1
>>>>>> > > rank 0=r011n003 slot=1
>>>>>> > >
>>>>>> > > mpirun --hostfile hostfile.0 -rf rankfile.0 -n 1 hostname : -rf
>>>>>> > rankfile.1
>>>>>> > > -n 1 hostname ### CRASHED
>>>>>> > > *[r011n002:28778] *** Process received signal ***
>>>>>> > > [r011n002:28778] Signal: Segmentation fault (11)
>>>>>> > > [r011n002:28778] Signal code: Address not mapped (1)
>>>>>> > > [r011n002:28778] Failing at address: 0x34
>>>>>> > > [r011n002:28778] [ 0] [0xffffe600]
>>>>>> > > [r011n002:28778] [ 1]
>>>>>> > > /tmp/HALMPI/openmpi-1.3.1/lib/libopen-rte.so.
>>>>>> > 0(orte_odls_base_default_get_add_procs_data+0x55d)
>>>>>> > > [0x5557decd]
>>>>>> > > [r011n002:28778] [ 2]
>>>>>> > > /tmp/HALMPI/openmpi-1.3.1/lib/libopen-rte.so.
>>>>>> > 0(orte_plm_base_launch_apps+0x117)
>>>>>> > > [0x555842a7]
>>>>>> > > [r011n002:28778] [ 3] /tmp/HALMPI/openmpi-1.3.1/lib/openmpi/
>>>>>> > mca_plm_rsh.so
>>>>>> > > [0x556098c0]
>>>>>> > > [r011n002:28778] [ 4] /tmp/HALMPI/openmpi-1.3.1/bin/orterun
>>>>>> > [0x804aa27]
>>>>>> > > [r011n002:28778] [ 5] /tmp/HALMPI/openmpi-1.3.1/bin/orterun
>>>>>> > [0x804a022]
>>>>>> > > [r011n002:28778] [ 6] /lib/libc.so.6(__libc_start_main+0xdc)
>>>>>> > [0x9f1dec]
>>>>>> > > [r011n002:28778] [ 7] /tmp/HALMPI/openmpi-1.3.1/bin/orterun
>>>>>> > [0x8049f71]
>>>>>> > > [r011n002:28778] *** End of error message ***
>>>>>> > > Segmentation fault (core dumped)*
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> > > I hope that I've found a bug because it would be very important
>>>>>> > for me to
>>>>>> > > have this kind of capabiliy .
>>>>>> > > Launch a multiexe mpirun command line and be able to bind my exes
>>>>>> > and
>>>>>> > > sockets together.
>>>>>> > >
>>>>>> > > Thanks in advance for your help
>>>>>> > >
>>>>>> > > Geoffroy
>>>>>> > _______________________________________________
>>>>>> > users mailing list
>>>>>> > us...@open-mpi.org
>>>>>> > http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>
>>>>>> -------------- next part --------------
>>>>>> HTML attachment scrubbed and removed
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> users mailing list
>>>>>> us...@open-mpi.org
>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>
>>>>>> End of users Digest, Vol 1202, Issue 2
>>>>>> **************************************
>>>>>>
>>>>>> _______________________________________________
>>>>>> users mailing list
>>>>>> us...@open-mpi.org
>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>
>>>>>> _______________________________________________
>>>>>> users mailing list
>>>>>> us...@open-mpi.org
>>>>>> -------------- next part --------------
>>>>>> HTML attachment scrubbed and removed
>>>>>>
>>>>>> ------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> users mailing list
>>>>>> us...@open-mpi.org
>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>>>
>>>>>> End of users Digest, Vol 1218, Issue 2
>>>>>> **************************************
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> us...@open-mpi.org
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> us...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>>
>>
>>
>> _______________________________________________
>> users mailing list
>> us...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>
>
>
> _______________________________________________
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>

Reply via email to