wiki:mutualiation_modeles_traceurs

Version 3 (modified by acosce, 16 months ago) (diff)

--

Travail sur la mutualisation des forces entre les modèles de traceurs

Réunion du 9 février 2023

Présents : Juliette, Thibaut, Didier, Nicolas, Olivier, Patricia, David, Myriam, Lola, Marion, Slimane (+ Yves qui a quitté la réunion à cause de soucis de connexion)

Nous avons commencé par une présentation rapide et succincte des modèles Reprobus, Strataer, et Inca

La discussion est ensuite passée sur les raisons de l'organisation de cette réunion : la machine exascale se profile à l'horizon 2025 et pour l'instant nous ne savons toujours pas avec certitude quelles seront les technologies de retenues et donc le ou les langages / librairies / protocoles à utiliser pour porter les codes sur cette machine. Actuellement l'hypothèse la plus vraisemblable est l'utilisation de l'openACC, qui consiste à rajouter des directives dans les codes pour indiquer les parties qui doivent être accélérées sur les GPU et les parties qui doivent rester sur les CPU. Le consortium Nemo mise sur l'utilisation d'un pré-processeur permettant d'intégrer ces directives au code.

Olivier précise que l'IPSL a recruté Kazem Ardaneh pour travailler sur le portage des codes en GPU. Actuellement Kazem travaille sur Orchidee. Ensuite Kazem devrait travailler sur les autres codes de l'IPSL. Anne rappelle que dans l'état actuel des choses Kazem ne pourra pas travailler sur Inca qui ne fonctionne que sur les supers calculateurs auxquels il n'a pas accès. Et ne pourra être donc au mieux qu'un consultant sur la question.

Le portage sur GPU doit être accompagné d'une réflexion sur les questions de performances. Avoir la reproductibilité des résultats avec le code sur CPU est également un équilibre à trouver qui peut facilement être cassé par une directive mal placée.

Pour faciliter ce portage il est recommandé d'avoir des codes propres et bien codés. L'idée en organisant cette réunion c'est de voir si il est possible de penser un nouveau code de chimie aérosols qui regrouperait tout ce qui est fait dans les 3 modèles existant pour éviter de dupliquer les efforts et faciliter les interactions entre les boîtes.

Olivier rappelle que Thibaut travaille actuellement sur LMDZ pour pouvoir appeler parallèlement les différents code de inca, strataer et reprobus. Ce dev est intéressant car c'est une première brique vers un code unifier et permettra de pointer les éventuels soucis ou les avantages à se regrouper.

Une réflexion est menée sur les points communs sur lesquels nous pourrions commencer ce travail :

  • le solveur chimique ? Didier précise que pour l'instant inca n'a pas travaillé sur le nouveau solveur que va utiliser reprobus faute de personne et non pas faute d’intérêt
  • le lessivage
  • la lecture des émissions

Actuellement Nicolas et Marion travaillent ensemble pour unifier le module de lecture d'émissions entre reprobus et strataer. Anne est d'accord pour se joindre à ce travail et voir avec eux comment cela peut être pensé de manière générique pour convenir à chacun des modèles. Anne rappelle que dans ce travail il faut garder en vue une lecture des fichiers avec interpolation pour l'icosaédrique (grille dynamico) ce qui est déjà fait côté inca.

Slimane rappelle qu'il faut être vigilant sur la conservation de la masse.

Didier précise que la partie stratosphère de inca n'est pas une chimie simplifiée mais une chimie équivalente à utilisée dans reprobus

Slimane souligne le fait que l'unification des codes sera plus simple pour la chimie que pour les aérosols.

Anne précise que le but serait des modules communs, bien identifiés les uns par rapports aux autres, et il est toujours possible d'avoir des programmes principaux différents qui suivant les cas traités appeleraient les aérosols strato, la chimie et aérosols tropo, la chimie et aérosols tropo et strato, ou la chimie strato.

La réunion se finit en s'interrogeant sur les suites à donner à cette initiative :

Dans un premier temps Anne va contacter Nicolas et Marion au sujet du module de lecture d'émissions. Et il est suggéré d'organiser des réunions de travail en petits comités autour de sujets précis pour déterminer ce qui existe pour chacun des sujets listés plus haut, ce qu'il faut conserver ou modifier et travailler dessus.

(Note de Anne hors réunion : je viens de regarder il y a 57312 lignes dans les routines et modules de inca, hors lignes générées par le pré-processeur et hors fichiers xml - si l'on considère que 30% de ces lignes sont des commentaires et des lignes blanches, cela laisse 40 119 lignes de code)

Réunion du 8 mars 2023

Présents : Marion M, Anne C, Nicolas L

4 types de développements pourraient être mutualisés dans un premier temps entre les modèles StratAer? / INCA / REPROBUS :

  • Routine d’injection ponctuelle d’un traceur : travail bien avancé dans StratAer? et repris par REPROBUS —-> permet l’injection en 1 point ou une zone lon/lat d’une espèce (Soufre, eau, Chl, Br...) avec une distribution en temps et altitude donnée.
  • Lecture de fichiers climato / trajectoire : travail avancé dans INCA pour utiliser XIOS pour la lecture et l’interpolation sur la grille du modèle plutôt que NetCDF -> permet d’anticiper le passage à la grille icosaédrique (à reprendre pour REPR/StratAer)
  • Gestion des sorties via XIOS : travail déjà fait dans INCA pour créer des fichiers dédiés aux différentes sorties spécifiques (émission, bilans, ...) et pour gérer par groupe des niveaux variables de traceurs. Scripts existants pour générés les XML pour des sorties CMOR.
  • Utilisation des nouveaux fichiers de traceurs : validation faite dans INCA, REPROBUS est à jour et les utilise régulièrement. StratAer? à faire en s’inspirant du travail de Lola.

Conclusions :

  • Ajouter Lola aux discussions
  • Prochain point le 22 mars à 11h

Attachments (2)