Thanks Zijin — sharing the YAML files made this much easier to investigate. Your counterintuitive T2 warming turns out to be a real numerical issue in the Roughness Sub-Layer (RSL) profile diagnostic, not a mistake on your end, and the good news is that it has already been fixed in a newer release.
How we tested it
We loaded both of your configurations (base and 30% evergreen trees) in supy 2026.1.28 — your version — and drove them with identical meteorological forcing. We did not have your Manila forcing file, so we used the SUEWS built-in sample forcing (a temperate London-like site, summer 2012) for the test. This means the absolute T2 magnitudes we quote below will differ from yours, but the mechanism and the fix are independent of the forcing because the issue is driven by site morphology, not meteorology.
What we reproduced
With the temperate sample forcing, your base vs tree30 comparison showed the same counterintuitive sign as you reported: roughly +0.6°C warming in the summer mean and up to +1.4°C at midday when tree cover is increased. The energy fluxes themselves moved the expected way — QH dropped by about 58 W/m² and QE rose by about 50 W/m² — which made the T2 sign all the more puzzling.
Root cause
The issue sits in how SUEWS diagnoses 2 m air temperature through the RSL profile. With your base configuration (sparse 4.76 m buildings, essentially no trees), the site-total Frontal Area Index (FAI) is very small — effectively near zero — while the Plan Area Index (PAI ≈ 0.16) is just above the threshold that activates the RSL path. In that low-FAI regime, the RSL parameter solver (based on Harman & Finnigan 2008) becomes ill-conditioned and produces physically impossible roughness values for the base case:
z0_RSL ≈ 12.5 m — larger than the 4.77 m canopy height itselfLc ≈ 1905 m, elm ≈ 467 m — mixing length orders of magnitude too large
So your tree30 result is fine, but your base result is corrupted, and the A–B comparison shows spurious warming. You can confirm this locally by re-running the base case with rslmethod = 0 (force MOST instead of RSL). In our test the sign flipped and the comparison showed the expected cooling from adding trees.
The real fix: upgrade to supy 2026.4.3
Between 2026.1.28 and 2026.4.3, three relevant commits added numerical guards to the RSL chain:
- Fix division-by-zero pitfalls in RSL/resistance chain (#1229)
- Fix interpolation bounds error in RSL profiles (#1228)
- Compute c2m/c2h dynamically from HF08 RSL theory (#1116)
We verified with Guo-matched site parameters in 2026.4.3: the same low-FAI configuration now yields sensible roughness (z0 ≈ 0.64 m, elm ≈ 1.36 m), and the T2 response to adding 30% evergreen trees becomes a physically sensible cooling rather than warming.
Recommended action
pip install --upgrade supy==2026.4.3
Then re-run your two cases with your Manila forcing and no other changes. If you still see anything odd after upgrading, please post the new outputs here and we will take another look. We will also use this case as a test example in the docs — it is a nice illustration of why RSL diagnostics need defensive numerics at the edges of their applicability domain.
One small housekeeping point: your two YAML files point to different forcing file paths (Manila.txt vs Manila1.txt). That is worth double-checking on your side — any difference in the meteorological forcing between the two runs would mix into the T2 signal and confuse interpretation.