Opened 16 years ago
Last modified 5 years ago
#21 new incoherences
"day_ini" dans "create_etat0_limit" et "gcm" — at Initial Version
| Reported by: | lguez | Owned by: | Laurent Fairhead |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | LMDZ | Keywords: | |
| Cc: |
Description ¶
"create_etat0_limit" est actuellement incompatible avec "gcm" en ce qui concerne la gestion du temps. Le problème vient de 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 calendrier de 360 jours on démarre dans "gcm" avec un jour courant au 1er novembre 1981. Et les erreurs qui vont avec ça dans "physiq" pour la position sur l'orbite, etc.
