¶ Cluster de calculs CPU & GPU
Ce cluster de calcul est partagé par toute l’équipe DSIMB.
Le cluster est utile pour les calculs intensifs en Deep Learning, pour les dynamiques moléculaires (Gromacs) ou encore la prédiction et l’analyse des structures de protéines (i.e. AlphaFold, RoseTTAFold, ColabFold, etc).
¶ Comment accéder au noeud service du cluster ?
Depuis opera ou n’importe quelle machine du labo:
$ ssh cafe
¶ Caractéristiques techniques
| NODE | CPUs | Nb GPU | GPU | GPU Memory (GB) | RAM (GB) | Type de noeud |
|---|---|---|---|---|---|---|
| CAFE | 28 | 1 | A6000 | 48 | 50 | Service |
| COCO | 48 | 1 | A5000 | 24 | 124 | Calcul |
| ARABICA | 64 | 1 | A5500 | 24 | 124 | Calcul |
| ROBUSTA | 32 | 1 | A6000 | 48 | 60 | Calcul |
| CACAO | 96 | 1 | A100 | 80 | 288 | Calcul |
| ITALIE | 32 | 0 | 160 | Calcul |
¶ Programmes
Les programmes disponibles sont toujours accessibles via les modules. Néanmoins, étant donné que la machine comporte une GPU, certains programmes ont été compilé exprès pour prendre en compte la GPU, ce qui fait que certains modules qui ne sont pas accessibles sur d’autres machines seront spécifiquement accessibles sur cette machine en particulier.
Vérifiez les programmes disponibles avec la commande: module av
¶ Lancer un job
Afin d’avoir une gestion le plus équitable possible des ressources de la machine, un gestionnaire de queue a été installé: SLURM.
C’est le même gestionnaire qui est utilisé sur les plus grosses plateforme de calcul HPC en France (e.g. OCCIGEN, IDRIS, IRENE) et dans le monde.
Des partitions ont été définies, afin de faciliter la priorisation des jobs, selon la durée du job requis:
| PARTITION | LIMITE DE TEMPS | NOEUDS ACCESSIBLES | USAGE |
|---|---|---|---|
| RISTRETTO | 12:00:00 | cafe, coco, arabica, robusta | Mixte |
| ESPRESSO* | 1-00:00:00 | cafe, coco, arabica, robusta | Mixte |
| LUNGO | 7-00:00:00 | cafe, coco, arabica, robusta | Mixte |
| DEEP_LEARNING | 7-00:00:00 | cacao, cafe, robusta | Deep learning, haute utilisation de mémoire GPU |
| SEARCH_DATABASES | 1-00:00:00 | coco | Recherche dans des bases de données (partition SSD) |
| HIGH_MEMORY | 1-00:00:00 | italie | Besoin de beaucoup de mémoire RAM, calcul CPU |
La partition ESPRESSO est celle utilisée par défaut si aucune n’est procurée dans la définition du job.
Des facteurs de priorité ont été définis, afin de favoriser entre autre les jobs de petite durée (à envoyer donc dans la partition RISTRETTO).
Si le job dépasse le temps limite de la partition dédiée, il est automatiquement arrêté par le système avec le message d’erreur suivant:
slurmstepd-cafe: error: *** STEP <JOB ID> ON cafe CANCELLED AT <DATE> DUE TO TIME LIMIT ***
Il est interdit de lancer un calcul sans passer par le gestionnaire de queue SLURM, sous peine de se le voir tuer sans semonce.
¶ Stockage
Le stockage du cluster se trouve sur le noeud principal cafe.
Donnez le chemin vers vos données en input et output en utilisant /home/cafe ou /dsimb/cafe.
Il existe plusieurs manières de lancer un job avec SLURM, en voici quelques-unes explicitées ci-dessous.
¶ Avec SBATCH
Pour des explications avancées sur cette commande en particulier, se référer à la documentation en ligne: https://slurm.schedmd.com/sbatch.html
¶ Example pour lancer un script python.
#!/bin/bash
#SBATCH -p RISTRETTO # partition: choice between [RISTRETTO, ESPRESSO (default), LUNGO]. Type `sinfo` for more info
#SBATCH --time=1:00:00 # walltime: max depends on the partition chosen
#SBATCH --cpus-per-task=4 # number of processor cores
#SBATCH --nodes=1 # number of nodes
#SBATCH --gres=gpu:1 # number of GPU
#SBATCH --mail-user=email # Où envoyer l'e-mail
#SBATCH --mail-type=END,FAIL # Événements déclencheurs (NONE, BEGIN, END, FAIL, ALL)
#SBATCH -J "test" # job name
date;pwd
ml purge # Clean the environment
ml py-tensorflow/2.14.0
python3 -c "import tensorflow as tf; tf.test.is_gpu_available(cuda_only=False, min_cuda_compute_capability=None)"
date
Lancer avec la commande:
$ sbatch filename.sh
¶ Utiliser un environnement conda
Suivez la documentation sur cette page.
¶ AlphaFold
La compilation des modèles et la partie prédictions prennent entre 2 et 4 fois plus longtemps en full CPU par rapport à avec une GPU.
Exemple: Pour une protéine de 220 résidus, la partie inférence avec 1 modèle qui prend 2 minutes en GPU, prend 40 minutes en CPU. Sachant qu’il y a 5 modèles différents et donc 5 compilations + prédictions, cette partie qui est négligeable en utilisant la GPU peut très vite devenir la partie la plus lente en full CPU.
Néanmoins, par défaut, un job Alphafold est lancé sans GPU afin de ne pas bloquer des jobs qui nécessitent par nature la GPU (Deep Learning).
Exemple d’un job AlphaFold lancé en GPU sur
cafe:
- Séquence de 178 résidues
- Monomère
- full_dbs
- Relaxation Amber sur la GPU
Temps de calcul total: ~30 minutes
¶ job_script.sh
#!/bin/bash
#Submit this script with: sbatch thefilename
#SBATCH -p LUNGO # Partition: choice between [RISTRETTO, ESPRESSO, LUNGO, DEEP_LEARNING].
#SBATCH --time=2:00:00 # Walltime: max depends on the partition chosen
#SBATCH --cpus-per-task=8 # Nombre de coeurs
#SBATCH --mem=20G # 20 Gb by default
#SBATCH --gres=gpu:1 # Nombre de GPU (aucune par défaut)
#SBATCH --nodes=1 # Number of nodes
#SBATCH --output=%x.%j.out # Standard output + error
#SBATCH --mail-user=email # Où envoyer l'e-mail
#SBATCH --mail-type=END,FAIL # Événements déclencheurs (NONE, BEGIN, END, FAIL, ALL)
#SBATCH -J "alphafold" # Job name
# Move to the directory where the job was submitted
cd $SLURM_SUBMIT_DIR
ml purge
ml py-alphafold/2.3.2
date;pwd
# On spécifie le nombre de CPUs pour les étapes de HHBlits et Jackhmmer
export HHBLITS_NTHREADS=$SLURM_CPUS_PER_TASK
export JACKHMMER_NTHREADS=$SLURM_CPUS_PER_TASK
# Ceci est un wrapper pour simplier le lancement d'Alphafold.
# Les bases de données sont prédéfinies dans le wrapper.
# Pour avoir tous les arguments optionnels, lancez: run_alphafold.sh -h
run_alphafold.sh \
-d /dsimb/cafe/DATABASES \
-f input/sequence.fasta \
-o outputs \
-t 2020-05-14 \
-m monomer \
-c full_dbs
# Option -f: chemins vers les fichiers FASTA, chacun contenant une cible qui sera prédite l'une après l'autre.
# Si un fichier FASTA contient plusieurs séquences, alors il sera considéré comme un multimère
.
# Les chemins doivent être séparés par des virgules.
# Tous les chemins FASTA doivent avoir un nom de base unique car le nom de base est utilisé pour nommer les répertoires de sortie pour chaque prédiction.
date
Modifiez à votre guise les chemins et autres options de AlphaFold, puis lancez le job avec la commande:
$ sbatch job_script.sh
Pour avoir l’état de la queue:
$ squeue
Pour surveiller l’output du job:
$ tail -f output/alphafold.<job_id>.out
Pour supprimer le job avant la fin si besoin:
$ scancel <job_id>
Pour avoir des infos sur les ressources du job:
$ scontrol show job <job_id>
¶ GROMACS
#!/bin/bash
#Submit this script with: sbatch filename
#SBATCH -p LUNGO # Partition: choice between [RISTRETTO, ESPRESSO (default), LUNGO]. Type `sinfo` for more info
#SBATCH --time=72:00:00 # Walltime: max depends on the partition chosen
#SBATCH --cpus-per-task=40 # Nombre de coeurs
#SBATCH --mem=20G # 20 Gb by default
#SBATCH --gres=gpu:1 # 1 GPU (pas plus)
#SBATCH --nodes=1 # Number of nodes
#SBATCH --output=%x.%j.out # Standard output + error
#SBATCH --mail-user=email # Où envoyer l'e-mail
#SBATCH --mail-type=END,FAIL # Événements déclencheurs (NONE, BEGIN, END, FAIL, ALL)
#SBATCH -J "gromacs" # Job name
# Move to the directory where the job was submitted
cd $SLURM_SUBMIT_DIR
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
ml purge
ml gromacs/2022
date;pwd
gmx mdrun -v -deffnm /home/cafe/cretin/md_test
date
¶ Colabfold
ColabFold a été installé en local.
Les calculs de MSAs (les plus intensifs et longs) sont effectués sur le serveur de MMSEQS en ligne,
puis la prédiction avec les 5 modèle d’alphafold est quant à elle lancée en local sur une GPU.
Il est possible de ne pas utiliser de GPU, ça sera plus long mais permet de ne pas monopoliser une GPU en cas
de forte demande de calculs.
Un job prend en moyenne ~10-15 minutes (avec GPU).
Pour avoir plus d’infos sur les commandes à lancer ou le projet en général, regarder la page du projet:
https://github.com/YoshitakaMo/localcolabfold
#!/bin/bash
# Submit this script with: sbatch filename
#SBATCH -p DEEP_LEARNING # Partition: choice between [RISTRETTO, ESPRESSO (default), LUNGO, DEEP_LEARNING]. Type `sinfo` for more info
#SBATCH --time=00:15:00 # Walltime: max depends on the partition chosen
#SBATCH --cpus-per-task=8 # Nombre de coeurs (suffisant pour un job colabfold)
#SBATCH --mem=10G # 10 Gb by default
#SBATCH --gres=gpu:1 # Nombre de GPU (aucune par défaut)
#SBATCH --nodes=1 # Number of nodes
#SBATCH --output=%x.%j.out # Standard output + error
#SBATCH --mail-user=email # Où envoyer l'e-mail
#SBATCH --mail-type=END,FAIL # Événements déclencheurs (NONE, BEGIN, END, FAIL, ALL)
#SBATCH -J "colabfold" # Job name
# Move to the directory where the job was submitted
cd $SLURM_SUBMIT_DIR
ml purge
ml py-colabfold/1.5.5
date;pwd
# More infos here: https://github.com/YoshitakaMo/localcolabfold
colabfold_batch --amber --templates --num-recycle 3 --use-gpu-relax /home/cafe/cretin/colabfold/input/1jx4.fasta /home/cafe/cretin/colabfold/output/
date
¶ RoseTTAFold
Site web du projet: https://github.com/RosettaCommons/RoseTTAFold
¶ For monomer structure prediction
run_[pyrosetta, e2e]_ver.sh input.fa .
¶ For complex modeling
See README file under https://github.com/RosettaCommons/RoseTTAFold/tree/main/example/complex_modeling for details.
predict_complex.py -i paired.a3m -o complex -Ls 218 310
¶ For PPI screening using faster 2-track version (example input and output are at example/complex_2track)
predict_msa.py -msa [paired MSA file in a3m format] -npz [output npz file name] -L1 [Length of first chain]
e.g. network_2track/predict_msa.py -msa input.a3m -npz complex.npz -L1 218
¶ SLURM example job
#!/bin/bash
# Submit this script with: sbatch filename
#SBATCH -p DEEP_LEARNING # Partition: choice between [RISTRETTO, ESPRESSO (default), LUNGO, DEEP_LEARNING]. Type `sinfo` for more info
#SBATCH --time=01:00:00 # Walltime: max depends on the partition chosen
#SBATCH --cpus-per-task=16 # Number of cores
#SBATCH --mem=20G # 20000 Mb = 20 Gb by default
#SBATCH --gres=gpu:1 # Nombre de GPU
#SBATCH --nodes=1 # Number of nodes
#SBATCH --output=%x.%j.out # Standard output + error
#SBATCH --mail-user=email # Où envoyer l'e-mail
#SBATCH --mail-type=END,FAIL # Événements déclencheurs (NONE, BEGIN, END, FAIL, ALL)
#SBATCH -J "Rosettafold" # Job name
# Move to the directory where the job was submitted
cd $SLURM_SUBMIT_DIR
ml purge
ml rosettafold
date;pwd
# Set custom databases
export DATABASES_DIR=/dsimb/cafe/DATABASES/
export UNIREF=$DATABASES_DIR/uniclust30/uniclust30_2021_06/UniRef30_2021_06
export BFD=$DATABASES_DIR/bfd/bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt
export PDB=$DATABASES_DIR/pdb100_2021Mar03/pdb100_2021Mar03
# Launch prediction
run_e2e_ver.sh ./T1078.fasta ./results/T1078
date
¶ Demander des GPUs spécifiques
Pour voir les GPUs disponibles par partition:
cretin@cafe:~# sinfo -o "%P %G %D %N"
PARTITION GRES NODES NODELIST
RISTRETTO gpu:rtx3090:1 1 cafe
RISTRETTO gpu:rtx3080:1 1 liege
ESPRESSO* gpu:rtx3090:1 1 cafe
ESPRESSO* gpu:rtx3080:1 1 liege
LUNGO gpu:rtx3090:1 1 cafe
LUNGO gpu:rtx3080:1 1 liege
DEEP_LEARNING gpu:a100:1 1 cacao
Pour requêter spécifiquement une RTX3090 dans un job utiliser la ligne suivante:
#SBATCH --gres=gpu:rtx3090:1
¶ Nvidia A100 80 Go (PCIe)
Pour lancer un job sur le noeud cacao avec la GPU A100 il faut requêter la partition DEEP_LEARNING et une GPU:
#SBATCH -p DEEP_LEARNING
#SBATCH --gres=gpu:a100
ou
#SBATCH -p DEEP_LEARNING
#SBATCH --gres=gpu:1
¶ Commande interactive SRUN
La commande srun est une commande SLURM qui permet de lancer un job directement avec la demande d’allocation de ressources en ligne de commande.
Etant donné le grand nombre d’arguments et de possibilités de cette commande, je vous invite à lire sa documentation pour plus d’infos: https://slurm.schedmd.com/srun.html
¶ Efficacité des jobs
¶ seff
La commande seff <job_id> permet d’afficher la consommation réelle des jobs en CPUs, en mémoire et en temps.
Elle fourni également la mesure générale d’efficacité en CPU et en mémoire.
Cette commande est très utile pour calibrer plus justement vos requêtes en ressources, ceci afin non seulement d’ajuster
votre “note” de FAIR Share, mais également afin potentiellement de libérer de la ressource pour d’autres utilisateurs.
cretin@cafe:~$ seff 1248
Job ID: 1248
Cluster: cafe
User/Group: cretin/dsimb
State: COMPLETED (exit code 0)
Nodes: 1
Cores per node: 16
CPU Utilized: 00:00:24
CPU Efficiency: 3.12% of 00:12:48 core-walltime
Job Wall-clock time: 00:00:48
Memory Utilized: 910.80 MB
Memory Efficiency: 4.55% of 19.53 GB
¶ reportseff
Voir la documentation complète: https://github.com/troycomi/reportseff
Exemple d’une sortie:
cretin@cafe:~$ reportseff -u cretin
Si la sortie de la commande est bizarre avec des
ESC[0mqui traînent partout, exécutez cette commande:
echo "export LESS='-R'" >> ~/.bashrc && source ~/.bashrc
¶ jobstats
Exemple de sortie de la commande jobstats en tant que root (qui a la visibilité sur tous les jobs).
root@cafe:~$ jobstats
JobID JobName ReqMem MaxRSS ReqCPUS UserCPU Timelimit Elapsed State JobEff
=======================================================================================================================================
2787 ProtTrans Embeddin+ 50.0G 0.0M 96 00:00.753 7-00:00:00 00:00:02 FAILED -
2788 ProtTrans Embeddin+ 50.0G 0.0M 96 00:00.758 7-00:00:00 00:00:02 FAILED -
2789 ProtTrans Embeddin+ 50.0G 0.0M 96 00:00.715 7-00:00:00 00:00:01 FAILED -
2790 ProtTrans Embeddin+ 50.0G 4.74G 96 00:13.784 7-00:00:00 00:02:33 FAILED -
2791 ProtTrans Embeddin+ 50.0G 2.46G 96 01:04.327 7-00:00:00 00:01:04 FAILED -
2792 ProtTrans Embeddin+ 50.0G 0.0M 96 00:18.562 7-00:00:00 00:00:16 FAILED -
2793 ProtTrans Embeddin+ 50.0G 0.02M 96 00:17.261 7-00:00:00 00:00:17 COMPLETED 0.35
2794 ProtTrans Embeddin+ 50.0G 0.0M 96 00:17.806 7-00:00:00 00:00:17 COMPLETED 0.55
2795 ProtTrans Embeddin+ 50.0G 0.0M 96 00:13.863 7-00:00:00 00:00:13 FAILED -
2796 ProtTrans Embeddin+ 50.0G 0.0M 96 00:15.458 7-00:00:00 00:00:17 COMPLETED 0.47
2797 ProtTrans Embeddin+ 50.0G 0.0M 96 00:16.598 7-00:00:00 00:00:17 COMPLETED 0.51
2798 ProtTrans Embeddin+ 50.0G 0.0M 96 00:17.644 7-00:00:00 00:00:17 COMPLETED 0.54
2799 ProtTrans Embeddin+ 50.0G 0.0M 96 00:13.542 7-00:00:00 00:00:13 FAILED -
2800 ProtTrans Embeddin+ 50.0G 4.32G 96 01:00.008 7-00:00:00 00:00:58 FAILED -
2801 ProtTrans Embeddin+ 50.0G 4.72G 96 01:09.308 7-00:00:00 00:01:22 COMPLETED 3.44
2802 ProtTrans Embeddin+ 50.0G 4.68G 96 01:12.887 7-00:00:00 00:01:28 COMPLETED 3.42
2803 ProtTrans Embeddin+ 50.0G 4.69G 96 01:09.765 7-00:00:00 00:01:25 COMPLETED 3.42
2804 ProtTrans Embeddin+ 50.0G 0.0M 8 00:00.922 7-00:00:00 00:00:02 FAILED -
2806 ProtTrans Embeddin+ 50.0G 49.3G 96 38:08.350 7-00:00:00 00:39:42 OUT_OF_MEMORY -
2811 AlphaFold 39.0G 13.5G 8 01:57:09 06:00:00 01:01:12 COMPLETED 25.24
2812 AlphaFold 39.0G 13.0G 8 01:22:42 06:00:00 00:42:49 COMPLETED 23.16
2813 AlphaFold 39.0G 13.3G 8 01:06:46 06:00:00 00:33:20 COMPLETED 22.86
2814 AlphaFold 39.0G 14.0G 8 02:08:03 06:00:00 01:03:11 COMPLETED 26.29
2815 ProtTrans Embeddin+ 279.G 254.G 96 45:13.432 7-00:00:00 00:47:55 OUT_OF_MEMORY -
2816 ProtTrans Embeddin+ 279.G 0.0M 96 00:00.962 7-00:00:00 00:00:09 FAILED -
2817 ProtTrans Embeddin+ 279.G 59.4G 96 41:07.999 7-00:00:00 00:43:15 FAILED -
2818 ProtTrans Embeddin+ 279.G 265.G 96 45:01.293 7-00:00:00 00:47:42 OUT_OF_MEMORY -
2819 ProtTrans Embeddin+ 279.G 59.1G 96 41:07.117 7-00:00:00 00:42:50 FAILED -
2820 AlphaFold 39.0G 13.1G 8 01:37:45 06:00:00 01:00:33 COMPLETED 23.55
2821 AlphaFold 39.0G 13.2G 8 01:35:32 06:00:00 00:44:54 COMPLETED 24.3
2822 ProtTrans Embeddin+ 279.G 110.G 96 41:26.744 7-00:00:00 00:52:07 COMPLETED 13.7
2823 check_redundancy_PS 40.0G 6.13G 48 7-02:11:54 12:00:00 04:33:11 COMPLETED 43.71
2825 ProtTrans Embeddin+ 50.0G 0.04M 96 00:00.253 7-00:00:00 00:00:01 COMPLETED 0.09
2826 sleep 1.00G 0.05M 2 00:00.006 7-00:00:00 00:00:00 FAILED -
2827 ProtTrans Embeddin+ 50.0G 16.4M 96 00:00.226 7-00:00:00 00:00:01 COMPLETED 0.09
2832 Pro_Epi_log 19.5G 0.0M 16 00:00.380 01:00:00 00:00:02 COMPLETED 0.62
2833 Pro_Epi_log 19.5G 0.0M 16 00:00.362 01:00:00 00:00:01 COMPLETED 1.15
2834 Pro_Epi_log 19.5G 0.0M 16 02:50.249 01:00:00 00:00:23 COMPLETED 23.45
2835 Pro_Epi_log 19.5G 0.02M 16 03:04.160 01:00:00 00:00:22 COMPLETED 17.64
=======================================================================================================================================
Memory : 18.70%
CPU : 51.37%
Time Limit : 00.56%
=======================
Efficiency Score: 23.54
=======================
¶ Efficacité des jobs GPU
La commande sacct native de SLURM sur laquelle se basent les commandes précédentes (reportseff et jobstats)
ne répertorie pas encore l’usage des GPUs.
Pour l’obtenir, des scripts qu’on appel prolog et epilog ont été rajoutés et se basent sur le package
développé par NVIDIA: Data-Center GPU Managment (dcgm).
En début et fin de tous les jobs, SLURM lance des scripts qui permettent d’enregistrer les performances et usages de la GPU par ce job.
Les statistiques d’utilisation et efficacité des GPU par vos jobs se trouvent dans le répertoire de sortie de ceux-ci sous la forme:
gpu-stats-$HOSTNAME-$SLURM_JOBID.info
¶ Priorité des jobs (FAIR Share)
Pour garantir un accès équilibré aux ressources du cluster, un système de partage équitable a été instauré sur le cluster. En pratique, cela signifie que les tâches ont un score de priorité qui dicte quand elles peuvent être exécutées par rapport à d’autres tâches. Ce score est affecté par le nombre d’heures d’équivalent CPU utilisées par un utilisateur au cours des dernières semaines. Le nombre d’équivalents CPU alloués à une tâche est défini comme le plus grand entre (a) le nombre de coeurs demandés et (b) la quantité totale de mémoire demandée divisée par la mémoire par défaut par coeur. Si un utilisateur a utilisé une grande quantité d’heures d’équivalent CPU, ses travaux reçoivent un score de priorité inférieur et prendront donc plus de temps à démarrer si le cluster est occupé.
Pour connaître votre “note” de FAIR Share, utilisez la commande sshare:
cretin@cafe:~$ sshare
Account User RawShares NormShares RawUsage EffectvUsage FairShare
-------------------- ---------- ---------- ----------- ----------- ------------- ----------
dsimb 1 0.500000 5311 1.000000
dsimb cretin 1 0.058824 0 0.000000 0.944444
Pour voire les notes de tout le groupe DSIMB
cretin@cafe:~$ sshare -a dsimb
Account User RawShares NormShares RawUsage EffectvUsage FairShare
-------------------- ---------- ---------- ----------- ----------- ------------- ----------
dsimb 1 0.500000 5311 1.000000
dsimb balduzzi 1 0.058824 0 0.000000 0.944444
dsimb barry 1 0.058824 0 0.000000 0.944444
dsimb bellaiche 1 0.058824 0 0.000000 0.944444
dsimb benyakhlaf 1 0.058824 4980 0.937649 0.055556
dsimb cathy 1 0.058824 0 0.000000 0.944444
dsimb cretin 1 0.058824 0 0.000000 0.944444
dsimb debrevern 1 0.058824 0 0.000000 0.944444
dsimb diharce 1 0.058824 0 0.000000 0.944444
dsimb falque 1 0.058824 0 0.000000 0.944444
dsimb galochkina 1 0.058824 0 0.000000 0.944444
dsimb gelly 1 0.058824 331 0.062351 0.111111
dsimb grand 1 0.058824 0 0.000000 0.944444
dsimb jedele 1 0.058824 0 0.000000 0.944444
dsimb martins 1 0.058824 0 0.000000 0.944444
dsimb molza 1 0.058824 0 0.000000 0.944444
dsimb nadaradja+ 1 0.058824 0 0.000000 0.944444
dsimb vmeersch 1 0.058824 0 0.000000 0.944444
¶ Quand est-ce que mon job va se lancer ?
Pour obtenir une estimation de l’heure de début de vos jobs, utilisez cette commande :
squeue -u $USER --start
Cette commande n’affichera que les tâches en attente. Par conséquent, les informations sur les tâches en cours d’exécution ne seront pas affichées. Slurm ne prend en compte que trois tâches en attente à la fois par utilisateur, vous ne verrez donc pas les heures de démarrage estimées pour plus de ce nombre de tâches.
¶ Rappel des principales commandes utiles de SLURM
| User commands | Environment | Job Specification | |||
|---|---|---|---|---|---|
| Job submission | sbatch [script_file] | Job ID | $SLURM_JOBID | Script directive | #SBATCH |
| Job deletion | scancel [job_id] | Submit Directory | $SLURM_SUBMIT_DIR | Queue | -p [queue] |
| Job status (by job) | squeue [job_id] | Submit Host | $SLURM_SUBMIT_HOST | Node Count | -N [min[-max]] |
| Job status (by user) | squeue -u [user_name] | Node List | $SLURM_JOB_NODELIST | CPU Count | -n [count] |
| Job hold | scontrol hold [job_id] | Job Array Index | $SLURM_ARRAY_TASK_ID | Wall Clock Limit | -t [min] OR -t [days-hh:mm:ss] |
| Job release | scontrol release [job_id] | Standard Output FIle | -o [file_name] | ||
| Queue list | squeue | Standard Error File | e [file_name] | ||
| Node list | sinfo -N OR scontrol show nodes | Combine stdout/err | (use -o without -e) | ||
| Cluster status | sinfo | Copy Environment | –export=[ALL | NONE | variables] | ||
| GUI | sview | Event Notification | –mail-type=[events] | ||
| Email Address | –mail-user=[address] | ||||
| Job Name | –job-name=[name] | ||||
| Job Restart | –requeue OR --no-requeue (NOTE:configurable default) | ||||
| Working Directory | –workdir=[dir_name] | ||||
| Resource Sharing | –exclusive OR–shared | ||||
| Memory Size | –mem=[mem][M|G|T] OR --mem-per-cpu=[mem][M|G|T] | ||||
| Account to charge | –account=[account] | ||||
| Tasks Per Node | –tasks-per-node=[count] | ||||
| CPUs Per Task | –cpus-per-task=[count] | ||||
| Job Dependency | –depend=[state:job_id] | ||||
| Job Project | –wckey=[name] | ||||
| Job host preference | –nodelist=[nodes] AND/OR --exclude=[nodes] | ||||
| Quality Of Service | –qos=[name] | ||||
| Job Arrays | –array=[array_spec] (Slurm version 2.6+) | ||||
| Generic Resources | –gres=[resource_spec] | ||||
| Licenses | –licenses=[license_spec] | ||||
| Begin Time | –begin=YYYY-MM-DD[THH:MM[:SS]] |