L’arrivée des versions parallèles des modèles de l’IPSL Adapter les codes aux architectures multiprocesseurs des futures machines afin d’améliorer les.

Présentation au sujet: "L’arrivée des versions parallèles des modèles de l’IPSL Adapter les codes aux architectures multiprocesseurs des futures machines afin d’améliorer les."— Transcription de la présentation:

1 L’arrivée des versions parallèles des modèles de l’IPSL 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. Codes plus complexes (ex : ESM) Parallélisation des codes LMDZ4, ORCHIDEE et INCA (+adaption OASIS 3 ). Objectif : mise en production d’une version parallèle de l’ensemble du modèle couplé pour l’arrivée de la nouvelle machine vectorielle de l’IDRIS. Version de test d’un couplé LMDZ4/ORCHIDEE/OPA vers mi-juillet

2 Les grandes lignes sur la parallélisation des codes Chacun des processeurs effectue les calculs sur une partie des données. Communication inter-processus : distribution des tâches, échange de données et synchronisation. Technologie employée : communication interprocessus à l’aide de la librairie MPI (Message Passing Interface). Implémentation de la parallélisation : 2 parties distinctes : Partie dynamique de LMDZ4 : beaucoup de communications et d’échanges de données entre processus sur des échelles de temps très courtes. Partie physique de LMDZ4, ORCHIDEE et INCA : données localement indépendantes, peu de communications.

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 plusieurs fois par itération (pas de temps). Problème 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. Répartition de la charge. 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. Génération automatique d’un fichier d’ajustement pour une résolution et un nombre de processus donné, réutilisable pour les simulations suivantes.  Ex : Résolution 96x72x19 sur 4 processus : Bands_96x72x19_prc.dat

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. Nécessité de la réalisation d’une documentation

8 Etat d’avancement et calendrier LMDZ 4 : partie dynamique + partie physique. Parallélisation terminée. Phase d’intégration dans la version LMDZ4 V3 //. A terme : - une dynamique séquentielle + une dynamique parallèle. - une partie physique commune parallèle. Version finalisée début juillet. LMDZ4 // + OASIS3 + OPA8 séquentiel : OK, tests concluants avec la pré-version. Version finalisée avec LMDZ4 V3 vers mi-juillet. ORCHIDEE (et LMDZOR) : Parallélisation terminée Phase d’intégration CVS (M. Mancip) => ORCHIDEE 2.0 //. Fonctionne en mode forcé et en couplé (LMDZOR). Version finalisée vers mi-juillet.

9 LMDZOR/OPA Pas encore testé. Mi-juillet ? INCA : NMHC + AER (119 traceurs), CH4. Parallélisation terminée. Phase d’intégration CVS et merge des versions (A. Cozic). Version finale : fin Septembre. Tests et validation scientifique : courant de l’été. Cours et documentation : prévus pour l’automne. Vers le ESM // : date : ???

10 Perspectives à court terme : 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 processeurs vectoriels sur les futures grilles standards (ex : 192x144x50). Pour INCA : ajouter un niveau de parallélisation sur l’advection des traceurs.