1 / 11 Organisatorisches 1.Versionsarchiv für Dokumente: z.Z. i.CMIP-CDOs.ppt.

1 / 11

Organisatorisches

1. Versionsarchiv für Dokumente:https://code.zmaw.de/projects/cdo/wiki/CMOR z.Z.

i. CMIP-CDOs.ppt als Diskussionsgrundlageii. CDOandCMIP-Standard.docx (noch nicht)

2. Eingabedateien zum Testen in:/work/ik0555/cmip5/archive/CMIP5/output/MPI-M/

3. nächstes Treffen am Di. 28. Juli 10:00 in Raum 207 DKRZ

https://code.zmaw.de/projects/cdo/wiki/CMOR

2 / 11

CMIP[5,6,...] und CDOsDefinition: file-c sind soweit wie möglich CMIP-konforme DateienDefinition: „so weit wie möglich“: vollständig für CMIP-VariablenDefinition: CMIP5-Variablen sind die in standard_output.xls

A. es gibt einen cdo operator „cmor“ mit cdo cmor,var,tab,... ifile ofile-c

der CMIP-konforme Ausgabedateien erzeugt,falls: ifile enthält genau eine CMIP Variable inkl. ancillary_variables

var ist ein CMIP oder MPI-ESM VariablennameB. die cdos liefern grundsätzlich so weit wie möglich CMIP-konforme

Dateien C. cdo Ausgabe von CMIP-konformen Eingabedateien ist so weit wie

möglich CMIP-konform cdo <operator> ifile1-c ... ifilen-c ofile-c

3 / 11

CMIP[5,6+,...] und CDOs: WordingA. Konforme Formatierung:

cdo cmor,var,tab,... ifile ofile-cHintergrund:Es soll einen Befehl geben, der benutzt werden kann, bzw. soll, um CMIP5 und später CMIP6+² Variablen entsprechend den Projekt-Standards zu formatieren. Die Ergebnisdatei ofile-c wird nur eine Variable enthalten, sonst ist sie nicht CMIP-konform. CMIP-konform bedeutet, dass die Daten ins ESGF eingefüllt werden können. Dafür ist es essentiell, dass die Daten den vom Projekt vorgeschriebenen Namen haben. Die Erfahrung mit Daten, die zur ESGF-Publikation eingereicht wurden, zeigt, dass leider nicht erwartet werden kann, dass die Daten mit den verlangten Namen abgegeben werden, solange Freiheiten in der Namensgebung bestehen. Bei der ESGF-Publikation muss dann die Annahme der Daten verweigert werden, mit den entsprechenden Auswirkungen auf den reibungsfreien Ablauf. 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. Aus diesem Grund soll es nicht möglich sein, den Ausgabefilenamen anzugeben, weshalb der oben angegebene Dateiname durchgestrichen ist. Kalle sieht es kritisch, wenn kein o-file-c Namen angegeben werden kann, da im WF der Wissenschaftler der vorgeschriebene Name nicht akzeptabel sein kann.Um Konflikte zwischen den Use-Cases aus dem WF der Wissenschaftler und Use-Cases im Zusammenhang mit der Aufbereitung für das offizielle CMIP-Archiv zu lösen, ist es vielleicht einfacher, 2 CDO-Operatoren zu entwickeln.Das macht es leichter, die Restriktionen aus dem CMIP-Standard durchzusetzen. Es muss im Fokus behalten werden, dass sowohl die CDOs als auch die Skripte auch außerhalb des MPIs benutzt werden (sollen).

²DECK, CMIP6, und endorsedMIPs

4 / 11

CMIP[5,6+,...] und CDOs: WordingA. Konforme Formatierung:

cdo cmor,var,tab,... ifile ofile-c

Vorschlag: ein zweiter Operator

cdo pcmor,var,tab,... ifile ofile-c

soll die gewünschten Freiheiten zulassen

Bemerkung: ‚cmor‘ muß wg. der (jährlichen) operationellen Kettenverarbeitung einen ‚chunk_range‘ übergeben; für pcmor ist das nicht zwingend notwendig. Wenn die CDOs CMIP-konform arbeiten, könnte man das auch mit einem nachgelagerten ‚cdo cat ...‘ erledigen. Letzen Endes eine Entscheidung am MPI-M.

Bemerkung: Optimalerweise sollte cdo cmor,,tab,... alle Variablen in einer Datei CMIP-konform aufbereiten. Voraussetzung ist, dass alle Variablen in der Datei einen CMIP-Standardnamen haben. Dazu müssen sie zu derselben MIP-Tabelle ‚tab‘ gehören. Ein falscher Name würde – wenn er in einen CMOR-Bibliotheksaufruf übergeben wird, einen Abbruch durch die Bibliothek erzeugen. 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.

5 / 11

CMIP[5,6+,...] und CDOs: WordingB. Konforme CDOsdie cdos liefern grundsätzlich so weit wie möglich CMIP konforme Dateien

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 über den Aufruf ‚cdo cmor,var,tab,... [-selname,var] ifile‘ wiederhergestellt werden.

6 / 11

A. Konforme Formatierung

1. Ausbaustufe:

Vorteil:• wohldefinierte Schnittstellen• transparenter Übergang CMIP5 CMIP6 CMIP7 ...• implementierbar ohne weitere Änderungen der CDOs• eventuell Tabelle mit Zuordnung :

CMIP-Variablenname <-> ECHAM-,JSBACH-,MPIOM-,HAMOCC-Codenr. • zusätzliche CMIP Tabelle(n) mit lokalen Variablen/Experimenten möglich

cdo cmorifile

cmor.x cmor2.aofile-c

DKRZ PCMDIMPI-M

Name wird von CMOR gesetzt

7 / 11

CMIP[5,6,...] und CDOsIMDI/CMOR Postprocessing workflow für CMIP5 Experimente

cmor.a

cmor.x

NetCDFfiles(shape**)

8 / 11


Der ‚shape‘-Parameter (siehe letzte Folie unten rechts) ist problematisch für die Nutzer, es ist aber nicht klar, ob er abgeschafft werden kann.• Eine einfache, aber suboptimale Lösung wäre, dies über eine Tabelle zu pflegen. Es

ginge aber nicht über eine MIP-Tabelle, sondern nur über eine zusätzliche Tabelle, z.b. ([cmip-var=tas,echam=temp2,shape=agrid],...). Für nicht-CMIP-Variablen müssten also 2 Tabellen gepflegt werden.

• Eine zweite Lösung wäre, die Übergabe zwingend zu machen, aber viel Support zu geben (Ausgabe von möglichen 2D-shapes, 3D-shapes,...).

Noch problematischer wird es, wenn darüber nachgedacht wird, auch Daten von anderes ESMs zu verarbeiten – optimalerweise, ohne genau zu wissen wie die Gitter aussahen.

cdo cmorifile


DKRZ PCMDIMPI-M


9 / 11


letzte Ausbaustufe:

Die Verarbeitung in cmor.x wird Schritt für Schritt in die CDOs verschoben. In der letzten Stufe werden die CMOR Library-Aufrufe in den CDOs getätigt:

DKRZ PCMDIMPI-Mcdo cmor

ifilecmor.x cmor2.a

ofile-cXPCMDIMPI-M

cdo cmorifile

cmor2.aofile-c



10 / 11

A. Konforme Formatierung: Eingabe

cdo cmorifile


var: variable nametab: MIP table namerealm³shape²³[chunk-range]ffilegfileifile

command-line Eingabe

branch_timebasetimeexperiment_idforcingparent_experiment_idparent_experiment_ripinitialisation_methodphysics_versionrealization[ comment history references]²

command-line file name: ffile

input_dirtabs_dirgrids_dirarch_dirproject_idinstitute_idmodel_idcalendarcontactsourceproduct

env. params file name:gfile

² optional³ nicht benötigt²³ kann eventuell aus den Daten abgeleitet werden

11 / 11

A. Konforme Formatierung: Aufrufcdo cmorf,ffilecdo cmorg,gfile cdo cmor,var,tab[[,realm],shape[,chunk-range]] ifile ofile-c

odercdo cmor,var,tab[[,realm],shape[,chunk-range]] [-cmorf,ffile] [-cmorg,gfile] \ ifile ofile-c

var: variable nametab: MIP table namerealmshapeffilegfile [es gibt default name]ifile

command-line Eingabe

branch_timebasetimeexperiment_idforcingparent_experiment_idparent_experiment_ripinitialisation_methodphysics_versionrealization[ comment history references]

command-line file name: ffile

input_dirtabs_dirgrids_dirarch_dirproject_idinstitute_idmodel_idcalendarcontactsourceproduct

env. params file name:gfile

hier handelt es sich nur um einen Vorschlag; Action !: Uwe teil mit, wie das Interface aussehen soll

12 / 11

A. Konforme Formatierung: CommandLineEingabe

cdo cmor,var,tab[[,realm],shape[,chunk-range]] -cmorf,ffile -cmorg,gfile ifile ofile-c

cdo cmorifile


var: variable name (CV) tab: MIP table name (CV)realm (CV)shapeExpid-fileProj-fileifile

command-line Eingabe:

23. Juni 15

I. Wird ‚tab‘ benötigt?Z.B.: ‚tas‘ existiert in tab=Amon, day, und 3hr.Kann nicht aus der Frequenz hergeleitet werden, wenn lokale Tabellen (z.B. myAmon) existieren.

II. Wird ‚realm‘ benötigt? Nein. In CMIP5 nur zum Aufbau einer Verzeichnis-Struktur, um die alte Datei im Fall eines ‚append‘ zu finden. Es ist nicht ganz klar, welche Rolle die Verzeichnisstruktur in CMIP5 spielen wird.

III. Wird ‚shape‘ benötigt? Action ! Kann man vielleicht aus den Dimensionen herleiten...

IV. ‚chunk_range‘ könnte aus den Datumsangaben in der NetCDF-Datei abgeleitet werden; dazu müsste auch das Datum und CMOR-Darstellung des Zeitranges im Dateinamen der Vorgängerdatei abgeleitet werden; und das Verzeichnis muss

durchsucht werden. Ist das möglich ? Action !


13 / 11

cdo cmor,var,tab[,[realm,]shape[,chunk-range]] -cmorf,ffile -cmorg,gfile ifile

Für CMIP5 und CMIP-Daten:IV. shape (DKRZ CV): agrid, ogrid, alevel, ...

Systematisch: axy, oxy, axyl, axyp, oyz, ... (passages, basins?)Kann man das aus den Daten herleiten? Aus ‚var‘ und Daten?Wurde zum Chunking benötigt.

V. ffile: Namenskonvention (‘experiment_id‘_‘rip‘...ksh) ? Default (experiment_id_rip.ksh) ?environment parameter => experiment_id_rip.ksh => ffile

VI. gfile: Namenskonvention (‚project_id‘_‘institute_id‘_‘model_id‘...ksh) ? Default (project_id_institute_id_model_id.ksh) ?environment parameter => project_id_institute_id_model_id.ksh => gfile

VII. Übergabe an cmor.x durch Aufbau der NAMELISTs? => i. cmor.x kann zunächst ohne Änderung benutzt werdenii. die Skripten für die Experimente und das Postprocessing können ohne Änderung die

verschiedenen Ausbaustufen von ‚‘cdo cmor,...‘ benutzen

Action !

A. Konforme Formatierung: CommandLineEingabe

14 / 11

&CMORCTRL INPUT_FILENAME=${ifile}CHUNK_RANGE = "“ (def=“”)TABLE_NAME = Amon def=NAREALM = "${realm}“ def=atmosREC_NUM = ${RecDay} header!OUT_FLAG = "replace"

(if chunk_range=“”)SHAPE = "${shape}"ANZVARS = 1var =tasunit =„K“Expid-file =aquaControl_r1i1p1.kshProj-file = MPI-M_MPI-ESM-LR.ksh/

A. Konforme Formatierung: filescdo cmor,var,tab[[,realm],shape[,chunk-range]] -cmorf,ffile cmorg,gfile ifile

experiment_id=„aquaControl“realization=1initialization_method=1physics_version=1baseyear=1850forcing=„N/A“parent_experiment_id=„N/A“parent_experiment_rip=„N/A“branch_time=0.0[ comment=„“ history=„“ references=„“]

ffile=aquaControl_r1i1p1.ksh &CMORCONST

INPUT_DIRNAME = “${input_dir}“TABDIR = "${tabs_dir}“ GRIDFILE_DIRNAME = "${grids_dir}“ OUTPUT_DIRNAME = "${arch_dir}“PROJECT_TEXT = "${project_id}“MOD_ID = "${model_id}“INSTITUTE_ID =“${institute_id}“ SOURCE_TEXT = "${source}”CONTACT_TEXT = “${contact}”CALENDAR_TEXT = “${calendar}“PRODUCT =„${product} EXPEID = "${exeriment_id}“ RUN = "${realization}“ INM = "${initialisation_method}“ PHV = "${physics_version}“ FORCING_TEXT = "${forcing}“ HISTORY_TEXT = "${history}" COMMENT_TEXT = "${comment:-""}" REFERENCES_TEXT = "${references}“ INIT_YEAR = ${baseyear} PAR_MOD = "${parent_experiment_id}“ PAR_RIP = "${parent_member_rip}" BRANCH_T = ${branch_time} ZOSCONST = ${zosga},${zossga}/

input_dir=“.”tabs_dir=“.”grids_dir=“.”arch_dir=“.”project_id=CMIP5model_id=MPI-ESM-LRinstitute_id=MPI-Msource=„my model“[email protected]=standardproduct=output

gfile=MPI-M_MPI-ESM-LR.ksh

cdo cmorifile


15 / 11

&CMORVAR INPUT_FILENAME=${ifile}CHUNK_RANGE = "“ (def=“”)TABLE_NAME = Amon (no def)REC_NUM = ${RecDay} header!OUT_FLAG = "replace"

(if chunk_range=“”)SHAPE = "${shape}"ANZVARS = 1var =tasunit =„K“Expid-file =aquaControl_r1i1p1.kshProj-file = MPI-M_MPI-ESM-LR.ksh/

A. Konforme Formatierung: filescdo cmor,var,tab[[,realm],shape[,chunk-range]] -cmorf,ffile -cmorg,gfile ifile

experiment_id=„aquaControl“realization=1initialization_method=1physics_version=1baseyear=1850forcing=„N/A“parent_experiment_id=„N/A“parent_experiment_rip=„N/A“branch_time=0.0[ comment=„“ history=„“ references=„“]

ffile=aquaControl_r1i1p1.ksh

&CMOREXP EXPEID = "${exeriment_id}“ RUN = "${realization}“ INM = "${initialisation_method}“ PHV = "${physics_version}“ FORCING_TEXT = "${forcing}“ HISTORY_TEXT = "${history}" COMMENT_TEXT = "${comment:-""}" REFERENCES_TEXT = "${references}“ INIT_YEAR = ${baseyear} PAR_MOD = "${parent_experiment_id}“ PAR_RIP = "${parent_member_rip}" BRANCH_T = ${branch_time} ZOSCONST = ${zosga},${zossga}/

input_dir=“.”tabs_dir=“.”grids_dir=“.”arch_dir=“.”project_id=CMIP5model_id=MPI-ESM-LRinstitute_id=MPI-Msource=„my model“[email protected]=standardproduct=output

gfile=MPI-M_MPI-ESM-LR.ksh

cdo cmorifile


&CMORINST INPUT_DIRNAME = “${input_dir}“TABDIR = "${tabs_dir}“ GRIDFILE_DIRNAME = "${grids_dir}“ OUTPUT_DIRNAME = "${arch_dir}“PROJECT_TEXT = "${project_id}“MOD_ID = "${model_id}“INSTITUTE_ID =“${institute_id}“ SOURCE_TEXT = "${source}”CONTACT_TEXT = “${contact}”CALENDAR_TEXT = “${calendar}“PRODUCT =„${product} ZOSCONST = ${zosga},${zossga}/

16 / 11

B. Konforme CDOsB. 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.

‚esmrcp85‘ ist das 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 notiert wurde, wird beim Vergleich für eine andere Komponente nicht mehr erwähnt.

9. Juni 15

17 / 11

All realms / grids:1. bnds => nb2 Action! 5. time:axis = "T„ geht verloren Action! 6. global history-Attribut anhängen: Action!

E.g.: “Raw output...with IMDI ...; CMOR rewrote ...“ “Raw output...[with ‘infrastructure‘...]; CMOR rewrote ...; CDO selname,cl ...“

7. tracking_id muss er-/gesetzt werden Action!8. creation_date muss er-/gesetzt werden Action!9. time:units = "days since’ ‘850-1-1 00:00:00" ; versus Action!

time:units = "days since’ ‘850-01-01 00:00:00" ;

9. Juni 15

B. header–Vergleich nach cdo copy

18 / 11

Realm / grid atmos:1. var:cell_measures = “area: areacella“ geht verloren; Action!2. Location von areacella in var:associated_files = "baseURL: http://......“Action!3. var:grid_type = “gaussian“ ; Action!4. Single value dimension treatment by 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 ;

9. Juni 15


geht verloren Action!

19 / 11

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

a. lev:standard_name verlorenb. lev:formula = "p = ap + b*ps" ;c. lev:formula_terms = "ap: ap b: b ps: ps" ;d. lev_bnds:formulae. lev_bnds:formula_terms="ap: ap_bnds b: b_bnds ps: ps" f. lev_bnds:standard_name verloren (sollte nicht vorhanden sein CF conventions)g. lev_bnds:units verloren (“ “ “ “)h. double [ap|b](lev) verloreni. [ap|b]_bnds(lev, x); dimension x statt bndsj. float ps(time, lat, lon) verloren

Mögl. Lösung: CMOR schreibt auch cl:ancillary_variables = “ps ap b ap_bnds b_bnds“ oder über “formula_terms“ regeln; Bemerkung: es sollte darüber nachgedacht werden, ob man die Variablen auf ECHAM-Modellleveln erst mal außen vor lassen kann. Vielleicht gibt es aber hier nur ein Missverständnis.

9. Juni 15

Action ! (schwierig; CDOs könnten die alten Daten nicht mehr lesen)

20 / 11

Realm / grid land:1. float baresoilFrac(time, lat, lon) ;

bareSoilFrac:coordinates = “type“; char type(strlen)² ;

type:long_name = "surface type"type:standard_name = "area_type" ;

2. 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 = "bare_ground" ;

9. Juni 15


geht verloren (s.o.) Action!

geht verloren (s.o.) Action!

21 / 11

Realm / grid seaIce :1. var:cell_measures = “area: areacello“ geht verloren; Location von areacello in

var:associated_files = "baseURL: http://......“(s.o.)Action ! 2. nv4 = 4 ; statt vertices = 4 ; 3. x = 256 statt i = 256 ; 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 Action ! 8. coordinates = „lon lat“ statt „lat lon“ Action !

9. Juni 15

Action ! Action !


22 / 11

Realm / grid ocean :

1. 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" ;

2. 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" ;

9. Juni 15


geht verloren (s.o.) Action !


23 / 11

Realm / grid ocean :

1. float msftmyz(time, basin, lev, lat) ; lat:bounds = "lat_bnds" ; lat:standard_name = "latitude" ;

2. Bem. ‚nbds = 2‘ steht überflüssigerweise in areacello ; Action ! CD&KT

9. Juni 15



24 / 11

Realm / grid ocnBgchem:

1. single value vertical dimension (siehe realm/grid = atmos Punkt 4.):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 ;

9. Juni 15



25 / 11

Realm / grid atmos:1. Vertical coordinate

a. double ap_bnds(lev) verlorenb. double b_bnds(lev) verloren

9. Juni 15

B. header–Vergleich nach cdo selname

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

27 / 11

Installation und Distributionen

...

1 / 11 Organisatorisches 1.Versionsarchiv für Dokumente: z.Z. i.CMIP-CDOs.ppt.

Documents

Transcript of 1 / 11 Organisatorisches 1.Versionsarchiv für Dokumente: z.Z. i.CMIP-CDOs.ppt.