Le point sur la parallélisation du couplé Adapter les codes aux architectures multiprocesseurs des futures machines afin d’améliorer les temps de restitution.

Présentation au sujet: "Le point sur la parallélisation du couplé Adapter les codes aux architectures multiprocesseurs des futures machines afin d’améliorer les temps de restitution."— Transcription de la présentation:

1 Le point sur la parallélisation du couplé Adapter les codes aux architectures multiprocesseurs des futures machines afin d’améliorer les temps de restitution des simulations. Simulation sur de plus longues durées, accession à de plus fines résolutions. Objectif : mise en production d’une version parallèle de l’ensemble du modèle couplé pour l’arrivée de la nouvelle machine de l’IDRIS (probablement en juin 2006). Technologie employée : communication interprocessus à l’aide de la librairie MPI (Message Passing Interface).

2 Etat d’avancement LMDZ 4 : partie dynamique + partie physique. Parallélisation terminée, phase d’intégration CVS (L. Fairhead). A terme : - une dynamique séquentielle + une dynamique parallèle. - une partie physique commune. LMDZ4 // + OASIS3 + OPA8 séquentiel : OK, attente d’un test // avec OPA 9. ORCHIDEE : Parallélisation terminée, phase d’intégration CVS (M. Mancip). Fonctionne en mode forcé et en couplé (LMDZOR). INCA : NMHC + AER (119 traceurs) Parallélisation quasi complète, phase de déboggage. Intégration CVS dans quelques semaines (A. Cozic).

3 Distribution des données sur chaque processus LMDZ 4 : partie dynamique Resserrement des mailles aux pôles : non respect de la condition CFL. Divergence des champs. Application d’un filtre (de type FFT) pour supprimer les fluctuations de courtes longueurs d’onde. Filtre appliqué sur les 1/6 de la région des pôles soit 1/3 de la surface globale. Très pénalisant en temps de calcul, appelé à chaque calcul faisant appel à un opérateur différentiel (caldyn et dissip). Difficulté pour découper le domaine en longitude. Découpage uniquement en lattitude. Grille dynamique grille iim x jjm sur llm niveaux verticaux

4 PROCESS 0 PROCESS 1 PROCESS 3 Répartition des données par process PROCESS 2 pôle nord pôle sud latitude longitudes

5 Communication MPI des halos à chaque itération (ou plus). Répartition de la charge. A cause du filtre, les processeurs aux pôle travaillent beaucoup plus qu’à l’équateur  on diminue la répartition des domaines aux pôles pour l’augmenter à l’équateur. Chaque routine ( caldyn, vanleer et dissip ) a sa propre répartition optimale. Rééquilibrage dynamique pour chacune des routines. Procédure d’ajustement pour déterminer l’optimum.

6 LMDZ4 – partie physique, ORCHIDEE, INCA Sur la grille physique, les points géographiques sont localement indépendants. On distribue à chaque processus un vecteur de point géographique (incluant la colonne atmosphérique pour INCA et LMDZ). Ne nécessite pas de communication interprocessus à de rare exception près : Accès IO Diagnostiques globaux Interface du couplé, routage de l’eau (ORCHIDEE)… Gestion des IOs Fichiers d’initialisation et de restart : lus par le processus maître qui distribue ensuite les données aux autres processus. Fichiers d’historique (histwrite) : chaque processeur écrit dans son fichier local. Reconstruction d’un fichier unique par post-traitement (outil rebuild, J. Bellier).

7 Ce qui va changer Coté utilisateur : (presque) rien Lancement de l’exécutable :./gcm.e => mpirun –np N./gcm.e Reconstruction des fichiers histoire : rebuild –o histday.nc histday_00[0-n].nc Coté développeur Éviter les corrélations entre les points géographiques sur la grille physique. Prudence lors de la réalisation de diagnostiques globaux ou des moyennes zonales. Prudence lors de la lecture ou l’écriture de fichiers (excepté pour histwrite) Nécessite des communications.

8 Quelques performances : LMDZ4 // sur NEC SX6 Résolution 96x72x19 1 processus2 processus4 processus8 processsus Temps CPU 255 s134 s79 s50.1 Scalabilité 11.903.235.1 Mémoire 720 Mo1.14 Go1.76 Go3 Go GFlops 1.983.616.059.12 % Vectorisation 98.12 %98.03 %98.01 %97.62 % Résolution 192x144x19 1 processus2 processus4 processus8 processsus Temps CPU 812 s422 s245 s135 s Scalabilité 11.923.315.98 Mémoire 2.27 Go3. Go4.31 Go6 Go GFlops 2.274.37.412.5 % Vectorisation 98.5 % 98.4 %98 %

9 Perspectives : A court terme, finaliser complètement l’intégration CVS de l’ensemble des codes du modèle couplé. Optimisation des modèles : amélioration de la parallélisation et de la vectorisation. Phase de benchmark afin de déterminer les performances et la scalabilité des codes sur différentes architectures matérielles. Ajout d’un niveau parallélisation supplémentaire en OpenMP (en mémoire partagée) sur les niveaux verticaux de la dynamique.  Objectif à terme : parallélisation mixte MPI/OpenMP Facteur 3 en speed-up attendu en plus des gains MPI. Facteur 6 si doublement des niveaux verticaux. Objectif : atteindre des speed-ups de 20 sur une trentaine de procs. sur les futures grilles standards (ex : 192x144x50). Pour INCA : ajouter un niveau de parallélisation sur l’advection des traceurs.