skip to primary navigationskip to content

Cambridge Service for Data Driven Discovery

University of Cambridge

Studying at Cambridge


Using email on the HPCS systems email addresses do not provide new points for the delivery of email, and user email messages are not delivered to any part of Peta4 / Wilkes2 itself. However, email messages can be sent manually from the login nodes (e.g. as a result of a user using the mail command), or automatically by the queueing system to a user if job notification messages have been requested.

Example - manual mail from a login node

A Cambridge user xyz123 on a login node wishes to send a quick email to another HPC user (assumed also to be a member of the University), pqr456:

[login-e-3 /home/xyz123]$ mail pqr456

or to someone else not necessarily connected with the HPC:

[login-e-3 /home/xyz123]$ mail someone'at'

In the first case, not specifying a non-local part of the recipient address leads to a default of To: pqr456'at' In both cases, the message generated appears to be From: xyz123'at'; replies or error messages will be returned to xyz123'at' and delivered to the home email address provided to us by the user (not to Peta4 / Wilkes2).

Please note that email involving Peta4  / Wilkes2 accounts not associated with a current member of the University of Cambridge may work differently.

Example - automatic mail from a batch job

Automatic email notification for a job submitted to SLURM is set via a directive in the submission script such as:

#SBATCH --mail-type=ALL

or equivalently on the command line, as in

sbatch --mail-type=ALL ...other options... filename

where ALL can be replaced by one of BEGIN, END, FAIL, REQUEUE to restrict the types of messages sent (see the sbatch documentation). This option can also be given multiple times.

If the job owner is pqr456, these messages will be sent To: pqr456'at' and From: root'at' (except in the case of external users). In fact they are generated by the SLURM server node; the original message, as well as any replies and errors (neither of which should normally occur), are ultimately received by the University's managed mail domain machinery and forwarded appropriately.