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) Problems with using ECMWF IFS operational products to drive WPS/WRF

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.


New member
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/ and /glade/collections/rda/data/ds113.1/ 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
Copen: File =
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

Then I used g2print.exe and I got this:

gribdata/ttest> ./g2print.exe
\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.

Take a look at this post and see if it's helpful:
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!

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.

Okay, so this may be more related to this problem:

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:

and a couple of the input data files

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.



  • namelist.wps
    1.6 KB · Views: 103
  • ungrib.log
    2.3 MB · Views: 85
    100 MB · Views: 71
    100 MB · Views: 61
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:

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:


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!