Organisatorisches Die Dokumente CDO-CMOR_Konforme-Formatierung.ppt und Konforme_CDOs.pptx sind wieder zu einem Dokument zusammengefasst (Name: CDO-CMOR.pptx).

Organisatorisches Die Dokumente CDO-CMOR_Konforme-Formatierung.ppt und Konforme_CDOs.pptx sind wieder zu einem Dokument zusammengefasst (Name: CDO-CMOR.pptx). Zunächst weiterhin hochgeladen auf : Zusätzlich in Eingabedateien zum Testen in: mistral:/work/ik0555/cmip5/archive/CMIP5/output/MPI-M. Eine Testversion der CDOs gibt es unter: mistral:/home/zmaw/m214003/local/bin/cdo Den Quellcode gibt demnächst unter: *Jeder will Großes erreichen, ohne sich darüber im Klaren zu sein, dass das Leben aus kleines Sachen besteht.

BMBF-Projekt ‚CMIP6-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 CMIP6-Datenarchivs und einer Infrastruktur zur Datenqualitätssicherung“ 4 Stellen bewilligt, 1 davon für CDO-Entwicklung (4 Jahre), deren Aufgaben: CDO-Operator für konforme Formatierung Konforme CDOs Metadatenmodell Datenmodell Klimaindizes

CMIP[5,6,...] und CDOs: Ziele Konforme Formatierung
es gibt einen cdo operator der CMIP-konforme Ausgabedateien erzeugt, falls: die Eingabedatei CMIP Variablen mit korrekter Aggregation enthält; alle von CMOR benötigten Hilfs-Variablen zugänglich (z.B. scalar-z-coordinate ‘keyword=szc‘) sind ; 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 CMIP-konform (cdo <operator> 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 in standard_output.xls für CMIP5 festgelegt; für CMIP6 steht die Liste noch nicht fest;

CMIP[5,6,...] und CDOs: Zeitplan
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 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 CMIP5/6: Jörg‘s FORTRAN-Programm mit DKRZ-Wrapper. 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 ...

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 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 CMIP6-Experimente möglichst alle CMIP-Variablen direkt aus den Modellen mit den CMIP-Namen ausgegeben werden könnten. Aber das ist unrealistisch. ²DECK, CMIP6, und endorsedMIPs

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 CMOR2/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. die Regeln für die Verzeichnisstruktur (oder für die Dateinamen ?) kann für CMOR3 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 nicht erzeugen (können?) Action: Jörg

Dateiname wird für verlangte CMIP-Variablen von CMOR2/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 CMIP-Archiv 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).

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 den Namen nicht kennen, gegebenenfalls muss ‘cdo cat ....‘ benutzt werden

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,…‘ 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 von der Grenzfläche Atmosphäre/Ozean wegzeigend Atmosphäre: nach oben Land, Ozean : nach unten 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 P0( Pa) ????? Action: Jörg Action: Jörg

Zeit-Achse s. keyword ‘cm‘ (cell_method ) Metadaten zu vielen NetCDF-Attributen gibt es DRS-Elemente aus denen Dateinamen und Verzeichnisse aufgebaut werden cmor2/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 (CMIP5) dving_model_id, driving_experiment_name ,cordex_domain (CORDEX ) andere, schon vorhandene NetCDF-Attribute gehen beim Passieren von cmor2/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>???‘

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 3rd dimension How to get char. value vectors (e.g. basins, oline) into cdo cmor? Options: ifile, gfile, mapping table, keyword ???

Syntax: cdo cmor,mipTable[,keyword=keyvalue(s), ...] ifile ofile-c Bemerkungen: Der Operator heißt ‚cmor‘. Der Operator ruft die Cmor-Bibliothek. mipTable 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 ($mipTable_dir/‚project_id‘_‘mipTable‘) wird die Verarbeitung abgebrochen. Es werden so viele Ergebnisdateien erzeugt, wie Variablen verarbeitet werden. Der Name der Ausgabedatei ist durchgestrichen, um zu erinnern, dass er nicht gesetzt werden kann! CDO-cmor soll auf Fehlbedienung reagieren, wie die Bibliotheksaufrufe. Aus Performanzgründen sollte die Verarbeitung aber abgebrochen werden, bevor die CMOR-Bibliotheksroutinen oder andere aufwändige Operationen durchgeführt werden. CDO-cmor soll die Ergebnisdaten aller an CMIP6 teilnehmenden ESMs verarbeiten können. Der Operator soll für CMIP5- und CMIP6-Formatierung benutzbar sein. Die Eingabedateien müssen mit den CDIs lesbar sein (NetCDF, GRIB, ...).

Syntax: cdo –v -W cmor,mipTable[,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

Syntax: cdo –[m] mappingTable cmor,mipTable[,keyword=keyvalue(s), ...] ifile Option mappingTable [optional] mappingTable 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 mappingTable 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 NetCDF-Eingabedateien) oder GRIB-Code (bei GRIB-Eingabedateien) 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 mappingTable angegeben wird, bzw. die (Default-)Tabelle nicht gefunden wird, bzw. der gesuchte out_name in der mappingTable 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!?!

Konforme Formatierung:
Zuordnungs(mapping)tabelle Format &parameter param= 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/echam6/util/mappings/echam6_cmip5_all src/mod/mpiom/util/mappings/mpiom_cmip5_2ddm src/mod/mpiom/util/mappings/mpiom_cmip5_3dmm

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).

Syntax: cdo cmor,mipTable,vars=cs-variableList[,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 mipTable 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 CMOR-Bibliotheksaufrufen sichergestellt werden, dass die MIP-Tabellen gelesen werden, um gegebenenfalls eine Warnung auszugeben, und zur Verarbeitung der nächsten Variablen überzugehen.

Syntax: cdo cmor,mipTable,vars=cs-variableList[,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 CMIP-Targetvariablen sein. Für jede CMIP-Variable, die nicht mit dem CMIP-Variablennamen in der Eingabedatei abgelegt ist, muss ein Eintrag in der mappingTable (s.o.) vorhanden sein, der die Zuordnung von CMIP-Variablennamen und lokalen Variablennamen bzw. GRIB-Parametern enthält.

Syntax: cdo cmor,mipTable,pos=[u| |d][,keyword=keyvalue(s), ...] ifile keyword pos [optional; default=blank => keine Übergabe an Cmor-Aufrufe] Die CMOR2-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 CMOR2 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 Cmor2 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.

Syntax: cdo cmor,mipTable, 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 CMOR-Library die Prüfung der Units überspringen lässt, entsprechend der Deaktivierung des ‚positive‘-Checks.

Syntax: cdo cmor,mipTable, oflag=outputMode[,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 die Zeitebenen von ifile geschrieben werden (Default=replace). Der CDO-cmor-Operator muss wg. der operationellen Kettenverarbeitung auch die append-Funktion der CMOR2 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.

Syntax: cdo cmor,mipTable, oflag=outputMode[,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 Datei gefunden wird, bricht die Verarbeitung ab. ls –lrt: tas_MPI-ESM-P_historical_r1i1p1_ nc tas_MPI-ESM-P_historical_r1i1p1_ nc tas_MPI-ESM-P_historical_r1i1p1_ nc

Syntax: cdo cmor,mipTable,vcomm=“...”[,keyword=keyvalue(s), ...] ifile keyword [optional; default=leerer String] Variablenbezogener Kommentar; Länge bis ??? CHARACTER

Syntax: cdo cmor,mipTable,cm=cellMethod4Time[,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 der 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 mor-lib werden nur einige Checks durchgeführt (Überlappungg, streng monoton, ...)

Syntax: cdo cmor,mipTable,szc=axisValue[,keyword=keyvalue(s), ...] ifile keyword [optional; kein Default] CMOR-Dimension-Name und Wert einer vertikalen skalaren Achse (scalar z-coordinate). Die Einheit muss die des Defaultwerts sein. Beispiel: height2m_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 height2m oder height10m handelt?

Syntax: cdo cmor,mipTable,ginfo=gridFile [,keyword=keyvalue(s), ...] ifile keyword [optional, default=???] Name einer NetCDF-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 gridFile überschreiben die in ifile.

Syntax: cdo cmor,mipTable,info=cs-fileList[,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 NetCDF-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 Default-Verzeichnis: $HOME nur wenn info=.cdocmorinfo (default) ./ nur wenn info=.cdocmorinfo (default) (ii geht vor)

Konforme Formatierung
Übergang *.f90  *.c : Wrapper (Cdo), Info(Metadaten)Dateien, compile Skript, und *.f90 in SVN-trunk Libraries in MIP- und Variablen-Zuordnungstabellen in 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 in der Geschwindigkeit des Bearbeiters erfolgen.

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

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 CF: grid_mapping_name = latitude_longitude; no parameter coordinates float lat(lat) ; lat:long_name = "latitude" ; lat:units = "degrees_north" ; lat:standard_name = "latitude" ;

CMOR bekannte Gitter ( = CF-Standard grid_mapping list): ... 10. rotated_latitude_longitude .... CF + CMIP5 convention 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”;

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

Konforme Formatierung: Performanz
MPI-ESM-LR (T63,L47) 1 Variable, 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

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.

B. header–Vergleich nach cdo copy
All realms / grids: bnds => nb2 ok! time:axis = "T„ geht verloren ok! 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 “ tracking_id muss er-/gesetzt werden ok! (wird neu gesetzt) Nee! creation_date muss er-/gesetzt werden ok! (wird übernommen) time:units = "days since’ ‘ :00:00" statt time:units = "days since’ ‘ :00:00" ok! (ev. KT, CD fragen)

Realm / grid atmos: var:cell_measures = “area: areacella“ geht verloren; action! Location von areacella in var: associated_files = "baseURL: geht verloren; ok! var:grid_type = “gaussian“ ; kein Problem! 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 ; geht nicht mehr verloren; aber wird nicht erzeugt ok! Bjorn hat ‚zugesagt‘ dass das Problem am MPI-M registriert wurde.

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 CMIP-Standard-Variante sein? Beide Varianten sind NetCDF/CF konform.

Realm / grid atmos: Vertical coordinate lev:standard_name verloren lev:formula = "p = ap + b*ps" ; lev:formula_terms = "ap: ap b: b ps: ps" ; lev_bnds:formula lev_bnds:formula_terms="ap: ap_bnds b: b_bnds ps: ps" lev_bnds:standard_name verloren lev_bnds:units double [ap|b](lev) verloren [ap|b]_bnds(lev, x); dimension x statt bnds float ps(time, lat, lon) verloren 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) ok! (d.h. die formulas und ihre koeff. bleiben erhalten; sie werden erzeugt mit ‚cdo cmor ...‘);

Realm / grid atmos: 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;

Realm / grid land: 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 = "" ; geht verloren (s.o.) Action!

Realm / grid land: 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; verloren double lev(lev) lev:axis = „Z“; lev: long_name = „generic“; lev:units = „level“; eingefügt Action!

Realm / grid seaIce : var:cell_measures = “area: areacello“ geht verloren var:associated_files = "baseURL: (location von areacello ) ok ! nv4 = 4 ; statt vertices = 4 ; x = 256 statt i = 256 ; y = 220 statt j = 220 ; Action ! int i(i) fehlt Action ! i:units = "1" ; i:long_name = "cell index along first dimension" ; int j(j) fehlt Action ! j:units = "1" ; j:long_name = "cell index along second dimension" ; [lat|lon]_bnds statt [lat|lon]_vertices angefragt! (keine Antwort) Warum ‚angefragt‘? coordinates = „lon lat“ statt „lat lon“ ok! Action ! Action ! Action !

Realm / grid ocean : 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" ; 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) ; region:long_name = "ocean basin" ; region:standard_name = "region" ; geht verloren (s.o.) Action ! geht verloren (s.o.) Action !

Realm / grid ocean : Coordinates besides x,y,z,t float msftmyz(time, basin, lev, lat) ; lat:bounds = "lat_bnds" ; lat:standard_name = "latitude" ; Bem. ‚nbds = 2‘ steht überflüssigerweise in areacello ; gemeldet! CD&KT geht verloren (s.o.) Action !

Realm / grid ocnBgchem: 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 ; fddtalk, fddtdic, fddtdife, fddtdin, fddtdip, fddtdisi: depth:bnds = „depth_bnds“ ; double depth_bnds(bnds) ; geht verloren (s.o.) ok! geht verloren (s.o.) Action !

A. single-value dimension cdo operator
Es gibt eine CMOR variable/ccoordinate „height2m“ mit valid_min=1.0 valid_max=10.0 default=2.0 CMOR3-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 height2m=1.5 übergeben werden; Jörg‘s Programm ruft in diesem Fall „cmor_axis“ mit „height2m“ & „1.5“; entsprechend height10m=9.0; oder: svd=height2m_1.5, svd=height10m_9.0, etc.

B. single-value dimension cdo operator
Es werden all Dimensionen mitgenommen: Beispiel: tas:coordinates=„height“ => double height; height; ... . data: height = 2.0 ; cdo setpar,name=tas,svd=height_2m ifile ofile setzt die Angaben wie unter i) grib?

Gitter (ncdump –h) vor (<) und nach (>) cdo copy
B. Konforme CDOs Gitter (ncdump –h) vor (<) und nach (>) cdo copy < time:units = "days since T00:00:00Z" ; > time:units = "days since :00:00" ; < vertices = 4 ; > nv4 = 4 ; < rlon = 194 ; > x = 194 ; < rlat = 201 ; > y = 201 ; < double rlat(rlat) ; < double rlon(rlon) ; < float lat(rlat, rlon) ; > float lat(y, x) ; < float lat_vertices(rlat, rlon, vertices) ; > float lat_bnds(y, x, nv4) ; < float lon(rlat, rlon) ; > float lon(y, x) ; < float lon_vertices(rlat, rlon, vertices) ; > float lon_bnds(y, x, nv4) ; < float tas(time, rlat, rlon) ; > float tas(time, y, x) ; < lat:bounds = "lat_vertices" ; > lat:bounds = "lat_bnds" ; < lon:bounds = "lon_vertices" ; > lon:bounds = "lon_bnds" ;

Gitter (ncdump –h) vor (<) und nach (>) cdo copy
B. Konforme CDOs Gitter (ncdump –h) vor (<) und nach (>) 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" ;

B. header–Vergleich nach cdo selname
Realm / grid atmos: 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 Operationen
Alle: frequeny : frequeny = „freq“ aus CMIP5 CV (fx,yr,mon,day,6hr,3hr,subhr) setzen ok! frequency updaten (z. B. bei monmean) Action! Fabian! Frequenz als Operator oder im Datenmodell? Was passiert mit verschiedenen Attributwerten bei Modellensembles? model_id = ““ model_id = „differing values in input files“ model_id = „MPI-ESM-*“ bei MPI-ESM-LR und MPI-ESM-P model_id = „MPI-ESM-LR MPI-ESM-P“ Was passiert mit verschiedenen Attributwerten bei Simulationenensembles? realization = * realization = „1,2,11,13“ Use Cases: ESMValTool Ensemble-Modell-Daten im ESGF Ensemble-Modell-Daten aus dem ESGF (processing auf dem Datenserver) Normaler Datennutzer (z.B. am MPI-M)

und B. Kommunikation und Software-Austausch
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: Jeder Nutzer muss aktiviert werden, sonst wie GitHub Noch keine Entscheidung! Wie soll der Datenaustausch (Programme etc.) stattfinden ? versioniert Lösung für de.CMIP6-Partner (AWI, DLR, FUB,…, MPI-M,…) SVN? Redmine? GitHub? GitLab?

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

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

Organisatorisches Die Dokumente CDO-CMOR_Konforme-Formatierung.ppt und Konforme_CDOs.pptx sind wieder zu einem Dokument zusammengefasst (Name: CDO-CMOR.pptx).

Ähnliche Präsentationen

Präsentation zum Thema: "Organisatorisches Die Dokumente CDO-CMOR_Konforme-Formatierung.ppt und Konforme_CDOs.pptx sind wieder zu einem Dokument zusammengefasst (Name: CDO-CMOR.pptx)."— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Organisatorisches Die Dokumente CDO-CMOR_Konforme-Formatierung.ppt und Konforme_CDOs.pptx sind wieder zu einem Dokument zusammengefasst (Name: CDO-CMOR.pptx).

Ähnliche Präsentationen

Präsentation zum Thema: "Organisatorisches Die Dokumente CDO-CMOR_Konforme-Formatierung.ppt und Konforme_CDOs.pptx sind wieder zu einem Dokument zusammengefasst (Name: CDO-CMOR.pptx)."— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback