Custom Query (96 matches)

Bug sur les poles pour le changement de repère avant et après couplage avec l'océan

Dans "etat0_netcdf", on a la déclaration :

real pls(iip1,jjp1,llm)

et l'appel :

CALL startget(varname, iip1, jjm, rlonv, rlatv, llm, pls, workvar, vvent, 0.0, jjp1, rlonu, rlatu, interbar )

Dans la procédure appelée, "startget_dyn", on a, pour cet appel précis :

iml = iip1 jml = jjm lml = llm

et la déclaration :

REAL, INTENT(in) :: pls(iml, jml, lml)

qui équivaut donc à :

REAL, INTENT(in) :: pls(iip1, jjm, llm)

Les profils des arguments "pls" effectif et muet ne correspondent donc pas. Les éléments des argument "pls" effectifs et muet sont associés en suivant l'ordre des éléments de tableau (le premier indice varie le plus vite, puis le second etc.). Donc, par exemple, on va avoir :

pls_muet(:, 1, 2) = pls_effectif(:, jjp1, 1)

Si, dans "startget_dyn", les trois dimensions de "pls" sont toujours interprétées comme longitude, latitude, niveau vertical alors on va utiliser comme valeurs au second niveau vertical et au pôle nord des valeurs qui correspondent en fait au premier niveau vertical et au pôle sud. Le décalage s'accentue au fur et à mesure qu'on progresse dans les éléments du tableau. On a par exemple ensuite :

pls_muet(:, 1, 3) = pls_effectif(:, jjp1-1, 2)

On utilise comme valeurs au troisième niveau vertical et au pôle nord des valeurs qui correspondent en fait au second niveau vertical et à la dernière latitude avant le pôle sud.

Inclusion d'un calendrier réaliste dans LMDZ.

Après discussion avec Frédéric et Lionel et interaction avec Phu, il faudrait intervenir à trois niveaux:

1. la lecture des conditions aux limites
2. le calcul de l'angle solaire
3. les sorties

En ce qui concerne les sorties, vu que IOIPSL ne doit pas pouvoir gérer cela (je ne vois pas comment dire à IOIPSL de sortir des moyennes mensuelles avec des mois à longueur variable dans une simulation annuelle), c'est au niveua du script de lancement que sera géré le problème.

Pour la calcul de l'angle solaire, on récupère la routine de calcul utilisée par LMDZ-planète qui sait gérer de "vraies" années.

Pour les conditions aux limites, l'idée c'est d'avoir un compteur de temps dans la dynamique (genre jour julien) et de faire la transformation au calendrier souhaité dans la physique (en utilisant les routines de gestions de calendrier disponibles dans ioipsl) et de lire les différents fichiers de conditions en calculant le numéro du jour dans l'année (comme actuellement mais avec des "vrais" jours).

On devrait donc disposer des calendriers 360jours, 365 jours et grégorien sans trop de travail supplémentaire.