> DIO/ Calcul/ Grappe de calcul interne

Description générale

Présentation du service

La DIO met à la disposition des utilisateurs une grappe de calcul et de traitement de données : tycho.

L'accès à cette machine est ouvert à  tous les membres de l'Observatoire néanmoins il est nécessaire d'en faire la demande. Pour cela envoyez un mail à 

admin.dio@obspm.fr

Nous invitons tous les utilisateurs à lire les paragraphes ci-dessous et à suivre ces recommandations. Pour une utilisation optimale des moyens de calcul, les utilisateurs doivent soumettre leurs jobs via le système de gestionnaire de tâches SLURM (Simple Linux Utility for Resource Management).

Les utilisateurs doivent s'inscrire à la liste de diffusion mpopm (machine parallèle de l'observatoire de Paris-Meudon) pour être informé des arrêts programmés de la grappe (mise à jour système, coupure électrique...) et des mises à jour logiciels.

N'hésitez pas à nous faire part de votre avis concernant l'utilisation du système. De nouveaux logiciels seront installés sur demande.

Description et caractéristiques techniques de la grappe

La grappe est actuellement constituée de :

  • 1 frontale : tycho

     pour l'édition, la compilation et la soumission des jobs
    
     pour travailler en interactif
    
  • 70 noeuds :

Noeud Nb coeurs Processeur Mémoire/noeud Disque local GPU Mise en service feature
tycho[01-16] 16 Intel Xeon E5-2670 à 2.60 GHz 64 Go 1,7 To Octobre 2013 tycho2013
tycho[17-20] 16 Intel Xeon E5-2650 v2 à 2.60 GHz 64 Go 0,9 To Juin 2014 tycho2013
tycho[21-24] 16 Intel Xeon E5-2640 v3 à 2.60 GHz 64 Go 1,7 To Octobre 2015 tycho2015
tycho25 16 Intel Xeon E5-2667 v3 à 3.2 GHz 96 Go 3,6 To 1 Tesla K20Xm Juillet 2015 tycho2015
tycho26 16 Intel Xeon E5-2667 v3 à 3.2 GHz 64 Go 1,7 To Octobre 2015 tycho2015
tycho[27,28] 24 Intel Xeon E5-2690 v3 à 2.6 GHz 256 Go 1,7 To Janvier 2016 tycho2015
tycho[29-32] 16 Intel Xeon E5-2640 v3 à 2.60 GHz 64 Go 1,7 To Mars 2016 tycho2015
tycho[33-36] 24 Intel Xeon E5-2650 v4 à 2.20 GHz 128 Go 1,7 To Septembre 2017 tycho2015
tycho[37-44] 16 Intel Xeon Silver 4110 à 2.10GHz 96 Go 0,7 To Décembre 2017 tycho2015
tycho[45-48] 24 Intel Xeon Gold 5118 à 2.30GHz  128 Go 1,6 To Décembre 2017 tycho2015
tycho[49-52] 24 Intel Xeon Gold 5118 à 2.30GHz  192 Go 1,6 To Décembre 2017 tycho2015
tycho[53-56] 28 Intel Xeon Gold 5120 à 2.20GHz 96 Go 1,6 To Novembre 2018 tycho2020
tycho57 16 Intel Xeon Bronze 3106 à 1.70GHz 96 Go 3.4 To 2 Tesla P40 novembre 2018 tycho2020
tycho58 24 Intel Xeon Silver 4214 à 2.20GHz 192 Go 1.7 To 3 Tesla V100-PCIE-32GB  octobre 2019 tycho2020
tycho[59-62] 32 Intel Xeon Gold 5120 à 2.30GHz 96 Go 1,6 To Janvier 2020 tycho2020
tycho[63-66] 48 Intel Xeon Gold 5220R à 2.20GHz 192 Go 1,5 To Juin 2020 tycho2020
tycho[67-70] 48 Intel Xeon Gold 5220R à 2.20GHz 192 Go 1,5 To Mars 2021 tycho2021
tycho[71-74] 48 Intel Xeon Gold 5220R à 2.20GHz 192 Go 1,5 To Mars 2022 tycho2022
tycho[75-78] 48 Intel Xeon Gold 5220R à 2.20GHz 192 Go 1,5 To Mars 2022 tycho2022

Logiciels et accès

Tous les noeuds de calcul sont d'un point de vue système parfaitement identiques. Si les logiciels scientifiques dont vous avez besoin ne sont pas encore disponibles sur ces machines, signalez-le mail à la DIO (admin.dio@obspm.fr). Nous vous demandons de ne pas installer de logiciel dans votre espace de stockage personnel.

L'utilisation de cette grappe est possible pour toute personne ayant un compte durable DIO (c'est-à-dire dans l'annuaire LDAP commun, utilisé aussi pour la messagerie et l'accès sans-fil).

Il est possible d'y accéder (depuis l'intérieur du réseau de l'Observatoire) par les outils ssh, avec donc le même identifiant de login et le même mot de passe que pour la messagerie ou l'accès sans-fil. Pour cela utilisez, par exemple, la commande suivante :

ssh -X tycho.obspm.fr

Pour le transfert de fichiers, depuis votre poste de travail vers ces machines, ou vice et versa, vous pouvez utiliser des outils comme scp, sftp ou rsync.

Espace de stockage

Chaque utilisateur possède des espaces de stockage :

/obs/son_login

  • sauvegarde une fois par jour, en rotation sur 14 occurrences
  • à utiliser pour y mettre les fichiers produits par l'utilisateur lui-même : fichiers bureautiques, programmes, scripts, etc... En bref tout ce qui n'est pas reproductible par calcul ou traitement, et qui a beaucoup de valeur
  • quota de 30 Go

/data/son_login

  • sauvegarde une fois par semaine, en rotation sur 4 occurrences
  • à utiliser pour y mettre les données consolidées avant ou après calcul et traitement ; autrement dit des choses qui ne bougent pas forcément beaucoup une fois qu'elles existent, mais qui ont de la valeur, car produit d'un long traitement
  • quota de 60 Go (augmentable sur demande motivée)

/poubelle/son_login :

  • pas de sauvegarde
  • suppression après 120 jours des fichiers non modifiés
  • à utiliser pour des grosses manipulations de fichiers temporaires : désarchivage/archivage, transfert avec d'autres machines extérieures à la DIO, fichiers intermédiaires dans une série de traitements, etc.
  • autrement dit, un gros passe-plats et espace tampon
  • pas de quota

/scratch/son_login :

  • pas de sauvegarde
  • les fichiers datant de plus de 20 jours sont régulièrement effacés
  • espace non partagé entre les serveurs de calcul
  • à utiliser sans réserve pour les fichiers temporaires créés lors de l'exécution d'un calcul
  • pas de quota, mais demande de déplacement à la fin du job, de manière à laisser ces espaces libres pour les calculs à venir des collègues

Nous attirons votre attention sur le fait que l'espace $HOME (= /obs/login) est sauvé une fois par jour : aussi si vous l'utilisez pour des fichiers interméiaires liés à des calculs, cela pénalise gravement le système de sauvegarde qui va enregistrer tous ces fichiers et toutes leurs variations.

L'idée sous-jacente est d'appliquer une politique de stockage et de sauvegarde adéquate aux données suivant leur nature. Plus nous pourrons « optimiser » cela, plus nous pourrons offrir de la ressource (taille de l'espace, performances, fréquence de sauvegarde, nombre de versions dans le temps, durée de conservation), là où c'est utile. Car énormément d'espace avec beaucoup de sauvegardes n'est pas possible. D'où le besoin de classifier.

Aussi merci par avance à chaque utilisateur pour bien répartir ses fichiers, souvent actuellement exclusivement dans son $HOME, entre ces différents espaces.

Statistiques d'utilisation de la grappe

Vous pouvez voir en temps réel l'utilisation de la grappe.

Gestion des variables d'environnement

La modification des variables d'environnement pour l'accès aux compilateurs est gérée par l'alias module du shell bash.

Lors de la connexion sur la frontale aucun module n'est chargé. Chaque utilisateur doit charger les modules et les versions souhaités. Il est possible de charger des modules par défaut en ajoutant la commande : module load {module_name}/{version} au fichier $HOME/.profile.

Remarque : toute modification faite sur le .profile nécessite de se déconnecter de la frontale pour sa prise en compte.

Les commandes suivantes sont disponibles :

  • module avail : affiche les modules disponibles
  • module whatis : affiche les modules disponible avec un résumé
  • module list : affiche les modules chargés dans le shell courant
  • module load module1 [module2] [...] : permet de charger des modules
  • module unload module1 : permet d'annuler la modification des variables d'environnement effectuée par le chargement du module module1
  • module purge : annule toutes les modifications apportées aux variables d'environnement par les précédent chargements

Le gestionnaire de tâches SLURM

Pour une répartition optimale des jobs que vous aurez à exécuter sur la grappe de calcul tycho, nous utilisons le système de gestion de tâches SLURM (Simple Linux Utility for Resource Management). Ce système permet une utilisation optimale des noeud/processeurs disponibles. Ce système de batch a été organisé en plusieurs queues de soumission. Dans un premier temps chaque utilisateur est limité à 156 tâches, ensuite nous ajusterons les limites par queues.

Définition des queues

6 queues publiques qui peuvent être utilisées par l'ensemble des utilisateurs, la queue par défaut est la queue short :

Partition temps maximum en min Nb noeuds maximum Noeud
maup(Mise Au Point) 5 1 tycho[01-04,06-52,57,59-78]
short 60 4 tycho[03-04,06-16,53-78]
medium 1440 4 tycho[01-04,06-24,26-32,53-56,59-78]
long 7200 4 tycho[01-02,04,06-15,17-48,57,59-78]
verylong 21600 4 tycho[01-02,04,06-11,17-32,67-78]
interactif 21600 1 tycho05
low 21600 4 tycho[03-04,06-16,67-78]

10 queues dédiées à des projets, les membres du laboratoire/projet sont prioritaire sur les noeuds qui leur sont dédiés :

Partition temps maximum en min Nb noeuds maximum Noeud
gaia 21600 8 tycho[02,21,33-36,49-52,65]
gaiaservice 21600 4 tycho[02,21,49-52,65]
grace 21600 1 tycho[25,57]
minerva 21600 1 tycho58
mis 21600 1 tycho[01,22-24,37-44,68,70,75-76]
misservice 21600 2 tycho[01,22,68,70]
mosaic 21600 1 tycho[29-32,63-64]
padc_medium 21600 1 tycho[66,75-78]
padc_verylong 21600 1 tycho[66,75-78]
pegase 21600 1 tycho[71-72]
plato 21600 1 tycho[27-28,67,69]
skybot 21600 4 tycho[17-20]
virage 21600 5 tycho[26,45-48]

Rq : les partitions [gaia,mis]service sont plus prioritaires que les partitions gaia,mis dont elles préempte les jobs.

1 queue dédiée aux utilisateurs de la bibliothèque NAG :

  • nag : maximum 15j, le noeud nag-serveur.

Les jobs non prioritaires qui s'exécutent sur les noeud dédiés aux queues gaia, mis, skybot, grace, virage, plato, mosaic, minerva, padc ou pegase sont susceptibles d'être préemptés (le job de basse priorité est mis en sommeil ---et en swap--- pour laisser la place au job prioritaire.)

Les jobs en cours d'exécution qui ont été soumis sur la partition 'low' sont susceptibles d'être préemptés par les jobs des autres partitions.

En-tête des scripts de soumission SLURM

La grappe de calcul étant hétérogène il est important de bien définir les ressources nécessaire pour que le gestionnaire de tâches répartisse au mieux les jobs. Pour cela il est indispensable de définir ces directives SLURM en en-tête :

#!/bin/bash
#SBATCH --job-name=MonProg  {Nom du programme}
#SBATCH --nodes=2 --ntasks-per-node=16 {Le nombre de noeud et de coeurs/noeud}
#SBATCH --time=120 {Le temps en minute}
#SBATCH --partition=medium {La file d'attente}
#SBATCH --mail-user=prenom.nom@obspm.fr
#SBATCH --mail-type=ALL
#SBATCH --mem=1gb {la mémoire globale, au maximum 61Gb}
#SBATCH --tmp=10gb {l'espace disque pour des fichiers stockés temporairement sur /scratch}

Rq : la directive --tmp fait référence à la taille réelle du disque scratch et non à la taille disponible.

Des exemples de scripts de soumission sont disponible dans le répertoire /shared/apps/slurm/exemples

Script de soumission d'un job MPI

Voici un script typique qui réserve 2 noeud avec 1Gb de mémoire pour 120 mn sur la queue medium :

#!/bin/bash
#SBATCH --job-name=MonProg
#SBATCH --nodes=2 --ntasks-per-node=16
#SBATCH --time=120
#SBATCH --partition=medium
#SBATCH --mem=1gb

## Définir le répertoire scratch et recopier les fichiers nécessaires à l'exécution
SCRATCH=/scratch/$USER/run.${SLURM_JOBID}
srun --ntasks=$SLURM_JOB_NUM_NODES mkdir -p $SCRATCH
cd $SCRATCH
srun --ntasks=$SLURM_JOB_NUM_NODES cp /obs/$USER/MonProg .
srun --ntasks=$SLURM_JOB_NUM_NODES cp /data/$USER/MesDonnees .

mpiexec ./MonProg > MonProg.out

srun --ntasks=$SLURM_JOB_NUM_NODES mv MesResultats /data/$USER
cd ${SLURM_SUBMIT_DIR}
mv ${SCRATCH}/MonProg.out .
srun --ntasks=$SLURM_JOB_NUM_NODES rm -rf ${SCRATCH}

exit 0

Script de soumission d'un job openMP

Voici un script typique :

#!/bin/bash
#SBATCH --job-name=MonProg
#SBATCH --nodes=1 --ntasks-per-node=16
#SBATCH --time=120
#SBATCH --partition=medium
#SBATCH --mem=1gb

## Définir le répertoire scratch et recopier les fichiers nécessaires à l'exécution
SCRATCH=/scratch/$USER/run.${SLURM_JOBID}
mkdir -p $SCRATCH
cd $SCRATCH
cp /obs/$USER/MonProg.f90 .
cp /data/$USER/MesDonnees .

ifort -openmp MonProg.f90 -o MonProg
export OMP_NUM_THREADS=16
./MonProg > MonProg.out

mv MesResultats /data/$USER
cd ${SLURM_SUBMIT_DIR}
mv ${SCRATCH}/MonProg.out .
rm -rf ${SCRATCH}

exit 0

Le nombre maximum de threads par noeud est de 16.

Soumission d'un tableau de tâches (ARRAY_TASKS)

Les ARRAY_TASKS permettent de lancer et de gérer une collection de jobs similaires, par exemple dans le cas d'un même programme analysant des sources différentes, ou initialisés avec différents fichiers de configuration.

Soumission

Pour lancer un ARRAY_TASKS il faut utiliser la commande sbatch --array=0-16 tache.slurm. Ceci aura pour effet de générer des variables d'environnement supplémentaire, notamment SLURM_ARRAY_TASK_ID et SLURM_ARRAY_JOB_ID :

  • SLURM_ARRAY_JOB_ID contient l'identifiant du tableau de tâche (identique pour toutes les taches de ce tableau)

  • SLURM_ARRAY_TASK_ID contient le numéro de la tâche courante.

L'option --array

L'option --array=0-16 présente plusieurs options :

  • --array=0-7:2 lancera les taches de 0 à 7 avec un pas de 2

  • --array=0-7%2 lancera les taches de 0 à 7 et empêchera l'exécution simultanée de plus de 2 tâches.

Nom des fichiers

Pour nommer les fichiers de sortie des jobs d'ARRAY_TASKS, il est possible d'utiliser %A et % a

  • %A : valeur de SLURM_ARRAY_JOB_ID

  • %a : valeur de SLURM_ARRAY_TASK_ID.

email

L'utilisation de tous les mots clés de l'option --mail fonctionne. Il ne s'applique cependant qu'au SLURM_ARRAY_JOB_ID. L'ajout de l'option ARRAY_TASKS appliquera l'ensemble des autres mots clés utilisés (BEGIN, ALL, END...) à chacune des tâches.

Exemple de tableau de tâches

La façon la plus simple d'utiliser un SLURM_ARRAY_JOB est de déclarer un tableau de paramètres et d'appeler chaque valeur avec SLURM_ARRAY_TASK_ID.

#!/bin/bash
#SBATCH --job-name=jobarray
#SBATCH --time=01:00:00
#SBATCH --nodes=1 --ntasks-per-node=2
#SBATCH --partition=short
#SBATCH --mem=40gb 
#SBATCH --mail-user=clement.hottier@obspm.fr
#SBATCH --output=slurm-jobarray-%A_%a.out
#SBATCH --mail-type=ALL
#SBATCH --array=0-7%4

initarray = ("init0" "init1" "init2" "init3" "init4" "init5" "init6") 

SCRATCH=/scratch/$USER/run.$SLURM_ARRAY_JOB_ID.$SLURM_ARRAY_TASK_ID
mkdir $SCRATCH

./monprog --init ${initarray[$SLURM_ARRAY_TASK_ID]} --scratch $SCRATCH

rm -rf $SCRATCH

Le script précédent lancera l'exécutable monprog sur tous les fichiers init.

$> sbatch jobarray.slurm
Submitted batch job 25289
$> squeue -j 25289
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
       25290_[4-7]     short     chottier PD            0:00      1 (Priority)
       25290_0         short     chottier R             0:05      1 tycho04
       25290_1         short     chottier R             0:05      1 tycho04
       25290_2         short     chottier R             0:05      1 tycho04
       25290_3         short     chottier R             0:05      1 tycho04
contrôle des SLURM_ARRAY_JOB

Toutes les fonctionnalités de scontrol et scancel peuvent être utilisées :

  • sur tout les SLURM_ARRAY_JOB : scontrol update --job=25290

  • sur une seule tâche : scontrol update --job=25290_2

  • sur une sélection de tâches : scontrol update --job=25290_[1-4,7] (s'applique sur 1, 2, 3, 4 et 7)

Soumission d'un job "finisher"

Il est possible de soumettre un job qui ne se lancera qu'après la fin de l'exécution du SLURM_ARRAY_JOB : sbatch --depend=aftercondition:jobid(s) finisher.slurm. Le job finisher ne se lancera que lorsque la condition aftercondition sera réalisée.

Plusieurs aftercondition sont possibles :

  • after : satisfait quand toutes les tâches sont lancées

  • afterok : satisfait quand toutes les tâches sont achevées sans erreurs

  • afterany : satisfait quand toutes les tâches sont achevées

  • afternotok : satisfait quand toutes les tâches sont achevées, et qu'au moins une ait produit une erreur.

On peut ainsi spécifier un job finisher pour tout le SLURM_ARRAY_JOB

sbatch --depend=afterok:25290 finisher.slurm

mais aussi pour un job spécifique :

sbatch --depend=afterok:25290_5

Enfin on peut aussi lancer un réparateur

sbatch --depend=afternotok:25290 execfixer.slurm

Soumission d'un job utilisant IDL

Nous avons un nombre limité de jetons IDL (cf Nombre de licences). Pour utiliser le moins de jeton un utilisateur doit soumettre tous ses jobs faisant appel à IDL sur un même noeud. Pour cela il faut utiliser la commande idl.slurm.sh, cette commande renvoie le nom du noeud ou l'utilisateur doit soumettre son job. Si l'utilisateur n'utilise pas encore de jeton IDL, le nom du noeud sera le noeud qui a le plus de processeurs disponible au cas ou l'utilisateur voudrait soumettre un ou plusieurs autres jobs. S'il utilise déjà un jeton IDL, la commande va regarder si on peut soumettre un autre job sur le même noeud. Le résultat de la commande dépend du nombre de processeurs, de la taille mémoire et de la partition demandés. Quand il n'y a plus de noeud disponible, la commande renvoie 1.

Par exemple, je souhaite soumettre un job sur 4 proc avec 0.5 Go dans la partition medium :

tycho :~> idl.slurm.sh 4 0.5 medium
tycho03

La commande a vérifié que j'utilisais déjà un jeton IDL et qu'il restait suffisamment d'espace pour mon job. Je dois donc ajouter dans l'en-tête de mon script

#SBATCH --nodelist=tycho03

Travail interactif

  • Réservation d'un coeur sur le noeud interactif et exécution de Mathematica

      module load mathematica
      salloc -t 04:00:00 -p interactif -J mathematica srun --x11 mathematica
    
  • Réservation d'un coeur sur un le noeud interactif et exécution de Matlab

      module load matlab
      salloc -t 04:00:00 -p interactif -J matlab srun --pty --x11 matlab
    
  • Réservation d'un coeur sur le noeud interactif et ouverture d'une session sur ce noeud

      salloc [-t tempsMinute] [-J NomJob] -p interactif srun --pty bash
      ou
      salloc [-t tempsMinute] [-J NomJob] -p interactif srun --x11 xterm
    
  • Réservation d'un coeur et ouverture d'une session sur nag-serveur pour la compilation des bibliothèques NAG

      salloc [-t tempsMinute] [-J NomJob] -p nag srun --pty bash
      ou
      salloc [-t tempsMinute] [-J NomJob] -p nag srun --x11 xterm
    

Attention : la version actuelle de slurm ne permet pas d'utiliser l'option --x11. Il faut exécuter srun --pty bash pour réserver les ressources nécessaires et ensuite se connecter sur le noeud interactif : ssh -X interactif

Soumission d'un job utilisant le GPU

Il faut réserver un GPU en précisant l'option :

#SBATCH --gres=gpu:1

Les commandes de base

  • sbatch : soumission d'un job

      tycho:~$ sbatch MonProg.slurm
      Submitted batch job 381
    

Option : -x pour exclure des noeuds, par exemple les noeuds qui peuvent être préemptés

    tycho:~$ sbatch -x tycho[01-02,17-20] MonProg.slurm

ou dans le script :

    #SBATCH --exclude=tycho[01-02,17-20]

Une autre façon d'exclure les noeuds sur lequels la préemption peut avoir lieu :

    #SBATCH --constraint=public

Pour faire tourner un job sur type de noeud particulier :

    #SBATCH --constraint=tycho2013
  • scancel : destruction d'un job

      tycho:~$ scancel 381
    
  • scancel : destruction de tous ses jobs

      tycho:~$ scancel -u $USER
    
  • squeue : suivi d'un job

      tycho:~$ squeue 
      JOBID    PARTITION     NAME     USER  ST       TIME  NODES NODELIST(REASON)
        381         long  MonProg marchand   R 2-23:49:59      2 tycho[03-04]
        475       medium     Test vaillant   R      23:18      1 tycho06
        473       medium  MonProg marchand  PD       0:00      1 (resources)
    
  • sacct : récapitulatif des jobs sur une période

Par exemple afficher certains paramètres de tous les jobs soumis après le 1er Mars 2014 :

    tycho:~$ sacct -S 2014-03-01 -o jobid,user,nodelist,state
       JobID     User      NodeList     State
    -------- -------- ------------- ---------
      245    marchand       tycho03   TIMEOUT
      245.0                 tycho03 CANCELLED
      286    vaillant       tycho05 COMPLETED
      286.0                 tycho05 COMPLETED
      381    marchand  tycho[03-04]   RUNNING
      475    vaillant       tycho06   RUNNING
      473    marchand None assigned   PENDING

Pour connaitre la liste des paramètres :

    tycho:~$ sacct -helpformat
  • scontrol : visualisation et modification d'un job

      tycho:~$ scontrol show job {jobid}
      tycho:~$ scontrol update JobID={jobid} TimeLimit=10:00:00
    
  • sview : interface graphique qui permet de voir l'état général du système

Liste des variables d'environnement définies par SLURM lors de l'exécution d'un job :

SLURM_CHECKPOINT_IMAGE_DIR=/home/$USER/MonRep
SLURM_CPUS_ON_NODE=16
SLURMD_NODENAME=tycho03
SLURM_GTIDS=0
SLURM_JOB_CPUS_PER_NODE=16(x2)
SLURM_JOB_ID=381
SLURM_JOBID=381
SLURM_JOB_NAME=MonProg
SLURM_JOB_NODELIST=tycho[03-04]
SLURM_JOB_NUM_NODES=2
SLURM_LOCALID=0
SLURM_MEM_PER_NODE=1024
SLURM_NNODES=2
SLURM_NODEID=0
SLURM_NODELIST=tycho[03-04]
SLURM_NPROCS=32
SLURM_NTASKS=32
SLURM_PRIO_PROCESS=0
SLURM_PROCID=0
SLURM_SUBMIT_DIR=/home/$USER/MonRep
SLURM_TASK_PID=25434
SLURM_TASKS_PER_NODE=16(x2)
SLURM_TOPOLOGY_ADDR_PATTERN=node
SLURM_TOPOLOGY_ADDR=tycho03

Commandes de gestion de l'espace /scratch

L'espace /scratch est local à chaque noeud.

A la fin du script, les données de scratch doivent être recopiés sur une des zones partagées (obs, data ou poubelle) puis être effacées de l'espace /scratch de chacuns des noeuds alloués à l'exécution du job.

En cas d'interruption du job (dépassement de la limite de temps par exemple) des données vont rester sur les noeuds et il faudra retrouver les noeuds sur lesquels elles sont restées et les effacer en se connectant par ssh sur chacun des noeuds. Des utilitaires sont là pour vous aider :

  • scratch_ls : liste le contenu de /scratch/$USER sur tous les noeuds
  • scratch_du : affiche l'espace occupé par /scratch/$USER sur tous les noeuds
  • scratch_rm tycho[90-92,95] : efface le contenu de /scratch/$USER sur les noeuds tycho90 à tycho92 et tycho95
  • scratch_rm -a : efface le contenu de /scratch/$USER sur tous les noeuds. Il faut s'assurer auparavant que vous n'avez aucun job en cours d'exécution.

Ces commandes utilisent le shell distribué pdsh pour executer une commande sur tout ou partie des noeuds. Par exemple :

  • Lister le contenu d'un répertoire sur tous les noeuds :

    pdsh -a ls -l /scratch/$USER

  • Idem mais avec une meilleure présentation :

    pdsh -a ls -l /scratch/$USER | dshbak

Remarque : Il est normal que ces commandes affichent un message d'erreur lorsqu'elles se connectent à des noeuds éteints par slurm.

Accès à l'IDRIS

L'accès aux serveurs de l'IDRIS est possible depuis tycho.obspm.fr

Statistiques d'utilisation

Statistiques pour l'année 2022, temps d'attente par partition

Statistiques pour l'année 2021, temps d'attente par partition

Statistiques pour l'année 2020, temps d'attente par partition

Statistiques pour l'année 2019, temps d'attente par partition

Statistiques pour l'année 2018, temps d'attente par partition

Statistiques pour l'année 2017

Statistiques pour l'année 2016

Statistiques pour l'année 2015

Statistiques pour l'année 2014

Statistiques pour l'année 2013