2006-07-10 21:25:33 +00:00
|
|
|
# -*- text -*-
|
|
|
|
|
#
|
|
|
|
|
# Copyright (c) 2004-2005 The Trustees of Indiana University and Indiana
|
|
|
|
|
# University Research and Technology
|
|
|
|
|
# Corporation. All rights reserved.
|
|
|
|
|
# Copyright (c) 2004-2005 The University of Tennessee and The University
|
|
|
|
|
# of Tennessee Research Foundation. All rights
|
|
|
|
|
# reserved.
|
|
|
|
|
# Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
|
|
|
|
|
# University of Stuttgart. All rights reserved.
|
|
|
|
|
# Copyright (c) 2004-2005 The Regents of the University of California.
|
|
|
|
|
# All rights reserved.
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 03:40:11 +00:00
|
|
|
# Copyright (c) 2011 Cisco Systems, Inc. All rights reserved.
|
2011-12-02 14:10:08 +00:00
|
|
|
# Copyright (c) 2011 Los Alamos National Security, LLC.
|
|
|
|
|
# All rights reserved.
|
2006-07-10 21:25:33 +00:00
|
|
|
# $COPYRIGHT$
|
|
|
|
|
#
|
|
|
|
|
# Additional copyrights may follow
|
|
|
|
|
#
|
|
|
|
|
# $HEADER$
|
|
|
|
|
#
|
|
|
|
|
# This is the US/English general help file for Open RTE's orterun.
|
|
|
|
|
#
|
|
|
|
|
[orte-rmaps-base:alloc-error]
|
|
|
|
|
There are not enough slots available in the system to satisfy the %d slots
|
|
|
|
|
that were requested by the application:
|
|
|
|
|
%s
|
|
|
|
|
|
|
|
|
|
Either request fewer slots for your application, or make more slots available
|
|
|
|
|
for use.
|
|
|
|
|
[orte-rmaps-base:not-all-mapped-alloc]
|
|
|
|
|
Some of the requested hosts are not included in the current allocation for the
|
|
|
|
|
application:
|
|
|
|
|
%s
|
|
|
|
|
The requested hosts were:
|
|
|
|
|
%s
|
|
|
|
|
|
|
|
|
|
Verify that you have mapped the allocated resources properly using the
|
2008-02-28 01:57:57 +00:00
|
|
|
--host or --hostfile specification.
|
2006-07-10 21:25:33 +00:00
|
|
|
[orte-rmaps-base:no-mapped-node]
|
|
|
|
|
There are no allocated resources for the application
|
|
|
|
|
%s
|
|
|
|
|
that match the requested mapping:
|
|
|
|
|
%s
|
|
|
|
|
|
2008-02-28 01:57:57 +00:00
|
|
|
Verify that you have mapped the allocated resources properly using the
|
|
|
|
|
--host or --hostfile specification.
|
2006-10-26 21:46:18 +00:00
|
|
|
[orte-rmaps-base:nolocal-no-available-resources]
|
|
|
|
|
There are no available nodes allocated to this job. This could be because
|
|
|
|
|
no nodes were found or all the available nodes were already used.
|
|
|
|
|
|
|
|
|
|
Note that since the -nolocal option was given no processes can be
|
|
|
|
|
launched on the local node.
|
|
|
|
|
[orte-rmaps-base:no-available-resources]
|
2010-07-01 19:39:31 +00:00
|
|
|
No nodes are available for this job, either due to a failure to
|
|
|
|
|
allocate nodes to the job, or allocated nodes being marked
|
|
|
|
|
as unavailable (e.g., down, rebooting, or a process attempting
|
|
|
|
|
to be relocated to another node when none are available).
|
2006-10-26 21:46:18 +00:00
|
|
|
[orte-rmaps-base:all-available-resources-used]
|
|
|
|
|
All nodes which are allocated for this job are already filled.
|
2008-02-28 01:57:57 +00:00
|
|
|
#
|
|
|
|
|
[out-of-vpids]
|
|
|
|
|
The system has exhausted its available ranks - the application is attempting
|
|
|
|
|
to spawn too many daemons and will be aborted.
|
|
|
|
|
|
|
|
|
|
This may be resolved by increasing the number of available ranks by
|
|
|
|
|
re-configuring with the --enable-jumbo-apps option, and then
|
|
|
|
|
re-building the application.
|
2009-09-07 03:36:10 +00:00
|
|
|
#
|
|
|
|
|
[rmaps:too-many-procs]
|
|
|
|
|
Your job has requested a conflicting number of processes for the
|
|
|
|
|
application:
|
|
|
|
|
|
|
|
|
|
App: %s
|
|
|
|
|
number of procs: %d
|
|
|
|
|
|
|
|
|
|
This is more processes than we can launch under the following
|
|
|
|
|
additional directives and conditions:
|
|
|
|
|
|
|
|
|
|
%s: %d
|
|
|
|
|
%s: %d
|
2006-10-26 21:46:18 +00:00
|
|
|
|
2009-09-07 03:36:10 +00:00
|
|
|
Please revise the conflict and try again.
|
2009-10-13 04:19:07 +00:00
|
|
|
#
|
|
|
|
|
[too-many-cpus-per-rank]
|
|
|
|
|
Your job has requested more cpus per process(rank) than there
|
|
|
|
|
are cpus in a socket:
|
|
|
|
|
|
|
|
|
|
Cpus/rank: %d
|
|
|
|
|
#cpus/socket: %d
|
|
|
|
|
|
|
|
|
|
Please correct one or both of these values and try again.
|
2011-02-15 23:24:31 +00:00
|
|
|
#
|
|
|
|
|
[failed-map]
|
|
|
|
|
Your job failed to map. Either no mapper was available, or none
|
|
|
|
|
of the available mappers was able to perform the requested
|
|
|
|
|
mapping operation. This can happen if you request a map type
|
|
|
|
|
(e.g., loadbalance) and the corresponding mapper was not built.
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 03:40:11 +00:00
|
|
|
#
|
|
|
|
|
[unrecognized-policy]
|
|
|
|
|
The specified %s policy is not recognized:
|
|
|
|
|
|
|
|
|
|
Policy: %s
|
|
|
|
|
|
|
|
|
|
Please check for a typo or ensure that the option is a supported
|
|
|
|
|
one.
|
|
|
|
|
#
|
|
|
|
|
[redefining-policy]
|
|
|
|
|
Conflicting directives for %s policy are causing the policy
|
|
|
|
|
to be redefined:
|
|
|
|
|
|
|
|
|
|
New policy: %s
|
|
|
|
|
Prior policy: %s
|
|
|
|
|
|
|
|
|
|
Please check that only one policy is defined.
|
|
|
|
|
#
|
|
|
|
|
[rmaps:binding-target-not-found]
|
|
|
|
|
A request was made to bind to %s, but an appropriate target could not
|
|
|
|
|
be found on node %s.
|
|
|
|
|
#
|
|
|
|
|
[rmaps:binding-overload]
|
|
|
|
|
A request was made to bind to that would result in binding more
|
|
|
|
|
processes than cpus on a resource:
|
|
|
|
|
|
|
|
|
|
Bind to: %s
|
|
|
|
|
Node: %s
|
|
|
|
|
#processes: %d
|
|
|
|
|
#cpus: %d
|
|
|
|
|
|
|
|
|
|
You can override this protection by adding the "overload-allowed"
|
|
|
|
|
option to your binding directive.
|
|
|
|
|
#
|
|
|
|
|
[rmaps:no-topology]
|
2012-01-27 12:21:45 +00:00
|
|
|
A mapping directive was given that requires knowledge of
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 03:40:11 +00:00
|
|
|
a remote node's topology. However, no topology info is
|
|
|
|
|
available for the following node:
|
|
|
|
|
|
|
|
|
|
Node: %s
|
|
|
|
|
|
|
|
|
|
The job cannot be executed under this condition. Please either
|
2012-01-27 12:21:45 +00:00
|
|
|
remove the directive or investigate the lack of topology info.
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 03:40:11 +00:00
|
|
|
#
|
|
|
|
|
[rmaps:no-available-cpus]
|
|
|
|
|
While computing bindings, we found no available cpus on
|
|
|
|
|
the following node:
|
|
|
|
|
|
|
|
|
|
Node: %s
|
|
|
|
|
|
|
|
|
|
Please check your allocation.
|
|
|
|
|
#
|
|
|
|
|
[rmaps:cpubind-not-supported]
|
|
|
|
|
A request was made to bind a process, but at least one node does NOT
|
|
|
|
|
support binding processes to cpus.
|
|
|
|
|
|
|
|
|
|
Node: %s
|
|
|
|
|
#
|
|
|
|
|
[rmaps:membind-not-supported]
|
|
|
|
|
WARNING: a request was made to bind a process. While the system
|
|
|
|
|
supports binding the process itself, at least one node does NOT
|
|
|
|
|
support binding memory to the process location.
|
|
|
|
|
|
|
|
|
|
Node: %s
|
|
|
|
|
|
|
|
|
|
This is a warning only; your job will continue, though performance may
|
|
|
|
|
be degraded.
|
|
|
|
|
#
|
|
|
|
|
[rmaps:membind-not-supported-fatal]
|
|
|
|
|
A request was made to bind a process. While the system
|
|
|
|
|
supports binding the process itself, at least one node does NOT
|
|
|
|
|
support binding memory to the process location.
|
|
|
|
|
|
|
|
|
|
Node: %s
|
|
|
|
|
|
|
|
|
|
The provided memory binding policy requires that we abort the
|
|
|
|
|
job at this time.
|
|
|
|
|
#
|
|
|
|
|
[rmaps:no-bindable-objects]
|
|
|
|
|
No bindable objects of the specified type were available
|
|
|
|
|
on at least one node:
|
|
|
|
|
|
|
|
|
|
Node: %s
|
|
|
|
|
Target: %s
|
|
|
|
|
#
|
|
|
|
|
[rmaps:unknown-binding-level]
|
|
|
|
|
Unknown binding level:
|
2011-02-15 23:24:31 +00:00
|
|
|
|
At long last, the fabled revision to the affinity system has arrived. A more detailed explanation of how this all works will be presented here:
https://svn.open-mpi.org/trac/ompi/wiki/ProcessPlacement
The wiki page is incomplete at the moment, but I hope to complete it over the next few days. I will provide updates on the devel list. As the wiki page states, the default and most commonly used options remain unchanged (except as noted below). New, esoteric and complex options have been added, but unless you are a true masochist, you are unlikely to use many of them beyond perhaps an initial curiosity-motivated experimentation.
In a nutshell, this commit revamps the map/rank/bind procedure to take into account topology info on the compute nodes. I have, for the most part, preserved the default behaviors, with three notable exceptions:
1. I have at long last bowed my head in submission to the system admin's of managed clusters. For years, they have complained about our default of allowing users to oversubscribe nodes - i.e., to run more processes on a node than allocated slots. Accordingly, I have modified the default behavior: if you are running off of hostfile/dash-host allocated nodes, then the default is to allow oversubscription. If you are running off of RM-allocated nodes, then the default is to NOT allow oversubscription. Flags to override these behaviors are provided, so this only affects the default behavior.
2. both cpus/rank and stride have been removed. The latter was demanded by those who didn't understand the purpose behind it - and I agreed as the users who requested it are no longer using it. The former was removed temporarily pending implementation.
3. vm launch is now the sole method for starting OMPI. It was just too darned hard to maintain multiple launch procedures - maybe someday, provided someone can demonstrate a reason to do so.
As Jeff stated, it is impossible to fully test a change of this size. I have tested it on Linux and Mac, covering all the default and simple options, singletons, and comm_spawn. That said, I'm sure others will find problems, so I'll be watching MTT results until this stabilizes.
This commit was SVN r25476.
2011-11-15 03:40:11 +00:00
|
|
|
Target: %s
|
|
|
|
|
Cache level: %u
|
2011-12-02 14:10:08 +00:00
|
|
|
#
|
|
|
|
|
[orte-rmaps-base:missing-daemon]
|
|
|
|
|
While attempting to build a map of this job, a node
|
|
|
|
|
was detected to be missing a daemon:
|
|
|
|
|
|
|
|
|
|
Node: %s
|
|
|
|
|
|
|
|
|
|
This usually indicates a mismatch between what the
|
|
|
|
|
allocation provided for the node name versus what was
|
|
|
|
|
actually found on the node.
|
2012-08-04 21:52:36 +00:00
|
|
|
#
|
|
|
|
|
[orte-rmaps-base:no-objects]
|
|
|
|
|
No objects of the specified type were found on at least one node:
|
|
|
|
|
|
|
|
|
|
Type: %s
|
|
|
|
|
Node: %s
|
|
|
|
|
|
|
|
|
|
The map cannot be done as specified.
|