WRF-urban updates for the next WRF release

[cenlinhe]

This update includes urban new capabilities for solar panel, green roof, and local climate zone (LCZ).

TYPE: new feature

KEYWORDS: urban, green roof, solar panel, local climate zone, new building drag coefficient

SOURCE: Developer: Andrea Zonato (University of Trento, Italy)

DESCRIPTION OF CHANGES:
This update includes new capabilities to account for urban solar panel, green roof, new building drag coefficient, and local climate zone (LCZ). The first three new capabilities are for BEP+BEM. The new building drag coefficient is based on Santiago and Martilli (2010) and Guti ́errez et al. (2015). The newly added LCZs are all related to urban and all urban updates are still controlled by sf_urban_physics options. More details will be available in the User's Guide. Briefly, a new urban parameter table (URBPARAM_LCZ.TBL) has been added for using the new LCZ urban category. The new LCZ definition has LU_INDEX=LCZ+30. If a user still wants to keep using the traditional 33 classes (31st-33rd for urban), please specify the namelist option "use_wudapt_lcz = 0". If a user wants to use the new LCZ, please specify the namelist option "use_wudapt_lcz = 1". If the number of urban category in the input files is inconsistent with the namelist option, error messages will occur. Only the LCZ modeling capability is provided here, not the dataset which is the responsibility of users. The method to create the LCZ data is described in the World Urban Database website: http://www.wudapt.org/

LIST OF MODIFIED FILES: list of changed files (use git diff --name-status master to get formatted list)
M Registry/Registry.EM_COMMON
M Registry/Registry.NMM
M Registry/registry.dimspec
M dyn_em/module_first_rk_step_part1.F
M dyn_em/module_initialize_real.F
M dyn_em/start_em.F
M dyn_nmm/module_PHYSICS_CALLS.F
M dyn_nmm/start_domain_nmm.F
M phys/module_physics_init.F
M phys/module_sf_bem.F
M phys/module_sf_bep.F
M phys/module_sf_bep_bem.F
M phys/module_sf_clm.F
M phys/module_sf_noahdrv.F
M phys/module_sf_noahlsm.F
M phys/module_sf_noahmpdrv.F
M phys/module_sf_noahmplsm.F
M phys/module_sf_urban.F
M phys/module_surface_driver.F
M run/LANDUSE.TBL
M run/MPTABLE.TBL
M run/URBPARM.TBL
A run/URBPARM_LCZ.TBL
M run/VEGPARM.TBL
M share/module_check_a_mundo.F

TESTS CONDUCTED:

1. The model compilation has been tested successfully (tested in Cheyenne by both the developer and Cenlin He, NCAR)
2. The model simulation has been tested successfully (tested in Cheyenne by the developer)
3. The model simulation has been tested successfully (tested in WRF Docker by Cenlin He, NCAR)

RELEASE NOTE: WRF-urban updates for green roof, solar panel, and new building drag coefficient for BEP+BEM, and local climate zone for all urban schemes. The paper describing the roof and LCZ update is under development. The new building drag coefficient is based on Santiago and Martilli (2010) and Guti ́errez et al. (2015).
Santiago, J. L. and Martilli, A. (2010). A Dynamic Urban Canopy Parameterization for Mesoscale Models Based on Computational Fluid Dynamics Reynolds-Averaged Navier-Stokes Microscale Simulations. Boundary- Layer Meteorology, 137(3):417–439.
Guti ́errez, E., Martilli, A., Santiago, J. L., and Gonz ́alez, J. E. (2015). A Mechanical Drag Coefficient Formu- lation and Urban Canopy Parameter Assimilation Technique for Complex Urban Environments. Boundary- Layer Meteorology, 157(2):333–341.

[davegill]

@cenlinhe
It looks like all of the NMM jobs are failing. This is typical when there are mods to the Registry.EM_COMMON. There is also a failure with an urban test, so something is not working with existing code.

Please find result of the WRF regression test cases in the attachment. This build is for Commit ID: d93bfb8eabe6cb9d7b32ee7e6aecab8997b8040c, requested by: cenlinhe for PR: https://github.com/wrf-model/WRF/pull/1309. For any query please send e-mail to David Gill.

    Test Type              | Expected  | Received |  Failed
    = = = = = = = = = = = = = = = = = = = = = = = =  = = = =
    Number of Tests        : 19           18
    Number of Builds       : 48           46
    Number of Simulations  : 166           164         5
    Number of Comparisons  : 105           103         0

    Failed Simulations are: 
    output_18:11 = STATUS test_018s em em_real 32 urb3bNE
output_18:9 = STATUS test_018m em em_real 34 urb3bNE
output_2:2 = STATUS test_002m hwrf nmm_real 34 1NE
output_2:2 = STATUS test_002m hwrf nmm_real 34 2NE
output_2:2 = STATUS test_002m hwrf nmm_real 34 3NE
    Which comparisons are not bit-for-bit: 
    None

[cenlinhe]

Hi Dave, I am not familiar with this test failure issue. Could you please give some advice on which part I should look into? The code has been tested and ran successfully in a ARW configuration by the developer. Thanks. Cenlin

…

On Fri, Oct 30, 2020 at 5:41 PM Dave Gill ***@***.***> wrote: @cenlinhe <https://github.com/cenlinhe> It looks like all of the NMM jobs are failing. This is typical when there are mods to the Registry.EM_COMMON. There is also a failure with an urban test, so something is not working with existing code. Please find result of the WRF regression test cases in the attachment. This build is for Commit ID: d93bfb8, requested by: cenlinhe for PR: #1309. For any query please send e-mail to David Gill. Test Type | Expected | Received | Failed = = = = = = = = = = = = = = = = = = = = = = = = = = = = Number of Tests : 19 18 Number of Builds : 48 46 Number of Simulations : 166 164 5 Number of Comparisons : 105 103 0 Failed Simulations are: output_18:11 = STATUS test_018s em em_real 32 urb3bNE output_18:9 = STATUS test_018m em em_real 34 urb3bNE output_2:2 = STATUS test_002m hwrf nmm_real 34 1NE output_2:2 = STATUS test_002m hwrf nmm_real 34 2NE output_2:2 = STATUS test_002m hwrf nmm_real 34 3NE Which comparisons are not bit-for-bit: None — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1309 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKLAFXEGGE53F2VAG7PRGEDSNNFMJANCNFSM4TFPVXLQ> .

-- Cenlin He, Ph.D. Project Scientist Research Application Lab (RAL) National Center for Atmospheric Research (NCAR) Boulder, CO 80301, USA Email: cenlinhe@ucar.edu —— *My working day may not be your working day. Please do not feel obliged to reply to this email outside of your normal working hours.*

[weiwangncar]

@cenlinhe If you never compiled NMM, following the instruction near the end of this page: https://github.com/davegill/wrf-coop/blob/master/README_user.md, and try to compile NMM or HWRF. The compile log file should give you some hints. There are ways to make your code compile with NMM: For every new rconfig variable, you may need to add it in Registry.NMM (check one that looks like the one you've added, and see if anything is done in Registry.NMM). NMM does not support urban options, and hence your new variables are declared as optional. The new 2D and 3D variables should also be packaged. Again check some similar variables for urban options and see how they are handled inside Registry.EM_COMMON.

[dudhia]

Quite often it is possible to make it compile without NMM Registry changes by making variables optional in the driver as long as ifdefs are used in the driver to prevent NMM from seeing them.

…

On Fri, Oct 30, 2020 at 7:05 PM weiwangncar ***@***.***> wrote: @cenlinhe <https://github.com/cenlinhe> If you never compiled NMM, following the instruction near the end of this page: https://github.com/davegill/wrf-coop/blob/master/README_user.md, and try to compile NMM or HWRF. The compile log file should give you some hints. There are ways to make your code compile with NMM: For every new rconfig variable, you may need to add it in Registry.NMM (check one that looks like the one you've added, and see if anything is done in Registry.NMM). NMM does not support urban options, and hence your new variables are declared as optional. The new 2D and 3D variables should also be packaged. Again check some similar variables for urban options and see how they are handled inside Registry.EM_COMMON. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#1309 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77C6MKNU57WBVOC5YXTSNNPDXANCNFSM4TFPVXLQ> .

[davegill]

This causes a failure in

module_PHYSICS_CALLS.f90:1399:26:

 &y_interval,fasdas=fasdas)
                          1
Error: Missing actual argument for argument 'swddir' at (1)

These variables could be declared optional, because there is an explicit interface for each variable in the calling routine.

[davegill]

the variables urban_map_{zrd, zwd, gd, zd, zdf, bd, wd, gbd, fdb} are all defined in the NMM Registry. To be conventional, urban_map_zgrd should also be there.

[davegill]

This additional variable needs to be in the call from start_domain_nmm.F. Optional variables are not easy in for the physics init routine. This would be consistent with having the variable available from the NMM Registry.

[davegill]

These can be optional (even though they are to physics init).

[davegill]

@cenlinhe
The previous comments should get the code OK for an NMM build.

[davegill]

@cenlinhe
I used these namelist options:

 &physics
 fractional_seaice                   = 0,
 mp_physics                          = 16,    16,    16,
 ra_lw_physics                       = 14,    14,    14,
 ra_sw_physics                       = 14,    14,    14,
 radt                                = 6,     6,     6,
 sf_sfclay_physics                   = 2,     2,     2,
 sf_surface_physics                  = 4,     4,     4,
 bl_pbl_physics                      = 8,     8,     8,
 bldt                                = 0,     0,     0,
 cu_physics                          = 16,    16,    0,
 sf_urban_physics                    = 3,     3,     3,
 shcu_physics                        = 0,     0,     0,
 topo_shading                        = 0,     0,     0,
 cudt                                = 5,     5,     5,
 isfflx                              = 1,
 ifsnow                              = 0,
 icloud                              = 1,
 surface_input_source                = 1,
 num_soil_layers                     = 5,
 num_land_cat                        = 28,
 mp_zero_out                         = 0,
 maxiens                             = 1,
 maxens                              = 3,
 maxens2                             = 3,
 maxens3                             = 16,
 ensdim                              = 144,
 aer_opt                             = 2,
 aer_type                            = 1,
 aer_aod550_opt                      = 1,
 aer_aod550_val                      = 0.12
 aer_angexp_opt                      = 1,
 aer_angexp_val                      = 1.3
 aer_ssa_opt                         = 1,
 aer_ssa_val                         = 0.85
 aer_asy_opt                         = 1,
 aer_asy_val                         = 0.90
 /

I get this error in the first timestep:

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x7fd074016dfd in ???
#1  0x7fd074016013 in ???
#2  0x7fd07350e3ff in ???
#3  0x1a276aa in __module_sf_bep_bem_MOD_flux_flat_roof
	at /wrf/WRF/phys/module_sf_bep_bem.f90:4557

The .f90 = line number 4557; the .F file = line number 4370.

   4351       f1=(f+rsmin/rsmax)/(1.+f)
   4352 
   4353       ta=pt*(pr/p0)**(rcp_u)-273.15
   4354       esa=6.11*(10**(ta*7.5/(237.7+ta)))
   4355       qvs=0.62197*esa/(0.01*pr-0.378*esa)
   4356 
   4357       f2= 1./(1.+hs*(qvs-qv))
   4358       f3=1.-0.0016*(25.-ta)**2.
   4359       f4=0.
   4360       dzg_tot=0.
   4361       do iz=1,ng_u
   4362        gx=(qg(iz)-qw)/(qref-qw)
   4363        if (gx.gt.1)gx=1.
   4364        if (gx.lt.0)gx=0.
   4365        f4=f4+gx*dzg_u(iz)
   4366        dzg_tot=dzg_tot+dzg_u(iz)
   4367       enddo
   4368       f4=f4/dzg_tot
   4369 
   4370       rsveg=min(rsmin/(lai*f1*f2*f3*f4),rsmax)
   4371       resg= rr/(aa*aa*utot*fh)

[davegill]

@cenlinhe
The above are the two errors that the regression testing found: failed NMM builds and failed urban simulation.

[cenlinhe]

@davegill @weiwangncar @dudhia Thank you all for the helpful suggestions in solving the NMM compilation problem. Following your suggestions, I have fixed the bugs for NMM and the NMM compilation in Cheyenne has been successful based on my own test. For the urban calculation issue, the equation (line 4370 in module_sf_bep_bem.F) has been modified to solve the problem. Could you please do another regression test to see if all the bugs have been fixed? Thank you!

[davegill]

@cenlinhe @dudhia @weiwangncar
It looks like you have accidentally included files to be staged for commit, and are now part of the code in this PR branch:

./compile.log
./compile_nmm.log
./test/nmm_real/HLC.TBL
./test/nmm_real/wind-turbine-1.tbl

These need to be removed.

[davegill]

@cenlinhe

Could you please do another regression test to see if all the bugs have been fixed?

Thank you for updating the code so quickly. The jenkins regression tests is automatically triggered when you submit a PR. We'll see the status in about 30 minutes. Do you get an email from "jenkins"? It might be in your SPAM folder.

[cenlinhe]

@cenlinhe @dudhia @weiwangncar
It looks like you have accidentally included files to be staged for commit, and are now part of the code in this PR branch:

./compile.log
./compile_nmm.log
./test/nmm_real/HLC.TBL
./test/nmm_real/wind-turbine-1.tbl

These need to be removed.

The files have been removed in the latest version.

[cenlinhe]

@cenlinhe

Could you please do another regression test to see if all the bugs have been fixed?

Thank you for updating the code so quickly. The jenkins regression tests is automatically triggered when you submit a PR. We'll see the status in about 30 minutes. Do you get an email from "jenkins"? It might be in your SPAM folder.

I checked my mailbox and SPAM folder, but I did not see any email from "jenkins".

[davegill]

@cenlinhe
It is suspicious that the only bit-for-bit failure is a nested urban option and this is a PR that addresses urban options.

Here is the jenkins status:

Please find result of the WRF regression test cases in the attachment. This build is for Commit ID: e2b4665121b4e23c2c353ac987e541e0b7f55128, requested by: cenlinhe for PR: https://github.com/wrf-model/WRF/pull/1309. For any query please send e-mail to David Gill.

    Test Type              | Expected  | Received |  Failed
    = = = = = = = = = = = = = = = = = = = = = = = =  = = = =
    Number of Tests        : 19           18
    Number of Builds       : 48           46
    Number of Simulations  : 166           164         1
    Number of Comparisons  : 105           103         0

    Failed Simulations are: 
    output_18:11 = STATUS test_018m em em_real 34 urb3bNE
    Which comparisons are not bit-for-bit: 
    None

[davegill]

@cenlinhe
Sorry for not addressing the previous comments.
The NMM build now works.
The urban job no longer fails with an error.
AND
There is a bit-for-bit difference in the urban options.

[cenlinhe]

@cenlinhe
Sorry for not addressing the previous comments.
The NMM build now works.
The urban job no longer fails with an error.
AND
There is a bit-for-bit difference in the urban options.

Does this nested urban option issue reside in the Registry? Any clue? I am not sure which part is wrong. Thanks!

[davegill]

Align code as much as possible

[cenlinhe]

will do

[davegill]

In the PR commit message, would explain why this initialization is removed from the real program.

[cenlinhe]

will add to the commit message

[davegill]

align code

[davegill]

align code

[davegill]

align code

[davegill]

This file should not be part of the commit

[cenlinhe]

OK. Thanks.

[cenlinhe]

@davegill I have included all your suggestions in this new version for code alignment, adding registry vars to a package, and including an explanation on removing FRC_URB2D initialization in the latest PR commit message. Please let me know if you notice any further issues. Thank you!

[weiwangncar]

@cenlinhe Can you please add some description about replacing the old low/high_density_residential and high_intensity_industrial with LZ*? Is the change only internal and does not impact how a user uses it? If someone has a dataset with urban categories of 31-33, do they need to do anything to use the new code?

[cenlinhe]

@cenlinhe Can you please add some description about replacing the old low/high_density_residential and high_intensity_industrial with LZ*? Is the change only internal and does not impact how a user uses it? If someone has a dataset with urban categories of 31-33, do they need to do anything to use the new code?

@weiwangncar Here is the answer I got from the developer:
"In case one has just 33 classes (31-33 are urban), the code works the same. However one has to relate the 31-33 classes to their respective parameters. The problem is that LCZ_1 that correspond to LU_INDEX=31 does not correspond to the LOW_DENSITY_RESIDENTIAL class, since LCZ_1 would represent the HIGH_DENSITY_RESIDENTIAL CLASS (LU_INDEX=32).

There are 2 possible solutions for this:

1. Make the LCZ correspondent to different LU_INDEX (not like in my code, where LU_INDEX=LCZ+30), so when one uses the 31-33 it automatically corresponds to the correct LCZ.
2. when one uses the 31-33, he should modify the URBPARM.TBL, in order to make the 3 urban classes correspondent to the correct urban parameters."

I have included this information in the "Descriptions of Change" part of the official PR comment above.

[weiwangncar]

@cenlinhe Thanks for the answer. Please update your PR message, and this needs to be described clearly so that the current users of urban options know what to do. I'd also like to see something describing the advantage of this improvement (I assume this is an improvement over what is currently done). Are the added LCZs all related to urban? Are these still controlled by sf_urban_physics options? Maybe you could ask Andrea Zonato to contribute for some documentation of this new feature, and we can add it to the User's Guide.

[cenlinhe]

I'd also like to see something describing the advantage of this improvement (I assume this is an improvement over what is currently done). Are the added LCZs all related to urban? Are these still controlled by sf_urban_physics options? Maybe you could ask Andrea Zonato to contribute for some documentation of this new feature, and we can add it to the User's Guide.

Yes, the LCZ is related to urban and still controlled by sf_urban_physics option. I have included this information in the "descriptions of change" part of the PR message above. Please let me know if that is the location you are pointing to. I have also asked Andrea Zonato to provide me a detailed README file regarding this new urban update, and I will share the README with the WRF release team once I get it.

[weiwangncar]

@cenlinhe Good. But if this overwrites the previously defined urban categories, shouldn't URBPARM.TBL be modified for this release? If there is a paper reference, we could use that too.

[cenlinhe]

@cenlinhe Good. But if this overwrites the previously defined urban categories, shouldn't URBPARM.TBL be modified for this release? If there is a paper reference, we could use that too.

Yes, as I mentioned in the PR message, several Noah-MP parameter tables (not only the URBPARM.TBL) have been modified for all the three urban updates (greenroof, solar panel, and LCZ). Andrea Zonato is writing the paper describing this update currently.

[weiwangncar]

@cenlinhe What about URBPARM.TBL? Shouldn't those parameters corresponding low/high residential and industrial densities be modified to correspond to the new categories?

[cenlinhe]

@cenlinhe What about URBPARM.TBL? Shouldn't those parameters corresponding low/high residential and industrial densities be modified to correspond to the new categories?

Sorry for the confusion. Yes, the parameters in URBPARM.TBL have already been modified to correspond to the new 11 LCZ categories. So if the user runs the default code, the model will use the default parameter values in URBPARM.TBL corresponding to the new 11 LCZ categories.

[weiwangncar]

@cenlinhe That's good. I missed it... But does this contradict to what you've added in PR:
(1) When a user uses the 31st-33rd classes, one could modify the URBPARM.TBL, in order to make the 3 urban classes correspondent to the correct LCZ urban parameters.

[cenlinhe]

@cenlinhe That's good. I missed it... But does this contradict to what you've added in PR:
(1) When a user uses the 31st-33rd classes, one could modify the URBPARM.TBL, in order to make the 3 urban classes correspondent to the correct LCZ urban parameters.

Thanks for catching this. I made the mistake to put "LCZ" in the "correct LCZ urban parameters". It should be "correct urban parameters". I will modify the PR message. The explanation is the following:
If a user still wants to keep using the traditional 33 classes (31st-33rd for urban) and only has a dataset with urban categories of 31-33, the code will still run. However, one has to relate the 31st-33rd classes to their respective parameters, because LCZ_1 that corresponds to LU_INDEX=31 in the current default parameter table does not correspond to the traditional LOW_DENSITY_RESIDENTIAL class (LU_INDEX=31 for traditional 33 classes). The LCZ_1 parameter in the current parameter table represents the HIGH_DENSITY_RESIDENTIAL CLASS. So when a user uses the traditional31st-33rd classes, one needs to modify the URBPARM.TBL in order to make the 3 urban classes correspondent to the correct urban parameters.

[weiwangncar]

@cenlinhe Thanks. This is information as much for the users as for us. Another question I have is how a user can find the dataset that defines the LCZs? Is the dataset readily available for anywhere?

[cenlinhe]

@cenlinhe Thanks. This is information as much for the users as for us. Another question I have is how a user can find the dataset that defines the LCZs? Is the dataset readily available for anywhere?

@weiwangncar I am not sure about this. I will ask Andrea Zonato and Fei.

[cenlinhe]

@cenlinhe Thanks. This is information as much for the users as for us. Another question I have is how a user can find the dataset that defines the LCZs? Is the dataset readily available for anywhere?

@weiwangncar I am not sure about this. I will ask Andrea Zonato and Fei.

@weiwangncar Confirmed with Fei about this. We provide only the LCZ modeling capabilities here, not the dataset which is the responsibility of users. The method to create the LCZ data is described in World Urban Database website: http://www.wudapt.org/
I will also include this in both README file and the PR message.

[weiwangncar]

@cenlinhe Thanks, and that would be good to provide the info.

[cenlinhe]

I am closing this PR, since an updated PR about this WRF-urban update has been submitted: #1385