Named after the mountain of the Bernese Alps, Eiger is the production partition on Alps, the HPE Cray EX Supercomputer, which is accessible via SSH as eiger.cscs.ch
from the frontend ela.cscs.ch
.
Known issues
You might get occasionally a "Bus error" in the logs of your simulations: unfortunately it is a bug affecting Eiger that has been reported to HPE/Cray support and will be fixed in the next update of Eiger starting March 18th
Latest news
You can read the Latest news on Eiger, that include the announcements about planned interventions on the system. The list of past and on-going interventions is available in the page about Past interventions.
Architecture
Compute Nodes (CN) feature two sockets with one AMD EPYCTM 7742 64-Core processor per socket, that interface with the high-speed HPE Slingshot interconnect: please check the system specifics of the HPE Cray EX Supercomputer. More detailed information on the supercomputer cabinets and the HPE Slingshot interconnect is available in the HPE Cray EX Liquid-Cooled Cabinet for Large-Scale Systems brochure.
Optimal CPU affinity settings require an understanding of the architectural features of the AMD EPYCTM 7742 processor: please refer to the technical description of the processor for further details.
Please find additional details on the Compute node configuration and the CPU configuration following the links to the dedicated pages.
File systems
The user space on the scratch file system can be reached using the environment variable $SCRATCH
that points to the user's personal folder /capstor/scratch/cscs/$USER
.
The scratch file system is connected to the compute nodes of the system. File systems access type (read, write, None) from compute (CN) and user access nodes (UAN) is summarized in the table below:
scratch | /users | /project | /store | |
---|---|---|---|---|
CN | r+w | r+w | r | r |
UAN | r+w | r+w | r+w | r+w |
Please read carefully the general information on file systems at CSCS, especially with respect to the soft quota and the cleaning policy enforced on scratch.
Cray Programming Environment (CPE)
User Access Nodes (UAN) are the login nodes of the system and feature the Cray Programming Environment (CPE). The CPE provides tools for applications development and code performance analysis, including compilers, analyzers, optimized libraries, and debuggers. The CPE implementation on the system is controlled using the environment modules system Lmod, written in the Lua programming language, which provides a hierarchical mechanism to access compilers, tools and applications. Please find out more in the page Lmod with the CPE.
No modules are loaded by default at login: users need to load the module cray
first, then they will be able to load the modules available in the default Cray programming environment. Therefore users are invited to add the command module load cray
to their scripts and workflows.
Cray meta-modules
CPE modulefiles are organized into meta-modules, each one supporting a different compiler suite, that can be loaded as usual with the command module load
. The CPE on the system comes with the definition of the meta-modules PrgEnv-aocc
, PrgEnv-cray
, PrgEnv-gnu
and PrgEnv-intel
.
Depending on the chosen CPE meta-module, the environment variable PE_ENV
will be defined (with value AOCC
, CRAY
, GNU
or INTEL
respectively), loading the module craype
with the compiler wrappers (cc
for C code, CC
for C++ code and ftn
for Fortran code), the compiler (aocc
, cce
, gcc
or intel
according to the selected environment), the MPI library (cray-mpich
) and the scientific library (cray-libsci
).
The wrappers call the correct compiler with appropriate options to build and link applications with relevant libraries, as required by the loaded modules (only dynamic linking is supported) and therefore should replace direct calls to compiler drivers in Makefiles and build scripts.
Supported applications and libraries
Supported applications and libraries are built using the EasyBuild toolchains cpeAMD
, cpeCray,
cpeGNU
and cpeIntel,
which load compilers and libraries of the modules PrgEnv-aocc
, PrgEnv-cray,
PrgEnv-gnu
and PrgEnv-intel
respectively: please have a look at Building software with EasyBuild for more details. After loading a toolchain module, you will be able to list with module avail
and load with module load
additional applications and libraries built with the currently loaded toolchain. The available CPE toolchains can be listed using the following command:
module avail cpe
You can list all the modules on the system by typing the command module spider
. Add an argument to the module spider
command to get the instructions to load a specific module. When multiple versions are available, you have to provide the module full name as argument to the module spider
command, in order to see how to load it, as in the example below:
As explained in the section Module hierarchy, the search is case insensitive: however, you need to type the correct case when loading the module.
Please note that the toolchains follow the naming convention of the Cray Programming Environment, that is released on a monthly basis: as a consequence, the version of the toolchain modules has the format YY.MM
(two digits for the year, two digits for the month). If you don't specify the version in your module
command, the default will be selected by Lmod; when no default is set, Lmod will load the latest one:
The compilers available on the system support different implementations of the OpenMP API. Please check the _OPENMP
macro for each compiler version, which helps mapping it with the supported OpenMP API. For instance, the clang-cpp
pre-processor of the aocc
and cce
available loading the default modules will return 201811
(Nov 2018) using the command below:
$ echo | clang-cpp -fopenmp -dM | grep _OPENMP #define _OPENMP 201811
You can retrieve the complete list of modules available on the system with the command module spider
, as described above. Software commonly used on the system is listed below:
Running Jobs
Parallel programs compiled with the Cray MPI library cray-mpich
must be run on the compute nodes using the Slurm srun
command: running applications on the login nodes is not allowed, as they are a shared resource.
Slurm batch scripts should be submitted with the Slurm sbatch
command from the user's $SCRATCH
folder: for performance reasons users should NOT run jobs from other filesystems.
A template Slurm job submission script to run a simulation with 16 MPI tasks per node and 8 OpenMP threads per task on 6 nodes is provided below: please replace <executable>
with the name of the real executable file.
The srun
option --cpu-bind
binds MPI tasks to CPUs: in the template above, the keyword cores
will bind tasks to cores (note that if the number of tasks differs from the number of allocated cores, this can result in sub-optimal binding). We have also enabled the verbose mode with the keyword verbose
, that will report in the Slurm output the selected CPU binding for all commands executed in the script. You can also set the SLURM_CPU_BIND
environment variable value to verbose
to select verbose output. Please use alternatively the srun
option --hint=nomultithread
to avoid extra threads with in-core multi-threading, a configuration that can benefit communication intensive applications: in this case, please remove --cpu-bind
, see man srun
for details. Please note as well:
- the default
OMP_STACKSIZE
is small for the GNU compiler, therefore you may get a segmentation fault with multithreaded simulations: in this case, try to increase it as in the template above. The actual value ofOMP_STACKSIZE
at runtime will be limited by the free memory on the node, therefore you might get an error likelibgomp: Thread creation failed: Resource temporarily unavailable
if you request more memory than currently available - some applications might fail at runtime reporting an error related to
FI_CXI_RX_MATCH_MODE
. In this case, please addexport FI_CXI_RX_MATCH_MODE=hybrid
as in the template above orexport FI_CXI_RX_MATCH_MODE=software
in your Slurm batch script. Other environment variables might be fine tuned, for instanceFI_CXI_RDZV_THRESHOLD
,FI_CXI_REQ_BUF_SIZE
,FI_CXI_REQ_BUF_MIN_POSTED and
FI_CXI_REQ_BUF_MAX_CACHED
Please be reminded to include the active project that you would like this job to be charged for allocation. This can be done with the Slurm option #SBATCH --account=<project>
in the submission script or as a flag with the srun
command, i.e. --account=<project>
or -A <project>
, where the string <project>
is the ID of the active project. You also need to specify the Slurm constraint #SBATCH --
constraint=mc
in the batch script or as a srun
option ( --
constraint=mc
or -C mc
).
The list of queues and partitions is available typing sinfo
or scontrol show partition
. Note that not all projects are enabled on every partition, please check the AllowGroups
entry of the command scontrol show partition
.
sinfo -l
provides a summary of the Slurm batch queues that is easy to visualize. Please check the other options of the command with sinfo --help
.You can choose the queue where to run your job by issuing the Slurm directive --partition
in your batch script as follows: #SBATCH --partition=<partition_name>
. The list of Slurm queues available on the system is presented in the table below:
Name | Wall time | Max nodes per job | Max jobs per user | Brief description |
---|---|---|---|---|
debug | 30 minutes | 10 | 1 | Quick turnaround for tests |
normal | 24 hours | Standard production jobs | ||
prepost | 30 minutes | 1 | High priority pre- and post-processing | |
low | 24 hours | Low priority queue |
Allocating large memory nodes
Slurm supports the --mem
option to specify the real memory required per node. For applications requiring more than 256 GB of memory per node, users should add the Slurm directive #SBATCH --mem=497G
in their jobscript. See the sbatch
man page for more details.
Container solutions
Available Tools | Functionalities (highlights) |
---|---|
Buildah |
|
Sarus |
|
Singularity |
|
Please click on the name of the tool to access the dedicated pages available in the CSCS Knowledge Base.
Debugging and Performance analysis tools
The HPE/Cray EX Programming Environment provides a set of debugging and performance analysis tools to analyse the behaviour and performance of programs running on the system:
cpe | atp | cray- ccdb | cray- stat | gdb 4hpc | valgrind 4hpc | papi | perftools | |
---|---|---|---|---|---|---|---|---|
22.05 | 3.14.11 | 4.12.11 | 4.11.10 | 4.14.0 | 2.12.8 | 6.0.0.14 | 22.05 |
In addition to the tools provided by HPE/Cray, we also support other debuggers and performance analysis tools:
As explained above in the section Module hierarchy, there are two ways to find the list of installed tools:
Use the command
module spider
as shown in the examples belowInstalled tools can be listed by using the
module spider
command with the module name:A more detailed description of a module can be printed by the command
module spider
using as argument the full module name with a version number:Use the command
module avail
only after a specific toolchain module (cpeAMD
,cpeCray
,cpeGNU
,cpeIntel
) has been loaded
Interactive Computing with JupyterLab
JupyterLab is available on the system and can be ued as described in the dedicated page on JupyterLab in the CSCS Knowledge Base. For further information on creating Jupyter kernels from virtual environments or if you run into any issues using any of our tools, please contact us as described below.
Contact us
Please have a look at the article How to submit a support request on the CSCS Knowledge Base: after logging in with your credentials, you can select a request type that best matches your question, that will be directed to the team in charge and will help us react faster.
Please make sure to include all relevant information to help us address your request: kindly note that the request summary, description and project are mandatory fields for all request types, while the system is mandatory for some request types only.