Skip to content

Solweig_2026a default path: is the wave-delayed absolute Tg into gvf_2018a intended? #136

Description

@songololo

Hello, a question about the default path of Solweig_2026a_calc_forprocessing.py (groundScheme = 0, outgoingLW = 0), which seems to differ from 2025a in a way that may or may not be intended.

In 2025a, gvf_2018a receives the raw ground temperature deviation Tg, and TsWaveDelay_2015a is applied afterwards to the returned gvfLup* grids. Inside the GVF (sunonsurface_2018a) the emission is computed as:

Lup = SBC * emis_grid * (Tg * shadow + Ta + 273.15) ** 4 - ...

so it expects Tg to be a deviation from air temperature, with the shadow weighting applied internally.

In 2026a the wave delay is applied before the GVF, to the absolute temperature:

TgTemp = Tgdiff * shadow + Ta
_, timeadd, Tg = TsWaveDelay_2015a(TgTemp, firstdaytime, timeadd, timestepdec, Tg)

and this Tg (absolute, already shadow-weighted) is then passed to the unchanged gvf_2018a. The GVF then appears to add Ta a second time and apply the shadow factor a second time. At Ta = 20 °C that raises the emitting temperature by roughly 20 K, on the order of +100 W/m² in Lup for sunlit ground, relative to 2025a. Since this is the default branch, it affects runs that have not enabled the new ground scheme.

Is this restructuring intended (perhaps as groundwork for the scheme), or should the default path stay equivalent to 2025a? If the latter, restoring the 2025a ordering (pass Tgdiff to gvf_2018a, delay the returned gvfLup* grids) looks sufficient, and a PR is no problem. Apologies in advance if a compensating change elsewhere has been missed here.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions