2022/05/16
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 ",
sujet du jour: ré-organisation de physiq_mod.F90
Entame de la discussion en repartant de ce schéma
| Le monde du modèle LMDZ | le monde de la paramétrisation | |
| physiq_mod.F90 | PARAM | |
|
une suite d'appels à call_param(....) + forçages de PARAM call_convection() contiendrait l'aiguillage vers Tiedtke ou Kerry-Emmanuel MODULE call_convection()
|
2 modules: ini_param_mod(...) initialisation des variables de module utilisées par PARAM, calcul_param_mod(...) routine de calcul de PARAM, |
|
et en s'appuyant sur la ré-écriture de la paramétrisation WAKE. On a
- côté paramétrisation:
- une partie / un module initialisation de la paramétrisation: en particulier, on définit des variables de modules contenant les constantes physiques utilisées par la paramétrisation (et qui seront donc transmises au module calcul de la paramétrisation par un USE ) et on les initialise dans cette partie aux valeurs de la physique LMDZ
- une partie / un module "calcul" de la paramétrisation à laquelle on transmet les variables d'état nécessaires par arguments IN/OUT/INOUT
- côté LMDZ:
- un module physiq_mod.F90 qui est (a priori) une suite d'appels aux paramétrisations par des calPARAM
- des modules calPARAM qui sont les interfaces entre le "monde informatique LMDZ" et les paramétrisations
Cette séparation claire a l'avantage de faciliter l'échange de paramétrisations avec d'autres équipes / modèles.
En examinant l'appel à calWAKE dans physiq_mod.F90, on remarque que l'appel est "entouré" de lignes de codes qui "préparent" les variables d'état qui vont être passées à la paramétrisation. Ces "préparations" sont inhérentes à la recherche de l'équipe, les différents champs utilisés par la paramétrisation des wakes dépendent (peuvent dépendre) de la convection, des thermiques. Il est donc nécessaire de prévoir ces interactions entre paramétrisations. Elles peuvent être définies dans
- physiq_mod.F90, comme cela est fait pour l'instant. L'avantage est que toutes les tendances des paramétrisations sont remontées au module physiq_mod puisque c'est là que ce fait l'ajout des tendances; l'inconvénient est que cela nuit à la lisibilité du code
- dans chaque module calPARAM, l'avantage étant que chaque calPARAM explicite de façon autonome notre façon d'appeler la paramétrisation, l'inconvénient est qu'il faut alors prévoir un mécanisme de passage des tendances à chaque calPARAM qui pourrait en avoir besoin
Se posent enfin des questions d'interactions avec l'extérieur de la physique:
- les appels aux initialisations des paramétrisations doivent ils être inclus dans un IF (debut) dans physiq_mod comme à présent ou prévus dans les différents modules calPARAM?
- l'écriture et la lecture des restart doivent-elles 'splittées' entre paramétrisations?
- quid des sorties? il paraît admis que si chaque paramétrisation écrit ses propres sorties (plutôt que physiq_mod), celles-ci doivent se faire au niveau de l'interface avec le modèle, c'est-à-dire dans les modules calPARAM
Tour de table: