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 with moving_nest and hires

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
Dear all,

I am reaching you as I have an issue on using WRF4.2 with a moving nest and high-resolution terrain and landuse input.

Currently, I manage to run WRF with a moving nest but without using high-resolution terrain. When doing it, I am following instructions presented here
and putting in my namelist:

input_from_hires       = .false., .true.,
rsmas_data_path        = “terrain_and_landuse_data_directory”

Knowing that rsmas data are from here:
Also, geogrid made by WPS was done by using usgs with lakes.

The problem seems related to the interpolation of the LU_INDEX for the d02 when using hires. When doing so, lu_index tends to put incoherent values ( from negative to high values) and interp error
horizontal interp error - lake (  15,  13), using average    -4.0000

which creates the following error in WRF:

-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE:  <stdin>  LINE:    1734
 ERROR: LANDUSE OUTSIDE RANGE =          -1  AT           24           1  LUN=           33

I traced it back to the interp_fcnm_lu function ( in share/interp_fcn.F) but could not go futher to understand what was wrong.
I tried adding -DLANDREAD_STUB in CFLAGS of the configure.wrf but it did not change anything.

I don't know if you have ever encountered this kind of problem and if you have any solution for it.

Thank you
A small update...

When compiling with -DTERRAIN_AND_LANDUSE the compilation is failling... Do not know how to solve it...
I join the confire.wrf used and the log file



  • configure.wrf
    22.5 KB · Views: 22
  • log.compil.txt
    1.3 MB · Views: 26
Hi Mathieu,
Yes, to use this option, you will need to compile using the -DTERRAIN_AND_LANDUSE flag. To get around the compile error you're seeing, can you try to go into the share/ directory and copy "landread.c.dist" to "landread.c?" After that, you'll need to go back to the WRF directory, issue a "clean -a," make sure you have TERRAIN_AND_LANDUSE set in the environment, and then recompile. Let me know if that helps.
Hi, and thank you for your reply

Yes, I already tried that. Indeed, the compiliation works fine but it still rises an error due to lu_index interpolation (negative values appearing ...).
The thing is, when using landread.c.dist the get_landuse (used in interp_fcnm_lu) does not do much....

int GET_LANDUSE ( float *adx,
                         float *xlat,
                         float *xlon,
                         float       *landuse,
                         int   *mix,
                         int   *mjx,
                         int   *iyyn,
                         int   *jxxn,
                         int   *ipath , int * ipathlen ) /* integer coded ASCII string from Funtran and len */
#ifndef MS_SUA
 fprintf(stderr, "***************************************************************\n" ) ;
 fprintf(stderr, "Access to RSMAS Topo Ingest Code is by Special Arrangement Only\n" ) ;
 fprintf(stderr, "in WRF.  Please contact                      \n" ) ;
 fprintf(stderr, "***************************************************************\n" ) ;
 return(0) ;

I don't know how to get around this problem
Thank you

Can you attach your namelist.input file, along with your error logs (e.g., rsl.error*). If there are multiple error logs, please package them together in a single *.TAR file. Please also send me your configure.wrf file. Thanks!
Thanks for sending that. Out of curiosity, if you set
input_from_hires = .true., .true.
does that make any difference?
Thanks for trying that. I see in your namelist, you have num_land_cat = 28, which is what I would expect with USGS static data, but the error you're getting indicates that it's finding 33 categories. Are you using anything else, in addition, to the USGS?

If not, can you send me a couple of your met_em* files, along with your namelist.wps file (if the files are too large, see the home page of this forum for information on sending large files)? I'd like to try to repeat this, if possible.
Hi Mathieu,
Thank you for providing those, and for your patience. I think I've figured out the issue. In your namelist.wps, you have:
geog_data_res     =   usgs_lakes+30s+albedo_ncep+maxsnowalb_ncep, 3s, 3s+30s,

Unfortunately the hires landuse option only works with basic USGS, which means you'll have to set this to:
geog_data_res     =   'usgs_30s+default',

I tried a couple of tests with my own input data. I first set geog_data_res = 'usgs_lakes+default' and I still get the error you're getting, but when I switch to just geog_data_res = 'usgs_30s+default' it gets past that error when running wrf.

That being said, I'm still not able to get ANY (including my own test, separate from yours) hires moving nest option to run wrf to completion, so I'm not sure what the problem is. I don't have a lot of experience with this option, but I assume some run it without issues. If you do get past this current error, and then run into other problems, open a new forum post and we can look at the new issue. Either way, let me know how this suggestions works out.
Surprisingly it is working fine with an old version I have (WRF-3.7.1). No need to change the landread.c and the LU_INDEX interpolation is done properly. I am investigating what can create the compilation error in my other version.


I am coming back to you since I found a way to solve the error. The probleme was that the -DRPC_TYPES ==1 (or 2) was not put in the right place in my configure.wrf.

At first it was in "ARCH_LOCAL" list. But when putting it in "CFLAGS", the compilation of landread.c is done correctly and wrf.exe with moving_nest + hires works fine.

Wow, that actually helped my case finish running, as well! Thank you so much for finding this and for updating with the fix. I'll submit a request to modify the code to include something that will correct this. Thanks!
Also, in case some people have trouble using moving nest with sst_update. When you do this, you may get strange patterns for SST in wrfout_d02 ( if d02 is your moving nest).

It seems that in the distributed version the SST is not interpolated. To correct this you can edit in Registry/Registry.EM:
# Simple SST interpolation from the CG
state    real   SST              ij    misc        1         -     i01245rh05d=(interp_mask_field:lu_index,iswater)f=(p2c)   "SST"              "SEA SURFACE TEMPERATURE" "K"
#state    real   SST              ij     misc        1         -     i01245rh0d=(interp_mask_field:lu_index,iswater)   "SST"              "SEA SURFACE TEMPERATURE" "K"

Then SST interpolation from d02 is done properly.

Thanks again! I'd like to acknowledge you in the code modification request. Do you mind telling me your full name and affiliation? If you'd rather not post it here, let me know and I can provide an email address for you. Thanks!
I sent an email but got a message saying that
WRF Support questions are no longer answered through
So I do not know if you received it. If no,t I will put informations here.