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

Ungrib error "killed"


New member
Hi, I'm new to WRF and I tried running ungrib, but it gave me an error "killed". This is what the terminal shows:

*** Starting program ungrib.exe ***
Start_date = 2020-05-03_13:00:00 , End_date = 2020-05-04_23:00:00
output format is WPS
Path to intermediate files is ./

This is what ungrib.log shows:
2022-09-01 21:58:08.567 --- *** Starting program ungrib.exe ***
2022-09-01 21:58:08.574 --- Start_date = 2020-05-03_13:00:00 , End_date = 2020-05-04_23:00:00
2022-09-01 21:58:08.576 --- &UNGRIB
2022-09-01 21:58:08.577 --- out_format = WPS
2022-09-01 21:58:08.578 --- ordered_by_date = TRUE
2022-09-01 21:58:08.579 --- prefix = FILE
2022-09-01 21:58:08.579 --- /
2022-09-01 21:58:08.580 --- output format is WPS
2022-09-01 21:58:08.581 --- INFORM: Interval value: 3600 seconds or 1.000000 hours
2022-09-01 21:58:08.582 --- Path to intermediate files is ./
2022-09-01 21:58:08.608 --- INFORM: Linked in png and jpeg libraries for Grib Edition 2
2022-09-01 21:58:08.609 --- INFORM: Reading Grib Edition 2
1) Can you tell me what command you are using to run ungrib?
2) Please issue the following
ls -ls GRIBFILE* >& log.gribfile
and please attach log.gribfile
3) Please also attach your namelist.wps file and ungrib.log

Can you try adding the prefix ".txt" to the end and see if that allows you to attach them?
Okay, thanks! I also extended the end date to 00z a few days ago.


  • log.gribfile.txt
    1.5 KB · Views: 2
  • namelist.wps.txt
    760 bytes · Views: 3
Thanks for sending those. Unfortunately the ungrib log doesn't really have any error message. It just prints that it's reading the GRIB2 data, and then it stops. I know this sounds silly, but can you try to recompile WPS in a different directory and run this again there to see if it works? If it's still not working, will you send me a couple time periods of your input data so I can try a test? If the files are too large, see the home page of this forum for information on sharing large files. Thanks!
WPS didn't compile right, and I don't see anything that could've gone wrong


  • log.compile.txt
    127.3 KB · Views: 4
The error message says:

   12 | ../../ungrib/src/module_stringutil.F
      | 1
Error: Invalid character in name at (1)

which I don't believe should be happening if the code has not been modified at all. If you didn't do this already, will you obtain the WPS code from the GitHub repository so that we know it's pristine and try to compile that one?

To clarify, when I said in the previous post to compile in a different directory, I didn't mean to issue the compile command from a different directory that where the code is you're trying to compile - just that you should leave your original compile alone, obtain the WRF source code again, and compile it again in a new directory. I'm only saying that because the error message is indicating that it's looking for something two directories up, so I wanted to make sure that's not what you were doing.
You don't need to recompile WRF. Just create a new directory and call it something like "WPS_NEW." Go into that directory, download or clone (from GitHub) the latest version of WPS (V4.4) and then set
export WRF_DIR=<path-to-your-wrf-directory>
The above is for a bash environment. If using csh/tcsh, use
setenv WRF_DIR <path-to-your-wrf-directory>
and then just recompile WPS.
Do you mean you got the original ungrib error, or the same compile error as above?
  • If it's the ungrib error, please send a couple of your data input files, along with the Vtable you're using, so I can try to repeat the issue. If the input files are too large to attach, see the home page of this forum for instructions on sharing large files.
  • If it's the compile error, please send the full compile log, along with the configure.wps file.
I'm talking about the compile error.


  • log.compile (2).txt
    127.9 KB · Views: 1
  • configure.wps.txt
    3.4 KB · Views: 2
I apologize for the delay in response. I wanted to seek the opinion of one of our software engineers. They think this could be an issue with symbolic links. Perhaps you're working on a filesystem that doesn't support symbolic links, or there was a problem preserving symbolic links when obtaining the source code? In the latter case, it may depend on whether you downloaded a tar file or cloned the repository. I would suggest discussing the issue with a systems administrator at your institution to see if they have any thoughts or suggestions, and let us know if you figure anything out.