1 / 11 Organisatorisches 1.Versionsarchiv für Dokumente: https://code.zmaw.de/projects/cdo/wiki/CMOR https://code.zmaw.de/projects/cdo/wiki/CMOR i.CMIP-CDOs.ppt.

Slides:



Advertisements
Ähnliche Präsentationen
Integrations- und Funktionstests im Rahmen des V-Modelles
Advertisements

PC-Senioren Ludwigsburg
Online-Dissertationen
WR + WS ZEIGEN Neues aus der Mathematik.
„Ansicht Arbeitsbereich“ ist die nutzerspezifische Ansicht, in der alle Dokumente aufgelistet sind, die dem angemeldeten Benutzer zugeordnet sind. D.h.
Dynamische Seiten mit Dreamweaver Zugriff auf (mysql) Datenbank mit PHP.
der Universität Oldenburg
C.M. Presents D.A.R. und Ein Bisschen dies und das!
Lizenz Modelle GNU GPL BSD Shareware.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Was ist Refactoring? Bevor man die Integration angeht, mag es angebracht sein, den.
es gibt (fast) nichts, was nicht anders gemacht werden könnte
FH-Hof Extensible Markup Language Richard Göbel. FH-Hof Extensible Markup Language XML XML ist universeller Ansatz für die Strukturierung von Zeichenketten.
Dateihandles Um in Perl eine bestimmte Datei zum Lesen, Schreiben oder Anhängen zu öffnen, benötigt man so genannte Dateihandles. Ein Dateihandle ist der.
Algorithmus. Ein Kochrezept, zum Beispiel: Kartoffelbrei.
SWITCH - Anweisung.
Datentyp- umwandlung. Literale sind: Bezeichner mit einem festen Wert wie z.B:
Strukturen. In einer Struktur kann eine beliebige Anzahl von Komponenten (Daten) mit unterschiedlichen Datentypen (im Gegensatz zu Feldern) zusammengefaßt.
Konstruktoren.
Polymorphie (Vielgestaltigkeit)
Objekte und Arbeitsspeicher
Dynamischer Speicher. In einer Funktion wird z.B. mit der Deklaration int i; Speicher auf dem sogenannten Stack reserviert. Wenn die Funktion verlassen.
EINI-I Einführung in die Informatik für Naturwissenschaftler und Ingenieure I Vorlesung 2 SWS WS 99/00 Gisbert Dittrich FBI Unido
Modularisierungstechniken
DVG Kommentare1 Kommentare. DVG Kommentare 2 Kommentare Es gibt zwei Arten von Kommentaren: einzeilige Kommentare // der Kommentar geht.
DVG Kommentare 1 Kommentare. 2 Kommentare Es gibt zwei Arten von Kommentaren: einzeilige Kommentare // der Kommentar geht bis zum Ende der Zeile.
Wir müssen also überlegen: Implementierung der Knoten, Implementierung der Kanten, daraus: Implementierung des Graphen insgesamt. Annahme: die Knoteninhalte.
Bidirektionales VFX-XML-Interface für Daten-Import/Export Visual Extend Anwendertreffen 2009 Rainer Becker, Frank Kropp deutschsprachige FoxPro User Group.
Wizards & Builders GmbH Schulung Visual SourceSafe für Visual FoxPro Norbert Abb W&B.
Wie macht man ein Sudoku? Transformations-Methode:
Bezirksregierung Detmold Hier könnte ein schmales Bild eingefügt werden Online-Beteiligungsverfahren zum Entwurf von Bewirtschaftungsplan und den Maßnahmenprogrammen.
Welche Funktion hat die php.ini? -Beinhaltet wichtige Einstellungen für PHP. Genannt seien hier u.a. der Speicherort von Cookies, Parameter der Kompilierung,
Dokumente AutorMatthias Bahr, Montanus-Realschule Leverkusen, NRW Erlernen des Umrechnens von Längen-, Flächen-, Volumen- und Masseneinheiten; Trainieren.
Ich möchte gerne mehrere Bilder auf ein Folie
Hyperlinks und Anker Links notieren
Moin. Ich benutze PPT 2002 und möchte drei Bilder nacheinander 1
Westfälische Wilhelms-Universität Münster 15-JAN-2004 Heinz-Hermann Adam Benutzung von tragbaren Computern Unter Windows in.
Einführung in die Programmiersprache C 3.Tag Institut für Mathematische Optimierung - Technische Universität Braunschweig.
Erzeugen von Karten, Layern und Legenden
Effiziente Algorithmen
Beweissysteme Hartmut Klauck Universität Frankfurt WS 06/
Copyright 2011 Bernd Brügge, Christian Herzog Grundlagen der Programmierung TUM Wintersemester 2011/12 Kapitel 11, Folie 1 2 Dr. Christian Herzog Technische.
Wird ganz am Anfang der HTML-Datei geschrieben Doctype html public bedeutet, dass man sich auf die Öffentlichkeit der html-dtd bezieht Html ist die meist.
Wie schreibe ich eine Diplom- bzw. Masterarbeit ?
Web-Publishing: HTML im Rahmen des PS aus Elektronischer Datenverarbeitung (Rechnerpraktikum)
Vom Kontext zum Projekt V Carina Berning Sabrina Gursch Pierre Streicher Intelligente Dateisysteme.
Unterprogramme in JAVA
verstehen planen bearbeiten
Allgemeine Funktionalitätsbeschreibung
Kommandozeile und Batch-Dateien Molekulare Phylogenetik – Praktikum
Medienbibliothek-islam.de Setze dein Ziel im Leben
Vom graphischen Differenzieren
Mag. Thomas Hilpold, Universität Linz, Institut für Wirtschaftsinformatik – Software Engineering 1 Algorithmen und Datenstrukturen 1 SS 2002 Mag.Thomas.
1 / 11 Organisatorisches 1.Versionsarchiv für Dokumente: z.Z. i.CMIP-CDOs.ppt.
1 / 11 Organisatorisches 1.Versionsarchiv für Dokumente: z.Z. i.CMIP-CDOs.ppt.
1 / 11 Organisatorisches 1.Versionsarchiv für Dokumente? Vorschlag: CDO-Wiki (code.zmaw); z.Z. i.CMIP-CDOs.ppt als Diskussionsgrundlage ii.CDOandCMIP-Standard.docx.
1 / 11 Organisatorisches 1.Versionsarchiv für Dokumente: i.CMIP-CDOs.ppt.
1 / 11 Organisatorisches 1.Versionsarchiv für Dokumente: i.CMIP-CDOs.ppt.
Funktionen. Aufgabe : Eingabe zweier Zahlen ---> Minimum bestimmen Dann nochmals Eingabe zweier Zahlen ---> Minimum bestimmen.
Pointer. Grundsätzliches: Im Arbeitsspeicher werden Daten gespeichert. Um auf die Daten eindeutig zugreifen zu können, werden diesen Daten Adressen zugeordnet.
1 / 11 Organisatorisches 1.Versionsarchiv für Dokumente: i.CMIP-CDOs.ppt.
Funktionen, Felder und Parameter- übergabe. Funktionsaufruf mit Feld als Parameter: Parameter = Name des Feldes.
1 / 11 Organisatorisches 1.Dokumente in: i.CDO-CMOR_Konforme-Formatierung.ppt.
1 / 11 Organisatorisches 1.Dokumente in: i.CDO-CMOR_Konforme-Formatierung.ppt.
Hilfs-Indikator Indikator
1 / 11 Organisatorisches 1.Die Dokumente CDO-CMOR_Konforme-Formatierung.ppt und Konforme_CDOs.ppt sind wieder zu einem Dokument zusammengefasst (alter.
Tutorium Software-Engineering SS14 Florian Manghofer.
Lineare Optimierung Nakkiye Günay, Jennifer Kalywas & Corina Unger Jetzt erkläre ich euch die einzelnen Schritte und gebe Tipps!
Tutorium Software-Engineering SS14 Florian Manghofer.
Förderverein Bürgernetz München Land e.V. Seite 1 von 16 Textverarbeitung-2016_06 © 2016–Günther Scheckeler Tel.: Inhalt 1 Bestandteile eines.
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:

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.nächstes Treffen am Di. ??. Nov. 10:00 in Raum 207 DKRZ Action RB & ML : einige Tage vor der nächsten WGCM Sitzung erinnern, dass die Textform abgeschickt wird. *Jeder will was Großes erreichen, ohne sich darüber im Klaren zu sein, dass das Leben aus kleines Sachen besteht. Steve * RI W

2 / 11 Organisatorisches 1.Eingabedateien zum Testen in: blizzard:/work/ik0555/cmip5/archive/CMIP5/output/MPI-M/ Die Daten werden nach mistral:/work/ik0555/cmip5/archive/CMIP5/output/MPI-M transferiert. Ende des Jahres werden wir ein Datenprojekt beantragen, damit sie darüber hinaus erhalten bleiben. 2.Z.Z. stehen sie in mistral:/mnt/lustre01/rsync/work/ik0555/... 3.Eine Testversion der CDOs gibt es unter: mistral:/home/zmaw/m214003/local/bin/cdo 4.Die Sourcen gibt demnächst unter: Welche ? der Testversion? Über die Klimaindizes reden !!!

3 / 11 CMIP[5,6,...] und CDOs Ziele: A.es gibt einen cdo operator „cmor“ mit cdo cmor,tab,[OPTION=value,...] ifile ofile-c der CMIP-konforme Ausgabedateien erzeugt, falls a)-c) erfüllt sind: a)die Eingabedatei ifile enthält CMIP Variablen mit korrekter Einheit und Aggregation; b)eine Option var enthält, wenn sie besetzt ist, eine komma- separierte Liste mit CMOR- oder MPI-ESM-Namen von CMIP tab- Variablen; wenn var nicht besetzt ist, müssen alle in ifile enthaltenen Variablen zu tab gehören; sie werden all verarbeitet; 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

4 / 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. Die ESGF-Publikation muss dann verweigert werden, mit den entsprechenden Auswirkungen auf den reibungsfreien Ablauf mit korrigierten Daten. Wenn alles schief geht, kann es passieren, dass die Daten unter falschen Instituts-, Modell-, oder Experimentnamen im ESGF liegen, und von den Datennutzern nicht gefunden werden können. Deshalb sollen die cdos in die Lage versetzt werden, gegen die CMOR-Lib zu linken, um CMIP5 und später CMIP6+² Variablen entsprechend den Projekt-Standards zu formatieren. Es wird angestrebt, dass dieser Operator auch von Programmierern benutzt wird, die vorher schon mit der CMOR-Bibliothek gearbeitet haben. Das bedeutet, dass das Verhalten des CDO-Operators dem der CMOR-Bibliotheks-Aufrufe möglichst nahe kommen sollte. ²DECK, CMIP6, und endorsedMIPs

5 / 11 A.Konforme Formatierung: cdo cmor,tab,[OPTION=value,...] ifile ofile-c Bemerkungen: 1.Der Name der Ausgabedatei ist durchgestrichen, um zu erinnern, dass er nicht gesetzt werden kann! 2.Es müssen nicht alle tab-Variablen in i-file enthalten sein. 3.Die Ergebnisdatei ofile-c wird nur eine Variable enthalten, sonst ist sie nicht CMIP-konform. Das wird durch die CMOR-Bibliothek sichergestellt. 4.Da die Erfahrung zeigt, dass nicht garantiert werden kann, dass die Dateien mit den verlangten Namen abgegeben werden, solange Freiheiten in der Namensgebung bestehen, soll der Name der Ausgabe-Datei, der von CMOR gesetzt wird, nicht veränderbar bzw. nicht anzugeben sein. Es können Konflikte zwischen den Use- Cases aus dem WF der Wissenschaftler, die normalerweise weniger Restriktionen wünschen, und Use-Cases im Zusammenhang mit der Aufbereitung für das offizielle CMIP-Archiv entstehen. Z.B. könnte gewünscht werden, den ofile-c Namen angegeben zu können, wenn im WF der Wissenschaftler der vorgeschriebene Name nicht akzeptabel ist. Die gewünschten Freiheiten sollen zulassen werden, wenn ein bestimmter environment-Parameter (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). 5. cdo cmor muß wg. der operationellen Kettenverarbeitung auch die append-Funktion der CMOR2 Bibliothek ermöglichen. Für den täglichen WF bei der Datenverarbeitung und Analyse ist das nicht zwingend notwendig, und es kann auch der Befehl ‚cdo cat...‘ benutzt werden. Dazu müssen aber zunächst die CDOs CMIP-konform arbeiten (s. Punkt B. oben). Wg. der kommenden CMIP6-Aktivitäten und den damit verbundene Terminen kann nicht riskiert werden, sich von B. oder C. abhängig zu machen. Eventuell gibt es auch Performanzgründe für die Benutzung der CMOR-Append-Funktionalität. CMIP und CDOs

6 / 11 CMIP und CDOs

7 / 11 CMIP und CDOs: Konforme CDOs B. Konforme CDOs 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) 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.

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

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

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

11 / 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, da die MIP-Tabellen am PCMDI gepflegt werden. Wir wollen nicht lokale Versionen pflegen, das macht zu viel Arbeit bei den CMOR-Lib-Upgrades. 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.

12 / 11 A.Konforme Formatierung letzte Ausbaustufe: Die Verarbeitung in cmor.x wird Schritt für Schritt in die CDOs verschoben. In der letzten Stufe werden die CMOR Bibliothek-Aufrufe in den CDOs getätigt: DKRZPCMDIMPI-M cdo cmor ifile cmor.xcmorN.a/so ofile-c X PCMDIMPI-M cdo cmor ifile cmorN.a ofile-c Name wird von CMOR gesetzt

13 / 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)Es gibt 2 Optionen für den Wert, der an chunk übergeben wird: i.Falls es nicht möglich ist, den Namen der Datei, an die angehängt werden soll, aus den Eingabeparametern incl. dem Inhalt von efile, ufile, und mfile herzuleiten, kann der Name oder unbekannte Namensteil mit chunk übergeben werden. Wenn chunk nicht besetzt ist (Default) wird eine neue Datei begonnen. ii.Andernfalls reicht es, ‚replace‘ (Default-Wert) zu übergeben, wenn eine neue Datei begonnen werden soll, bzw. ‚append‘, wenn die Daten an eine schon vorhandene Datei anzuhängen sind. A.Konforme Formatierung

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

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

16 / 11 A.Konforme Formatierung: CommandLineEingabe

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

18 / 11 B. Konforme CDOs B. die cdos sollen so weit wie möglich CMIP konforme Dateien liefern Vergleiche header von allen CMIP5 Dateien in /mnt/lustre01/rsync/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.

19 / 11 All realms / grids: 1.bnds => nb2 ok! 5.time:axis = "T„ geht verloren ok! 6.global history-Attribut anhängen: ok! mit –no_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) 8.creation_date muss er-/gesetzt werden ok! (wird übernommen 9.time:units = "days since’ ‘ :00:00" statt time:units = "days since’ ‘ :00:00" ok! (ev. KT, CD fragen) B. header–Vergleich nach cdo copy

20 / 11 Realm / grid atmos: 1.var:cell_measures = “area: areacella“ geht verloren; action! 2.Location von areacella in var: associated_files = "baseURL: geht verloren; ok! 3.var:grid_type = “gaussian“ ; kein Problem! 4.Single value dimension in CMOR (siehe andere Beispiele unten): Beispiel: float sfcWind(time, lat, lon) ; sfcWind: coordinates = "height" ; double height ; height:axis = "Z" ; height:long_name = "height" ; height:positive = "up" ; height:standard_name = "height" ; height:units = "m" ; ² data: height = 2 ; B. header–Vergleich nach cdo copy geht nicht mehr verloren; aber wird nicht erzeugt ok! Wir müssen überlegen, wie wir damit umgehen;

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

22 / 11 Realm / grid atmos: 1.Vertical coordinate B. header–Vergleich nach cdo copy

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

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

25 / 11 B. header–Vergleich nach cdo copy

26 / 11 B. header–Vergleich nach cdo copy

27 / 11 B. header–Vergleich nach cdo copy

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

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

30 / 11 Alle: 1.frequeny : a) „day“ => „mon“ ist vonnöten nach ‚cdo monmean‘: immer frequeny = „freq“ aus frequeny-CV von CMIP5 setzen Action! 2.ensmean: Was passiert mit verschiedenen Attributwerten? (z.B. model_id) 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“ e)realization = * C. header–Vergleich nach cdo operations

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

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