Portage du modèle climatique de surface continentale de l'ipsl. sur une grappe de serveurs XD1

BERNARDO Frederic Master 2 Physique et Applications CCI Université Paris XI Orsay (91) Portage du modèle climatique de surface continentale de l'ipsl sur une grappe de serveurs XD1 Différences de température entre les années 2000 et 2070 selon deux scénarios de l'ipcc, a2 (gauche) et b2 (droite) IPCC 2001 Stage de Master 2 Professionnel Compétences Complémentaires en Informatique sous la direction de M. Mancip et Y. Meurdesoif à l'institut Pierre Simon Laplace (IPSL Jussieu) 1 / 42 Avril Août 2006

2 / 42

Remerciements Martial Mancip, Yann Meurdesoif, Sébastien Denvil, Patrick Brockmann, Abderrahmane Idelkadi, Jacques Lefrère, Marie Angèle Filiberti, Marie Alice Foujols, Patricia Cadule, Olivier Marti, Armella Longrez, Mina Melloulchi, Laurent Fairhead, Laurent Bourdette, les membres du LMD, du LSCE, du SA et de l'ensemble de l'ipsl Michel Krawczyk, Stéphane Rohrbach, François Gueudet, les membres du CCRE de Jussieu Denis Girou, Patrick Corde, les membres de l'idris 3 / 42

Table des matières Remerciements 3 1.Présentation du stage 6 1.1.Présentation des organismes d'accueil 1.2.Le modèle climatique de l'ipsl :IPSL CM4 1.3.Présentation du calcul parallèle a)du séquentiel au parallèle b)le supercalculateur parallèle du CCRE : le XD1 2.La parallélisation du modèle climatique de surface continentale ORCHIDEE 7 8 9 10 10 12 2.1.Le fonctionnement des modèles climatiques de l'ipsl 12 2.2.Le calcul parallèle 15 2.3.La parallélisation d'orchidee 17 a)le modèle climatique global b)le modèle climatique de surface continentale ORCHIDEE c)les fichiers externes utilisés par ORCHIDEE a)les caractéristiques du calcul parallèle b)les différences entre le calcul distribué et le calcul partagé c)l'utilisation d'une implémentation de directives parallèles : MPI a)les principes de la répartition des calculs a)une répartition des charges évolutive b)une parallélisation néanmoins incomplète 3.Après la parallélisation 12 12 14 15 16 17 17 18 20 20 3.1.Différentes versions possibles pour ORCHIDEE_OL 3.2.Les principaux problèmes rencontrés 3.3.Un modèle en constante évolution 20 20 21 3.4.Fiabilisation et portabilité de la version parallèle 21 a)évolutions disjointes des versions parallèles séquentielles b)l'environnement des modèles de l'ipsl 4.Protocole de test 21 21 23 4.1.Les critères de test 23 4.2.Les caractéristiques utilisées pour l'évaluation des performances 4.3.La mise en oeuvre sur le XD1 4.4.La récupération des résultats 24 24 26 a)les entrées sorties b)l'influence du nombre de processus et des options de compilation 4 / 42 23 23

5.Résultats et analyse 26 5.1.Les options de compilation et le nombre de processus 5.2.Les entrées sorties 6.Conclusions et perspectives 26 29 31 6.1.Bilan de la parallélisation 6.2.Les bénéfices apportés par le récent supercalculateur XD1 du CCRE 6.3.Les critères déterminants pour l'optimisation des calculs d'orchidee 31 31 31 Annexes 33 Glossaire 40 Bibliographie 42 5 / 42

1. Présentation du stage Médiatisé par le protocole de Kyoto en 1997, le réchauffement climatique est lié selon la majorité scientifique en partie à l'activité humaine, notamment sa production en gaz à effet de serre. Pour confirmer cette théorie, ont été mises en place des simulations du climat, visant également à prévoir ses évolutions futures. L'IPSL (Institut Pierre Simon Laplace), par le biais de son pôle modélisation, possède un modèle climatique global, permettant de mettre en évidence l'évolution climatique selon de nombreux paramètres, notamment l'activité anthropique et la nature des gaz émis par les activités humaines. Reposant sur l'exploitation des données recueillies, le modèle climatique de l'ipsl nécessite des ressources informatiques importantes et de plus en plus coûteuses. Les supercalculateurs sur lesquels s'exécutent ce type de simulation se tournent d'ailleurs de plus en plus vers les technologies de calculs parallèles : une mise en commun de plusieurs systèmes, pas forcément identiques, chaque système s'octroyant une partie de la charge. Ce type d'architecture, s'appuyant sur des technologies de communication entre les systèmes, se révèle incontournable, mais requiert la parallélisation du code exécuté, une mise en oeuvre plus ou moins complexe qui demande des compétences informatiques spécifiques. La parallélisation de LMDz (modèle de circulation générale atmosphérique du Laboratoire de Météorologie Dynamique) et d'orchidee (ORganizing Carbon and Hydrology In Dynamic EcosystEms), composantes du modèle climatique global de l'ipsl, est réalisée depuis l'été 2005 par Y. Meurdesoif, ingénieur LSCE (Laboratoire des Sciences du Climat et de l'environnement). S'appuyant sur MPI (Message Passing Interface), les modèles parallèles de l'ipsl sont ainsi capables de tirer parti des architectures des supercalculateurs parallèles, notamment la grappe de serveurs XD1 (Cray), récemment installée au CCRE (Centre de Calcul Recherche et Enseignement) à l'upmc (Université Pierre et Marie Curie). En intégrant l'équipe ORCHIDEE au sein de l'ipsl, j'ai été amené à assurer le débogage de la version parallèle de ce modèle, à en finaliser la parallélisation et à y intégrer certaines évolutions des nouvelles versions séquentielles, introduites récemment. J'ai ensuite effectué le portage de la composante terrestre du modèle global sur le XD1. Cela m'a permis de tester les performances du modèle parallèle et de ses variantes possibles, dans les conditions réelles de fonctionnement. Enfin, l'analyse des résultats obtenus m'a permis de dégager les caractéristiques les plus déterminantes sur les performances de la version parallélisée du modèle. Dans la suite de cette introduction seront présentés l'ipsl qui m'a accueilli ainsi que les différents organismes qu'il m'a été amené de côtoyer à travers mon stage. Une brève description des modèles climatiques IPSL CM (modèle climatique couplé) sera ensuite abordée. 6 / 42

1.1.Présentation des organismes d'accueil L'Institut Pierre Simon Laplace (IPSL) regroupe près de 40% du dispositif national de recherche du CNRS et des universités dans le domaine des sciences de l'océan et de l'atmosphère, soit quelques 750 personnes (environ 250 chercheurs et enseignants chercheurs, 250 ingénieurs, techniciens et agents administratifs et 250 doctorants, post doctorants et stagiaires) réparties dans cinq laboratoires : le Centre d'étude des Environnements Terrestre et Planétaires (CETP) le Laboratoire de Météorologie Dynamique (LMD) le Laboratoire d'océanographie et du Climat : Expérimentation et approches Numériques (LOCEAN) le Laboratoire des Sciences du Climat et de l'environnement (LSCE) le Service d'aéronomie (SA) Fig. 1 : Structure de l'ipsl Ces laboratoires et la structure fédérative sont placés sous la tutelle de quatre organismes gouvernementaux (CNRS, CEA, IRD, CNES) et de quatre établissements d'enseignement supérieur (Université Pierre et Marie Curie, Université de Versailles Saint Quentin, École Normale Supérieure, École Polytechnique). Ils sont implantés sur plusieurs sites en région parisienne : Université Pierre et Marie Curie à Jussieu, Verrières le Buisson / Vélizy, Plateau de Saclay / Gif sur Yvette, Saint Maur. L'IPSL étudie l'évolution du climat, de l'effet de serre et de la couche d'ozone, et s'intéresse à la pollution de l'air et des océans. Dans une perspective plus large, il cherche aussi à comprendre les processus qui régissent l'évolution des autres environnements planétaires du système solaire. Des actions fédératrices sont mises en place pour répondre à des priorités nationales : recherche sur le climat, impacts des activités humaines aux échelles régionales et locales, planétologie. Une des grandes réussites de l'ipsl en tant que fédération de laboratoires de recherche est le développement d'un modèle global couplant les modèles conçus par les laboratoires pour rendre compte 7 / 42

individuellement des processus atmosphériques, océaniques et biosphériques. Par ailleurs, ce stage m'a également amené à consulter régulièrement les administrateurs du CCRE de l'upmc, dont les missions sont d'offrir, auprès de la communauté scientifique du campus Jussieu, un ensemble de ressources matérielles et logicielles dans différents domaines (calcul scientifique, sauvegardes des données sensibles des laboratoires de Jussieu dont ceux de l'ipsl,...). Enfin, j'ai également eu l'opportunité de suivre deux formations à l'idris (Institut du Développement et des Ressources en Informatique Scientifique), me permettant d'acquérir certaines connaissances informatiques spécifiques au calcul scientifique. Centre majeur du CNRS pour le calcul numérique intensif de très haute performance, l'idris participe à la mise en place de ressources informatiques nationales, et assure leur support, au service de la communauté scientifique de la recherche publique. J'ai été intégré dans l'équipe ORCHIDEE de l'ipsl à Jussieu (Paris), sous les directives de mes responsables de stage, M. Mancip, ingénieur IPSL en charge du modèle ORCHIDEE, et Y. Meurdesoif, ingénieur LSCE qui effectua sa parallélisation ainsi que celle de LMDz, toutes deux composantes du modèle climatique global de l'ipsl. J'ai ainsi pu avoir accès à un serveur de calcul léger, calculo, basé sur un bi processeur Opteron, sur lequel s'est déroulée la phase de développement, avant d'effectuer des tests de performances sur le récent supercalculateur du CCRE. 1.2.Le modèle climatique de l'ipsl :IPSL CM4 Le modèle climatique de l'ipsl est un support privilégié pour simuler l'évolution du climat. S'appuyant sur les données climatologiques mondiales, il calcule l'évolution temporelle du climat sur de longues périodes (de 150 ans à 100 000 ans), à travers les variations de ses caractéristiques : la température du sol, le nombre de couches végétales, l'albédo, la vitesse du vent, l'évaporation, etc... La comparaison des résultats entre une simulation de référence et une simulation tenant compte d'une hypothèse d'étude (comme l'augmentation ou l'absence de gaz d'origine anthropique) permet par exemple, d'évaluer l'influence de l'homme dans le climat d'aujourd'hui et de demain. Il est ainsi possible d'effectuer plusieurs modélisations du climat de demain en variant, par exemple, la quantité de CO2 émise par l'homme dans l'atmosphère. Cette méthode revient à évaluer qualitativement l'évolution du climat selon les différents scénarios économiques possibles. Ces simulations ont d'ailleurs été conduites récemment par plusieurs laboratoires des sciences du climat et aboutissent à des conclusions proches de celles de l'ipsl. Le modèle global s'appuie sur les différentes composantes actives du système terrestre et leurs interactions : LMDz pour l'atmosphère OPA pour l'océan LIM (Louvain la Neuve Ice Model) pour la glace de mer ORCHIDEE pour la surface terrestre OASIS (Ocean Atmosphere Sea Ice Snowpack) en tant que coupleur Ce système souple et par composante, écrit en Fortran95, permet de simuler de façon autonome ou en interaction les unes avec les autres chacune de ces composantes. Il offre en outre la possibilité d'incorporer de plus en plus de processus physiques, chimiques ou biologiques, améliorant ainsi la pertinence du modèle au fil des versions de chaque composante, sous l'impulsion de différents laboratoires du pôle de modélisation. 8 / 42

Fig. 2 : Cartes des différences de températures entre la décennie 2090 2099 et la décennie 2000 2009 dans le scénario A2 Mais l'un des buts avoués de la modélisation à l'ipsl est d'utiliser son modèle pour des durées de plus en plus importantes, sur des grilles de résolutions de plus en plus fines. Ainsi, alors que la modélisation climatique est par nature consommatrice et génératrice de quantités importantes de données, la tendance est largement à la hausse, sans oublier les paramètres de plus en plus nombreux et les phénomènes de plus en plus complexes à prendre en compte, comme par exemple certaines interactions biochimiques. Il en résulte une amélioration indéniable des résultats, de par leur précision et leur fiabilité, mais également un net accroissement des temps de calcul. Actuellement, sur la plate forme de développement (un bi processeur Opteron), la version séquentielle de la modélisation climatique de la surface continentale, ORCHIDEE, sur 32 jours avec un pas de temps de 30 minutes sur la carte mondiale en résolution 1 de longitude sur 1 de latitude, effectue une restitution en 156 minutes. Toutefois, ORCHIDEE ne représente que 7% environ du temps de calcul dans le modèle global, et une simulation de 32 jours n'aborde pas les échelles climatiques, à l'heure où le monde s'interroge sur le climat des années 2100 et plus. Ces chiffres informent cependant sur l'importance des ressources requises pour ce genre de modélisation climatique. 1.3.Présentation du calcul parallèle Il est à noter que le calcul précédemment décrit n'a fait intervenir qu'un seul des deux processeurs de la machine, ce qui s'avère strictement normal dans le cadre d'un modèle strictement séquentiel. Alors que le marché informatique se dirige vers une multiplication des processeurs au sein d'une même unité de calcul, une évolution nécessaire serait donc l'utilisation en parallèle des processeurs lors de calculs lourds. Néanmoins, la puissance du processeur élémentaire reste un élément clé. 9 / 42

a) Du séquentiel au parallèle Mais les supercalculateurs, dédiés à ce genre de travail, offrent également d'autres avantages au calcul parallèle. De plus en plus bâtis sur des systèmes complets autonomes inter connectés entre eux, ils permettent de bénéficier de plusieurs systèmes de fichiers en plus de l'apport de plusieurs processeurs de calculs. Ceci favorise donc également la rapidité des entrées sorties, élément le plus critique dans certaines applications scientifiques comme celles de la modélisation climatique. Ainsi, les plus importants superordinateurs sont maintenant pour la plupart constitués de plusieurs centaines voire milliers de processeurs, et offrent des puissances potentielles de calcul énormes. Pour les exploiter pleinement, les constructeurs ont tout d'abord mis au point des protocoles propriétaires de communication entre processeurs, utilisables par des directives parallèles. Ceux ci aboutissent à partir de 1992 à des "standards de fait" multi plates formes, avec OpenMP et MPI (Message Passing Interface). Ces derniers sont à présent les modèles de programmation parallèle les plus utilisés, parfois simultanément du fait de leur complémentarité. Fig. 3 : Photographie d'un XD1 constitué de 6 chassis (soit 72 processeurs). Le XD1 du CCRE ne dispose que de 5 chassis. b) Le supercalculateur parallèle du CCRE : le XD1 Le CCRE de l'upmc s'est doté en 2005 d'un supercalculateur de type intermédiaire, dédié aux applications parallèles avec MPI. Le XD1, conçu par Cray, est formé de 28 noeuds de calculs auquel s'ajoutent les 2 noeuds du serveur frontal. Chaque noeud est constitué d'un bi Opteron à 2,6 GHz, chaque processeur étant doté de 2 Go de mémoire DDR SDRAM (4 Go pour ceux du 10 / 42

frontal) ainsi qu'un disque local de 74 Go en S ATA (250 Go pour le frontal). Un réseau de haute performance assure un débit d'au moins 4 Go/s entre deux processeurs quelconques, avec une latence inférieure à 2 µs. Enfin, le frontal est relié par un débit de 200 Mo/s à un stockage externe de type SAN (Storage Area Network) de 2 To. Calculateur Calculo Eclair XD1 Tera 10 BlueGene L Puissance théorique (GFlops) Nombre de CPU Commentaires 13 2 Plate forme de développement (IPSL) 312 60 Plate forme d'évaluation (CCRE) 55705 1008 367000 N 1 français (CEA) 131072 N 1 mondial (DOE/NNSA/LLNL USA) Fig. 4 : Puissance théorique des serveurs de calculs utilisées, comparé à des références du top500 mondial Fig. 5 : Architecture matérielle du XD1 du CCRE eclair Chaque noeud est géré par un système Linux 64 bits autonome, et comprend des implémentations libres et propriétaires. Ainsi sont disponibles les compilateurs GNU et PGI, ainsi que les bibliothèques MPICH2 (implémentation MPI open source) et NetCDF (Network Common Data Form, implémentation libre de gestion de données fournie par Unidata). L'ensemble des noeuds de calcul est piloté par le système de soumission SGE (Sun Grid Engine). En effet, plusieurs travaux d'utilisateurs différents sont effectués au même instant sur le XD1, comme pour la majorité des supercalculateurs actuels. Chacun d'eux est soumis en batch au SGE, qui lui réserve alors le nombre de noeuds demandé. Le frontal est le seul élément du 11 / 42

calculateur réellement accessible par l'utilisateur, où il peut effectuer des compilations, ainsi que des post traitements. 2. La parallélisation du modèle climatique de surface continentale ORCHIDEE 2.1.Le fonctionnement des modèles climatiques de l'ipsl a) Le modèle climatique global Comme décrit plus haut, le modèle climatique global de l'ipsl s'articule sur plusieurs composantes, chacune interagissant plus ou moins directement avec les autres (cf figure 6). Fig. 6 : Structure du modèle climatique global de l'ipsl autour de ses composantes Cependant, d'autres outils sont également utilisés dans le cadre du couplage et des entrées sorties. Ainsi le couplage LMDZOR (composé de LMDz et d'orchidee) ORCALIM (OPA et LIM) est effectué par OASIS par projection de grilles. Les opérations d'entrées sorties sont gérées par IOIPSL, une bibliothèque developpé par l'ipsl qui constitue l'interface du modèle avec NetCDF. b) Le modèle climatique de surface continentale ORCHIDEE LMDZOR est en fait «piloté» par LMDz, celui ci appelant un module intersurf présent dans ORCHIDEE. Cet appel à chaque pas de temps, soit toutes les 30 minutes de temps simulé, en communiquant certaines données atmosphériques (ensoleillement, température de l'air,...). Le modèle de surface continentale est en fait constitué de deux modules, SECHIBA et STOMATE (voir figure 7). 12 / 42

fig. 7 : Composition du modèle climatique de surface continentale ORCHIDEE de l'ipsl SECHIBA est appelé par intersurf toutes les 30 minutes de temps simulé et traite de la physique de la surface continentale, des sols et de la végétation. Les phénomènes hydrologiques dont le routage de l'eau sont également gérés par SECHIBA, mais seulement une fois par jour. Quant à STOMATE, il est appelé toutes les 24 heures pour traiter la biogéochimie continentale, comme la croissance de la végétation, dont l'évolution des phénomènes modélisés est moins rapide. Les calculs du modèle ORCHIDEE à travers ces deux modules s'effectuent principalement sur les points de terre, eux même étant obtenus à partir de la grille à deux dimensions représentant le domaine étudié (cf figure 8). Cette conversion est obtenue en parcourant en longitude puis en latitude la grille, remplissant au fur et à mesure un tableau à une dimension par les points contenant au moins une fraction de surface continentale. La construction d'un index des points de terre permet ensuite de reconstituer la grille. L'utilisation des points de terre au lieu d'une grille 2D est motivée par le gain de place mémoire apporté. En effet, ce choix permet de n'utiliser que 33% de la mémoire requise en deux dimensions, dans le cas d'une modélisation climatique globale (soit la proportion de surface terrestre émergée sur la planète), autorisant ce modèle à s'exécuter en global sur une simple station de travail (la taille mémoire requise montant jusqu'à environ 600 Mo). En outre, cette méthode requiert peu de calculs supplémentaires, étant donné l'absence d'interactions entre les points de terre, sauf dans le cas du routage de l'eau (un tableau de voisins étant alors utilisé). II est également possible d'utiliser ORCHIDEE seul pour la modélisation du climat sur la surface terrestre. Cette version, dite forcée, exploite des fichiers de forçage fournis par LMDz, contenant les données climatiques nécessaires à la simulation. ORCHIDEE_OL (pour Off Line) est en fait une «surcouche» autonome d'orchidee, qui dans un premier temps lit les données d'initialisation, puis au fur et à mesure de la simulation, les données de forçage. Celles ci étant obtenues dans une grille 2D (selon la latitude et la longitude), il est aussi nécessaire de les convertir en points de terre avant d'appeler le modèle. 13 / 42

Fig. 8a : Modélisation de la température au sol de la surface continentale durant l'année 1982 (en K) Seuls les points de la grille 2D comportant des surfaces continentales sont indexés par ORCHIDEE en points de terre. Outre une méthode efficace pour tester ORCHIDEE, le forçage permet d'utiliser la simulation climatique seulement au niveau de la surface terrestre très simplement et rapidement, les autres données étant extraites des fichiers de forçage toutes les 6 heures (et interpolées entre ces lectures), au lieu d'être calculées dans les autres composantes du modèle. c) Les fichiers externes utilisés par ORCHIDEE Le modèle climatique de surface continentale nécessite, que ce soit dans sa version forcée ou couplée, des fichiers de tailles importantes : Plusieurs fichiers décrivant d'entrée, accédés uniquement en lecture, décrivent les propriétés de la surface continentale, comme l'hydrologie ou la répartition des végétaux. Les fichiers de redémarrage restart, en lecture et en écriture, permettent de reprendre la modélisation à partir de données déjà obtenues. Cette fonction est en effet essentielle dans le cas de la modélisation climatique, où les temps d'initialisation des modèles nécessitent leur exécution sur des milliers d'années avant d'obtenir l'état d'équilibre. Les fichiers history contiennent les données calculées par le modèle. Écrits par SECHIBA et STOMATE, ils constituent les résultats exploitables fournis par la simulation. Uniquement dans le cas de la version forcée, ORCHIDEE utilise des fichiers de forçage contenant les données atmosphériques. Celles ci sont fournies directement par LMDz dans le cas du modèle couplé. 14 / 42

Tous ces fichiers de données sont au format NetCDF, un format portable de stockage de données binaires compressées, ce qui ne les empêche pas d'atteindre 1,8 Go pour les seuls fichiers de lecture. Mais un autre fichier, au format texte, intervient dans la configuration du modèle. Le fichier de paramétrage, run.def, permet de configurer sans recompilation les différentes options du modèle (le temps de la simulation, le niveau d'écriture, etc...). 2.2.Le calcul parallèle a) Les caractéristiques du calcul parallèle La vitesse des traitements séquentiels traditionnels semble s'approcher de la limite physique au delà de laquelle il n'est plus possible d'accélérer. En revanche, il est à présent possible d'utiliser à moindre coût : Plusieurs processeurs dans une même puce (architecture actuellement popularisée par les constructeurs sous l'appellation «multi core») Plusieurs processeurs sur une même carte mère (architecture multi processeurs) Plusieurs cartes mères sur le même châssis Les supercalculateurs actuels sont donc conçus autour de ce principe d'architecture parallèle. Leur puissance potentielle de calcul s'est d'ailleurs accrue d'une façon considérable depuis 1990, s'appuyant simplement sur la multiplication des ressources de calculs. Il existe cependant une limite au gain apporté par ce système, schématisée par la loi d'amdahl : R étant le gain de temps entre la version séquentielle et la version 1 parallèle du même programme R= s s étant un paramètre dépendant du programme et de l'efficacité de sa 1 s parallélisation, ou coefficient de parallélisabilité N N le nombre de processeurs Fig. 9 : Loi d'amdahl définissant le gain par processeur Fig. 10 : Évolution du gain R en fonction du nombre de processeurs N selon la loi d'amdahl pour s = 0,88, face au gain idéal (s = 1) 15 / 42

Le rendement de la parallélisation diminuant avec le nombre de processeurs mis en jeu, cela implique que les simulations utilisent rarement toutes les ressources disponibles du système, surtout lorsque l'on considère que le coût d'un travail est généralement fonction du temps consommé total (et donc le temps du calcul multiplié par le nombre de processeurs sollicités). Ce rendement peut d'ailleurs être quantifié par le coefficient de parallélisabilité : 1 R s= 1 1 N 1 Fig. 11 : Coefficient de parallèlisabilité obtenu à partir de la loi d'amdahl selon le gain R et le nombre de processus N b) Les différences entre le calcul distribué et le calcul partagé Le calcul parallèle consiste en l'exécution simultanée d'une même tache, celle ci étant adaptée et partitionnée afin de pouvoir être répartie entre plusieurs systèmes de calcul en vue de traiter plus rapidement des problèmes plus grands. Il existe plusieurs types d'ordinateurs parallèles, caractérisés, principalement, par différents modèles d'interconnexions entre les processeurs et entre les processeurs et la mémoire. La classification la plus populaire est celle de Flynn (1966), qui classe les ordinateurs parallèles selon le type d'organisation du flot de données et du flot d'instructions. Elle distingue ainsi les machines SPMD (Single Program Multiple Data), à flot d'instructions unique sur des données multiples, et les machines MPMD (Multiple Program Multiple Data) à flot d'instructions et de données multiples. Les modèles de programmation parallèle MPI et OpenMP fonctionnent selon le type SPMD, bien qu'il leur soit possible d'émuler le MPMD. Les directives parallèles les plus utilisées actuellement, OpenMP et MPI, utilisent néanmoins des structures différentes : Fig. 12 : Deux conceptions du calcul parallèle : à ressources partagées (OpenMP), ou distribuées (MPI) Partagé dans le cas de l'openmp. Parfaitement adapté aux ordinateurs multi processeurs, les 16 / 42

processus partagent la même architecture système mais s'exécutent sur des processeurs différents. Distribué dans le cas de MPI. Cette solution est préconisée pour les grappes de PC comme le XD1, plusieurs exécutions se déroulant sur des systèmes différents, uniquement liées par les communications réseaux. Leur différences permettent de les utiliser conjointement afin de tirer pleinement profit des ressources offertes par les grappes de serveurs multi processeurs. c) L'utilisation d'une implémentation de directives parallèles : MPI MPI est disponible pour la plupart des langages classiques, comme le C, le C++, le Fortran90... Chaque processus, à qui MPI attribue un rang lui servant d'identifiant, exécute le même programme. Toutes les variables du programme sont privées et résident dans la mémoire locale allouée à chaque processus. Les données sont ensuite échangées entre deux ou plusieurs processus via des appels à des fonctions MPI. 1. program qui_je_suis 2. implicit none 3. include 'mpif.h' 4. integer :: nb_procs,rang,code 5. call MPI_INIT(code) 6. call MPI_COMM_SIZE(MPI_COMM_WORLD,nb_procs,code) 7. call MPI_COMM_RANK(MPI_COMM_WORLD,rang,code) 8. print *,'Je suis le processus ',rang,' parmi ',nb_procs 9. call MPI_FINALIZE(code) 10.end program qui_je_suis fig. 13a : Exemple d'un programme MPI en Fortran Source : Cours MPI de l'idris $ mpirun np 7 qui_je_suis Je suis le processus 3 parmi 7 Je suis le processus 0 parmi 7 Je suis le processus 4 parmi 7 Je suis le processus 1 parmi 7 Je suis le processus 5 parmi 7 Je suis le processus 2 parmi 7 Je suis le processus 6 parmi 7 fig. 13b : Exemple d'exécution d'un programme MPI Très souvent, notamment dans le cas du XD1, l'architecture parallèle est exploitée telle que chaque processeur est réservé à un processus. Mais il est également possible, que ce soit en test ou en production, et indépendamment de l'architecture, que plusieurs processus soient exécutés par un unique processeur. Par exemple, sur notre plate forme de développement constituée d'un bi processeur, il est possible de lancer un calcul parallèle sur 1, 2, 4 processus ou plus, partagés entre les deux processeurs de la configuration. 2.3.La parallélisation d'orchidee a) Les principes de la répartition des calculs Dans le cas d'orchidee (et de IPSL CM4 plus généralement), la parallélisation se base 17 / 42

sur une répartition géographique, plus particulièrement sur celle des points de terre, facilitée par leur faible interaction. Ainsi, chaque processus ne «voit» que son domaine de points de terre, qui lui est fixe. Un processus root, identifié par le rang 0, effectue l'écriture des fichiers de redémarrage, et les calculs concernant le routage de l'eau. Cette dernière nécessitant de nombreuses communications «points à points», sa parallélisation paraît peu bénéfique, d'autant plus que sa version séquentielle consomme peu de temps de calcul. Le modèle atmosphérique LMDz fonctionnant sur le principe d'une grille 2D, l'appel à ORCHIDEE via intersurf ne concerne que les processus contenant des points de terre, sans modification de leur répartition dans le modèle terrestre. En revanche, dans le cas du modèle forcé, c'est le processus root qui effectue l'initialisation du parallélisme, notamment par l'attribution des points de terre à tous les processus, et les variables liées à leur répartition (cf fig. 8). De plus, la parallélisation comprenant également l'écriture des fichiers d'historique, un outil rebuild a été developpé et fourni par la bibliothèque IOIPSL pour permettre la reconstruction d'un fichier d'historique unique à partir des parties écrites par chaque processus. a) Une répartition des charges évolutive Lors de la première exécution du modèle forcé, root effectue une répartition égale en nombre de points de terre entre chaque processus, afin de distribuer équitablement la charge de travail à chaque processus ( s > 1, dans la loi d'amdahl, cf figure 9). Mais une répartition égale des points de terre ne suffit pas, puisque différents critères comme la présence de végétation ou l'ensoleillement influent énormément sur le nombre des phénomènes impliqués et donc sur le volume de calcul de chaque point. Ceux ci sont ainsi plus "lourds" en zone tropicale que dans les régions désertiques ou polaires. De plus, le processus root effectue également des opérations diverses non parallélisables (routage de l'eau, initialisation du parallélisme, etc...), et s'en trouve donc ralenti par rapport aux autres processus. Or les multiples communications émaillant la version parallèle font toutes appel à des synchronisations entre processus, imposant donc de les "mettre à niveau" régulièrement. Forcément, le processus ne contenant que des points d'une région polaire, favorisée au niveau des calculs, doit alors attendre que les autres processus aient terminé leurs calculs avant de pouvoir communiquer avec eux. La parallélisation n'est dans ce cas là pas optimale. Rééquilibrer les charges revient donc en pratique à diminuer le temps d'attente de chaque processus. C'est d'ailleurs en se basant sur le temps d'attente durant les précédentes modélisations que vont être redistribués les points de terre. À la fin de chaque exécution, le nombre de points de terre pour chaque processus est recalculé en fonction de leur temps d'attente. Le résultat de ce réajustement est stocké dans un fichier texte load_balancing, en vue d'être utilisé à la prochaine exécution (cf figure 14). 0 1 356 406 fig. 14 : Contenu du fichier load_balancing pour une répartition sur 2 processus de 762 points (Europe) Ainsi, un processus ayant eu un temps d'attente supérieur aux autres processus, se verra attribuer un nombre supérieur de points de terre à la prochaine exécution. L'équilibre est donc amélioré au fur et à mesure des exécutions du modèle sur le même domaine avec le même nombre de processus. Concrètement, les tests ont montré que l'équilibre est quasiment atteint après seulement une première simulation d'au moins 30 jours, sauf certains cas particuliers. Par exemple, une première modélisation globale (contenant 15600 points de terre) à 4 processus va s'effectuer sur 3900 points de terre pour chaque processus, puis la répartition s'optimise par la suite. 18 / 42

Fig. 8b : Répartition de la zone Europe Afrique par ORCHIDEE_OL sur 3 processus, avec description des paramètres de la grille pour le 3ème processus (en bleu) (cf fig. 8c en annexe). 19 / 42

b) Une parallélisation néanmoins incomplète Il existe cependant des temps d'attente incompressibles entre les processus malgré une répartition de charges optimale. En effet, cette dernière n'est parfaitement efficace que si les calculs parallèles de chaque processus s'équilibrent simultanément avec les tâches non parallélisées. Ainsi ces dernières devraient toutes être suivies de calculs parallèles avant que le modèle n'effectue une synchronisation. En particulier, les opérations de lecture écriture des fichiers de redémarrage, pris en charge uniquement par le processus root, sont souvent encadrées de communications et donc de synchronisation, empêchant les autres processus de prendre en charge les calculs durant les phases d'attente. 3. Après la parallélisation 3.1.Différentes versions possibles pour ORCHIDEE_OL Élément critique du modèle séquentiel (jusqu'à 40% du temps de restitution), les entrées sorties ont également été concernées par la parallélisation, et seules les opérations sur les fichiers de redémarrage et d'initialisation restent affectées au seul processus 'root'. Ainsi, chaque processus obtient directement du fichier de forçage les données du domaine qui lui est affecté dans le cas du modèle forcé. Cette méthode est optimale pour les machines à systèmes de fichiers multiples comme le XD1, et ne pénalise pas les autres architectures. Cependant, l'utilisation de la bibliothèque IOIPSL par ORCHIDEE, pour les opérations d'entrées sorties, présente quelques défauts, notamment la lecture des fichiers de forçage : l'extraction des données d'un domaine spécifique du fichier de forçage passe obligatoirement par la lecture de ces données sur le domaine global. Peu gênante dans le cas du XD1, cette situation est préoccupante pour la modélisation sur une machine au système de fichier unique comme les stations de travail traditionnelles. Chaque processus va donc parcourir entièrement le même fichier, soit une lecture d'environ 100 Mo (correspondant à la cinquantaine de caractéristiques requises) à chaque passe principale, une interpolation étant effectuée pour les passes internes. C'est pourquoi j'ai développé, en concertation avec mes responsables, une version d'orchidee_ol où la lecture des fichiers de forçage se fait uniquement par 'root', celui ci les dispersant ensuite selon les besoins des autres processus. La charge réseau ainsi induite par la dispersion est négligeable quelle que soit l'architecture du calculateur, mais le système de fichiers se voit épargner une multitude de lectures inutiles. Cette version, à première vue fonctionnelle, mit rapidement en évidence un problème, jusqu'ici indécelé dans la version précédente, entraînant une modification des résultats par rapport aux précédents. Ensuite, devant les mises à jour prochaines de IOIPSL, il a été décidé d'abandonner cette nouvelle version et de concentrer les efforts sur d'autres aspects du code : débogage, mise à niveau par rapport à la version séquentielle. Néanmoins, cette variante de la version parallèle aura mis en lumière un problème important dans l'implémentation de la parallélisation, aboutissant dans certains cas à des résultats faux. 3.2.Les principaux problèmes rencontrés Les difficultés rencontrées dans la parallélisation proviennent en majorité de la répartition des points. En effet, sa mise en oeuvre a nécessité l'ajout de nombreuses variables permettant de passer de la grille 2D globale aux points de terre locaux (cf fig. 8b). Par exemple, le problème rencontré par ma version modifiée d'orchidee_ol provenait d'une initialisation erronée des index locaux, construits à partir d'un mauvais décalage de départ. 20 / 42