Job deployment in Geryon2 is handled by the TORQUE resource manager, which is based on the original PBS. The Maui Cluster scheduler is integrated to TORQUE to improve the manageability and efficiency of the scheduler. Some of the basic commands available are listed in the table below
Job submission can be done in one of two ways: either call qsub from the command line, passing all the necessary flags, or prepare a submission script. A typical BASH script would be like this:
#PBS -S /bin/bash
#PBS -V
#PBS -N XXXnameXXX
#PBS -k eo
#PBS -q XXXqueueXXX
#PBS -l nodes=XXXmpinodesXXX:ppn=XXXmpicoresXXX
#PBS -l walltime=hh:mm:ss
#################################
### Switch to the working directory;
cd $PBS_O_WORKDIR
### Run:
module load openmpi-1.10.4_no-mellanox
mpirun -np XXXnprocessXXX XXXcommandXXX
echo "done"
In the example, replace XXXnprocessXXX with the number of processes to run and XXXcommandXXX with the name of your program. To submit this job, simply type
$> qsub ./example.sh
For more mpirun options, type mpirun --help on a terminal. The meanings of the PBS flags passed in the script are:
We encourage users to look into the documentation of Maui to learn about its functionality and how to take advantage of it.
It is possible to launch an interactive console using qsub -I -l nodes=1:ppn=1 where you can open a new terminal inside the runing job where you can do initial testing of your script or compile. It is not recommended for larger runs or compute something longer than a cople minutes since it grabs the terminal and any interruption/disconnect will kill the job.
Geryon2 makes use of the Environment Modules package. This provides a dynamic modification of a user's environment via modulefiles.
Each modulefile contains the information needed to configure the shell for an application. Once the Modules package is initialized, the environment can be modified on a per-module basis using the module command, which interprets the modulefiles.
Typically modulefiles instruct the module command to set or modify shell environment variables such as PATH, MANPATH, LD_LIBRARY_PATH, INCLUDE_DIR, etc. Modulefiles may be shared by many users on a system, and users may have their own collection to supplement or replace the shared modulefiles.
Modules can be loaded and unloaded dynamically and atomically, in a clean fashion. All popular shells are supported, including bash, ksh, zsh, sh, csh and tcsh, as well as some scripting languages such as Perl and Python.
Modules are useful in managing different versions of applications. Modules can also be bundled into metamodules that will load an entire suite of different
applications.
To check the list of available modules in Geryon2, type
$> module avail
----------------------------- /usr/share/Modules/modulefiles------------------------------------------
atlas fftw3_gnu hdf5-serial openmpi-1.10.4_no-mellanox
devtoolset/devtoolset-9 fftw3_intel intel openmpi-4.1.4_no-mellanox
dot gcc-4.9.2 module-git plplot-5.9.9
fftw2_gnu gsl_gnu module-info python-2.7.6
fftw2_gnu_float gsl_intel modules R-4.2.2
fftw2_intel hdf5-1.10.5-serial null use.own
fftw2_intel_float hdf5-parallel openmpi-1.10.4
-------------------------------- /etc/-----------------------------------------------------------------
Examples:
module load gsl-gnu
module load intel
Modules can also be loaded from the command line. Modules are active for the duration of a session, or until they are explicitly unloaded with the module unload command. For more details check the man pages
for the module command.
For python users who require special libraries or python>3.6.8, we recomend install miniconda in their HOME dir.