vocabulary for domain_id

[larsbuntemeyer]

According to our current discussion, we need to fix the vocabulary for the domain_id.

Outdated?

{
    "domain_id":{
        "EUR-11": {
          "domain_id": "EUR-11",
          "domain": "Europe",
          "nominal_resolution": "12.5km"
        },
        "EUR-22": {
          "domain_id": "EUR-22",
          "domain": "Europe",
          "nominal_resolution": "25km"
        },
        "EUR-44": {
          "domain_id": "EUR-44",
          "domain": "Europe",
          "nominal_resolution": "50km"
        }
    }
}

New?

{
    "domain_id":{
        "EUR-12": {
          "domain_id": "EUR-12",
          "domain": "Europe",
          "nominal_resolution": "12.5km"
        },
        "EUR-25": {
          "domain_id": "EUR-25",
          "domain": "Europe",
          "nominal_resolution": "25km"
        },
        "EUR-50": {
          "domain_id": "EUR-50",
          "domain": "Europe",
          "nominal_resolution": "50km"
        }
    }
}

[gnikulin]

yes, I think we can go for resolution in km here (50, 25 and 12) and later see what the CORDEX community say when the FOD of the CORDEX-CMIP6 archiving specs is released for comments.

[sol1105]

Should the unit be included when the resolution is not provided in degrees?
This way there would be no ambiguity what is meant, and it would also be easier to switch to EUR-800m etc. in the (far?) future.

{
    "domain_id":{
        "EUR-6km": {
          "domain_id": "EUR-6km",    # 0.055 degree
          "domain": "Europe",
          "nominal_resolution": "6.25km"   
        },   
        "EUR-12km": {
          "domain_id": "EUR-12km",
          "domain": "Europe",
          "nominal_resolution": "12.5km"
        },
        "EUR-25km": {
          "domain_id": "EUR-25km",
          "domain": "Europe",
          "nominal_resolution": "25km"
        },
        "EUR-50km": {
          "domain_id": "EUR-50km",
          "domain": "Europe",
          "nominal_resolution": "50km"
        }
    }
}

Should the nominal_resolution attribute be calculated as for CMIP6, i.e. in a more discrete manner?

{
    "nominal_resolution" : [
        0.5,
        1.0,
        2.5,
        5.0,
        10.0,
        25.0,
        50.0,
        100.0,
        250.0,
        500.0,
        1000.0,
        2500.0,
        5000.0,
        10000.0],
    "threshold" : [
        0.72,
        1.6,
        3.6,
        7.2,
        16.0,
        36.0,
        72.0,
        160.0,
        360.0,
        720.0,
        1600.0,
        3600.0,
        7200.0]
}

[larsbuntemeyer]

Thanks @sol1105, yes that calcuation of nominal_resolution would be great! Those current numbers in the CV are more or less placeholders. Currently, nominal_resolutions is not a required global attribute #8 .

Furthermore, i think there is no common understanding right now, how to define that domain_id consistently. E.g., for 0.0275 resolutions (~3km), i saw EUR-3 and also EUR-0275 in presentations.

[gnikulin]

How to present different resolutions with different units is an old issue. The current suggestion is to use resolution only in km with some rounding as in the above example. This approach should work fine for the continental-scale CORDEX domains (50, 25, 12 and 6 km) but not with sub-kilometer resolution that can be used in CORDEX FPS for example. It would be good to have a common approach for all resolutions so "km" and "m" suffixes may work fine.

[gnikulin]

I'm not sure that nominal_resolution can be useful in CORDEX. We don't expect RCMs with a wide range of resolutions for one CORDEX domain. RCMs with the Lambert Conformal and Mercator projections define resolution exactly in m, no need to calculate nominal_resolution. nominal_resolution for RCMs with the rotated pole coordinate system should be very close to the recommended resolutions (25 or 12.5km) and the same for all RCMs.

[gnikulin]

although for models with unstructured grids like ICON nominal_resolution may be useful

[larsbuntemeyer]

Encoding both the domain or region and grid info in the domain_id seems indeed challenging (and we probably don't want to preference any grid setup). However, I like the idea of having native grid units in the id, e.g.

• EUR-11 -> EUR-11d (rotated grid, native degrees)
• EUR-11 -> EUR-12km or EUR-12500m (mercator/lambert, native m or km)
• EUR-11i -> EUR-125d (regular EUR, actually has 0.125 degrees resoultion)

higher resolved domains would be no problem, e.g., EUR-500m or EUR-0275d. I think there would be less confusion than, e.g., simply going from EUR-11 to EUR-12. This would also allow to infer the grid mapping from the filename (or as a search facet). Any information about whether the grid is native model output or interpolated could be given through the grid_label...

[gnikulin]

I'm not sure that we need to make simple things more complex. The current -44, -22 and -11 resolution suffixes exactly define resolution for RCMs with the rotated pole coordinate (0.11d) while other RCM whit for example the LCC projection (12.5km) use the same suffixes. It's very easy to find all simulations at about the same resolution for a CORDEX domain looking only for EUR-11 or AFR-22. Instead, a global attribute native_resolution can be introduced. The main idea now is to use only km or m for the resolution suffix.

[larsbuntemeyer]

closed by 9f1cb5c