Add a new parameter in dycore to control cutoff level for implicit RF

[XiaqiongZhou-NOAA]

Commit Queue Requirements:

• Fill out all sections of this template.
• All sub component pull requests have been reviewed by their code managers.
• Run the full Intel+GNU RT suite (compared to current baselines) on either Hera/Derecho/Hercules
• Commit 'test_changes.list' from previous step

---

Description:

A new parameter rf_cutoff_w is introduced in dynamics to independently control the cutoff level for implicit Rayleigh damping when fast_tau_w_sec>0, decoupling it from the cutoff level (rf_cutoff) used for explicit damping when tau>0.
The default value of rf_cutoff_w=100. (1hPa). It changes the results in RTs with fast_tau_w_sec>0 and rt_cutoff is not equal to 100.

Commit Message:

* UFSWM - Add a new parameter to control cutoff level for implicit RF
   * FV3 - Add a new parameter to control cutoff level for implicit RF
    * atmos_cubed_sphere - Add a new parameter to control cutoff level for implicit RF
  

Priority:

• High: For the update of GFSv17/GEFSv13

Git Tracking

UFSWM:

• None

Sub component Pull Requests:

• FV3: Add a new parameter to control cutoff level for implicit RF NOAA-EMC/ufsatm#962
  • atmos_cubed_sphere: Add a new parameter to control cutoff level for implicit RF NOAA-GFDL/GFDL_atmos_cubed_sphere#381

UFSWM Blocking Dependencies:

• None

Documentation:

• No documentation update is required for this PR (please explain).

---

Changes

Regression Test Changes (Please commit test_changes.list):

• PR Updates/Changes Baselines.

Input data Changes:

• None.

Library Changes/Upgrades:

• No Updates

---

Testing Log:

• RDHPCS
  • Hera
  • Orion
  • Hercules
  • GaeaC6
  • Derecho
• WCOSS2
  • Dogwood/Cactus
  • Acorn
• CI
• opnReqTest (complete task if unnecessary)

[jkbk2004]

@XiaqiongZhou-NOAA can you sync up branches?

[XiaqiongZhou-NOAA]

@XiaqiongZhou-NOAA can you sync up branches?
Updated.

[FernandoAndrade-NOAA]

#2723 has been merged. This PR is next for testing, please sync up all branches/resolve conflicts, thank you.

[jkbk2004]

@XiaqiongZhou-NOAA I don't have permission to your feature branches. If you add my git id jkbk2004 to your repo, I can help to sync up branches.

[XiaqiongZhou-NOAA]

@XiaqiongZhou-NOAA I don't have permission to your feature branches. If you add my git id jkbk2004 to your repo, I can help to sync up branches.

I do not know how to add your id but it was sync-ed.

[BrianCurtis-NOAA]

@FernandoAndrade-NOAA was this ready for testing yet, or are we waiting on something first?

[FernandoAndrade-NOAA]

Orion/Hercules are failing baseline creation for gnv1_c96_no_nest_debug_intel due to floating point exception, please refer to the following test directories:
/work2/noaa/epic/nandoam/stmp/hercules/nandoam/FV3_RT/rt_122113/gnv1_c96_no_nest_debug_intel/err
/work2/noaa/epic/nandoam/stmp/orion/nandoam/FV3_RT/rt_2010589/gnv1_c96_no_nest_debug_intel/err

[FernandoAndrade-NOAA]

@BrianCurtis-NOAA @rhaesung @JessicaMeixner-NOAA The gnv1_c96_no_nest_debug_intel baseline creation issues seem to be exclusive to orion/hercules. A temporary solution would be to disable this test, create an issue, and potentially fix in #2752, or we could delay this PR until the test issues are resolved.

[JessicaMeixner-NOAA]

I'll defer to others on the path forward, but if there's something I can do let me know.

[rhaesung]

I'll defer to others on the path forward, but if there's something I can do let me know.

Ditto!

[BrianCurtis-NOAA]

@BrianCurtis-NOAA @rhaesung @JessicaMeixner-NOAA The gnv1_c96_no_nest_debug_intel baseline creation issues seem to be exclusive to orion/hercules. A temporary solution would be to disable this test, create an issue, and potentially fix in #2752, or we could delay this PR until the test issues are resolved.

How confident are we that #2752 will solve this?

[XiaqiongZhou-NOAA]

you mean
#2759, right?

[FernandoAndrade-NOAA]

@BrianCurtis-NOAA @rhaesung @JessicaMeixner-NOAA The gnv1_c96_no_nest_debug_intel baseline creation issues seem to be exclusive to orion/hercules. A temporary solution would be to disable this test, create an issue, and potentially fix in #2752, or we could delay this PR until the test issues are resolved.

How confident are we that #2752 will solve this?

Apologies for any confusion, I meant that a fix would need to be introduced in the upcoming #2752 when it's time to process that PR. #2747 would follow this PR whether we decide to skip or merge, which would give some time for developers to introduce a fix into #2752.

[yangfanglin]

Can we rerun this test gnv1_c96_no_nest_debug_intel but set LANDICE=.fasle. ? If this cannot be easily done, I'd suggest we skip this RT for this PR, and turn this RT back in the future after the issues documented in #2768 are fixed.

[BrianCurtis-NOAA]

Can we rerun this test gnv1_c96_no_nest_debug_intel but set LANDICE=.fasle. ? If this cannot be easily done, I'd suggest we skip this RT for this PR, and turn this RT back in the future after the issues documented in #2768 are fixed.

This is sufficient. I just want to make sure it is actively being worked on. We can disable those tests for Hercules/Orion and move forward with this PR.

[jkbk2004]

/work2/noaa/stmp/jongkim/stmp/jongkim/FV3_RT/rt_58610/gnv1_c96_no_nest_debug_intel runs ok with LANDICE = .false.

[yangfanglin]

Please skip RT gnv1_c96_no_nest_debug_intel for this PR, and get this dycore update committed as soon as you can.

All the LANDICE related issues in a few RTs can be fixed in #2768

Thanks
Fanglin

[BrianCurtis-NOAA]

I have made changes that address gnv1_c96_no_nest_debug in #2772 . It sets LANDICE to .false. among some LSM/LANDICE changes to other tests.