pbs_resources(7B)

💖 pbs_resources — computational resources for PBS jobs 💖

okay so this is pbs_resources(7B), bestie: the PBS Professional page all about computational resources for PBS jobs. it’s giving “everything you need to know about resources, limits, and placement” energy, and honestly? iconic. 💅

🌸 NAME 🌸

• pbs_resources — computational resources for PBS jobs

✨ DESCRIPTION ✨

PBS gives you computational resources for jobs, limits on using resources, and control over how jobs are placed on the vnodes from which resources may be allocated for a job. literally the whole vibe of this page. 🫶

PBS provides built-in resources and custom resources for some systems, and allows the administrator to define custom resources. The administrator can specify which resources are available on a given vnode, as well as at the queue or server level (e.g. walltime). Resources can be “stretched” across vnodes. See the qmgr(8B) man page.

Resources defined at the queue or server level apply to an entire job. If resources are defined at the host level, they apply only to the part of the job running on that host. no cap, that distinction matters. 💀

---

💅 Allocating Resources to Jobs

Resources are allocated to jobs when jobs explicitly request them, when hooks assign them, and when defaults are assigned by PBS. Resources are explicitly requested in this order of precedence:

1. Through a qalter operation
2. Via the qsub command line
3. Via PBS job script directives

The administrator writes any hooks that assign resources to jobs. Default resources can be specified by the administrator (in order of precedence) for qsub arguments, queues, the server, and vnodes.

🔥 Limits on Resource Usage

A resource allocated to a job — whether explicitly requested or assigned via hooks or defaults — places a limit on the amount of that resource a job can use. This limit applies to how much the job can use on each vnode and to how much the whole job can use. both. at the same time. yes bestie. 😭

🦋 Placing Jobs on Vnodes

Jobs are placed on vnodes according to their explicit placement request, or according to default placement rules. The explicit placement request can be specified (in order of precedence) using qalter, qsub, and PBS job script directives. Default placement rules can be specified for queues and the server, and rules for default placement take effect if no other placement specifications exist. A job’s placement request is specified in its place statement.

💀 Old Syntax

A job submitted with the old node or resource specification syntax will be converted to the new select and place syntax. If the job is submitted with -lnodes= or -lncpus= it will be converted to -l select= and -l place=. See BACKWARD COMPATIBILITY. Jobs cannot use both new and old syntax for resource requests.

not both, bestie. that’s an error waiting to happen. 🙈

🎀 Allocating Chunks and Job-wide Resources

Job resource requests are defined either at the host level in chunks specified in a selection statement, or as job-wide resources.

Job-wide format:

qsub ... -l <resource name>=<value>

Chunk format:

-l select=<chunks>

The only resources that can be requested in chunks are host-level resources, such as mem and ncpus. The only resources that can be in a job-wide request are server-level or queue-level resources, such as walltime.

🍓 Requesting Resources in Chunks

A chunk declares the value of each resource in a set of resources which are to be allocated as a unit to a job. All of a chunk must be taken from a single vnode. A chunk request is a host-level request, and it must be for a host-level resource. A chunk is the smallest set of resources that will be allocated to a job. It is one or more <resource name>=<value> statements separated by a colon, e.g.:

ncpus=2:mem=10GB:host=Host1
ncpus=1:mem=20GB:arch=linux

Chunks are described in a selection statement, which specifies how many of each kind of chunk. A selection statement is of the form:

-l select=[<N>:]<chunk>[+[<N>:]<chunk> ...]

If N is not specified, it is taken to be 1. No spaces are allowed between chunks.

Example of multiple chunks in a selection statement:

-l select=2:ncpus=1:mem=10GB+3:ncpus=2:mem=8GB

💜 Requesting Job-wide Resources

A job-wide resource request is for resource(s) at the server or queue level. This resource must be a server-level or queue-level resource. A job-wide resource is designed to be used by the entire job, and is available to the complex, not just one execution host. Job-wide resources are requested outside of a selection statement, in this form:

-l <resource name>=<value>[,<resource name>=<value> ...]

where resource name is either a consumable resource or a time-based resource such as walltime.

Example of job-wide resources: walltime

Do not mix old style resource or node specification with the new select and place statements. Do not use one in a job script and the other on the command line. This will result in an error. 💀

See the qsub(1B) man page for a detailed description of how to request resources and place jobs on vnodes.

🌈 Applying Resource Defaults

When a default resource is defined, it is applied to a job when that job does not explicitly request the resource. Jobs get default resources, both job-wide and per-chunk, with the following order of precedence, from:

1. Default qsub arguments
2. Default queue resources
3. Default server resources

For each chunk in the job’s selection statement, first queue chunk defaults are applied, then server chunk defaults are applied. If the chunk does not contain a resource defined in the defaults, the default is added. The chunk defaults are specified with "default_chunk.<resource name>".

For example, if the queue in which the job is enqueued has the following defaults defined:

default_chunk.ncpus=1
default_chunk.mem=2gb

a job submitted with this selection statement:

select=2:ncpus=4+1:mem=9gb

will have this specification after the default_chunk elements are applied:

select=2:ncpus=4:mem=2gb+1:ncpus=1:mem=9gb

In the above, mem=2gb and ncpus=1 are inherited from default_chunk.

If a default job-wide resource is defined which is not specified in a job’s resource request, it is added to the resource request. Queue defaults are applied first, then server defaults are applied to any remaining gaps in the resource request.

🌟 Specifying Default Resources

The administrator can specify default resources on the server and queue. These resources can be job-wide or apply to chunks. Job-wide resources are specified via resources_default on the server or queue, and chunk resources are specified via default_chunk on the server or queue.

The administrator can specify default resources to be added to any qsub arguments via the server’s default_qsub_arguments attribute.

🧚 Specifying Default Placement

The administrator can specify default job placement by setting a value for resources.default at the queue or server.

See the qmgr(8B) man page for how to set default resources.

🦋 How Default Resources Work When Moving Jobs Between Queues

If the job is moved from the current queue to a new queue, any default resources in the job’s resource list are removed. This includes a select specification and place directive generated by the rules for conversion from the old syntax. If a job’s resource is unset (undefined) and there exists a default value at the new queue or server, that default value is applied to the job’s resource list. If either select or place is missing from the job’s new resource list, it will be automatically generated, using any newly-inherited default values.

Example:

Given the following set of queue and server default values:

Server
   resources_default.ncpus=1

Queue QA
   resources_default.ncpus=2
   default_chunk.mem=2gb

Queue QB
   default_chunk.mem=1gb
   no default for ncpus

The following illustrate the equivalent select specification for jobs submitted into queue QA and then moved to (or submitted directly to) queue QB:

qsub -l ncpus=1 -lmem=4gb
   In QA:  select=1:ncpus=1:mem=4gb  -  no defaults need be applied
   In QB:  select=1:ncpus=1:mem=4gb  -  no defaults need be applied

qsub -l ncpus=1
   In QA: select=1:ncpus=1:mem=2gb
   In QB: select=1:ncpus=1:mem=1gb

qsub -lmem=4gb
   In QA: select=1:ncpus=2:mem=4gb
   In QB: select=1:ncpus=1:mem=4gb

qsub -l nodes=4
   In QA: select=4:ncpus=1:mem=2gb
   In QB: select=4:mem=1gb

qsub -l mem=16gb -l nodes=4
   In QA: select=4:ncpus=1:mem=4gb
   In QB: select=4:ncpus=1:mem=4gb

💀 Limits on Resource Usage

Each chunk’s per-chunk limits determine how much of any resource can be used in that chunk. Per-chunk resource usage limits are established by per-chunk resources, both from explicit requests and from defaults.

Job-wide resource limits set a limit for per-job resource usage. Job-wide resource limits are established both by requesting job-wide resources and by summing per-chunk consumable resources. Job-wide resource limits from sums of all chunks, including defaults, override those from job-wide defaults and resource requests. Limits include both explicitly requested resources and default resources.

If a job-wide resource limit exceeds queue or server restrictions, it will not be put in the queue or accepted by the server. If, while running, a job exceeds its limit for a consumable or time-based resource, it will be terminated. terminated, bestie. gone. 💀

👑 Controlling Placement of Jobs

Jobs are placed on vnodes according to their place statements. The place statement is specified, in order of precedence, via:

1. Explicit placement request in qalter
2. Explicit placement request in qsub
3. Explicit placement request in PBS job script directives
4. Default qsub place statement
5. Queue default placement rules
6. Server default placement rules
7. Built-in default conversion and placement rules

The place statement may be not be used without the select statement.

For a detailed description of the place statement, see the qsub(1B) man page.

Note that vnodes can have sharing attributes that override job placement requests. See the pbs_node_attributes(7B) man page.

🌸 Default Placement

If, after all defaults have been applied to a resource request that contains a selection statement, there is no place statement, then arrangement is set to free. Default sharing is shared.

If the job’s place statement does not contain group=resource, then a grouping defined at the queue level may be used, or a grouping defined at the server level if there is none at the queue level.

📦 Placement of Jobs Submitted with Old Syntax 📦

okay bestie, so if a job gets submitted with a node spec (-lnodes=) or a resource spec (-lncpus=), PBS is gonna convert that into select and place — following the rules down in BACKWARD COMPATIBILITY. slay.

🟢 Boolean Resources

A Boolean resource is literally just true or false. When you request a Boolean resource, you're specifying the required value for that Boolean resource. For example, if some vnodes have green=true and some have red=true, then a selection statement asking for two vnodes, each with one CPU, all green and no red, would be:

-l select=2:green=true:red=false:ncpus=1

🔥 Consumable Resources

Consumable resources are the ones where a job using them reduces how much is available to other concurrent jobs — think memory (mem), CPUs (ncpus), and licenses. Non-consumable resources include time-based resources such as walltime and CPU time (cput), plus string-value resources such as architecture (arch).

🎀 Custom Resources

Custom resources are site-defined and site-dependent, meaning the administrator defines them. These are typically used for licenses and scratch space. PBS provides custom resources specifically for Cray systems.

A job requesting a floating license must specify it outside of a selection statement, as a job-wide resource limit. A job requesting a node-locked license must specify it inside a selection statement in a chunk. See your system administrator.

Custom resources can be created to be invisible or read-only for unprivileged users. See the pbsnodes(8B), pbs_rstat(1B), pbs_rsub(1B), qalter(1B), qselect(1B), qstat(1B), and qmgr(8B) man pages. These restricted resources cannot be requested by a job via the qsub command, regardless of privilege.

🫶 Behavior of Unset Resources

An unset resource is undefined. An unset numerical resource (i.e. float, long, size, or time) at the host level behaves as if its value is zero, but at the server or queue level it behaves as if it were infinite. An unset string or string array resource at the server, queue, or vnode level cannot be matched by a job's resource request. An unset Boolean resource at a server, queue, or vnode behaves as if that resource is set to "false".

---

🌈 Resources Built Into PBS 🌈

⚡ accelerator

Indicates whether this vnode is associated with an accelerator. Used for requesting accelerators. On Cray, this resource exists only when there is at least one associated accelerator.

Behavior:

• True — On Cray, this is set to True when there is at least one associated accelerator whose state is UP.
• False — On Cray, set to False when all associated accelerators are in state DOWN.

Host-level. Can be requested only inside of a select statement. Not consumable. Format: Boolean Python type: bool Default: False

🧠 accelerator_memory

Indicates amount of memory for accelerator(s) associated with this vnode.

On Cray, PBS sets this resource only on vnodes with at least one accelerator with state = UP. For Cray, PBS sets this resource on the 0th NUMA node (the vnode with PBScrayseg=0), and the resource is shared by other vnodes on the compute node.

For example, on vnodeA_2_0:

resources_available.accelerator_memory=4196mb

On vnodeA_2_1:

resources_available.accelerator_memory=@vnodeA_2_0

A scheduler rounds all resources of type size up to the nearest kb.

Host-level. Can be requested only inside of a select statement. Consumable. Format: Size Python type: pbs.size Default: No default

🎛️ accelerator_model

Indicates model of accelerator(s) associated with this vnode. On Cray, PBS sets this resource only on vnodes with at least one accelerator with state = UP.

Host-level. Can be requested only inside of a select statement. Non-consumable. Format: String Python type: str Default: No default

🧚 aoe

List of AOEs (Application Operating Environments) that can be instantiated on this vnode. Case-sensitive. An AOE is the environment that results from provisioning a vnode. Each job can request at most one AOE. Cannot be set on server's host.

Valid values: Allowable values are site-dependent.

Host-level. Can be requested only inside of a select statement. Non-consumable. Type: String_array Python type: str Default: No default

🏛️ arch

System architecture. One architecture can be defined for a vnode. One architecture can be requested per vnode.

Valid values: Allowable values and effect on job placement are site-dependent.

Host-level. Can be requested only inside of a select statement. Non-consumable. Type: String Python type: str Default: No default

⏱️ cput

Amount of CPU time used by the job for all processes on all vnodes. Establishes a job-wide resource limit.

Job-wide. Can be requested only outside of a select statement. Non-consumable. Type: Duration Python type: pbs.duration Default: No default

⚡ energy

The energy used by a job. Set by PBS.

Consumable. Format: Float Units: kWh Default: No default

🔋 eoe

Stands for "Energy Operational Environment". When set on a vnode in resources_available.eoe, contains the list of available power profiles. When set for a job in Resource_List.eoe, can contain at most one power profile. (A job can request only one power profile.)

Non-consumable. Format: String_array Python type: str Default value for resources_available.eoe: unset Default value for Resource_List.eoe: no default

🖥️ exec_vnode

The vnodes that PBS estimates this job will use. Cannot be requested for a job; used for reporting only. Read-only.

Type: String Python type: str Default: No default

📄 file

Size of any single file that may be created by the job. The scheduler rounds all resources of type size up to the nearest kb.

Job-wide. Can be requested only outside of a select statement. Type: Size Python type: pbs.size Default: No default

🚀 hbmem

High-bandwidth memory. Available only on some architectures such as Xeon Phi KNL.

Valid values: Greater than or equal to zero.

Host-level. Format: Size Python type: pbs.size Default: No default

🏠 host

Name of execution host. Cannot be changed. Site-dependent. Can be requested only inside of a select statement.

Behavior:

• Automatically set to the short form of the hostname in the Mom attribute.
• On Cray compute node, set to <mpp_host>_<nid>.

Type: String Python type: str

⏳ max_walltime

Maximum walltime allowed for a shrink-to-fit job. Job's actual walltime is between max_walltime and min_walltime. PBS sets walltime for a shrink-to-fit job. If max_walltime is specified, min_walltime must also be specified. Cannot be used for resources_min or resources_max. Cannot be set on job arrays or reservations.

Valid values: Must be greater than or equal to min_walltime.

Can be requested only outside of a select statement. Non-consumable. Format: Duration Python type: pbs.duration Default: 5 years

🧠 mem

Amount of physical memory i.e. workingset allocated to the job, either job-wide or host-level. The scheduler rounds all resources of type size up to the nearest kb.

Can be requested only inside of a select statement. Consumable. Format: Size Python type: pbs.size Default: No default

⏳ min_walltime

Minimum walltime allowed for a shrink-to-fit job. When min_walltime is specified, job is a shrink-to-fit job. If this attribute is set, PBS sets the job walltime. Job's actual walltime is between max_walltime and min_walltime. Cannot be used for resources_min or resources_max. Cannot be set on job arrays or reservations.

Valid values: Must be less than or equal to max_walltime.

Can be requested only outside of a select statement. Non-consumable. Type: Duration Python type: pbs.duration Default: No default

🧵 mpiprocs

Number of MPI processes for this chunk. Cannot use sum from chunks as job-wide limit.

The number of lines in PBS_NODEFILE is the sum of the values of mpiprocs for all chunks requested by the job. For each chunk with mpiprocs=P, the host name for that chunk is written to the PBS_NODEFILE P times.

Host-level. Can be requested only inside of a select statement. Format: Integer Python type: int Default:

• If ncpus > 0: 1
• Otherwise: 0

🚀 naccelerators

Number of accelerators on the host. PBS sets this resource to the number of accelerators with state = UP.

On Cray, PBS sets this resource only on vnodes whose hosts have at least one accelerator with state = UP. For Cray, PBS sets this resource on the 0th NUMA node (the vnode with PBScrayseg=0), and the resource is shared by other vnodes on the compute node.

For example, on vnodeA_2_0:

resources_available.naccelerators=1

On vnodeA_2_1:

resources_available.naccelerators=@vnodeA_2_0

Host-level. Can be requested only inside of a select statement. Consumable. Format: Integer Python type: int Default: No default

nchunk 🧩

Number of chunks requested between plus symbols in a select statement. For example, if the select statement is

-lselect=4:ncpus=2+12:ncpus=8

the value of nchunk for the first part is 4, and for the second part it is 12. The nchunk resource cannot be named in a select statement; it can only be specified as a number preceding the colon, as in the above example. When the number is omitted, nchunk is 1.

This resource can be used to specify the default number of chunks at the server or queue. Example:

set queue myqueue default_chunk.nchunk=2

This resource cannot be used in server and queue resources_min and resources_max.

• Non-consumable.
• Format: Integer
• Python type: int
• Default value: 1

ncpus 💻

Number of processors. Can be requested only inside of a select statement.

• Consumable.
• Format: Integer
• Python type: int
• Default: No default

nice 😌

Nice value with which the job is to be run. Host-dependent. Can be requested only outside of a select statement.

• Format: Integer
• Python type: int
• Default: No default

nodect 🧮

Deprecated. Number of chunks in resource request from selection directive, or number of nodes requested from node specification. Otherwise defaults to value of 1. Can be requested only outside of a select statement. Read-only.

• Format: Integer
• Python type: int
• Default: 1

nodes 🌐

Deprecated. Number of hosts requested.

• Format: Integer
• See BACKWARD COMPATIBILITY.

ompthreads 🧵

Number of OpenMP threads for this chunk. Cannot use sum from chunks as job-wide limit. For the MPI process with rank 0, the environment variables NCPUS and OMP_NUM_THREADS are set to the value of ompthreads. For other MPI processes, behavior is dependent on MPI implementation. Can be requested only inside of a select statement.

• Non-consumable.
• Format: Integer
• Python type: int
• Default: Value of ncpus

PBScrayhost 🖍️

Used to differentiate a Cray system, containing ALPS, login nodes running PBS MoMs, and compute nodes, from a separate Cray system with a separate ALPS.

• Non-consumable.
• Format: String
• Python type: str
• Default: Value of mpp_host for this system

PBScraylabel_<label name> 🏷️

Tracks labels applied to compute nodes. For each label on a compute node, PBS creates a custom resource whose name is a concatenation of PBScraylabel_ and the name of the label. Name format: PBScraylabel_<label name> For example, if the label name is Blue, the name of this resource is PBScraylabel_Blue.

Behavior:

• PBS sets the value of the resource to True on all vnodes representing the compute node.
• Format: Boolean
• Python type: bool
• Default: No default

PBScraynid 🆔

Tracks the node ID of the associated compute node. All vnodes representing a particular compute node share a value for PBScraynid.

• Non-consumable.
• Format: String
• Python type: str
• Default: Value of node_id for this compute node

PBScrayorder 🔢

Tracks the order in which compute nodes are listed in the Cray inventory. All vnodes associated with a particular compute node share a value for PBScrayorder.

Behavior:

• Vnodes for the first compute node listed are assigned a value of 1 for PBScrayorder.
• The vnodes for each subsequent compute node listed are assigned a value one greater than the previous value.

Do not use this resource in a resource request.

• Non-consumable.
• Format: Integer
• Python type: int
• Default: No default

PBScrayseg 🫥

Not used.

• Format: String
• Default: No default

pcput ⏱️

Amount of CPU time allocated to any single process in the job. Establishes a per-process resource limit. Can be requested only outside of a select statement.

• Non-consumable.
• Format: Duration
• Python type: pbs.duration
• Default: No default

pmem 🧠

Amount of physical memory (workingset) for use by any single process of the job. Establishes a per-process resource limit. The scheduler rounds all resources of type size up to the nearest kb. Can be requested only outside of a select statement.

• Non-consumable.
• Format: Size
• Python type: pbs.size
• Default: No default

preempt_targets 🎯

List of resources and/or queues. Jobs requesting those resources or in those queues are preemption targets. Job-wide. Can be requested only outside of a select statement.

Syntax:

preempt_targets="Queue=<queue name>[,Queue=<queue name>],
Resource_List.<resource>=<value>[,Resource_List.<resource>=<value>]"

or

preempt_targets=None

The keywords queue and none are case-insensitive. You can list multiple comma-separated targets.

• Non-consumable.
• Format: String_array
• Python type: str
• Default: No default

pvmem 🧬

Amount of virtual memory for use by any single process in the job. Establishes a per-process resource limit. The scheduler rounds all resources of type size up to the nearest kb. Can be requested only outside of a select statement.

• Non-consumable.
• Format: Size
• Python type: pbs.size
• Default: No default

site 🏡

Arbitrary string resource. Can be requested only outside of a select statement.

• Non-consumable.
• Format: String
• Python type: str
• Default: No default

software 🛠️

Site-specific software specification. Values: Allowable values and effect on job placement are site-dependent. Can be requested only outside of a select statement.

• Format: String
• Python type: pbs.software
• Default: No default

soft_walltime 🕰️

Soft limit on walltime. Similar to walltime, but cannot be requested by unprivileged users, and job is not killed if it exceeds its soft_walltime. A job's soft_walltime cannot exceed its walltime. Can be set by Manager only.

• Format: Duration
• Python type: pbs.duration
• Default: No default

start_time ⏳

The estimated start time for this job. Cannot be requested for a job; used for reporting only. Appears only in job's estimated attribute. Read-only. Host-level.

• Consumable.
• Format: Integer
• Python type: int
• Default: No default

vmem 🧠✨

Amount of virtual memory for use by all concurrent processes in the job. Establishes a per-chunk resource limit. The scheduler rounds all resources of type size up to the nearest kb. Can be requested only inside of a select statement.

• Consumable.
• Format: Size
• Python type: pbs.size
• Default: No default

vnode 🪐

Name of virtual node (vnode) on which to execute. Site-dependent. See the pbs_node_attributes(7B) man page. Can be requested only inside of a select statement.

• Format: String
• Python type: str
• Default: No default

vntype 🧚

The type of the vnode. Automatically set by PBS to one of two specific values for Cray vnodes. Has no meaning for non-Cray vnodes.

Automatically assigned values for Cray vnodes:

• cray_compute — This vnode represents part of a compute node.
• cray_login — This vnode represents a login node.

Can be requested only inside of a select statement.

• Non-consumable.
• Format: String_array
• Python type: str
• Default: No default

walltime 🕛

Amount of wall-clock time. Establishes a job-wide resource limit. Actual elapsed time may differ from walltime during Daylight Savings transitions. Can be requested only outside of a select statement.

• Non-consumable.
• Format: Duration
• Python type: pbs.duration
• Default: 5 years

🌈 BACKWARD COMPATIBILITY 🌈

okay so bestie, for backward compatibility, a legal node specification or resource specification gets converted into selection and placement directives. That's the whole vibe here 💅✨

🫶 Conversion to Select and Place 🫶

🎀 Node Specification Conversion 🎀

Node specification format:

-lnodes=[<N>:<spec list> | <spec list>]
        [[+<N>:<spec list> | +<spec list>] ...]
        [#<suffix> ...][-lncpus=Z]

where:

• spec list has syntax: <spec>[:<spec> ...]
• spec is any of: <hostname> | <property> | ncpus=X | cpp=X | ppn=P
• suffix is any of: <property> | excl | shared
• N and P are positive integers
• X and Z are non-negative integers

The node specification is converted into selection and placement directives as follows:

• Each spec list is converted into one chunk, so that <N>:<spec list> is converted into N chunks.
• If spec is hostname:
  • The chunk will include host=<hostname>
• If spec matches any vnode's resources_available.host value:
  • The chunk will include host=<hostname>
• If spec is <property>:
  • The chunk will include <property>=true
  • where property must be a site-defined host-level Boolean resource.
• If spec is ncpus=X or cpp=X:
  • The chunk will include ncpus=X
• If no spec is ncpus=X and no spec is cpp=X:
  • The chunk will include ncpus=1
• If spec is ppn=P:
  • The chunk will include mpiprocs=P
  • Example:

-lnodes=4:ppn=2

is converted into

-lselect=4:ncpus=2:mpiprocs=2

• If -lncpus=Z is specified and no spec contains ncpus=X and no spec is ccp=X:
  • Every chunk will include ncpus=W,
  • where W is Z divided by the total number of chunks.
  • (Note: W must be an integer; Z must be evenly divisible by the number of chunks.)
• If property is a suffix:
  • All chunks will include <property>=true
• If excl is a suffix:
  • The placement directive will be -lplace=scatter:excl
• If shared is a suffix:
  • The placement directive will be -lplace=scatter:shared
• If neither excl nor shared is a suffix:
  • The placement directive will be -lplace=scatter

Example:

-l nodes=3:green:ncpus=2:ppn=2+2:red

is converted to:

-l select=3:green=true:ncpus=4:mpiprocs=2+2:red=true:ncpus=1
-l place=scatter

Heads up, bestie: node specification syntax for requesting properties is deprecated. The new Boolean resource syntax "<property>=<value>" is accepted only in a selection directive. It is erroneous to mix old and new syntax. 🫶

🍓 Resource Specification Conversion 🍓

The resource specification is converted to select and place statements after any defaults have been applied.

Resource specification format:

-l<resource>=<value>[:<resource>=<value> ...]

The resource specification is converted to:

select=1[:<resource>=<value> ...]
place=pack

with one instance of <resource>=<value> for each of the following host-level resources in the resource request:

• Built-in resources: ncpus | mem | vmem | arch | host
• Site-defined host-level resources with flags including "h"

---

👑 SEE ALSO 👑

• pbs_node_attributes(7B)
• pbs_rsub(1B)
• qalter(1B)
• qmgr(8B)
• qstat(1B)
• qsub(1B)

mwah 💖 this little archive moment comes from the Local pbs_resources(7B) page, dated 6 May 2020. periodt 🎀✨