Only reset snow north of 45N and between 100W - 0W

[billsacks]

Description of changes

Similar to #3036 , this is a draft that I'm opening to document this change that may be used in a CESM3 test run. This currently hard-codes a region for snow resetting. But, if desired, we could implement namelist variables to give a bounding box for snow resetting - though my feeling is that that probably is not worth doing.

Specific notes

Contributors other than yourself, if any:

CTSM Issues Fixed (include github issue #):

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

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:
SMS_D_Ld3_P8x1.f10_f10_mg37.I2000Clm50BgcCropQianRs.green_gnu.clm-default with reset_snow = .true. and reset_snow_glc = .true.: passes; manual inspection of SNOW_DEPTH suggests this new code is working as intended

[wwieder]

Seems like we're going to have this featured enabled for future CESM runs. I wonder if we should merge it to main?

[billsacks]

This will take some more work before it can be merged. @ekluzek and I discussed a few possible levels of generality... in increasing order from easiest / least general to hardest / most general:

(1) Keep the bounding box hard-coded but introduce a new namelist flag that dictates whether to apply the reset_snow flags globally or over this hard-coded bounding box... ugly, but fairly quick to implement.

(2) Introduce namelist options that specify the bounds of this bounding box, for a single bounding box. We're lucky in this case that the bounding box doesn't cross the 0° longitude line, so we can get away with a single bounding box.

(3) Allow even more generality for the case where the desired bounding box crosses 0° longitude.

Some discussion is needed to decide which approach to take, and even within one of these approaches, exactly what the user interface should look like. For example, do we want a new flag that selects between applying these two reset_snow flags globally vs. over a bounding box but then still keep the existing flags that turn on/off reset_snow_glc and reset_snow individually? Or do we want separate control over global vs regional application of reset_snow_glc and reset_snow? etc.

[wwieder]

Thanks for your thoughts here Bill.

I think I'd opt for the most simple application here #_1 from your list, above.

The goal with this PR is just to get the lab sea through the threat of freezing oven when initializing the coupled model from a G-case. From CESM run 147 it seems like being able to store precip on land (or generatite negative ice runoff from the data glacier model) is an effective way to do this.

As such, it's something we hopefully won't use often, but it maybe something that we end up need to user again in CESM development. I'd support bringing this PR to main to enable this namelist capability in the most simple (hard coded bounding box).

[wwieder]

Since 147 is still freezing we're going to wait to bring this in until it's asked for again in a CESM3_dev case.

[billsacks]

Recording some brief notes to myself that I wrote a few hours ago before we decided to pause this... if going with option (1):

• Add a logical like: apply_reset_snow_only_over_bounding_box
• If that's true, then determine if within hard-coded bounding box
• If false, then the corresponding flag will always be true
• Test:
  • With reset_snow and reset_snow_glc true, new flag false: should be identical to old run with those two flags true
  • With reset_snow and reset_snow_glc true, new flag true: should be identical to previous branch run with those two flags true

[ekluzek]

I'm going to close this for now, as we figure we won't be doing this. But, could reopen if needed. And it's easy enough to bring in later if it is asked for...