Réunion sur la démocratisation du workflow de production des données

Présents : Sébastien D, Arnaud C, Fabienne M, Ionela M, Anne C, Laurent F, Didier H, Frédéric H, Eliott D, Patricia C, Juliette M, Yann M, Yann C, Abderrahmane I, Nicolas L, Simona F, Julie D, Christian E, Thibaut L, Guillaume L, Olivier B (visio) et Gaelle R (CNRM, visio)

Les slides présentés sont disponibles là : Workflow_27092019.pdf​

1. Présentation et discussions autour de l’existant

1.1 Les principes généraux de XIOS

Le fichier de configuration « iodef.xml » permet la gestion des paramètres XIOS relatifs aux champs, aux grilles et aux fichiers des différentes composantes. Ce fichier peut être splitté en plusieurs fichiers comme c’est fait dans toutes les composantes IPSL avec les fichiers context.xml, field_def.xml et file_def.xml. La composante NEMO a fait le choix d’utiliser également des fichiers grids_def.xml, axis_def.xml et domain_def.xml pour les informations relatives aux grilles.

1.2 Le workflow actuel des configurations IPSL avec le mode standard et le mode CMIP6

Deux modes de sorties différents sont actuellement possibles dans les configurations IPSL :

• le mode standard gère les sorties sous le format de fichiers contenant plusieurs variables. libIGCM assure la gestion de ces fichiers sous une forme « packée » ainsi que la génération d’un monitoring dans une phase de post-traitement.
• Le mode « CMIP6 » permet d’obtenir des sorties satisfaisant à la DR CMIP6. Ce mode utilise un fichier ping.xml intermédiaire et nécessite l’utilisation de l’outil dr2xml pour générer les fichiers xml. Cet outil dr2xml permet l’utilisation de « variables maison » qui sont à définir via un fichier annexe au format jason.

Les 2 modes utilisent les mêmes fichiers « field_def.xml » dans les composantes à l’exception d’INCA qui doit générer un fichier field_def.xml particulier dans le cas « CMIP6 » car les champs sont définis dans le modèle dans le mode « standard » (dr2xml a besoin que l’ensemble des champs soient définis dans le field_def.xml).

2. Objectifs, souhaits

La question posée était : « Idéalement, qu’est-ce que vous souhaiteriez avoir dans vos sorties ? ». Le tour de table a fait ressortir les souhaits et remarques suivants :

• des sorties au format « CMIP6 » (nom de la variable, arborescence, nom du fichier) pour analyse et comparaison avec des sorties « CMIP6 » déjà existantes.
• des diagnostics qui ont été codés (et sortis) dans la production « CMIP6 » dans les sorties standards.
• des fichiers de type « standards » pour les phases de développement des modèles.
• une filière « standard » plus proche de la filière CMIP6 : même grille décalée pour LMDZ, mêmes noms de variables,…
• les filières standards XIOS et IOIPSL : tout le monde ne faisant pas du « CMIP6 », il est important que la filière standard XIOS reste proche de la filière standard IOIPSL lorsque celle-ci existe encore (ex : ORCHIDEE).
• facilité de modification des diagnostics : par exemple pour les projets d’inter-comparaison avec les autres modèles (suivant les projets, les variables demandées n’ont pas le même nom (ex : CMIP6, Aerocom)).
• facilité d’intégration de nouveaux diagnostics
• Projet QUEST : des sorties proches des sorties CMIP6 pour une partie du projet. Une autre partie du projet sera composée de 250 petites simulations avec peu de variables à sortir.

3. Contraintes : inodes, volume de données

Les fichiers standards sont utiles pour limiter le nombre d’inodes utilisés. Une dimension supplémentaire pour gérer les membres des ensembles serait aussi utile. Cette dimension supplémentaire pourrait se faire soit via XIOS qui est capable de gérer cela, soit via une tâche de post-traitement (libIGCM). Dans un fonctionnement proche du workflow CMIP6, on distingue deux catégories de simulations

• les longues simulations permettant d’avoir des ratios TB produits / Fichiers produits de l’ordre de 1TB/250 fichiers.
• les simulations d’ensembles courtes permettant d’avoir un ratio de l’ordre de 1TB produits / 2000 à 5000 fichiers.

Sur un système de fichiers ayant des contraintes fortes sur les inodes et leur taille moyenne, le workflow CMIP6 n’est pas adapté aux simulations d’ensemble courtes (type DCPP, VolMIP). Dans ces cas là, la possibilité de rassembler des « variables CMIP6 » dans des fichiers par fréquence (type histmth_CMIP6) est impérative à relativement court terme. Pour les simulations longues et DCPP, 66 % du volume CMIP6 STORE est occupé par les restarts et les sorties NEMO à la fréquence de 5 jours. Pour les simulations de type VolMIP, 80 % du volume STORE est occupé par les restarts (les restarts sont produits mensuellement et sont tous conservés).

4. Remarques complémentaires

Les remarques suivantes ont été mentionnées :

• les nouveaux outils d’analyse comme « xarray » permettent de rendre transparent le format des fichiers (Time Series vs fichiers standards)
• CMIP6 : quand on parle de « CMIP6 » il faut comprendre la « logique » CMIP6 plutôt qu’une bibliothèque de variables à sortir.
• Toute décision prise sur LMDZ ou/et ORCHIDEE aura un impact sur les utilisateurs non CMIP6.
• Des sorties souples sont nécessaires en phase de développement, des sorties standardisées sont nécessaires lors de simulations de sensibilité pour se comparer à des jeux de données type CMIP et des sorties répondant strictement à un protocole plus complexe sont nécessaires en mode production.
• Performances de calcul : attention à la montée en résolution. Par exemple, on a vu pour la mise au point du workflow CMIP6 que les performances étaient correctes en LR mais deviennent plus problématiques lorsqu’on passe à des résolutions plus élevées.
• La génération automatique faite par un outil comme dr2xml ne se soucie pas de l’efficacité (par ex : gestion mémoire, ordonnancement des opérations,…)
• Le CNRM a fait le choix de la combinaison Eclis + XIOS + dr2xml pour gérer les sorties autres que CMIP6 et éventuellement rajouter des variables lorsque c’est nécessaire.
• Dr2xml est capable de générer des fichiers xml moins lourds (pas ou moins d’attributs).
• L’éclatement des fichiers hist par level est nécessaire lorsque le nombre de variables par fichiers est important et que les sorties se font en parallèle (limitation HDF).
• Problème lorsqu’on sort les 2 modes : on duplique certaines variables. On reste très efficace comparativement à qui est fait dans certains centres (x 5 pour le stockage au NCAR).
• Difficulté de validation des 2 filières en phase de développement d’un modèle car cela se fait en utilisant principalement une des 2 filières. Cela implique donc un peu de stress lorsqu’on active la 2eme filière en production (ex : développement CMIP6 fait sur la filière standard, puis production et publication des données issues de la filière CMIP6).
• Le groupe plateforme ne veut/peut pas se lancer (tout de suite) dans de gros développements concernant la chaîne de calcul et de production de données

5. Résumé et conclusions

Compte tenu des souhaits et des remarques de chacun, il est donc proposé de maintenir les 2 filières sous la forme suivante :

5.1 Mode standard

• fichier avec plusieurs variables (de type hist, grid_T,…) réparties par fréquence.
• pour le tuning et le développement
• cohérent avec des projets déjà existants et non CMIP6
• cohérent avec des sorties IOIPSL
• facilement modifiable
• prédéfinis pour des niveau de sorties (low, medium, high)
• déjà existants mais à faire évoluer pour aller vers du formatage « CMIP6 » (grille, noms de variables,…)
• suppression des sorties 5D nemo
• possibilité d’avoir les TS
  • Via libIGCM : déjà opérationnel
  • Via xml (XIOS) : n’existe pas encore mais la fonctionnalité XIOS existe déjà.
• Monitoring
  • via libIGCM (réduction faite par ferret): déjà opérationnel
  • via XIOS (réduction faite par XIOS): n’existe pas encore

5.2 Mode CMIP6

• fichier proche du format CMIP6 (TS, variable,…) mais allégé pour le rendre plus lisible (un peu de travail, il est possible avec drxml de supprimer ou réduire les attributs) et améliorer l’efficacité (un peu plus de travail)
• possibilité d’utilisation d’un mode intermédiaire (déjà disponible et utilisé par Juliette) avec des TS très proches des sorties CMIP6 (mode intermédiaire déjà utilisée par juliette)
• pré-définis pour des expériences type (historical, piControl, volmip) et niveau de sorties (low, medium, high)
• produit des fichiers
  • TS allégés (un peu de travail/développement)
  • De type « hist_CMIP6 » via une l’utilisation de la fonctionnalité XIOS pour produire directement des fichiers histoire contenant toute les variables d’une fréquence donnée et couvrant une large période temporelle, typiquement beaucoup plus que la période d’intégration (plus de développement)
• Monitoring
  • Via libIGCM (réduction faite par ferret) : n’existe pas encore
  • Via XIOS (réduction faite par XIOS) : n’existe pas encore

6. Prochaines étapes

Il n’y a pas d’urgence à avancer sur le sujet. Les prochaines étapes seront de créer une matrice de fichiers de type CMIP6 en fonction de l’expérience (picontrol, historical ) et de la priorité (low, medium, high) et dans un 2ème temps de générer ces sorties-là sous la forme de fichier « hist-CMIP6 » pour les expériences de type VolMIP.