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

cglc-modis-lcz_100m dataset " WARNING, THE URBAN FRACTION WILL BE READ FROM URBPARM.TBL USING DEFAULT URBAN MORPHOLOGY"

liz

New member
Dear WRF experts!

I am stuck running WRF urban using the cglc-modis-lcz_100m dataset for Germany using three one-way nested domains at 12, 3, and 1 km, respectively. I'm considering the sf_urban_physics = 2 and the hybrid 100-m global land cover dataset with Local Climate Zones. To use this dataset, I followed the instructions provided here, which include changing the geog_data_res in namelist.wps as follows:

geog_data_res = 'cglc_modis_lcz+default', 'cglc_modis_lcz+default', 'cglc_modis_lcz+default'

I changed the GEOGRID.TBL.ARW_LCZ accordingly.
Also, I downloaded the dataset from the WPS V4 Geographical Static Data Downloads Page. Geogrid.exe, ungrib.exe, and metgrid.exe work fine, so does real.exe.
However, when I run wrf.exe, I get suspicious warnings in the rsl.error.0000 claiming that WRF does not use the LCZ data:

WARNING, FRC_URB2D = 0 BUT IVGTYP IS URBAN
WARNING, THE URBAN FRACTION WILL BE READ FROM URBPARM.TBL
USING DEFAULT URBAN MORPHOLOGY

I attached the namlist.wps, namlist.input and the rsl.error.0000 file.

Additionally, I uploaded a folder called "wrf_physics_lcz_Germany.zip" to the nextcloud that contains geo_em and met_em files and the Geogrid tbl (plus the files attached below).

I am using WRF 4.5.2 and WPS 4.5 and ensured that for both of them I am using official releases as you suggested in this post.

Can you see what the problem is? What did I miss?
Thank you very much for your help!

Best,
Lisa
 

Attachments

  • namelist.input
    3.4 KB · Views: 4
  • namelist.wps
    1.1 KB · Views: 7
  • rsl.error.0000
    919.5 KB · Views: 2
Last edited:
Hi there, here are answers to your questions:
1. You did not activate LCZ in your namelist.input. set "use_wudapt_lcz = 1" in your &physics section.
2. the "FRC_URB2D" is only available over CONUS region because it is from NLCD2011 data. For regions outside US, the FRC_URB2D (either use or not use LCZ) will be read from urban parameter table (URBPARM.TBL or URBPARM_LCZ.TBL).
 
Thanks for the quick answer and the explanation.

However, when setting the parameter use_wudapt_lcz=1 in the &physics section, the warning/error still remains. (I actually accidentally uploaded the wrong namlist.input file previously. Still I double-checked it and rerun the model - same output. You can find the right namelist.input attached. Sorry for the inconvenience).

Is there any other problem you can spot? How can I avoid the model falling back to default morphology, i.e., not considering the LCZ classes? Thanks!
 

Attachments

  • namelist.input
    4.6 KB · Views: 6
Last edited:
Hi, the warning is fine. As I explained in my earlier message, because there is no "FRC_URB2D" outside US region from WPS (if you check this variable in your geo_em file or wrfinput file, it shows 0 over your study domain), the model directly uses the FRC_URB value set in the URBPARM_LCZ.TBL for each LCZ type. So there is no issue for your run. You can ignore the warning.
 
Dear WRF team,
one follow-up on that: I performed two runs: one with urban + lcz data, one without urban physics + lcz data.
The output in the rsl.error.0000 message is different (I do not get the warning when turning lcz data off as expected).
However, the output predicted/simulated by the wrf model is exactly the same (I compared numerical values on my most inner domain of different variables like T2, tc, etc. in the wrfoutput files).

In my understanding, it should not be the case that using lcz data and urban physics does not make (even the tiniest) difference, right?

It would be great to get your opinion on/ assessment of that! Thank you very much for your help.
 
Dear WRF team,
one follow-up on that: I performed two runs: one with urban + lcz data, one without urban physics + lcz data.
The output in the rsl.error.0000 message is different (I do not get the warning when turning lcz data off as expected).
However, the output predicted/simulated by the wrf model is exactly the same (I compared numerical values on my most inner domain of different variables like T2, tc, etc. in the wrfoutput files).

In my understanding, it should not be the case that using lcz data and urban physics does not make (even the tiniest) difference, right?

It would be great to get your opinion on/ assessment of that! Thank you very much for your help.
One of your runs turned off the city parameterization scheme but used LCZ instead, right ?
 
Ah, sorry for the confusing description:
One of the runs had BOTH urban physics and LCZ turned on.
The other one had neither of them (urban physics was turned off, and LCZ was not used either).
 
@liz,
I agree with you that there should have differences at least at those urban points. Have you compared Lu_Index in your wrfinput files for the two experiments? Are there large differences between them? What is the resolution of your run?
 
Dear @Ming Chen,
I compared the LU_index attribute and visualized their distribution for both settings (see the attached files, it is for domain 3. "Urban" in this case means "urban+lcz", "no urban" means "no urban, no lcz"). I checked the labels and given the translation from index to category from the technical documentation for both settings (see screenshot for the 61 LCZ categories below) they seem to make sense.

I am using three domains with the following resolution: 9000, 3000, 1000.

Thanks for your help!
 

Attachments

  • landcategory_hist_False.png
    landcategory_hist_False.png
    24.5 KB · Views: 6
  • landcategory_hist_True.png
    landcategory_hist_True.png
    23.3 KB · Views: 6
  • Screenshot 2024-03-18 at 12.47.27.png
    Screenshot 2024-03-18 at 12.47.27.png
    420.7 KB · Views: 5
Last edited:
Hi Lisa,
Thanks for the clarification. The figures you show are for global dataset, not for your study area. Whatsoever, I still believe that with and without LCZ data implementation, you should have different results.
While I have no immediate answers to the question you have, I am concerned of your study domain. With the settings below:

e_we = 37, 58, 13
e_sn = 28, 46, 10

and

map_proj = 'mercator'
ref_lat = 51.480
ref_lon = 7.219

There are two issues here:
(1) The grid numbers in all domains, especially D03, are too small.
(2) The projection is not appropriate for the domain.


Would you please enlarge your domains by increasing the grid numbers to at least 100 x 100 for all domains?

For your study area in mid-latitude, you should change the map projection to 'lambert'

Please modify the configuration and run the case again. Let me know whether you have reasonable results.
 
Hi Lisa,
Thanks for the clarification. The figures you show are for global dataset, not for your study area. Whatsoever, I still believe that with and without LCZ data implementation, you should have different results.
While I have no immediate answers to the question you have, I am concerned of your study domain. With the settings below:

e_we = 37, 58, 13
e_sn = 28, 46, 10

and

map_proj = 'mercator'
ref_lat = 51.480
ref_lon = 7.219

There are two issues here:
(1) The grid numbers in all domains, especially D03, are too small.
(2) The projection is not appropriate for the domain.


Would you please enlarge your domains by increasing the grid numbers to at least 100 x 100 for all domains?

For your study area in mid-latitude, you should change the map projection to 'lambert'

Please modify the configuration and run the case again. Let me know whether you have reasonable results.
CAN WRF use LCZ when turning off city schemes?
 
Dear @Ming Chen,

thanks for the hint. I tested it - and indeed - now I get slightly different results for the two runs. However, the difference is limited to the third decimal place, i.e. the predictions differ <0.01 units for the attributes tested (wind, pressure, and temperature).

Is that what you would expect or should LCZ+urban make a bigger difference?

Once again, thank you very much!
 
Here is, btw, the visualized difference in temperature (t2m) between the two runs in case that helps.
test_diff_19_03_d03.png
 
Top