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?