Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Starting from January 2018 GALILEO has been reconfigured with Intel Xeon E5-2697 v4 (Broadwell) nodes, inherited from MARCONI system. The cluster with this reconfiguration has opened for production in March of the same year.

Starting from August 2019 the a new reconfiguration phase has begun leading led to the a new, upgraded environment, equipped with Intel Omni-Path internal network with and increasing the number of compute nodes available to 1024 Intel Xeon E5-2697 v4 (Broadwell) nodes (at the end of August).


System Architecture

Compute Nodes: There are 352 36-core compute nodes. Each one contains 2 18-cores Intel Xeon E5-2697 v4 (Broadwell) at 2.30 GHz. All the compute nodes have 128 GB of memory. 36 of these compute nodes are equipped with  nVidia K80 GPU and two with nVidia V100.

Login and Service nodes: 8  Login & Viz node are available (5 academic and 3 industrials), equipped with 2 nVidia K40 GPU each. 8  service nodes for I/O and cluster management.

All the nodes are interconnected through a Infiniband network, with OPA v1.5-4, capable of a maximum bandwidth of 100Gbit/s between each pair of nodes.

Accounting

For accounting information please consult our dedicated section.

Budget Linearization policy

On GALILEO a linearization policy for the usage of project budgets has been defined and implemented. For each account, a monthly quota is defined as:

monthTotal = (total_budget / total_no_of_months)

Starting from the first day of each month, the collaborators of any account are allowed to use the quota at full priority. As long as the budget is consumed, the jobs submitted from the account will gradually lose priority, until the monthly budget (monthTotal) is fully consumed. At that moment, their jobs will still be considered for execution, but with a lower priority than the jobs from accounts that still have some monthly quota left.

This policy is similar to those already applied by other important HPC centers in Europe and worldwide. The goal is to improve the response time, giving users the opportunity of using the cpu hours assigned to their project in relation of their actual size (total amount of core-hours).


Disks and Filesystems

The storage organisation conforms to the CINECA infrastructure (see Section "Data storage and Filesystems") . In addition to the home directory ($HOME), for each user is defined a scratch area $CINECA_SCRATCH, a large disk for storing run time data and files. $WORK is defined for each active project on the system, reserved for all the collaborators of the project. This is a safe storage area to keep run time data for the whole life of the project.


Total Dimension (TB)Quota (GB)Notes
$HOME20050
  • permanent/backed up, user specific, local
$CINECA_SCRATCH2.500no quota
  • temporary, user specific, local
  • automatic cleaning procedure of data older than 50 days (time interval can be reduced in case of critical usage ratio of the area. In this case, users will be notified via HPC-News)
$WORK7.1001.000
  • permanent, project specific, local
  • extensions can be considered if needed (mailto: superc@cineca.it)


$DRES points to the shared repository where Data RESources are maintained. This is a data archive area availble only on-request, shared with all CINECA HPC systems and among different projects.

$DRES is not mounted on the compute nodes. This means that you can't access it within a batch job: all data needed during the batch execution has to be moved on $WORK or $CINECA_SCRATCH before the run starts.

Since all the filesystems are based on gpfs (General Parallel FIle System), the usual unix command "quota" is not working. Use the local command "cindata" to query for disk usage and quota ("cindata -h" for help):

  > cindata

Modules environment

As usual, the software modules are collected in different profiles and organized by functional category (compilers, libraries, tools, applications,..).

On GALILEO a new feature has been added to the module environment: the profiles are of two types,  “domain” type (chem, phys, lifesc,..) for the production activity and “programming” type (base and advanced)  for compilation, debugging and profiling activities and that they can be loaded together.

"Base" profile is the default. It is automatically loaded after login and it contains basic modules for the programming activities (intel e gnu compilers, math libraries, profiling and debugging tools,..).

If you want to use a module placed under others profiles, for example an application module, you will have to load preventively the corresponding profile:

>module load profile/<profile name>
>module load autoload <module name>

For listing all profiles you have loaded use the following command:

>module list

In order to detect all profiles, categories and modules available on GALILEO the command “modmap” is available:

>modmap

We allow you to load old-Galileo environment modules.

To switch from new environmengt environment (the default one) to the old and vice-versa, you can load the superc module

>module load autoload superc

and run one of the following commands:


FOR BASH USERS

. $SUPERC_SWITCH/switch_to_old.sh

to switch from new to old environment, or

. $SUPERC_SWITCH/switch_to_new.sh

to switch from old to the new environment.


FOR CSH/TCSH USERS:

source $SUPERC_SWITCH/switch_to_old.csh

to switch from new to old environment, or

source $SUPERC_SWITCH/switch_to_new.csh

to switch from old to the new environment.

...