billsacks
commented
5 years ago Incidentally, this block of code feels out of place here (in the HandleNewSnow routine). I thought about moving it to some later part of the driver loop – such as somewhere that deals with the effect of temperature on the snow pack. However, moving it would almost certainly change behavior: the code immediately following this block is:
which initiates an explicit snow layer if we previously had 0 snow layers but now we have accumulated enough snow to warrant a new layer. If we moved the wetland code to later, I think behavior would be changed in situations where we started the time step with 0 layers then added enough snow to have an explicit layer, with t_grnd > tfrz over wetland:
-
With the current code, h2osno and snow_depth are set to 0 in this case, and a new snow layer is not initiated
-
If we moved the wetland code to later, a new snow layer is initiated. Because we now have mass in
h2osoi_ice(c,0), the resetting of h2osno wouldn't accomplish anything (as noted above), so we will have initiated a new snow layer.
Maybe such a move is still the right thing to do, but I'd like feedback from others before doing that.
adamrher
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_unresolvedto 0, rather than settingh2osno_totalto 0;h2osno_totalwould 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?