Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

(RESOLVED) ungrib treats grib2 data as grib1

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

chenhua

New member
I download WPS4.2 and compiled WPS using option 17 "Linux x86_64, Intel compiler (serial)". I use 2019 grib2 GFS data. The corresponding Vtable I used is Vtable.GFS provided in ungrib/Variable_Tables. When I run ungrib, I got the error message (see below the asterisk line). It seems like ungrib.exe identifies my grib2 files as grib1 files. I used g2print.exe to check the files and everything looks fine.
******************************************************************
*** stopping in gribcode ***\n
\tI was expecting a Grib1 file, but this is a Grib2 file.
\tIt is possible this is because your GRIBFILE.XXX files
\tare not all of the same type.
\tWPS can handle both file types, but a separate ungrib
\tjob must be run for each Grib type.\n
gribsize in gribcode
 
Where did you download GFS 2019 data? I would suggest you get data from NCAR CISL:
https://rda.ucar.edu/datasets/ds084.1/

These archived datasets are open to public. We can successfully ungrib these data using WPS.

Please try and let me know if you have any problem.
 
Thanks for your help. I use 0.25deg GFS data and run the model on jet (GFS data are also available on NOAA's jet). I removed the line "ec_rec_len = 26214508," from the namelist.wps and ungrib can identify the grib2 file. But after the first pass it run into segmentation fault. I switched to another computer, all three steps of WPS finished successfully.
 
Thanks for letting me know. Only one issue I would like to raise, the option ec_rec_len is specified for high-resolution ECMWF data. It shouldn't be set for GFS data.
 
Top