Organisatorisches 1 Die Dokumente CDOCMORKonformeFormatierung ppt und KonformeCDOs

  • Slides: 54
Download presentation
Organisatorisches 1. Die Dokumente CDO-CMOR_Konforme-Formatierung. ppt und Konforme_CDOs. pptx sind wieder zu einem Dokument

Organisatorisches 1. Die Dokumente CDO-CMOR_Konforme-Formatierung. ppt und Konforme_CDOs. pptx sind wieder zu einem Dokument zusammengefasst (Name: CDO-CMOR. pptx). 2. Zunächst weiterhin hochgeladen auf : https: //code. zmaw. de/projects/cdo/wiki/CMOR 3. Zusätzlich in https: //svn. dkrz. de/mad/Model/cmor-support/trunk/cmor-projs/cdo-cmor/doc 4. Eingabedateien zum Testen in: mistral: /work/ik 0555/cmip 5/archive/CMIP 5/output/MPI-M. 5. Eine Testversion der CDOs gibt es unter: mistral: /home/zmaw/m 214003/local/bin/cdo 6. Den Quellcode gibt demnächst unter: https: //code. zmaw. de/projects/cdo/files *Jeder will Großes erreichen, ohne sich darüber im Klaren zu sein, dass das Leben aus kleines Sachen besteht. 27. 10. 2020 10: 57 1 / 11

BMBF-Projekt ‚CMIP 6 -DICAD‘ Verbund-Projekt: Verbund 1 ‘DICAD‘ (DKRZ, DLR, DWD, FUB) + Verbund

BMBF-Projekt ‚CMIP 6 -DICAD‘ Verbund-Projekt: Verbund 1 ‘DICAD‘ (DKRZ, DLR, DWD, FUB) + Verbund 2 ‘Chemie‘ (DLR, Uni Bonn) Teilprojekt 1 (DKRZ) in Verbund 1: ‚‘DICAD TP-1‘ „Aufbau und Betrieb des Nationalen CMIP 6 -Datenarchivs und einer Infrastruktur zur Datenqualitätssicherung“ 4 Stellen bewilligt, 1 davon für CDO-Entwicklung (4 Jahre), deren Aufgaben: ü ü o 27. 10. 2020 10: 57 CDO-Operator für konforme Formatierung Konforme CDOs ü Metadatenmodell o Datenmodell Klimaindizes 2 / 11

CMIP[5, 6, . . . ] und CDOs: Ziele A. Konforme Formatierung es gibt

CMIP[5, 6, . . . ] und CDOs: Ziele A. Konforme Formatierung es gibt einen cdo operator der CMIP-konforme Ausgabedateien erzeugt, falls: a) die Eingabedatei CMIP Variablen mit korrekter Aggregation enthält; b) alle von CMOR benötigten Hilfs-Variablen zugänglich (z. B. scalar-zcoordinate ‘keyword=szc‘) sind ; B. Konforme CDOs 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 CMIPkonform (cdo <operator> ifile 1 -c. . . ifile. N-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 in standard_output. xls für CMIP 5 festgelegt; für CMIP 6 steht die Liste noch nicht fest; 27. 10. 2020 10: 57 3 / 11

CMIP[5, 6, . . . ] und CDOs: Zeitplan A. Konforme Formatierung mit den

CMIP[5, 6, . . . ] und CDOs: Zeitplan A. Konforme Formatierung mit den CDOs sollte mit den aufgelisteten Funktionalitäten möglich sein, wenn die Verarbeitung der CMIP 6 -Projektergebnisse beginnt. Also nach dem derzeitigen Stand September 2016. Das BMBF-Projekt ist Juli 2016 gestartet. Zu der Zeit wurde mit der Entwicklung des CDO-Operators ‚cmor‘ in Richtung ‚letzte Ausbaustufe‘ (s. u. ) begonnen. Die Entscheidung, wie viele Stufen es dazwischen gibt, und ob sie ‚released‘ werden, bleibt dem Projekt vorbehalten. Alle Stufen nach der ersten sollten aber für den Nutzer transparent bleiben. Rückfalllösung für CMIP 5/6: Jörg‘s FORTRAN-Programm mit DKRZ-Wrapper. A. Konforme CDOs ist Aufgabe des Projekts und des MPI-Ms. Die folgenden Seiten befassen sich zunächst mit der konformen Formatierung, d. h. der Entwicklung eines ‚cdo cmor. . . ‘-Operators. Im Folgenden wird dann der Aspekt der ‚konformen CDOs‘ betrachtet. Grundsätzlich besteht die Möglichkeit, dass der CDO-Operator ‚cdo 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. . . 27. 10. 2020 10: 57 4 / 11

A. Konforme Formatierung Hintergrund: Die Erfahrung mit Daten, die zur ESGF-Publikation eingereicht wurden, zeigt,

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 CMIP 5 und später CMIP 6+²-Variablen entsprechend den Projektstandards 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. Es wäre wünschenswert, wenn bis zum Start der CMIP 6 -Experimente möglichst alle CMIP-Variablen direkt aus den Modellen mit den CMIP-Namen ausgegeben werden könnten. Aber das ist unrealistisch. ²DECK, CMIP 6, und endorsed. MIPs 27. 10. 2020 10: 57 5 / 11

Konforme Formatierung <-> Konforme DCOs Die konforme Formatierung mit dem CDO-CMOR-Operator dient primär dazu,

Konforme Formatierung <-> Konforme DCOs Die konforme Formatierung mit dem CDO-CMOR-Operator dient primär dazu, Modell(roh)daten in CMIP-konforme Daten zu überführen. Um reibungsfreie Abläufe bei der Publikation zu schaffen, sollte die Fehlermöglichkeit durch die Anwender so weit wie möglich eingeschränkt werden. Das bedeutet, dass alles, was im ‚cdo cmor, . . ‘-Operator inkl. CMORn-Bibliothek berechnet werden kann, dort auch berechnet werden soll. Dazu gehören: • Verzeichnisstruktur • kann in CMOR 2/3 aus-/eingeschaltet werden (d. h. Projekt-DRS oder. /). Projekt-DRS ist das default-Ausgabe-Verzeichnis für ‘cdo cmor, . . . ‘. Für die Ausgabe in ‘. /‘ muss (? ? ? keyword=? ? ? ) angegeben werden. Action: Jörg die Regeln für die Verzeichnisstruktur (oder für die Dateinamen ? ) kann für CMOR 3 angegeben werden; deshalb sollte es möglich sein, Regeln für lokale Projekt vorzugeben • eine ‚eigene‘ DRS soll nicht ermöglicht werden; gegebenenfalls können die Daten im ‚current working directory‘ abgelegt werden (s. o. ), und müssen dann in die gewünschten Verzeichnisse verschoben werden. • die konformen CDOs werden die Struktur ohnehin nicht erzeugen (können? ) 27. 10. 2020 10: 57 6 / 11

Konforme Formatierung <-> Konforme DCOs • Dateiname • wird für verlangte CMIP-Variablen von CMOR

Konforme Formatierung <-> Konforme DCOs • Dateiname • wird für verlangte CMIP-Variablen von CMOR 2/3 erzeugt; sollte ein anderer Name gewünscht werden, muss ein ‚mv‘ durchgeführt werden (s. o) • die ‚konformen‘ CDOs werden dagegen keinen Standard-/Default-Namen setzen (können) 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 vorzugeben 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 CMIPArchiv entstehen. Z. B. könnte gewünscht werden, Namen(spattern) für die Ausgabedatei(en) angegeben zu können. Die gewünschten Freiheiten könnten zulassen werden, wenn ein bestimmter Umgebungs-Parameter (Vorschlag: CDO_PS_CMOR) gesetzt ist. Es muss im Auge behalten werden, dass der CDO-CMOR-Operator und die Skripte auch außerhalb des MPIs benutzt werden (sollen). 27. 10. 2020 10: 57 7 / 11

Konforme Formatierung <-> Konforme DCOs • Inhalt • die Ausgabedatei wird nur eine verlangte

Konforme Formatierung <-> Konforme DCOs • Inhalt • die Ausgabedatei wird nur eine verlangte CMIP-Variable enthalten (plus assoziierte Variablen) • die ‚konformen CDOs‘ können diesbezüglich freier sein • es wird aber angestrebt, dass die ‚konformen CDOs‘ die CMIP-assoziierten Variablen berücksichtigen, mitnehmen, reklamieren, … • Dateigröße • es gibt weder eine maximale noch minimale Dateigröße (Anzahl Zeitebenen) • die Anzahl der Zeitebenen wird gesetzt durch • das Projekt (z. B. CORDEX) • die Anzahl Zeitebenen in der Ursprungsdatei • indem Zeitebenen an vorhandene Dateien angehängt werden (keyword: outflag=a (append)) • der Name der Datei, an die angehängt werden wird, wird in ‚cdo cmor, …‘ erzeugt (entsprechend der Projekt-Vorgaben) • die konformen CDOs werden Namen nicht kennen, gegebenenfalls muss ‘cdo cat. . ‘ benutzt werden 27. 10. 2020 10: 57 8 / 11

A. Konforme Formatierung • Koordinaten • x-/y-Achsen • Richtung • geograpische lat/lon-Gitter (grid_mapping=latitude-longitude) •

A. Konforme Formatierung • Koordinaten • x-/y-Achsen • Richtung • geograpische lat/lon-Gitter (grid_mapping=latitude-longitude) • x/lat : -90 Grad-Nord -> +90 Grad-Nord • y/lon: 0 Grad-Ost – 360 Grad-Ost • Korrektur in ‘cmor-lib, cmor-prog, …‘ Action: Jörg • auf regulären Gittern können die bnds_lat/lon berechnet werden • die Ecken (vertices ) von curvilinear Gittern werden berechnet, wenn nicht mitgeliefert; • z-Achse • Richtung • von der Grenzfläche Atmosphäre/Ozean wegzeigend • Atmosphäre: nach oben • Land, Ozean : nach unten Action: Jörg • Korrektur in ‚cmor-lib, cmor-prog, …‘ • die Zellränder (bounds) werden berechnet, wenn sie nicht in den Dateien vorhanden sind (alle Werte sind zentriert) • computes all from ap_bnds & b_bnds, needs sea level pressure and P 0(101325 Pa) ? ? ? 27. 10. 2020 10: 57 9 / 11

A. Konforme Formatierung • Zeit-Achse s. keyword ‘cm‘ (cell_method ) • Metadaten • zu

A. Konforme Formatierung • Zeit-Achse s. keyword ‘cm‘ (cell_method ) • Metadaten • zu vielen Net. CDF-Attributen gibt es DRS-Elemente aus denen Dateinamen und Verzeichnisse aufgebaut werden • cmor 2/3 prüft die Vollständigkeit von • institute_id, institution, contact • model_id, calendar, source, references • project_id, product, member, experiment_id, time_units • parent_experiment_id, parent_experiment_rip, forcing, branch_times (CMIP 5) • dving_model_id, driving_experiment_name , cordex_domain (CORDEX ) • andere, schon vorhandene Net. CDF-Attribute gehen beim Passieren von cmor 2/3 verloren • beliebige andere als die Standardattribute sind erlaubt • mit den konformen CDOs sollen alle Attribute erhalten bleiben; • Attribute, die auch CMIP-Attribute sind, werden umbenannt: ‘? ? ? <attribute>? ? ? ‘ 27. 10. 2020 10: 57 10 / 11

A. Konforme Formatierung • controlled vocabularies (CV) • ein Teil der Attribute verlangt Werte

A. Konforme Formatierung • controlled vocabularies (CV) • ein Teil der Attribute verlangt Werte aus vorgegebenen CVs • ein anderer Teil verlangt Werte aus abgestimmten CVs (z. B. model_id) • einige erlauben beliebige Strings (z. B. references) • sollen die abgestimmten CVs schon vor dem Aufruf von cmor-Routinen abgefragt werden? • Menge des outputs • cdo-Option –W (extra warnings) verbosity=1 (alle Warnungen) • cdo-Option –v (extra details) verbosity=2 (alle Infos & Warnungen) • der cdo-Output ist disjunkt; ‘cdo cmor, . . . ‘ wird das genauso machen • no z-axis 3 rd dimension • How to get char. value vectors (e. g. basins, oline) into cdo cmor? Options: ifile, gfile, mapping table, keyword ? ? ? 27. 10. 2020 10: 57 11 / 11

A. Konforme Formatierung Syntax: cdo cmor, mip. Table[, keyword=keyvalue(s), . . . ] ifile

A. Konforme Formatierung Syntax: cdo cmor, mip. Table[, keyword=keyvalue(s), . . . ] ifile ofile-c Bemerkungen: 1. Der Operator heißt ‚cmor‘. 2. Der Operator ruft die Cmor-Bibliothek. 3. mip. Table ist eine der MIP-Tabellen des Projekts. Die Variablen, die in einem Aufruf verarbeitet werden sollen, müssen alle zur selben MIP-Tabelle gehören. Es gibt keine Prüfung auf CV, damit lokale Tabellen möglich sind. Wenn die verlangte Tabelle nicht existiert ($mip. Table_dir/‚project_id‘_‘mip. Table‘) wird die Verarbeitung abgebrochen. 4. Es werden so viele Ergebnisdateien erzeugt, wie Variablen verarbeitet werden. 5. Der Name der Ausgabedatei ist durchgestrichen, um zu erinnern, dass er nicht gesetzt werden kann! 6. CDO-cmor soll auf Fehlbedienung reagieren, wie die Bibliotheksaufrufe. Aus Performanzgründen sollte die Verarbeitung aber abgebrochen werden, bevor die CMORBibliotheksroutinen oder andere aufwändige Operationen durchgeführt werden. 7. CDO-cmor soll die Ergebnisdaten aller an CMIP 6 teilnehmenden ESMs verarbeiten können. 8. Der Operator soll für CMIP 5 - und CMIP 6 -Formatierung benutzbar sein. 9. Die Eingabedateien müssen mit den CDIs lesbar sein (Net. CDF, GRIB, . . . ). 27. 10. 2020 10: 57 12 / 11

A. Konforme Formatierung Syntax: cdo –v -W cmor, mip. Table[, keyword=keyvalue(s), . . .

A. Konforme Formatierung Syntax: cdo –v -W cmor, mip. Table[, keyword=keyvalue(s), . . . ] ifile Options –v und –W [optional]: -W : zusätzliche Ausgabe von Meldungen mit Warnungs-Charakter -v : zusätzliche Ausgabe von Meldungen mit Informationscharakter für Fehlersuche 27. 10. 2020 10: 57 13 / 11

A. Konforme Formatierung Syntax: cdo –[m] mapping. Table cmor, mip. Table[, keyword=keyvalue(s), . .

A. Konforme Formatierung Syntax: cdo –[m] mapping. Table cmor, mip. Table[, keyword=keyvalue(s), . . . ] ifile Option mapping. Table [optional] mapping. Table ist eine formatierte Textdatei (NAMELIST Format) mit der den Projektnamen der CMIP-Variablen (out_name=) ein lokaler Name (name=) oder ein GRIB-Parameter (param/code=) in der Eingabendatei zugeordnet werden kann. Wenn mapping. Table angegeben ist, sucht CDO-cmor darin nach dem Namen der aktuellen Variablen. Wird der Name als Wert von out_name gefunden, wird die Variable mit dem zugehörigen lokalen Namen (für Net. CDF-Eingabedateien) oder GRIB-Code (bei GRIBEingabedateien) verarbeitet. Die Mapping-Tabelle kann andere Angaben enthalten, die von ‚cdo cmor, . . . ‘, anderen cdo-Operatoren oder anderer Software interpretiert werden. Die von ‚‘cdo cmor, . . . ‘ interpretierten Angaben können durch keywords in der Kommandozeile überschrieben werden. Wenn keine mapping. Table angegeben wird, bzw. die (Default-)Tabelle nicht gefunden wird, bzw. der gesuchte out_name in der mapping. Table nicht vorhanden ist, versucht ‘cdo cmor, . . . ‘ die Variable mit Hilfe der Angaben in der Kommandozeile zu formatieren. Soll es default Namen und Verzeichnis geben? -m und –M gibt es schon für die cdos!? ! 27. 10. 2020 10: 57 14 / 11

A. Konforme Formatierung: Zuordnungs(mapping)tabelle • • Format • &parameter param=123. 456 name=modnam out_name=projnam otherkey=othervalue(s)

A. Konforme Formatierung: Zuordnungs(mapping)tabelle • • Format • &parameter param=123. 456 name=modnam out_name=projnam otherkey=othervalue(s) / • die Reihenfolge der Schlüsselwörter ist beliebig • Zusätzliche Schlüsselwörter sind möglich, um die Tabelle für andere Zwecke nutzbar zu machen. • jede Zeile, die out_name=“. . . “ enthält, muss eine Angabe name=“. . . “ oder param=“. . . “ enthalten, sonst kann sie von ‘cdo cmor, . . . ‘ nicht interpretiert werden (s. o. ) Kommentare • Zeilen, die mit dem Zeichen ‘!‘ beginnen Versionierung • im Quellcode. (Bsp. : MPI-M Modelle: src/mod/<component>/util/mappings) Beispiele für Tabellen-Namen : src/mod/echam 6/util/mappings/echam 6_cmip 5_all src/mod/mpiom/util/mappings/mpiom_cmip 5_2 ddm src/mod/mpiom/util/mappings/mpiom_cmip 5_3 dmm 27. 10. 2020 10: 57 15 / 11

A. Konforme Formatierung: Zuordnungs(mapping)tabelle (contd. ) • von ’cdo cmor, . . . ‘

A. Konforme Formatierung: Zuordnungs(mapping)tabelle (contd. ) • von ’cdo cmor, . . . ‘ interpretierte Schlüsselwörter • units=„. . . “ mögliche Werte: UD-Units CV kann mit Schlüsselwort units=“. . . “ in der Kommandozeile überschrieben werden • p=“. . . “ mögliche Werte: [u(up)|d(down)|“ “]; nur die erste Stelle wird interpretiert kann mit Schlüsselwort pos=“. . . “ in der Kommandozeile überschrieben werden • cell_methods=“. . . “ mögliche Werte: [n(invariant)|c(climatological)|p(instantaneous)|m(mean)]; nur die erste Stelle wird interpretiert kann mit Schlüsselwort cm=“. . . “ in der Kommandozeile überschrieben werden • muss es eine Regel geben, wann Anführungszeichen gesetzt werden? Userfreundlich: nur nötig, wenn die Variable Leerzeichen enthält (z. B. units=m oder units=“kg m-2“ sind erlaubt). 27. 10. 2020 10: 57 16 / 11

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, vars=cs-variable. List[, keyword=keyvalue(s), . . .

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, vars=cs-variable. List[, keyword=keyvalue(s), . . . ] ifile keyword vars [optional; default=all target-variables in ifile] vars enthält eine komma-separierte Liste von CMIP-Variablennamen. Es ist möglich, eine, mehrere oder alle (Default) in der Eingabedatei enthaltenen Variablen zu verarbeiten, wobei die folgenden Restriktionen zu beachten sind: Alle in der Liste enthaltenen Variablen müssen zu derselben MIP-Tabelle gehören. Sie müssen in der Eingabedatei enthalten sein. Die Werte der folgenden Schlüsselwörter müssen für all Variablen in vars gelten. Bem. : Ein nicht zu mip. Table gehörender Variablenname würde – spätestens in einem CMOR-Bibliotheksaufruf - einen Abbruch verursachen. Wenn es gewünscht ist, dass solche Variablen einfach nur ignoriert werden, müsste vor den CMORBibliotheksaufrufen sichergestellt werden, dass die MIP-Tabellen gelesen werden, um gegebenenfalls eine Warnung auszugeben, und zur Verarbeitung der nächsten Variablen überzugehen. 27. 10. 2020 10: 57 17 / 11

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, vars=cs-variable. List[, keyword=keyvalue(s), . . .

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, vars=cs-variable. List[, keyword=keyvalue(s), . . . ] ifile keyword vars [optional; default=all target-variables in ifile] (cntd. ) Wenn vars nicht explizit besetzt wird, wird aus allen Variablen in der Eingabedatei eine Variablenliste vars erzeugt und verarbeitet. Bem. : Es könnten sich Probleme ergeben, wenn sich Variablen in der Datei befinden, die als Hilfsvariablen für andere verwendet werden (z. B. ps für cl). Um das zu vermeiden, müssen in diesem Fall alle Variablen in der Eingabedatei CMIPTargetvariablen sein. Für jede CMIP-Variable, die nicht mit dem CMIP-Variablennamen in der Eingabedatei abgelegt ist, muss ein Eintrag in der mapping. Table (s. o. ) vorhanden sein, der die Zuordnung von CMIP-Variablennamen und lokalen Variablennamen bzw. GRIBParametern enthält. 27. 10. 2020 10: 57 18 / 11

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, pos=[u| |d][, keyword=keyvalue(s), . . .

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, pos=[u| |d][, keyword=keyvalue(s), . . . ] ifile keyword pos [optional; default=blank => keine Übergabe an Cmor-Aufrufe] Die CMOR 2 -Bibliothek prüft, ob the Flussrichtung angegeben ist, falls verlangt (praktisch alle Flüsse). Die Angabe ist eigentlich redundant, da vom standard_name die Richtung positiver Flüsse abgeleitet werden kann. Wenn nicht die vorgegebene Richtung angegeben wird, d. h. wenn das Vorzeichen der bereitgestellten Variablen nicht mit dem standard_name übereinstimmt, ändert CMOR 2 das Vorzeichen. Wenn die Angabe nicht verlangt wird, darf sie nicht gegeben werden. Wenn das Schlüsselwort in der Kommandozeile angegeben ist, müssen alle Variablen, die in einem Durchgang verarbeitet werden sollen, dieselbe Flussrichtung haben. Der Wert überschreibt, wie alle anderen Angaben in der Kommandozeile auch, die Angaben in einer Mapping-Tabelle. Ein ccp-flag _CDO_CMOR_EXPERT_MODE ist in einer lokalen Version von Cmor 2 eingeführt, das die CMOR-Library den Check überspringen lässt. Damit können in einem Durchgang Variablen mit verschiedenen Flussrichtungen verarbeitet werden, vorausgesetzt, die Angabe pos=“. . . “ ist jeweils vorhanden. 27. 10. 2020 10: 57 19 / 11

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, units=‘udunit’[, keyword=keyvalue(s), . . . ]

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, units=‘udunit’[, keyword=keyvalue(s), . . . ] ifile keyword units [optional; kein Default]: Soll die unveränderte Standard-CMOR-Bibliothek benutzt werden, muss eine Units. Angabe vorhanden sein. Gegebenenfalls werden die Werte der Variablen so modifiziert, dass sie die richtigen Einheiten haben (udunit-Bibliothek). Wird units=“. . . “ in der Kommandozeile angegeben, müssen alle in dem Aufruf zu verarbeitenden Variablen dieselben Units haben. Fehlt die Angabe von units, müssen die Units für alle Variablen in der Mapping-Tabelle eingetragen sein. Ein ccp-flag _CDO_CMOR_EXPERT_MODE könnte eingeführt werden, das die CMORLibrary die Prüfung der Units überspringen lässt, entsprechend der Deaktivierung des ‚positive‘-Checks. 27. 10. 2020 10: 57 20 / 11

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, oflag=output. Mode[, keyword=keyvalue(s), . . .

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, oflag=output. Mode[, keyword=keyvalue(s), . . . ] ifile keyword oflag [optional; default=r(eplace)] Die Werte ‚replace‘ oder ‚append‘ sind möglich. Nur das erste Zeichen wird ausgewertet. Wenn oflag nicht besetzt ist, wird eine neue Datei angelegt, in die Zeitebenen von ifile geschrieben werden (Default=replace). Der CDO-cmor-Operator muss wg. der operationellen Kettenverarbeitung auch die append-Funktion der CMOR 2 Bibliothek ermöglichen. Bei oflag=‘a(ppend)‘ werden die Daten in ifile an eine vorher erzeugte Datei angehängt. Dabei wird das letzte Datum im vorherigen Chunk aus dem ersten Zeitwert im aktuellen Chunk und der Frequenz hergeleitet. Die Namen von Dateien, die sich zum Fortschreiben eigenen, können sich nur in dem ersten Datum des am Ende des Dateinamens anzugebenen Zeit-Bereichs unterscheiden. 27. 10. 2020 10: 57 21 / 11

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, oflag=output. Mode[, keyword=keyvalue(s), . . .

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, oflag=output. Mode[, keyword=keyvalue(s), . . . ] ifile keyword oflag [optional; default=r(eplace)] (cntd. ) Der Dateiname – bis auf dieses Datum (s. DRS)– wird im CMOR-Programm konstruiert. 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 keine geeignete ls –lrt: Datei gefunden wird, bricht die Verarbeitung ab. tas_MPI-ESM-P_historical_r 1 i 1 p 1_190501 -190912. nc tas_MPI-ESM-P_historical_r 1 i 1 p 1_191001 -191912. nc tas_MPI-ESM-P_historical_r 1 i 1 p 1_192001 -192912. nc 27. 10. 2020 10: 57 22 / 11

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, vcomm=“. . . ”[, keyword=keyvalue(s), .

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, vcomm=“. . . ”[, keyword=keyvalue(s), . . . ] ifile keyword [optional; default=leerer String] Variablenbezogener Kommentar; Länge bis ? ? ? CHARACTER 27. 10. 2020 10: 57 23 / 11

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, cm=cell. Method 4 Time[, keyword=keyvalue(s), .

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, cm=cell. Method 4 Time[, keyword=keyvalue(s), . . . ] ifile keyword [optional; default=m(ean)] cell_methods der Zeitachse (time: cell_methods) mögliche Werte: [none|point|mean|clim]; nur das erste Zeichen wird ausgewertet • point: instantane Werte; die Zeitpunkte werden vom Projekt-Standard vorgegeben • mean/clim/…: Ränder Zeitintervalle werden vom Projektstandard vorgegeben; die Zeitpunkte müssen in der Mitte liegen. • 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. • • Bem. : die Ränder können, (und sollen) in ‘cdo cmor, …‘ berechnet werden; in der morlib werden nur einige Checks durchgeführt (Überlappungg, streng monoton, . . . ) 27. 10. 2020 10: 57 24 / 11

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, szc=axis. Value[, keyword=keyvalue(s), . . .

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, szc=axis. Value[, keyword=keyvalue(s), . . . ] ifile keyword [optional; kein Default] CMOR-Dimension-Name und Wert einer vertikalen skalaren Achse (scalar zcoordinate). Die Einheit muss die des Defaultwerts sein. Beispiel: height 2 m_1. 5. Dieses Schlüsselwort muss immer besetzt sein, wenn die Variable für einen anderen als den default-Wert repräsentativ ist. Andere Optionen: • MIP Tabelle anpassen: Lösung für lokales Arbeiten; bei Aufbereitung für das ESGF sollte die MIP-Tabelle vorher aktualisiert werden. Dabei würden lokale Modifikationen verloren gehen. • Zuordnungs/Mapping-Tabelle: ? ? ? möglich • ifile: Abfragen auf Deklaration wie vom Standard vorgesehen (lev=1? ? ? ) Woher weiß man dann, ob es sich um height 2 m oder height 10 m handelt? 27. 10. 2020 10: 57 25 / 11

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, ginfo=grid. File [, keyword=keyvalue(s), . .

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, ginfo=grid. File [, keyword=keyvalue(s), . . . ] ifile keyword [optional, default=? ? ? ] Name einer Net. CDF-Datei mit Angaben zum Modellgitter; sowohl der Basisname, als auch ein Verzeichnisname können auch in einer Konfigurationsdatei angegeben werden. Wenn kein absoluter Pfad angegeben ist, wird gegebenenfalls der Pfad aus einer Konfigurationsdatei (s. u. ) vorangestellt. Diese Datei wird nur benötigt, wenn nicht alle erforderlichen Gitterangaben in ifile stehen. Die Angaben in grid. File überschreiben die in ifile. 27. 10. 2020 10: 57 26 / 11

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, info=cs-file. List[, keyword=keyvalue(s), . . .

A. Konforme Formatierung Syntax: cdo cmor, mip. Table, info=cs-file. List[, keyword=keyvalue(s), . . . ] ifile keyword [optional; default=. cdocmorinfo] Komma-separierte Liste mit beliebig vielen Dateinamen, in denen die von CMOR benötigten Angaben abgelegt sind. Die Anzahl der Dateien ist beliebig. Die meisten Schlüsselwörter entsprechen Net. CDF-Attributen des CMIP-Standard-Metadaten. Modells (zum ESM, Institut und Experiment, etc. ). Ihre Werte müssen in den meisten Fällen einem CV entnommen werden. Andere Beispiele sind Pfad oder Dateiname von zusätzlichen Dateien (MIP-Tabellen, Mapping-Tabellen, Gitterdatei). • Format: Schlüsselwort=Wert • 27. 10. 2020 10: 57 Default-Verzeichnis: i. $HOME nur wenn info=. cdocmorinfo (default) ii. . / nur wenn info=. cdocmorinfo (default) (ii geht vor) 27 / 11

A. Konforme Formatierung Übergang *. f 90 *. c : • • • Wrapper

A. Konforme Formatierung Übergang *. f 90 *. c : • • • Wrapper (Cdo), Info(Metadaten)Dateien, compile Skript, und *. f 90 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/cmor 2 -lib MIP- und Variablen-Zuordnungstabellen in http: //svn-mad. dkrz. de/svn/mad/Model/cmor-support/trunk/cmorprojs/<project>/tables Grundsätzlich ist das Ziel, das f 90 -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 f 90 -Programm bis zur endgültigen Fertigstellung weiterentwickelt. Der Übergang zum c-Programm kann in der Geschwindigkeit des Bearbeiters erfolgen. 27. 10. 2020 10: 57 28 / 11

A. Konforme Formatierung: Gitter CMOR bekannte Gitter ( = CF-Standard grid_mapping list): 1. albers_conical_equal_area

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 27. 10. 2020 10: 57 CDIs grid. Types • 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 29 / 11

A. Konforme Formatierung: Gitter CF: grid_mapping_name = latitude_longitude; • no parameter • coordinates float

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" ; 27. 10. 2020 10: 57 CDIs grid. Types • 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 30 / 11

A. Konforme Formatierung: Gitter CMOR bekannte Gitter ( = CF-Standard grid_mapping list): . .

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”; 27. 10. 2020 10: 57 CF + CMIP 5 convention 31 / 11

A. Konforme Formatierung: Gitter CMOR bekannte Gitter ( = CF-Standard grid_mapping list): • albers_conical_equal_area

A. Konforme Formatierung: Gitter 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 27. 10. 2020 10: 57 32 / 11

A. Konforme Formatierung: Performanz • • MPI-ESM-LR (T 63, L 47) • 1 Variable,

A. Konforme Formatierung: Performanz • • MPI-ESM-LR (T 63, L 47) • 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 (Net. CDF) • 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 27. 10. 2020 10: 57 33 / 11

B. Konforme CDOs B. die cdos sollen so weit wie möglich CMIP konforme Dateien

B. Konforme CDOs B. die cdos sollen so weit wie möglich CMIP konforme Dateien liefern Vergleiche header von allen CMIP 5 Dateien in /work/ik 0555/. . . /esmrcp 85/ mit den headern derselben Datei, wenn sie von einem CDO-Operator verarbeitet wurden: experiment_id=‚esmrcp 85‘ 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. 27. 10. 2020 10: 57 34 / 11

B. header–Vergleich nach cdo copy All realms / grids: 1. bnds => nb 2

B. header–Vergleich nach cdo copy All realms / grids: 1. bnds => nb 2 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" statt time: units = "days since’ ‘ 850 -1 -1 00: 00" ok! (ev. KT, CD fragen) 27. 10. 2020 10: 57 35 / 11

B. header–Vergleich nach cdo copy Realm / grid atmos: 1. var: cell_measures = “area:

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

 • CDO-operator (wird gegenwärtig realisiert; ist aber nur für konforme CDOs sinnvoll; ansonsten

• CDO-operator (wird gegenwärtig realisiert; ist aber nur für konforme CDOs sinnvoll; ansonsten Pbl (s. o. )) Eigener Operator oder ‚cdo setparm‘ für die erstmalige Angabe einer szc? Soll die erstmalige d. h. Default-Version einer ‘scalar z-coordinate‘, die CMIPStandard-Variante sein? Beide Varianten sind Net. CDF/CF konform. 27. 10. 2020 10: 57 37 / 11

B. header–Vergleich nach cdo copy Realm / grid atmos: 1. Vertical coordinate ok! (d.

B. header–Vergleich nach cdo copy Realm / grid atmos: 1. Vertical coordinate ok! (d. h. die formulas und a. lev: standard_name verloren ihre koeff. bleiben erhalten; b. lev: formula = "p = ap + b*ps" ; sie werden erzeugt c. lev: formula_terms = "ap: ap b: b ps: ps" ; mit ‚cdo cmor. . . ‘); 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) 27. 10. 2020 10: 57 38 / 11

B. header–Vergleich nach cdo copy Realm / grid atmos: 1. Vertical coordinate Lösung: Die

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 CMIP 5 -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 Net. CDF-Standard verwendeten Annahme eine eigene Form für ‚formula-terms‘ haben; 27. 10. 2020 10: 57 39 / 11

B. header–Vergleich nach cdo copy Realm / grid land: 1. Surface type coordinates/single value

B. header–Vergleich nach cdo copy Realm / grid land: 1. Surface type coordinates/single value dimension float baresoil. Frac, c 3 ft. Frac, c 4 ft. Frac(time, lat, lon) ; c 3 Pft. Frac: coordinates = „type“ ; c 4 Pft. Frac: coordinates = „type“ ; geht verloren (s. o. ) Action! char type(strlen) ; type: long_name = "surface type" type: standard_name = "area_type" ; data: type = "bare_ground" ; data: type = "" ; 27. 10. 2020 10: 57 40 / 11

B. header–Vergleich nach cdo copy Realm / grid land: 1. Coordinates besides x, y,

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

B. header–Vergleich nach cdo copy Realm / grid sea. Ice : 1. var: cell_measures

B. header–Vergleich nach cdo copy Realm / grid sea. Ice : 1. var: cell_measures = “area: areacello“ geht verloren Action ! var: associated_files = "base. URL: http: //. . . “(s. o. ) (location von areacello ) ok ! 2. nv 4 = 4 ; statt vertices = 4 ; Action ! 3. x = 256 statt i = 256 ; Action ! 4. y = 220 statt j = 220 ; Action ! 5. int i(i) fehlt Action ! i: units = "1" ; i: long_name = "cell index along first dimension" ; 6. int j(j) fehlt Action ! j: units = "1" ; j: long_name = "cell index along second dimension" ; 7. [lat|lon]_bnds statt [lat|lon]_vertices angefragt! (keine Antwort) Warum ‚angefragt‘? 8. coordinates = „lon lat“ statt „lat lon“ ok! 27. 10. 2020 10: 57 42 / 11

B. header–Vergleich nach cdo copy Realm / grid ocean : 1. Coordinates besides x,

B. header–Vergleich nach cdo copy Realm / grid ocean : 1. Coordinates besides x, y, z, t float mfo(time, x) ; statt float mfo(time, line) ; mfo: coordinates = "passage" ; char passage(line, strlen) ; passage: long_name = "ocean passage" ; passage: standard_name = "region" ; geht verloren (s. o. ) Action ! 2. Coordinates besides x, y, z, t float msftmyz(time, x, lev, lat) ; statt float msftmyz(time, basin, lev, lat); msftmyz: coordinates = "region" ; char region(basin, strlen) ; geht verloren (s. o. ) Action ! region: long_name = "ocean basin" ; region: standard_name = "region" ; 27. 10. 2020 10: 57 43 / 11

B. header–Vergleich nach cdo copy Realm / grid ocean : 1. Coordinates besides x,

B. header–Vergleich nach cdo copy Realm / grid ocean : 1. Coordinates besides x, y, z, t float msftmyz(time, basin, lev, lat) ; geht verloren (s. o. ) Action ! lat: bounds = "lat_bnds" ; lat: standard_name = "latitude" ; 2. Bem. ‚nbds = 2‘ steht überflüssigerweise in areacello ; gemeldet! CD&KT 27. 10. 2020 10: 57 44 / 11

B. header–Vergleich nach cdo copy Realm / grid ocn. Bgchem: 1. single value dimension

B. header–Vergleich nach cdo copy Realm / grid ocn. Bgchem: 1. single value dimension : bfe: coordinates = "lat lon" ; statt bfe: coordinates = "depth lat lon" ; double depth ; depth: axis = "Z" ; depth: long_name = "depth" ; geht verloren (s. o. ) ok! 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) ; geht verloren (s. o. ) Action ! 27. 10. 2020 10: 57 45 / 11

A. single-value dimension cdo operator Es gibt eine CMOR variable/ccoordinate „height 2 m“ mit

A. single-value dimension cdo operator Es gibt eine CMOR variable/ccoordinate „height 2 m“ mit • valid_min=1. 0 • valid_max=10. 0 • default=2. 0 CMOR 3 -Doku: • „. . . overwrite the MIP table specification. . . “ • „. . . there normally is no nedd to call cmor_axis in the case of a singleton dimension unless the MIP recommended coordinate value is inconsistent with what the user can supply. . . “ Vorschlag: wenn der default Wert nicht zutrifft, kann ein Schlüsselparameter height 2 m=1. 5 übergeben werden; Jörg‘s Programm ruft in diesem Fall „cmor_axis“ mit „height 2 m“ & „ 1. 5“; entsprechend height 10 m=9. 0; oder: svd=height 2 m_1. 5, svd=height 10 m_9. 0, etc. 27. 10. 2020 10: 57 46 / 11

B. single-value dimension cdo operator i. Es werden all Dimensionen mitgenommen: Beispiel: tas: coordinates=„height“

B. single-value dimension cdo operator i. Es werden all Dimensionen mitgenommen: Beispiel: tas: coordinates=„height“ => double height; . . . data: height = 2. 0 ; ii. cdo setpar, name=tas, svd=height_2 m ifile ofile setzt die Angaben wie unter i) iii. grib? 27. 10. 2020 10: 57 47 / 11

B. Konforme CDOs Gitter (ncdump –h) vor (<) und nach (>) cdo copy <

B. Konforme CDOs Gitter (ncdump –h) vor (<) und nach (>) cdo copy < time: units = "days since 1949 -12 -01 T 00: 00 Z" ; > < < < > > > time: units = "days since 1949 -12 -1 00: 00" ; nv 4 = 4 ; x = 194 ; y = 201 ; > > > > float lat(y, x) ; float lat_bnds(y, x, nv 4) ; float lon(y, x) ; float lon_bnds(y, x, nv 4) ; float tas(time, y, x) ; lat: bounds = "lat_bnds" ; lon: bounds = "lon_bnds" ; vertices = 4 ; rlon = 194 ; rlat = 201 ; double rlat(rlat) ; double rlon(rlon) ; float lat(rlat, rlon) ; float lat_vertices(rlat, rlon, vertices) ; float lon(rlat, rlon) ; float lon_vertices(rlat, rlon, vertices) ; float tas(time, rlat, rlon) ; lat: bounds = "lat_vertices" ; lon: bounds = "lon_vertices" ; 27. 10. 2020 10: 57 48 / 11

B. Konforme CDOs Gitter (ncdump –h) vor (<) und nach (>) cdo copy <

B. Konforme CDOs Gitter (ncdump –h) vor (<) und nach (>) cdo copy < < < < > > lat: _Coordinate. Axis. Type = "Lat" ; lon: _Coordinate. Axis. Type = "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" ; 27. 10. 2020 10: 57 49 / 11

B. header–Vergleich nach cdo selname Realm / grid atmos: 1. float ps(time, lat, lon)

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

B. header–Vergleich nach cdo Operationen Alle: 1. frequeny : a) frequeny = „freq“ aus

B. header–Vergleich nach cdo Operationen Alle: 1. frequeny : a) frequeny = „freq“ aus CMIP 5 CV (fx, yr, mon, day, 6 hr, 3 hr, subhr) setzen ok! b) frequency updaten (z. B. bei monmean) Action! Fabian! c) Frequenz als Operator oder im Datenmodell? 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. ESMVal. Tool 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) 27. 10. 2020 10: 57 51 / 11

A. und B. Kommunikation und Software-Austausch Speicherung und Kommunikation: Redmine (Wiki, Repository über links,

A. und B. Kommunikation und Software-Austausch Speicherung und Kommunikation: Redmine (Wiki, Repository über links, nur Lesen) Git. Hub: externe Speicherung, frei; d. h. die ganze Welt kann darauf zugreifen, Wiki, Repository Git. Lab: im eigenen Netz: https: //gitlab. dkrz. de Jeder Nutzer muss aktiviert werden, sonst wie Git. Hub Noch keine Entscheidung! 1. Wie soll der Datenaustausch (Programme etc. ) stattfinden ? 1. versioniert 2. Lösung für de. CMIP 6 -Partner (AWI, DLR, FUB, …, MPI-M, …) 1. SVN? 2. Redmine? 3. Git. Hub? 4. Git. Lab? 27. 10. 2020 10: 57 52 / 11

A. und B. : Installation und Distributionen . . . • statische/dynamische Anbindung an

A. und B. : Installation und Distributionen . . . • statische/dynamische Anbindung an CMOR • Verteilung mit conda? 27. 10. 2020 10: 58 53 / 11

Zu diskutieren: I. Inwieweit ist es sinnvoll, die Modelle diese Dateien erzeugen zu lassen?

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. 10. 2020 10: 58 54 / 11