Aller au contenu. | Aller à la navigation

Outils personnels

Navigation
Vous êtes ici : Accueil / Le coin des développeurs / CR de réunions / POIHL / 2022/05/16

2022/05/16

Compte rendu du poihl du 16/05/2022

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
  + sorties spécifiques à PARAM

l'aiguillage vers les différentes paramétrisations des différents processus se ferait dans call_param(), par exemple:
call_convection() contiendrait l'aiguillage vers Tiedtke ou Kerry-Emmanuel

MODULE call_convection()
....
forçages convection
....
IF (first) THEN
  IF (tiedtke) THEN
      CALL ini_tietdke_mod(...)
  ELSE IF (ke) THEN
      CALL ini_ke_mod(...)
  ENDIF
ENDIF
...
IF (tiedtke) THEN
    CALL calcul_tietdke_mod(...)
ELSE IF (ke) THEN
    CALL calcul_ke_mod(...)
ENDIF
....
sorties convection
END MODULE

 

2 modules:

ini_param_mod(...)

     initialisation des variables de module utilisées par PARAM,
    
appelé une seule fois au premier appel de la physique

calcul_param_mod(...)

      routine de calcul de PARAM,
     
appelée à tous les pas de temps

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:

    Laurent

    • commit xios dans dyn3dmem

    Adriana
    •  guidage : documentation des scripts ; màj de l'info ; systématisation de l'info sur site LMDz et LMDZPedia finalisée avec Laurent
    • simulation zoomée sur Maroc avec correction de biais : running (2006/2014)
    • tutorial_prod : tests croisés avec versions IOIPSL du modipsl*.tar et v_2.2.5, et revs Orchidee CMIP et 2_2 ; plantages avec certaines combinaisons ; 
      • conclusion: Laurent va passer à IOIPSL à jour v_2.2.5 dans modipsl.tar, en rajoutant ce qu'il faut pour pouvoir continuer à compiler avec gmake (en plus de makeioipsl_fcm) pour le cas OR-CMIP6 ; il va ajuster install_lmdz.sh en conséquence
    Ajouter un commentaire

    Vous pouvez ajouter un commentaire en complétant le formulaire ci-dessous. Le format doit être plain text. Les commentaires sont modérés.

    Enter the word