read grib2 parameter on surface level using grid_stat

[carlos9917]

Hello
I am trying to use the two files attached with grid_stat, but I am having trouble telling the tool how to read the parameter. This is an output from the Harmonie model in grib2 format.

The forecast field in the config file is defined like this
file_type = GRIB2;
field = [
{
name = "fscov"; //"FSNOWC";
GRIB_lvl_typ = 0; // "surface";
level = ["Z0"];
//GRIB_lvl_val1 = 0.0;
GRIB2_param = [ 260289 ];
GRIB2_cntr = 88;
GRIB2_parm_cat = 1;
GIRB_disc = "Meteorological products";}
];

Since grid_stat was unable to find the variable I defined a table file like this:
GRIB2
0 0 0 255 88 0 1 260289 "fscov" "Snow cover fraction" "%"
and then set MET_GRIB_TABLES to point to this file.

I tried both with FSNOWC (which is the variable that wgrib2 prints)
1:0:d=2015050100:FSNOWC:surface:anl:
snow_files.tar.gz
and fscov, which is the variable I see when I use grib_ls

I get the error

read_data_plane() -> fscov/Z0 not found in file

I tried using L0 and Z0, but not sure how to specify this type of variable/level
and I did not find any example in the documentation.

Thanks for any help.

Best regards,

Carlos

[JohnHalleyGotway]

Carlos, thanks for laying out the issue you're seeing and sending along sample data to illustrate. I am able to replicate the problem you describe by running the plot_data_plane tool for MET version 11.1.0:

plot_data_plane snow_cover_forecast_20150501.grib2 fcst.ps 'name="FSNOWC"; level="Z0";'
...
ERROR  : VarInfoGrib2::set_dict() -> unrecognized GRIB2 field abbreviation 'FSNOWC'

And comparing that to the output from wgrib2 version 3.1.1, it happily identifies this data as being "FSNOWC":

musial6:2465 johnhg$ wgrib2 snow_cover_forecast_20150501.grib2 
1:0:d=2015050100:FSNOWC:surface:anl:

And I certainly see the "FSNOWC" variable documented in this GRIB2 table.

Using the MET_GRIB2_TABLES workaround for now, I created a file named grib2_fsnowc.txt that contains:

GRIB2
0 1 0 255 0 0 1 121  "FSNOWC"  "Fraction of Snow Cover"  "proportion"

And I set MET_GRIB_TABLES to the full path to that grib2_fsnowc.txt file. Re-testing, I see that plot_data_plane is now happy:

musial6:2465 johnhg$ echo $MET_GRIB_TABLES
/Volumes/d1/projects/METplus_Discussions/2465/grib2_fsnowc.txt

musial6:2465 johnhg$ plot_data_plane snow_cover_forecast_20150501.grib2 fcst.ps 'name="FSNOWC"; level="Z0";'
DEBUG 1: Reading user-defined grib2 MET_GRIB_TABLES file: /Volumes/d1/projects/METplus_Discussions/2465/grib2_fsnowc.txt
DEBUG 1: Start plot_data_plane by johnhg(6088) at 2024-01-16 18:27:16Z  cmd: /Volumes/d1/projects/MET/MET_development/MET-main_v11.1/bin/plot_data_plane snow_cover_forecast_20150501.grib2 fcst.ps name="FSNOWC"; level="Z0"; 
DEBUG 1: Opening data file: snow_cover_forecast_20150501.grib2
DEBUG 1: Creating postscript file: fcst.ps
DEBUG 1: Finish plot_data_plane by johnhg(6088) at 2024-01-16 18:27:17Z

Some conclusions from this:

1. I always recommend using plot_data_plane to test out the reading of novel datasets.
2. For GRIB2 data, double-checking against the output from wgrib2 is a great idea.
3. Finding the target variable name in the GRIB2 docs is also useful.
4. The GRIB (1 and 2) tables are stored in MET in the table_files directory. I just found a variable name that's part of the same table (MASSDH in this case) and then just copied the full line from grib2_all.txt into a separate file... and then edited the line to change the variable number 99 to 121 and then update the name, long name, and units columns.
5. We do already have an issue to update the MET GRIB2 tables for version 12.0.0. But I added this comment on that issue to double-check that table 4.2-0-1 gets updated.

Thanks for pointing out this short-coming in MET, and for reading through the docs to figure out the MET_GRIB_TABLES workaround. Please let me know if you have any questions or issues with the suggestions I provided above.

[carlos9917]

Thank you so much for your help! It worked with that grib2 table definition.
I will test with plot_data_plane next time.
Best wishes
Carlos

[JohnHalleyGotway]

Great, glad that did the trick. Thanks for following up to let us know. I'll lock this discussion thread to prevent future posts. But if more issues or questions arise, please feel free to open a new discussion.