J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Ateliers de Modélisation de l'Atmosphère 2011 Adaptation de Méso-NH aux Architectures Massivement Parallèles Pétaflopiques Juan Escobar Laboratoire d'Aérologie, CNRS et Université de Toulouse III 8-10 Février 2011 CIC de Météopole à Toulouse

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Le Défi du Massivement Parallèle Pétaflopique – Rappel Aujourd'hui : METEO-FRANCE/NEC-SX9 = 102 GFLOPS * 160 proc. = PFLOPS IDRIS/IBM-BG/P = 3.4 GFLOPS * cores = PFLOPS CINES/SGI-ICE = 12 GFLOPS * cores = PFLOPS – Demain matin /PRACE ( 2011) : JÜLICH(DE)/IBM-BG/P = 3.4 GFLOPS * cores = 1.0 PFLOPS CCRT/CEA/BULL-X = 18.6 GLFOPS * cores = 1.5 PFLOPS – Après demain (2012) : IBM BleueGene/Q = cores = 20 PFLOPS

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Le Modèle de Recherche Méso-NH – Un développement conjoint CNRS Météo-France Modèle non hydrostatique pour traiter une vaste gamme de phénomènes atmosphériques de 1000 km au mètre jeu complet de paramétrisations physiques, dont nuages, turbulence et rayonnement couplé au modèle de surface SURFEX configuration en cas idéalisés 1D, 2D, 3D et cas réel avec capacité d’imbrication pour descente en échelle chimie et aérosols en phase gazeuse et aqueuse bilan, traceurs, opérateurs d’observation (sat, radar, GPS) – Parallélisation F90 + MPI = 1million de lignes de codes 100% vectoriel ARRAY SYNTAXE ( presque pas de boucle ) Décomposition de Domaine 2D X*Y, Z complet Point Difficile, Solveur de Pression Équation Elliptique à inverser – Préconditionneur FFT3D + Méthode Gradient Conjugué – WEB : Version courante PACK-MNH-V4-8-4 – Reproductible au bit prêt en parallèle

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Méso-NH est-il prêt pour le Calcul Pétaflopique ? On y travaille!

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Benchmark sur Cas Idéalisé – Courant 2008 efforts de développement/portage de Méso-NH sur les nouvelles plateformes massivement parallèles du GENCI – Avant solveur de pression : décomposition de domaine en 2 dimensions X*Y nombre de processeurs maximum = min (dimX, dimY )‏ grille 512x512x128 → 512 processeurs max B-Splitting FFT-XFFT-Y transposition

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Benchmark sur Cas Idéalisé – Après // en Z : décomposition de domaine en 3 dimensions grille 512x512x128 → 128*512 = processeurs B-SplittingFFT-X/Z FFT-Y/Z transposition Z-substitution

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Benchmark sur Cas Idéalisé – Premières simulations Idéalisées de Méso-NH grille allant jusqu'à 4906x4096x128 points Soit 2 milliards de points de grille 1 Fichier d'entrée = 177 GO ( x2 en sortie ) cores sur JADE SGI/ICE (CINES) cores sur BABEL IBM/BGP (IDRIS) pour la première fois une performance soutenue de plus de 1 Téraflops pour Méso-NH

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Méso-NH(début 2009) : 1 TFLOPS / 8K-16K cores

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Parallélisation des I/O – Avant dans Méso-NH : un seul processeur gère les I/O (Entrées/Sorties) lit et écrit les champs 3D au format LFI Cas test idéal 4096x4096x128 pts => 1 Fichier d'entrées Méso-NH = 177 GO ( x2 pour les sorties ) – Benchmark IOR: Tout type I/O //, Posix, N fichiers, P-Netcdf, HDF5, MPI-I/O Test de MPI-I/O sur le même filesystem « $WORKDIR » : – sur VARGAS = 5000 MO/sec – Sur BABEL = 50 MO/sec Conclusion: performance non « portable » – Benchmark : IOMPI = F90 + I/O accès direct * N fichiers – 7000 MO/sec quelle que soit la machine – Solution retenue ( en attendant mieux … ) – Après parallélisation des I/O dans Méso-NH 1 Proc IO * 1 champ 3D → parallélisation par NZ proc. IO * 1 champ 2D, ( toujours fichiers LFI ) réduit de 2 ordres de grandeur la taille des buffers alloués pour les I/O ( très important pour BG/P 512MO de mémoire/proc. ) Compilation en INTEGER*8 de LFI pour dépasser la taille de 16GO par fichier – Performance d'écriture d'1 fichier LFI sur PREP_IDEAL_CASE 1proc. IO → 100 MO/sec 128 proc. IO et 1024 processeurs → 1800 MO/sec

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ PREP_IDEAL_CASE( mi 2009 ) 1.8 GB/sec sur 128 Fichiers

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Cas Réel Problème de la montée en résolution => Obligation de « penser tout parallèle » Nécessité de paralléliser toute la filière Méso-NH Du pré-processing : – PREP_REAL_CASE génération de grille initiale avec champs météorologiques 3D au delà de 512x256x70 points – PREP_PGD génération de grille avec champs de surface 2D au delà de 2000x2000 points Au post-processing : – Intégration dans l'outils DIAG ( déjà parallèle ) des traitements « ad-hoc » pour générer des sortie 2D pré-traité. – Visualisation 3D : en test Paraview / Visit

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Méso-NH ( fin 2009 ) Cas Réél a 4KM Atlantique Nord : Cyclone HELENE 2006 Grille 3072*1532*64 pts = 300 Millions Pts

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Méso-NH ( fin 2009 ) Cas Réél a 4KM

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Cas Réel 4KM => 2KM & 1KM – Grille visée Échelle kilométrique, Sur l'Atlantique Nord soit x Kilomètres. 4KM de Résolution Horizontale Minimum pour une représentation explicite des nuages ( Cloud Resolving Model ) 4KM « zone grise » => Idéale 2KM voir 1 KM – MESONH : Grille 4KM sur JADE2 pour 1 seconde calcul / 1 seconde simulée 4096x4096x128 pts 1 fichier 177GO 4096 cores 4 TO Mem. Glob. Pour garder 1 seconde calcul 1 seconde simulée – Si on accroît d'un facteur 2 la résolution kilométrique – => * 4 en taille mémoire & IO – => * 8 temps de calcul => * 8 nombre cores de calcul Extrapolation sur CURIE/BULL-X ( ou MIRA / BG/Q )

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Méso-NH est-il scalable au delà de 16K-cores ?? – Sur Babel ( IDRIS/BG/P ) run à 16K cores OK Plantage « CPU LIMIT » à 32K cores – Début 2010 : PROJET d'accès au prototype PRACE JUGENE 1 Million d'heures pour essayer d'étendre la scalabilité de Méso-NH au delà de 100 K cores – JUGENE/IBM-BG/P 3.4 GFLOPS * cores = 1.0 PFLOPS

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Méso-NH est-il scalable au delà de 16Kcores ?? Boite à Outils Pétaflopique Indispensable Pour l'Analyse de Performance – Outils d'analyse de performance : Scalasca Runs Méso-NH comparatif de 4K, 8K et 16 K cores Etude de l'impact du MAPPING et des SHAPE Identification de goulots d'étranglement imprévus – Utilisation de Benchmark HelloWord – A cores 32 minutes pour boot la partition heures juste pour démarrer l'application... Librairie P3DFFT – pour tester la scalabilité des FFT3D jusqu'à 128K cores Résultats : optimisation de Méso-NH Implémentation des communications MPI_ALLTOALLV – Implémentation BG/P 3 fois plus rapide que MPICH Placement « optimisé » des processus.

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Méso-NH est-il scalable au delà de 16Kcores ?? Boite a Outils Pétaflopique Indispensable Pour le Codage / Debuggage – Aller retour permanent PC-Linux Cluster Local Centre Nationaux Tier 0 – Debuggage interactif Totalview Jusqu'à 4K cores sur BABEL – Débogage Post mortem coreprocessor.pl Jusqu'à 128K cores sur JUGENE ( aucun problème jusqu'à 64K cores !!! Problème I/O MPI_SEND bloquant )

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Travaux Pratique sur JUGENE Les outils Pétaflopiques en Action

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Scalasca 32K cores JUGENE P3DFFT : MAPPING = S2X2X4 TXYZ

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Scalasca 32K cores JUGENE P3DFFT : MAPPING = S2X2X4 ZYXT

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Coreprocessor 64K cores JUGENE : Problème d'I/O ( encore ! ) manque de mémoire !!

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Debuggage Aller Retour PC Cluster Local Centre National Tier 0

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ ;-) Enfin Méso-NH sur 128K cores

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Méso-NH ( mi 2010) JUGENE/BG/P : 4.3 TFLOPS / 128K cores MPI_ALLTOALLV

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Conclusion Scalabilité de Méso-NH démontré jusqu'à cores Utilisation en routine sur 4096 cores: – voir présentation de Florian Pantillon : Mercredi 16h30 Modélisation Méso-NH semi-hémisphérique à résolution kilométrique : transition extra-tropicale de l'ouragan Hélène 2006 Prospective – Runs a 2KM & 1KM sur CURIE – Calcul sur Carte Graphique – Solveur Multi-grilles

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ WHAT ELSE?

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Après Demain ? – Calcul sur Carte Graphique Premier prototype de machine disponible au CCRT et GENCI Attente de compilateur FORTRAN90 – Première « offre » HMPP PGF90

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ GPU : PGI + ACC directive Schéma d'Advection PPM Directive distribution donnée !$acc data Directive parallélisation !$acc region

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ GPU : PGI + ACC directive Schéma d'Advection PPM Temps d'exécution sur CPU(Néhalem)

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ GPU : PGI + ACC directive Schéma d'Advection PPM Temps d'exécution sur GPU( Fermi GTX470 )

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ ;-) vers L'infini et Au delà Modélisation des Temps Communication FFT3D – Modélisation des temps de communication des FFT3D sous la forme TCOM(NB_PROC,GRID_SIZE) = NITR( TS * NB_PROC**(0.5+S1) + TW * ( GRID_SIZE /( NB_PROC**(1.0-S2) ) ) ) où NB_PROC = nombre de processeurs GRID_SIZE = nombre de points dans la grille = DIMX*DIMY*DIMZ NITR = nombre d'itérations du solveur TS = Latence du résau = temps d'envoi du premier octet TW = vitesse du réseau = 1/ ( bande passante ) – Réseau non idéal 2 paramètres de saturations S1 = Paramètre Saturation Latence S2 = Paramètre Saturation Bande Passante

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Modélisation Temps Communication FFT3D Grille <= 4KM

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Temps Communication FFT3D Extrapolation Grille = 2KM & 1KM

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Temps Communication FFT3D Extrapolation Grille = 2KM & 1KM BLUEGENE/Q MIRA 768Kcores

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Problème PREP_PGD – PREP_PGD OK – à 3072x1536X64 pts à 4KM – Problème avec les interpolations au delà de cette taille => Grille à 2 KM !!

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Méso-NH Solveur Pression

J.ESCOBAR LA/CNRS/UPS || AMA 8- 10/2/ Méso-NH JADE/CINES TITANE/CEA/CCRT