# Counter-intuitive T2 response to tree density under RSL method **URL:** \ **Category:** General\ **Created:** [30 August 2026 03:13 UTC](https://community.suews.io/t/counter-intuitive-t2-response-to-tree-density-under-rsl-method/155 "2026-08-30T03:13:09Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![HXban](https://avatars.discourse-cdn.com/v4/letter/h/e47774/32.png) [@HXban](https://community.suews.io/u/HXban)\ **Post date:** [30 August 2026 03:13 UTC](https://community.suews.io/t/counter-intuitive-t2-response-to-tree-density-under-rsl-method/155/1 "2026-08-30T03:13:09Z")
Hello, I’m running a tree density sensitivity analysis with rslmethod=1 and observing that 2m air temperature increases with tree density, which is physically counter-intuitive. Under rslmethod=0 (MOST), the trend for temperature is correct (more trees → lower T2). However, under MOST, wind speed increases with building density, which is physically incorrect. Therefore, I must use RSL method. My question is whether this is a known behavior of the RSL scheme when applied to vegetation, or if it indicates a limitation in how RSL handles trees. Are there any recommended parameter adjustments or configuration settings that could help resolve this issue? `FAI`: 0.01–0.4 (normal range for urban areas) SUEWS version: 2026.4.3 Thanks in advance for any guidance. ---
**Author:** ![Janka](https://avatars.discourse-cdn.com/v4/letter/j/df705f/32.png) [@Janka](https://community.suews.io/u/Janka)\ **Post date:** [31 August 2026 11:52 UTC](https://community.suews.io/t/counter-intuitive-t2-response-to-tree-density-under-rsl-method/155/2 "2026-08-31T11:52:43Z")
Hi, Just want to add that I have similar results in 2026.6.5 when modifying tree cover (and paved area cover) in Gothenburg, Sweden, summertime. With rlsmethod = 1, T2 increases with increasing tree cover. With rlsmethod = 0, there is hardly any response of T2 in my case. Curious to learn more about this! ---
**Author:** ![sunt05](https://dub1.discourse-cdn.com/flex014/user_avatar/community.suews.io/sunt05/32/5_2.png) [@sunt05](https://community.suews.io/u/sunt05)\ **Post date:** [2 September 2026 10:24 UTC](https://community.suews.io/t/counter-intuitive-t2-response-to-tree-density-under-rsl-method/155/3 "2026-09-02T10:24:39Z")
Thanks @HXban and @Janka. This is a known limitation rather than a misconfiguration, and the two observations, that MOST barely responds while RSL responds the “wrong” way, are two faces of the same design. I ran a small sweep on the bundled sample site (current development version; the diagnostic code in question is unchanged since 2026.4.3) to make sure I was describing what the code actually does rather than what I remembered. **Setup.** Sample London site (22 m buildings, forcing at 40 m), June to July 2012, deciduous tree fraction raised from 0.02 to 0.32 at the expense of paved, everything else unchanged. Numbers below are daytime (11 to 15 h) means. **Under MOST (`roughness_sublayer: most`).** T\_2 moves from 18.38 to 18.33 degC, so about 0.05 K for a 30 percentage-point increase in tree cover, even though Q\_H falls from 191 to 175 \mathrm{W\,m^{-2}} and Q\_E rises from 65 to 114 \mathrm{W\,m^{-2}}. The reason is where MOST samples “2 m”: at 2 m above the displacement height plus roughness length, z = 2 + z\_d + z\_{0m}, which on this site is about 18 m above ground. This is not a SUEWS quirk but the standard convention whenever MOST is used to diagnose screen-level values: the similarity profile only exists above z\_d + z\_{0m}, so “2 m” means 2 m above that reference surface. WRF’s surface-layer diagnostics and land-surface schemes such as CLM define their 2 m temperature the same way, relative to the roughness or displacement surface rather than the ground. At that height the profile is nearly well mixed and the surface signal is heavily damped. This is @Janka’s “hardly any response”. The same sampling rule is the likely explanation for the wind result @HXban mentions: under MOST, U\_{10} is read at 10 + z\_d + z\_{0m}, so if your roughness settings derive z\_{0m} and z\_d from morphology, denser or taller buildings push the sampling point upwards and the diagnosed “10 m” wind increases. That would be a reference-height artefact, not physics. It is worth checking against the `z0_RSL` and `zd_RSL` columns in your runs (in my sweep z\_{0m} and z\_d were held fixed, so this did not show). **Under RSL (`roughness_sublayer: rst`).** T\_2 is now read at a true 2 m above ground, inside the canopy, and it rises from 19.2 to 20.2 degC across the same sweep, not quite monotonically. Q\_H falls exactly as under MOST, so the fluxes are doing the right thing. What changes is the profile scaling. Trees enter the RSL scheme only through the bulk morphology (z\_H, plan and frontal area index, with a porosity weighting), and from those the scheme derives z\_0, z\_d and the in-canopy mixing length. In this sweep the effective roughness length falls from about 1.0 to 0.6 m and the friction velocity used for the heat profile from 0.59 to 0.50 \mathrm{m\,s^{-1}}, so the temperature scale T\_\* = -\frac{Q\_H}{\rho\, c\_p\, u\_\*} grows in magnitude even though Q\_H shrinks. The larger |T\_\*| together with the altered in-canopy profile shape gives a warmer 2 m value in unstable daytime conditions; the sweep cannot separate the two, but |T\_\*| tracks T\_2 in rank order across all four runs. Feeding T\_2 back into the surface scheme (`roughness_sublayer_level`) made no material difference; the effect is in the profile, not the energy balance. At night the RSL response is about a tenth of a degree and not monotonic, so the daytime numbers are the ones that matter for your sensitivity. **What this means physically.** SUEWS has no canopy-layer energy balance and no shading of the in-canopy air. Trees cool the surface energy balance by shifting Q\_H into Q\_E, and both schemes see that. But T\_2 is a flux-gradient diagnostic anchored at the forcing temperature above the canopy, so it only ever sees the tree effect through Q\_H and through the morphology-derived turbulence parameters, and under RSL the second of those can dominate the first. The sign you are seeing is therefore a real property of the current parameterisation, and we do not have a validated fix to offer for it today. **Practical suggestions.** - Treat T\_2 as a diagnostic, not as the quantity that measures tree cooling. Compare \Delta Q\_H, \Delta Q\_E and the surface temperature between scenarios first; these are where the vegetation effect actually lives in the model. - If the end goal is thermal comfort, mean radiant temperature is the quantity that responds to trees, because it carries their shading. SUEWS includes a one-dimensional descendant of SOLWEIG (BEERS) that writes T\_\mathrm{mrt} to the `BEERS` output group, but in that port the vegetation sky-view factor is fixed at 1, so tree shading is not represented there either. For tree scenarios use SOLWEIG in UMEP with a canopy DSM, driven by the SUEWS output. - When reporting T\_2 sensitivities, write out the `RSL` output group and look at `zH_RSL`, `PAI`, `z0_RSL`, `UStar_heat` and `TStar_RSL` alongside T\_2, so you can see whether a change is coming from the fluxes or from the morphology. - Keep the forcing height and the tree height consistent with the buildings; in the RSL scheme a tree fraction taller or shorter than the buildings changes z\_H directly. If either of you can share the Q\_H, u\_\* and z\_H columns from your runs, that would let us confirm the same mechanism is at work in your cases. Related: [How to best model within canyon air temperature](https://community.suews.io/t/how-to-best-model-within-canyon-air-temperature/34) and [Air temperature incomparable across MOST and RSL simulations](https://community.suews.io/t/air-temperature-incomparable-across-most-and-rsl-simulations/157)