Catálogo de software¶

Los nombres de esta tabla son los que escribes en module load, tal cual salen en module avail del clúster (47 aplicaciones, 73 módulos). La versión marcada con (d) es la por defecto de cada aplicación.

Motores, compiladores y bibliotecas¶

Módulo	Versiones exactas
`gcc`	10.5.0 · 11.4.0 · 12.3.0 (d)
`nvhpc`	24.3
`cuda`	11.5 · 11.8 · 12.4 · 12.8 (d)
`cudnn`	8.9.7-cuda11.8
`openmpi`	4.1.6-gcc12 · 4.1.8-gcc12 · 4.1.8-nvhpc24.3 (d)
`openblas`	0.3.28-gcc12
`scalapack`	2.2.0-gcc12-openmpi4
`hdf5`	1.14.5-gcc12-openmpi4
`netcdf`	4.9.2-gcc12-openmpi4
`netcdf-fortran`	4.6.1-gcc12-openmpi4
`netcdf-wrf`	4.9.2-4.6.1-gcc12-openmpi4
`cmake`	4.1.0
`numactl`	2.0.16
`zlib`	1.3.2-gcc12
`libpng`	1.6.43-gcc12
`libxml2`	2.11.7
`jasper`	2.0.33-gcc12
`libxc`	6.2.2-gcc12

Aprendizaje automático, Python y visual¶

Módulo	Versiones exactas
`pytorch`	1.10-hrda · 2.2 (d)
`python`	3.11
`miniconda3`	3
`jupyterlab`	3.11
`huggingface-cli`	0.23.5
`opencv`	4.5.5/cpu · 4.5.5/gpu (d) · 4.9.0/cpu · 4.9.0/gpu (d) · 4.10.0/cpu · 4.10.0/gpu · 4.10.0/gpu-cudnn
`rstudio_singularity`	3.6.2 · 4.2.0 (d) — RStudio Server sobre contenedor

Simulación molecular y ciencia de materiales¶

Módulo	Versiones exactas
`gromacs`	2026.0/cpu · 2026.0/gpu (d)
`lammps`	30Sep2026-gcc12-openmpi4/cpu · 30Sep2026-gcc12-openmpi4/gpu (d)
`quantum-espresso`	7.3-gcc12-openmpi4 · 7.3-nvhpc-cuda-gpu · 7.6-gcc12-openmpi4 · 7.6-nvhpc-cuda-gpu (d)
`siesta`	5.4.2-gcc12-openmpi4 (d) · 5.4.2-gcc12-openmpi4-cuda
`orca`	6.0.1 · 6.1.1 (d)
`vmd`	1.9.4a55 · 2.0.0a8 (d)

Geo-ciencias, clima y ambientes¶

Módulo	Versiones exactas
`wrf`	4.7.1-gcc12-openmpi4
`wps`	4.7.0-gcc12-openmpi4
`qgis`	ltr-3.28 (d) · latest
`gdal`	3.11.5
`geos`	3.12.3
`proj`	9.6.2
`python-gis`	3.11.14

Astrofísica y física¶

Módulo	Versiones exactas
`pluto`	4.4
`gpluto`	4.4
`camb`	1.5.6
`cobaya`	3.3

Bioinformática¶

Módulo	Versiones exactas
`blast`	2.12.0 · 2.15.0 · 2.17.0 (d)
`mmseqs2`	14
`pylychord`	1.2

Utilidades¶

Módulo	Versiones exactas
`awscli`	2
`sqlite`	3.45.3

Versiones comprobadas¶

Al pie del catálogo del portal encontrarás las aplicaciones agrupadas por área. Estas cadenas salieron de ejecutar cada aplicación dentro del clúster (nodo de cómputo, partición cpu), no de la documentación del fabricante:

gcc (GCC) 12.3.0                                   gcc/12.3.0
nvc 24.3-0 64-bit target on x86-64 Linux -tp znver2   nvhpc/24.3   [carga antes cuda/12.4]
Build cuda_12.8.r12.8/compiler.35583870_0          cuda/12.8
mpirun (Open MPI) 4.1.8                            openmpi/4.1.8-gcc12
cmake version 4.1.0                                cmake/4.1.0
h5dump: Version 1.14.5                             hdf5/1.14.5-gcc12-openmpi4
netCDF 4.9.2                                       netcdf/4.9.2-gcc12-openmpi4
GDAL 3.11.5 "Eganville", released 2025/10/29       gdal/3.11.5   [carga antes gcc/12.3.0]
Rel. 9.6.2, June 4th, 2025                         proj/9.6.2
Python 3.11.14                                     python/3.11
2.10.0+cu128                                       pytorch/2.2
:-) GROMACS - gmx, 2026.0 (-:                      gromacs/2026.0/cpu
Large-scale Atomic/Molecular Massively Parallel Simulator - 30 Sep 2026
                                                   lammps/30Sep2026-gcc12-openmpi4/cpu
Program PWSCF v.7.6 starts on 28Oct2026            quantum-espresso/7.6-gcc12-openmpi4
blastn: 2.17.0+                                    blast/2.17.0
R version 4.2.0 (2022-04-22) -- "Vigorous Calisthenics"   rstudio_singularity/4.2.0

(A la derecha, el módulo que hay que cargar para obtener esa cadena; lo que está a la izquierda es literalmente lo que devolvió la aplicación.)

El nombre del módulo y la versión del programa

El nombre del módulo sigue la release del paquete con el que se compiló; la aplicación puede reportar una revisión más nueva al ejecutarla (es el caso de pytorch/2.2, que responde 2.10.0+cu128). Para tu trabajo lo que importa es el nombre del módulo: es estable y es el que va en el script de SLURM. Ante la duda, module load <módulo> y el --version de la aplicación.

Algunos módulos necesitan que cargues antes su dependencia (gdal y nvhpc son los casos que lo requieren hoy). Si uno te da un error de GLIBCXX/version not found, carga primero el compilador base:

module load gcc/12.3.0 gdal/3.11.5 && gdalinfo --version

GDAL 3.11.5 "Eganville", released 2025/10/29

Lo que el nombre del módulo no te dice¶

Estas cinco cosas las probamos una por una dentro del clúster; son las que más confunden cuando uno escribe su script:

Módulo	Lo que reporta al ejecutarlo
`pytorch/2.2`	`2.10.0+cu128`
`sqlite/3.45.3`	`3.51.2 2026-01-09 …`
`huggingface-cli/0.23.5`	`1.13.0`
`cobaya/3.3`	`3.6.2`
`camb/1.5.6`	`1.6.7`
`qgis/ltr-3.28`	`QGIS 3.44.8-Solothurn`

Ninguno está mal: el nombre del módulo es el identificador estable que cargan tus scripts y el número que imprime la aplicación es su revisión real. Para reproducir un análisis, anota el nombre del módulo.

Y tres detalles que ahorran un rato de búsqueda:

No hay comando de versión en openblas, scalapack y wps: son bibliotecas (o, en WPS, ejecutables que solo imprimen su banner al correr). Su versión es la del módulo. camb tampoco tiene CLI: se lee desde Python (python -c "import camb; print(camb.__version__)").
El binario no siempre se llama como el módulo: lammps ejecuta lmp, opencv se comprueba con opencv_version. qgis no es un binario sino una función de shell que levanta un contenedor: se arranca con qgis.
pylychord/1.2 no arranca hoy si cargas el módulo a secas: su entorno necesita numpy de python/3.11. Si lo usas, escribe al NOC y lo dejamos listo en el módulo.

¿Falta algo?

El catálogo crece por solicitud: pide tu aplicación al NOC y, si puede instalarse en esta modalidad, se valida, se compila para este hardware y aparece aquí con su nombre de módulo.