Serial Jobs
Serial batch job submission
A serial job uses one CPU core. To run a serial job in the batch system you should not specify a partition or a queue (which you may have done on other systems).
We now recommend loading modulefiles within your jobscript so that you have a full record of how the job was run and it also minimises the potential for conflict between different pieces of software and libraries. See the example jobscript below for how to do this.
You should run jobs from within your scratch area:
cd ~/scratch/my_code/run01 # for example
An example single core job script:
#!/bin/bash --login #SBATCH -n 1 # (or --ntasks=1) Use just 1 core # OPTIONAL LINE: the default partition is serial #SBATCH -p serial # (or --partition=serial) # The default output file will be named slurm-JOBID.out # To use SGE-style file names, use the following # #SBATCH -o %x.o%j # %x is job name (default name is the jobscript filename) # #SBATCH -e %x.e%j # If no -e flag used, everything goes in the -o file # Load any required modulefiles module load someapp/1.2.3 # Now the commands to be run by the job theapp.exe
To submit the job to the batch system:
sbatch jobscript
Where jobscript is replaced with the name of your submission script.
Command-line one-liner…
The above serial job can also be achieved all on the command-line on the login node (a quick way of running a serial job in batch). Note that you will need to load any modulefiles before submitting the job. The batch system takes a copy of any settings made by the modulefile so that they are visible to the job when it eventually runs. You could logout of the CSF before the job runs and it will still have a copy of the modulefile settings allowing the job to run correctly.
module load someapp/1.2.3
sbatch -J jobname --wrap="theapp.exe optional-args"
#
# Optional. If not given the job will be named 'wrap' in the squeue listing.
where optional-args are any command line flags that you want to pass to the theapp.exe program (or your own program). The --wrap="..." wraps your commands up as though they were in a jobscript.
Serial Hardware
Serial jobs can run on Intel Cascade Lake compute-nodes. The type of Intel hardware used (amount of memory available to the job, CPU architecture, runtime) can be controlled with extra jobscript flags as shown below. But in general you don’t need to specify any of these flags in your jobscript unless you know your job needs more memory or a specific type of CPU for example.
Serial (1-core) jobs
|
||
| Optional Resources | Node type | Additional usage guidance |
|---|---|---|
| None | ||
Running lots of similar serial jobs
If you wish to run a large number of largely identical jobs: for example, the same program many times with different arguments or parameters; or perhaps process a thousand different input files then please use Job Arrays. These cut down on the amount of job setup you need to do and are much more efficient for the batch system than lots of individual jobs.
Serial Java and Matlab Jobs
Some applications need to be told explicitly to use only a single core otherwise they will try to grab all of the cores available in a compute node.
When you submit a serial jobscript to the queue the batch system will reserve a single core for you (and only run your jobscript when a core becomes available). But you must also ensure your application only uses a single core when it runs.
If you know your code (or application) is serial then you have nothing more to do – it will correctly use one core only. However applications such as Java and MATLAB will try to grab all of the cores in a compute node unless you explicitly tell them to use only one core. You may end up trampling on other users’ jobs that are also running on the same compute node.
Please read carefully any application-specific documentation to check your code will use only a single core if run using a serial jobscript. In particular please read our Java notes and MATLAB notes. Jobs found running on more cores than have been requested in the jobscript will be killed without notice.