Soil temperature initialization not implemented correctly in ctsm5.1.dev058 and thus subsequent tags

[olyson]

Brief summary of bug

Soil temperature was intended to be initialized at 272K, replacing the previous setting of 274K, as described in issue #1460, but was not implemented correctly

General bug information

CTSM version you are using: ctsm5.1.dev058 (bug is in latest ctsm tag as well)

Does this bug cause significantly incorrect results in the model's science? Yes

Configurations affected: BGC

Details of bug

This issue here: https://github.com/ESCOMP/CTSM/issues/1460

requested a change of initial soil temperature from 274 to 272 in TemperatureType.F90. It looks like that was implemented as part of a bunch of small changes in Oct, 2021 through this pull request:

https://github.com/ESCOMP/CTSM/pull/1497/files

However, it looks like the wrong line was changed. The original issue #1460 describes the required change like this:

The code modification required is in TemperatureType.F90, changing this line:

this%t_soisno_col(c,1:nlevgrnd) = 274._r8

to this:

this%t_soisno_col(c,1:nlevgrnd) = 272._r8

See /glade/work/oleson/PPE.n08_ctsm5.1.dev023/cime/scripts/ctsm51c6_PPEn08ctsm51d023_2deg_GSWP3V1_Sparse400_cs_ts_tsoisno272_2000AD/SourceMods/src.clm/TemperatureType.F90

The code referred to here was correct, however, what ended up being changed as part of the combined PR was a different line of code that sets t_soisno for pervious and impervious road only, i.e.,

              if (col%itype(c) == icol_road_perv .or. col%itype(c) == icol_road_imperv) then
                 this%t_soisno_col(c,1:nlevgrnd) = 272._r8

Important output or errors that show the problem

We recently noted large deposits of deep soil carbon at high latitudes in recent simulations, which was a feature that the soil temperature change was intended to correct.

[wwieder]

This won't be b4b, but should it come in on a b4b-dev tag, or do we need to combine it with other answer changing tags? Also tagging @samsrabin and @adrifoster

[samsrabin]

b4b-dev merges should only include PRs from the b4b-dev branch, and PRs on that branch should always be bit-for-bit. As far as whether it needs its own tag on master or if it can be brought in with others, I think that's something we can assess once the PR fixing this issue is ready.

[ekluzek]

@olyson is running simulations to check on this.

[olyson]

The set of simulations described in https://github.com/NCAR/LMWG_dev/issues/45 are being repeated with this fix.