Skip to content

Using the Federated Software Catalog

The Federated Software Catalog is currently entirely based on the European Environment for Scientific Software Installations (EESSI).

Using EESSI

Using EESSI comes down to the following two steps:

  1. Initialize your shell environment to start using EESSI
  2. Load one or more modules to activate the software you want to use

Step 1: Initialize your shell environment for using EESSI

Before you can use software installations that are included in the Federated Software Catalog, you first need to initialize EESSI by updating your shell environment.

This involves auto-detecting the CPU/GPU (micro)architecture of the system you are on, so that the best suited subset of software installations provided by EESSI can be selected.

There are two options for initializing EESSI:

Do make sure you have access to EESSI before trying this.

Warning: Loaded modules may be unloaded (click for more information)

Any modules that are loaded when you initialize your shell environment for using EESSI may be unloaded.

If you need to avoid this, see Purging of loaded modules.

Step 1 - Option A: Loading an EESSI module (recommended)

The recommended approach to initiliaze your shell environment for using EESSI is to load an EESSI module.

Check if an EESSI module is available using the following command:

module avail EESSI

If no EESSI module is available, see Option B: Sourcing an init script.

If one or more EESSI modules are available, pick an EESSI version (for example based on which software is available) and load the corresponding module.

For example:

module load EESSI/2025.06

Loading this module will initialize your shell environment so that software installations provided by that EESSI version are ready to (activate and) use.

It may also apply some system-specific changes to your shell environment, beyond what the standard EESSI initialization script does (see below), which is why it is recommended to load an EESSI module if it is available.

To verify that the EESSI module was loaded correctly, run the module list command:

$ module list

Currently Loaded Modules:
  1) EESSI/2025.06

If that worked as expected, you can proceed by loading modules to activate software (see Step 2).

Step 1 - Option B: Sourcing an init script

Warning: Only do this if no EESSI module is available!

If an EESSI module is available for loading, it is highly recommended to use it, since it may apply system-specific changes that improve the experience of using EESSI.

Only use the approach outlined below if that is not the case.

If no EESSI module is available, you can source a script that is provided by EESSI itself to initialize your shell environment for using EESSI.

For example, to initialize for using EESSI version 2025.06 in a bash shell environment:

source /cvmfs/software.eessi.io/versions/2025.06/init/lmod/bash

Note that you should source the script by using the source or . command, as opposed to running it, because it will make changes to your current shell environment.

As a result of sourcing the script, you should see that an EESSI module was loaded. Check the output of the module list command to verify.

If you would like to use a different version of EESSI, or if you are not using bash as a shell (see echo $SHELL), you will need to adjust this command accordingly.

Once any EESSI version has been initialised, you can always load a different version by loading the module for the required EESSI version. For example, if you have initialised for the 2025.06 version of EESSI, you can afterwards use module load EESSI/2023.06 to switch to the 2023.06 version of EESSI.

For more details on this approach, or other ways to initialize your environment for using EESSI, see the EESSI documentation.

Step 2: Load modules to activate software

After initializing your shell environment for using EESSI (see Step 1), you can explore which software is available using the module avail command.

For example, to check which versions of the software named example are available:

module avail example

The output should show that some modules that match your query are provided by EESSI, that is that they are available under /cvmfs/software.eessi.io, for example: 

-------- /cvmfs/software.eessi.io/versions/.../modules/all --------
   example/1.2.3

Note

The exact path for the modules (replaced by ... in the example above) will be different across systems, because the CPU microarchitecture of the system you are using is detected and used when initializing EESSI.

Once you have determined which software installation(s) you want to use, you should load the corresponding module(s) using the module load command.

For example, to activate version 1.2.3 of the software named example:

module load example/1.2.3

Tip: Always load a specific version of a module!

See also the best practices section on this below.

Best practices for using FSC

When using the Federated Software Catalog, we recommend taking into account the following best practices.

Initialize environment in job scripts

Due to the auto-detection of the system CPU and GPU that happens when initializing your shell environment for using EESSI, it is recommended to do the steps outlined above in Using EESSI in your job scripts.

In other words, you should make your job scripts self-contained by including the commands for loading the EESSI module (or sourcing the init script) and loading the software modules.

On some systems it may be possible to first set up your shell environment, and then submit jobs that inherit this environment. We highly discourage relying on this, because the architecture of the system you are using when submitting jobs (for example a login node) may be very different from the system architecture of the compute nodes on which your job will be run (especially on heterogenous systems with different types of partitions).

Load specific module versions

It is highly recommend to always load a specific version of a module.

So, you should not do the following:

# BAD example: loading a module without specifying a version (DO NOT USE)
module load example

While not specifying a version will typically result in loading the most recent version of that software, you should not rely on this.

Which version is activated may change over time as more software installations are added to the Federated Software Stack, so sooner or later you will run into surprises if you do not specify a version.

System-specific best practices

Take into account that there may be additional system-specific best practices for using the Federated Software Stack that you should take into account.

Make sure to check the System-specific best practices subsection of the page in the System-specific details section that corresponds to the EuroHPC system you are using.

Caveats

Some caveats with using the Federated Software Stack that you should be aware of.

Purging of loaded modules

If any modules were loaded when you to initialize your shell environment for using EESSI, they will be automatically unloaded (a.k.a. purged), to avoid interfering with the software installations provided by EESSI.

This may impact some functionality, depending on which system you are using.

To avoid loaded modules being purged when sourcing an EESSI init script, you can set the $EESSI_NO_MODULE_PURGE_ON_INIT environment variable before initializing your shell environment for using EESSI: 

export EESSI_NO_MODULE_PURGE_ON_INIT=1

Note

This has no impact when loading an EESSI module file, it only affect the sourcing of an EESSI init script.

System-specific known limitations

Take into account that there may be additional system-specific known limitations related to using the Federated Software Stack that you should be aware of.

Make sure to check the Known limitations subsection of the page in the System-specific details section that corresponds to the EuroHPC system you are using.

Getting help

If you need help with using the Federated Software Catalog on one of the EuroHPC systems, please contact EFP Helpdesk.