-
Notifications
You must be signed in to change notification settings - Fork 43
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
GriB file with constant field (all values = 0) throws an error #355
Comments
While I am not a GriB expert, I nevertheless did some further investigations by comparing with the file for the preceding day (attached below). This sheds some light on where the problem might be.
and for the problematic file:
As far as I understand, if zero bits are used to represent the data then section 7 will be empty, in which case the |
We ended up monkey-patching this (and a couple other special cases) by updating
|
@larsbarring and @greenlaw This issue should now be resolved thanks to #362. This has been included in the 0.19.0 release, which is now available on Care to try it out and confirm whether this fixes your problem? If so, feel free to close this issue 👍 |
@bjlittle thanks for taking care of this! Here is my test: $ ipython
Python 3.11.0 | packaged by conda-forge | (main, Jan 14 2023, 12:27:40) [GCC 11.3.0]
Type 'copyright', 'credits' or 'license' for more information
IPython 8.10.0 -- An enhanced Interactive Python. Type '?' for help.
In [1]: import iris
In [2]: print(iris.__version__)
3.8.0.dev52
In [3]: import iris_grib
/home/a001257/mambaforge/envs/scitools/lib/python3.11/site-packages/gribapi/__init__.py:23: UserWarning: ecCodes 2.31.0 or higher is recommended. You are running version 2.29.0
warnings.warn(
In [4]: print(iris_grib.__version__)
0.19.dev0
In [5]: d1 = iris.load_cube("sd_an_1961092306.grb").data
In [6]: print(d1.min(), d1.max())
0.0 0.0040847319178283215
In [7]: d2 = iris.load_cube("sd_an_1961092406.grb").data
In [8]: print(d2.min(), d2.max())
0.0 0.0 That is, the all-zero file is read without problems, as expected. 👍 👍 👍 However, when looking at the PR (#362) I see that if the reference_value = sections[5]["referenceValue"]
decimal_scale_factor = sections[5]["decimalScaleFactor"]
data = np.ones(self.shape) * reference_value / (10**decimal_scale_factor) |
@greenlaw Do you have an example GRIB2 file with a single message that demonstrates this behaviour? I'm happy to add this extension as a patch i.e., 0.19.1 |
@bjlittle @larsbarring Sorry, it was a while ago that I wrote that code, and I can't seem to find a file that demonstrates the non-zero missing |
No problem @greenlaw, thanks for getting back to let me know 🍻 |
I guess that files with all values in a field be exactly the same non-zero value are not that easy to come by. Hence I have hacked the test file included in my first post: import struct
import os
with open("sd_an_1961092406.grb", mode='rb') as file:
fileContent = file.read()
# position in file of referenceValue -- derived using grib_dump -O
refPosition = 16 + 21 + 81 + 34 + 11
# change referenceValue to a "reasonable number",
# I did not bother what it actually meant or how it was packed into grib
ref = struct.pack("f",1.9999)
new = fileContent[0:refPosition] + ref + fileContent[refPosition+4:]
with open("sd_an_1961092406__NEW.grb", mode='wb') as file:
file.write(new)
print("\nCheck that the new value landed where is supposed to (actual value is garbled):")
os.system("grib_dump -O sd_an_1961092406__NEW.grb | grep referenceValue")
print("\n\n\nAnd print how eccodes sees the data:")
os.system("grib_dump sd_an_1961092406__NEW.grb | tail -n 36")
import iris
import iris_grib
print(iris.__version__)
print(iris_grib.__version__)
cube = iris.load_cube("sd_an_1961092406__NEW.grb")
print(f"\n\nCUBE min = {cube.data.min()}, and max = {cube.data.max()}") results in this printout:
|
Thanks very much @larsbarring! Resource permitting, we now have all we need to work on this |
@trexfeathers -- thanks and if you change my code as follows the numbers becomes as one expects: # put a "reasonable number"
ref = struct.pack(">f", 1.999)
bin = struct.pack("h", 0)
new = fileContent[0:refPosition] + ref + bin +fileContent[refPosition+6:] where the grib-dump output now shows 1.999 |
.... and now I happened to bounce into #265 .... |
We have a file where all data is 0. This is encoded as a bitmap in section 6, while section 7 is empty. When reading this into iris we get the error as below. Eccodes is able to read this without problems so it appears that there is no problem with the file. It seems like this error is similar to what was reported in #131. The file is available at the end, although with the ending ".txt" appended to allow it to be uploaded.
sd_an_1961092406.grb.txt
The text was updated successfully, but these errors were encountered: