iris-grib

iris-grib copied to clipboard

When printing the contents summary for Iris cubes containing GRIB-2 data, many of the parameters in the MDDA catalogue spreadsheet seem to be mapped to 'unknown/(unknown)', rather than meaningful parameter names and units. Would it be possible to implement sensible mappings for all of the MDDA catalogue entries for the Global Deterministic Model? See link below.

https://metoffice.sharepoint.com/sites/technologyservicehubservice/SitePages/Global-Deterministic-Model-%E2%80%93-Coverage-Service.aspx

@SciTools/peloton: We believe this just needs some additions to: _grib_cf_map.py. Thanks for bringing this to our attention!

@mgange659 we would welcome a Pull Request, if you're up for it, but understand if not.

I will start preparing a Pull Request with new table entries for GRIB2_TO_CF. Some of the MDDA parameters have officially agreed local codes. is there a need a new GRIB2_LOCAL_TO_CF lookup table?

I will start preparing a Pull Request with new table entries for GRIB2_TO_CF. Some of the MDDA parameters have officially agreed local codes. is there a need a new GRIB2_LOCAL_TO_CF lookup table?

Thanks! I should have also said: it doesn't look like the mapping extends to CF standard names. If that's the case then the name to use is the long name.

https://github.com/SciTools/iris-grib/blob/e10442b93d351752d36ac94ee7f110ef2b55c27d/iris_grib/_grib_cf_map.py#L15

When you say "local codes", are you referring to something like STASH, or LBFC? If so: #297 would be an appropriate model - this had a partner PR in Iris itself.

I was referring to GRIB-2 Local Codes. These often have 'Number' settings in the range 192-254.

I was referring to GRIB-2 Local Codes. These often have 'Number' settings in the range 192-254.

Ah OK, thanks. iris-grib would not be the place to record such mappings, since it would not use this information anywhere. So that's slightly less work!

The CF_TO_GRIB2 Table is missing these Service Hub coverage service parameters: None, 'surface_diffusive_downwelling_shortwave_flux_in_air', 'W m-2' (2, 0, 4, 14) 'altitude', None, 'm' (2, 0, 3, 33) 'atmosphere_boundary_layer_thickness', None, 'm' (2, 0, 3, 18) 'canopy_water_amount', None, 'kg m-2' (2, 2, 0, 13) 'cloud_base_altitude_assuming_only_consider_cloud_area_fraction_greater_than_2p5_oktas', None, 'm' (2, 0, 3, 33) 'convective_cloud_area_fraction', None, '%' (2, 0, 6, 2) 'convective_rainfall_rate', None, 'm s-1' (2, 0, 1, 76) 'fog_area_fraction', None, '1' (2, 0, 6, 32) 'lwe_convective_snowfall_rate', None, 'm s-1' (2, 0, 1, 55) 'lwe_precipitation_rate', None, 'm s-1' ((2, 0, 1, 52) 'lwe_snowfall_rate', None, 'm s-1' (2, 0, 1, 56) 'mass_concentration_of_condensed_water_in_soil', None, 'kg m-3' (2, 2, 3, 19) 'soil_temperature', None, 'K' (2, 2, 3, 18) 'surface_direct_downwelling_shortwave_flux_in_air', None, 'W m-2' (2, 0, 4, 13) 'toa_outgoing_longwave_flux', None, 'W m-2' (2, 0, 5, 4) 'upward_air_velocity', None, 'm s-1' (2, 0, 2, 9) 'visibility_in_air', None, 'm' (2, 0, 19, 0) ... and the following 4 parameters currently have non-conformant CF names in the table source code cloud_area_fraction', None, '1' (2, 0, 6, 1) 'land_binary_mask', None, '1' (2, 2, 0, 0) 'lwe_thickness_of_surface_snow_amount' (2, 0, 1, 60) 'rainfall_rate', None, 'm s-1' (2, 0, 1, 77)

@SciTools/peloton just noticing that this has not progressed (!) Unfortunately there isn't much dedicated resource to work on this now, so nothing has happened from our end.
Are you still interested, and do you have time to make an actual PR for this @mgange659 ?