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

Ingesting high-resolution terrain and landuse input in a moving nest run

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 am performing a WRF run with two automatic moving nests. I would like to incorporate high-resolution terrain and landuse input in the moving nests. I have followed the user manual and added the following to my namelist.input:

- At run time, add these namelists in &time_control:
input_from_hires = .true., .true.,
rsmas_data_path = “terrain_and_landuse_data_directory”

However, I got the following error from my rsl.error.0000 file:

Access to RSMAS Topo Ingest Code is by Special Arrangement Only in WRF. Please contact wrf

​I am using WPSV4.2 and WRFV4.2. I have attached my namelist.input and my rsl.error.0000 below for reference.

Thank you for your help in advance.


  • namelist.input.txt
    4.6 KB · Views: 43
  • rsl.error.0000.txt
    5.7 KB · Views: 31
I re-compiled WRF with
and were able to fix the above error.

However, another problem appeared. After ~48 hrs of integration, WRF crashed with the error
rsl.error.0073:Water budget problem in NOAHMP LSM
Searching for the keyword "error" in the rsl.error.xxxx files, I found
horizontal interp error - lake ( 118, 65), using average -0.0009

Upon removing the two lines
input_from_hires = .true., .true.,
rsmas_data_path = “terrain_and_landuse_data_directory”
from namelist.input, I was able to run WRF towards completion without problem.

The terrain and landuse data was obtained from I am using ERA5 for the runs.

I have attached my error log, namelist.wps, and namelist.input file here.



  • namelist.input
    4.5 KB · Views: 54
  • namelist.wps
    885 bytes · Views: 47
  • rsl.error.0073.txt
    148.5 KB · Views: 36
I am able to avoid the Water budget problem by setting sf_surface_physics = 1, although the horizontal interp error persists. Thanks for the advice!
I have a further question about the way the high-res data are ingested into the moving nests:

I am aware that the fields VAR, CON, OA1, OA2, OA3, OA4, OL1, OL2, OL3, OL4 are generated from the WPS for the gravity wave drag scheme.

When I use high-res data ingestion for the moving nests, does the gravity wave drag scheme in the moving nests use the fields generated from the WPS (which were supposedly generated for the coarsest, non-moving domain), or does it calculate new fields for the moving nests from the high-res data?

Many thanks!
The high-resolution data incorporated into moving nest run only includes terrain height and land use type. When the model runs with moving nest capability, it recalculate topography and landuse type based on the high-resolution input data. Surface fluxes will change accordingly over the fine-resolution grids.