I'm making a GRIB2 file of a locally defined parameter (say, WNISI) using wgrib2.
I followed the instruction below https://www.cpc.ncep.noaa.gov/products/wesley/wgrib2/user_grib2tables.html
and make a local table (my_grib2table)
0:23:0:255:253:7:1:208:WNISI:WNI Storm Index:??
then
export GRIB2TABLE=./my_grib2table
and then got
$ wgrib2 out.grib -set_var WNISI -grib out.grb
*** FATAL ERROR: set_var: could not find WNISI ***
When I changed the "parameter" field (in above example 208) to 190 or 191, it worked
$ wgrib2 out.grib -set_var WNISI -grib out.grb
1:0:d=2022071400:WNISI:0 mb:6 hour fcst:
2:179:d=2022071400:WNISI:0 mb:12 hour fcst:
However, thus obtained GRIB data provides the parameter to be 191 when read with pygrib.
$ python
Python 3.10.5 | packaged by conda-forge | (main, Jun 14 2022, 07:06:46) [GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygrib
>>> grbs = pygrib.open("out.grb")
>>> for grb in grbs:
... print(grb.parameterName)
...
191
191
How should I resolve this conflict?
Any suggestion and comments are appreciated. Thanks!
"0:23:0:255:253:7:1:208:WNISI:WNI Storm Index:??"
ref: https://www.cpc.ncep.noaa.gov/products/wesley/wgrib2/user_grib2tables.html
Since the discipline, parameter category or parameter > 191, the table entry is a "locally defined" variable. For the table entry to apply, the center has to be 253 (section 1, octets 6-7) and the local table has to be 7 (section 1, octet 11).
"0:23:0:255:253:7:1:191:WNISI:WNI Storm Index:??"
The only difference is the parameter is 191.
The discipline, parameter category and parameter <= 191, so this is a WMO defined field. Therefore it is good for all files.
The solution is to use the make the center and local table match the contents of your files. Pygrib is based on ECcodes which uses different tables from wgrib2. To get Pygrib to recognize your variable, you will have to alter the ECcode tables.