| The CSF2 has been replaced by the CSF3 - please use that system! This documentation may be out of date. Please read the CSF3 documentation instead. To display this old CSF2 page click here. |
Serial Jobs
Basic serial SGE batch job submission
To run a single-core (serial) job in the batch system you should not specify a Parallel Environment (PE) or a queue (which you may have done on other systems).
- Make sure you have all appropriate modules loaded (see the relevant software page for further information)
- Normally you run jobs from within your scratch area:
cd ~/scratch/my_code/run01 # for example
Example single core job script:
#!/bin/bash #$ -cwd # Job will run in the current directory (where you ran qsub) #$ -V # Inherit current environment (e.g., any loaded modulefiles) # ... important so that commands can be found when jobs run. # Now the commands the job is to run. ./hello.exe
To submit the job to the batch system:
qsub jobscript
Where jobscript is replaced with the name of your submission script
If you receive an error:
bash: qsub: command not found
then to fix this you need to load the batch system modulefile on the login node using:
module load services/gridscheduler
You will then be able to submit jobs, monitor your jobs and so on.
Command-line one-liner…
The above serial job can also be achieved all on the command-line (a quick way of running a serial job in batch)
qsub -b y -V -cwd ./hello.exe optional-args
where optional-args are any command line flags that you want to pass to the hello.exe program (or your own program). This example also assumes your executable is in the current directory.
Intel serial environments
Serial jobs will run on the Intel hardware. 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.
-l short4GB/core, 1 hour runtimeCurrently a pool of 24 Westmere cores.
Serial (1-core) jobs
|
||
| Optional Resources (use only one flag1) | Additional usage guidance | |
|---|---|---|
-l highmem |
8GB/core | Jobs must genuinely need extra memory. Total pool 84 Westmere cores (shared with vhighmem jobs). |
-l vhighmem |
16GB/core | Jobs must genuinely need extra memory. Total pool 42 Westmere cores (shared with highmem jobs). |
-l westmere |
4GB/core | Use only Westmere cores. |
-l sandybridge |
5GB/core | Use only Sandybridge cores. |
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 SGE 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 simply 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.