Modules

One of the main ways to use software on GLiCID is through Modules. They are a way for us, administrators, to globally install software for the clusters. When you want to use a specific library, software, etc. you have to load the module, which will give you access to the commands and libraries you need.

Modules Cheatsheet

module avail

List the available modules.

module list

List all the currently loaded modules.

module load mymodule/version

Load the named module.

module load mymodule/version variantname=bla +booleanvariant

Load the named module with variants

module unload mymodule/version

Unload the named module

module purge

reset and remove all modules

module show mymodule/version

Show details about the module, including the potential variants that the module has

Checking available modules

The available modules can be shown with the command module avail. This will give you a list of all modules available to you.

Here is an example of the command. This output is not fixed, as we update, add and delete modules.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------- Libraries -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
aocl-blis/4.0          cuda/12.8.0_570.86.10(12)                fftw/mpi/3.3.10_gnu_13.1.0_openmpi        gmp/6.2.1                hdf5/1.14.1-2_gnu_openmpi     intel/dpl/2022.1.0                        intel/tbb/2021.9.0                mfem/4.8                                     netcdf/c-4.9.2_gnu           scalapack/2.2.2_gnu13.1.0_v
blas/3.12.0_gnu        cudnn/9.16.0.29_cuda12                   fftw/mpi/3.3.10_gnu_15.1.0_openmpi_5.0.8  gmsh/4.11.1_gnu          hdf5/1.14.1-2_intel           intel/dpl/2022.10(latest)                 intel/tbb/2022.3(latest)          mfem/4.8-metis5.1.0_cuda12.6.2               netcdf/f-4.6.1_gnu           scilib/0.1/complex
boost/1.82.0_gnu       eigen/3.4.0                              fftw/mpi/3.3.10_intel_2023.1.0_intelmpi   gmt/4.5.15_gnu(4)        hdf5/1.14.1-2_intel_intelmpi  intel/intel_ipp_intel64/2021.8.0          lapack/3.12.1_gcc_13.1.0          mfem/4.8-openmpi4.1.8_metis5.1.0_cuda12.6.2  petsc/3.20.1                 scilib/0.1/real

Loading modules

When you want to use a specific module that you need, use the module load command to make it available.

[pbondial@ec-nantes.fr@nautilus-devel-001 ~]$ mpicc
-bash: mpicc: command not found (1)
[pbondial@ec-nantes.fr@nautilus-devel-001 ~]$ module load intel/mpi/2021.17 (2)
[pbondial@ec-nantes.fr@nautilus-devel-001 ~]$ mpicc
This script invokes an appropriate specialized C MPI compiler driver.
The following ways (priority order) can be used for changing default
compiler name (gcc):
   1. Command line option:  -cc=<compiler_name>
   2. Environment variable: I_MPI_CC (current value '')
   3. Environment variable: MPICH_CC (current value '')
1 Without loading the module, the command is not found
2 Load the module you want to make it available

Advanced module features

To see the legend for the modules, check the bottom of the module avail command :

Key:
(symbolic-version)  modulepath  module-alias  default-version  forbidden

This will give you the colors and syntax for each module

Module aliases

Module aliases are written in green in the module avail output

These modules are just aliases, mainly for compatibility with the older module system. If setting up your environment for the first time, we advise you not to use them, as we will remove them entirely in the future.

Default versions

Default versions of modules are underlined in the module avail output

When loading a module without specifying a version, like this module load intel/compiler, it will choose the default version from this module :

intel/compiler/2023.1.0 intel/compiler/2025.3.2

Here, the version 2025.3.2 will be loaded by default when running module load intel/compiler.

We do not recommend specifying default versions, as this could lead to changes when we change the default version of a module. It is preferred to specify a version when loading modules. Use default versions only for testing.

Symbolic versions

Symbolic versions of modules are written in purple in the module avail output

We create symbolic versions for some of the modules that need it. For example, here you can see that the following module :

gmt/5.3.1_gnu(5:latest)

Have two symbolic versions : version 5 and version latest.

These are labels that you can use when loading the modules. From the example above, the following commands will have the same effect :

module load gmt/5.3.1_gnu
module load gmt/5
module load gmt/latest

These aliases are useful when you might be dependent on a major version of a software, but don’t care about the minor versions of it.

We will frequently update the modules linked to the latest symbolic version, or major software versions. If you need to pin the version you need, use the full module version number instead of symbolic ones.

Forbidden modules

Forbidden modules are written in a red background in the module avail output if you are not allowed to use it, otherwise it wil appear as normal modules

Some modules on GLiCID are restricted to only a subset of users. The forbidden modules are mainly used to restrict access to licenced software (Matlab, Abaqus, etc.).

If you try to load forbidden modules, you will have a message like this :

[pbondial@ec-nantes.fr@nautilus-devel-001 ~]$ module load matlab/2023b-gem
ERROR: Access to module matlab/2023b-gem is denied
  Access is restricted to the 'gem' group

Module variants

Modules variants are, by default, not shown. If you want to see if a module has any variants, use module show mymodule

Module variants are a way for us to keep the available modules clean and readable for everyone. One main use for it could be to have a single module named mymodule/4.0.0 which can be compiled either in sequential, OpenMP or hybrid mode. Before, we had to create 3 separate modules, but this made module avail quickly unreadable. This Is why we use the variant feature of Modules.

Now instead of doing :

module load mymodule/4.0.0_sequential
# or
module load mymodule/4.0.0_openmp
# or
module load mymodule/4.0.0_hybrid

You can specify it like this

module load mymodule/4.0.0 threading=sequential
# or
module load mymodule/4.0.0 threading=openmp
# or
module load mymodule/4.0.0 threading=hybrid

That way, it is cleaner on module avail which shows only mymodule/4.0.0 without any clutter.

You can check if some variants exists for a module by doing :

[pbondial@ec-nantes.fr@nautilus-devel-001 ~]$ module show openmpi/4.1.8-testing
/opt/software/Modules/modulefiles/parallel/openmpi/4.1.8-testing:
variant         --default 1.17.0 ucx 1.17.0
variant         --default 13.1.0 gcc 13.1.0
variant         --default 46.0 rdma 46.0
variant         --default v4 pmix v4 internal

On the example above, you can see that there is variants for ucx, gcc, rdma and pmix, with the possible values. For this example module, you could choose to do something like this :

[pbondial@ec-nantes.fr@nautilus-devel-001 ~]$ module load openmpi/4.1.8-testing ucx=1.17.0 gcc=13.1.0 rdma=46.0 pmix=internal
Loading openmpi/4.1.8-testing{gcc=13.1.0:pmix=internal:rdma=46.0:ucx=1.17.0}
  Loading requirement: gcc/13.1.0 libffi/3.4.6 python/3.11.4 rdma/46.0_gnu ucx/1.17.0_gnu zlib/1.2.8_gnu openmpi/ucx/4.1.8_gcc_13.1.0_ucx_1.17.0_rdma_46.0_internal

Or use the default variant by simply not specifying any variant attribute.

We strongly advise you to use the default variant that we configured if you do not know what a variant mean.
The example above uses text variants, but they can also be boolean, in that case they can be specified with -variantname to disable it, or +variantname to enable it.