Determination of htvp looks wrong
- Dominant language
- Fortran
- Stars
- 352
- Forks
- 361
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 7
Description
The setting of htvp looks wrong to @swensosc @dlawrenncar and me:
https://github.com/ESCOMP/ctsm/blob/ed893b4aae22ed7fd7e231a18678853ef45772a0/src/biogeophys/CanopyTemperatureMod.F90#L409-L410
Although consistent with the tech note, this looks wrong, scientifically: Why should this only use hsub if there is exactly 0 liquid water? And shouldn't this really use some weighted average of hvap and hsub depending on the actual balance of evaporation vs. sublimation? We haven't taken the time to fully understand what's going on, but it looks like this could be wrong, and could even be a source of energy conservation errors.
@swensosc thought there might be a more significant issue here, because he thought liquid water might never quite go to zero. But based on a 1-day average history file (generated with `SMS_D_Ld1_P4x1.f10_f10_musgs.I2000Clm50BgcCropQianRsGs.bishorn_gnu.clm-default`, with mods to output a new HTVP history field), I see that htvp is sometimes set to `hsub` rather than `hvap` (in particular, in the higher latitudes, where this would be expected). But the above issue still potentially stands.
Note that hvap = 2.501e6, whereas hsub = 2.835e6 - so there isn't a *huge* difference.
Contributor guide
Assessment
This issue has not been assessed yet.