GPC Quickstart

General Purpose Cluster (GPC)
General Purpose Cluster (GPC)
Installed	June 2009
Operating System	Linux
Interconnect	1/4 on Infiniband, rest on GigE
Ram/Node	16 Gb
Cores/Node	8
Login/Devel Node	gpc01..gpc04 (from login.scinet)
Vendor Compilers	icc (C) ifort (fortran) icpc (C++)
Queue Submission	Moab/Torque

The General Purpose Cluster is an extremely large cluster (ranked 16th in the world at its inception, and fastest in Canada) and is where most simulations are to be done at SciNet. It is an IBM iDataPlex cluster based on Intel's Nehalem architecture (one of the first in the world to make use of the new chips). The GPC consists of 3,780 nodes with a total of 30,240 2.5GHz cores, with 16GB RAM per node (2GB per core). Approximately one quarter of the cluster is interconnected with non-blocking 4x-DDR InfiniBand while the rest of the nodes are connected with gigabit ethernet.

Login

First login via ssh with your scinet account at login.scinet.utoronto.ca, and from there you can proceed to the Development nodes to compile/test your code.

Compile/Devel Nodes

From a scinet login node you can ssh to gpc01..gpc04. These nodes have the same hardware configuration as most of the compute nodes -- 8 Nehalem processing cores with 16GB RAM and Gigabit ethernet. You can compile and test your codes on these nodes. To interactively test on more than 8 processors, or to test your code over an InfiniBand connection, you can submit an interactive job request.

Your home directory is in /home/USER; you have 10GB there that is backed up. This directory cannot be written to by the compute nodes! Thus, to run jobs, you'll use the /scratch/USER directory. Here, there is a large amount of disk space, but it is not backed up. Thus it makes sense to keep your codes in /home, compile there, and then run them in the /scratch directory.

Environment Variables

A modules system is used to handle environment variables associated with different compilers, MPI versions, libraries etc. A list of the installed software is available in Software & Libraries and can be seen on the system by typing

module avail

To load a module

module load intel

To unload a module

module unload intel

To unload all modules

module purge

These commands should go in your .bashrc files and/or in your submission scripts to make sure you are using the correct packages.

Compilers

The intel compilers are icc/icpc/ifort for C/C++/Fortran, and are available with the default module "intel". The latest version of the GNU compiler suite (currently 4.4.0) is available by loading the "gcc" module. To ensure that the intel compilers are in your PATH and their libraries are in your LD_LIBRARY_PATH, use the command

module load intel

This should likely go in your .bashrc file so that it will automatically be loaded.

MPI

SciNet currently provides two sets of MPI libraries for the GPC OpenMPI and MVAPICH2. Both sets of libraries will automatically work with both the infiniband and gigabit ethernet interconnects on the GPC system. We recommend OpenMPI as the default, as it quite reliably demonstrates good performance.

Both sets of libraries are compiled with the gnu compiler suite and the intel compiler suite. To use (for instance) the intel-compiled OpenMPI libraries, which we recommend as the default (and use for most of our examples here), use

module load openmpi intel

in your .bashrc. Other combinations behave similarly.

Both sets of MPI libraries define the wrappers mpicc/mpicxx/mpif90/mpif77 as wrappers around the appropriate compilers, which ensure the appropriate include and library directories and used in the compilation and linking steps.

We currently recommend the Intel + OpenMPI combination. However, if you require the GNU compilers as well as MPI, then the module combination

module load gcc openmpi/1.3.2-gcc-v4.4.0-ofed

will enable development and runtime with gcc/g++/gfortran version 4.4 and OpenMPI version 1.3.2. You can make this your default by putting the module load line in your ~/.bashrc file.

Submitting A Batch Job

The SciNet machines are shared systems, and jobs that are to run on them are submitted to a queue; the scheduler then orders the jobs in order to make the best use of the machine, and has them launched when resources become availble. The intervention of the scheduler can mean that the jobs aren't quite run in a first-in first-out order.

The maximum wallclock time for a job in the queue is 48 hours; computations that will take longer than this must be broken into 48-hour chunks and run as several jobs. The usual way to do this is with checkpoints, writing out the complete state of the computation every so often in such a way that a job can be restarted from this state information and continue on from where it left off. Generating checkpoints is a good idea anyway, as in the unlikely event of a hardware failure during your run, it allows you to restart without having lost much work.

If your job should run in fewer than 48 hours, specify that in your script -- your job will start sooner. (It's easier for the scheduler to fit in a short job than a long job). On the downside, the job will be killed automatically by the queue manager software at the end of the specified wallclock time, so if you guess wrong you might lose some work. So the standard procedure is to estimate how long your job will take and add 10% or so.

You interact with the queuing system through the queue/resource manager, Moab and Torque. To see all the jobs in the queue use

showq

To submit your own job, you must write a script which describes the job and how it is to be run (a sample script follows) and submit it to the queue, using the command

qsub SCRIPT-FILE-NAME

where you will replace SCRIPT-FILE-NAME with the file containing the submission script. This will return a job ID, for example 31415, which is used to identify the jobs. Information about a queued job can be found using

checkjob JOB-ID

and jobs can be canceled with the command

canceljob JOB-ID

Again, these commands have many options, which can be read about on their man pages.

Much more information on the queueing system is available on our queue page.

Batch Submission Script: MPI

A sample submission script is shown below for an mpi job using ethernet with the #PBS directives at the top and the rest being what will be executed on the compute node.

!/bin/bash
MOAB/Torque submission script for SciNet GPC (ethernet)
PBS -l nodes=2:ppn=8,walltime=1:00:00
PBS -N test

DIRECTORY TO RUN - $PBS_O_WORKDIR is directory job was submitted from

cd $PBS_O_WORKDIR

EXECUTION COMMAND; -np = nodes*ppn

mpirun -np 16 -hostfile $PBS_NODEFILE ./a.out </source>

The script above requests two nodes, using 8 processors per node, for a wallclock time of one hour. (The resources required by the job are listed on the #PBS -l line.) Other options can be given in other #PBS lines, such as #PBS -N, which sets the the name of the job. On the first of the two nodes, a shell is launched that changes directory to /scratch/USER/SOMEDIRECTORY and then uses the mpirun command to launch the job. Assumed here is that the user has a line like

module load openmpi intel

in their .bashrc.

Submitting Collections of Serial Jobs

A SciNet-approved method for running collections of serial jobs is outlined in the FAQ.

Batch Submission Script: OpenMP

For running OpenMP jobs, the procedure is similar as for MPI jobs:

!/bin/bash
MOAB/Torque submission script for SciNet GPC (OpenMP)
PBS -l nodes=1:ppn=8,walltime=1:00:00
PBS -N test

DIRECTORY TO RUN - $PBS_O_WORKDIR is directory job was submitted from

cd $PBS_O_WORKDIR

export OMP_NUM_THREADS=8 ./a.out </source>

Note that in some circumstances it can be more efficient to run (say) two jobs each running on four threads than one job running on eight threads. In that case you can use the same `ampersand-and-wait' technique outlined for serial jobs in the FAQ for less-than-eight-core OpenMP jobs.

Submitting an Interactive Job

It is sometimes convenient to run a job interactively; this can be very handy for debugging purposes. In this case, you type a qsub command which submits an interactive job to the queue; when the scheduler selects this job to run, then it starts a shell running on the first node of the job, which connects to your terminal. You can then type any series of commands (for instance, the same commands listed as in the batch submission script above) to run a job interactively.

For example, to start the same sort of job as in the batch submission script above, but interactively, one would type

$ qsub -I -l nodes=2:ppn=8,walltime=1:00:00

This is exactly the #PBS -l line in the batch script above (which requests all 8 processors on each of 2 nodes for one hour), but prepended with a -I for `interactive'. When this job begins, your terminal will now show you as being logged in to one of the compute nodes, and one can type in any shell command, run mpirun, etc. When you exit the shell, the job will end.

Ethernet vs. Infiniband

About 1/4 of the GPC (862 nodes or 6896 cores) is connected with a high bandwidth low-latency fabric called InfiniBand. Many jobs which require tight coupling to scale well greatly benefit from this interconnect; other types of jobs, which have relatively modest communications, do not require this and run fine on Gigabit ethernet.

Jobs which require the InfiniBand for good performance can request the nodes that have the `ib' feature in the #PBS -l line,

#PBS -l nodes=2:ib:ppn=8,walltime=1:00:00

Because there are a limited number of these nodes, your job will run faster if you do not request them (e.g. if you use the scripts as shown above), as this increases the number of nodes available to run your job. In fact, the InfiniBand nodes are to be used only for jobs that are known to scale well and will benefit from this type of interconnect. The MPI libraries provided by SciNet automatically correctly use either the InfiniBand or ethernet interconnect depending on which nodes your job runs on.

Large Memory Nodes

There are two stand-alone large memory (128GB) nodes, gpc-lrgmem01 and gpc-lrgmem02 which can be used for data analysis of runs. They have 8 cores and are intel machines running linux, but they are not the same architecture (Nehalem) as the GPC compute nodes, so codes will have to be compiled separately for these machines. They can be logged into from login.scinet.utoronto.ca.

Managing jobs on the Queuing system

Information on checking available resources, starting, viewing, managing and canceling jobs on Moab/Torque