1 / 11 Organisatorisches 1.Dokumente in: https://code.zmaw.de/projects/cdo/wiki/CMOR https://code.zmaw.de/projects/cdo/wiki/CMOR i.CDO-CMOR_Konforme-Formatierung.ppt.

Präsentation zum Thema: "1 / 11 Organisatorisches 1.Dokumente in: https://code.zmaw.de/projects/cdo/wiki/CMOR https://code.zmaw.de/projects/cdo/wiki/CMOR i.CDO-CMOR_Konforme-Formatierung.ppt."—  Präsentation transkript:

1 1 / 11 Organisatorisches 1.Dokumente in: https://code.zmaw.de/projects/cdo/wiki/CMOR https://code.zmaw.de/projects/cdo/wiki/CMOR i.CDO-CMOR_Konforme-Formatierung.ppt als Diskussionsgrundlage ii.Konforme CDOs.ppt 2.Eingabedateien zum Testen in: mistral:/work/ik0555/cmip5/archive/CMIP5/output/MPI-M. 3.Eine Testversion der CDOs gibt es unter: mistral:/home/zmaw/m214003/local/bin/cdo 4.Die Sourcen gibt demnächst unter: https://code.zmaw.de/projects/cdo/files https://code.zmaw.de/projects/cdo/files 5.Über die Klimaindizes reden !!! später.... *Jeder will Großes erreichen, ohne sich darüber im Klaren zu sein, dass das Leben aus kleines Sachen besteht. Steve Bjoernson * RI W

2 2 / 11 CMIP[5,6,...] und CDOs Ziele: A.es gibt einen cdo operator „cmor“ mit cdo cmor,tab,[OPTION=value,...] ifile ofile-c der CMIP-konforme Ausgabedateien erzeugt, falls a)-b) erfüllt sind: a)die Eingabedatei ifile enthält CMIP Variablen mit korrekter Aggregation; die Einheit kann mit Hilfe der udunit-Bibliothek (in CMOR) oder durch Übergabe von geeigneten Operatoren + Operanden geändert werden; b)die Eingabedatei ifile enthält alle von CMOR benötigten Hilfs- Variablen (z.B. inkl. single-value Koordinaten); c)die Koordinatenvariablen können auch in einem separaten Grid-file enthalten sein; B.die cdos liefern grundsätzlich so weit wie möglich CMIP-konforme Dateien C.eine cdo-Ausgabe von CMIP-konformen Eingabedateien ist so weit wie möglich CMIP-konform (cdo ifile1-c... ifileN-c ofile-c) „file-c“ sind soweit wie möglich CMIP-konforme Dateien „so weit wie möglich“: vollständig für CMIP-Variablen „CMIP-Variablen“ sind die in standard_output.xls für CMIP5; für CMIP6 steht die Liste noch nicht fest;

3 3 / 11 B. Konforme CDOs B. die cdos sollen so weit wie möglich CMIP konforme Dateien liefern Vergleiche header von allen CMIP5 Dateien in /work/ik0555/.../esmrcp85/ mit den headern derselben Datei, wenn sie von einem CDO-Operator verarbeitet wurden: experiment_id=‚esmrcp85‘ oder ‚historical‘(Experiment mit vermutlich den meisten Variablen) Die Vergleiche sind inkrementell, d.h. was schon mit ‚cdo copy‘ notiert wurde, wird beim Vergleich für einen nächsten CDO-Operator nicht mehr erwähnt; was schon für eine Modellkomponente (realm/grid) notiert wurde, wird beim Vergleich für eine andere Komponente nicht mehr erwähnt.

4 4 / 11 All realms / grids: 1.bnds => nb2 ok! 5.time:axis = "T„ geht verloren ok! 6.global history-Attribut anhängen: ok! mit --history E.g.: “Raw output...with IMDI...; CMOR rewrote...“ “Raw output...[with ‘infrastructure‘...]; CDO selname,cl ; CMOR rewrote......“ 7.tracking_id muss er-/gesetzt werden ok! (wird neu gesetzt) Nee! 8.creation_date muss er-/gesetzt werden ok! (wird übernommen) 9.time:units = "days since’ ‘850-01-01 00:00:00" statt time:units = "days since’ ‘850-1-1 00:00:00" ok! (ev. KT, CD fragen) B. header–Vergleich nach cdo copy

5 5 / 11 Realm / grid atmos: 1.var:cell_measures = “area: areacella“ geht verloren; action! 2.Location von areacella in var: associated_files = "baseURL: http://......“ geht verloren; ok! 3.var:grid_type = “gaussian“ ; kein Problem! 4.Single value dimension in CMOR (siehe andere Beispiele unten): Beispiel: float sfcWind(time, lat, lon) ; sfcWind: coordinates = "height" ; double height ; height:axis = "Z" ; height:long_name = "height" ; height:positive = "up" ; height:standard_name = "height" ; height:units = "m" ; ² data: height = 2 ; B. header–Vergleich nach cdo copy geht nicht mehr verloren; aber wird nicht erzeugt ok! Bjorn hat ‚zugesagt‘ dass das Problem am MPI-M registriert wurde.

6 6 / 11 B. header–Vergleich nach cdo copy Realm / grid atmos: 1.Vertical coordinate a.lev:standard_name verloren b.lev:formula = "p = ap + b*ps" ; c.lev:formula_terms = "ap: ap b: b ps: ps" ; d.lev_bnds:formula e.lev_bnds:formula_terms="ap: ap_bnds b: b_bnds ps: ps" f.lev_bnds:standard_name verloren lev_bnds:units g.double [ap|b](lev) verloren h.[ap|b]_bnds(lev, x); dimension x statt bnds i.float ps(time, lat, lon) verloren j.b_bnds:units = „1“ b:units = „1“ zugefügt; no pbl! (nicht nötig für CF, aber inkonsequent in CMOR (ap/b_bnds verschieden behandelt)

7 7 / 11 B. header–Vergleich nach cdo copy Realm / grid atmos: 1.Vertical coordinate Lösung: Die Erzeugung von konformen Variablen auf Modellebenen wird mit der Benutzung von Jörg‘s Programm und der CMOR-Bibliothek realisiert. Darüber hinaus wird die im CMIP5-Standard benutzte Beschreibung von Variablen auf Modellleveln bei einer Bearbeitung mit den CDOs beibehalten Bemerkung: Die *_bnds: Attribute müssen für die vertikale Koordinate der Atmosphäre aufgeführt werden, da die ‚bounds‘ entgegen der für den NetCDF-Standard verwendeten Annahme eine eigene Form für ‚formula-terms‘ haben;

8 8 / 11 Realm / grid land: 1.Surface type coordinates/single value dimension float baresoilFrac,c3ftFrac,c4ftFrac(time, lat, lon) ; c3PftFrac: coordinates = „type“ ; c4PftFrac: coordinates = „type“ ; char type(strlen) ; type:long_name = "surface type" type:standard_name = "area_type" ; data: type = "bare_ground" ; data: type = "" ; B. header–Vergleich nach cdo copy geht verloren (s.o.) Action!

9 9 / 11 Realm / grid land: 1.Coordinates besides x,y,z,t Dimension type = 13 => lev = 13 strlen = 34; float landCoverFrac(time, type, lat, lon) landCoverFrac:coordinates = "type_description" ; char type_description(type, strlen) ; type_description:long_name = "plant functional type" ; type_description:standard_name = "area_type" ; data: type_description = „glacier “,...; mit LES reden; B. header–Vergleich nach cdo copy verloren double lev(lev) lev:axis = „Z“; lev: long_name = „generic“; lev:units = „level“; eingefügt Action!

10 10 / 11 B. header–Vergleich nach cdo copy

11 11 / 11 B. header–Vergleich nach cdo copy

12 12 / 11 B. header–Vergleich nach cdo copy

13 13 / 11 Realm / grid ocnBgchem: 1.single value dimension : bfe:coordinates = "lat lon" ; statt bfe:coordinates = "depth lat lon" ; double depth ; depth:axis = "Z" ; depth:long_name = "depth" ; depth:positive = "down" ; depth:standard_name = "depth" ; depth:units = "m" ; data: depth = 0 ; 2.fddtalk, fddtdic, fddtdife, fddtdin, fddtdip, fddtdisi: depth:bnds = „depth_bnds“ ; double depth_bnds(bnds) ; B. header–Vergleich nach cdo copy

14 14 / 11 Realm / grid atmos: 1.float ps(time, lat, lon) geht verloren als Hilfsvariable in cl,cli,clw ok! ps:... Vorschlag: cl:ancillary_variables = “ps" ; ???????????????????? float ps(time, lat, lon) ps:... B. header–Vergleich nach cdo selname

15 15 / 11 Alle: 1.frequeny : a)frequeny = „freq“ aus CMIP5 CV (fx,yr,mon,day,6hr,3hr,subhr) setzen ok! b)frequency updaten (z. B. bei monmean) Action! 2.Was passiert mit verschiedenen Attributwerten bei Modellensembles? a)model_id = ““ b)model_id = „differing values in input files“ c)model_id = „MPI-ESM-*“ bei MPI-ESM-LR und MPI-ESM-P d)model_id = „MPI-ESM-LR MPI-ESM-P“ 3.Was passiert mit verschiedenen Attributwerten bei Simulationenensembles? a)realization = * b)realization = „1,2,11,13“ Use Cases: I.ESMValTool II.Ensemble-Modell-Daten im ESGF III.Ensemble-Modell-Daten aus dem ESGF (processing auf dem Datenserver) IV.Normaler Datennutzer (z.B. am MPI-M) C. header–Vergleich nach cdo operations

16 16 / 11 Zu diskutieren: I.Inwieweit ist es sinnvoll, die Modelle diese Dateien erzeugen zu lassen? II.Soll cdo cmor auch GRIB Daten lesen/ausgeben können? III.Brauchen wir eine Liste mit Use-Cases?

17 17 / 11 Installation und Distributionen... statische/dynamische Anbindung an CMOR Verteilung mit conda?