Opened 15 years ago
Last modified 5 years ago
#21 new incoherences
"day_ini" dans "create_etat0_limit" et "gcm"
Reported by: | lguez | Owned by: | Laurent Fairhead |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | LMDZ | Keywords: | |
Cc: |
Description (last modified by )
"create_etat0_limit" est actuellement incompatible avec "gcm" en ce qui concerne la définition de la variable "day_ini". "day_ini" est évalué dans "gcm" au premier jour de la simulation courante et ne change plus au cours de la simulation. Sauf erreur, avant les modifications de Laurent, "day_ini" était le nombre de jours depuis le 1er janvier de "annee_ref". Mais Laurent a semblé considérer que "day_ini" était le nombre de jours depuis la date de référence "(annee_ref, day_ref)". Cela se voit à la ligne 222 de "leapfrog.F" :
jD_cur = jD_ref + (day_ini - 1) + int (itau * dtvr / daysec)
Le problème est que "etat0_netcdf" est toujours écrit selon l'ancienne définition de "day_ini". Si bien que si on crée par exemple un état initial avec "create_etat0_limit" avec :
day_ref = 331 annee_ref = 1980
calendrier de 360 jours, on démarre dans "gcm" avec :
day_ini = 331
d'où un jour courant au 1er novembre 1981. Et les erreurs qui vont avec ça dans "physiq" pour la position sur l'orbite, etc.
L'ancienne définition de "day_ini" semble aussi avoir cours dans "pbl_surface" et "cpl_init" :
idayref = day_ini CALL ymds2ju(annee_ref, 1, idayref, 0.0, zjulian)
Change History (4)
comment:1 Changed 15 years ago by
Description: | modified (diff) |
---|
comment:2 Changed 15 years ago by
Description: | modified (diff) |
---|
comment:3 Changed 15 years ago by
Description: | modified (diff) |
---|
comment:4 Changed 5 years ago by
Type: | defect → incoherences |
---|