-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Stochastically Perturbed Parameterizations (SPP) in FV3 #51
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Things look good here. Have you tested a restart run to ensure bit-for-bit reproducibility?
@pjpegion, thanks for reviewing. I haven't tested a restart run. Are you referring to b4b between the write component and restart files written for the same time? There is a request from Dom and Joe to rewrite the implementation of SPP to remove |
@JeffBeck-NOAA I didn't realize that Laurie retired. Yes for the restart capability, I am referring to running something like a 24-hour forecast, dropping a restart at 12-hours, then running a 2nd run starting with that restart. The history and restart files at FHR 24 should be identical. |
@pjpegion, yep, December 9th was her last day. We worked together among the team to decide on the general implementation of SPP in FV3, and she coded it up within her forks of the repos. Do you know if there is a ufs-weather-model regression test for a b4b restart run? If not, I'll test things manually the way you described it. Thanks. |
Simplest thing to do is to create a regression test that includes SPP, and run the operational requirements test (ORT) on it. The restart test is part of the suite of tests. |
Thanks! There's a plan to create an SPP RT anyway, so this is great. |
… into feature/stoch_spp
… into feature/stoch_spp
Description
This PR adds the necessary code in stochastic_physics to run the FV3 with Stochastically Perturbed Parameterizations (SPP). The associated code uses the stochastic_physics pattern generator (same as for SKEB, SHUM, and SPPT) to create a random pattern based on scales, magnitudes, etc., from the FV3 input.nml namelist and perturbs RAP/HRRR-based physics scheme parameters in selected parameterizations. This PR to stochastic_physics integrates and initializes SPP within the stochastic physics routines and connects the pattern generator to SPP.
Issue(s) addressed
This PR address Issue #978 in ufs-weather-model.
Testing
Regression testing for ufs-weather-model was conducted on Hera and Cheyenne. All passed, but not bit-for-bit for RAP and HRRR cases (tests 41 and 42 on cheyenne, 44 and 45 on hera); although unlikely that this B4B discrepancy is related to code in this PR. Debugging revealed several errors in the GSL GWD interfaces, might be the cause of the B4B issue (unallocated, mis-matched array sizes, etc.) that are caught with a DEBUG compile. These cases do not run in debug mode, and there are no debug tests in the RT, so maybe this is a known issue? The unique element for these two cases is the GSL GWD scheme (drag_suite.F90). @DomHeinzeller described an optimization/bug in RRTMGhttps://github.com/NCAR/ccpp-physics/pull/820P that caused B4B issues, maybe reducing optimization on drag_suite.F90 would fix the issue?
Dependencies
Depends on the following PRs from fv3atm, ufs-weather-model, and ccpp-physics.
@llpcarson, @jwolff-ncar, @willmayfield, @bluefinweiwei, @michelleharrold, @judithberner, @pjpegion