Set initial t_soisno=272 for soils and 274K for urban road

[olyson]

Description of changes

Set initial t_soisno=272K for soils and 274K for urban road

Specific notes

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. Instead urban road was set to 272K and soils were unchanged.

Contributors other than yourself, if any: @wwieder @dlawrenncar

CTSM Issues Fixed (include github issue #): #2338

Are answers expected to change (and if so in what way)? Yes. Less soil carbon at high latitudes. See here for a set of simulations evaluating this: NCAR/LMWG_dev#45

Any User Interface Changes (namelist or namelist defaults changes)? No

Testing performed, if any:
No system testing performed yet.

[wwieder]

Thanks for correcting this @olyson

[ekluzek]

@slevis-lmwg will add this to a merge-tag for answer changes to come in right away.

[slevis-lmwg]

Link to discussion of the problem.

[olyson]

I have added a use_fates that encompasses the code in question as suggested by @wwieder in issue #2373 . The test now passes. However, a couple of questions.

1. The setting of t_soisno to 5deg below the freezing temperature when excess_ice is on is outside of the use_fates check and so if the test is changed so that excess_ice is on ( the current default is off), this test will fail (confirmed). I'm not sure what the future plans for excess_ice are and if it is intended for use with FATES.
2. There is an indication from the excess_ice PR (Adding excess ground ice to CTSM  #1787) that it might be ok to set the initial soil temperature to 272K instead of tfrz-5. This would simplify the code, particularly if we want to run FATES with excess_ice on. "src/biogeophys/TemperatureType.F90 -- initial soil temperature set to 268.15 K at the cold start (might be redundant if Initialize t_soisno to 272K instead of 274K to avoid deep soil carbon in permafrost regions #1460 is added)"

[olyson]

Per the discussion at CTSM software meeting, my understanding is that we will not put in a use_fates statement and will simply mark the test as an expected fail. This will be revisited once #2384 is resolved. Also, @olyson will test a potential fix from @rgknox from the FATES side.

[olyson]

I've backed out the use_fates change and added the FATES test as an expected failure. I ran the full test suite on both derecho and izumi to make sure there weren't any other problems. All tests PASSed or FAILed as expected.

[ekluzek]

Looks great.

@olyson is this ready to come to master then?

[olyson]

Yes, I believe it is ready, thanks.

[slevis-lmwg]

I'm about to merge to dev170 and then start the test-suites.

@olyson if you have 5', please look over the ChangeLog that I put together for dev171. It's ok if not.

Test-suites:
cheyenne IN PROGRESS here /glade/work/slevis/git/latest_master/tests_0301-155329de
izumi DIFF (expected)

[olyson]

Looks good other than see my comment about summarizing changes to answers, thanks.