Port soil color climatology prescription for Noah-MP from UFS to SHiELD

[spencerkclark]

Description

Previously in SHiELD the soil color category was uniformly set to 4 over all land surfaces when using Noah-MP (see here and where this variable is used downstream). This category corresponded to a surface with medium reflectivity, producing albedo biases that were most apparent over generally bright desert regions like the Sahara and Arabian Peninsula. This was already observed in the UFS and they addressed it by prescribing a spatially varying soil color from a climatology and updating the albedo table those categories correspond with. This PR ports the soil-color-related changes made in ufs-community/ccpp-physics#78 to SHiELD.

Appropriate soil color reference data on the cubed sphere can be generated using the sfc_climo_gen tool of UFS-UTILS with data from this NOAA bucket on S3.

@kaiyuan-cheng when you get a chance it would be great to get your review of this code.

cc: @lharris4

How Has This Been Tested?

I have tested this by running one month C24 simulations initialized on January 1st, 2020 from GFS analysis with prescribed observed sea surface temperatures and sea ice in three configurations:

• SHiELD-Noah—SHiELD with the Noah land surface model.
• SHiELD-Noah-MP (original)—SHiELD with Noah-MP with the code prior to this branch.
• SHiELD-Noah-MP (soil color)—SHiELD with Noah-MP with this branch and prescribed soil color data.

If we plot the difference in implied surface albedo compared with ERA5 reanalysis we find that SHiELD-Noah and SHiELD-Noah-MP have much smaller biases over the Sahara and the Arabian Peninsula.

I have also tested that the model restarts reproducibly by running a test that the model produced bitwise identical restart files after 12 hours in simulations configured to run in one segment of 12 hours or two segments of 6 hours. To achieve this I needed to make sure to write the soil color variable out to sfc_data restart files and load it in from disk upon restart like other Noah-MP-relevant fields.

Finally, I have tested that one can initialize SHiELD-Noah-MP from a set of restart files generated with SHiELD-Noah without the model crashing. The model will start with a default uniform soil color of 4 and then take on the prescribed soil properties at the next cycling interval.

Checklist:

Please check all whether they apply or not

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[spencerkclark]

One case I have not tested is warm-starting from restart files that do not include an scolor variable, e.g. branching a run with Noah-MP off of restart files from a run done with Noah. I think an additional small change may be needed there, which I'll look into tomorrow.

[spencerkclark]

1138dad addresses the use case of initializing SHiELD-Noah-MP from restart files generated with SHiELD-Noah. Note that it provides a default value for the soil color over land, which will get overridden by the soil color from the provided climatology at the next cycling interval.

I think we can discuss the default value to use—I am using 4 here following what is done in the UFS if no soil color data is provided, but with the updated albedo table this now corresponds with an albedo on the brighter side of average (e.g. 0.20 vs. 0.09 previously for the visible saturated soil albedo). But maybe we are not so concerned about this, since running with Noah-MP without a soil color dataset is likely unadvised regardless of the choice we make for the uniform default.

[kaiyuan-cheng]

Hi, @spencerkclark . This is great. This aligns with what I have been doing: fixing the inconsistency in the Noah-MP driver and initialization. I appreciate that you carefully examined changes from outside and modified our codes. The modifications you made look good and this code runs without issues.

[lharris4]

This looks good, thanks for getting this in so quickly. It looks like nearly all of the code is for the challenging task of getting the dataset to be properly read and saved by the model.

[lharris4]

@spencerkclark thanks for plumbing the depths of this difficult code.

[spencerkclark]

Thanks @lharris4 and @kaiyuan-cheng!