Add support for Stochastically Perturbed Parameterizations (SPP) in FV3 #820
Conversation
JeffBeck-NOAA
requested review from
climbfuji,
grantfirl,
mkavulich and
SamuelTrahanNOAA
as code owners
JeffBeck-NOAA
changed the title
There was a problem hiding this comment.
A few small changes here and there.
The main concern I have is that half of this PR deals with passing stochastic perturbations through the various interfaces to the gravity wave drag, but then these variables don't get used at all?
Also, regarding the b4b mismatches and the speculations as to why, please see my comment in the ufs-weather-model PR.
|
The last update of this code from the authoritative repos is 18 days ago - definitely behind. |
@climbfuji, pulled in the latest code. |
|
Jeff,
I'm not sure I follow... It looks to me that when do_spp = true, then
spp_pbl = 1, and then certain parts of the code (additional spp-related
do-loops) will be used even if the perturbations are zero. I realize most
of the perturbations will come from the PBL portion of SPP, so do_spp is
unlikely to ever be true with the pbl portion deactivated - outside of some
(likely) rare test cases, but as is I think any time do_spp is true,
spp_pbl will be set to 1, which will cause more do-loops to be used even
though the perturbations will be (hopefully) set to zero. For example, in
subroutine *mym_turbulence*:
if (spp_pbl==1) then
DO k = kts,kte
dfm(k)= dfm(k) + dfm(k)* rstoch_col(k) * 1.5 * MAX(exp(-MAX
(zw(k)-8000.,0.0)/2000.),0.001)
dfh(k)= dfh(k) + dfh(k)* rstoch_col(k) * 1.5 * MAX(exp(-MAX
(zw(k)-8000.,0.0)/2000.),0.001)
END DO
endif
It would be more ideal if spp_pbl could be set to zero if not listed in the
spp_var_list.
…-joe
On Tue, Dec 28, 2021 at 1:32 PM JeffBeck-NOAA ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In physics/drag_suite.F90
<#820 (comment)>:
> @@ -595,6 +601,21 @@ subroutine drag_suite_run( &
endif
enddo
+! SPP, if do_spp is false, no perturbations are applied.
Thanks, @joeolson42 <https://github.com/joeolson42>! I added the last
missing perturbation code this morning and am testing it right now. I
believe it's now back to where it was.
—
Reply to this email directly, view it on GitHub
<#820 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADLRR3WB5T5BQ4DK7V2NSADUTINGTANCNFSM5KZS7SXA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Joseph Olson
Model Physics Branch Chief
Environmental Prediction Advancement Division
NOAA-Global Systems Laboratory
Boulder, Colorado
|
|
@joeolson42, you're correct, if do_spp is .true., then spp_pbl = 1 (even if 'pbl' isn't listed in spp_var_list and SPP is being used for another parameterization). In that case, those do loops are still activated, but with zero perturbation values. It's not ideal, and I agree, we should base the activation of SPP in MYNN PBL on whether 'pbl' is listed in spp_var_list. I would need to take a look at how Laurie implemented spp_var_list to see if it can be queried within MYNN PBL. We need something like: I realize that the use of do_spp may not be necessary in this case. The problem is that spp_var_list can be any combination of 'pbl', 'sfc', 'mp', 'gwd', or 'rad', so I'm not sure how to "check" whether 'pbl' is listed within Fortran. Do you have an idea? |
|
See GFS_surface_generic.F90 for an example of how this is done for lndp_var_list (line 136).
… On Dec 28, 2021, at 5:34 PM, JeffBeck-NOAA ***@***.***> wrote:
@joeolson42 <https://github.com/joeolson42>, you're correct, if do_spp is .true., then spp_pbl = 1 (even if 'pbl' isn't listed in spp_var_list and SPP is being used for another parameterization). In that case, those do loops are still activated, but with zero perturbation values. It's not ideal, and I agree, we should base the activation of SPP in MYNN PBL on whether 'pbl' is listed in spp_var_list. I would need to take a look at how Laurie implemented spp_var_list to see if it can be queried within MYNN PBL. We need something like:
if ( do_spp ) .AND. (spp_var_list contains 'pbl')
spp_pbl=1
endif
I realize that the use of do_spp may not be necessary in this case.
The problem is that spp_var_list can be any combination of 'pbl', 'sfc', 'mp', 'gwd', or 'rad', so I'm not sure how to "check" whether 'pbl' is listed within Fortran. Do you have an idea?
—
Reply to this email directly, view it on GitHub <#820 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RJSNWCQNBIBWLICK2DUTJJRTANCNFSM5KZS7SXA>.
Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.
|
|
These PRs need more work before they can be considered for merging. I will add labels "do not merge" and "work in progress". |
metadata units fix
drag_suite.F90
Outdated
| @@ -0,0 +1,1381 @@ | |||
| !> \File drag_suite.F90 | |||
There was a problem hiding this comment.
@JeffBeck-NOAA It looks like this file was misplaced. Could you remove it please?
There was a problem hiding this comment.
Thanks, @grantfirl! Removed.
| [spp_rad] | ||
| standard_name = control_for_radiation_spp_perturbations | ||
| long_name = control for radiation spp perturbations | ||
| units = count |
There was a problem hiding this comment.
This isn't the right unit for this, but this can be cleaned up in the future since there are a bunch of wrong units for stuff like this, at least according to https://github.com/ESCOMP/CCPPStandardNames/blob/main/StandardNamesRules.rst
There was a problem hiding this comment.
Thanks! I'm happy to make those changes in a future PR if it's not urgent right now?
There was a problem hiding this comment.
It's not urgent right now and can be merged as-is since we're so far along in the process.
| [spp_gwd] | ||
| standard_name = control_for_gravity_wave_drag_spp_perturbations | ||
| long_name = control for gravity wave drag spp perturbations | ||
| units = count |
There was a problem hiding this comment.
Same comment RE: units.
| [spp_pbl] | ||
| standard_name = control_for_pbl_spp_perturbations | ||
| long_name = control for pbl spp perturbations | ||
| units = count |
| [spp_sfc] | ||
| standard_name = control_for_surface_layer_spp_perturbations | ||
| long_name = control for surface layer spp perturbations | ||
| units = count |
| [spp_mp] | ||
| standard_name = control_for_microphysics_spp_perturbations | ||
| long_name = control for microphysics spp perturbations | ||
| units = count |
| [spp_gwd] | ||
| standard_name = control_for_gravity_wave_drag_spp_perturbations | ||
| long_name = control for gravity wave drag spp perturbations | ||
| units = count |
| [spp_gwd] | ||
| standard_name = control_for_gravity_wave_drag_spp_perturbations | ||
| long_name = control for gravity wave drag spp perturbations | ||
| units = count |
|
@JeffBeck-NOAA I'll approve this so that it can be merged once the extraneous drag_suite.F90 file is removed. |
There was a problem hiding this comment.
This looks good to me. @JeffBeck-NOAA did a nice job addressing previous comments/suggestions, IMO.
|
@climbfuji Since you requested changes, could you take a look at this again to see if your request was addressed? It looks like merging is blocked until you review again. |
Thanks, @climbfuji! I appreciate your reviews. I'll keep an eye on things regarding the use of SPP in Thompson MP and any potential failures. |
…(AKA spp_wts_mp); change to assumed-shape and reduce rank to match rank of input (i,k) instead of (i,j,k)
edit module_mp_thompson.F90 to remove optional keyword for rand_pert …
…ccpp-physics into feature/stoch_spp
…assumed-shape in module_bl_mynn and module_sf_mynn
Fix the rest of the Cheyenne/GNU tests
Description
This PR adds the necessary code in ccpp-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 ccpp-physics connects the SPP flag and weights to the specific RAP/HRRR parameterizations.
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 RRTMGP 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 stochastic_physics.
@llpcarson, @jwolff-ncar, @willmayfield, @bluefinweiwei, @michelleharrold, @judithberner, @pjpegion