In the CORDEX data request, we have traditionally relied on simple 2D fields for all variables. 3D variables were just split into a set of predefined, requested levels and the level added to the variable name. Some examples: ta850 (air temperature at 850 hPa) or ua50m (zonal wind at 50 meters height above the surface). For CORDEX-CMIP6, soil variables (tsl, mrsol, mrsfl) already broke this basic rule, by including a 3rd space dimension (depth) to code the native soil model levels.
The situation becomes more complicated with the new components, which we are now considering initially in the framework of Med-CORDEX, but which will be needed more extensively very soon. In the ocean, native depth coordinates are typically used (Med-CORDEX/internal-data-request#2). For the aerosol variables (#74) a large set of pressure levels is requested:
200, 250, 300, 350, 400, 450, 500, 550, 600, 650, 700, 750, 800, 850, 900, 925, 950, 975, 1000 hPa
If combined with the spectral bands (350, 440, 550, 870, 1000 nm) and aerosol species (dust, ss, oa, so4, nh4, ...), this leads to a very large set of variables such as ext550no3850. Several problems arise here:
- We'd need a separator between the model level and the variable name, since the current building rules mix the numbers in the species name with the model level
- To go for a single file, we'd need a set of standard level sets, likely different for different variables. This problem led CMIP to a pressure level set nightmare which still persists in CMIP7. This was originally solved in CMIP via variable tables (that we do not have in CORDEX) and currently via branded variables.
An alternative to the latter would be to let the vertical levels be free to chose by each modelling group, so the actual contents of a 3D variable are unpredictable from the data request (note that this is still the case when dealing with native model levels) and the user would need to open the file to actually know what's inside. Note that this still needs some way to declare a variable 3D in space, which is not currently in place (see Med-CORDEX/internal-data-request#2).
Ping @gnikulin
In the CORDEX data request, we have traditionally relied on simple 2D fields for all variables. 3D variables were just split into a set of predefined, requested levels and the level added to the variable name. Some examples:
ta850(air temperature at 850 hPa) orua50m(zonal wind at 50 meters height above the surface). For CORDEX-CMIP6, soil variables (tsl, mrsol, mrsfl) already broke this basic rule, by including a 3rd space dimension (depth) to code the native soil model levels.The situation becomes more complicated with the new components, which we are now considering initially in the framework of Med-CORDEX, but which will be needed more extensively very soon. In the ocean, native depth coordinates are typically used (Med-CORDEX/internal-data-request#2). For the aerosol variables (#74) a large set of pressure levels is requested:
200, 250, 300, 350, 400, 450, 500, 550, 600, 650, 700, 750, 800, 850, 900, 925, 950, 975, 1000 hPa
If combined with the spectral bands (350, 440, 550, 870, 1000 nm) and aerosol species (dust, ss, oa, so4, nh4, ...), this leads to a very large set of variables such as
ext550no3850. Several problems arise here:An alternative to the latter would be to let the vertical levels be free to chose by each modelling group, so the actual contents of a 3D variable are unpredictable from the data request (note that this is still the case when dealing with native model levels) and the user would need to open the file to actually know what's inside. Note that this still needs some way to declare a variable 3D in space, which is not currently in place (see Med-CORDEX/internal-data-request#2).
Ping @gnikulin