Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different types of first and second fixed surface: Why error? #99

Open
lkugler opened this issue May 6, 2018 · 2 comments
Open

Different types of first and second fixed surface: Why error? #99

lkugler opened this issue May 6, 2018 · 2 comments

Comments

@lkugler
Copy link

lkugler commented May 6, 2018

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

#-Unknown code table entry ()
typeOfFirstFixedSurface = 100;
#-READ ONLY- unitsOfFirstFixedSurface = 100;
#-READ ONLY- nameOfFirstFixedSurface = 100;
scaleFactorOfFirstFixedSurface = 0;
scaledValueOfFirstFixedSurface = 80000;
#-Unknown code table entry ()
typeOfSecondFixedSurface = 1;
#-READ ONLY- unitsOfSecondFixedSurface = 1;
#-READ ONLY- nameOfSecondFixedSurface = 1;
scaleFactorOfSecondFixedSurface = 0;
scaledValueOfSecondFixedSurface = 0;
topLevel = 800;
bottomLevel = 0;
shortNameECMF = ccl;
shortName = CLCL;
nameECMF = Cloud cover;
name = Cloud Cover (800 hPa - Soil);

@pp-mo
Copy link
Member

pp-mo commented May 14, 2018

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.

What kind of solution do you need ?

@marfel
Copy link

marfel commented Aug 16, 2020

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

4 participants