Direct comparison
Slurm vs LSF vs PBS: Scheduler Commands
Translate job scripts between Slurm (sbatch), LSF (bsub), and PBS (qsub): equivalent submit, status, and resource-request flags for moving clusters.
Written and maintained by CASRAI Editorial Board
Last updated
Ask CASRAI · included with Regulatory Radar
Ask about Slurm vs LSF vs PBS: Scheduler Commands
Ask CASRAI answers research-administration questions and cites the passages behind every claim — and says so when the corpus does not cover something, instead of guessing. It comes with a Regulatory Radar subscription at $29 a month, alongside the daily digest of regulatory changes and the dashboard of what changed.
150 questions a day, on this site, over the API, or inside your own tools through the CASRAI MCP server.
Everything CASRAI publishes — this page, the dictionary, the guides and the news — stays free to read, with no account and no card.
How do Slurm, IBM Spectrum LSF, PBS Pro / OpenPBS compare side by side?
The table below compares Slurm, IBM Spectrum LSF, PBS Pro / OpenPBS across 14 procurement-relevant dimensions, from submit a batch script through list available queues.
Side-by-side comparison
| Dimension | Slurm | IBM Spectrum LSF | PBS Pro / OpenPBS |
|---|---|---|---|
| Submit a batch script | sbatch script.sh — returns a job ID immediately, script runs later | bsub < script.sh (redirected) or bsub script.sh | qsub script.sh |
| Start an interactive session | srun --pty bash, or salloc then srun from inside the allocation | bsub -Is bash (pseudo-terminal, shell mode) or bsub -Ip for a pty without shell mode | qsub -I |
| Check job status | squeue -u $USER | bjobs -u $USER | qstat -u $USER |
| Cancel a job | scancel <jobid> | bkill <jobid> | qdel <jobid> |
| In-script directive prefix | #SBATCH | #BSUB | #PBS |
| Request nodes / cores | --nodes=N --ntasks=M (or --ntasks-per-node=M, --cpus-per-task=C) | -n <slots> for total core count; add -R "span[ptile=M]" to fix cores per host | -l select=N:ncpus=M (PBS Pro/OpenPBS syntax — legacy Torque used -l nodes=N:ppn=M instead) |
| Request walltime | --time=HH:MM:SS (also accepts D-HH:MM:SS, MM, or MM:SS) | -W HH:MM (or plain minutes) | -l walltime=HH:MM:SS |
| Request memory | --mem=8G (per node) or --mem-per-cpu=2G | -R "rusage[mem=8000]" to request, -M to set a hard per-process limit — the unit is site-configured (LSF_UNIT_FOR_LIMITS), so confirm it locally rather than assuming MB | -l mem=8gb, usually appended to the same -l select= resource string |
| Request a queue / partition | --partition=<name> (-p) | -q <name> | -q <name> |
| Job name | --job-name=<name> (-J) | -J <name> | -N <name> |
| Standard output file | --output=<file> (-o) — %j expands to the job ID | -o <file> — %J expands to the job ID | -o <file> |
| Job dependency | --dependency=afterok:<jobid> (-d) — also afterany, afternotok, singleton | -w "done(<jobid>)" or -w "ended(<jobid>)" | -W depend=afterok:<jobid> — also afterany, afternotok |
| Job-ID environment variable inside the job | $SLURM_JOB_ID | $LSB_JOBID | $PBS_JOBID |
| List available queues | sinfo | bqueues | qstat -Q |
Common questions
Common questions about Slurm vs IBM Spectrum LSF vs PBS Pro / OpenPBS
Is there a one-to-one flag equivalent for every Slurm option in LSF and PBS?
+
For core resource requests — nodes/cores, walltime, memory, queue, job name, output file, dependency — yes, each has a direct counterpart, which is what the table above maps. Scheduler-specific concepts don't translate as cleanly: Slurm's QOS and association limits, LSF's fairshare and host groups, and PBS's routing queues and node groups are each configured differently at the site level, so a script that relies on one of those needs to be re-thought for the new scheduler, not just re-flagged.
My PBS documentation says -l nodes=4:ppn=8 instead of -l select=4:ncpus=8 — which is right?
+
-l nodes=N:ppn=M is the older Torque/PBS resource syntax; -l select=N:ncpus=M is PBS Professional and OpenPBS. Both are still encountered because many "PBS" clusters actually run one of several forks. Check your site's qsub --version or its own job-script examples before assuming which form your cluster expects — the two are not interchangeable.
How can I tell which scheduler a cluster is running before writing a job script?
+
Try each scheduler's status command on the login node: squeue or sinfo means Slurm, bjobs or bqueues means LSF, qstat -Q means PBS. All three fail cleanly with "command not found" if that scheduler isn't installed, and the cluster's own onboarding documentation or module system almost always states which one it uses.
Can I reuse an sbatch script as-is on an LSF or PBS cluster?
+
No. The #SBATCH directive lines are ignored by LSF and PBS — they read #BSUB and #PBS respectively — so the script body runs, but every resource request in the header is silently dropped, and the job gets whatever the site's default allocation is rather than what you asked for. Translate the directive block using the table above before submitting.
Do memory-request units default the same way across Slurm, LSF, and PBS?
+
No, and this is a common source of jobs being killed for exceeding memory they never actually requested. Slurm's --mem takes an explicit suffix (M/G) and defaults to megabytes if you omit one; PBS's -l mem= also expects an explicit suffix (mb/gb); LSF's -M and -R rusage[mem=] are unitless numbers whose meaning is set by the site's LSF_UNIT_FOR_LIMITS configuration, which is not always MB. Always give an explicit unit where the scheduler accepts one, and check local documentation for LSF.
What does #BSUB or #PBS at the top of a script actually do?
+
The same thing #SBATCH does for Slurm: each scheduler's submission command (bsub, qsub) reads special comment lines at the top of the script matching its own directive prefix and treats them as command-line flags, so #BSUB -q normal is equivalent to passing -q normal on the bsub command line. Directive lines for a different scheduler are just ordinary comments and are silently ignored, not an error.
