(RESOLVED) Problems with using ECMWF IFS operational products to drive WPS/WRF

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

Hi,
Take a look at this post and see if it's helpful:
https://forum.mmm.ucar.edu/phpBB3/viewtopic.php?f=32&t=433&p=1279&hilit=ec_rec_len#p1279

Thank you so much for the suggestion! The magical line, ec_rec_len = 26214508 in namelist.wps under &ungrib, indeed worked for me with version 4.1.2 though not with version 3.9.1 (for version 3.9.1, it complained about "invalid reference to variable in NAMELIST input" for that line). If there is a workaround for version 3.9.1 that would be great but otherwise I can just use version 4.1.2.

Thank you again!

Yongxin

Yongxin,
I am glad to hear that you were able to get it to work with V4.1.2. We don't have a quick solution for V3.9.1 at this time, so to save you time, it's probably easiest to just use WPSV4.1.2. If you'd still like to use WRFV3.9.1, you still can. It's not mandatory to use the same version of WPS and WRF. The output from WPSV4.1.2 should work without a problem in WRFV3.9.1.

Sorry to bother you again but somehow my ungrib job did not complete successfully. All of the PFILEs were generated but then the job was stopped complaining "forrtl: severe (174): SIGSEGV, segmentation fault occurred" and the error message was:

End-of-record mark (7777) not found 0
Sec0(1) = 26214508 0

I tested with running ungrib for different time periods but the same errors occurred. My grid size is large (991 x 601) but I successfully ran this grid size before using the GFS data. I am just wondering if you have any suggestions.

Thanks!
Yongxin

Okay, so this may be more related to this problem:
https://forum.mmm.ucar.edu/phpBB3/viewtopic.php?f=34&t=278&p=782&hilit=ds113.1#p782

See if any of that is helpful to you. It looks like there was a work-around for the particular issue they were seeing, but it may not help your case. If not, will you please attach the following:

namelist.wps
ungrib.log
and a couple of the input data files

Thanks!

Thank you so much for your willingness to help! Attached please find "namelist.wps", "ungrib.log", and two input grib data surface files (I had to change the names from .grb to .txt since otherwise the files won't be attached here. The pressure level files are too large to be attached here. They are located under /glade/p/ral/nsap/zhangyx/SaudiGAMEP/WPS.ECMWF/gribdata/ if you can access Cheyenne). I used debug_level = 500.

Please let me know if you have any suggestions. Surprisingly my WRF runs with using the ERA5 (i.e., the latest ERA5 reanalysis data set ds633.0, grib files downloaded from NCAR's HPSS) for the entire month of January 2019 did not have any problems although the simulated temperature has pronounced cold biases when compared to the observations and I am still investigating the source of the cold biases.

Thanks,
Yongxin

Hi,
I just recalled that I worked with someone else last month who was using this type of input file. There are specific surface files that you need for every time period. They are:

ec.oper.an.sfc.XXX_XXX_z.regn1280sc.YYYYMMDD.grb
ec.oper.an.sfc.XXX_XXX_sp.regn1280sc.YYYYMMDD.grb
ec.oper.an.sfc.XXX_XXX_stl1.regn1280sc.YYYYMMDD.grb
ec.oper.an.sfc.XXX_XXX_stl2.regn1280sc.YYYYMMDD.grb
ec.oper.an.sfc.XXX_XXX_stl3.regn1280sc.YYYYMMDD.grb
ec.oper.an.sfc.XXX_XXX_stl4.regn1280sc.YYYYMMDD.grb
ec.oper.an.sfc.XXX_XXX_msl.regn1280sc.YYYYMMDD.grb
ec.oper.an.sfc.XXX_XXX_10u.regn1280sc.YYYYMMDD.grb
ec.oper.an.sfc.XXX_XXX_10v.regn1280sc.YYYYMMDD.grb
ec.oper.an.sfc.XXX_XXX_2t.regn1280sc.YYYYMMDD.grb
ec.oper.an.sfc.XXX_XXX_skt.regn1280sc.YYYYMMDD.grb
ec.oper.an.sfc.XXX_XXX_swl1.regn1280sc.YYYYMMDD.grb
ec.oper.an.sfc.XXX_XXX_swl2.regn1280sc.YYYYMMDD.grb
ec.oper.an.sfc.XXX_XXX_swl3.regn1280sc.YYYYMMDD.grb
ec.oper.an.sfc.XXX_XXX_swl4.regn1280sc.YYYYMMDD.grb

and some of the others actually cause problems (I believe the *_lsm* file is one of them). Try to get all of those files for a particular date and run it and see if that makes a difference.

As a side note, it's best to turn debug_level off (set to 0). We took this out of the default namelists recently because we find that it is not helpful and just adds a lot of junk to the log files, making them difficult to read through.

Thank you so much for these suggestions. I checked every one of the files and indeed the following files are problematic:

1. ec.oper.an.sfc.???_???_ci.regn1280sc.????????.grb
2. ec.oper.an.sfc.???_???_sstk.regn1280sc.????????.grb
3. ec.oper.an.sfc.???_???_sd.regn1280sc.????????.grb
4. ec.oper.an.sfc.???_???_lsm.regn1280sc.????????.grb

I removed those problematic files and submitted the WPS job though the job has been in hold for quite some time already. I will let you know if the run runs successfully.

Thanks again!

Yongxin

The run was indeed successfully finished. Thank you so much for solving this problem!

Yongxin

That's great! Thanks for letting me know!