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

Unable to run the WRF with sf_urban_physics = 3 option

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
Hi everyone,

When I am using the sf_urban_physics = 3 option in the namelist.input file of WRF V4.0, I am getting the below mentioned issue.

"num_urban_layers too small, please increase to at least 5400"

WRF model is not running even if I added the num_urban_layers = 5400 in the namelist.input file.

I shall be grateful if anyone can help me to resolve this issue.
When you increase num_urban_layers to 5400, are you still getting the same error? Please attach your namelist.input file, along with all of your rsl* files packed together into a single *.TAR (not *.rar - we can't open this type) file. Please also let me know which version of the model you are using. Thanks!
Dear Kwerner,

Thank you for your kind response.

When I increased num_urban_layers to 5400, I did not get the same error, but the model is not running, I am using WRF V4.0

When I am using the sf_urban_physics = 3 option, without running any timesteps, it is showing "num_urban_layers too small, please increase to at least 5400". After adding the "num_urban_layers = 5400" option, it was running for 23 hours (out of 96 hours) then it has stopped abruptly.

As you ask, I am sending my namelist.input file and one rsl.error and out file only. The total rsl file has 13G, that's why I am not sending all rsl file. If these are necessary I will send them.

Note: I was able to complete the simulations with the sf_urban_physics =1 and 2 options but the problem with option 3 only.

Thanking you


  • rsl.out.0000.txt
    27.1 MB · Views: 30
  • rsl.error.0000.txt
    1.5 MB · Views: 31
  • namelist.input
    4.6 KB · Views: 65
It looks like there were some issues with urban option 3 prior to V4.2 of the WRF code. Can you try to run this with V4.2 code (or newer) and see if you're able to get past the problem?
Dear Kwerner,

As you suggested I used the WRF V4.2 for urban option 3, but it is showing below-mentioned issue/error when I am running the real.exe. Same namelist.input file is working for the WRFV4.0 but it is not working for WRFV4.2.

"Maybe this is a global domain, but the polar flag was not set in the bdy_control namelist".

I shall be grateful if you could give me some suggestions to solve my issue.
Thank you
The error is stating that it believes you are using a global domain, but you don't have the polar flag set in your namelist. To correct this, you simply need to add (in the &bdy_control section)

polar = .true.
Dear Kwerner,

After adding the polar = .true. in the &bdy_control section, it is showing below mentioned error.

alloc_space_field: domain 1 , 847752956 bytes allocated
d01 2020-10-11_00:00:00 Yes, this special data is acceptable to use: OUTPUT FROM METGRID V4.2
d01 2020-10-11_00:00:00 Input data is acceptable to use:
metgrid input_wrf.F first_date_input = 2020-10-11_00:00:00
metgrid input_wrf.F first_date_nml = 2020-10-11_00:00:00
d01 2020-10-11_00:00:00 Timing for input 1 s.
d01 2020-10-11_00:00:00 flag_soil_layers read from met_em file is 1
d01 2020-10-11_00:00:00 Turning off use of MAX WIND level data in vertical interpolation
d01 2020-10-11_00:00:00 Turning off use of TROPOPAUSE level data in vertical interpolation
*** Error in boundary condition specification
boundary conditions at xs 1
boundary conditions at xe 1
boundary conditions at ys 2
boundary conditions at ye 2
boundary conditions logicals are
periodic_x F
periodic_y F
symmetric_xs F
symmetric_xe F
symmetric_ys F
symmetric_ye F
open_xs F
open_xe F
open_ys F
open_ye F
polar T
nested F
specified T
-------------- FATAL CALLED ---------------
*** Error in boundary condition specification
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 19
Ok, I went back and looked closer at your namelist. It doesn't look like you are actually trying a global run, so remove the "polar" option from the namelist. Go back and run again and this time, please send me the full output log (e.g., rsl.error.*) so that I can take a look. Thanks!
Dear Kwerner,

Sorry for the late response. I was unable to concentrate on my research due to some personal problems.

As you suggested, I am attaching the namelist.input file and all rsl files in zip format.

Than you


    962.2 KB · Views: 30
Thanks for sending those.

1) As we know there is likely a problem with urban option 3 in older versions, I'd like to ask that, at least for now, you use the latest version of the code (V4.2.2). It's a lot harder to try to troubleshoot a problem, when there could potentially be multiple problems. The rsl files you sent show that you're using V4.0.

2) You mentioned that you did set num_urban_layers to 5400, but I'm not seeing it in your namelist, and the rsl.out* files still give the error:
num_urban_layers too small, please increase to at least         5400
However, this is no longer a namelist option (and I assume something that needs to be done) in the newer versions of the code. I just wanted to point out that this is the reason for the failure - at least in the simulation you sent me, for V4.0.

3) If WRF is still failing when you use V4.2.2, try to determine if there is a particular domain causing the problem by running only 1 domain, and if that runs, try 2. Once the model fails, please re-send your new namelist and rsl* files.