SNICAR snow albedo scheme updates

[cenlinhe]

Description of changes

This PR made a few substantial changes in SNICAR module for the following updated snow albedo calculation features:

1. Updated ice optical properties from Flanner et al. (2021), with multiple types for ice refractive indices (the updated SNICAR database files are in Cheyenne:
   /glade/work/cenlinhe/NOAA_CPT_snowAER/CLM_SNICAR_data/snicar_optics_480bnd_c012422.nc
   /glade/work/cenlinhe/NOAA_CPT_snowAER/CLM_SNICAR_data/snicar_optics_5bnd_c013122.nc
2. Updated aerosol optical properties from Flanner et al. (2021) with multiple dust types & new BC and OC optics (the updated data are in the new SNICAR database files shown above).
3. Updated downward solar spectra from Flanner et al. (2021) for multiple condition types.
4. More accurate radiative transfer solver (adding-doubling) from Dang et al. (2019).
5. Nonspherical snow grain scheme from He et al. (2017).
6. BC-snow internal mixing scheme from He et al. (2017).
7. Dust-snow internal mixing scheme from He et al. (2019).
8. Hyperspectral (480-band, 10-nm spectral res) capability with all the above features
9. Add new namelist controls for aerosol in snow and additional snow albedo diagnostic output variables

Specific notes

Code contributors: Cenlin He (NCAR/RAL) with advice from Dave Lawrence (NCAR/CGD) and Mark Flanner (UMich).
The manuscript to report this update is in preparation (He et al, 2022 JAMES in prep)
These updates will change the snow and surface albedo results along with other surface fluxes changes.
There are a few new namelist options related to SNICAR scheme added to the namelist control.
Testing performed: 10-year global GSWP-driven offline CLM simulation have been performed for testing for each of the above updates and the results are reasonable and as expected based on physics (with Dave Lawrence's and Mark Flanner's review of preliminary test results)

Fixes trivial error found while working on this PR

Fixes #2173
Fixes #2107
Fixes #2129

[ekluzek]

@cenlinhe something simple we'd like you to do is to run the clm_short testlist. This is fairly simple to do using the run_sys_tests script at the top of the CTSM checkout. What CESM machines do you have access to? Do you have access to cheyenne?

To run clm_short, without comparing or generating baselines.

./run_sys_tests -s clm_short --skip-compare --skip-generate

[cenlinhe]

Hi Erik, Yes I have access to Cheyenne. I will do it once Cheyenne is back online

[cenlinhe]

@ekluzek I have run the clm_short testlist as you suggested at: /glade/scratch/cenlinhe/test/CTSM_snicartest/
Here is the info shown after I initiated the command:

Testroot: /glade/scratch/cenlinhe/tests_1106-110104ch

create_test --retry: 0

Current hash: 7191233 (cenlinhe, Sun Apr 10 20:31:03 2022 -0600) bug fix for albsni_hst2

snicar_allupdate

(clean sandbox)

manage_externals status:
Processing externals description file : Externals.cfg
Processing externals description file : Externals_CLM.cfg
Processing externals description file : Externals_CISM.cfg
Processing externals description file : Externals_CDEPS.cfg
Checking status of externals: clm, fates, cism, source_cism, rtm, mosart, mizuroute, cime, cmeps, cdeps, fox, genf90, cpl7, share, mct, parallelio, doc-builder,
./cime
clean sandbox, on branch_tags/cime6.0.12_a01
./components/cdeps
clean sandbox, on cdeps0.12.34
./components/cdeps/fox
clean sandbox, on 4.1.2.1
./components/cdeps/share/genf90
clean sandbox, on genf90_200608
./components/cism
clean sandbox, on cismwrap_2_1_93
./components/cism/source_cism
clean sandbox, on cism_main_2.01.010
./components/cmeps
clean sandbox, on cmeps0.13.43
./components/cpl7
clean sandbox, on cpl7.0.7
./components/mizuRoute
clean sandbox, on 34723c2e4df7caa16812770f8d53ebc83fa22360
./components/mosart
clean sandbox, on mosart1_0_45
./components/rtm
clean sandbox, on rtm1_0_78
e-o ./doc/doc-builder
-, not checked out --> v1.0.8
./libraries/mct
clean sandbox, on MCT_2.11.0
./libraries/parallelio
clean sandbox, on pio2_5_4
./share
clean sandbox, on share1.0.10
./src/fates
clean sandbox, on sci.1.53.0_api.21.0.0

[wwieder]

@cenlinhe would you be able to present on this work at an upcoming CLM meeting (every other Thursday at 1). It would be helpful to get a sense of the science impacts we can expect from this PR.

[cenlinhe]

@wwieder Sure, I am happy to do it. I presented some preliminary results in the CESM workshop earlier this year, but I haven't had too much time to complete my detailed scientific analysis yet since I have been busy with proposals and some other projects. I may be able to present some results early next year (considering the upcoming holidays and AGU). Does this work?

[wwieder]

Yes, I think this is fine. You can also chose if it makes more sense to present at:

• Our Thursday CLM meeting (longer time & more in depth discussion with smaller team) and/or
• LMWG workshop in February (shorter presentation, but larger audience).
  Either or both of these are appropriate. Let me know your preference.

[cenlinhe]

Both work for me. I will let you know when I am ready. Thank you!

[rosiealice]

I've been looking a bit at the albedo biases in various versions of CLM (mostly from a vegetation perspective), and they all seem to share a pretty serious low bias in the albedo compared to both GEWEX and CERES. Will this improve matters, do you think? I'd be interested to hear about the changes! https://www.ilamb.org/CMIP5v6/historical/RadiationandEnergyCycle/Albedo/GEWEX.SRB/GEWEX.SRB.html?model=row_name&region=global

[cenlinhe]

The use of nonspherical snow grains will increase snow albedo but only for snow-covered regions and periods. If the albedo underestimation is large and consistently across all seasons, then it may be the issue with vegetation process (e.g., canopy radiative transfer, vegetation properties, etc.).

[wwieder]

@cenlinhe thanks for your presentation last week. It seems we should push forward to bring this PR to main. It seems that next steps for us to review this PR. Let's make a game plan at the SE meeting this week.

[wwieder]

We're wanting to move this up the priority list for upcoming tags.

• @ekluzek is going to provide a high level code review for @cenlinhe before spending more time on bringing this onto main.
• @swensosc or @dlawrenncar can you provide a scientific review of this code?

One question for the group, was if we want / need to maintain all the namelist options provided in this PR or just support the default options that are being suggested for CTSM? It's hard for me to assess the scientific capabilities and options that we want to enable and support moving forward?

[slevis-lmwg]

Commit 44d128e (a few lines up from here) was accidental, unnecessary, and inconsequential (introduced no diffs).

Test-suites
cheyenne OK
izumi OK

[slevis-lmwg]

Although this PR is merged, I will add relevant posts:

I updated the Answer Changing Tags wiki
with a link to diagnostics comparing dev145 to dev116 (which was the most recent tag before dev145 with significant changes).

@cenlinhe @wwieder @dlawrenncar @olyson
I would like feedback regarding the changes in the diagnostics. Feel free to share with others who should take a look.

Notes regarding my simulations:
dev145 had to use a new 1989 initial file due to changes in the restart files. I can share details when /glade becomes available.

[wwieder]

At a high level it seems as though winter albedo is significantly higher with the new SNICAR code, which likely causes summer snow to persist for a bit longer.

Is this an accurate interpretation, Sam?
Is this what you'd expect, @cenlinhe, based on your previous work?

[wwieder]

@slevis-lmwg we also have big declines in LAI, that seem unexpected. Is this related to the restart file issue you mentioned or is something else going on?

GPP and other fields look very different in places without snow. Are there other changes since the Dev116 baseline that we're looking at here too?

[cenlinhe]

At a high level it seems as though winter albedo is significantly higher with the new SNICAR code, which likely causes summer snow to persist for a bit longer.

Is this an accurate interpretation, Sam? Is this what you'd expect, @cenlinhe, based on your previous work?

Yes, the higher surface albedo (particularly in winter) is due to the higher snow albedo mainly caused by using nonspherical snow grain shape. It seems that the LAI decline mentioned in your other comment also contributes to the higher surface albedo to some extent?

[slevis-lmwg]

@slevis-lmwg we also have big declines in LAI, that seem unexpected. Is this related to the restart file issue you mentioned or is something else going on?

GPP and other fields look very different in places without snow. Are there other changes since the Dev116 baseline that we're looking at here too?

Based on the tag descriptions, I would not expect large changes in LAI; however, it may help to go back through the tags next week and see whether LAI changes at a certain tag or due to new initial conditions.

[slevis-lmwg]

It's my choice of finidat file, which comes from an SP simulation.
So I need a new AD spinup with a recent tag (with the variable name changes in it) or I could add SourceMods to make the code backwards compatible with older finidat files. I will see if I can accomplish the latter easily...

[wwieder]

I think @olyson will soon be doing a transient historical control case for LMWG_dev # 1. Maybe this would be the case to branch off of for this test?

[wwieder]

@slevis-lmwg does it make sense to migrate the SNICAR evaluation over to the LMWG_dev repo, or better to keep the discussion here?

[slevis-lmwg]

I think @olyson will soon be doing a transient historical control case for LMWG_dev # 1. Maybe this would be the case to branch off of for this test?

@slevis-lmwg does it make sense to migrate the SNICAR evaluation over to the LMWG_dev repo, or better to keep the discussion here?

LMWG_dev makes sense for documenting the simulation. I can open a new issue for it.

@olyson will you be running a new control using a tag that has the new variables names? If so, then it makes sense for me to wait.

[olyson]

@slevis-lmwg I'm running cesm2_3_alpha16b, which has ctsm5.1.dev130. Not sure what tag has the new variables?

[slevis-lmwg]

dev135. So I can start a new control with dev145 (the SNICAR tag) to have available.

[olyson]

@slevis-lmwg , it just occurred to me that since there are new restart file variables, maybe you should turn on isotopes in your spinup. I have one going but it doesn't have the new restart variables.

[wwieder]

@cenlinhe we're interested in looking at uncertainty in SNICAR parameters, especially regarding snow albedo, as part of the PPE project. Are there SNICAR parameters we could consider adjusting as part of this effort?

[cenlinhe]

@wwieder For SNICAR physics options, candidates could be (1) snow grain shape, (2) dust types, (3) BC-snow mixing, (4) dust-snow mixing. For SNICAR hard-coded tunable parameters, candidates could be (1) C2_liq_Brun89 (wet aging coeff), (2) snw_rds_refrz (refrozne grain size), (3) fresh_snw_rds_max (max fresh snow grain size), (4) snw_rds_min (cold snow size), (5) scvng_fct_mlt_bcphi, scvng_fct_mlt_bcpho, scvng_fct_mlt_dst1~4

[wwieder]

Thanks @cenlinhe we aren't really considering physics options in our PPE experiment, but maybe this is something we should consider? It looks like a number of these namelist options are EXPERIMENTAL, UNSUPPORTED, and UNTESTED!. Are these really options that should be on the table for default global CTSM5.1 cases?

[wwieder]

@djk2120, @linniahawkins, @katiedagon see the list of potential snow albedo parameter we could consider. I think the first OAT tests only had C2_liq_Brun89, which had little effect. I'm unsure if the other parameters need to be moved to the parameter file, but may be worth considering?

[katiedagon]

Yes I think only C2_liq_Brun89 was included previously. It would make sense to me to include migrating these other hard coded SNICAR parameters to the parameter file as part of the PPE PR that came up in the software engineering meeting yesterday. Even if they don't make the cut for the next iteration of a LHC ensemble, it's possible we may want to run another OAAT ensemble at some point with CTSM/CLM6.

[wwieder]

@cenlinhe @dlawrenncar @slevis-lmwg @olyson from our conversation today it seems like the snicar_snobc_intmix and snicar_snodst_intmix could be set to .true. on to accelerate snowmelt? I copied the default namelist options below?

The snow parameters I saw in the PPE list were

parameter	description
xdrdt	arbitrary factor applied to snow aging rate
snw_rds_refrz	effective radius of re-frozen snow [microns]
scvng_fct_mlt_sf	scaling factor modifying scavenging factors for BC, OC, and dust species inclusion in meltwater
fresh_snw_rds_max	free snow radius (AerosolMod.F90)
snicar_snobc_intmix = .true.	namelist change
ceta	overburden compaction constant
C2_liq_Brun89	Constant for liquid water grain growth [m3 s-1],from Brun89: corrected for LWC in units of percent

It sounds like we could also increase xdrdt to melt snow faster? Maybe worth consulting with the OAAT results on the others?

 snicar_dust_optics = 'sahara'
 snicar_numrad_snw = 5
 snicar_snobc_intmix = .false.
 snicar_snodst_intmix = .false.
 snicar_snw_shape = 'hexagonal_plate'
 snicar_solarspec = 'mid_latitude_winter'
 snicar_use_aerosol = .true.

[cenlinhe]

I would suggest not turning on snicar_snobc_intmix and snicar_snodst_intmix at the same time, which will overestimate aerosol impacts. It may be good to test turning on snicar_snobc_intmix for BC, which tends to have a larger impact over high latitudes than dust.

[cenlinhe]

Here are some snow albedo related hard-coded tunable parameters (to reduce snow albedo):

1. increase fresh_snw_rds_max (AerosolMod.F90);
2. reduce scvng_fct_mlt_sf (shown in Will's table above);
3. increase snw_rds_refrz (shown in Will's table above);
4. increase xdrdt (shown in Will's table above);