UPF Scientific Computing Core Facility

Scientific Software

Reproducible scientific software environments for Correfoc CPU and GPU architectures.

The SCC provides curated software environments so researchers can load tested applications, compilers, libraries and tools without rebuilding complex dependencies manually.

When possible, software is provided through EESSI. When needed, SCC extends it with EasyBuild recipes, UPF-managed modules or architecture-specific builds.

Common when possible. Specific when needed.

We use a common EESSI software base whenever possible, and add UPF-managed applications or optimized builds when a package, version, license or architecture requires it.

EESSI base layer
↓
EasyBuild managed installations
↓
UPF / Apps local layer
↓
Architecture-specific builds when required

Software stack layers

EESSI logo

EESSI base software layer

EESSI provides a shared, architecture-aware European scientific software stack with compilers, libraries and applications exposed through a consistent module environment.

  • Shared scientific software base.
  • Consistent module environment.
  • Common compilers and libraries.
  • Reproducible environments across compatible systems.
EB

EasyBuild managed installations

EasyBuild is used to automate software builds, dependencies, compiler toolchains and module files, making installations traceable and easier to reproduce.

  • Managed builds.
  • Documented dependencies.
  • Reproducible installation recipes.
  • Easier version management.
UPF

UPF / Apps local layer

UPF / Apps contains locally managed software that cannot be provided directly through EESSI or needs local handling.

  • Licensed applications.
  • Conda environments.
  • Applications not available through EESSI.
  • Project-specific wrappers or modules.
CPU

Architecture-specific builds

Some software must be compiled or adapted for specific CPU or GPU architectures, numerical libraries, CUDA support or partition-specific requirements.

  • CPU-optimized builds.
  • GPU-enabled builds.
  • Architecture-specific dependencies.

What users will see

The user-facing module environment is kept as simple as possible. Users will normally interact with a small set of main software layers, while SCC manages architecture-specific details behind the scenes.

modulepath/EESSI/2023.06 modulepath/EESSI/2025.06 modulepath/UPF/Apps

Additional architecture-specific paths may exist for inspection, migration or administrative purposes, but regular users should normally start from the main EESSI and UPF / Apps layers.

Software availability may vary between partitions during migration or when architecture-specific builds are required.

How software is provided

Software request
↓
Available in EESSI?
yes →
Use EESSI moduleLoad the tested common software layer.
no ↓
EasyBuild possible?
yes →
SCC-managed EasyBuild moduleCreate a reproducible build and module file.
no →
UPF / Apps, Conda, containers or dedicated stackChoose the local path for licenses, special dependencies or architecture-specific needs.

Interactive scientific software

Some scientific software is used through interactive applications rather than batch modules. These tools can be launched from the Visualization Portal, powered by Open OnDemand, and run on SCC resources close to GPFS data.

Learn more about Visualization and Interactive apps service

Interactive applications are useful for development, exploration and visualization. Large production workloads should be moved to Slurm jobs when appropriate.

Request additional software

If a required application, version or environment is not available, SCC can evaluate the best way to provide it.

SCC will check

  • Whether the software is available through EESSI.
  • Whether it can be installed with EasyBuild.
  • Whether it belongs in UPF / Apps.
  • Whether it requires Conda, containers, a license or architecture-specific builds.
  • Whether it is intended for batch jobs or interactive use.

Please provide

  • Software name, version and official URL or documentation.
  • License requirements.
  • Target partition: std-cpu, high-cpu, std-gpu or high-gpu.
  • CPU/GPU requirements and expected users or research group.
  • Whether it is for batch jobs, interactive applications or both.

Software good practices

Load software through modules when possible.

Avoid compiling large software stacks manually in home directories.

Use project spaces for shared environments when needed.

Specify the target partition or architecture when requesting software.

Test software on small workloads before production jobs.

Do not assume a module available on one partition is automatically available on all architectures.

Contact SCC for software with complex dependencies, licenses or GPU requirements.

Need a scientific software environment?

Tell us what software you need, which version, where it should run and whether it is for batch jobs, interactive work or both. The SCC team will evaluate the best installation path.