Questions about WRF-UCM landuse and URBAPARM.TBL

[Kecheng Zhao]

Hello,


I encountered the following issues while using WRF-UCM:


I am using MODIS 21-class land use data. After running geogrid, I used my own Python code to replace urban category 13 with 31 (low-density residential), 32 (high-density residential), and 33 (commercial) based on population density. The met_em files generated after running metgrid also show LU_INDEX as 31, 32, and 33.


However, after running real, I found that the LU_INDEX in the wrfinput files reverted to 13. In my namelist settings, I set num_land_cat = 21, and during the WRF run, I noticed the message "USING DEFAULT URBAN MORPHOLOGY" in the logs, so I’m unsure if it used my URBAPARM.TBL settings.


Therefore, I have a few questions and would appreciate your help:

1. Is my approach to modifying land use categories incorrect? How should I properly replace urban categories with 31, 32, and 33? Do I need to modify files like LANDUSE.TBL?
2. The beginning of URBAPARM.TBL is as follows:

# The parameters in this table may vary greatly from city to city.
# The default values are probably not appropriate for any given city.
# Users should adapt these values based on the city they are working
# with.

# Urban Parameters depending on Urban type
# USGS

Number of urban categories: 3

#
# Where there are multiple columns of values, the values refer, in
# order, to: 1) Low density residential, 2) High density residential,
# and 3) Commercial: I.e.:
#
# Index: 1 2 3
# Type: Low-dens Res, Hi-dens Res, Commercial
#


How can I ensure that the low-density residential, high-density residential, and commercial areas use the corresponding settings in URBAPARM.TBL? Or does WRF automatically recognize 31, 32, and 33?

Thank you for your help!

 

[Ming Chen]

I will talk to our urban moduel expert and get back to you ...

 

[Kecheng Zhao]

I will talk to our urban moduel expert and get back to you ...

Thank you so much.

 

[cenlinhe]

which WRF version are you using? If you are using v4.4 and later, please assign 51, 52, and 53 rather than 31, 32, 33:

WRF/phys/module_sf_urban.F at master · wrf-model/WRF

The official repository for the Weather Research and Forecasting (WRF) model - wrf-model/WRF

github.com

WRF/run/VEGPARM.TBL at master · wrf-model/WRF

The official repository for the Weather Research and Forecasting (WRF) model - wrf-model/WRF

github.com

noahmp/parameters/MPTABLE.TBL at e5c0859874407859936739e8be8741f9aed369ee · NCAR/noahmp

Noah-MP Community Repository. Contribute to NCAR/noahmp development by creating an account on GitHub.

github.com

 

[Kecheng Zhao]

which WRF version are you using? If you are using v4.4 and later, please assign 51, 52, and 53 rather than 31, 32, 33:

WRF/phys/module_sf_urban.F at master · wrf-model/WRF

The official repository for the Weather Research and Forecasting (WRF) model - wrf-model/WRF

github.com

WRF/run/VEGPARM.TBL at master · wrf-model/WRF

The official repository for the Weather Research and Forecasting (WRF) model - wrf-model/WRF

github.com

noahmp/parameters/MPTABLE.TBL at e5c0859874407859936739e8be8741f9aed369ee · NCAR/noahmp

Noah-MP Community Repository. Contribute to NCAR/noahmp development by creating an account on GitHub.

github.com

Thank you for your advice.
I'm using v4.5.2, and I think your advice is quite useful.
But I have another question: How should I set num_land_cat?

 

[cenlinhe]

Also, you need to make sure that those modified grids have FRC_URB value larger than 0 in your met_em or geo_em file:

WRF/dyn_em/module_initialize_real.F at master · wrf-model/WRF

The official repository for the Weather Research and Forecasting (WRF) model - wrf-model/WRF

github.com

 

[cenlinhe]

Thank you for your advice.
I'm using v4.5.2, and I think your advice is quite useful.
But I have another question: How should I set num_land_cat?

num_land_cat = 21 is correct for MODIS land type data

 

[Kecheng Zhao]

Also, you need to make sure that those modified grids have FRC_URB value larger than 0 in your met_em or geo_em file:

WRF/dyn_em/module_initialize_real.F at master · wrf-model/WRF

The official repository for the Weather Research and Forecasting (WRF) model - wrf-model/WRF

github.com

I've checked geo_em file and I found that the FRC_URB value of those modified grids are all 0.
I think it will cause "WARNING, THE URBAN FRACTION WILL BE READ FROM URBPARM.TBL" in rsl.error when running wrf? In other posts, I saw someone metioned this warning and it seems not serious.
If I want to avoid this warning, can I change their FRC_URB value?

 

[Ming Chen]

Hi Kecheng,

I've checked geo_em file and I found that the FRC_URB value of those modified grids are all 0.
I think it will cause "WARNING, THE URBAN FRACTION WILL BE READ FROM URBPARM.TBL" in rsl.error when running wrf? In other posts, I saw someone metioned this warning and it seems not serious.

You are right that is FRC_URB = 0 at an urban grid, the model will issue the warning message. However, it is not serious because WRF will use the value from URBPARM.TBL.

If I want to avoid this warning, can I change their FRC_URB value?

You need to create a dataset of FRC_URB, and run geogrid.exe to include it in your geo_em file.

 

[Kecheng Zhao]

Hi Kecheng,


You are right that is FRC_URB = 0 at an urban grid, the model will issue the warning message. However, it is not serious because WRF will use the value from URBPARM.TBL.


You need to create a dataset of FRC_URB, and run geogrid.exe to include it in your geo_em file.

Hi Professor Chen,

Thank you for your advice.

And I want to know if after subdividing city categories into 51, 52, 53, are the data read from URBAPARM.TBL like categories 31, 32, 33? Or are they read from URBAPARM_LCZ.TBL?

 

[cenlinhe]

Hi Professor Chen,

Thank you for your advice.

And I want to know if after subdividing city categories into 51, 52, 53, are the data read from URBAPARM.TBL like categories 31, 32, 33? Or are they read from URBAPARM_LCZ.TBL?

1. you should not activate LCZ in this case (i.e., use the default use_wudapt_lcz = 0), then the model will read the data from URBPARM.TBL like categories 31, 32, 33.
2. Also, please comment out the following lines to allow the model to read in URBPARM.TBL table value for those FRC_URB = 0 urban grids:

WRF/dyn_em/module_initialize_real.F at master · wrf-model/WRF

The official repository for the Weather Research and Forecasting (WRF) model - wrf-model/WRF

github.com

3. If you do the step 2 above, then you do not have to provide a 2-D FRC_URB map as input data in geo_em or wrfinput file, because the model will just use the FRC_URB value from the URBPARM.TBL table value based on your urban categories: WRF/run/URBPARM.TBL at master · wrf-model/WRF

 

[Kecheng Zhao]

1. you should not activate LCZ in this case (i.e., use the default use_wudapt_lcz = 0), then the model will read the data from URBPARM.TBL like categories 31, 32, 33.
2. Also, please comment out the following lines to allow the model to read in URBPARM.TBL table value for those FRC_URB = 0 urban grids:

WRF/dyn_em/module_initialize_real.F at master · wrf-model/WRF

The official repository for the Weather Research and Forecasting (WRF) model - wrf-model/WRF

github.com

3. If you do the step 2 above, then you do not have to provide a 2-D FRC_URB map as input data in geo_em or wrfinput file, because the model will just use the FRC_URB value from the URBPARM.TBL table value based on your urban categories: WRF/run/URBPARM.TBL at master · wrf-model/WRF

Thank you, your advice really helps me a lot.

I have another samll question:

If I didn't commented out the lines and I used 31, 32, 33, with the rsl.error showing "WARNING, THE URBAN FRACTION WILL BE READ FROM URBPARM.TBL", isn't the FRC_URB data read from URBPARM.TBL table? Or just like the code in your link saying "grid%FRC_URB2D(i,j) = 0.9"?

Or commenting out the lines in your link is a requirement for using 51, 52, 53?

 

[cenlinhe]

Thank you, your advice really helps me a lot.

I have another samll question:

If I didn't commented out the lines and I used 31, 32, 33, with the rsl.error showing "WARNING, THE URBAN FRACTION WILL BE READ FROM URBPARM.TBL", isn't the FRC_URB data read from URBPARM.TBL table? Or just like the code in your link saying "grid%FRC_URB2D(i,j) = 0.9"?

Or commenting out the lines in your link is a requirement for using 51, 52, 53?

if you do not comment out the lines and used 31, 32, 33, the FRC_URB2D will be set to 0.9 by ("grid%FRC_URB2D(i,j) = 0.9") and not read from table.
yes, commenting out the lines in my link is a requirement to read FRC_URB2D values from URBPARM.TBL. if you do not comment out those lines, the model will still read other urban parameters from URBPARM.TBL when you use 51, 52, 53.

 

[Kecheng Zhao]

if you do not comment out the lines and used 31, 32, 33, the FRC_URB2D will be set to 0.9 by ("grid%FRC_URB2D(i,j) = 0.9") and not read from table.
yes, commenting out the lines in my link is a requirement to read FRC_URB2D values from URBPARM.TBL. if you do not comment out those lines, the model will still read other urban parameters from URBPARM.TBL when you use 51, 52, 53.

Get it.

It means whether I use 31-33 or 51-53, if I don't comment out those lines, the FRC_URB2D will be set to 0.9 though rsl.error says "THE URBAN FRACTION WILL BE READ FROM URBPARM.TBL"

Thank you so much for your help!

 

[htan2013]

Get it.

It means whether I use 31-33 or 51-53, if I don't comment out those lines, the FRC_URB2D will be set to 0.9 though rsl.error says "THE URBAN FRACTION WILL BE READ FROM URBPARM.TBL"

Thank you so much for your help!

Hi Kecheng, hope you have fixed the building height issue with BEPBEM.
Can you share the paper/methods about transferring urban built-up to low/high/commerical residential area based on population density?

Thank you,
HT