-
Notifications
You must be signed in to change notification settings - Fork 695
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Forcing and output in SLUCM: actual temperature or potential temperature #2093
Comments
We did some simulations using HRLDAS, and compare the diagnostic T2 of methods used by WRF and method that TH2_URB2D is considered as air temperature: xuelingbo/LSP-DS#5. |
Looks like based on @xuelingbo 's tests, for low-altitude cities, the difference is very small, but for high-altitude urban regions, the difference is huge (up to ~4 degC). My understanding is that TH2 inside urban module code is the actual 2-m air temperature instead of potential temperature. |
I guess some of the equations in SLUCM are required to use air temperature, so they probably made the assumption that air temperature is similar to the potential temperature in SLUCM. I will do a test case in a city for this modification. |
another question I had is Line 1678 in 0a11865
how about this line of the code, it was commented out, what is the difference between (CHS/CHS2) and (PSIT2/PSIT) |
@cenlinhe @tslin2 @xuelingbo I agree with @tslin2 on the use of potential temperature. However, the diagnostic potential temperature (TH2) basically denoted the compression/expansion effects due to pressure change and within 2m height ground from the ground, pressure change is assumed to be having no effect. In addition, diagnostic potential temperature is a reference temperature. @tslin2 There is a slight difference between PSIT and CHS variables if you go by their definition. PSIT I believe indicate the similarity function for the temperature whereas CHS denotes the exchange coefficient derived using those similarity functions. The exchange coefficient equation also include the urban roughness effects by including friction velocity in its definition hence, CHS appears to be a better option where both thermal and mechanical roughness impacts can be included while calculating the potential temperature. Let me know your views. |
@tslin2 @joshi994 I understand they probably made the assumption that air temperature is similar to the potential temperatur as 2m height is near the ground. But TA is actual temperature at 1st atmospheric layer (~30m), I am concerned if it's correct to use this assumption. |
This is not directly relevant, Lines 428 to 429 in 0a11865
U10, V10 should be INTENT(INOUT) due to the use for Calculating Wind Direction and Assign Appropriae lf_urb Line 710 in 0a11865
or use U1, V1 to calculate WDR |
@xuelingbo @joshi994 thanks for your views. @xuelingbo agree on your view to have a consistent method for Noah-MP and SLUCM, this can also be related to the potential comparison with the BEP method for T2 using potential temperature. @joshi994 the comment DanLi-BU#5 (comment) by @DanLi-BU somehow justify the use of CHS from the surface layer scheme that considers momentum and thermal roughness based on Noah-SLUCM. In that sense, should Q2 be calculated from CHS2 and CHS?, Line 1686 in 0a11865
due to Lines 1628 to 1629 in 0a11865
|
I did look into this issue a few months ago while I was writing a paper. Although I was not using Noah-MP (I was using Noah), I did spend sometime thinking about the calculation of T2. Noah SLUCMI'll start with Noah-SLUCM. In Noah-SLUCM, the TH2 computed by WRF/phys/module_surface_driver.F Lines 3000 to 3018 in 2e885eb
In other words, the T2 of urban grid cells is still computed by Noah-MP SLUCMNoah-MP does things differently. As @xuelingbo showed, T2 is computed as some sort of area-average: WRF/phys/module_surface_driver.F Lines 3382 to 3404 in 2e885eb
In this case, whether TH2 is an air temperature or potential temperature does make a difference. How TH2 is computed makes perhaps an even more important difference. Q1: is TH2 an air temperature or potential temperatureLong story short, it is an air temperature. So the (1.E5/PSFC(i,j))**RCP) correction in the above code (line 3392) is incorrect. More broadly, the use of air temeprature throughout Q2: how should T2 be diagnosed for a grid cell conceptualized as part of grass (handled by Noah or Noah-MP) and part of impervious land (handled by SLUCM)This is a bigger issue and I thought about it a lot. The challenge is associated with conceptualizing the atmospheric surface layer between the land surface and the 1st atmospheric level. One can think of two scenarios/approaches: 1) turbulence in the atmospheric surface layer is so mixed that all patches see one turbulent transfer coefficient and one flux, and 2) turbulence is isolated that different patches see different turbulent transfer coefficients and different fluxes. Both are consistent with the assumption that the 1st atmospheric model level receives the total flux, but they have vastly different implications for the temperature profiles in the atmospheric surface layer and thus TSK/T2. As far as I know, Noah-SLUCM uses the first approach. This is why TS and QS of the impervious patch are calculated using CHS which is a turbulent transfer coefficient computed outside of This also explains why T2/Q2 are computed by As far as I can see, Noah-MP-SLUCM diagnoses TSK in a similar way as Noah-SLUCM. In this case, Noah-MP-SLUCM has implicitly chosen the 1st approach. That being said, the area average of T2 is inconsistent with the spirit of the 1st approach. If we were to implement the 2nd approach say in Noah-MP, we would have to diagnose TS and T2 using the respective fluxes and transfer coefficients. To do so, we need to replace CHS and CHS2 in the calculation of TS and T2 in |
Thanks @DanLi-BU for comments, agree on the sensible heat of using potential temperature for SLCUM |
@DanLi-BU Thank you for your comments, I fully understand your discussion about how should we diagnostic T2 in Noah-MP-SLUCM. Just for reminder, in HRLDAS, |
A related issue is Q2. Regardless of whether CHS or PSIT should be used for Q2, the following statement: Line 1686 in 0a11865
should be written as
so that it is consistent with the 2-m air temperature calculation: Line 1685 in 0a11865
|
As @xuelingbo and @cenlinhe noted, the difference in H can become much bigger with increasing elevation. But to my knowledge, many UCMs still use air temperature to calculate sensible heat flux. I just did a quick search in Noah-MP. Interestingly, for sensible heat flux from the surface, it also uses surface temperature and air temperature (rather than potential temperature). See:
@cenlinhe Thoughts? |
@xuelingbo I took a quick look at the modifications in HRLDAS. You are right that this seems consistent with the second approach I described (diagnosing T2/TS for each patch separately and then aggregate them). However, the counter-argument is if so, then why don't we diagnose T2/TS for roof and canyon separately? Remember, in the current SLUCM, the fluxes from roof and canyon are calculated separately. In other words, the roof and canyon are treated as different patches. Another way of looking at this issue is to ask the question why is the calculation of CHS/CHS2 only dependent on Z0HC, or why is Z0HR playing no role in the calculation of CHS/CHS2? We are trying to diagnose a T2/TS for the entire impervious land which composes of a roof and a canyon, I can't think of a reason why Z0HC should be used to represent the heat transfer capability of the entire impervious land. Note here we are talking about heat transfer, not momentum transfer. Maybe the role of roof can be neglected for momentum transfer, but I'm not sure about heat transfer. I don't have good answers to these questions though :) |
@chenghaow I guess CHS/CHS2 are conductances, PSIT/PSIT2 are resistances. |
It appears that the only variable T3D is the actual temperature. TA is potential temperature. Rest of the variables such as TH2, TS, etc. calculated using TA are potential temperatures. T2 in surface_driver.F using TH2_URB2D is actual temperature. In the subsequent line/command (3393) TH2 is again converted to the potential temperature. Let's go by the definition of different temperature measures, in order to calculate the virtual potential temperature (TAV), the potential temperature is used. Hence TA has to be the potential temperature not the actual temperature. For simulations over Riyadh, if you do not consider TH2_URB2D as potential temperature, I believe you are then looking at potential temperature instead of actual temperature (which is T2). Line/command 587 in module_sf_noaddrv.F mentioned TH2_URB2D as potential temperature. @xuelingbo how did you modified the TH2_URB2D to actual temperature? Also, to calculate the Q2, I believe that @DanLi-BU explanation on using CHS from Noah for calculating the QS in SLUCM make sense as the pervious and impervious surfaces have their own contribution. Your views @cenlinhe, @tslin2 |
related to this, NCAR/hrldas#79 I did test this by uncomment Line 1689 in 0a11865
It did change the T2 results if using radiative temperature for TS; resulted in a higher temperature for both TS and T2. This method is more similar to the Noah-MP and BEP/BEM methods for calculating the TSK using the Stefan-Boltzmann law, but not exactly the same. NoahMP-SLUCM: NoahMP-BEP/BEM: |
@joshi994 I agree with you that SLUCM needs to use potential temperature in module_sf_urban.F, but current TA in SLUCM is read from WRF 1st layer actual atmospheric temperature (T3D/T_PHY), not potential temperature. So the codes need to read the TH_PHY, which is the potential temperature in WRF. Just need to use actual temperature for some calculations in SLUCM, which can be converted based on potential temperature. The potential temperature was used in BEP/BEM for sensible heat flux calculation as well and converted to actual temperature for other purposes, such as calculating saturated water vapor pressure. This involves another issue that @DanLi-BU and @chenghaow raised about the potential temperature in the Noah and Noah-MP. Previously, I did test it in a case using NoahMP-BEP by simply using the potential temperature to diagnose T2 for all grids, like BEP/BEM for T2 for urban grids in module_surface_driver.F, but this is an indirect way but not the best as Noah-MP used actual temperature, not potential temperature. I think using potential temperature is more suitable for urban models. WRF/phys/module_surface_driver.F Line 3413 in 0a11865
|
Actually, in my research (https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2023JD040531), for the TSK issue, I uncomment this line Line 1689 in 0a11865
Line 1685 in 0a11865
|
I digged deep into the governing flux-form equation that WRF solver solves. It appears that the output temperature form the WRF model itself is potential temperature and not the actual temperature. In addition, the WRF output list indicate that T2 is actual temperature (converted using the Clausius-clapeyron equation) and TH2 is infact potential temperature. Please refer to pages 8-9 (specifically eqs. 2.7-2.14 and the text in between. As per the govenering equations T3D = T (perturbation potential temperature) + Reference potential temperature, whereas t_phy is converted to physical/actual temperature by thermodynamics relations. For instance, t_phy is supplied in module SLAB but it is converted to potential temperature within the module following the use of potential temperature. However, when T3D is supplied directly, it is actually the potential temperature. Hence, there's a difference between T3D and T_PHY and WEF solves for potential temperature and actual/physical temperature is obtained later. |
@joshi994 , WRF/Registry/Registry.EM_COMMON Line 209 in 0a11865
but T3D is different from T, is T_PHY WRF/phys/module_surface_driver.F Line 3138 in 0a11865
|
I also looked into the "module_pbl_driver.F" (https://github.com/wrf-model/WRF/blob/master/phys/module_pbl_driver.F) where it says: however, when I looked into the YSU PBL scheme (module_bl_ysu.F), I found the following: |
In the forcing of
subroutine urban
, temperatureTA
is fromT3D
which is actual temperature:https://github.com/NCAR/noahmp/blob/848f54ad3d28c4303151fe5ad83724e232694422/drivers/wrf/module_sf_noahmpdrv.F#L3393
https://github.com/NCAR/noahmp/blob/848f54ad3d28c4303151fe5ad83724e232694422/drivers/wrf/module_sf_noahmpdrv.F#L3499
After passing
T3D
tosubroutine urban
,Firstly,
TS
is calculated according toTA
and sensible heat flux :WRF/phys/module_sf_urban.F
Line 1628 in 0a11865
Then,
TH2
is calculated according toTA
andTS
:WRF/phys/module_sf_urban.F
Line 1685 in 0a11865
According to these codes,
TA
,TS
, andTH2
should all be actual temperatures.But in the diagnostic 2m air temperature
T2
,TH2
is treated as 2m potential temperature:WRF/phys/module_surface_driver.F
Line 3392 in 0a11865
This seems somewhat inconsistent
Additionally, another inconsistent part is the comments for
TA
andTH2
, both of which indicate they are potential temperatures. :WRF/phys/module_sf_urban.F
Line 144 in 0a11865
WRF/phys/module_sf_urban.F
Line 195 in 0a11865
In
subroutine urban
,TA
is also used in the following codes, which I think actual temperature should be used:WRF/phys/module_sf_urban.F
Line 886 in 0a11865
WRF/phys/module_sf_urban.F
Line 1006 in 0a11865
WRF/phys/module_sf_urban.F
Line 1079 in 0a11865
WRF/phys/module_sf_urban.F
Line 1447 in 0a11865
WRF/phys/module_sf_urban.F
Line 1601 in 0a11865
The text was updated successfully, but these errors were encountered: