2023/02/13
Liens utiles:
- le lien gotomeeting pour la visio: https://www.gotomeet.me/EMC3_LMDZ/poihl
- la page des liens utiles: https://lmdz.lmd.jussieu.fr/le-coin-des-developpeurs/cr-de-reunions/poihl/liens_utiles
Poihl "Infrastructure / Architecture"
Infos générales:
- 1er sprint de fermeture de ticket jeudi dernier, va falloir accélérer la cadence si on veut tous les fermer dans un temps raisonnable :-)
- des modifications sont en cours sur install_lmdz.sh, bien récupérer la dernière version avant utilisation
- au prochain poihl, on discute des tests de validation des versions de référence: envoyez vos propositions de tests et vos candidatures de responsables.
sujet du jour: ré-organisation de physiq_mod.F90 (suite)
On a bien deux axes de ré-organisation / ré-écriture de la physique du modèle:
- une ré-écriture des paramétrisations en elles-même pour les adapter au format replay
- une ré-organisation / ré-écriture du moniteur de la physique (en gros physiq_mod.F90) pour le rendre plus efficace / lisible / modulaire / compréhensible
On considère donc deux "mondes" pour la physique du modèle:
- le monde de la paramétrisation qu'on doit rendre indépendant du modèle utilisé (et qui passe donc, a priori, par le format replay)
- le monde du modèle LMDZ avec ses interfaces vers les paramétrisations. Il faut donc coder ces routines d'interface (exemple calltherm.F90, calwake.F90)
On aimerait séparer physiq_mod.F90 en de gros blocs indépendants (convection/nuages, couche limite / interface surface, ondes de gravité, rayonnement) mais le découpage même et l'agencement des différents blocs est un enjeu de recherche.
On sent qu'une autre discussion sur les sorties est nécessaire: les programmes tel CMIP demandent des sorties qui peuvent dépendre de l'interprétation du modèle plutôt que de la paramétrisation. Ce genre de sortie se fera donc nécessairement dans le monde 'LMDZ' plutôt que dans le monde 'paramétrisation'. les sorties doivent donc être gérées au niveau interface modèle / paramétrisation plutôt que dans la paramétrisation.
Se pose la question du rôle du moniteur de la physique, que doit-il faire?
- initialisations: champs du restart, champs des conditions aux limites, initialisations diverses (paramétrisations, couplage, sorties)
- appel des paramétrisations selon le schéma temporel choisi
- gestion des sorties (variables de sorties, champs du restart)
On examine le fichier physiq_mod.F90. En début de chaque appel au moniteur, les variables d'état passées par la dynamique sont recopiées dans des variables propres au moniteur (les *_seri) qui vont évoluer au fur et à mesure des appels aux différentes paramétrisations. A la fin du moniteur, on calcule les tendances totales que l'on transfère à la dynamique. On prend l'exemple de l'appel à reevap qui se trouve en début d'appel de la physique comme exemple de ce qu'on voudrait pour chaque appel aux paramétrisations:
- en variables d'entrée: les variables d'état (t_seri, ...)
- en sortie les tendances calculées par cette paramétrisation
Les tendances calculées par chaque paramétrisation sont rajoutées aux variables d'état de travail (les *_seri) par la routine générale phys_add_tend qui permet de faire des contrôles sur les valeurs des champs (c'est là qu'est appelée hgardfou).
Points divers constatés à l'étude de physiq_mod.F90:
- les déclarations locales en save pourraient passer en variables de module
- sur les 5410 lignes de physiq_mod.F90, 1200 sont des déclarations de variables, et 1000 sont liées à l'initialisation (... if debut ...)
1er chantier: décomposer physiq_mod.F90 en un 'iniphysiq' et un 'physiq'.
Question: les initialisations des paramétrisations doivent-elles apparaître dans iniphysiq ou dans les routines d'interface aux paramétrisations?
Recrues pour le chantier: J. Derouillat, Y. Meurdesoif, T. Dubos, F. Hourdin, E. Vignon, L. Fairhead, autres?