> MesoPSL/ lmod

Lmod

Présentation

Lmod est un outil de gestion de modules développé au TACC. Les modules sont gérés de facon hiérarchique et divisés en trois catégories :

  • les modules qui ne dépendent de rien
  • les modules qui dépendent d'un compilateur
  • les modules qui dépendent d'un compilateur et d'une version de MPI

Lorsque aucun module n'est chargé, la commande
module list
donne la liste des modules qui ne dépendent de rien.

Si vous chargez un module de compilateur, la même commande
module list
ajoute l'ensemble des modules qui dépendent de ce compilateur.

Si vous chargez un module MPI en plus d'un module de compilateur, alors
module list
propose également tous les modules qui dépendent de ce MPI spécifique.

Les modules s'utilisent de la même manière qu'avec l'outil environment module qui était installé auparavant sur MesoPSL, avec un seul ajout notable (spider).
Pour rappel, voici les différents mots clés :

  • load (ou add) M : charge la version par défaut du module M ;
  • load (ou add) M/V : charge la version V du module M ;
  • unload (ou del) M : décharge le module M ;
  • purge : décharge tous les modules ;
  • swap (ou sw) M1 M2 : décharge le module M1 et charge le module M2 ;
  • list (ou li) : donne la liste des modules chargés ;
  • avail (ou av) : donne la liste des modules disponibles selon les dépendances déjà chargées ;
  • spider : donne la liste de tous les modules disponibles indépendamment des dépendances ;
  • spider M : donne toutes les versions disponibles du module V ;
  • spider M/V : donne des informations sur la version V du module M, dont toutes les dépendances nécessaires pour pouvoir le charger ;
  • whatis M : donne des informations plus détaillées sur la version par défaut du module M ;
  • whatis M/V : donne des informations plus détaillées sur la version V du module M.

Modules disponibles sur MesoPSL

  • STAR: STAR/2.7.5a
  • abinit: abinit/8.10.2
  • boost: boost/1.72.0
  • cfitsio: cfitsio/3.47.0
  • cmake: cmake/3.16.3
  • fftw: fftw/3.3.8
  • gcc: gcc/6.3.0, gcc/7.3.0, gcc/8.3.0, gcc/9.2.0
  • git: git/2.23.0
  • gsl: gsl/2.6
  • gyoto: gyoto/1.4.4
  • hdf5: hdf5/1.8.21, hdf5/1.10.5
  • intel: intel/18.0.1, intel/19.0.0, intel/19.1.0
  • intelmpi: intelmpi/18.0.1, intelmpi/19.0.0, intelmpi/19.1.0
  • julia: julia/1.2.0, julia/1.5.3
  • lapack: lapack/3.8.0
  • lorene: lorene/1.0.0
  • mkl: mkl/19.0.0
  • molpro: molpro/2015.1.41
  • openmpi: openmpi/3.0.0, openmpi/4.0.1, openmpi/4.0.2
  • pgplot: pgplot/5.2.0
  • python: python/2.7.16, python/3.6.8, python/3.7.3
  • samtools: samtools/1.10
  • udunits: udunits/2.2.26
  • yorick: yorick/2.2.04

Gestion d'une collection de modules

  • save (ou s) : sauve la liste de modules chargés comme la collection par défaut de l'utilisateur ;
  • save (ou s) NOM : sauve la liste de modules chargés sous le nom de collection NOM ;
  • reset : charge les modules par défaut du système s'il y en a ;
  • restore (ou r) : charge les modules par défaut de l'utilisateur s'il a créé sa liste par défaut, du système sinon ;
  • restore (ou r) NOM : charge la collection NOM ;
  • restore system : charge les modules par défaut du système ;
  • savelist : liste des collections sauvegardées.

Modules et slurm

Lorsque vous soumettez un job avec slurm, les variables d'environnement sont transmises aux noeuds attribués à votre job.
Si vous avez besoin d'utiliser un module dans un job, vous avez donc deux possibilités :

  • charger le module dans votre shell avant de soumettre votre job ;
  • charger le module dans votre script slurm.

Conflits entre modules

Les modules "gcc" et "intel" ne sont pas compatibles entre eux.
Vous ne pourrez donc a priori pas utiliser en même temps un compilateur intel et un compilateur gcc autre que la version par défaut de gcc (4.8.5).

Liens

  • Documentation officielle : https://lmod.readthedocs.io/en/latest/
  • Github : https://github.com/TACC/Lmod
  • Page sur le site du TACC : https://www.tacc.utexas.edu/research-development/tacc-projects/lmod