2021/10/11
Poihl 'architecture et développement du code'
Le poihl de la semaine prochaine sera un poihl 'banalisé'
Pour rappel:
Le lien gotomeeting est https://www.gotomeet.me/EMC3_LMDZ/poihl
La page du tour de table virtuel est ici
https://pad.colibris-outilslibres.org/p/TourdeTablePoihl
Infos générales:
- Formation: déjà 14 inscrits en 1 semaine. A priori, une grosse moitié des inscrits est intéressée par les traceurs.Point de vue agenda: on reprend en gros les horaires d'il y a deux ans et on prévoit une session 'ferret' à la réunion de préparation à la formation organisée le jeudi 2 décembre. Mise en place d'un groupe de travail "formation" avec les usual suspects (Adriana, Ehouarn, Laurent) et un petit "nouveau" (Etienne)
- proposition de points pour un prochain poihl: Martin Ménégoz aimerait discuter de la bimodalité des précipitations mais pas avant début novembre
"Architecture et développement du code":
Ehouarn nous fait un exposé de l'architecture de LMDZ en se basant sur le répertoire LMDZ6/libf, explique les différences entre LMDZ terrestre et LMDZ planeto (même interface, dyn3dpar inclut les modifications pour les cps variables qui n'ont pas été portées sur dyn3dmem). Etienne rédige un README explicitant les différents sous-répertoires de libf. Ce README est commité dans libf/ sur le dépôt svn du code. On se rend bien compte que l'architecture du code LMDZ a été choisie pour éviter les duplications de code et qu'elle est contrainte par la gestion des dépendances à la commpilation. Ces contraintes pourraient sauter en adoptant des notions introduites par les versions plus récentes de fortran (plugins ...). S'ensuivent discussions, demandes de clarification, propositions de règle de codage à adopter.
Photo du tableau blanc
Propositions de travaux à engager:
- nettoyage de l'architecture (répertoire misc et obsolete, commandes scopy/cray, suppression dyn3dpar / phymar)
- convergence dyn3dpar planeto / dyn3dmem terrestre
- l'interface avec la (les) physique(s): comment la rendre plus générique, quelles sont les différences entre les routines d'appel et d'initialisation des différentes physiques (celles qui sont sous dynphy_lonlat/phy....) et ces différences justifient-elles des routines différentes
- règles sur les principes de codage, par exemple: quand faut-il passer une variable par argument plutôt que par common/module? une bonne règle pourrait être que les variables passées par module ne peuvent être modifiées que par les routines incluses dans le même module et toute variable nécessitant d'être modifiée à plusieurs endroits dans le code passerait de routine en routine comme argument de ces routines.
- question sur l'inclusion de l'interface avec DYNAMICO dans l'architecture actuelle
Tour de table virtuel:
- Ehouarn:
- Test ancienne physique r3989 sur Jean-Zay OK.
- N'a pas avancé sur le guidage
- Laurent
retour irene donc contrôle qualité quest (j'en vois le bout)
- Adriana
semaine passée passée ( ) sur "tutorial_prod" ; document ouvert (google-doc) pour documentation et FAQ, souhaitée collaboratif, ouvert ici (forme et contenu evolutif, à discuter...) :
https://docs.google.com/document/d/1OLZG6e-86NiXuv5-aALxKIh-QPkp4BdCwWtiBFot-6c/edit?userstoinvite=eghvignon%40gmail.com&actionButton=1
- Ionela
- Réussi à faire tourner le simulateur AIRS
- en local en séquentiel et en mode debug, après ajouts conditions supplémentaires
- sur jean-zay en séquentiel et en parallèle mixte (les 2 sans debug).
- Reste à faire/comparer les 2 sorties de jean-zay, avec mêmes fréquences calcul et écriture.
- Tuning LMDZ : définition (avec Frédéric) du travail à faire côté métriques 3D