Merge branch 'main' of github.com:MesoNET/user-documentation

Author: barriost

README.md

@@ -22,4 +22,3 @@ L'adresse de la documentation est celle-ci : https://www.mesonet.fr/documentatio
 - on installe docusaurus : `cd mesodoc && yarn install` ou `cd mesodoc && npm install`
 - On édite ce que l'on souhaite
 - On construit le site et lance un serveur web localement pour le prévisualiser : `yarn serve` ou `npm run start`
-

docs/arch_exp/turpan/Actualité.md

@@ -9,16 +9,33 @@ Vous trouverez ici les dernières informations, annonces et mises à jour concer
 
 ---
 ## Dernières Nouvelles
+### 🔄 **Maintenance de Turpan** 
+**🗓️ <u>Date : 19 Novembre 2025</u>**
+
+Une maintenance Turpan aura lieu du **19 Novembre à 9h00** . Les nœuds seront de nouveau disponibles les uns après les autres dans la journée.
+:::caution  
+📌 **Indisponibilité du système**  
+Vos job seront suspendues pendant cette période, mais la machine restera accessible. 
+:::
+
+---
+### 💻➕ Environnement logiciel 
+L’environnement logiciel a été enrichi avec les modules :
+- [La dynamique moléculaire](./logiciels/dynamique_moléculaire.md): LAMMPS, GROMACS et AMBER sont désormais disponible. 
+- [Chdb](./logiciels/chdb.md): pour  embarrassingly parallel sur un grand nombre d’entrées indépendantes.
+- L'utile `placement` a été mis à jour pour permettre une surveillance continue comme suit : Ajoutez à votre commande l’option **`--rt`**, qui par défaut affiche les informations toutes les 1 seconde, ou **--rt=t**, qui affiche les informations sur l’utilisation des ressources du code intégrées sur un intervalle de temps t. Pour plus d’informations, consultez placement --help.
+
+
+##  Actualités Précédentes
+---
+### 💻➕ Environnement logiciel 
 L’environnement logiciel a été enrichi avec les modules suivants :
 
 - **MAQAO version 25.1.0**  est désormais disponible. Cette dernière version offre des outils améliorés pour l’analyse et l’optimisation des performances.
 
 - **SYCL avec AdaptiveCpp** pour ARM a été intégré avec succès, permettant une programmation hétérogène efficace et un meilleur support des plateformes basées sur ARM.
-
-
 ---
 
-##  Actualités Précédentes
 ### 🔄 **Mise à jour et maintenance de Turpan** ✅
 **🗓️ <u>Date : 31 mars - 3 avril 2025</u>**
 

docs/arch_exp/turpan/logiciels/chdb.md

@@ -0,0 +1,114 @@
+---
+title: Chdb
+sidebar_position: 1
+---
+
+Chdb est conçu pour exécuter en parallèle le même programme sur un grand nombre d’entrées indépendantes. Il s’adresse aux calculs dits « embarrassingly parallel », qui ne nécessitent aucune communication entre processus et ne font donc pas appel à MPI.
+## Les prérequis
+Il s’applique aux calculs ayant les caractéristiques suivantes :
+- Un exécutable séquentiel ou multithreadé est appliqué de manière répétitive sur un ensemble de fichiers d’entrée
+- Les noms des fichiers d’entrée se terminent tous par la même extension
+- Il n’y a pas de dépendance entre les différents traitements
+- Il n’y a donc pas de communication entre eux
+- Il est possible de lancer plusieurs instances de l’exécutable simultanément.
+
+## Les précautions à pendre
+
+:::danger Important
+chdb est un outil très puissant : s’il y a une erreur dans votre exécutable produisant des effets néfastes pour le système, en particulier des entrées-sorties intensives, ceux-ci seront démultipliés. La règle d’or est donc la suivante :
+
+AVANT DE LANCER UN EXÉCUTABLE AVEC chdb, VÉRIFIEZ QUE CELUI-CI FONCTIONNE CORRECTEMENT EN LE LANÇANT en "STANDALONE". Si le comportement de votre exécutable est correct, alors seulement vous pouvez envisager de l’utiliser avec chdb.
+:::
+
+## Initialiser l’environnement
+L’environnement doit être initialisé :
+>```shell
+> module load chdb/1.1 
+>```
+
+## La commande chdb
+
+chdb permet d’exécuter un programme présentant les caractéristiques ci-dessus sur un nombre arbitraire de processeurs et de nœuds.
+
+Lire la documentation `chdb --help`
+
+#### On **doit passer** les paramètres suivants :
+
+- `--in-dir` Le nom du répertoire dans lequel se trouvent les fichiers d’entrée. Ce répertoire doit exister
+- `--in-type` L’extension des fichiers que l’on considère comme fichiers d’entrée. Par exemple txt, pdb, etc.
+- `--out-files` Le nom du ou des fichiers créés par la commande, pour chaque exécution de la commande le nom est bien sûr différent, on utilise des "templates" qui seront remplacés avec le nom du fichier d’entrée. S’il y a plusieurs fichiers créés, leurs noms doivent être séparés par des virgules (,)
+- `--command-line` La ligne de commande utilisée. Il est possible de mettre un morceau de shell complet (une série de commandes séparée par des | par exemple). La seule restriction est que cette commande doit lire un fichier en entrée, écrire un ou plusieurs fichiers en sortie. La commande doit être mise entre guillemets, sinon elle sera interprétée par le shell
+- `--out-dir` Le nom du répertoire contenant les fichiers de sortie. Ce répertoire ne doit pas exister au démarrage de chdb
+
+#### On peut passer en outre les paramètres suivants :
+
+- `--work-dir` Avant d’exécuter la commande, chdb fera un chdir dans ce répertoire. Ce répertoire est souvent le même que --outdir, et les mêmes "templates" peuvent être utilisés.
+- `--create-environment` Vous pouvez entrer ici un "petit morceau" de code shell, qui sera exécuté après le chdir précédent et avant l’appel de la commande : cela vous permet par exemple de copier des fichiers d’entrée qui seraient obligatoirement présents dans le répertoire courant.
+- `--sort-by-size` Les fichiers présentés en entrée sont triés du plus gros au plus petit, si l’on fait l’hypothèse que le temps de traitement est proportionnel à la charge cela devrait permettre un meilleur équilibrage de la charge
+- `--block-size=10` Si on met 10 par exemple, cela signifie que les process mpi traitent les fichiers par blocs de 10. Cela permet de minimiser les communications lorsque le nombre de fichiers est important. S’il y a peu de fichiers, cette option risque par contre de générer un déséquilibrage de la charge.
+- `--in-files` Permet de ne traiter qu’une partie des fichiers du répertoire d’entrée
+
+#### En cas d’erreur dans la commande exécutée :
+
+Si la commande exécutée renvoie un code d’erreur (c’est-à -dire un statut différent de zéro), le comportement par défaut de chdb est d’arrêter tout traitement.
+
+On peut toutefois modifier ce comportement en spécifiant le paramètre `--on-error` : le nom des fichiers ayant provoqué une erreur est conservé, cela permet de relancer chdb (avec des paramètres différents).
+
+Pour cela, le paramètre `--in-files` sera utile car il permettra de ne relancer le programme que sur les fichiers d’entrée qui ont provoqué l’erreur.
+
+### Chdb dans un script slurm
+Dans cet exemple simple, un script Bash génère les fichiers d’entrée et le programme qui exécute le traitement correspondant à chaque entrée.
+
+>```shell
+> #create directories
+> mkdir -p ./chdb_test/input
+> mkdir -p ./chdb_test/dev_output   
+> cd ./chdb_test
+> #create 20 small input files
+>for i in $(seq -f "%02g" 1 20); do
+>  printf "This is file %s\n" "$i" > input/file_${i}.txt
+>done
+> # create a simple processing program (mon_programme)
+> # This program reads stdin (or a filename arg) and writes an output file.
+> cat > mon_programme.sh <<'EOF'
+> #!/bin/bash
+> # mon_programme.sh infile > outfile
+> infile="$1"
+> # simulate some work: sleep 0-2 seconds, print file contents with header
+> sleep $((RANDOM % 3))
+> echo "=== processed: $(basename "$infile") ==="
+> cat "$infile"
+> EOF
+> chmod +x mon_programme.sh
+> #test one run "standalone" (MANDATORY before using chdb)
+> ./mon_programme.sh input/file_01.txt > dev_output/file_01.out
+> cat dev_output/file_01.out
+>```
+
+Ce script Slurm permet de lancer le code sur tous les fichiers d’entrée.
+```
+#!/bin/bash
+#SBATCH -J chdb_example
+#SBATCH -N 1
+#SBATCH -n 3
+#SBATCH --ntasks-per-node=3
+#SBATCH --ntasks-per-core=1
+#SBATCH --time=00:30:00
+#SBATCH --output=chdb.out
+
+module purge
+module load chdb/1.1
+
+
+# IMPORTANT: ensure out directory does NOT exist
+rm -rf out_slurm
+mpirun chdb \
+  --in-dir ./chdb_test/input \
+  --in-type txt \
+  --out-dir ./chdb_test/out_slurm \
+  --out-files %out-dir%/%path% \
+  --sort-by-size \
+  --command "./mon_program.sh %in-dir%/%path% > %out-dir%/%path%"
+```
+
+Les variables `%in-dir%/%path%` et `%out-dir%/%path%` correspondent aux chemins d’entrée et de sortie définis précédemment dans la commande par (`--out-dir`, `--in-dir`) ; elles seront détectées automatiquement.

docs/arch_exp/turpan/logiciels/dynamique_moléculaire.md

@@ -0,0 +1,119 @@
+---
+title: La dynamique moléculaire
+sidebar_position: 12
+---
+
+Les modules disponibles sont:
+- LAMMPS
+- GROMACS
+- AMBER
+
+## LAMMPS
+LAMMPS (Large-scale Atomic/Molecular Massively Parallel Simulator) est un logiciel de dynamique moléculaire hautement parallélisé, conçu pour simuler des systèmes atomiques, moléculaires ou mésoscopiques. Il est particulièrement utilisé pour la modélisation des matériaux, des polymères, des métaux et des fluides complexes.
+
+« Il y a deux modules disponibles : l’un avec GNU-CUDA et l’autre avec le support de Kokkos. »
+
+```
+#!/bin/bash
+#SBATCH -J lammps-run
+#SBATCH -N 1
+#SBATCH -n 2
+#SBATCH --gres=gpu:2
+#SBATCH --cpus-per-task=1
+
+export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
+export OMP_PROC_BIND=close
+```
+#### Kokkos GPU-MPI
+
+```
+module purge
+module load lammps/lammps_kakos
+mpirun -np ${ntasks} --mca pml ucx -x UCX_NET_DEVICES=all --map-by ppr:80:node:PE=$SLURM_CPUS_PER_TASK --bind-to core lmp -k on g 2 -sf kk -pk kokkos -in in.file
+
+```
+
+#### GNU-CUDA
+```
+module purge
+module load lammps/lammps_gnu_cuda
+```
+Il existe plusieurs façons d’exécuter le programme ; vous pouvez en choisir une parmi les suivantes
+```
+# MPI
+mpirun -np $SLURM_NTASKS --mca pml ucx -x UCX_NET_DEVICES=all --map-by ppr:80:node:PE=$SLURM_CPUS_PER_TASK --bind-to core lmp -in in.file
+```
+```
+# MPI OMP (lmp -sf omp )
+mpirun -np $SLURM_NTASKS --mca pml ucx -x UCX_NET_DEVICES=all --map-by ppr:80:node:PE=$SLURM_CPUS_PER_TASK --bind-to core lmp -sf omp -in in.file
+```
+```
+# GPU cuda (lmp -sf gpu )
+export CUDA_VISIBLE_DEVIES=0,1
+mpirun -np $SLURM_NTASKS --mca pml ucx -x UCX_NET_DEVICES=all --map-by ppr:80:node:PE=$SLURM_CPUS_PER_TASK --bind-to core lmp -sf gpu -in in.file
+```
+
+
+## GROMACS
+GROMACS est un logiciel open source spécialisé dans la dynamique moléculaire, principalement utilisé pour l’étude des biomolécules comme les protéines, les lipides et les acides nucléiques. Il est reconnu pour sa rapidité et son efficacité sur les architectures parallèles, notamment les GPU.
+
+```
+#!/bin/bash
+#SBATCH --job-name=gmx_mpi_gpu
+#SBATCH --nodes=1
+#SBATCH --ntasks-per-node=16
+#SBATCH --gres=gpu:2
+#SBATCH --cpus-per-task=4
+#SBATCH --time=00:30:00
+#SBATCH --partition=small
+#SBATCH -o gmx_%j.out
+#SBATCH -e gmx_%j.err
+
+# Chargement des modules
+module purge
+module load gromacs/2024.6
+
+source $GMXRC
+
+# Commande MPI explicite
+mpirun -np $SLURM_NTASKS \
+    --hostfile hosts.txt \
+    --map-by ppr:$SLURM_NTASKS:node:PE=$SLURM_CPUS_PER_TASK \
+    --bind-to core \
+    gmx_mpi mdrun \
+        -s benchPEP.tpr \
+        -deffnm benchPEP \
+        -ntomp $SLURM_CPUS_PER_TASK \
+        -nb gpu \
+        -pin on -v
+```
+:::danger Important
+N'oubliez pas `source $GMXRC` 
+:::
+
+:::tip Note
+Si vous lancez un calcul sans `mpirun`, et que vous ne définissez pas `--cpus-per-task` ou `OMP_NUM_THREADS`, le programme utilisera alors 80 threads
+:::
+
+## AMBER
+AMBER (Assisted Model Building with Energy Refinement) est un ensemble de programmes destinés à la simulation de biomolécules par dynamique moléculaire. Il repose sur des champs de force précis et est couramment employé en chimie computationnelle et en biophysique pour l’étude des interactions et de la stabilité des systèmes biologiques.
+
+```
+
+#!/bin/bash
+#SBATCH -N 1
+#SBATCH -n 2
+#SBATCH --gres=gpu:2
+#SBATCH -p small
+#SBATCH --ntasks-per-node=2
+
+module purge
+module load amber/gnu/25
+source $AMBERSH
+
+mpirun -n 2 pmemd.cuda_SPFP.MPI -O -i mdin5 -o overall_output.out -p sys.prmtop -c sys4.rst  -inf mdinfo5 -x sys4rot5.mdcrd
+
+```
+:::danger Important
+N'oubliez pas `source $AMBERSH` 
+:::

docs/arch_exp/turpan/soumettre_calcul/MIG.md

@@ -0,0 +1,78 @@
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+Les GPU A100 sont puissants, mais parfois une application n’a pas besoin de toute la capacité du GPU. La technologie MIG (Multi-Instance GPU) de NVIDIA permet de partitionner un seul GPU en plusieurs instances plus petites, chacune avec sa propre mémoire, ses cœurs et ses ressources de calcul dédiées.
+
+L’utilisation de MIG améliorera l’efficacité de la machine et réduira aussi [votre consommation d’heures](../accounting/accounting-rules.md) au lieu d'utiliser Shared ou Full nœud.  
+
+:::info
+Pour savoir si votre application doit utiliser un MIG ou non, essayez-la d’abord sur un GPU complet et utilisez `placement` pour observer l’utilisation du GPU ``` placement --jobid={your_job_id} ``` qui permet de voir l’utilisation du GPU et de la mémoire, sachant qu’un GPU complet dispose de 80 Go de mémoire.
+:::
+
+
+## À propos de MIG sur Turpan
+Il existe 2 types d’instances MIG sur Turpan :
+#### 3g.40gb
+Cela représente environ 57 % d’un GPU A100 complet. À prendre en compte dans cette configuration :
+- Le nombre de cœurs CPU disponibles sur cette configuration est `20 cores` 
+- La mémoire disponible est `40 GB`
+#### 2g.20gb
+Cela représente environ 40 % d’un GPU A100 complet. À prendre en compte dans cette configuration :
+- Le nombre de cœurs CPU disponibles sur cette configuration est  `10 cores` 
+- La mémoire disponible est `20 GB`
+
+## Quand utiliser MIG
+Après avoir exécuté votre code une première fois sur un GPU complet, utilisez placement pour analyser l’usage du GPU.
+- Si votre **code utilise entre 50 % et 35 %**, moins de 20 cœurs et moins de 40 Go de mémoire, utilisez **`3g.40gb`**
+    - Si votre code a besoin de plus de 40 Go ou de plus de 20 cœurs, restez sur le GPU complet.
+- Si votre **code utilise moins de 35 %**, 10 cœurs et moins de 20 Go de mémoire, utilisez **`2g.20gb`**
+    - Si vous avez besoin de plus de 10 cœurs mais moins de 20, ou de plus de 20 Go de mémoire mais moins de 40 Go, suivez les indications de la configuration `3g.40gb`. 
+
+:::caution
+MIG est utilisable uniquement si votre application n’a besoin que d’un seul GPU.
+:::
+
+## Comment utiliser MIG
+
+<Tabs>
+  <TabItem label="3g.40gb" value="3g.40gb" >
+
+>```
+>#!/bin/bash
+>#SBATCH -N 1
+>#SBATCH -n 20
+>#SBATCH --gres=gpu:3g.40gb 
+>#SBATCH -p 3g.40gb
+>
+>module purge
+>module load gnu/11.2.0
+>module load openmpi/gnu/4.1.4-gpu
+>
+>mpirun -n 20 ./exec
+>```
+
+  </TabItem>
+  
+  <TabItem label="2g.20gb" value="2g.20gb" >
+
+>```
+>#!/bin/bash
+>#SBATCH -N 1
+>#SBATCH -n 10
+>#SBATCH --gres=gpu:2g.20gb 
+>#SBATCH -p 2g.20gb
+>
+>module purge
+>module load gnu/11.2.0
+>module load openmpi/gnu/4.1.4-gpu
+>
+>mpirun -n 10 ./exec
+>```
+
+  </TabItem>
+</Tabs>
+
+:::danger Important
+- Impossible d’utiliser plus d’une instance MIG par job.
+- Évitez l’option --gpus-per-task, car elle considère automatiquement un GPU complet.
+:::