You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I understand right, what this represents is a cloud fractional coverage, for all the atmosphere between ground level and the 800 hPa level.
So I think this is a problem from Iris' point of view, because Iris data-model is all aligned with netcdf-CF rules, and CF just does not provide a means of describing what is intended here.
In CF terms this information "should" translate into a one-point vertical coordinate with a point value and bounds. However, CF expects upper and lower bound values to have common units and meaning, whereas here the correct upper bound is a pressure value, but the lower bound (ground level) can not be given as a (fixed) pressure.
So the key problem is how should this data appear in Iris ?
I can think of a few possibilities :
use a nominal fixed pressure value for the lower surface, e.g. 1000 hPa (standard) or 100e6 (improbably large); .. or ..
.. define a new (Iris-specific) nonstandard phenomenon identity meaning 'cloud below given level', and load with a pressure point-value only (no bounds or equal-value bounds)
and (optionally) add case-specific metadata to track metadata adjustments
Such solutions can be potentially be implemented by extending iris-grib. However, a user-code-specific solution is obviously more flexible as you don't need to resolve the core problem in a generally acceptable way.
You can modify low-level data before translating, with a callback function or via iris_grib.load_pairs_from_fields (see docs).
It really depends on what you then need to do with the data.
If you just needs a means of loading (working around the load error), I think I would just set the type and value of the second fixed surface to that of the first in this case, using a load callback.
That will yield a cube that apparently has a specific cloud fraction value between levels of 800 to 800 hPa, which is nonsensical but at least no original information is lost.
Just wanted to note that I just ran into the exact same problem. For me, it would be enough to change the second fixed surface to look like the first, as you suggested. How would such a callback look like?
Hi, I tried to load a grib2 containing 'Low Cloud Cover (800 hPa - Soil)' from opendata.dwd.de.
This raises a
TranslationError: Product definition section 4 has different types of first and second fixed surface.
I don't see why this should be a problem, can anyone clear things up? Thanks!
grib_dump shows
The text was updated successfully, but these errors were encountered: