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

"horizontal interp error – lake" and moving nest


New member

I have successfully compiled WRF v4.1.5 (option 3) with the TERRAIN_AND_LANDUSE option turned on. I can also simulate the outer domain to completion without any errors. However, when I initialize the moving nest domain, I get "horizontal interp error – lake" errors in several rsl files (see the The output looks really clean at the first timestep (at 18z) but becomes awful at 19z (see for examples). From the screenshots, it appears that the horizontal interpolation of the high resolution data is working properly at 18z but not 19z. I was hoping that someone could help be remedy the problem.



  • namelist.wps
    1.2 KB · Views: 0
  • configure.wrf.txt
    20.6 KB · Views: 0
  • namelist.input.txt
    4.3 KB · Views: 3
    270 KB · Views: 0
    757 KB · Views: 1

In your namelist.input, you set:

start_year = 2022, 2022,

start_month = 09, 09,

start_day = 24, 25,

start_hour = 06, 18,

Can you specify the same initial time for D01 and D02 and let me know whether the case can run successfully?
I changed my namelist.input so that both domains are initialized at 18z. So it reads:

start_year = 2022, 2022,
start_month = 09, 09,
start_day = 25, 25,
start_hour = 18, 18,

But I'm still getting the "horizontal interp error – lake" error in multiple rsl files and the output at 19z on 9/25 looks even worse than the previous attempt. Surprisingly, the simulation is still running without any other errors even though the output (e.g., P) in d02 does not resemble a tropical cyclone at all. Do you have any other suggestions?

Let's try the options below:

(1) Recompile WRF by putting "-DRPC_TYPES ==1" to "CFLAGS" list (not in "ARCH_LOCAL" list)

(2) set input_from_hires = .true., .true.

Note that the hires landuse option only works with basic USGS, and thus in your nameless.wps, you must set:

geog_data_res = 'usgs_30s+default',

Please try and let me know whether this case can work.
WRF was originally compiled with "-DRPC_TYPES ==1" in the "CFLAGS" list and namelist.wps was set to the correct geog_data_res (i.e., 'usgs_30s+default'). I tried suggestions (2) and (3) but the simulation still posts the same error.
If you turn off the option TERRAIN_AND_LANDUSE, can you successfully run this moving nest case ?
I "setenv TERRAIN_AND_LANDUSE 0" in my .tcshrc file and replaced every instance of "-DTERRAIN_AND_LANDUSE" to "-DLANDREAD_STUB" in my configure.wrf prior to recompiling WRF. The simulation produces the wrfout files at the first timestep but immediately tosses a segmentation fault error. I've tried increasing and decreasing the number of cores to run the simulation and nothing helps. Furthermore, the rsl files contain no mention of "error", "cfl", or "fatal". When I preview the output data in the inner (moving nest) domain, I can see that data is clearly missing or erroneous (see P_screenshot.png) and that the simulation does not do any horizontal interpolation of the landuse data (see LU_INDEX_screenshot.png). I'm also including my updated configure.wrf and namelist.input files for completeness.

When I run the simulation with only the outer domain it happily runs without any errors. Any other insight on this would be greatly appreciated!


  • configure.wrf.txt
    20.6 KB · Views: 0
  • LU_INDEX_screenshot.PNG
    64.2 KB · Views: 3
  • P_screenshot.PNG
    101.1 KB · Views: 3
  • namelist.input.txt
    4.3 KB · Views: 2
If you didn't compile the code with high-resolution input option, then in your nameless.input, please set

input_from_hires = .false., .false.,

Also, please correct the options as follow:

diff_opt = 1, 1,
km_opt = 4, 4,

Let's make sure this case can run without high-resolution input data.
Last edited:
I made the changes you suggested and the model still tosses the "horizontal interp error – lake". The model continues running for several more hours before failing because of the cfl condition (which I'm assuming stems from the interp error resulting in erroneous data). Do you have any other suggestions?