Hello, first of all thank you for the 2026a ground-surface scheme — the force-restore/OHM formulation and the water slab are a clear step forward. The scheme has recently been ported to the solweig rust optimised package (https://github.com/UMEP-dev/solweig), and re-running that package's validation suite with the scheme enabled surfaced a systematic discrepancy against field measurements. This issue asks whether part of the radiation composition is intended.
Setup: the port matches this repository's implementation component by component (surfaceTemperature_calc, outgoingLongwave_calc, Lside_veg_v2026, and the Solweig_2026a_calc ordering are parity-tested against the upstream files), and as an end-to-end check this repository's Solweig_2026a_calc itself (unmodified, groundScheme = 1, outgoingLW = 1, isotropic) was run against the port on identical inputs over a full diurnal cycle: Tmrt agrees to within 0.08 °C for 22 of 24 hours (the two exceptions are sunrise/sunset transition hours with differing clearness-index handling in the drivers). The numbers below therefore reflect the scheme as published rather than the port.
Running with groundScheme = 1, outgoingLW = 1 and the anisotropic sky against measured Tmrt at three Gothenburg sites (Kronenhuset 2005-10-07, Gustav Adolfs torg 2005/2006, GVC 2010 — the Lindberg et al. validation datasets) gives a large one-directional warm bias: Tmrt RMSE 13 to 22 °C, bias +12 to +21 °C over seven site-days, where the 2025a formulation on the same inputs sits at 4 to 9 °C RMSE with small bias. Full tables: https://github.com/UMEP-dev/solweig/blob/main/VALIDATION.md (section "UMEP 2026a ground scheme (opt-in): field comparison").
The flux decomposition points away from the ground temperature model itself: Kdown, Kup and Ldown are essentially unchanged, and the scheme's Lup at the Kronenhuset station is closer to the measurements than 2025a (bias +0.3 vs +8.3 W/m²). The excess appears to enter through the directional side longwave composition:
- The march's
gvfLside* terms feed the cardinal directions (Fside term), replacing the 2022a Lup*0.5 ground term.
- In addition, 2026a computes
Lside = (Lsouth + Lnorth + Least + Lwest) / 4
...
Lside += Lside_
and uses this Lside in the Fcyl term of Sstr. In 2025a the Fcyl term used only the anisotropic-sky Lside_. Since the directional sums already enter Sstr through Fside, adding their mean to Fcyl seems to count the ground/wall side longwave twice.
An isotropic re-run at Kronenhuset (where the Fcyl longwave term is absent from Sstr) reduces the bias to +7 °C, consistent with point 2 accounting for roughly two thirds of the anisotropic-mode bias and point 1 (or parameters) for the rest.
Caveats: the site parameter files were extended with the default OHM and heat-capacity blocks (the site JSONs predate them), so a parameter mismatch cannot be fully excluded, and a misreading of the intended composition is of course possible.
Is the mean-of-directions term in Fcyl intended, and has the 2026a scheme been compared against measured Tmrt somewhere? The per-hour comparison tables and the harness are available if useful.
Hello, first of all thank you for the 2026a ground-surface scheme — the force-restore/OHM formulation and the water slab are a clear step forward. The scheme has recently been ported to the solweig rust optimised package (https://github.com/UMEP-dev/solweig), and re-running that package's validation suite with the scheme enabled surfaced a systematic discrepancy against field measurements. This issue asks whether part of the radiation composition is intended.
Setup: the port matches this repository's implementation component by component (surfaceTemperature_calc, outgoingLongwave_calc, Lside_veg_v2026, and the Solweig_2026a_calc ordering are parity-tested against the upstream files), and as an end-to-end check this repository's Solweig_2026a_calc itself (unmodified, groundScheme = 1, outgoingLW = 1, isotropic) was run against the port on identical inputs over a full diurnal cycle: Tmrt agrees to within 0.08 °C for 22 of 24 hours (the two exceptions are sunrise/sunset transition hours with differing clearness-index handling in the drivers). The numbers below therefore reflect the scheme as published rather than the port.
Running with groundScheme = 1, outgoingLW = 1 and the anisotropic sky against measured Tmrt at three Gothenburg sites (Kronenhuset 2005-10-07, Gustav Adolfs torg 2005/2006, GVC 2010 — the Lindberg et al. validation datasets) gives a large one-directional warm bias: Tmrt RMSE 13 to 22 °C, bias +12 to +21 °C over seven site-days, where the 2025a formulation on the same inputs sits at 4 to 9 °C RMSE with small bias. Full tables: https://github.com/UMEP-dev/solweig/blob/main/VALIDATION.md (section "UMEP 2026a ground scheme (opt-in): field comparison").
The flux decomposition points away from the ground temperature model itself: Kdown, Kup and Ldown are essentially unchanged, and the scheme's Lup at the Kronenhuset station is closer to the measurements than 2025a (bias +0.3 vs +8.3 W/m²). The excess appears to enter through the directional side longwave composition:
gvfLside*terms feed the cardinal directions (Fside term), replacing the 2022aLup*0.5ground term.and uses this
Lsidein the Fcyl term of Sstr. In 2025a the Fcyl term used only the anisotropic-skyLside_. Since the directional sums already enter Sstr through Fside, adding their mean to Fcyl seems to count the ground/wall side longwave twice.An isotropic re-run at Kronenhuset (where the Fcyl longwave term is absent from Sstr) reduces the bias to +7 °C, consistent with point 2 accounting for roughly two thirds of the anisotropic-mode bias and point 1 (or parameters) for the rest.
Caveats: the site parameter files were extended with the default OHM and heat-capacity blocks (the site JSONs predate them), so a parameter mismatch cannot be fully excluded, and a misreading of the intended composition is of course possible.
Is the mean-of-directions term in Fcyl intended, and has the 2026a scheme been compared against measured Tmrt somewhere? The per-hour comparison tables and the harness are available if useful.