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

WRF runs out of boundary conditions, but at end of simulation

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.

matthewblittle

New member
Problem:
I set WRF to run between 2009-03-01 00:00:00 and 2009-03-02 00:00:00, however WRF starts outputting error messages at 2009-03-02 00:00:00, looking for more data to ingest. I expected the model to stop ingesting data on the final time step and end successfully, but that does not seem to always be the case. The error message that keeps repeating (as can be seen in rsl.out and rsl.error files) is:

2 input_wrf: wrf_get_next_time current_date: 2009-03-02_00:00:00 Status = -4 d01 2009-03-02_00:00:00 ---- ERROR: Ran out of valid boundary conditions in file wrfbdy_d01 THIS TIME 2009-03-01_18:00:00, NEXT TIME 2009-03-02_00:00:00
I don’t understand why this happens some of the time since I thought I set the simulation to end at 2009-03-02_00:00:00. This error happens more often when I run the model for a day, as in this case, compared to 5 or 7 days.

Help requested:
If anyone can help me understand why this is occurring, or things I can do to prevent this error so WRF ends successfully (and therefore prevent spending unnecessary compute hours), I would appreciate it.

Details:
I am running 3 domains, 2 nested telescoping on the southeast United States.

I am using the Cheyenne HPC resources, using WRF and WPS Version 3.9, and retrieved pre-compiled model files from:
Code:
~wrfhelp/PRE_COMPILED_CODE/WRFV3.9_intel_dmpar/

My wrf working directory is:
Code:
/glade/scratch/mlittle/WRFV3.9_intel_dmpar/test/em_real/

And rsl out and error files are located at:
Code:
/glade/scratch/mlittle/WRFV3.9_intel_dmpar/test/em_real/20090301-20090302_PGW_RUN/RSL_FILES/
The name of the job is:
PGW-20090301_00Z-20090306_00Z-TEST

Currently loaded modules (retrieved from module list command):
1) ncarenv/1.3 2) intel/18.0.5 3) ncarcompilers/0.5.0 4) mpt/2.19 5) netcdf/4.6.3 6) idl/8.7.2 7) ncl/6.6.2 8) grads/2.2.1

Copies of the WPS and WRF namelists (also attached), and wrfbdy_01 file can be found at:
Code:
/glade/scratch/mlittle/WRFV3.9_intel_dmpar/test/em_real/20090301-20090302_PGW_RUN/

I am using 0.5° GFS analysis data from:
https://www.ncdc.noaa.gov/data-access/model-data/model-datasets/global-forcast-system-gfs

And using 0.5°RTG-SST data from:
ftp://polar.ncep.noaa.gov/history/sst/rtg_low_res

Please let me know if additional information needed to help understand and solve the problem.

Thanks,
Matthew B. Little
 

Attachments

  • namelist.input
    4.9 KB · Views: 174
  • namelist.wps
    1.5 KB · Views: 98
Hi Matthew,

The problem is that you have run_days = 5 at the top of the namelist. Since you only want to run for 24 hours, you should set that to 1 (or alternatively you could set it to 0 and set run_hours = 24 - it doesn't make a difference).

This may be more information than you are interested in, but as it's a bit confusing, I wanted to provide a bit more explanation. The real program looks at the start & end date& time section, so it runs and outputs boundary conditions at the beginning period for each available time. Since you have interval_seconds set to 21600, you will get boundary conditions every 6 hours. If you issue the command:
Code:
ncdump -v Times wrfbdy_d01

you will see the boundary times listed at the bottom of the output:
Code:
Times =
  "2009-03-01_00:00:00",
  "2009-03-01_06:00:00",
  "2009-03-01_12:00:00",
  "2009-03-01_18:00:00" ;

When the wrf program runs, it is interested in the start date/time, and "run_days" (or "run_minutes"). So it knows to start at 2009-03-01_00:00:00, but thinks it should continue for 5 days, and at time 2009-03-02_00:00:00, there are no boundary conditions listed in the wrfbdy_d01 file, so it doesn't know how to continue, and spits out the error.
 
Thank you for pointing out the issue in the namelist. I have now made the correction and also for the information about real.exe and boundary times, that helps me understand why this is occurring.

Thank you for sharing your time and expertise!
 
Top