skip to primary navigationskip to content

Cambridge Service for Data Driven Discovery

University of Cambridge

Studying at Cambridge


Quick Start


All users should contact CSD3 initially through the login nodes:.

To access the Peta4-Skylake (CPU cluster) nodes:

ssh <username>

To access the Peta4-KNL (KNL cluster) nodes:

ssh <username>

To access the Wilkes2-GPU (GPU cluster) nodes:

ssh <username>

Research Computing Services use CRSids where they exist and so the <username>@ can usually be omitted if your University of Cambridge system does also.

Individual login nodes login-e-1login-e-16 may be explicitly accessed in the same way (the first 8 of these nodes correspond randomly to the name login-gpu; the remaining 8 nodes correspond to login-cpu and login-knl).

All CSD3 nodes run the same O/S (Scientific Linux 7, which is a rebuild of Red Hat Enterprise Linux 7) and have the same access to filesystems. The three clusters differ however in their CPU types, and in the support libraries corresponding to their different interconnects (Mellanox Infiniband in the case of Wilkes2-GPU, and Intel Omni-Path for the others). Therefore it is recommended to develop code on the matching type of login node, and certainly to recompile applications that were previously run on other clusters (such as Darwin).



It is possible to change your initial password using the usual unix command passwd on a login node. University of Cambridge users should note that this will make it different to your UIS Password - see the UIS Password Management Application ( for changing the latter. Note that the security of both users' data and the service itself depends strongly on choosing the password sensibly, which in the age of automated cracking programs unfortunately means the following:

  • Use at least 10 characters
  • Use a mixture of upper and lower case letters, numbers and at least one non-alphanumeric character
  • Do not use dictionary words, common proper nouns or simple rearrangements of these
  • Do not use family names, user identifiers, car registrations, media references, ...
  • Do not re-use a password in use on another system (this is for damage limitation in case of a compromise somewhere).

Passwords should be treated like credit card numbers (and not left around, emailed or shared etc). The above rules are similar to those which apply to systems elsewhere.


Please see here for a brief summary of available filesystems and the rules governing them.


We use the modules environment extensively. A module can for instance be associated with a particular version of Intel compiler, or different MPI libraries etc. Loading a module establishes the environment required to find the related include and library files at compile-time and run-time.

By default the environment is such that the most commonly required modules are already loaded. It is possible to see what modules are loaded by using the command 'module list':

[ps459@login-e-7 ~]$ module list
Currently Loaded Modulefiles:
  1) dot                                7) rhel7/global
  2) slurm                              8) cuda/8.0
  3) java/jdk1.8.0_45                   9) gcc-5.4.0-gcc-4.8.5-fis24gg
  4) turbovnc/2.0.1                    10) openmpi-1.10.7-gcc-5.4.0-jdc7f4f
  5) vgl/2.5.1/64                      11) rhel7/default-gpu
  6) singularity/current

The above shows that SLURM (the job queueing system software), as well as the Intel compilers and the Intel MPI environment are loaded (these are actually loaded as a result of loading the default- module, which is loaded automatically on login).

To permanently change what modules are loaded by default, edit your ~/.bashrc file, e.g. adding

module load cfitsio-3.410-intel-17.0.4-4qrgkot 

will ensure that the next shell (or the current shell if you issue source ~/.bashrc) will also have the Intel compiler-compiled version of cfitsio 3.410 loaded into the environment.

Further commands:

module load <module>         -> load module
module unload <module>       -> unload module
module purge                 -> unload all modules
module list                  -> show currently loaded modules
module avail                 -> show available modules
module whatis                -> show available modules with brief explanation

There are currently a large number of historical modules inherited from older systems that appear in response to "module avail". Please avoid modules with names such as "sandybridge" and "nehalem" in their paths and prefer modules exhibiting the Spack hash (-4qrgkot in the example above).


The default environment should be correctly established automatically via the modules system and the shell initialization scripts. For example, essential system software for compilation, credit and quota management, job execution and scheduling, error-correcting wrappers and MPI recommended settings are all applied in this way. This works by setting the PATH and LD_LIBRARY_PATH environment variables, amongst others, to particular values. Please be careful when editing your ~/.bashrc file, if you wish to do so, as this can wreck the default settings and create many problems if done incorrectly, potentially rendering the account unusable until administrative intervention. In particular, if you wish to modify PATH or LD_LIBRARY_PATH please be sure to preserve the existing settings, e.g. do

export PATH=/your/custom/path/element:$PATH
export LD_LIBRARY_PATH=/your/custom/librarypath/element:$LD_LIBRARY_PATH

and don't simply overwrite the existing values, or you will have problems. If you are trying to add directories relating to centrally-installed software, please note that there is probably a module available which can be loaded to adjust the environment correctly.

Users who are returning to CSD3 after working on Darwin or Wilkes1 should check their ~/.bashrc files and if necessary DELETE any pre-existing lines such as these:

module load default-impi
module load default-wilkes

since these will now interfere with the proper environment settings on CSD3 nodes.


Note that the default-peta4 module, which is loaded by default on the Peta4 clusters, arranges for mpicc, mpif90  etc to be found and to use the Intel compilers automatically when invoked. These wrapper commands supply the correct flags for compiling with Intel MPI (which is currently the default MPI implementation for Peta4 compute nodes).

When compiling code, it is usually possible to remove any direct MPI library references in your Makefile as mpicc & mpif90 will take care of these details. In the Makefile, simply set


etc, or define

export CC=mpicc

etc before compilation.

If some required libraries are missing, please let us know and we can try to install them centrally (as a module).


Please note that the following resource limits apply:

  • On Peta4-Skylake, SL1 and SL2 users are limited to 1280 cores in use at any one time and a maximum wallclock runtime of 36 hours per job. On Peta4-KNL, SL1 and SL2 users are limited to 128 nodes in use at any one time and a maximum wallclock runtime of 36 hours per job. On Wilkes2-GPU, SL1 and SL2 are limited to 64 GPUs in use at any one time and a maximum wallclock runtime of 36 hours per job.
  • SL3 users are similarly limited to 320 cores (Peta4-Skylake), 64 nodes (Peta4-KNL) and 32 GPUs (Wilkes2-GPU), all with up to 12 hours per job.

For more information, please see this full description of service levels (SLs).

Please see the example job submission scripts under /usr/local/Cluster-Docs/SLURM. There are example scripts for launching an MPI application on Peta4 and Wilkes2 via the queueing system:




Copying this example file and then modifying the top section (where indicated) will create a script suitable for submission to the batch queueing system via the command sbatch.

Peta4 and Wilkes2 operate the SLURM batch queueing system for managing resources. Some useful commands:

showq       -> show global cluster information
sinfo       -> show global cluster information
sview       -> show global cluster information
scontrol show job nnnn -> examine the job with jobid nnnn
scontrol show node nodename -> examine the node with name nodename
sbatch      -> submits an executable script to the queueing system
sintr       -> submits an interactive job to the queueing system
srun        -> run a command either as a new job or within an existing job
scancel     -> delete a job
mybalance   -> show current balance of core hour credits

Once your application is compiled, e.g. to a binary called prog, it can be submitted to the queueing system as follows (we assume it is destined for Peta4-Skylake).

Firstly, copy the template SLURM submission script:

cp /usr/local/Cluster-Docs/SLURM/slurm_submit.peta4-skylake slurm_submit

(Note that for convenience newer users may have symbolic links to these template files in their home directories - these are read-only so making a copy is still necessary.) Edit the copy slurm_submit, setting application to "prog" and workdir to the correct working directory. Set options to contain any desired command line options, e.g ">outfile 2>errfile" would redirect stdout and stderr to files which could be monitored while the job runs. Note the comment lines at the head of the script:

#! Which project should be charged:
#! How many whole nodes should be allocated?
#SBATCH --nodes=2
#! How many (MPI) tasks will there be in total? (<= nodes*32)
#SBATCH --ntasks=64
#! How much wallclock time will be required?
#SBATCH --time=02:00:00
#! For 6GB per CPU, set "-p skylake"; for 12GB per CPU, set "-p skylake-himem":
#SBATCH -p skylake

These are comments to bash, but are interpreted by SLURM as requests to use 2 nodes, with 64 tasks in total (which because each Peta4-Skylake node has 32 cores, completely utilizes each node), for 2 hours of wall time (i.e. actual time as measured by a clock on the wall, rather than CPU time). Finally, the following command submits the job to the queueing system:

sbatch slurm_submit

Please note that each Peta4-Skylake node has 32 CPU cores, and one should normally be careful not to start more working processes or threads per node than there are CPUs per node.

Furthermore the Peta4-Skylake nodes come in two sizes - 6GB per CPU (192GB total RAM) and 12GB per CPU (384GB total RAM). These sizes are selected by the #SBATCH -p partition directive, i.e.

 #SBATCH -p skylake

 for 6GB per CPU nodes, and

 #SBATCH -p skylake-himem

for 12GB per CPU nodes. Jobs requesting more than 6GB per CPU may still be submitted to the skylake partition, but may be automatically assigned extra CPUs to cover the additional memory, and will therefore be charged more usage credits. Therefore it is recommended that whenever possible jobs requiring more than 6GB per CPU be submitted to skylake-himem.

The Wilkes2-GPU nodes each contain 4 NVIDIA P100 GPUs. It is possible to request 1, 2, 3, or 4 GPUs for a single node job, but multinode jobs will need to request 4 GPUs per node, which would be done by using the directives

#SBATCH -p pascal
#SBATCH --gres=gpu:4

 (see /usr/local/Cluster-Docs/SLURM/slurm_submit.wilkes2).

The Peta4-KNL nodes are specialised nodes each containing 256 logical CPUs, however only entire nodes are allocated. The memory mode of the KNL nodes allocated can be specified with the #SBATCH -C option. By default cache mode is assumed, but flat mode could be required using the directives

#SBATCH -p knl
#SBATCH -C flat

(see /usr/local/Cluster-Docs/SLURM/slurm_submit.peta4-knl). SLURM may need to reboot nodes if insufficiently many nodes in the desired mode can be found; this may introduce a startup delay of up to 30 minutes.

The job's status in the queue can be monitored with squeue; alternatively use qstat or showq (add -u username to focus on a particular user's jobs).

The job can be deleted with scancel <job_id> or qdel <job_id>.

When the job finishes (in error or correctly) there will normally be one file created in the submission directory with a name of the form slurm-NNNN.out (where NNNN is the job id).


Please check first of all whether there is an answer to your question in the FAQ. If not, please request support.