Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Threshold for explicit snow pack initiation should use frac_sno_eff, not frac_sno #785

Closed
billsacks opened this issue Aug 9, 2019 · 2 comments
Assignees
Labels
type: bug something is working incorrectly

Comments

@billsacks
Copy link
Member

Brief summary of bug

The threshold for snow pack initiation is currently based on frac_sno(c)*snow_depth(c). It seems this should actually be frac_sno_eff(c)*snow_depth(c)

General bug information

CTSM version you are using: ctsm1.0.dev055 (but also present in earlier versions)

Does this bug cause significantly incorrect results in the model's science? No

I believe this just affects (a) runs with use_subgrid_fluxes = .false. (NOT the default); (b) urban points in all runs. (For runs with use_subgrid_fluxes = .true., columns other than urban and lake have frac_sno == frac_sno_eff; the code in question doesn't operate over lakes, so I think this just affects urban points.) The impact should be fairly small in both cases, since this just changes the timing of when an explicit snow pack is initiated, rather than using an unresolved (0-layer) snow pack.

However, this bears further investigation.

Configurations affected: I think this just affects (a) runs with use_subgrid_fluxes = .false. (NOT the default); (b) urban points in all runs.

Details of bug

This is the code in question:

https://github.com/ESCOMP/ctsm/blob/a87e67da23ab4c7e971351289dc051e2ebc5bf1c/src/biogeophys/SnowHydrologyMod.F90#L746-L751

Based on other, similar code – particularly in CombineSnowLayers – I think frac_sno should actually be frac_sno_eff here. @swensosc agrees.

@billsacks billsacks added the type: bug something is working incorrectly label Aug 9, 2019
@billsacks billsacks self-assigned this Aug 9, 2019
@billsacks billsacks added this to In progress in Water isotopes Aug 9, 2019
@billsacks
Copy link
Member Author

I have confirmed that, as expected, in a case with use_subgrid_fluxes = .true. (the default), this fix only changes answers for urban landunits.

I confirmed this by running SMS_D_Ld1_P4x1.f10_f10_musgs.I2000Clm50BgcCropQianRsGs.bishorn_gnu.clm-default before and after the fix, with vector output for the h0 file. I examined the landunits for which FSH differs in this test, and found that it was just landunits 7, 8 and 9.

@billsacks
Copy link
Member Author

And also as expected: in a case with use_subgrid_fluxes = .false., differences are more wide-spread - i.e., across more landunits. (Confirmed via SMS_D_Ld1_P4x1.f10_f10_musgs.I2000Clm45BgcCropQianRsGs.bishorn_gnu.clm-no_subgrid_fluxes with vector output: there are diffs for landunits 1, 2, 4, 8 and 9.)

@billsacks billsacks moved this from In progress to Done but not on master in Water isotopes Aug 16, 2019
Water isotopes automation moved this from Done but not on master to Done Aug 20, 2019
billsacks added a commit that referenced this issue Aug 20, 2019
Fix frac_sno bugs

Two bug fixes related to frac_sno, and a third change involving
replacing a frac_sno calculation with a simpler equation that is
algebraically equivalent:

(1) Fix lake frac_sno always being 0
    (#783). This fixes the albedo
    calculation (and possibly others) over snow-covered lake surfaces.

(2) Fix threshold for explicit snow pack initiation to use frac_sno_eff,
    not frac_sno (#785). For
    standard runs (which have use_subgrid_fluxes = .true.), this just
    changes answers for urban columns. This also changes answers more
    widely for runs with use_subgrid_fluxes = .false.

(3) Rewrite Swenson & Lawrence 2012 frac_sno equation to be more
    straightforward and less sensitive to roundoff errors
    (#784)

- Resolves #783 (frac_sno is always 0 for lake points)
- Resolves #785 (Threshold for explicit snow pack initiation
  should use frac_sno_eff, not frac_sno)
- Resolves #784 (Suggested algebraic rework of frac_sno
  calculation)
slevis-lmwg pushed a commit to slevis-lmwg/ctsm that referenced this issue Aug 21, 2019
Fix frac_sno bugs

Two bug fixes related to frac_sno, and a third change involving
replacing a frac_sno calculation with a simpler equation that is
algebraically equivalent:

(1) Fix lake frac_sno always being 0
    (ESCOMP#783). This fixes the albedo
    calculation (and possibly others) over snow-covered lake surfaces.

(2) Fix threshold for explicit snow pack initiation to use frac_sno_eff,
    not frac_sno (ESCOMP#785). For
    standard runs (which have use_subgrid_fluxes = .true.), this just
    changes answers for urban columns. This also changes answers more
    widely for runs with use_subgrid_fluxes = .false.

(3) Rewrite Swenson & Lawrence 2012 frac_sno equation to be more
    straightforward and less sensitive to roundoff errors
    (ESCOMP#784)

Addressed conflicts in /doc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug something is working incorrectly
Projects
Development

No branches or pull requests

1 participant