Intégration de la librairie d`I/O XIOS dans le modèle IPSL ESM

Intégration de la librairie d’I/O XIOS dans le modèle IPSL ESM
(Milestone CONVERGENCE MS 4.1)
La librairie d’écriture XIOS a été implémentée dans toutes les composantes du modèle IPSLCM : LMDZ (modèle atmosphère), NEMO (modèle océan, glace de mer et biogéochimiemarine), ORCHIDEE (modèle de schéma de surface) et INCA (modèle d’aérosols et chimie
atmosphérique). Le modèle IPSL-CM est désormais un ensemble cohérent, flexible et
efficace en termes de gestion des écritures des variables.
1) Présentation de XIOS
XIOS est une librairie développée à l’IPSL qui permet, dans sa version actuelle, de gérer les
sorties d’un code de climat. Elle permet à la fois de réaliser les écritures de variables dans
des fichiers de sortie au format NetCDF et de réaliser des actions spécifiques (opérations
temporelles, opérations arithmétiques, combinaisons de variables,…) sur les variables ellesmêmes.
Fig 1 : Schéma descriptif de la librairie XIOS
Les fichiers de configuration XML permettent de décrire facilement l’information relative aux
sorties à réaliser. Cette information est représentée sous la forme d’attributs :
-
context : identification des modèles et sous-modèles
grid, domain, axis : informations sur la grille de chaque modèle
-
field : informations sur les variables (opérations, precision,…)
file : informations sur les fichiers contenant les variables (variables à inclure dans le fichier,
fréquence de sortie, fréquence de split,…).
La fonctionnalité de « serveur » permet de réaliser les écritures des variables en mode
asynchrone : l’écriture dans les différents fichiers de sortie est donc réalisée par des cœurs
de calcul dédiés. La partie « calcul » du code n’est donc pas pénalisée par la partie
« écriture » des variables. La fonctionnalité d’ « écriture parallèle » permet d’obtenir un seul
fichier de sortie plutôt qu’un fichier par process.
La librairie XIOS est utilisée dans les modèles de l’IPSL mais également à l’extérieur de l’IPSL:
-
modèle MAR (Atmospheric Regional model, LGGE)
modèle ROMS (Oceanic regional model, IFREMER)
modèle MARS3D (Model for Applications at Regional Scale, IFREMER)
2) Intégration de la librairie XIOS dans les composantes du modèle IPSL-CM
La librairie XIOS a été implémentée dans chacune des composantes du modèle IPSL-CM : LMDZ
(model atmosphère), NEMO (modèle océan, glace de mer et biogéochimie-marine), ORCHIDEE
(modèle de schéma de surface) et INCA (modèle d’aérosols et chimie atmosphérique).
a) Implémentation dans les composantes
L’intégration d’XIOS dans les modèles consiste simplement au codage des appels aux différentes
fonctions XIOS dans le modèle combiné à la mise en place d’un (ou plusieurs) fichier(s) de
configuration xml (Fig2 et Fig 3). L’intégration s’est faite de façon indépendante et différente
dans chacune des composantes :
-
NEMO : Activation de XIOS par défaut avec la clé cpp key_iomput
LMDZ : Activation de XIOS par clé cpp CPP_XIOS + flag « ok_all_xml=y » dans run.def
ORCHIDEE : Activation de XIOS par clé CPP XIOS + flag XIOS_ORCHIDEE_OK dans run.def
INCA : Activation de XIOS par clé CPP XIOS + flag XIOS_INCA dans inca.def
Fig 2 : Séquence schématique d’appel aux fonctions XIOS dans le modèle NEMO pour sortir la
variable « sst »
Fig 3 : Extrait des fichiers de configurations XML du modèle NEMO nécessaires pour sortir la
variable « sst »
Chacune des composantes du modèle IPSL-CM utilisait la librairie IOIPSL (développée à l’IPSL) pour
réaliser l’écriture des variables dans des fichiers au format NetCDF. La librairie XIOS remplace donc
désormais la librairie IOIPSL pour la gestion des écritures des variables dans les modèles de l’IPSL.
operation in histdef
flux_op
flux_scinsec
ave
once
tmaxcels
tmincels
sumscatter
argument in xios_send_field
one_day/dt(*)
1/dt (**)
-
operation in xml
average
once
maximum
minimum
accumulate
Fig 4 : Correspondance des opérations entre IOIPSL et XIOS pour le modèle ORCHIDEE
La validation des sorties effectuées avec la librairie XIOS s’est faite en comparant les « sorties XIOS »
avec les « sorties IOIPSL ». Des petites différences (de l’ordre de la précision machine) sur les
variables double et simple précision moyennées ont été constatées. Ceci s’explique par le fait que le
calcul de la moyenne dans XIOS est très légèrement différent du calcul fait dans IOIPSL : XIOS
cumule les champs puis les moyenne lorsqu’on est à une fréquence d’opération tandis qu’IOIPSL
moyenne à chaque pas de temps sans passer par l’étape de cumul.
b) Assemblage des composantes dans le modèle IPSL-CM : les contextes XIOS
XIOS est interfacé avec le coupleur parallèle Oasis-MCT ce qui permet au modèle Système Terre
IPSL-CM complet d’utiliser XIOS comme seule et unique librairie d’écriture. La gestion des variables à
sortir par composante (ou sous-composante) se fait en utilisant l’attribut « context » de XIOS :
chaque composante (ou sous-composante) définit son propre contexte d’utilisation de XIOS. Pour
chacun des contextes, les attributs (grille, champs, fichiers,…) sont définis dans un fichier XML
spécifique. Ces fonctionnalités de « contexte » et de découpage de fichiers XML en sous-fichiers XML
sont très utiles dans un contexte IPSL multi-configurations : la configuration de sorties de variables
d’un modèle peut ainsi être très facilement utilisée à la fois en configuration couplée (modèle IPSLCM), forcée (non couplée à un autre modèle) ou zoomée (sous-domaine géographique).
Fig 5 : Extrait du fichier principal de configuration XML du modèle IPSL-CM. Pour chacun des
contextes, les attributs (grille, champs, fichiers,…) sont définis dans un fichier XML
spécifique : nemo.xml, lmdz.xml,…
c) Performances : le mode serveur et l’écriture parallèle
L’utilisation d’XIOS en mode serveur (un groupe de process « serveurs » est partagé par les
composantes) permet d’écrire les données de manière asynchrone. Les performances
obtenues grâce au mode serveur permettent de cibler efficacement des machines SMP de
type TGCC-Curie et IDRIS-Ada. La fonctionnalité d’écriture parallèle permet de supprimer la
phase de post-processing de recombinaison des fichiers (étape de « rebuild »), fiabilisant
ainsi l’environnement d’exécution IPSL tout entier. Les performances obtenues en écriture
parallèle dépendent fortement des librairies NetCDF et HDF5 utilisées, des paramètres du
filesystem parallèle et de la charge d’utilisation de la machine et du filesystem au moment
des écritures.
Temps de restitution pour
1 mois de simulation (s)
27 ATM x 4 OMP + 20 OCE : mode one file
414
27 MPI x 4 OMP + 20 OCE : mode multiple file
330
27 MPI x 4 OMP + 20 OCE + 1 serveur XIOS : one file
330
Configuration
Fig 6 : Premières performances obtenues en utilisant le mode serveur sur la configuration
IPSL-CM basse résolution.
La figure 6 nous montre qu’il n’y a aucun surcout en temps de restitution à obtenir un seul
fichier de sortie avec 1 serveur XIOS (mode one file + serveur XIOS) plutôt qu’à obtenir un
fichier de sortie par process (mode multiple file). On voit en revanche, le surcout de
l’écriture parallèle lorsqu’on n’active pas le mode asynchrone (mode one file sans serveur
XIOS). Ces mesures de performances sont une preuve de faisabilité et de bon
fonctionnement de la librairie XIOS en mode serveur. Il est prévu de refaire ces mesures de
performances sur des configurations du modèle IPSL-CM à plus haute résolution et à plus
grand nombre de cœurs de calcul afin d’évaluer plus précisément le potentiel de la librairie
XIOS en termes de performances pour le modèle IPSL-CM (Task 3, MS 3.2a, CONVERGENCE).
3) Utilisation en production
Fig 7 : Schéma du modèle IPSL-CM utilisé en production
La librairie XIOS est désormais utilisée dans la version de référence du modèle IPSL-CM.
Cette version IPSLCM6 du modèle est la version actuelle du modèle Système Terre IPSL-CM
qui tourne sur les machines TGCC-Curie et IDRIS-Ada. La flexibilité apportée par les fichiers
de configuration XML facilitera le respect de protocoles imposés en termes de sorties des
modèles (noms des variables, fréquence, description,…) dans des exercices de type CMIP6.
4) Prochaines étapes
Les prochaines étapes dans l’intégration et l’utilisation de la librairie XIOS dans le modèle
IPSL-CM sont les suivantes :
-
-
-
Comme dit dans le paragraphe 2)c) de ce document, il est prévu d’évaluer les
performances de la librairie XIOS et en particulier du mode serveur sur des
configurations à grand nombre de cœurs et à résolutions de modèles élevées. La
mise au point d’un outil pour aider à trouver la configuration optimale en termes de
nombre de serveurs est prévu dans le cadre du projet CONVERGENCE (Task3, MS
3.2a).
La librairie XIOS est désormais intégrée dans le modèle IPSL-CM : il est donc possible
dès à présent d’évaluer la faisabilité d’utiliser XIOS pour réaliser des tâches de posttraitement (génération des times series, des moyennes saisonnières,…) afin d’alléger
au maximum la chaîne de production : ces tâches de post-traitement sont
actuellement réalisées par des tâches indépendantes du job de calcul.
Plusieurs développements dans la librairie XIOS sont prévus dans le cadre du projet
CONVERGENCE :
o Gestion des fichiers d’entrée (MS 2.2a)
o Gestion des fichiers restarts (MS 2.2.b)
o Gestion des interpolations (MS 2.3)
Il est prévu de tester et de valider l’utilisation de ces différentes fonctionnalités dans
le modèle IPSL-CM au fur et à mesure de leur disponibilité.
5) Difficultés rencontrées
Les principales difficultés rencontrées :
-
-
du retard a été pris dans l’intégration de la librairie XIOS dans le modèle IPSL-CM en
raison du phasage nécessaire des versions « développement » et « production » dans
chacune des composantes.
le modèle IPSL-CM a été le premier modèle à coupler entre elles des composantes
utilisant chacune la librairie XIOS comme librairie de sorties. L’intégration d’XIOS
dans le modèle IPSL-CM a donc été l’occasion de mettre en lumière certains bugs liés
à une utilisation spécifique et non-standard (mode MPMD, partage de serveurs entre
plusieurs composantes, utilisation d’OASIS-MCT,…).