Add variables needed for SLUCM with 2D maps of urban parameters and anthropogenic heat

[epn09]

• Related to https://github.com/wrf-model/WRF/pull/1986.
• This PR modifies GEOGRID.TBL.ARW to include variables needed for SLUCM with 2D maps of urban morphological parameters and anthropogenic heat.
• The binary files can be downloaded from here: https://urbanclimate.tse.ens.titech.ac.jp/database/slucm_distributed_drags_static_data
  • AHE_2010s.tar.gz: 2010s anthropogenic heat.
  • AHE_2050s.tar.gz: Projected 2050s anthropogenic heat.
  • urban_parameters.tar.gz: 2010s and projected 2050s urban parameters.
  • modis_landuse_20class_15s_2010s.tar.gz: The default modis_landuse_20class_15s with all grids with LandScan population density > 1000 people/km^2 converted to urban category (number 13). This was done because we found that the urban area in the default modis_landuse_20class_15s was too small. Better methods or data source are welcomed.
  • modis_landuse_20class_15s_2050s.tar.gz: Same as the above but projected 2050s population density is used.
  • modis_landuse_20class_15s_2010s_with_lakes.tar.gz, modis_landuse_20class_15s_2010s_with_lakes.tar.gz: Same as the above but using the modis with lakes version as the base for modification.
  • greenfrac_fcover_cgls.tar.gz and lai_cgls.tar.gz are the 2010-2019 averages of the CGLS green cover and LAI datasets. Because urban fraction is estimated from green fraction, using this dataset is preferable. The default MODIS greenfrac and LAI has zero value for urban. They can be selected by adding +cgls_veg to the namelist.wps.
  • The option modis_veg_no_search is the same as the default MODIS greenfrac and LAI but with the +search removed. The reason is because +search generates artificial patched vegetation patterns for urban areas.

[epn09]

@cenlinhe This the static data for the SLUCM distributed drag physics.

[weiwangncar]

@epn09 Can you let us know the source of these files? Who produced them? Name and organization? Thanks!

[epn09]

@weiwangncar I've updated the PR description. Please check. Thanks!

[weiwangncar]

@epn09 Thanks! Another question: what's the diff between AHE 2-byte and 3-byte datasets? Resolution?

[weiwangncar]

I have run a test to process the new data, and it seems to work fine. I placed the data in a subdirectory under WPS_GEOG/slucm/. This requires the change of the location for the data in geogrid/GEOGRID.TBL. Suggestions are welcome.

[cenlinhe]

I have run a test to process the new data, and it seems to work fine. I placed the data in a subdirectory under WPS_GEOG/slucm/. This requires the change of the location for the data in geogrid/GEOGRID.TBL. Suggestions are welcome.

putting it to WPS_GEOG/slucm/ sounds good to me.

[cenlinhe]

we will also need to upload it to the wps_geog data website.

[epn09]

@epn09 Thanks! Another question: what's the diff between AHE 2-byte and 3-byte datasets? Resolution?

@weiwangncar in most location, AHE can be represented using only 2 bytes. For very few big cities like Tokyo, 3 bytes are needed. Therefore, we separated them to save storage space. There is no tile having data in both 2- and 3-byte format.

[weiwangncar]

@epn09 If you also agree we can put all the new data under a directory slucm/, can you please add slucm/ to the data path such that, for example, rel_path = y2010_ahe:AHE_2010s/2_bytes/ will become rel_path = y2010_ahe:slucm/AHE_2010s/2_bytes/. Can you make the change in the GEOGRID.TBL.ARW file? Thanks.

[epn09]

@weiwangncar

Is it directory structure satisfactory? I feel like putting green fraction, LAI and modis landuse to slucm folder is a little bit weird.

WPS_GEOG/
├── greenfrac_fcover_cgls
├── lai_cgls
├── modis_landuse_20class_15s_2010s
├── modis_landuse_20class_15s_2050s
├── modis_landuse_20class_15s_with_lakes
├── modis_landuse_20class_30s_with_lakes
└── slucm
     ├── AHE_2010s
     │   ├── 2_bytes
     │   └── 3_bytes
     ├── AHE_2050s
     │   ├── 2_bytes
     │   └── 3_bytes
     └── urban_params
         ├── 2010
         │   ├── d
         │   ├── H_avg
         │   ├── lambda_f
         │   ├── lambda_p
         │   └── z_0
         └── 2050
             ├── d
             ├── H_avg
             ├── lambda_f
             ├── lambda_p
             └── z_0

[weiwangncar]

@epn09 The advantage to place all of the relevant files together is for a user to consider them together. @cenlinhe What do you think?

[epn09]

@cenlinhe What's your opinion?

[cenlinhe]

I think Wei's suggestion might be better, since your LAI and MODIS data are designed to work with your urban modifications. We do not want to mess up with the standard WRF/WPS MODIS dataset. I would suggest putting your data under SLUCM or even rename the folder as something like SLUCM_EPN (as a identifier for your scheme's dataset)

[epn09]

@weiwangncar @cenlinhe I've modified GEOGRID.TBL.ARW so that all new static data are under slucm_kvnk subdirectory. The manual pdf file is also updated to reflect this. Please check. https://urbanclimate.tse.ens.titech.ac.jp/database/slucm_distributed_drags_manual.pdf

[weiwangncar]

@epn09 Does kvnk mean something? @mgduda Should the branch this PR is compared to different than develop?

[epn09]

@weiwangncar kvnk is the combination of the initials of the people who developed this model (Khanh, Varquez, Nakayoshi, and Kanda). I have no specific preference for this naming. If you have suggestions about other user-friendly names, please let me know.

[weiwangncar]

@dudhia @cenlinhe Are you ok with this subdirectory name?

[cenlinhe]

I would suggest using the paper-related name, something like: slucm_Khanh2023 (if the paper is Khanh et al., 2023), just my two cents

[dudhia]

I think just slucm is fine. Wasn't that the original name in this commit?

[epn09]

So, what's the final decision about naming?

[weiwangncar]

@cenlinhe @dudhia I'm ok with just slucm, or slucm_Khanh2023. If slucm serves the purpose, I'd say we should go for something simpler.

[cenlinhe]

I am fine with slucm. The original reason for me to suggest put a suffix after slucm (e.g., slucm_K23) is to differentiate it from any potential future SLUCM-related data. If this is not a concern, then we can go with slucm for now.

[epn09]

@cenlinhe @weiwangncar I've changed the directory name to slucm.

[epn09]

Still wonder why the some of the changed files are not related to the table change.

@weiwangncar Those changes are due to the difference between the master and the develop branch. My changes are based on the master branch but the merging target of this PR was set to develop by @mgduda.

[mgduda]

Still wonder why the some of the changed files are not related to the table change.

@weiwangncar Those changes are due to the difference between the master and the develop branch. My changes are based on the master branch but the merging target of this PR was set to develop by @mgduda.

I'm not quite sure what's going on. The master branch was merged into the develop branch (81fc0d8), and so the commits b07ae296 .. 5a2ae639 that GitHub is showing as new in this PR are already on develop. I'll try changing the base branch to something other than develop, then back to develop again to see if GitHub recognizes the commits already on develop. Otherwise, I can verify the merge-base is actually correct (in spite of what GitHub says) on the command-line.

[imreduzmat]

Hello, I accidentally came across this link and decided to ask you.. Is it possible to add data with a resolution of 10m on the land surface. Similar to CORINE Land Cover (https://land.copernicus.eu/en/products/corine- land-cover/clc2018) but with a resolution of 10m, taking the data from CLC+Backbone (https://land.copernicus.eu/en/products/clc-backbone?fbclid=IwAR29NU-6vwFBBxYfadQpB2B8NG9F3ZTj3LpjXFSeZjkUC2RdyMn7qYFb98k) The aim is to simulate the influence of roads, buildings and clutter, but with a resolution of 10m. It may be included in the SLUCM (urban WRF) package, but I am not aware of it.

Thank you for your attention

[zhouleo0619-maker]

Hello, I noticed that after enabling distributed_aerodynamics_option, the following code in module_sf_urban.F is executed:

IF (distributed_aerodynamics_option) THEN ZDC = 0. IF (Z0_URB > MH_URB) THEN FATAL_ERROR("Z0_URB is larger than MH_URB") END IF ZR = MAX(MH_URB, 3.5) Z0C = MAX(Z0_URB, 0.1) ... END IF

Could you please explain why ZDC is forced to 0 here, instead of being read from the corresponding grid value zd in the met_em* files?

[epn09]

@zhouleo0619-maker Hello. Because under this option, Displacement height in met_em* files is added directly to topography in the real.exe step (see the code here: https://github.com/wrf-model/WRF/blob/f52c197ed39d12e087d02c50f412d90d418f6186/dyn_em/module_initialize_real.F#L626-L633). Therefore, we don't consider it once more in the urban module.

[zhouleo0619-maker]

Thank you very much for the clarification. I really appreciate your help!

Do Ngoc Khanh @.***> 于2025年9月11日周四 10:47写道：

epn09 left a comment (wrf-model/WPS#244) https://github.com/wrf-model/WPS/pull/244#issuecomment-3277173683

@zhouleo0619-maker https://github.com/zhouleo0619-maker Hello. Because under this option, Displacement height in met_em* files is added directly to topography in the real.exe step (see the code here: https://github.com/wrf-model/WRF/blob/f52c197ed39d12e087d02c50f412d90d418f6186/dyn_em/module_initialize_real.F#L626-L633). Therefore, we don't consider it once more in the urban module.

— Reply to this email directly, view it on GitHub https://github.com/wrf-model/WPS/pull/244#issuecomment-3277173683, or unsubscribe https://github.com/notifications/unsubscribe-auth/BXG5I637R3S5U3X6YAYZT733SDPEVAVCNFSM6AAAAACGGDHAI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENZXGE3TGNRYGM . You are receiving this because you were mentioned.Message ID: @.***>