AP3 - Infrastructure For Adaption To CMIP6 Project Standards¶
Ansprechpartner Martin Schupfner (schupfner@dkrz.de)
Historie CMOR Fortran Programm¶
Das CMOR Fortran Programm liest aus den bereits aggregierten Modelldaten alle notwendigen Felder für Daten und Gitter, bereitet sie wenn notwendig auf und
übergibt sie mit Metadateninformationen den cmor-Funktionen, die den Outputfile erstellen.
Das CMOR Fortran Programm hat sich im Laufe der Zeit aus mehreren kleinen Programmen (mit cmor1 Library), die für die Datenaufbereitung zum
TAR benutzt wurden, entwickelt und war in CMIP5 (jetzt mit der cmor2 Library) Teil einer Model- und Dateninfrastruktur (IMDI),
allerdings sehr speziell für die Klimamodelle des MPI-M konzipiert.
Ziel der Neuausrichtung ist, einen Operator für die "Climate Data Operators" (cdo) zu schaffen, der für den Output aller Klimamodelle verwendbar ist. Dabei sind
Anwendungen weiterer cd-Operatoren für ein pre-processing möglich. CMOR soll so (auf Basis der cmor3 Library) in den Operator Ablauf der cdos integriert werden
und den MIP spezifischen Output liefern.
Bis dahin soll eine Übergangslösung mit Fortran-Programm und ksh-Script mit dem "Look & Feel" der finalen Lösung zur Verfügung stehen.
Milestones¶
1. Skript für diagnostische Nachbereitung der Modellrohdaten von MPI-ESM1 (2016-9)¶
Die Stelle für die Arbeiten in AP3 konnte erst nach 2,5 Monaten, d.h. zum 15. September besetzt werden. Damit gibt es jetzt eine entsprechend Verzögerung.
Die Arbeit am Skript für das diagnostische Aufbereiten der MPI-ESM1-Modellrohdaten ist für die Atmosphären- und Landvariablen von Phase 5 (CMIP5) beendet.
Gegenwärtig wird geprüft, inwieweit es Änderungen gibt wg. neuer Anforderungen von CMIP6 und wg. des Updates von MPI-ESM1.0 nach MPI-ESM1.2.
Fast alle Variablen wurden mit dem CDO-CMOR-Wrapper CMIP-konform aufbereitet. Das Fortranprogramm, das im Wrapper gerufen wird, hat mehr Zeit beansprucht als geplant, da die Aufbereitung von Variablen mit einer CHARACTER-Achse als 3. Dimension Probleme bereitet (s.u.). Ein vollstandiges Re-Design und Re-Coding ist nötig, da das in CMIP5 benutzte Programm auf das MPI-ESM1.0 zugeschnitten war, das in CMIP5 benutzt wurde. Das neue Programm soll ESM-unabhängig sein.
Zum Einlesen der Input(Roh)daten soll die CDI-Bibliothek benutzt werden, da sie ein formatunabhängiges Einlesen von z.B. NetCDF- und GRIB-Daten erlaubt. Hier haben sich unerwartete Probleme mit dem Datenmodell der CDI/CDOs ergeben, wenn eine 3. Raumachse in den Daten existiert, die nicht die vertikale (sigma-hybrid, pressure, height, depth) ist. Dies Problem wird gegenwärtig (Nov 2016) untersucht. Es ist auch Gegenstand von AP3-Task2 (siehe WP2.2 im Antrag zum Vorhaben DICAD).
Im nächsten Schritt müssen einige Jahre eines gekoppeltes CMIP5-Experiment (vorzugsweise esmrcp85) durchgeführt werden, um die diagnostische Nachbereitung der Ozean- und BGC-Variablen mit dem neuen Programm testen zu können.
2. Werkzeug zum Prüfen des potentiellen CMIP-Variablenumfangs (2016-12)¶
Nutzung der von offizieller Seite veröffentlichten DreqPy API (Data Request Python Application Programming Interface), erweitert bzw. konfiguriert für die eigene Nutzung als WebGUI unter https://c6dreq.dkrz.de. Es sind jedoch laufend Anpassungen nötig, da weder die CMIP6-Datenanforderung noch die DreqPy-API in einer finalen Version vorliegen und sich durch Updates teilweise deutlich ändern. Durch das WebGUI ist es dem Anwender möglich den Variablenumfang je Experiment und Endorsed MIP einfach zu bestimmen und im ".csv"- oder ".xls"-Format herunterzuladen, sowie das ungefähr zu erwartende Datenvolumen zu berechnen ohne selbst den Umgang mit der DreqPy API erlernen oder die Software lokal installieren zu müssen.
Des Weiteren steht eine weitere webbasierte Applikation zur Erstellung einer Variablenzuordnungstabelle zwischen Modell- und CMOR-Variablen zur Verfügung. Hierdurch ist es möglich, dass verschiedene Modellierer gleichzeitig an der Erstellung der Variablenzuordnung arbeiten. Ein weiterer Vorteil ist die größere Übersichtlichkeit über die einzelnen Variablen und die Nachverfolgbarkeit von Änderungen der Variablen-Definitionen in der Datenanforderung.
Zur weiteren Information stehen zur Verfügung:
- Redmine-Wiki-Seite: Data Request and Variable Mapping WebGUI
- Einführungs-Video zur Nutzung des 'Data Request Web GUI'
- Einführungs-Video zur Nutzung des 'Variable Mapping Web GUI'
- Einführungs-Slideshow zur Nutzung des 'Variable Mapping Web GUI'
- "Ausführliches PDF-Dokument zur Nutzung beider Web GUIs": Entwurf folgt bald
- Nochmals Link zu beiden Web GUIs
Struktur des Datenrequests
Ein MIP hat wissenschaftliche Ziele. MIP definiert Experimente, die in Gruppen gegliedert sind.
Der Datenrequest selbst ist in Request Items eingeteilt, welche von MIPs, Experimenten oder Experiment-Gruppen verlangt werden.
Ein Request Item legt die Zeitspanne für die verlangten Daten fest und kann ebenso die Priorität und Tier der verlangten Variablen bzw. der Experimente überschreiben.
Das MIP definiert die Request Variablengruppe, wobei eine Variablengruppe mehreren Request Items zugeordnet sein kann (mit variierender Zeitspanne, Priorität und Experiment-Tier). Eine Request Variablengruppe enthält Request Variablen. Diese sind praktisch Links zu CMOR Variablen und mit einer Priorität versehen.
Einige CMOR Variablen sind mit einer Variable Choice verknüpft, und damit abhängig von einer Hierarchie oder speziellen Modellkonfiguration verlangt oder nicht.
Jede CMOR Variable ist mit einer Struktur verknüpft, welche mit der temporalen und räumlichen Form verbunden ist und ebenso mit der Information über die Cell Methods.
Erstere sind noch einmal im Grid zusammengefasst. Grids und MIP Variablen sind schließlich mit einem Standard-Name verknüpt.
3. Script for conformal formatting of CMIP6-data (2017-3)¶
Sobald Milestone 1, die Erstellung des Skriptes für die diagnostische Nachbereitung der MPI-ESM1 Modellrohdaten, abgeschlossen ist,
wird dieses Skript um die CMORisierung (Anpassung des Datenformates an CF- und CMIP-Konventionen mithilfe der CMOR-Bibliothek) erweitert und der diagnostische Teil für alle deutschen Modelle (im Projekt) zur flexiblen Anwendung gestaltet.
4. Software für modulare und flexible Ablaufsteuerung von Workflowschritten (2017-7)¶
Die in Milestone 1 und 3 angesprochenen Skripte zur diagnostischen Nachbereitung sowie zur CMORisierung werden automatisch erzeugt. Mit ihnen lassen sich ausgewählte Variablen prozessieren. Die Auswahl erfolgt nach folgenden Kriterien: Datenanforderung für die jeweilige Modellsimulation von CMIP6, Verfügbarkeit der Variable im Modell. Die zusätzliche Hinzunahme oder Entfernung von Variablen ist möglich, sofern sie im Modell verfügbar sind und eine offizielle Definition (MIP-Tabelleneintrag) existiert.
Um je Modell die Verfügbarkeit der angeforderten Variablen zu dokumentieren und um Modell-Variablen den angeforderten Variablen zuzuordnen, wurde ein weiteres Web-GUI entwickelt und zur Verfügung gestellt.
5. Dokumentation über Nutzbarkeit der Infrastruktur für lokale Anwendungen außerhalb CMIP (2018-3)¶
Anschließend an den Workshop (Milestone 6) wird die Nutzbarkeit der Infrastruktur für andere MIPs und Anwendungen untersucht und dokumentiert werden.
Die Erfahrungsberichte der Nutzer können ebenfalls dazu verwendet werden.
6. Workshop für Nutzer der Infrastruktur (2017-12)¶
Ende 2017 ist ein Workshop am DKRZ geplant. Dieser wird das Ziel haben, den Nutzern die entwickelte Software zur Nachbereitung und CMORisierung der Daten nahezubringen. Das umfasst auch den Umgang mit den entwickelten Web-GUIs sowie die operationelle und interaktive Nutzung von cdo-cmor.
7. Unterstützungsinfrastruktur existiert (2017-12)¶
Nach dem Workshop werden die Nutzer weiterhin von den Entwicklern bei der Anwendung der Software unterstützt und beraten, wie es auch jetzt schon der Fall ist.
8. Verbesserte nachhaltige Infrastruktur (2020-3)¶
Eventuell wird ein Workflowmanager (z.B. cylc) eingesetzt werden um die Nachbereitung der Daten zu steuern.
Ob dem Workflow weitere Abläufe, wie die Metadatenverarbeitung, hinzugefügt werden können muss noch abgewartet werden.
Attachments¶