Custom Query (98 matches)

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

Sur Curie, un débordement dans la fonction lnblnk fait planter LMDZ dans le couplé IPSLCM5A.

Ci-joint une version corrigée. A long terme, je suggère de supprimer lnblnk au profit de LEN_TRIM.

Olivier

! ! $Header$ !

INTEGER FUNCTION lnblnk (letter)

C-------------------------------------------------------- C Fonction qui determine la longeur d'un string sans les C blancs qui suivent. C--------------------------------------------------------- C ARGUMENTS C +++++++++ C letter: CHARACTER*xxx (xxx < imax) C le string dont on determine la longuer C lnblnk: INTEGER C le nombre de characteres C

IMPLICIT NONE

CHARACTER (LEN=*), INTENT (in)

letter

lnblnk = LEN_TRIM ( letter )

RETURN END

Intégration des modifications développées par U. Gérard durant son stage pour interfacer Xios à LMDZ