Custom Query (96 matches)

Le code s'attend à pouvoir lire les fichiers

• npCFMIP_param.data
• pointlocations.txt

qui définissent les points/stations sur lesquels on veut sortir des diagnostics même si cette sortie n'est pas activée.

Si ces fichiers ne sont pas présents, le code continue de tourner sans allouer et initialiser un certain nombre de variables qui sont passées en argument à phys_output_open qui peut donc recevoir des variables non allouées. On ne connaît pas le résultat d'un tel appel

Les fichiers de départ créés par ce0l ne semblent pas convenir pour la nouvelle physique, le modèle se plante dans un hgardfou dès le départ de la simulation. Problème de stabilité? erreur d'initialisation dans un des champs?

comme abordé brièvement lors du dernier poihl élargi, je me suis rendu compte qu'il y a quelques soucis avec la définition (ou non définition) des variables lev_hismth et ecrit_mth dans output.def.

1) lev_histmth

Si j'ai bien compris, dans le fichier output.def l'idée est de remplacer les anciens lev_* par : phys_out_filelevels= 5 2 2 5 5 5 qui remplit dans le modele la variable "lev_files".

Le pb vient de la variable lev_histmth qui, si elle n'est pas dans les .def, est mise par defaut à 2 (elle ne prend pas la valeur de lev_files)et lev_histmth est utilisée dans le modèle pour calculer ou pas des choses : titane1000 - /scratch/cont003/p86caub/VALIDATION_REF/modipsl/modeles/LMDZ4/libf/phylmd : grep lev_histmth * .... sw_aeroAR4.F90: IF (( lev_histmth .ge. 4 ) .or. ( .not. ok_ade )) THEN sw_aeroAR4.F90: IF (( lev_histmth .ge. 4 ) .or. ( .not. ok_aie )) THEN sw_aeroAR4.F90: IF (( lev_histmth .ge. 2 ) .or. (.not. ok_aie)) THEN sw_aeroAR4.F90: IF ( lev_histmth .ge. 4 ) THEN sw_aeroAR4.F90: IF ( lev_histmth .ge. 2 ) THEN

Et donc dans le cas ou on a seulement phys_out_filelevels= 5 2 2 5 5 5 et pas de lev_histmth=5 dans output.def on ne passera pas par les lignes ci dessus dans sw_aeroAR4.F90 (car lev_histmth aura la valeur par defaut du modèle cad 2) et les calculs sur les aerosols ne seront pas corrects.

2)ecrit_mth

Même genre de souci avec "ecrit_mth". L'idee avec output.def semble être de remplacer les ecrit_* par : phys_out_filetimesteps = 1.mth, 1.day, 0.25day, 0.125day, 0.125day, 1800.s

La variable "ecrit_mth" si elle n'est pas définie en dur dans l'output.def, prend la valeur par defaut du modèle qui est de 30. La partie COSP utilise "ecrit_mth" pour gerer sa frequence d'ecriture :

call phys_cosp(itap,dtime,freq_cosp,

$ ok_mensuelCOSP,ok_journeCOSP,ok_hfCOSP, $ ecrit_mth,....

Du coup, si "ecrit_mth" n'est pas defini dans output.def, alors il prend la valeur par defaut du modele qui est 30 et il y a un souci lorsqu'on est au mois de fevrier (28 jours).

Conclusion : j'ai observé un souci avec ces 2 variables dans mes tests avec LMDZ4_AR5. Je ne sais pas si ces bugs existent aussi avec LMDZ5. Mais je pense qu'il serait bien de corriger à la fois LMDZ5 (le cas échéant) et LMDZ4.

Merci d'avance,

Arnaud