Energy imbalance over land per coupler diagnostics

[olyson]

According to coupler diagnostics, there is an energy imbalance in the land in which the land appears to be gaining heat at 0.07 W/m2 (0.25 W/m2 over land only) even when the land is spunup. Specifically, the energy imbalance is 0.0747 W/m2 over 139 years of the b.e20.B1850.f09_g17.pi_control.all.265 simulation.
This imbalance was confirmed to within 0.001 W/m2 by processing the CLM history file output from b.e20.B1850.f09_g17.pi_control.all.265 for the balance terms used by the coupler.
Offline CLM5 simulations indicate a similar imbalance.
CLM4 and CLM4.5 simulations indicate that the imbalance was introduced in CLM4.5, simulations with CLM4 balance to within 0.01 W/m2.
Further investigation indicates that the imbalance is due to interactions of snow with surface water and possibly with lakes. A bug fix for snow-surface water interactions has been proposed by S. Swenson and tested in a offline CLM simulation (/glade/p/work/oleson/clm4_5_17_r265/cime/scripts/clm50_r265_1deg_GSWP3V1_iso_400i_ccrit_nosubgrid_bugfix_1850pAD). This bug fix results in an imbalance of -0.01 W/m2 for a twenty year climatology.
A related bug fix is currently being tested which indicates that the imbalance increases again, and this remaining appears to be related to snow-lake interactions only. Investigation in progress.

[ekluzek]

@swensosc there's a potential divide by zero (and I've hit it in testing) in SoilTemperatureMod in the following code snippet...

!         dz_h2osfc(c) = max(1.0e-6_r8,1.0e-3*h2osfc(c))
!         c_h2osfc(c)  = cpliq*denh2o*dz_h2osfc(c) !"areametric" heat capacity [J/K/m^2]
!scs
         if (h2osfc(c) > 0._r8) then
            c_h2osfc(c)  = max(1.0e-6_r8,cpliq*h2osfc(c)/frac_h2osfc(c))
            dz_h2osfc(c) = max(1.0e-6_r8,1.0e-3*h2osfc(c)/frac_h2osfc(c))
         else
            c_h2osfc(c)  = 1.0e-6_r8
            dz_h2osfc(c) = 1.0e-6_r8
         endif
!scs

You check for h2osfc being small, but not the actual number that's the divisor -- frac_h2osfc. There's a few different ways this could be handled, check for them both at the same time, or have a more complex if statement.

It's also recommended that you don't check for greater than exactly zero, but some small value. Doing a check like this would be numerically safe...

`if (h2osfc(c) > epsilon(h2osfc(c)) ) then`

that would translate to about 1.e-15. But, from what you have, it seems like a threshold much higher than that would be appropriate here.

[ekluzek]

This was fixed in PR #307 that came in with development tag: clm5.0.dev003.