Content
Both outside and within this project, multiple programs process 10 active variables and 1 external one. These variables are given on 2-dimensional, seldom 3-dimensional, fields. These programs follow different naming schemes. For the demo benchmark test case, everything is more tightly knit and hopefully no explanation is needed.
In the other case, you might want to consider these 2 tables. Since this wiki unfortunately does not support tables, you will have to confront the technical documentation:
Tables 1,2: document:“Naming schemes”
This project uses 10 naming schemes who, theoretically, could name each variable independently. In order to communicate, many programs have to translate from one naming scheme to another in addition to their core operations.
The table provides one column for each naming scheme. A naming scheme belongs to a program, and though it could be said that each translating program has 2 naming schemes, the displayed one here is always the one this program writes as output, the one it translates to. Some programs derive one variable from many variables. The source variables are grouped as sections with the target variable on top. What source variable to call the target is a subjective choice and you are welcome to disagree. Ideally, no code reflects this choice, but most likely it is far from ideal in this sense. After a derivation, some variables are no longer needed. Therefore, a program which comes late in the production chain may not have a name for some variables, but instead ‘[none]’. Blank spaces mean that the information is missing.
sva_DWD_forcing.ncl
As the entire project is aimed at producing [[What the Community Land Model requires|CLM input]], the CLM naming conventions are non-negotiable. It is inferred from the header of source:sandbox/clm/sva_DWD_forcing.ncl . Furthermore, the project processes [[COSMO]] data to get there. This means that, while there are many COSMO variables to choose from, their naming scheme is also final. Looking at what we need first, it makes sense to put sva_DWD_forcing.ncl in the first column (after commentary).
Coupled programs
The naming schemes are used in concert during the coupled run of model1, OASIS3 and model2.
Model2
The NCL script reads data which model2 writes. The naming scheme of model2 is easy to change and sva_DWD_forcing.ncl can read any kind of naming scheme. This wiggle room is eliminated by the choice - not necessity - to conform to COSMO’s naming scheme. It reads variables over the coupler, OASIS3, so reading conforms to namcouple‘s ’receiver#’ naming scheme.
In one respect, model2 takes its place a few steps ahead in the production process: It reads the fine topography and passes it along to OASIS3. In this case, it has to conform with namcouple in the same way model1 usually does. The field is then not passed along to other programs.
Src_downscal2
source:oasis3/lib/downscal/src/src_downscal2.F90
This particular procedure does not read anything. From the downscaling perspective, it is the heart of the project, but from a translation perspective, it just has to conform to namcouple’s prose naming scheme, which organizes its reading and writing. It gets its own column just to describe how well it is conforming in the appropriate table.
namcouple
This namelist reads what model1 passes along, named with alphanumeric sender numbers, sender#. It gives the received variables new names according to
- receiver#, to be received by model2, and
- prose, to be received by src_downscal2.
Both naming schemes are arbitrary since src_downscal2 and model2 can be programmed to read any names, but namcouple
conforms to an at times elaborate naming scheme imagined just for this purpose.
Model1
Model1 reads COSMO data, and conforms with COSMO’s two naming schemes as a result. Principally, it packs the data into chunks to be read by the coupler, OASIS3. Naming the chunks adheres to the same scheme which dictates namcouple’s names. In addition, it produces a debugging output. Its naming scheme is completely arbitrary because no other program needs to read it. Hopefully, humans can make sense of the names easily.
COSMO
When accessing layered data in files, COSMO dictates ecCodes Grib keys[12] to model1, else names are not needed. The files are ordered in directories which include the names found in Baldauf et al. (2011). Blue font signifies active data, brown font external data.
Grib keys
Each two-dimensional field in a Grib file can be accessed by a combination of keys (Baldauf et al. 2011). For COSMO-DE outputs, they are designated according to recommendations of the World Meteorological Organization (WMO), the custodian of the Grib format. The principle key is ee, the element’s number (cf. table 3), accompanied by tab, the table which contains it. tab may be 2, for the official WMO table, or, where this does not suffice, one of 201, 202, 203. The key ‘lvtyp’ decides whether the variable is given on the main, Arakawa-A layer (then 110), on their boundaries (109), on isohypses above ground (105), or on just the surface (1).
Table: 3 he variables this project plans to retrieve from COSMO-DE output (in Unicode order) along with their ee, lvtyp and tab.
name German name ee lvtyp tab
ALB_RAD Albedo des Bodens im Kurzwelligen 84 1 2
ASOB_S Kurzw. Strahlungsbilanz an der Oberflaeche 111 1 2
ATHB_S Langw. Strahlungsbilanz an der Oberflaeche 112 1 2
HHL Geometrische Höhe der Schichtgrenzen über NN 8 109 2
PS Unreduzierter Bodendruck 1 1 2
T Temperatur 11 110 2
TD_2M 2m-Taupunkt 17 105 2
TOT_PREC Gesamtniederschlag 61 1 2
T_G Temperatur der Unterlage 11 1 2
U_10M Zonaler Wind 33 105 2
V_10M Meridionaler Wind 34 105 2
The indices ‘ee’, ‘lvtyp’ and ‘tab’ will be employed only for validation in MATLAB. This adds another naming scheme to the lot.
Footnotes
fn1^. to be exact, the ecCodes namespace ‘ls’