LMDZ en configuration parallèle (et un peu de descente d'échelle)
Sommaire
Principe de la parallélisation
Le parallélisme permet d’effectuer des opérations en simultané et donc de réduire les temps de calcul. Il s’oppose à un fonctionnement séquentiel dans lequel les opérations sont réalisées les unes à la suite des autres.
Les 2 types de parallélisation
Mémoire partagée
Principe de la mémoire partagée:
- Plusieurs processeurs travaillent sur une mémoire commune
- Programmable par OpenMP
Intérêt : prise en main facile, on n’a pas besoin de spécifier la distribution des données sur chaque processeur puisque tout le monde accède à l’ensemble des données. Il suffit seulement de définir les driectives du programme qui doivent être parallélisée (ce qui est déjà fait pour LMDZ). On peut voir ça comme une répartition des taches mais pas des ressources.
Mémoire distribuée
.
Principe de la mémoire distribuée:
- Chaque processeur accède à un espace mémoire qui lui est propre mais peut communiquer des informations aux autres processeurs.
Ex avec LMDZ : 2 processeurs travaillent respectivement sur un espace mémoire correspondant à l’hémisphère Nord et l’autre à l’hémisphère Sud, ils ont uniquement besoin de communiquer des informations à la frontière (Equateur) : mémoire distribuée.
- Programmable avec MPI.
- On peut voir ça comme un partage des taches et des ressources, les limites de performance résident dans le temps de communication des procésseurs entre eux.
- Par la suite nous allons lancer une configuration hybride qui permet de tirer le maximum des deux répartitions de la mémoire.
Lancement d’une configuration hybride
Création d’un repertoire pour notre configuration
mkdir LMDZ_para cd LMDZ_para
Gérer la mémoire et indiquer où se trouve la bibliothèque MPI
- La façon dont la mémoire doit être gérée est un sujet sensible et nous y reviendrons au moment où elle peut poser problème.
- Il faut renseigner l’emplacement de la bibliothèque MPI, pour trouver son emplacement on peut utiliser une commande comme : locate mpi
Une fois que le chemin est localisé :
ulimit -s unlimited export LD_LIBRARY_PATH=/where/your/mpi/lib/is/lib:$LD_LIBRARY_PATH
Exemple :
export LD_LIBRARY_PATH=/usr/lib/openmpi/lib:$LD_LIBRARY_PATH
Installation de LMDZ parallèle
- On télécharge le modèle sur le site du LMD via wget.
- On s’accorde ensuite le droit d’execution sur install_lmdz.sh avec la commande chmod
- On compile le modèle en modèle parallèle (-parallel), avec un parallélisme hybride (mpi_omp), sur une grille de départ 48x36x39 pour le banc d’essai
wget http://www.lmd.jussieu.fr/~lmdz/pub/install_lmdz.sh chmod +x install_lmdz.sh ./install_lmdz.sh -parallel mpi_omp -d 48x36x39
.
La sortie si tout va bien
Les messages surlignés en jaune sont des indicateurs du bon déroulement de notre installation, il est essentiel que le banc d’essai ait tourné et donc que le répertoire BENCH48x36x39 existe.
3.4 Mise en place d’une configuration personelle
On lance les commandes suivantes pour récupérer les fichiers nécessaires à la mise en place d’une configuration (voir: mandatory tutorial sur [[1]] pour plus d’informations) :
wget http://www.lmd.jussieu.fr/~lmdz/pub/Training/tutorial.tar tar -xf tutorial.tar cd TUTORIAL
Cette commande engendre la création d’un répertoire TUTORIAL dans lequel nous allons mettre en place une configuration personnelle. Dans cet exemple nous allons changer le nombre de points de grilles et passer de 48x36x39 à 72x36x39.
NB: le nombre de points de grilles selon x doit etre un multiple de 8 pour des raisons de filtrage.
On lance gedit init.sh et on modifie la valeur surligné en jaune. On peut remarquer qu’on tourne bien en configuration parallèle (via le parallel=1) mais aussi sans ORCHIDEE avec un modèle de sol simplifié (via le veget=0).
Modifions la grille
En changeant le pas de grille nous avons doublé la résolution selon x. Afin de nous assurer que nous respectons toujours le critère CFL nous allons doubler le nombre de pas de temps par jour par rapport à la valeur initiale du tutoriel qui est valable pour la résolution de base. Pour cela on lance :
cd DEF gedit gcm.def
.
Modifions le pas de temps
Si tout se passe bien init.sh va lancer la création de plusieurs répertoires :
- INITIAL : contient tous les fichiers nécessaires à l’execution du modèle comme limit.nc, start.nc, startphy.nc qui viennent d’être créés et qui sont respectivement les conditions aux limites, l’état initial de la dynamique et l’état initial de la physique. On peut également y trouver notre grille dans grilles_gcm.nc qu’on peut visualiser via Ferret :
use grilles_gcm.nc newline let rel=if (abs(grille_s-1) gt 0.5) then phis shade/pal=land_sea_values rel ; go land let deep=if (rel lt 0.1) then rel shade/pal=blue/o deep
- SIMU1: un répertoire pour lancer une simulation
- PROD0 : un répertoire très ressemblant à SIMU1 mais muni d’outils qui permettent de gérer automatiquement les conditions initiales quand on veut prolonger une simulation (enchaine.sh)
.
Sortie de init.sh si tout va bien
3.5 Execution via run_local.sh
A ce stade tout est près pour l’execution de notre simulation. Nous allons le faire via run_local.sh qui encapsule les commandes qu’on doit préciser pour faire tourner le modèle en prallélisme hybride.
En OpenMP il faut préciser le nombre de threads (équivalent au nombre de taches exécutées en simultanés) l’espace mémoire qu’on leur accorde.
En MPI il suffit de préciser le nombre de subdivions des taches.
Il faudrait donc écrire à chaque fois quelque chose comme :
export OMP_STACKSIZE=200M export OMP_NUM_THREADS=2 mpirun -np 3 ./gcm.e
Si on ouvre run_local.sh, on se rend compte que ces commandes sont dans le script et qu’il suffit de préciser leur valeur en argument de la fonction.
.
Le contenu de run_local.sh
La suite du script permet de rassembler les parties mémoire gérée de façon distribuée via la fonction rebuild.
On peut donc lancer l’éxecution en tapant :
./run_local.sh 2 2 gcm.e
Remarque : on peut vérifier que la parallélisation réduit les temps de calcul en remplaçant les 2 par des 1, ce qui revient à ne pas subdiviser les taches.
.
Sortie de run_local.sh si tout va bien
On a dit au début que la gestion de la mémoire était un sujet sensible et il est possible d’obtenir des erreurs à l’éxecution liée à la façon dont on gère la mémoire.
- Premier type d’erreur : mpirun noticed that process rank 0 with PID 0 on node newhydra exited on signal 11 (Segmentation fault).
- Deuxième type d’erreur : mpirun noticed that process rank 1 with PID 0 on node newhydra exited on signal 11 (Segmentation fault).
La façon de gérer ces erreurs n’est pas très claire, mais afin de les résoudre on peut essayer :
- fermer la session et relancer (la commande ulimit -s unlimited du début est ainsi oublié)
- ulimit -s 20000 : on peut essayer de donner une valeur en dur (par forcément 20 000)
- ulimit -Ss unlimited
