Cluster OS update to Rocky Linux 9
Temporary site with ongoing changes!
Advice for your own compiled software:
- If you previously compiled software with very specific dependencies on system libraries, you may need to recompile this software
In the majority of cases, the upgrade to RL9 should not break existing applications due to backwards-compatibility. There might still be problems for dependencies from the Rocky software repositories have been upgraded to newer versions that are incompatible with earlier releases.
Even though it may not be necessary in many cases, you can recompile your software to avoid any kind of unexpected behavior. Especially for Python packages installed via pip or conda.
Changes in the Module System
We are also updated the default modules and toolchains available through the module commands. We consolidated a lot of software packages that were previously scattered among multiple compiler and MPI versions. As you could have been aware, certain modules can depend on other compiler and MPI modules that need to be previously loaded. For example, we provide certain software packages only for GCC and OpenMPI while others are solely available based on the Intel compilers and IntelMPI. With the new updated defaults we have tried to migrate existing software to the new default versions wherever possible. This should allow you to use more parts of our software stack with less issues and less compiler switching. However, this also requires some effort in cases where we have updated the default version of a module or built a previous version using the new default toolchains. We have also removed software packages that were either incompatible with Rocky Linux 9 or, according to our usage statistics, have not been used in the recent past.
This page is designed to give you an overview on the changes that come with our migration to Rocky Linux 9 (RL9) as well as the updates in the module system that we introduce along with this migration. You may find more exhaustive information on specific topics on the respective pages here on IT Center Help.
For context: We provide users with pre-installed software using the module system and module commands.
Operating System Upgrade
We are upgrading from Rocky Linux 8 (RL8) to Rocky Linux 9 (RL9). The new version comes with updated system software and better support for newer hardware. This has two relevant implications for your individual software:
- Rocky 9 supports more software that comes prebuilt such as AppImages due to its newer GLIBC version
- If you previously compiled software with very specific dependencies on system libraries, you may need to recompile it
In the majority of cases, the upgrade to Rocky 9 will not break existing applications since the new major version is mostly backwards-compatible. Problems arise where packages from the Rocky software repositories have been upgraded to newer versions that are incompatible with earlier releases.
Changes in the Module System
We are also updated the default modules and toolchains available through the module commands. We consolidated a lot of software packages that were previously scattered among multiple compiler and MPI versions.
For context: Previously certain modules depended on other compiler and MPI modules that need to be previously loaded as a dependency. Certain software packages required GCC and OpenMPI while others required Intel Compiler and IntelMPI pre-loaded.
With the new updated defaults we have tried to migrate existing software to new default versions wherever possible. This should allow you to use more software modules with less compiler / dependency switching. However, this might mean that certain modules are now using different dependencies, which might for you to recompile your own software. We have also removed software modules that were either incompatible with Rocky Linux 9 or, according to our usage statistics, have not been used in the recent past. Please check if your software or dependency requirements are still satisfied under the new module system.
The following table shows you the default compiler and MPI changes with RL9:
Name | Previous Default | New Default |
---|---|---|
Compilers | ||
GCC | 11.3.0 | 13.3.0 |
intel-compilers | 2022.1.0 | 2024.2.0 |
MPIs | ||
OpenMPI | 4.1.4 | 5.0.3 |
impi (IntelMPI) | 2021.6.0 | 2021.13.0 |
Math Libraries | ||
imkl (IntelMKL) | 2022.1.0 | 2024.2.0 |
OpenBLAS | 0.3.20 | 0.3.27 |
Other |
| |
CUDA | 12.3.0 | 12.6.3 |
Toolchains |
| |
intel | 2022a | 2024a |
foss | 2022a | 2024a |
gompi | 2022a | 2024a |
iimpi | 2022a | 2024a |
This is a first step towards the stage-based software lifecycle that we are planning for the future. You may know such software stages from other HPC centers such as JSC.
The previous default versions are still available but are no longer the defaults. They will be maintained until further notice. We do encourage you to rebuild your software packages with the newer toolchains where feasible and to use them for new software builds.
Potentially Software Breaking Changes
- GCCcore no longer hidden
- The GCCcore is the base for both the intel-compilers and the GCC toolchain modules. It is also required as a prerequisite module to load several modules such as Python. When we first introduced our hierarchical module system, we flagged this module as hidden in an attempt to make the hierarchy less confusing for users who did not understand the difference between GCC and GCCcore. We learnt, however, that this only made things worse because users would often directly load the hidden versions due to the information they got from the
module spider
command. Having to load hidden modules makes using the module system more clunky which led us to this change (GCCcore no longer being hidden). We will still keep the old hidden versions as compatibility links so that your pre-existing batch scripts and module collection do not crash, but we strongly recommend that you migrate to the new modules proactively (Note the missing leading dot .). - Example:
module load GCCcore/.13.3.0
becomesmodule load GCCcore/13.3.0
- Example:
ml GCCcore/.13.3.0
becomesml GCCcore/13.3.0
- The GCCcore is the base for both the intel-compilers and the GCC toolchain modules. It is also required as a prerequisite module to load several modules such as Python. When we first introduced our hierarchical module system, we flagged this module as hidden in an attempt to make the hierarchy less confusing for users who did not understand the difference between GCC and GCCcore. We learnt, however, that this only made things worse because users would often directly load the hidden versions due to the information they got from the
- Intel oneAPI-Compilers are used by default for C/C++ (intel >= 2023b)
- The classic Intel Compilers (icc, icpc, ifort) have been deprecated by Intel and replaced by the so-called oneAPI compilers (icx, icpx, ifx). Our new default modules use the new C/C++ oneAPI compilers by default which are not backwards-compatible with their classic counterparts. If you have written makefiles that make use of intel-specific compiler options, please take a look at the porting guides for the C++ compiler and the Fortran compiler.
- Intel still includes the old compilers up to version intel/2023b, but they are completely removed from version intel/2024a. The default Fortran compiler remains ifort for all versions.
- These changes also apply to the MPI compiler wrappers.
- User collections (module save/restore) created under the previous RL 8 do not work for RL9
Any user collections that are created with module save on a Rocky Linux 8 system are not loadable on a Rocky Linux 9 system. They need to be recreated on a Rocky 9 system!
Other Notable Changes
- Available module overview
- We have made significant changes to which software modules are in the
avail
overview and removed many modules that are only installed as dependencies of other modules that we maintain actively. This should give you a more helpful overview of the different software packages we provide on the cluster. The change does not affect the way modules are loaded. All modules can still be found using thespider
command.
- We have made significant changes to which software modules are in the