Removing non doalb call of wrap_canopy_radiation for fates

[rgknox]

Description of changes

This reverts a previous change that enabled a call to fates' wrap_canopy_radiation and zenith angle updates when the doalb flag was false. The original implementation was (apparently) needed for elm-fates to enable branch type restart runs, but appears to be unnecessary for clm-fates. The previous code was causing problems for cam-fates coupled runs.

Specific notes

Contributors other than yourself, if any: @mvdebolskiy performed tests, @ekluzek and @mvertens provided consultation

CTSM Issues Fixed (include github issue #):
Fixes: #3043

Are answers expected to change (and if so in what way)? no expected changes

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

Does this create a need to change or add documentation? Did you do so?

Testing performed, if any:
(List what testing you did to show your changes worked as expected)
(This can be manual testing or running of the different test suites)
(Documentation on system testing is here: https://github.com/ESCOMP/ctsm/wiki/System-Testing-Guide)
(aux_clm on derecho for intel/gnu and izumi for intel/gnu/nag/nvhpc is the standard for tags on master)

so far: ERI_Ld10.f45_f45_mg37.I2000Clm50FatesCru.derecho_gnu.clm-FatesColdTwoStream and ERS_Ld3.f19_g17.I2000Clm50FatesCru.derecho_gnu.clm-FatesColdTwoStream

NOTE: Be sure to check your coding style against the standard
(https://github.com/ESCOMP/ctsm/wiki/CTSM-coding-guidelines) and review
the list of common problems to watch out for
(https://github.com/ESCOMP/CTSM/wiki/List-of-common-problems).

[mvdebolskiy]

I am testing this in coupled cases.
Also, I want to add a testmod for fates that includes DATM namelist changes same as clm6cam7LndTuningMode. But that can be a separate PR.

[mvdebolskiy]

Also, there is a need to not allow WARNING in the BalanceCheckMod when fates is on, since the solver there has a different tolerance.
Also in clm-fates interface you are passing non-downscaled short-wave, is there specific reason for this?

[rgknox]

@mvdebolskiy , non-downscaled shortwave could just be a a legacy issue, ie we've been using it before a downscale version became available, but I'm just guessing. It has been that way since fates was clm-ed. I suppose there is no reason to not use the most downscaled version possible, but would need to look into how the downscaling is done and what is the actual change of scales (or what subgrid variability is this covering) before I could weigh-in .

[mvdebolskiy]

The downscaling is just for hillslope hydrology, in general case it equals to greedcell one, so if there is a need to have fates compatible with it, than the column level, downscaled sw should be used, same way as column level coszen.

[ekluzek]

Yes, @mvdebolskiy is right, you should use downscaled...

The downscaling is just for hillslope hydrology, in general case it equals to gridcell one, so if there is a need to have fates compatible with it, than the column level, downscaled sw should be used, same way as column level coszen.

In columns where that don't have downscaling, they'll be identical, but you'll want it for those cases that do use it. So you should just always use the downscaled version.

Downscaling is also done for glaciers -- which doesn't apply to FATES. But, the point is -- you'll want it for any cases where it has been done.

[ekluzek]

I am testing this in coupled cases. Also, I want to add a testmod for fates that includes DATM namelist changes same as clm6cam7LndTuningMode. But that can be a separate PR.

I'd actually like to get this new testcase installed in this PR. Partially, so that we can show that the new test breaks without the change, and it passes with it. This should be easy enough to do. I don't think adding this test will slow this effort down enough that it can't be done now.