Skip to content

Software environment

A rich user software environment is available on MeluXina and can be used through environment modules. It comprises:

  • Tools for HPC, HPDA and AI application development

    • Compilers & interpreters,
    • Common use libraries for math & data,
    • Tools for performance engineering.

  • Scientific computing applications, libraries and frameworks

    • general-purpose HPC, HPDA or AI,
    • or domain-specific.

The MeluXina User Software Environment (MUSE)

The EasyBuild system is used on MeluXina to deploy software stacks. Applications and libraries are provided as modules in one or several versions. Module versions can differ from each others depending on the compiler and/or MPI suite that has been used, and whether the module uses GPU acceleration or not.

The naming scheme used in the MeluXina software stacks follows the application/version schema, e.g. GROMACS/2025.2-foss-2025a-CUDA-12.8.0 which shows that ths GROMACS module is available in version 2025.2 which has been built with the foss/2025a toolchain, and with CUDA 12.8 support.

For a deeper overview on versioning and toolchains see the EasyBuild documentation specific to Common toolchains and available toolchains.

Software stacks

💡 Terminology : A software stack that is also sometimes called stack for short refers to a collection of software packages and their dependencies that are built and configured using a specific EasyBuild toolchain.

We release a new software stack at least once a year. We distinguish two types of stacks on MeluXina:

  • Production ('official' software stack releases, not updated anymore once deployed),
  • Staging (stack released before its Production counterpart, can be updated with some minor changes and with new modules while the release stack is fixed),

The software stacks can be either:

  • Maintained (previous, not updated with new tools/versions),
  • Retired (not maintained anymore and not recommended to be used unless necessary).

The following is a recap of the different stacks available:

MUSE release Based on EasyBuild toolchain(s) Status Path
2025.1 2025a Production, latest, maintained, default from 2026-02-19 /apps/USE/easybuild/release/2025.1/modules/all/
2025.1 2025a Staging, latest, maintained, /apps/USE/easybuild/staging/2025.1/modules/all/
2024.1 2024a Production, maintained /apps/USE/easybuild/release/2024.1/modules/all/
2024.1 2024a Staging, maintained /apps/USE/easybuild/staging/2024.1/modules/all/
2023.1 2023a Production, not maintained /apps/USE/easybuild/release/2023.1/modules/all/
2023.1 2023a Staging, not maintained /apps/USE/easybuild/staging/2023.1/modules/all/
2022.1 2022a Production, not maintained /apps/USE/easybuild/release/2022.1/modules/all/
2022.1 2022a Staging, not maintained /apps/USE/easybuild/staging/2022.1/modules/all/
2021.[1-5] 2021a Production, not maintained /apps/USE/easybuild/release/2021.[1-5]/modules/all
2021.[1,2,5] 2021a Staging, not maintained /apps/USE/easybuild/staging/2021.[1-5]/modules/all

A deeper insight on the different versions of the modules we propose

On this page you will find details about the different HPC applications, libraries and support tools available in the available releases of the MeluXina User Software Environment.

Using different MUSE releases

When you start an interactive job (see here) or when you submit a passive job (with the shebang #!/bin/bash -l on top), different LMOD variables are set that match with the latest/default software stack. If the module you need is not in this software stack but in another stack, you can:

  • Use the dedicated software environment modules in the 'env/' branch, e.g. module load env/staging/2025.1,
  • Or directly configure LMOD to use the appropriate modules path, e.g.:
    module use /apps/USE/easybuild/staging/2025.1/modules/all/

Requesting new software and features

💡 You may request the installation of new applications or features through the servicedesk.lxp.lu. Depending on a project's requirements, new software may be installed in the corresponding project directory or in the global software stack.

Environment modules

The core command by which software modules can be listed, loaded (activated), and unloaded (deactivated) is module, followed by an appropriate command. For more information on module commands, see this page

In case of multiple software versions, one version will always be defined as the default version, and can be identified by its (D) mark in the module avail output. For example, with GROMACS on the 2024 release stack:

$ ml av GROMACS

------------------------------------------------------ /apps/USE/easybuild/release/2025.1/modules/all -------------------------------------------------------
   GROMACS/2025.2-foss-2025a-CUDA-12.8.0    GROMACS/2025.2-foss-2025a (D)

  Where:
   D:  Default Module

This implies that if we just type module load GROMACS, the GROMACS/2025.2-foss-2025a module will be loaded. Fully specifying the software module (name+version) should always be preferred to ensure that the correct version is being activated. In the above case, if we need the CUDA version of the module, one must do:

module load GROMACS/2025.2-foss-2025a-CUDA-12.8.0

NVIDIA GPU Containers (NGC) modules

Our software suite has been enhanced to include Nvidia GPU Containers (NGC). This integration brings a significant upgrade to our capabilities, offering advanced GPU-accelerated applications and tools designed by Nvidia. With NGC, users will have access to a comprehensive catalog of GPU-optimized software for deep learning, machine learning, and high-performance computing (HPC) applications. This addition is part of our commitment to providing the most advanced and efficient tools to our users, ensuring they have access to cutting-edge technology for their computational needs.

Please see here for more on NGC modules.

MPI runtimes

MeluXina User Software Envronment (MUSE) main MPI runtime is the widely used OpenMPI which is capable of handling direct communication with GPU memory, making it CUDA-aware by default. MUSE also offers two more MPI runtimes: ParaStationMPI (which is also CUDA-aware) and IntelMPI.

The OpenMPI runtime automatically load a new standard module, referred to as ompi-configs, designed to configure the system suitably for the majority of users. The MeluXina User Software Envronment (MUSE) provides various versions of these configuration modules tailored to different scenarios. It’s important to note that the available MPI runtimes are highly adaptable, and the modules provided in MUSE represent just a selection of the possible configurations. It may be beneficial to experiment with the different possibilities in order to find the most suitable configuration for your application/run. The different provided configuration modules should give at least acceptable configurations for all users cases. These module configs use UCX and UCC to configure the OpenMPI runtime.

UCX (Unified Communication X) and UCC (Unified Collective Communication) are frameworks designed to enhance the performance and scalability of applications running on HPC and cloud infrastructures. UCX provides an optimized communication layer that facilitates efficient data transfer between devices in a network, supporting a variety of high-speed networking technologies like InfiniBand, RoCE, and more. It's particularly known for its use in facilitating efficient message passing and remote memory access, essential for modern computing applications. On the other hand, UCC focuses specifically on collective communication operations such as broadcasts, reductions and all to all which are common in parallel computing frameworks. UCC works to streamline and optimize these operations across different hardware and network configurations, aiming to improve overall computational efficiency and performance in large-scale environments. Together, UCX and UCC provide a comprehensive suite of tools that address the communication needs of advanced computing systems, supporting a wide range of HPC applications and frameworks.

The following ompi_configs modules are available on MUSE:

  • ompi-configs/ucx: This is the default ompi_configs module for CPU and largemem nodes which is set up to take advantage of UCX as the primary communication library. Additional configuration options are accessible via ompi_info -a.

  • ompi-configs/ucx-cuda: Similar to the ompi-configs/ucx module, this version establish the activation of CUDA transports within the UCX module, thus facilitating CUDA-aware operations. It is provided as the standard ompi_configs module GPU nodes.

  • ompi-configs/ucx-ucc: This configuration mirrors the ompi-configs/ucx module but defaults and prioritizes to using UCC for collective communication.

  • ompi-configs/ucx-cuda-ucc: This configuration mirrors the ompi-configs/ucx-cuda and integrates UCC as the default framwork for collective communication.

In the context of UCX, a transport refers to the underlying communication technology used for data transfer between nodes in a network. UCX supports various types of transports, each designed to optimize communications under different network configurations and hardware. These transports handle the actual movement of data across the network, and they can be tailored for specific types of hardware interfaces and communication protocols, such as InfiniBand, RDMA (Remote Direct Memory Access), shared memory, TCP/IP, and more.

The choice of transport affects performance characteristics such as latency, bandwidth, and scalability. We, therefore, also provides modules for pre-configuring UCX transport selection:

  • ucx-configs/ud exclusively activates the Unreliable Datagram (UD) transport, which is also known for its lower memory usage and suitability for small and medium-sized simulations. Due to problems on MeluXina with RC transport, UD remains the preferred transport for general use, even on large scall simulations.

  • ucx-configs/ud-cuda activates both the Unreliable Datagram (UD) and CUDA transports. UD is known for its smaller memory requirement compared to RC and is preferred for all general GPU simulations.

  • ucx-configs/dc turns on the Dynamically Connected (DC) transport, which is the Nvidia/Mellanox scalable offloaded dynamic connection transport. Although DC is characterized by a low memory footprint, making it potentially suitable for large-scale simulations, it has proved to be a much slower transport than UD for medium and large scale simulations.

  • ucx-configs/dc-cuda includes both the Dynamically Connected (DC) transport and CUDA. It is known for its low memory usage and is potentially suitable for very large GPU simulations.

  • ucx-configs/rc configures the system for the Reliable Connected (RC) transport alone. It has many known issues on our system and we advise not using it for now.

  • ucx-configs/rc-cuda configures the system to utilize both the Reliable Connected (RC) and CUDA transports. Similarly to the above point, we advise not using it for now

  • ucx-configs/plain removes any specific transport restrictions, allowing UCX to freely select the most appropriate transport based on its internal heuristics. This setting is similar to not using any ucx-configs module, giving full control back to UCX’s default decision-making processes.