AP2 - Anpassung der CDOs an den CMIP6+ Datenstandard¶

Ansprechpartner Fabian Wachsmann (wachsmannATdkrz.de)

Ein Vorhaben dieses APs ist, die Erzeugung von Klimadaten, die den CMIP6+ Datenstandard erfüllen, mit den CDOs* zu ermöglichen, um den Datenprozess und dessen Automatisierung zu vereinfachen. Dazu soll die CMOR**-Bibliothek in die CDOs integriert werden und mittels eines Operators aufgerufen werden können.
Zum Anderen sollen CDOs diesen Datenstandard beibehalten, wenn sie auf CMIP6+ konforme Daten angewendet werden. Dies erfordert die Anpassung des Metadaten- und des Datenmodels der CDOs an den CMIP6+ Datenstandard.

News¶

Stand 10.10.2017

• Eine ausführliche Dokumentation findet sich unter dem Tab 'Documents'
• Ein Tutorial vom 10.10. wird bereitgestellt. Die darin vorkommenden Kommandos können auf der mistral durchgeführt werden.

Stand 7.9.2017:

• Die CDOs können mit CMOR Versionen ab Version 2.92 installiert werden. Es gibt immer nur einen cdo cmor Operator.
• Vorinstallierte CDOs installiert mit unterschiedlichen CMOR Versionen finden sich auf der Mistral unter /work/bm0021/cdo_incl_cmor .
• Beim Aufruf des Operators müssen MIP-Tabellen an den Operator übergeben werden, die vom offiziellen Datenrequest abhängig sind. Das heißt, für die Nutzung einer aktuellen CMOR-Version benötigt man die aktuellen MIP-Tabellen und andersherum.

Milestones¶

1. CDO CMOR ist anwendbar auf CMIP5-Variablen (2017-03)¶

Wie cdo cmor die CMOR-Funktionen aufruft wird auf dieser Seite skizziert. Dies war Ausgangspunkt der Entwicklung des Operators.

Wie es war
Die Anwendung von CMOR Funktionen erwies sich auf Grund ihrer Komplexität als schwierig. Bei speziellen Datensätzen verändert sich das Protokoll zur Übergabe von Daten an CMOR und seine Funktionen müssen in anderer Form aufgerufen werden: Beispielsweise müssen bei der Verwendung eines rotierten Gitters die darauf berechneten Variablen auf eine von der Norm abweichende Art in CMOR übergeben werden. Weiterhin rufen die durch das "Controlled Vocabulary" festgelegten Namen für Achsen und Dimensionen Probleme hervor, da sie namensgetreu angegeben werden müssen, aber vom CF-Standard abweichen können.

Der Plan
CDI*** Funktionen können diese Probleme verhindern, da mit ihnen Gitter- und Achsentypen erkannt werden können. Deshalb ist ein cdo cmor Operator geplant, der die Erzeugung von CMIP6+ konformen Daten mit CMOR durch Nutzung der CDI Funktionen vereinfacht.

Aktueller Stand
Zunächst wird ein funktionierender Operator für den CMIP5 Standard entwickelt, in welchem die CMOR Version 2.92 benutzt wird.
Probleme: Bei Klimadaten mit Characterdimensionen fehlt CDI die Einlesemöglichkeit. Diese zu erstellen benötigt Zeit (Stand Nov 2016) und einen Eingriff in das Datenmodell der CDIs. Betroffen sind vorerst bestimmte Ozeanmodelldaten (Overturning) und Landdaten (LandCoverFraction).
Enticklung: Die Entwicklung und damit die grobe Funktionsweise des cdo cmor Operators wird im Folgenden anhand der Steuerung und Verarbeitung der CMOR Funktionen vorgestellt:

2. CDO CMOR ist an den CMIP6 standard angepasst (2017-06)¶

Updates:

• Die CDOs wurden von C auf C++ umgestellt
• CMOR-Versionen ab 3.23 können ebenfalls an die CDOs angelinkt werden. Der aktuelle Datenrequest kann allerdings immer nur mit der aktuellen CMOR Version verarbeitet werden, da beides noch nicht stabil ist.
• Zwar verändern sich die Eingabeformate und Funktionsaufrufe zwischen den CMOR2 und CMOR3 Versionen - auf die Steuerung des cdo cmor Operators wirkt sich das nur insofern aus, dass während des Prozessings ein temporärer File erzeugt wird. Dementsprechend gibt es nur ein Source-file und einen Operator cdo cmor für alle CMOR Versionen.

3. Das CDO Metadatenmodell ist an den CMIP standard angepasst (2017-12)¶

4. Das CDO Datenmodell ist an den CMIP standard angepasst (2018-06)¶

Derzeit wird eine Verarbeitungsroutine entwickelt, mit der Character-Koordinaten-Variablen gelesen und verarbeitet werden können. Diese kommen bei Ozeanvariablen wie dem Overturning aber auch bei Landdaten vor. CDI*** ist zur Zeit darauf ausgerichtet, auf Gitter projezierte Daten und Zahlen statt Zeichen zu prozessieren. Innerhalb des NetCDF Datenmodells sind allerdings auch Characterkoordinaten möglich, sodass es einer Anpassung an diesen Standard bedarf.

5. Klimaindizes werden von CDO korrekt berechnet und erfüllen die Anforderungen der Klimaforscher (ETCCDI, ECA&D, CORDEX, etc) (2020-03)¶

Eine Analyse der 27 core-Indices, die vom ETCCDI definiert werden, ergab Unterschiede zwischen den Resultaten der in CDO implementierten entsprechenden ECA-Indices und denen des vom ETCCDI empfohlenen Programms Climdex. Diese hatten verschiedene Ursachen:

• Die Outputfrequenz eines Indices konnte in CDOs nicht festgelegt werden. Stattdessen wurde der Index für die gesamte Zeitreihe berechnet. Die ETCCDI-Indices werden aber jährlich bzw. monatlich abgespeichert.
• Die CDOs boten keine Möglichkeit, die Länge von Perioden, die mehrere Jahre überlappen, in Indices mit einzubeziehen.
• Perzentile wurden unterschiedlich berechnet:
  • In Climdex wurde eine spezielle R-Methode (basierend auf dem Programmiersprache R) für die Berechnung angewendet, welche in CDO nicht implementiert war.
  • Damit Anfang und Ende einer Referenzperiode in der Perzentilberechnung basierend auf einem Fenster von 5 Tagen mit einbezogen wurde, musste umständlich eine neue Zeitserie zusammengegestellt werden.
• Für Indices, in denen die Überschreitungswahrscheinlichkeit bestimmt werden sollte, fehlte es an einer Bootstrapping-Methode. So unterschätzten die CDOs diese Indices systematisch für die Referenzperiode.

Um diese Ursachen zu beheben, wurden ETCCDI Operatoren entwickelt entsprechend der Form der Eca Operatoren, z.B.

 cdo etccdi_fd 

für frost days. Viele davon basieren auf den Eca-Operatoren und werden nun in der help-Funktion mit dem jew. ursprünglichen ECA Operator zusammengefasst. So werden auch Nutzer der ECA Operatoren auf die Neuerung aufmerksam gemacht, wenn sie die help-Funktion nutzen. Bei der Entwicklung wurde darauf geachtet, dass die vorhandenen ECA Operatoren in ihrer Funktion nicht eingeschränkt werden.

Mit der Möglichkeit, die Outputfrequenz zu setzen, werden nun auch Perioden mit überlappenden Jahren mit in den Index einbezogen. Bei

cdo eca_cdd

werden die consecutive dry days gezählt, wobei die längste Periode der gesamten Zeitreihe abgespeichert wird. Mit

cdo etccdi_cdd

wird nun so eine Periode für jedes Jahr der Zeitserie abgespeichert und Perioden in überlappenden Jahren ebenfalls mit bewertet. Letztere zählen dann zum letzten Jahr, in dem sie auftreten. Sollte über die gesamte Outputfrequenz eine Periode vorliegen, wird für das entsprechende Zeitintervall der Wert auf NAN gesetzt. Die Option, die Outputfrequenz zu setzen, ist nun nach Angabe der bisherigen Parameter für beide Operatoren möglich:

cdo eca_cdd,1,5,freq=month
cdo etccdi_cdd,1,5,freq=month

Das empirische p-Quantil Q, hier als Percentil bezeichnet, ist definiert als Linearkombintation der zwei Werte in einem nach Größe sortierten Datensatz, die am nahesten an Q liegen:

In der 8. R-Methode zur Percentilberechnung werden j und f definiert als:

Hier ist p das Percentile und n die Anzahl der Histogrammwerte.

Diese wurde nun in die CDOs implementiert. Außerdem gibt es nun einen Parameter, der es bei der Perzentilberechnung basierend auf einem Tagesfenster ermöglicht, die Einlesemethode zu setzen:

cdo ydrunpctl,10,5,pm=r8,rm=c infile outfile

Der erste Parameter ist weiterhin das Percentil, der zweite die Größe des Fensters. Neu ist: pm, die percentile method, rm, die read method. pm=r8 bedeutet, dass die R8-Methode benutzt werden soll; rm=c heißt, dass zeitlich zyklisch ("cyclic") eingelesen werden soll, d.h. Anfang und Ende der Zeitserie werden nicht abgeschnitten

Eine neue Bootstrappingmethode erforderte den Einbau eines neuen Moduls für Indices, die eine Überschreitungswahrscheinlichkeit darstellen. Die Routine für die betroffenen Indices umfasste u.a., die Zeitserie mehrere Male zusammenzusetzen und jew. ein Perzentil zu berechnen. Für diese Indices ist es nun auch möglich, mit single precision Werten zu prozessieren und diese auszugeben, um Arbeitsspeicher zu sparen. Die Anwendung hat die Form:

CDO_PCTL_NBINS=302
cdo --float tx90p,5,1961,1990,freq=month tasmax tasmaxrunmin tasmaxrunmax outfile

Mit CDO_PCTL_NBINS=302 wird festgelegt, wieviele BINs das Histogramm hat. Diese Zahl ist abhängig vom maximal verfügbaren Arbeitsspeicher. Solange genügend Speicher vorhanden ist, werden alle Werte aller Gitterpunkte im Arbeitsspeicher gehalten anstat dass ein Histogramm erzeugt wird. Die Option --float sagt, dass single precision Genauigkeit für das Processing verwendet werden soll. Der erste Parameter ist die Länge des Fensters; der zweite und dritte sind jew. Start bzw. Ende des Bootstrappingintervalls. Als zusätzlichen Parameter kann die Outputfrequenz angegeben werden.

Da die CDOs an das Einlesen über die Zeit gebunden sind, ist die Performance dieser neuen Gruppe von Operatoren limitiert: Für das MPI-ESM1-2-LR und eine 30jährige Referenzperiode müssen Daten in der Größenordnung 10GB im Arbeitsspeicher gehalten werden. Zwar konnte durch OpenMP-Parallelisierung eine Performance realisiert werden, die Nahe der des Climdex Programm ist, aber das Climdex Programm prozessiert in dieser Zeit alle Indices.

Einige Metadaten werden von den ETCCDI Operatoren nun so gesetzt, wie es Climdex macht: Name, Longname, units und Zeitwerte. Hier gibt es aber noch keine definierten Standards. Der Autor hält es aber für sinnvoll, den Index eines Jahres in die Mitte des Jahres zu setzen, anstatt an den letzten Tag, der in die Berechnung des Wertes mit einging - wie es bei den ECA Operatoren der Fall war.

(*) Climate Data Operators sind eine Sammlung von über 600 Commandline Operatoren, mit denen Klima- und Wettermodelldaten bearbeitet und analysiert werden können. Sie unterstützen eine Vielzahl von Datentypen und haben geringe Speicheranforderungen. In CMIP6 sind sie maßgeblicher Bestandteil der Verarbeitung und Aufbereitung des Datenoutputs der verschiedenen Modelle.

(**) Um die Vergleichbarkeit der Modelldaten innerhalb des Projekts zu gewährleisten, müssen diese einem definierten Standard entsprechen. Das letzte Glied in der Datenprozesskette ist deshalb die Nachbereitung mit Hilfe der CMOR Bibliothek zur Sicherstellung dieses Standards. Dabei werden auf Basis des Inputfiles, Metadaten und speziellen Tabellen selbstbeschreibende, CF-konforme Daten vom netCDF Typ erzeugt.

(***) Climate Data Interface ist ein Werkzeug zum Einlesen von Klima- und Wettermodelldaten. Es ist der Hauptbaustein der CDOs.