This documentation provides information for how to use PBS Pro to submit and manage interactive jobs and batch jobs on NCAR systems.
The basic PBS commands are the same on each cluster, but refer to these system-specific pages for details that are unique to each of them, including hardware specifications, software, and job-submission queues and procedures:
PBS Pro is used to schedule both interactive jobs and batch compute jobs. Detailed examples of how to start both types of jobs are included in the documentation (see links above) for each individual system.
Commands for starting interactive jobs are specific to individual systems. The basic command for starting a batch job, however, is the same.
To submit a batch job, use the qsub command followed by the name of your PBS batch script file.
Propagating environment settings
Some users find it useful to set environment variables in their login environment that can be temporarily used for multiple batch jobs without modifying the job script. This practice can be particularly useful during iterative development and debugging work.
PBS has two approaches to propagation:
In general, the first approach is preferred because the second may have unintended consequences.
These settings are controlled by qsub arguments that can be used at the command line or as directives within job scripts. Here are examples of both approaches:
When you use the selective option (lower-case v), you can either specify only the variable name to propagate the current value (as in CASE_NAME in the example), or you can explicitly set it to a given value at submission time (as in DEBUG).
Here are some of the most useful commands for managing and monitoring jobs that have been launched with PBS.
Most of these commands will only modify or query data from jobs that are active on the same system. That is, run each command on Derecho if you want to interact with a job on Derecho.
Run any command followed by -h to get help, as in qhist -h.
Run qdel with the job ID to kill a pending or running job.
Kill all of your own pending or running jobs. (Be sure to use backticks as shown.)
Run qhist for information on finished jobs.
Your output will include jobs that finished on the current day unless you specify the number (N) of days to include.
Your output will be similar to this, with Mem(GB) and CPU(%) indicating approximate total memory usage per job and average CPU usage per core per job:
The following variation will generate a list of jobs that finished with non-zero exit codes to help you identify jobs that failed.
Run this to see the status of all of your own unfinished jobs.
Your output will be similar to what is shown just below. Most column headings are self-explanatory – NDS for nodes, TSK for tasks, and so on.
In the status (S) column, most jobs are either queued (Q) or running (R). Sometimes jobs are held (H), which might mean they are dependent on the completion of another job. If you have a job that is held and is not dependent on another job, CISL recommends killing and resubmitting the job.
Following are examples of qstat with some other commonly used options and arguments.
Get a long-form summary of the status of an unfinished job. (Use this only sparingly; it places a high load on PBS.)
Get a single-line summary of the status of an unfinished or recently completed job (within 72 hours).
Get information about unfinished jobs in a specified execution queue.
See job activity by queue (e.g., pending, running) in terms of numbers of jobs.
Display information for all of your pending, running, and finished jobs.
Query jobs running on one system by specifying the system as shown here. (Only these options are supported when running qstat in this cross-server mode: -x, -u, -w, -n, -s)