1 / 11 Organisatorisches 1.Die Dokumente CDO-CMOR_Konforme-Formatierung.ppt und Konforme_CDOs.ppt sind wieder zu einem Dokument zusammengefasst (alter.

Präsentation zum Thema: "1 / 11 Organisatorisches 1.Die Dokumente CDO-CMOR_Konforme-Formatierung.ppt und Konforme_CDOs.ppt sind wieder zu einem Dokument zusammengefasst (alter."—  Präsentation transkript:

1 1 / 11 Organisatorisches 1.Die Dokumente CDO-CMOR_Konforme-Formatierung.ppt und Konforme_CDOs.ppt sind wieder zu einem Dokument zusammengefasst (alter Name: CDO-CMOR). 2.Zunächst weiterhin hochgeladen auf : https://code.zmaw.de/projects/cdo/wiki/CMORhttps://code.zmaw.de/projects/cdo/wiki/CMOR 3.Zusätzlich in https://svn.dkrz.de/mad/Model/cmor-support/trunk/cmor-projs/cdo-cmor/cmor-doc 4.Eingabedateien zum Testen in: mistral:/work/ik0555/cmip5/archive/CMIP5/output/MPI-M. 5.Eine Testversion der CDOs gibt es unter: mistral:/home/zmaw/m214003/local/bin/cdo 6.Die Sourcen gibt demnächst unter: https://code.zmaw.de/projects/cdo/fileshttps://code.zmaw.de/projects/cdo/files 7.Wie soll der Datenaustausch (Programme etc.) stattfinden ? 1.versioniert 2.Lösung für de.CMIP6-Partner (AWI, DLR, FUB,…, MPI-M,…) 1.SVN? 2.Redmine? 3.GitHub? 4.GitLab? *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 BMBF-Projekt ‚CMIP6-DICAD‘ Verbund-Projekt: Verbund 1 (DKRZ, DLR, DWD,FUB) + Verbund 2(DLR, Uni Bonn) Teilprojekt1 (DKRZ) in Verbund 1: „Aufbau und Betrieb des Nationalen CMIP6-Datenarchivs und einer Infrastruktur zur Datenqualitätssicherung“ 4 Stellen beantragt und so gut wie bewilligt, 1 davon für CDO- Entwicklung (4 Jahre), deren Aufgaben: CDO-Operator für konforme Formatierung Konforme CDOs Metadatenmodell o Datenmodell o Klimaindizes Steve Bjoernson * RI W

3 3 / 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); 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; der kann dann mit dem CDO Kommando ‚‘cdo –g gridfile cmor …‘ übergeben werden. B.die cdos liefern grundsätzlich so weit wie möglich CMIP-konforme Dateien und 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; *

4 4 / 11 CMIP und CDOs Die folgenden Seiten befassen sich zunächst mit der konformen Formatierung, d.h. der Entwicklung eines ‚cdo cmor...‘ Operators. Dieser Aspekt ist auch zeitlich dringlicher, da der Operator für CMIP6 vorhanden sein sollte. Im Folgenden wird dann der Aspekt der ‚konformen CDOs‘ betrachtet. A.Konforme Formatierung Hintergrund: Die Erfahrung mit Daten, die zur ESGF-Publikation eingereicht wurden, zeigt, dass nicht erwartet werden kann, dass eine CMIP-konforme Formatierung erreicht wird, ohne die CMOR-Bibliothek zu benutzen. Die ESGF-Publikation muss dann verweigert werden, mit den entsprechenden Auswirkungen auf den reibungsfreien Ablauf mit korrigierten Daten. Wenn alles schief geht, kann es passieren, dass die Daten unter falschen Instituts-, Modell-, oder Experimentnamen im ESGF liegen, und von den Datennutzern nicht gefunden werden können. Deshalb sollen die CDOs in die Lage versetzt werden, gegen die CMOR-Lib zu linken, um CMIP5 und später CMIP6+² Variablen entsprechend den Projekt-Standards zu formatieren. Es wird angestrebt, dass dieser Operator auch von Programmierern benutzt wird, die vorher schon mit der CMOR-Bibliothek gearbeitet haben. Das bedeutet, dass das Verhalten des CDO-Operators dem der CMOR-Bibliotheks-Aufrufe möglichst nahe kommen sollte. B. Konforme CDOs und A. Konforme Formatierung Grundsätzlich besteht die Möglichkeit, dass der CDO-Operator ‚cmor‘ überflüssig wird, nämlich dann, wenn die konformen CDOs vollständig CMIP-konforme Dateien liefert. Bis dahin ist aber noch ein weiter Weg: sämtliche Ozeandaten wurden unter B. noch nicht behandelt, bestimmte Landdaten fehlen noch, Gitter-projektionen, ein-wertige vertikale Achsen,.... ²DECK, CMIP6, und endorsedMIPs

5 5 / 11 A.Konforme Formatierung: cdo [-m parTab ] cmor,tab,[OPTION=value,...] ifile ofile-c Bemerkungen: 1.Der Name der Ausgabedatei ist durchgestrichen, um zu erinnern, dass er nicht gesetzt werden kann! 2.Es müssen nicht alle tab-Variablen in i-file enthalten sein. 3.Die Ergebnisdatei ofile-c wird nur eine Variable enthalten, sonst ist sie nicht CMIP-konform. Das wird durch die CMOR-Bibliothek sichergestellt. 4.Da die Erfahrung zeigt, dass nicht garantiert werden kann, dass die Dateien mit den verlangten Namen abgegeben werden, solange Freiheiten in der Namensgebung bestehen, soll der Name der Ausgabe-Datei, der von CMOR gesetzt wird, nicht veränderbar bzw. nicht anzugeben sein. Es können Konflikte zwischen den Use- Cases aus dem WF der Wissenschaftler, die normalerweise weniger Restriktionen wünschen, und Use-Cases im Zusammenhang mit der Aufbereitung für das offizielle CMIP-Archiv entstehen. Z.B. könnte gewünscht werden, den ofile-c Namen angegeben zu können, wenn im WF der Wissenschaftler der vorgeschriebene Name nicht akzeptabel ist. Die gewünschten Freiheiten sollen zulassen werden, wenn ein bestimmter environment-Parameter (CDO_PS_CMOR) gesetzt ist. Es muss im Auge behalten werden, dass sowohl die CDOs als auch die Skripte auch außerhalb des MPIs benutzt werden (sollen). _CDO_CMOR_Expert_MODE: von der CMOR-Bibliothek abweichendes Verhalten in Bezug auf die Eingabe (z. B. kein Check/Forderung von ‚positive‘) CMIP und CDOs

6 6 / 11 A.Konforme Formatierung: cdo cmor,tab,[OPTION=value,...] ifile ofile-c Bemerkungen (cntd): 5.cdo cmor muß wg. der operationellen Kettenverarbeitung auch die append-Funktion der CMOR2 Bibliothek ermöglichen. Für den täglichen WF bei der Datenverarbeitung und Analyse ist das nicht zwingend notwendig, und es kann auch der Befehl ‚cdo cat...‘ benutzt werden. Dazu müssen aber zunächst die CDOs CMIP-konform arbeiten (s. Punkt B. oben). Wg. der kommenden CMIP6-Aktivitäten und den damit verbundene Terminen kann nicht riskiert werden, sich von B. oder C. abhängig zu machen. Eventuell gibt es auch Performanzgründe für die Benutzung der CMOR-Append-Funktionalität. Das Schlüsselwort ist oflag mit den Werten ‚replace‘ oder ‚append‘. 6.Die CMOR2-Bibliothek prüft, ob the Flussrichtung (‚positive‘ Attribut) angegeben ist, falls verlangt, und ob die Einheiten angegeben sind; letzteres immer. Gegebenenfalls wird das Vorzeichen der Fluss-Variablen geändert, und die Werte der Variablen werden so modifiziert, dass sie die richtigen Einheiten haben (udunit). Soll also die unveränderte Standard-CMOR-Bibliothek benutzt werden, muss als OPTION-Schlüsselwort ‚pos‘ mit den Werten ‚u‘ für ‚up‘ oder ‚d‘ für ‚down‘ gegeben werden falls verlangt. Das Vorzeichen der Variablenwerte wird gegebenenfalls von der CMOR-Library geändert. Entsprechend werden von der udunit-Bibliothek die Variablenwerte an die geforderten Einheiten angepasst, wenn die eingegebenen Einheiten nicht den Verlangten entspricht. Ein ccp-flag _CDO_CMOR_EXPERT_MODE ist eingeführt, das die CMOR-Library die beiden Checks überspringen lässt (fertig für ‚positive; demnächst für die Einheiten). Das ginge natürlich auch über einen ProgrammSchalter, erfordert aber mehr Eingriffe in den Quellcode. CMIP und CDOs

7 7 / 11 A.Konforme Formatierung: Bemerkungen (cntd): 7. cdo cmor soll in der Lage sein, gewünschte Variablen unter den in der Eingabedatei enthaltenen Variablen auswählen zu können. Diese müssen alle zur selben MIP-Tabelle tab gehören und werden als Liste (kommasepariert?) mit der Option übergeben. Der Default für die Option vars soll sein, alle Variablen in einer Datei CMIP-konform aufzubereiten. Dazu müssen sie zu derselben MIP-Tabelle tab gehören. Ein nicht zu tab gehöriger Name würde – wenn er in einen CMOR-Bibliotheksaufruf übergeben wird, einen Abbruch durch die Bibliothek erzeugen. Wenn es gewünscht ist, dass solche Variablen einfach nur ignoriert werden, müsste vor den CMOR-Bibliotheksaufrufen sichergestellt werden, dass die MIP-Tabellen gelesen werden, um gegebenenfalls eine Warnung auszugeben, und zur Verarbeitung der nächsten Variablen überzugehen. Dies soll nur mit dem CDO_PS_CMOR Umgebungsparameter ermöglicht werden, denn vi.die Standard-Reaktionen der Software sollten unabhängig davon sein, über welche Schnittstelle (CDOs, andere Programme) die CMOR-Bibliotheksaufrufe getätigt werden. vii.Es könnten sich mit dem vars-Defaultwert Probleme ergeben, wenn sich Variablen in der Datei befinden, die als Hilfsvariablen für andere Targetvariablen verwendet werden (z.B. ps für cl). Das bleibt abzuwarten. viii.Im operationellen Gebrauch in Skripten möchte man die Anzahl der Variablen für eine ausgewogene Lastbilanz vorgeben können, ohne die Verteilung der Variablen in einzelnen Dateien ändern zu müssen. Wg. der Performanz wird eventuell auf einen Aufruf mit mehreren Variablen verzichtet werden (aber nicht auf die Option). CMIP und CDOs

8 8 / 11 CMIP und CDOs OK!

9 9 / 11 CMIP und CDOs: Zeitplan A.Konforme Formatierung mit den CDOs sollte mit den aufgelisteten Funktionalitäten möglich sein, wenn die Verarbeitung der CMIP6- Projektergebnisse beginnt. Also nach dem derzeitigen Stand Jul 2016. Hier ist die erste Ausbaustufe (s.u.) gemeint, nicht nur der DKRZ- Wrapper. Das BMBF-Projekt started vermutlich Juli 2016. Dann wird mit der Modifikation in Richtung ‚letzte Ausbaustufe‘ begonnen. Wie viele Stufen es dazwischen gibt, und ob sie ‚released‘ werden, bleibt den Projektmitarbeitern vorbehalten. Alle Stufen nach der ersten sollten aber für den Nutzer transparent bleiben. Rückfalllösung für CMIP6: Jörg‘s Programm mit Wrapper B.Projektaufgabe und MPI-M

10 10 / 11 A.Konforme Formatierung 1. Ausbaustufe: Vorteil: wohldefinierte Schnittstellen und Zuständigkeiten transparenter Übergang CMIP5  CMIP6  CMIP7... implementierbar ohne größere Änderungen der CDOs eventuell Tabelle mit Zuordnung : CMIP-Variablenname ECHAM-,JSBACH-,MPIOM-,HAMOCC-CodeNummern zusätzliche/lokale CMIP Tabelle(n) mit lokalen Variablen/Experimenten möglich cdo cmor ifile cmor.xcmorN.a ofile-c DKRZPCMDIMPI-M Name wird von CMOR gesetzt

11 11 / 11 CMIP[5,6,...] und CDOs IMDI/CMOR Postprocessing workflow für CMIP5 Experimente cmor.a NetCDFfiles(shape**) cmor.x

12 12 / 11 A.Konforme Formatierung letzte Ausbaustufe: Die Verarbeitung in cmor.x wird Schritt für Schritt ?² in die CDOs verschoben. In der letzten Stufe werden die CMOR Bibliothek-Aufrufe in den CDOs getätigt: DKRZPCMDIMPI-M cdo cmor ifile cmor.xcmorN.a/so ofile-c X PCMDIMPI-M cdo cmor ifile cmorN.a ofile-c Name wird von CMOR gesetzt ² da Jörg‘s CMOR.x-Program nicht fertig ist, müssen wir festlegen, wie der workflow bei der Zusammenarbeit mit Mathis sein soll committ mails?: MR:kein Bedarf

13 13 / 11 Übergang *.f90  *.c : Wrapper (Cdo), Info(Metadaten)Dateien, compile Skript, und *.f90 in SVN-trunk http://svn-mad.dkrz.de/svn/mad/Model/cmor-support/trunk/cmor-progs/cdo-cmor Libraries in http://svn-mad.dkrz.de/svn/mad/Model/cmor-support/trunk/cmor-libs/cmor2-lib MIP- und Variablen-Zuordnungstabellen in http://svn-mad.dkrz.de/svn/mad/Model/cmor-support/trunk/cmor-projs/cdo-cmor/tables Grundsätzlich ist das Ziel, das f90-Programm durch ein c-Programm, abzulösen, das direkt in die CDOs integriert werden soll. Um bis dahin entspannter arbeiten zu können, wird das F90-Programm bis zur endgültigen Fertigstellung weiterentwickelt. Der Übergang zum c-Programm kann dann in der Geschwindigkeit des Bearbeiters erfolgen. Das Vorgehen könnte geändert werden, wenn im CMIP6-Support-BMBF-Projekt die Stelle mit einem c-Experten besetzt werden kann. Dann ist zu diskutieren und zu entscheiden, wie die Arbeitsteilung zwischen ANW und DM weiterlaufen soll. Auf jeden Fall brauchen wir ab dem Zeitpunkt, an dem das f90-Programm nicht mehr weiterentwickelt wird, einen Bearbeiter für das c- Programm, der Vollzeit für diese Aufgabe zur Verfügung steht. A.Konforme Formatierung

14 14 / 11 A.Konforme Formatierung: Eingabe* cdo cmor ifile cmor.xcmorN.a ofile-c ² optional ³ nicht benötigt ²³ hoffentlich aus den NetCDF- Dateien ableitbar user info file : ufile institute_id institution contact table_dir model info file:mfile model_id [references]² calendar source grid_dir grid_file et al. experiment info file: efile project_id product branch_time req_time_units experiment_id forcing parent_experiment_id parent_experiment_rip member [ comment history]² et al. command-line Eingabe tab [einzige mandatory] vars oflag userinfo modinfo expinfo oper cval pos units time gfile ifile

15 15 / 11 Aufruf : cdo –m cmor,...[,info=file1,...,fileN[,gridinfo=gfile] [...] ifile ofile-c Bemerkungen: 1.info enthält eine kommaseparierte Liste mit beliebig vielen Dateinamen, in denen die von CMOR benötigten MetaDaten abgelegt sind. Zu den Dateien gibt es Default-Namen und eine Default- Hierachie, die beim Aufruf überschrieben werden können. 1.Defaultverzeichnisse für info=… Dateien: i.$HOME nur wenn info=.cdocmorinfo (default) ii.. nur wenn info=.cdocmorinfo (default) iii.vollständiger Pfad (inkl. filenamen) in der Kommandozeile 2.Die Dateien fileL, L=1,N enthalten Zeilen: attribute-name=attribute-value. 3.Default: eine Datei mit Namen.cdocmorinfo in $HOME oder./ 4.gfile gibt eine CF-konforme NetCDF-Datei an, aus der Gitterinformationen gelesen werden. Ein ESM kann mehrere Gitter, und damit mehrere Gitterinformationsdateien haben. Diese Dateien werden nur benötigt, wenn nicht alle erforderlichen Gitterangaben in ifile stehen. Die Angaben in gfile gehen vor, oder? 5.mfile ist die Zuordnungstabelle; Format s.u. A.Konforme Formatierung

16 16 / 11 A.Konforme Formatierung: CommandLineEingabe cdo [-m mfile] cmor,tab,[vars=varList][...] \ ifile ofile-c Bemerkungen: 1.Die Angabe von tab ist erforderlich und muss einer MIP-Tabelle entsprechen; keine Prüfung auf CV, damit lokale Tabellen möglich sind; Abbruch, wenn die verlangte Tabelle nicht existiert ($table_dir/‚project_id‘_‘tab‘). Alle anderen Parameter sind optional. 2. varList ist eine komma-separierte Liste von zu tab gehörigen Variablen. Die Variablennamen müssen den CMIP-Kurznamen entsprechen. Wenn eine Datei mit Zuordnungstabelle in mfile angegeben ist, wird geprüft, ob der Variablenname aus tab in der Zuordnungstabelle steht. Wenn das so ist, werden dort die Aggregation, Codenummern, lokale Variablennamen, ‚positive‘- Flussrichtungen, und tatsächliche Einheiten ausgelesen. Wenn diese Angaben mit der Kommandozeile übergeben werden, haben die Angaben in der Komandozeile Vorrang.

17 17 / 11 A.Konforme Formatierung: CommandLineEingabe cdo cmor,tab,[...[,oflag=output-mode][...] ifile ofile-c 5.Der output-mode kann die Werte ‚replace‘ oder ‚append‘ annehmen: Falls es mehrere Dateien gibt, an die auf Grund ihrer Dateienamen angehängt werden könnte, wird eine Warnung ausgegeben, und die jüngste Datei wird ausgewählt. Wenn oflag nicht besetzt ist, wird eine neue Datei angelegt (Default=replace). Die Namen von Dateien, die sich zum Fortschreiben eigenen, können sich nur in dem ersten Datum des am Ende des Dateinamens angegebenen Zeit-Bereichs unterscheiden. Der Dateiname – bis auf dieses Datums – wird im CMOR-Programm konstruiert. Dasselbe gilt für die Verzeichnisstruktur. Dateinamen werden mit System-Calls aufgelistet. Bei oflag=append wird das letzte Datum im vorherigen Chunk in der CMOR-Darstellung aus dem ersten Zeitwert im aktuellen Chunk und der Frequenz hergeleitet. Sollte es mehrere Dateien mit der entsprechenden Namensbasis im Arbeitsverzeichnis geben, wird die neueste Datei ausgewählt. ls –lrt: tas_MPI-ESM-P_historical_r1i1p1_190501-190912.nc tas_MPI-ESM-P_historical_r1i1p1_190001-190912.nc tas_MPI-ESM-P_historical_r1i1p1_191001-191912.nc

18 18 / 11 A.Konforme Formatierung: CommandLineEingabe cdo cmor,... [pos=direction[,units=unit][,time=cell_method] ifile ofile-c 6.Der Wert für direction kann die Werte ‚u‘ oder ‚d‘ annehmen, und gibt die Richtung positiver Flüsse an. Die Richtung ist auch in der standard_output-Tabelle notiert. Wenn die beiden Angaben nicht übereinstimmen, wird durch CMOR das Vorzeichen geändert. Es ist nicht möglich, die Angabe wegzulassen, auch nicht, wenn gewährleistet ist, dass das Vorzeichen der Variablen den Vorgaben entspricht. K.T. ist gefragt worden, ob CMOR optional auf die Angabe verzichten könnte. Es wurde freigestellt, die Änderung lokal vorzunehmen. Z. Z. wird ein _CDO_CMOR_EXPERT_MODE cpp-flag für die Aktivierung einer lokalen Option benutzt. Das soll mal ein Umgebungsparameter regeln, oder? 6.Für unit gilt Entsprechendes: bei Nicht-Übereinstimmung werden die Werte der Variablen mit udunit geändert. wenn die CMOR-Library unverändert benutzt wird. Dann MUSS aber bei jedem Aufruf eine Einheit mitgegeben werden, bzw. jede zu verarbeitende Variable muss über die Zuordnungstabelle mit einer Einheit versehen werden. In der Regel sollte das aber mit CDO-Operatoren gemacht werden, d.h. die CDOs dürfen Angaben, die für den Projektstandard nötig sind, nicht ignorieren (siehe B. Konforme CDOs). Umgebungsparameter bzw. cpp-flag für die CMOR-Bibliothek wie in 6. 7.Bei Aufruf der CMOR-Routinen muss angegeben werden, welche cell_method die Zeitachse benutzt. Mögliche Werte sind ‚point‘, ‚mean‘, oder ‚clim. Bei ‚point‘ müssen keine time_bnds angegeben werden. Da die time_bnds den CMOR-Routinen übergeben werden müssen, ist es nicht möglich, auf die Angabe zu verzichten, d.h. sie muss entweder über die Kommandozeile, oder über die Zuordnungstabelle kommen.

19 19 / 11 A.Konforme Formatierung: ‘shape‘

20 20 / 11 CDIs gridTypes GRID GAUSSIAN ECHAM GRID LONLAT GRID LCC GRID SPECTRAL GRID GME ICON? GRID CURVILINEAR GRnm, TPnm GRID UNSTRUCTURED FE(S)OM? GRID REFERENCE else: GRID GENERIC A.Konforme Formatierung: Gitter CMOR bekannte Gitter ( = CF-Standard grid_mapping list): 1.albers_conical_equal_area 2.azimuthal_equidistant 3.lambert_azimuthal_equal_area 4.lambert_conformal_conic 5.lambert_cylindrical_equal_area 6.latitude_longitude 7.mercator 8.orthographic 9.polar_stereographic 10.rotated_latitude_longitude? 11.stereographic 12.transverse_mercator 13.vertical_perspective

21 21 / 11 CDIs gridTypes GRID GAUSSIAN ECHAM GRID LONLAT GRID LCC GRID SPECTRAL GRID GME ICON? GRID CURVILINEAR GRnm, TPnm GRID UNSTRUCTURED FE(S)OM? GRID REFERENCE else: GRID GENERIC A.Konforme Formatierung: Gitter CF: grid_mapping_name = latitude_longitude; no parameter coordinates float lat(lat) ; lat:long_name = "latitude" ; lat:units = "degrees_north" ; lat:standard_name = "latitude" ;

22 22 / 11 A.Konforme Formatierung: Gitter CMOR bekannte Gitter ( = CF-Standard grid_mapping list):... 10. rotated_latitude_longitude.... int rotated_latitude_longitude (=:rll) rll:grid_mapping_name = “rotated_latitude_longitude“ rll:grid_north_pole_latitude = 80; rll:grid_north_pole_longitude = 180; rll:north_pole_grid_longitude = 0; (optional; def=0) double rlat(rlat) ; rlat:long_name = “grid_latitude" ; rlat:units = "degrees" ; rlat:standard_name = “grid_latitude" ; float lat(rlat,rlon)... float lat_vertices(rlat,rlon,4) float tas(rlat,rlon); tas:grid_mapping = “rll”; tas: coordinates = “height lat lon”; CF + CMIP5 convention

23 23 / 11 CMOR bekannte Gitter ( = CF-Standard grid_mapping list): albers_conical_equal_area azimuthal_equidistant lambert_azimuthal_equal_area lambert_conformal_conic lambert_cylindrical_equal_area latitude_longitude mercator orthographic polar_stereographic rotated_latitude_longitude stereographic transverse_mercator vertical_perspective A.Konforme Formatierung: Gitter

24 24 / 11 a)Über die CommandLineEingabe wird der Projekt-Kurzname der Variablen eingegeben: i.in der Zuordnungstabelle (default ? ‚ESM|component‘_‘project_id‘.txt) wird dem Kurznamen der lokale Name oder ein GRIB-Code zugeordnet, mit dem die Variable in den Eingabedateien gespeichert ist. Beispiel: MPIESM1_CMIP5.txt (Kopie von Kalles echam6cmip5_last_version) c[ode]=3-byte integer [default=000/‘ ‚?] n[local (model) variable name]=‚local name‘[default=CMIP-unit; optional] o[ut_name]=abc [no default, mandatory, CV] u[nits]=‚udunit‘[default=CMIP-unit; optional] c[ell_method]=‚time aggregation‘[m(default)|p|c, CV; mandatory] p[ositive]=‚flux direction‘[u|d|“ “(default), CV, optional] b)Granularität der Tabellen echam6_CMIP5.txt MPI-ESM1_CMIP5.txt... oder hamocc_CMIP6.txt MPI-ESM2_CMIP6.txt c)Die lokale Änderung der CMOR-library ist nicht nötig, wenn noch positive=u/d und unit=„...“ in den Zeilen der Zuordnungstabelle aufgenommen würde. A.Konforme Formatierung: Zuordnungstabelle für GRIB Codes, Modellnamen, etc... &parameter code=123 name=modnam output_name=projnam unit=„...“ positive=u|d time_cell_method=p|m/c (&parameter c=123 n=modnam o=projnam u=„...“ p=u|d time_cell_method=p|m/c)...

25 25 / 11 Kommentarcharacter: ! Versionierung der ParTabs: im Modell- Quellcode und projektbezogen. (Unterdirectoy in util, neben src) Namen der Tabellen: Vorschlag Kalle: pro Ausgabedatei – MPIOM-, HAMOCC-, ECHAMx-, JSBACH- usw../expressions/mpiom_data_2d_mm./expressions/hamocc_data_3d_ym./mappings/echam6cmip5all Zumindest in MPI-OM können die Ausgabedateiamen per Namelist geändert werden. Dadurch ist die Variante fehleranfällig. A.Konforme Formatierung: Zuordnungstabelle für GRIB Codes, Modellnamen, etc

26 26 / 11 MPI-ESM-LR (T63,L47) 1 Variable, 5 Jahre, 1 L, tgl. Daten: Real/User/Sys = 8.1/7.3/0.7 sec 3 Variablen, 10 Jahre, 1 L, monatliche Daten: Real/User/Sys = 5.2/1.9/0.9 sec (NetCDF) 3 Variablen, 10 Jahre, 1 L, monatliche Daten: Real/User/Sys = 5.8/2.4/2.0 sec (GRIB) 3 Variablen, 10 Jahre, 1 L, monatliche Daten: Real/User/Sys = 3.7/2.1/1.3 sec (GRIB; Datei wie oben) 1 Variable, 20 Jahre, 1 L, tgl. Daten: Real/User/Sys = 26.6/24.6/1.9 sec (GRIB, 538 MB) das gesamte Programm 16 sec nur für CMOR-Calls Cdo cmor,‘table‘ wird vermutlich nicht so oft benutzt A.Konforme Formatierung: Performanz

27 27 / 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.

28 28 / 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

29 29 / 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.

30 30 / 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)

31 31 / 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;

32 32 / 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!

33 33 / 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!

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

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

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

37 37 / 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

38 38 / 11 time:units = "days since 1949-12-1 00:00:00" ; nv4 = 4 ; x = 194 ; y = 201 ; < double rlat(rlat) ; < double rlon(rlon) ; float lat(y, x) ; float lat_bnds(y, x, nv4) ; float lon(y, x) ; float lon_bnds(y, x, nv4) ; float tas(time, y, x) ; lat:bounds = "lat_bnds" ; lon:bounds = "lon_bnds" ; B. Konforme CDOs Gitter (ncdump –h) vor ( ) cdo copy

39 39 / 11 B. Konforme CDOs Gitter (ncdump –h) vor ( ) cdo copy > lat:_CoordinateAxisType = "Lat" ; > lon:_CoordinateAxisType = "Lon" ; < rlat:axis = "Y" ; < rlon:axis = "X" ; < rlat:long_name = "latitude in rotated pole grid" ; < rlat:standard_name = "grid_latitude" ; < rlat:units = "degrees" ; < rlon:long_name = "longitude in rotated pole grid" ; < rlon:standard_name = "grid_longitude" ; < rlon:units = "degrees" ; < int rotated_latitude_longitude ; < rotated_latitude_longitude:grid_mapping_name = "rotated_latitude_longitude" ; < rotated_latitude_longitude:grid_north_pole_latitude = 90. ; < rotated_latitude_longitude:grid_north_pole_longitude = 180. ; < rotated_latitude_longitude:north_pole_grid_longitude = 0. ; < tas:grid_mapping = "rotated_latitude_longitude" ;

40 40 / 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

41 41 / 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) B. header–Vergleich nach cdo Operationen

42 42 / 11 Speicherung und Kommunikation: Redmine (Wiki, Repository über links, nur Lesen) GitHub: externe Speicherung, frei; d.h. die ganze Welt kann darauf zugreifen, Wiki, Repository GitLab: im eigenen Netz: https://gitlab.dkrz.de Jeder Nutzer muss aktiviert werden, sonst wie GitHub Noch keine Entscheidung! A.und B. Kommunikation und Software-Austausch

43 43 / 11 A. und B. : Installation und Distributionen... statische/dynamische Anbindung an CMOR Verteilung mit conda?

44 44 / 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?