IPSLCM4_v2 on zahir (IBM at IDRIS)

zahir is the scalar MPP computer at IDRIS. ​http://www.idris.fr/su/Scalaire/zahir/index.html

The OS on next scalar MPP at IDRIS will be the same on Power 6. We need to prepare IPSLCM4/5 portability on Power6.

See also #40.

L'axe des temps du fichier dynzon (moyenne mensuelle sur 10 ans) ne convient pas.

Est-ce du à la version IOIPSL? Bascule en mars 2008 sur v_2_1_2.

Détails :

[Post_1M_dynzon]
Patches = (Patch_20070220_histcom_time_axis)
GatherWithInternal = (lon, lat, presnivs, time_counter)
TimeSeriesVars=()


Mais je crains que ca ne marche pas vu la description du problème donné par Patrick. Il semble que ce soit les valeurs de l'axe des temps qui soit mauvaises et non pas seulement la définition de l'axe des temps. Avec nco impossible de changer la valeur de l'axe des temps, avec cdo c'est possible. Nos patchs sont en nco.

Patrick propose de mettre des unités "days" au lieu de "seconds" dans l'axe de temps ; CF veut que la variable de temps soit un integer, donc si on met des days, impossible de décrire des fréquences de sorties sub-daily (exemple : 0,25 jours ...) de façon CF.

Ce problème est curieux, peut-être cela vient-il d'une modification depuis VV202, IOIPSL aurait changé ou la gestion du temps dans LMDZ ... Quand l'IDRIS aura démarré je regarderais le fichier.

@+
Sébastien

Marie-Alice Foujols a écrit :
>
> Bonjour Sébastien,
>
> je ne vois pas ce que j'ai pu oublier pour que le fichier dynzon issu de SE ne soit pas bon pour son axe des temps.
>
> Je revérifierai tout lorsque l'IDRIS aura redémarré.
> Si tu vois qq chose d'anormal dis-moi. je garde au chaud ce souci pour le moment.
>
> Il est clair pour moi que dans les tests précédents VV202M, ... le fichier dynzon  après SE avait un bon axe des temps.
> La série de l'été n'a pas le bon axe des temps. Voir commentaires de Patrick.
>
> Je fais bien appel au Post_1M_dynzon dans les card.
>
> http://forge.ipsl.jussieu.fr/igcmg/browser/CONFIG/trunk/IPSLCM4_v2/EXP00/COMP/lmdz.card
>
>         (dynzon.nc,       ${R_OUT_ATM_O_M}/${PREFIX}_1M_dynzon.nc,       Post_1M_dynzon), \
>
>
> Le Post_1M_dynzon existe plus loin :
>
> 77 <http://forge.ipsl.jussieu.fr/igcmg/browser/CONFIG/trunk/IPSLCM4_v2/EXP00/COMP/lmdz.card#L77>     [Post_1M_dynzon]
> 78 <http://forge.ipsl.jussieu.fr/igcmg/browser/CONFIG/trunk/IPSLCM4_v2/EXP00/COMP/lmdz.card#L78>     Patches = ()
> 79 <http://forge.ipsl.jussieu.fr/igcmg/browser/CONFIG/trunk/IPSLCM4_v2/EXP00/COMP/lmdz.card#L79>     GatherWithInternal = (lon, lat, presnivs, time_counter)
> 80 <http://forge.ipsl.jussieu.fr/igcmg/browser/CONFIG/trunk/IPSLCM4_v2/EXP00/COMP/lmdz.card#L80>     TimeSeriesVars=()
>
>
> J'ai juste cela autour des fichiers dynzon des séries VV202 .
>
> Merci pour ton éclairage.
>
> A+
> MAF
>
>
>
>
>
> -------- Message original --------
> Sujet :     Re: aide sur fichier netcdf dynzon
> Date :     Mon, 29 Sep 2008 13:00:41 +0200
> De :     Brockmann Patrick <Patrick.Brockmann@cea.fr>
> Pour :     Marie-Alice Foujols <Marie-Alice.Foujols@ipsl.jussieu.fr>
> Copie à :     HOURDIN Frederic <Frederic.Hourdin@lmd.jussieu.fr>, FAIRHEAD Laurent <Laurent.Fairhead@lmd.jussieu.fr>
> Références :     <48E09D3B.4040800@ipsl.jussieu.fr>
>
>
>
> Marie-Alice Foujols a écrit :
> > Bonjour Patrick,
> >
> > j'ai un souci de tracé de courbes depuis les fichiers netCDF issu de > LMDZ, les fichiers dynzon.
> >
> > Est-ce que tu veux bien m'aider?
> >
> > Frédéric l'a remarqué sur tous les fichiers dynzon des tests des > différentes résolutions et j'essaye de comprendre comment le > contourner pour faire les tracés et comment l'éviter à la source. Je > t'ai joint le plus petit fichier (71x12)
> >
> > Ce sont des moyennes zonales donc des tableaux 2D latitude - temps ou J-L
> >
> > Les courbes pour chacun des mois
> > plot atotvt[l=1]
> > plot/ov atotvt[l=7]
> > passent bien et pour les 12 valeurs, 12 mois.
> >
> > Lorsque je veux faire la moyenne des 12 valeurs on met juste @ave et > cela donne comme le premier mois.
> >
> > plot atotvt[l=@ave]
> >
> > Si on déploie le calcul (1+2 ...+12)/12 cela passe.
> >
> > Qu'y a-t-il qui empêche de faire cette moyenne?
> >
> > Est-ce un souci dans le time_counter? Lequel?
> > Si c'est le cas, il faudra le changer à la base dans les sources LMDZ
> > et à la main dans les fichiers existants.
> >
> > Merci beaucoup pour ton aide et les informations.
> > Marie-Alice
> >
> >
> >
> Bonjour,
> Oui en effet, je confirme le problème.
> Il vient du fait que dans le fichier netCDF, il y a des valeurs à 1E+13 indiqués
> pour l'axe des temps. ferret se perd un peu puisque sa représentation des nombres
> est en floatant simple précsion  donc avec une précision de 1E+6.
>
> Il serait bien de ne pas utiliser des secondes pour l'axe des temps
> et je propose que les codes utilisent les unités "days" plutôt que "seconds"
> En attendant, la démarche lorsqu'on rencontre un problème de ce type est de regarder
> via un ncdump la tête de la variable time_counter.
>
> *************************************************
> Voici aussi comment gérer ce problème via ferret:
>
> ! Regarder l'axe : tout est à 0
> show grid/t atotvt
>
> ! Plot incorrect
> plot atotvt[l=1], atotvt[l=7], atotvt[l=@ave]
>
> ! Définition d'un nouvel axe (placé sur 1950 mais représentant la décade 1950-1959)
> ! Lire à ce propos http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.3/ch07s04.html
> def axis/t="15-JAN-1950":"15-DEC-1950":30/units="days"/cal=360_days mytaxis
> show axis/t mytaxis
>
> ! Définition d'une nouvel variable
> let new_atotvt=atotvt[gt=mytaxis@asn]
>
> ! Plot maintenant correct
> plot new_atotvt[l=1], new_atotvt[l=7], new_atotvt[l=@ave]
>
> *************************************************
> Autre solution pour corriger en dur le fichier, utiliser cdo avec la ligne suivante:
> cdo settaxis,1950-01-15,12:00,1month R97E_SE_1950_1959_1M_dynzon.nc newfile.nc
>
>
> Patrick
>
>
> -- 
> LSCE/IPSL, Laboratoire CEA-CNRS-UVSQ
> Data Analysis and Visualization Engineer
> IPSL Global Climate Modelling Group
> mailto:Patrick.Brockmann@cea.fr
> 01.69.08.32.24 --> LSCE (Orme des merisiers 712, Bureau 11)
> 01.44.27.21.10 --> IPSL (Jussieu, Tour 45-55, 3eme)
> http://www.ipsl.jussieu.fr/~brocksce/
> -- 
>
>   


-- 
Sébastien Denvil
IPSL, Pôle de modélisation du climat
UPMC, Case 101, 4 place Jussieu, 75252 Paris Cedex 5

Tour 45-55 3ème étage Bureau 303A
Tel: 33 1 44 27 21 10
Fax: 33 1 44 27 61 71

Install and test IPSLCM4_v2 on vargas (IDRIS) IBM Power6.

See also ​wiki page (ipsl/vivaipsl)