Réunion du 10/05/2016

Présents : Sophie T., Martine, David S., Roland, Sophie V., Marie-Pierre, Constantin, Stéphane, Matthieu, David SM, Laurent

• CNRM-CM6
  • Nemo-XIOS 2 : XIOS2 ne semble pas bien gérer automatiquement les tailles de buffer : il faut les augmneter explictement pour tourner. Par ailleurs, il a un problème de performance (augmentation de 40% du temps elapse, typiquement 35 à 40’ pour faire 1 mois de simulation avec ORCA0.25), problème à faire remonter à l’équipe XIOS.
  • évolution méthodes de compilation : proposition de s’affranchir des ’module load’ et de procéder pour toutes les composantes comme pour la compilation Arpège (méthode Ryad : utilisation de l’option -Wl de l’éditeur de lien)

• XIOS pour Arpege et Surfex :
  • tests des sorties de champs via XIOS2 menés pour Surfex et Aladin ; intégration des développements dans les codes en discussion avec Antoinette et Bertand
  • interpolations : interpolation avec masque en developpement, quelques plantages sur l’interpolation horizontale, interpolation verticale (hybride->pression) pas encore livrée par l’équipe XIOS ; les éventuelles finesses de l’interpolation verticale FullPos sont à vérifier
  • solution de secours si retard dans la livraison de l’interpolation verticale par l’équipe XIOS : utilisation de XIOS2 avec sorties en niveaux modèle + interpolation verticale via CDO (en step3, pour ne pas déplacer/gérer les gros volumes de données intermédiaires)
  • nécessité de production sur des niveaux modèle (AerChemMIP par ex) en complément des niveaux pression à confirmer (en particulier le nombre d’années et de variables concernées)
  • poursuite tests sur temps et taux de compression par CDO (vers netcdf4_classic) par divers outils : les coûts de lecture sont 2 fois supérieurs pour NetCDF4-Classic par rapport à NetCDF3, performances CDO : les performances de compression (efficacité et coûts) sont très variables d’un realm à un autre et même très variables pour les variables d’un même realm. Bonnes performances de compression confirmées via CDO (champs 3D océaniques inclus)

• Contrôle qualité : Sophie V. confirme que l’outil de contrôle qualité CEDA-CC Compliance Checker (utilisé dans SPECS) ne vérifie que si les fichiers sont cmorisés. Autre action menée : relecture papier DKRZ CMIP5, qui reste assez vague. Retours des contrôle qualité CMIP5 sur CNRM-CM5 à analyser encore

• Environnement, Prolix et Beaufix
  • choix Intel 15 ou 16 à venir par DSI
  • attente positionnement définitif GMAP sur le sujet,
  • post-réunion : les 2 environnements sont finalement disponibles pour test sur Prolix (mais adminhpc entend n’en supporter qu’un sur le long terme)
  • expérimentations scalabilité NEMO sur Beaufix-Prolix menés par E. Maisonnave (NEMO+LIM3 10 ans/j sur Prolix et plafond à 6 ans/j sur Beaufix, le tout sans I/O)
  • la limite en nb de taches MPI pour Arpege rencontrée par Eric Maisonnave (soit 1400) est sensiblement la même que celle rencontrée par Fabrice et Romain (qui ont un plantage dans le setup du semi-lagrangien) ; Eric n’a pu utiliser plus de procs qu’en activant la parallélisation OpenMP (qui s’avère peu efficace)

• Data Request
  • nouvelle version livrée par M. Juckes le 12/04 (AerChemMIP pris en compte)
  • action de recensement des diagnostics par MIPs à relancer pour la prochaine réunion CMIP6-Tech
  • cas particulier des diagnosctics LUMIP (variables Surfex par tile à instruire : fait dans Surfex ou par XIOS ?)
  • rappel : l’objectif est, pour les runs CMIP6, de configurer automatiquement les sorties des modèles, via des fichiers de configuration Xios construits dynamiquement en fonction de l’expérience, du membre, de l’année traitée, des MIPS auxquels on participe, et d’une liste d’exclusion de variables (celles non codée ou jugées de peu d’intérêt) ; les autres runs (hors CMIP) doivent pouvoir être configurés simplement

• ESGF
  • le nouveau file system du Cerfacs est installé et visible depuis le data node ESGF du CNRM. Le Cerfacs a récupéré l’ensemble de l’archive des données decennales CMIP5 précédemment publiées sur le noeud du CNRM. Action à suivre : transfert au Cerfacs des procédures CNRM permettant la publication de données sur le noeud du CNRM puis publication par le Cerfacs de ses données decennales sur le noeud du CNRM

• Autres :
  • les utilisateurs CNRM enregistrés peuvent écrire des contributions sur le Redmine du Cerfacs (en complément des publications habituelles d’atlas sur cnrm-game-meteo.fr/cm)
  • le problème rencontré avec Oasis dans l’interpolation conservative était dû à un défaut dans la description des cordonnées géographiques des coins de certaines mailles de la grille e-orca1, mailles qui n’auraient pas dû être impliquées dans l’interpolation car masquées ; Laure a rectifié le fichier de grille utilisé par oasis et les fichiers de poids corrigés ont été transmis à Aurore. Sophie a codé la modif équivalente dans Nemo pour pallier en amont à ce problème.