ESCOMP / ESCOMP/CTSM

Thawed wetlands should result in a complete removal of the snow pack

Open
#735 13 comments 0 reactions 0 assignees View on GitHub
bug priority: low science
Dominant language
Fortran
Stars
352
Forks
361
Avg merge
2d 21h
Merged PRs (30d)
7

Description

I'm not sure if this is actually a bug, but it at least is a source of confusion (for me anyway):

#### The problem

https://github.com/ESCOMP/ctsm/blob/6a7fed208cabe43a9afd34d4ec9bb44724f9508f/src/biogeophys/SnowHydrologyMod.F90#L484-L487

The problem here is that h2osno is set to 0 regardless of the number of snow layers, but h2osoi_liq and h2osoi_ice are *not* set to 0. From tracing the code logic, and from an experiment where I have verified this, it looks like, for snow packs with explicit snow layers, this setting of h2osno to 0 does not actually set the snow pack to 0: h2osno is reset to the sum of h2osoi_liq+h2osoi_ice in the snow pack later in the time step, and so returns to its previous value (or at least something close to it).

So the effect of this code is just to set very small (0-layer) snow packs to 0 when wetland t_grnd goes above freezing. I'll assume for the moment that the intention matches this actual behavior (though I'm not sure if that's right). But in that case, there are inconsistencies for part of the time step between h2osno/snow_depth (both 0) vs. h2osoi_liq, h2osoi_ice and other snow variables (which may indicate a non-zero, multi-layer snow pack). I can't tell if this causes any actual problems now, or if this is just a source of confusion and possible future problems.

#### My proposed solution

I propose adding a conditional here to make explicit that this setting to 0 only takes effect if we have a very small snow pack. i.e., adding an `if (snl(c) == 0)` conditional around this resetting.

(Then, connected with the changes for #733 , I would just set `h2osno_unresolved` to 0, rather than setting `h2osno_total` to 0; `h2osno_total` would be updated accordingly soon afterwards.)

#### Testing I have done

I ran a one-year, one-degree test (`SMS_Ly1.f09_g17.I2000Clm50SpGs.cheyenne_intel.clm-monthly`) from ctsm1.0.dev042. I generated baselines from master, and added a write statement to diagnose the number of times this resetting is triggered. This did 5422 resets to 0 when h2osno_col was not 0 to begin with. Of these, there were 487 times when snl < 0.

I then ran a second version of this test where I only did the resetting if `snl(c) == 0`, as proposed above. This was bit-for-bit with the original test.

Then, in case this test was missing some rare situation where this logic changes behavior, I also ran a paired set of tests where, for both, I did the resetting regardless of temperature. With that change, answers differed depending on whether I did the reset to 0 only when snl==0 vs. doing the reset to 0 regardless of snl. I'm not sure if this suggests that there are rare circumstances where my proposed logic changes answers, or if this only tells us that answers would change if we did the resetting for below-freezing t_grnd – but as long as we only do it for above-freezing t_grnd, my proposed change is bit-for-bit.

#### Request for feedback

@swensosc - can you please let me know if my proposed change sounds good to you?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.