Opened 15 years ago

Last modified 4 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 lguez)

"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 lguez

Description: modified (diff)

comment:2 Changed 15 years ago by lguez

Description: modified (diff)

comment:3 Changed 15 years ago by lguez

Description: modified (diff)

comment:4 Changed 4 years ago by Laurent Fairhead

Type: defectincoherences
Note: See TracTickets for help on using tickets.