UFS-dev PR#305

[grantfirl]

SOURCE: @grantfirl

DESCRIPTION OF CHANGES:

• Code changes need for RRTMGP v1.8

ISSUE: None

ASSOCIATED PRs:
NCAR/ccpp-physics#1168
NCAR/ccpp-physics#1172

TESTS CONDUCTED: SCM/UFS RTs

This PR catches the NCAR:main branch up with changes from the ufs-community:ufs/dev branch.

Associated ufs/dev PR:

• Feature/rte rrtmgp v1.8 ufs-community/ccpp-physics#305

Associated ufsatm PR:

• Update rte-rrtmgp to v1.8 NOAA-EMC/ufsatm#995

Associated NCAR PR:

• UFS-dev PR#305 ccpp-physics#1168

---

REGRESSION TEST CHANGES: Assuming all RRTMGP-based suites should change results.

[grantfirl]

Note: This should not be merged until we figure out what to do with the RRTMGP data. See NCAR/ccpp-physics#1168 (comment) for more details.

Edit: I tar'ed up the RRTMGP data files, added them as a release asset to v7.0, wrote a script to download them and stage them within scm/data/physics_input_data and modified physics namelists to point to them in their new location. All RRTMGP RTs should run now.

[grantfirl]

@scrasmussen @hertneky Not sure if we want to upload artifacts from the last PR merge to use them in this PR, or should we wait until #628 is finished?

[hertneky]

Changes look good.
Used new script to get new radiation data and ran RTs. All ran successfully, namely the RRTMGP suites

[hertneky]

@scrasmussen @hertneky Not sure if we want to upload artifacts from the last PR merge to use them in this PR, or should we wait until #628 is finished?

I don't think we need to wait on #628, but I'll let @scrasmussen chime in if he has an opinion.

[scrasmussen]

@scrasmussen @hertneky Not sure if we want to upload artifacts from the last PR merge to use them in this PR, or should we wait until #628 is finished?

@scrasmussen @hertneky Not sure if we want to upload artifacts from the last PR merge to use them in this PR, or should we wait until #628 is finished?

I don't think we need to wait on #628, but I'll let @scrasmussen chime in if he has an opinion.

Hi, no need to wait on PR #628! Not quite ready to be merged and it shouldn't effect this one.

[scrasmussen]

Looks good to me!

[scrasmussen]

@grantfirl I think the new get-artifacts was failing because the default number of artifact names that it returns is 30. It wasn't breaking for me because I was testing right after the main branch had created the artifacts. But as other PRs ran CI and create PR artifacts, it pushed the main artifacts out of the 30 range. I'll submit a fix to this momentarily