Enable customizable idealized, doubly-periodic tests

[LarissaReames-NOAA]

Description

This PR adds a doubly-periodic idealized test case to test_cases.F90 that is customizable by the user at run time via input.nml and that can be run within the UFS framework and is fully compatible with CCPP physics.

An important modification was made to make this case compatible with CCPP. To enable the user to choose the canned "SupeCell" sounding from GFDL's original supercell test, we copied over the routines from GFDL MP that were previously preventing this code from compiling with CCPP/"GFS physics".

We have added documentation to help the user, including some code to generate an idealized surface file that the user can customized to their liking. The PR at the UWM level will also have a corresponding regression test. It won't be baseline tested, but it will provide an easy route for user to generate a run directory.

Many thanks go to @MicroTed for all of his help and contributions to this effort as well. He's agreed to provide a test run directory on that can be cloned by those who'd like to test the code inside a pre-generated run directory. You can find that here: https://github.com/MicroTed/ufs_ideal_run.git

Fixes ufs-community/ufs-weather-model/issues/2558

How Has This Been Tested?

These code changes have been compiled and tested on both Hera and Jet. Tests have been run to check that all the various types of sounding options can be used successfully. The full suite of regression tests will be run at the weather model level.

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

[lharris4]

Hello @LarissaReames-NOAA . Can you explain what this new test case is intended to test in FV3, and how to validate the solution? Also, have these test cases and this implementation been scientifically vetted? In particular, care must be taken in the initialization so it is in-balance and consistent with the FV3 vertical discretization.

Thanks
Lucas

[LarissaReames-NOAA]

Hello @LarissaReames-NOAA . Can you explain what this new test case is intended to test in FV3, and how to validate the solution? Also, have these test cases and this implementation been scientifically vetted? In particular, care must be taken in the initialization so it is in-balance and consistent with the FV3 vertical discretization.

Thanks

Lucas

Hi Lucas,

This is meant to be a framework for users to generate their own idealized cases, not to provide a case that produces a single, verifiable solution. It's intended (and has been used successfully at NSSL) to test how the model core and physics respond to various changes in schemes and settings. This sort of functionality was listed as a community need at the first UFS workshop to enable non-real-data cases, hence we're submitting this PR so that it can be in the trunk instead of having to pass around external forks and branches.

We made every effort to copy the general format and sequence that was used in other test cases in the test_cases file, so unless those aren't consistent with the vertical discretization, I have no reason to believe that what we provide here wouldn't also be. However, I'm happy to implement any changes that those more familiar with this code base than I say are necessary.

[lharris4]

We will need some scientific description of these idealized storm cases and of what results are expected, and the specific scientific or development need for these new cases, before this PR can be further considered. You mentioned successful use at NSSL; could you elaborate?

…

On Thu, Jan 16, 2025 at 5:05 PM Larissa Reames ***@***.***> wrote: Hello @LarissaReames-NOAA <https://github.com/LarissaReames-NOAA> . Can you explain what this new test case is intended to test in FV3, and how to validate the solution? Also, have these test cases and this implementation been scientifically vetted? In particular, care must be taken in the initialization so it is in-balance and consistent with the FV3 vertical discretization. Thanks Lucas Hi Lucas, This is meant to be a framework for users to generate their own idealized cases, not to provide a case that produces a single, verifiable solution. It's intended (and has been used successfully at NSSL) to test how the model core and physics respond to various changes in schemes and settings. This sort of functionality was listed as a community need at the first UFS workshop to enable non-real-data cases, hence we're submitting this PR so that it can be in the trunk instead of having to pass around external forks and branches. We made every effort to copy the general format and sequence that was used in other test cases in the test_cases file, so unless those aren't consistent with the vertical discretization, I have no reason to believe that what we provide here wouldn't also be. However, I'm happy to implement any changes that those more familiar with this code base than I say are necessary. — Reply to this email directly, view it on GitHub <#370 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMUQRVBXG2SVVGAMTJLGHK32LAUKZAVCNFSM6AAAAABVFZTMTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJXGAYDKMBRGA> . You are receiving this because you commented.Message ID: ***@***.***>

[MicroTed]

@lharris4 Although the PR description may seem to give the impression of providing a case study, that is really only a provided example of an ability to run any suite in an general idealized environment with full physics. Therefore, no particular scientific results are expected. I brought up this capability at the 2023 UFS physics workshop, and there was general agreement that such capability would be useful (e.g., @ligiabernardet). I think of it as a 3D counterpart to the SCM. The included python script allows a user to set up any surface inputs as desired (e.g., land surface type and pattern), so it could be used for any kind of setup at any scale. The included sounding and initialization for an isolated storm are just one example of how it can be used. It will allow physics developers (e.g., CCPP) to run their own 3D tests in a controlled environment. At NSSL, this capability has been used for studying characteristics of deep convection and for CCPP microphysics testing.
Hope that helps!