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

Actual location information within module_sf_bep_bem.F

J

JasonWok

New member
Hello Community,

Git code permalink: https://github.com/wrf-model/WRF/bl...f1990e45a0aef8/phys/module_sf_bep_bem.F#L1712

I'd like to add my customized subroutine here.
How can I get related information?
Code: 
subroutine my(if_finest_domain,latitude, longitude, current_time)

! if_finest_domain is the boolean of finest domain, true or false
! latitude
! longitude
! current_time is the current simulateing time, such as 2002-10-01-00:06:12

I was able to get some related information. But I still don't know:
1. How to differentiate between coare and fine domain callings?
2. How to get the actual location (especially longitude)?

Bash: 
Timing for main: time 2023-05-01_00:06:00 on domain   4:    0.01925 elapsed seconds
Timing for main: time 2023-05-01_00:06:00 on domain   3:    0.15448 elapsed seconds
Timing for main: time 2023-05-01_00:06:00 on domain   2:    0.59661 elapsed seconds
Timing for main: time 2023-05-01_00:06:00 on domain   1:    1.94261 elapsed seconds
 calling spawn_children() counts:        1373 curix          14 curiy           6 curibui           1 curitime           3
 calling spawn_children() counts:        1374 curix          14 curiy           6 curibui           2 curitime           3
 calling spawn_children() counts:        1375 curix          17 curiy           1 curibui           1 curitime           7
 calling spawn_children() counts:        1376 curix          17 curiy           1 curibui           2 curitime           7
 calling spawn_children() counts:        1377 curix          17 curiy           3 curibui           1 curitime           7
 calling spawn_children() counts:        1378 curix          17 curiy           3 curibui           2 curitime           7
 calling spawn_children() counts:        1379 curix          21 curiy           1 curibui           1 curitime           7
 calling spawn_children() counts:        1380 curix          21 curiy           1 curibui           2 curitime           7
 calling spawn_children() counts:        1381 curix          13 curiy          13 curibui           1 curitime          19
 calling spawn_children() counts:        1382 curix          13 curiy          13 curibui           2 curitime          19
 calling spawn_children() counts:        1383 curix           5 curiy           6 curibui           1 curitime          55
 calling spawn_children() counts:        1384 curix           6 curiy           6 curibui           1 curitime          55
 calling spawn_children() counts:        1385 curix           6 curiy           6 curibui           2 curitime          55
 calling spawn_children() counts:        1386 curix           6 curiy           7 curibui           1 curitime          55
 calling spawn_children() counts:        1387 curix           8 curiy           7 curibui           1 curitime          55
 calling spawn_children() counts:        1388 curix           9 curiy           5 curibui           1 curitime          55
 calling spawn_children() counts:        1389 curix           9 curiy           5 curibui           2 curitime          55
 calling spawn_children() counts:        1390 curix           9 curiy           6 curibui           1 curitime          55
 calling spawn_children() counts:        1391 curix           9 curiy           6 curibui           2 curitime          55
 calling spawn_children() counts:        1392 curix           9 curiy           7 curibui           1 curitime          55
 calling spawn_children() counts:        1393 curix           9 curiy           7 curibui           2 curitime          55
 calling spawn_children() counts:        1394 curix           9 curiy           8 curibui           1 curitime          55
 calling spawn_children() counts:        1395 curix           9 curiy           8 curibui           2 curitime          55
 calling spawn_children() counts:        1396 curix          10 curiy           5 curibui           1 curitime          55
 calling spawn_children() counts:        1397 curix          10 curiy           5 curibui           2 curitime          55
 calling spawn_children() counts:        1398 curix          10 curiy           6 curibui           1 curitime          55
 calling spawn_children() counts:        1399 curix          10 curiy           6 curibui           2 curitime          55
 calling spawn_children() counts:        1400 curix          10 curiy           7 curibui           1 curitime          55
 calling spawn_children() counts:        1401 curix          10 curiy           8 curibui           1 curitime          55
 calling spawn_children() counts:        1402 curix          10 curiy           8 curibui           2 curitime          55
 calling spawn_children() counts:        1403 curix          11 curiy           6 curibui           1 curitime          55
 calling spawn_children() counts:        1404 curix          11 curiy           8 curibui           1 curitime          55
 calling spawn_children() counts:        1405 curix          11 curiy           8 curibui           2 curitime          55
 calling spawn_children() counts:        1406 curix          12 curiy           8 curibui           1 curitime          55
Timing for main: time 2023-05-01_00:06:06 on domain   4:    0.01981 elapsed seconds
 
Last edited:
Please see my answers below:
1. How to differentiate between coare and fine domain callings?
The physics is always the same for parent and child domain. WRF doesn't distinguish parent and child domain in physics module.
2. How to get the actual location (especially longitude)?
The variables xlat and xlong can be passed to physics module. Please see the example in phys/module_radiation_driver.F, where you can find that the lat/lon information are passed to the subroutine and used later in various radiation schemes.
 
Ming Chen said:
Please see my answers below:
1. How to differentiate between coare and fine domain callings?
The physics is always the same for parent and child domain. WRF doesn't distinguish parent and child domain in physics module.
2. How to get the actual location (especially longitude)?
The variables xlat and xlong can be passed to physics module. Please see the example in phys/module_radiation_driver.F, where you can find that the lat/lon information are passed to the subroutine and used later in various radiation schemes.
Click to expand...
Thanks for your reply!

I have one follow-up question: Different building types in one urban class related to `sf_urban_physics =3`.


Bash: 
 calling spawn_children() counts:        1388 curix           9 curiy           5 curibui           1 curitime          55
 calling spawn_children() counts:        1389 curix           9 curiy           5 curibui           2 curitime          55

Does the above mean that at same physical location (curix, curiy) we can have more than one building types (curibui =1 or 2)?
I'm using `cglc_modis_lcz+default` static geography data. In which part of the WPS-WRF simulation, will determine the number of building types in one urban class?
 
Hi,
If you look at URBPARM.TBL, for each urban class, there is a probability distribution of multiple building types which are specified as:
----
BUILDING HEIGHTS: 1
# (sf_urban_physics=2,3)

# height Percentage
# [m] [%]
5.0 15.0
10.0 70.0
15.0 15.0
END BUILDING HEIGHTS

BUILDING HEIGHTS: 2
# (sf_urban_physics=2,3)

# height Percentage
# [m] [%]
5.0 0.0
10.0 20.0
15.0 60.0
20.0 20.0
END BUILDING HEIGHTS

BUILDING HEIGHTS: 3
# (sf_urban_physics=2,3)

# height Percentage
# [m] [%]
5.0 0.0
10.0 0.0
15.0 10.0
20.0 25.0
25.0 40.0
30.0 25.0
35.0 0.0
END BUILDING HEIGHTS
-----

Inside the bep_bem code, this information is read in and stored in the following variable:
ss_urb(nz_um,nurbm) ! The probability that a building has an height equal to "z"

Hope this is helpful for you.
 
Ming Chen said:
Hi,
If you look at URBPARM.TBL, for each urban class, there is a probability distribution of multiple building types which are specified as:
----
BUILDING HEIGHTS: 1
# (sf_urban_physics=2,3)

# height Percentage
# [m] [%]
5.0 15.0
10.0 70.0
15.0 15.0
END BUILDING HEIGHTS

BUILDING HEIGHTS: 2
# (sf_urban_physics=2,3)

# height Percentage
# [m] [%]
5.0 0.0
10.0 20.0
15.0 60.0
20.0 20.0
END BUILDING HEIGHTS

BUILDING HEIGHTS: 3
# (sf_urban_physics=2,3)

# height Percentage
# [m] [%]
5.0 0.0
10.0 0.0
15.0 10.0
20.0 25.0
25.0 40.0
30.0 25.0
35.0 0.0
END BUILDING HEIGHTS
-----

Inside the bep_bem code, this information is read in and stored in the following variable:
ss_urb(nz_um,nurbm) ! The probability that a building has an height equal to "z"

Hope this is helpful for you.
Click to expand...


Thank you Ming for your insightful reply!
My static geog data is cglc_modis_lcz+default, and its resolution is 100m, link, which contains 11 urban land types, and is highly related with URBPARM_LCZ.TBL.

My nested domain resoutions are [m]: 30000, 10000, 3000, 1000.
In which part, WPS-WRF will determine(maybe aggregation?) the urban class from 100m resolution input static geog data to computation resoution (such as 30000m or 3000m)? For example, curix=17,curiy=1 for nested domain 2 with resolution 10000m
 
WPS/GEOGRID will read the static data, then produce the landuse type based on "interp_option" specified in GEOGRID.TBL. For the LCZ data, the default option is "interp_option = lcz_new:nearest_neighbor", I suppose the urban type in the coarse grid will be derived from the grid of fine-resolution data that is closest to the center of the coarse grid.
 
Ming Chen said:
WPS/GEOGRID will read the static data, then produce the landuse type based on "interp_option" specified in GEOGRID.TBL. For the LCZ data, the default option is "interp_option = lcz_new:nearest_neighbor", I suppose the urban type in the coarse grid will be derived from the grid of fine-resolution data that is closest to the center of the coarse grid.
Click to expand...
Thank you.
I have another follow-up question about the unit of sensible heat emitted outside the building [W].

Lets take example from one finest domain calling.

Bash: 
 calling spawn_children() counts:        1388 curix           9 curiy           5 curibui           1 curitime          55
The domain size is 1000 m by 1000 m.
The building type is defined in LCZ_1, with building_width= 12m, street_width=15m.
The calculated building sensible heat unit is W, based on the tiny building footprint area 12 * 15 = 180 m^2. (This 180 m2 is pretty small compared with the grid size 1,000,000 m2), WRF/phys/module_sf_bem.F at 21c72141142fc6c8d203d2bf79f1990e45a0aef8 · wrf-model/WRF.
In which part of WRF, will there be normalize the 180 m2 building heat into 1000,000 m2 urban grid heat?
 
Please take a look at the code module_sf_bem.F and module_surface_driver.F to find the answer. Note that we cannot provide detailed line-to-line code explanation due to limited human power and resources.
 
You must log in or register to reply here.
Top