I've been trying to using the ECMWF IFS high-resolution operational products to drive WPS/WRF but somehow WPS won't be able to read the data files. I am using the data files located under /glade/collections/rda/data/ds113.1/ec.oper.an.sfc/ and /glade/collections/rda/data/ds113.1/ec.oper.an.pl/ on Cheyenne. The data files are supposed to be GRIB1 files but when I used g1print.exe this is what I got:
gribdata/ttest> ./g1print.exe ec.oper.an.sfc.128_236_stl4.regn1280sc.20190317.grb
Copen: File = ec.oper.an.sfc.128_236_stl4.regn1280sc.20190317.grb
Fortran Unit = 0
UNIX File descriptor: 3
----------------------------------------------------
rec GRIB GRIB Lvl Lvl Lvl Time Fcst
Num Code name Code one two hour
----------------------------------------------------
End-of-record mark (7777) not found**********
Sec0(1) = 8607063 0
1 236 STL4 112 100 255 2019-03-17_00:00 + 00
*** stopping in findgrib in gribcode ***\n
\tI could not find the GRIB string in the input file
\tafter testing the first 100,000 bytes.
\tThe file may be corrupt or it is not a GRIB file.
\tPerhaps a gzipped GRIB file or netcdf?\n
findgrib
Then I used g2print.exe and I got this:
gribdata/ttest> ./g2print.exe ec.oper.an.sfc.128_236_stl4.regn1280sc.20190317.grb
\n\tThere is a problem with the input file.
\tPerhaps it is not a Grib2 file?\n
Grib2 file or date problem, stopping in edition_num.
I am just wondering if any of you have any suggestions as how to solve this problem.
Thanks,
Yongxin
gribdata/ttest> ./g1print.exe ec.oper.an.sfc.128_236_stl4.regn1280sc.20190317.grb
Copen: File = ec.oper.an.sfc.128_236_stl4.regn1280sc.20190317.grb
Fortran Unit = 0
UNIX File descriptor: 3
----------------------------------------------------
rec GRIB GRIB Lvl Lvl Lvl Time Fcst
Num Code name Code one two hour
----------------------------------------------------
End-of-record mark (7777) not found**********
Sec0(1) = 8607063 0
1 236 STL4 112 100 255 2019-03-17_00:00 + 00
*** stopping in findgrib in gribcode ***\n
\tI could not find the GRIB string in the input file
\tafter testing the first 100,000 bytes.
\tThe file may be corrupt or it is not a GRIB file.
\tPerhaps a gzipped GRIB file or netcdf?\n
findgrib
Then I used g2print.exe and I got this:
gribdata/ttest> ./g2print.exe ec.oper.an.sfc.128_236_stl4.regn1280sc.20190317.grb
\n\tThere is a problem with the input file.
\tPerhaps it is not a Grib2 file?\n
Grib2 file or date problem, stopping in edition_num.
I am just wondering if any of you have any suggestions as how to solve this problem.
Thanks,
Yongxin