1 / 11 Organisatorisches 1.Versionsarchiv für Dokumente: i.CMIP-CDOs.ppt als Diskussionsgrundlage ii.CDOandCMIP-Standard.docx (noch nicht) Wird auf der Grundlage des ppt‘s verfasst, und an ML, BS, JM, MC bis Mitte Oktober geschickt (zur WGCM Versammlung) 2.Eingabedateien zum Testen in: /work/ik0555/cmip5/archive/CMIP5/output/MPI-M/ 3.nächstes Treffen am Di. 8. Sep. 10:00 in Raum 207 DKRZ Action RB & ML : einige Tage vor der nächsten WGCM Sitzung erinnern, dass die Textform abgeschickt wird.

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 gilt: a)die Eingabedatei ifile enthält CMIP Variablen mit korrekter Einheit und Aggregation b)die Option var enthält eine komma-separierte Liste mit CMOR- oder MPI-ESM-Namen von CMIP tab-Variablen c)die Eingabedatei ifile enthält alle von CMOR benötigten Hilfs- und Koordinaten-Variablen (inkl. single-value Koordinaten) 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 „CMIP5-Variablen“ sind die in standard_output.xls

3 / 11 CMIP und CDOs 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. Bei der ESGF-Publikation muss dann die Annahme der Daten verweigert werden, mit den entsprechenden Auswirkungen auf den reibungsfreien Ablauf. 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 soll ein Befehl entwickelt werden, der benutzt werden kann, bzw. soll, um CMIP5 und später CMIP6+² Variablen durch Aufruf der CMOR-Bibliothek 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. ²DECK, CMIP6, und endorsedMIPs

4 / 11 A.Konforme Formatierung: cdo cmor,tab,[OPTION=value,...] ifile ofile-c Bemerkungen: 1.Die Ergebnisdatei ofile-c wird nur eine Variable enthalten, sonst ist sie nicht CMIP-konform. 2.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 (pcmor) gesetzt ist. Es muss im Auge behalten werden, dass sowohl die CDOs als auch die Skripte auch außerhalb des MPIs benutzt werden (sollen). 3. 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. Wenn die CDOs CMIP-konform arbeiten (s. Punkt B. oben), könnte man das auch mit einem nachgelagerten ‚cdo cat...‘ erledigen. CMIP und CDOs

5 / 11 CMIP und CDOs

6 / 11 CMIP und CDOs: Konforme CDOs B. Konforme CDOs die cdos liefern grundsätzlich so weit wie möglich CMIP konforme Dateien Hintergrund : Es soll auch möglich sein, die CDOs zu benutzen, um Datenverarbeitung durchzuführen ohne eine schon vorhandene Konformität unnötigerweise zu zerstören, bzw. eine CDO-Ausgabedatei soll grundsätzlich soweit wie möglich standardkonform sein, ohne allerdings den gewohnten WF der Wissenschaftler mit den CDOs einzuschränken. Ein Beispiel ist die Zusammenfassung mehrerer Variablen in einer Datei. Dabei sollen sich nicht die Metadaten (Dimensions-, Koordinatennamen,..) ändern, aber die Konformität ist damit natürlich zerstört. Schon ein konformer Dateiname ist nicht mehr möglich. Die Konformität müsste aber über den Aufruf ‘cdo cmor,tab,var=var,... ifile‘ wiederherstellbar sein. „So weit wie möglich“ bedeutet in diesem Zusammenhang, dass eine cdo-Ausgabedatei, die aus einer standard- konformen Eingabedatei entsteht, und die eine CMIP-Variable enthält, vollständig CMIP-konform sein sollte.

7 / 11 A.Konforme Formatierung 1. Ausbaustufe: Vorteil: wohldefinierte Schnittstellen und Zuständigkeiten transparenter Übergang CMIP5  CMIP6  CMIP7... implementierbar ohne weitere Ä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

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

9 / 11 A.Konforme Formatierung Bemerkungen : Der ‚shape‘-Parameter (siehe obige Folie unten rechts) ist problematisch für die Nutzer, es ist aber nicht klar, ob er abgeschafft werden kann. In CMIP5 wurde die shape-Angabe für das Chunking gebraucht, aber das soll ohnehin ‘generischer‘ werden. In cmor.x kann man vermutlich auch mit den Dimensionsangaben aus den NetCDF-Dateien leben. Dies ist auf jeden Fall erst mal die Richtung, in die gegangen wird. Die Tests werden mit dem DKRZ-Wrapper durchgeführt, was allerdings z.Z. nur für die CMIP5 Variablen möglich ist. Eine einfache, aber suboptimale, fall-back-Lösung wäre, die shape-Zuordnung über eine Tabelle zu pflegen. Es ginge aber nicht über eine MIP-Tabelle, sondern nur über eine zusätzliche Tabelle. Für nicht-CMIP-Variablen müssten dann 2 Tabellen gepflegt werden. Eine zweite suboptimale fall-back-Lösung wäre, die Übergabe eines shape-Parameters zu verlangen, aber viel Support zu geben (Ausgabe von möglichen 2D-shapes, 3D-shapes,...). Es muss aber auch möglich sein Daten von anderes ESMs zu verarbeiten – gegebenenfalls ohne genau zu wissen, wie die Gitter aussehen.

10 / 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 ofile-c X PCMDIMPI-M cdo cmor ifile cmorN.a ofile-c Name wird von CMOR gesetzt

11 / 11 Aufruf : cdo cmor,tab,var=varList[,[chunk=chunk,]expinfo=efile,userinfo=ufile,modinfo=mfile] ifile ofile-c Bemerkung: 1) varList ist eine komma-separierte Liste von zu tab gehörigen CMIP-Variablennamen. 2) e|u|mfile sind Dateinamen, in denen die von CMOR benötigten MD abgelegt sind. Zu den Dateien gibt es Default-Namen (s.u.), die beim Aufruf überschrieben werden können. 3) Der Default-Wert für chunk ist ‚replace‘, d.h. es wird eine neue Datei begonnen, statt die Daten an eine schon vorhandene Datei anzuhängen (chunk=append). 4)Falls es nicht möglich ist, den Namen der Datei, an die angehängt werden soll, projekt- und experimentunabhängig in cmor.x abzuleiten, muss – wie für CMIP5 gehandhabt – der Dateiname mit chunk übergeben werden. A.Konforme Formatierung

12 / 11 A.Konforme Formatierung: Eingabe* cdo cmor ifile cmor.xcmorN.a ofile-c ² optional ³ (hoffentlich) nicht benötigt ²³ hoffentlich aus den NetCDF- Dateien ableitbar user info file : ufile institute_id contact experiment info file:mfile model_id [references]² calendar source product experiment info file: efile branch_time basetime experiment_id forcing parent_experiment_id parent_experiment_rip initialisation_method physics_version realization [ comment history]² input/tabs/grids/arch_dir project_id command-line Eingabe varList: variable names tab: MIP table name realm³ shape²³ [chunk] ufile mfile efile ifile *Eingabe unabhängig von der Ausbaustufe

13 / 11 A.Konforme Formatierung: CommandLineEingabe cdo cmor,tab,var=varList,[chunk=chunk] ifile ofile-c cdo cmor ifile cmor.xcmor2.a ofile-c var: variable name (CV) tab: MIP table name (CV) realm (CV) shape ufile, efile, mfile ifile command-line Eingabe: 23. Juni 15 Name wird von CMOR gesetzt

14 / 11 A.Konforme Formatierung: CommandLineEingabe

15 / 11 A.Konforme Formatierung Verteilung der Parameter (bisher 2 NAMELISTs) auf dann 4: user info file : ufile institute_id contact command-line Eingabe [varList: variable names] tab: MIP table name realm shape [chunk] [ufile] [mfile] [efile] ifile &CMORCTRL INPUT_FILE=${input_file} CHUNK = “${chunk:-””}“ TABLE_ID = “${table_id}“ REALM = "${realm}“ REC_NUM = ${RecDay} OUT_FLAG = “${outflag:-”replace”}” SHAPE = "${shape}" ANZVARS = 1 var =tas unit =„K“ efile = amip_r1i1p1.ksh ufile = MPI-M.ksh mfile = MPI-ESM-LR.ksh / &CMORCONST INPUT_DIR = “${input_dir}“ TABS_DIR = "${tabs_dir}“ GRIDS_DIR = "${grids_dir}“ ARCH_DIR = "${arch_dir}“ PROJECT_ID = "${project_id}“ MODEL_ID = "${model_id}“ INSTITUTE_ID =“${institute_id}“ SOURCE = "${source}” CONTACT = “${contact}” CALENDAR = “${calendar}“ PRODUCT =„${product} EXPERIMENT_ID = "${exeriment_id}“ REALIZATION = "${realization:-1}“ INITIALISATION_METHOD = "${initialisation_method:-1}“ PHYSICS_VERSION = "${physics_version:-1}“ FORCING = "${forcing:-”N/A”}“ [HISTORY = "${history:-””}“] [COMMENT = "${comment:-""}“] [REFERENCES = "${references:-””}“] BASEYEAR = ${baseyear:-”0000”} PARENT_EXPERIMENT_ID = ${parent_experiment_id}“ PARENT_MEMBER_RIP = "${parent_member_rip}" BRANCH_TIME = ${branch_time} ZOSCONST = ${zosga},${zossga} / experiment info file:mfile model_id [references]² calendar source product experiment info file: efile branch_time baseyear experiment_id forcing parent_experiment_id parent_experiment_rip initialisation_method physics_version realization [ comment history] input/tabs/grids/arch_dir [project_id] 3 []: optional, d.h. es gibt Default [] 3 : optional in CMIP6, da jedem Experiment genau ein MIP zugeordnet werden soll

16 / 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‘ (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. 9. Juni 15

17 / 11 All realms / grids: 1.bnds => nb2 Action! 5.time:axis = "T„ geht verloren Action! 6.global history-Attribut anhängen: Action! E.g.: “Raw output...with IMDI...; CMOR rewrote...“ “Raw output...[with ‘infrastructure‘...]; CDO selname,cl ; CMOR rewrote......“ 7.tracking_id muss er-/gesetzt werden Action! 8.creation_date muss er-/gesetzt werden Action! 9.time:units = "days since’ ‘ :00:00" statt time:units = "days since’ ‘ :00:00" Action! 9. Juni 15 B. header–Vergleich nach cdo copy

18 / 11 Realm / grid atmos: 1.var:cell_measures = “area: areacella“ geht verloren; Action! 2.Location von areacella in var: associated_files = "baseURL: geht verloren; Action! 3.var:grid_type = “gaussian“ ; kein Pbl! 4.Single value dimension treatment by 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 ; 9. Juni 15 B. header–Vergleich nach cdo copy geht verloren Action!

19 / 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 Mögl. Lösung: “formula_terms“ in den CDOs behandeln wie ‚var:coordinates = „ “; ‚ Bemerkung: Es sollte darüber nachgedacht werden, ob man die Variablen auf ECHAM- Modellleveln erst mal außen vor lassen kann. Vielleicht gibt es aber hier nur ein Missverständnis. Bemerkung: die *_bnds: Attribute gibt es nur für die vertikale Koordinate der Atmosphäre ; dafür gibt es aber auch andere ‚formula-terms‘; 9. Juni 15

20 / 11 Realm / grid land: 1.float baresoilFrac(time, lat, lon) ; bareSoilFrac:coordinates = “type“; char type(strlen)² ; type:long_name = "surface type" type:standard_name = "area_type" ; 2.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 = "bare_ground" ; 9. Juni 15 B. header–Vergleich nach cdo copy geht verloren (s.o.) Action!

21 / Juni 15 B. header–Vergleich nach cdo copy

22 / Juni 15 B. header–Vergleich nach cdo copy

23 / Juni 15 B. header–Vergleich nach cdo copy

24 / 11 Realm / grid ocnBgchem: 1.single value vertical dimension (siehe realm/grid = atmos Punkt 4.): 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 ; 9. Juni 15 B. header–Vergleich nach cdo copy

25 / 11 Realm / grid atmos: 1.Vertical coordinate a.double ap_bnds(lev) verloren b.double b_bnds(lev) verloren 9. Juni 15 B. header–Vergleich nach cdo selname

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

27 / 11 Installation und Distributionen...