I got error while mixing normal wrfout files and restart wrfout files. I checked the restart wrfout file(2017-04-19) for that day and it is seems to be normal.
Here’s the error message:
*** SUBROUTINE: RDWRFEM
*** LOOKING FOR INPUT MET AT TIME 2017-04-19-00:00:00.0000
*** INPUT FILE NUMBER 4 IS BLANK
*** ERROR ABORT in subroutine RDWRFEM
ABNORMAL TERMINATION IN RDWRFEM
Date and time 0:00:00 April 19, 2017 (2017109:000000)
If you are using wrfout files from the same run, there should not be a problem. Please check your script to ensure that the file that should contain that output time is listed correctly (without a typo in the special characters in the name).
If the file is correct, please check the first wrfout file and the first restart file (assuming this time is at the bridge between the output files) to ensure that this time was actually included in the output. You can use “ncdump -v Times wrfout” to get a listing of the time periods that are included in each of the wrfout files. It is possible that you accidently omitted this time by using a space-saving option that can be enabled in the WRF namelist.input.
If you confirm that you have the correct file name in your script and the required time (00 UTC on 17 Apr 2019) in your output, then write back and I’ll ask for more information (including your script, too).
I recheck the wrfout files and find that the Times in normal wrfout is 00:00:00-23:00:00, but the restart wrfout is 01:00:00-00:00:00. So the missing hour of 2022-04-19_00:00:00 caused this problem.
I still need to find out why the restart wrfout Times start from 01:00:00 while I only change the start_day and run_days in wrf namelist.input.
Check your WRF namelist.input for the settings for “write_hist_at_0h_rst”, “frames_per_outfile”, and “time_step”. If your time_step is set so that you do not evenly have the number of seconds to land at 00 UTC, then that is one way that you may have missed the output at 00 UTC. I doubt that time_step is causing your problem (given your delta-x of 3 km and most typical permutations of time steps for 3-km domains are factors of 1440 seconds per day). My guess is it’s a combination of the first two settings, where you probably have 24 frames per output file, where you would have created a 2nd output file that only contains the missing time, but you didn’t save it. Then the space-saver option was enabled to not re-create the 00 UTC time period at the top of the first restart run.