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

Add new parameters in URBPARM.TBL

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

I'm studying to add the variables (traffic anthropogenic heat and its diurnal profile) in the URBPARM.TBL. I tried to set the variables (TAH and TAHDIUPRF) in module_sf_urban.F referring to the setting of the parameters AH and AHDIUPRF in the file. I didn't add the new variables (TAH and TAHDIUPRF) in Registry file, because I learned that the parameter AH is a local variable and "Local variables inside of physics packages are not controlled by the Registry" (

1. I personally think that if the registry file has not been changed, there is no need to clean the WRF code and rebuild it. Then I ran wrf.exe directly, the error was "Unrecognized name TAH in Subr URBAN_PARAM_INIT".

2. Therefore, I tried to clean the WRF code and rebuild it, and it failed to build executables. The error was "cannot find and open some module files, such as module_sf_urban.mod, module_sf_noahdrv.mod, module_surface_driver.mod, etc.

Thank you for any ideas or tips on how to add new parameters in URBPARM.TBL.
The values of AH and AHDIUPRF are provided in run/URBPARM.TBL. They are read into WRF in the subroutine "SUBROUTINE urban_param_init".
You are right that these variables are not state variables and thus you don't need to do ./clean -a. But once you change any codes, you still need to recompile the code by typing ./compile em_real.
If you did type ./clean -a and recompile the code, that is completely fine. However, if you failed to recompile WRF, it indicates that your modification introduced errors into WRF. Please look at your compile log file, and fix the errors first.
Hi, Ming.

Thank you for the reply. I recompiled the code, and it did work. Then I ran ./wrf.exe, but some errors occurred. Here are the error files that I encountered. Any suggestions on the problems?



  • 1-rsl.error.0000.txt
    2.7 KB · Views: 31
  • 2-rsl.error.0000.txt
    2.2 KB · Views: 32
Hi, Wenky,
It seems that the model crashed immediately after it started. This often indicates two issues: either the data is wrong or the memory is not sufficient.
To figure out the reason,
(1) Please make sure that you compile WRF in dmpar mode.
(2) Your 1-rsl.error.0000.txt indicates that you run run the case with only one processor, is this right? If so, can you run this case using 4 processors? More processors can give you larger memory.
(3) If the case still fails when run with 4 processors, then we will need to look at wrfinput ad wrfbdy. It is possible that the input data is wrong.
Hi, Ming.

Thank you for your reply. I tried some online methods to solve the segmentation fault. For example, reduce the time_step or increase the number of processors, but they didn't work. Later I figured out that although the WRF codes were recompiled successfully, there were errors when adding the new parameters in module_sf_urban.F. Then I corrected them and ran the codes successfully.