Suggested algebraic rework of frac_sno calculation

[billsacks]

The update of frac_sno to account for new snow looks like this:

https://github.com/ESCOMP/ctsm/blob/a87e67da23ab4c7e971351289dc051e2ebc5bf1c/src/biogeophys/SnowCoverFractionSwensonLawrence2012Mod.F90#L118-L120

I'm wondering if it would make sense to rewrite this as:

frac_sno(c) = frac_sno(c) + tanh(this%accum_factor * newsnow(c)) * (1._r8 - frac_sno(c))

I'm pretty sure that they do the same thing (though would love someone to double-check me on that), but I prefer the second form for two reasons:

1. It is easier to understand what it's doing: It's starting with the existing frac_sno, then adding some fraction of area that is currently represented by (1 - frac_sno). In the current formulation, I got very confused by the two leading 1 - terms.

2. The original form seems more sensitive to roundoff errors: If the tanh term is very small, note that the first expression results in frac_sno(c) = frac_sno(c), because 1 - tanh goes to 1 due to rounding error. The second expression is less sensitive to this roundoff-level issue. I particularly ran into this problem when trying a particular code refactoring (which I abandoned), when frac_sno was initially 0 and newsnow was very small: this should end up as frac_sno(c) = tanh(this%accum_factor * newsnow(c)), but due to rounding error, the original formulation gave exactly 0 in this case (causing a later divide by 0). (There may have been some other issue whereby newsno should have been truncated to 0 but wasn't.)

I wonder if we should change this... but I only want to do so if we're confident in the new form, because this will introduce answer changes and I want to be confident that this is truly just roundoff-level.

At the very least, I may want to add a comment to this effect.

However, before I either make the change or add a comment, I want feedback from @swensosc : Is there a reason why this is written the way it is? Do you have feelings on this proposed rewrite?

[swensosc]

It looks like an equivalent expression, so it would be okay to change. The argument for not changing is that the expression in the code is the result of the derivation in SL12 (eqn 3), which is the result of the probability based formulation. Maybe you could add a comment saying that it is equivalent to eqn 3 from SL12 when you change it.