Merge stochastic physics (SPPT only) into GSL's develop branch#239
Merge stochastic physics (SPPT only) into GSL's develop branch#239gsketefian wants to merge 152 commits into
Conversation
…he stochastic_physics submodule itself will be added in a separate commit.
…'t updated during latest merge of gsl/develop.
…he gsl/MPAS_stoch_physics in the stochastic_physics repo.
…teger seed workaround.
… smoke) from "output" to "output_smoke" (and file from "history..." to "history_smoke...". This is necessary because the stream name "output" is already taken by the main output stream, and having the same name for two different output streams apparently causes SMIOL I/O errors during the forecast (and incorrect/corrupted history*.nc files).
…) no stale stream_list.atmosphere files exist in the two default_inputs directories (one under core_atmosphere and the other immediately under the MPAS-Model top-level directory), and (2) for the atmosphere core, all files (stream-related as well as namelist) in the top-level directory are backed up before new such files are copied from the default_inputs directory back up a level into the top-level directory. Previously, existing (and thus possibly outdated) stream_list.atmosphere.* files in the top-level directory were not being replaced by newer ones in default_inputs, and that was causing unexpected (and wrong) behavior. Probably a similar fix is needed for the init_atmsophere core and maybe even other ones.
…ll as its output file) so it doesn't conflict with the default output stream.
…tochastic_physics's master branh will gradually happen.
…/MPAS_stoch_physics_try_merge_stoch_master
…tochastic_physics code know that the dycore being used is MPAS.
…ill instead be defined in the Makefile for stochastic_physics only (in a separate commit into the stochastic_physics repo) since it is only needed by the stochastic_physics submodule.
…e that is now added in the Makefile in stochastic_physics).
…s the TEMPO tables.
| rk_step = 1 | ||
| dynamics_substep = 1 | ||
|
|
||
| ! apply random perturbation pattern to the tendency |
There was a problem hiding this comment.
tend_names being hardcoded here is a problem.
Is there a way to make it accessible in stochastic_physics_pattern_apply without being set here?
There was a problem hiding this comment.
Why is this a problem? If there's a way to query which tendencies are being allocated, we could use that here and select (from that list), which to perturb based on the physics suite and stochastic method in question.
There was a problem hiding this comment.
Two things. The tendencies being perturbed is hardcoded and not extensible. Also tend_names doesn't need to be set at each time-step before applying the pattern (i.e. this could be done during initialization once).
For example, if you extend stochastic_physics_pattern_apply to perturb more tendencies, you will also need to modify the MPAS source code here.
A solution would be to make tend_names an allocatable variable that is set during stochastic_physics_pattern_init, then referenced by stochastic_physics_pattern_apply. This way it is set once, and doesn't need to be passed through MPAS .
Also, this allows another host model (e.g., UFS) to control which fields we want to perturb when using stochastic physucs within MPAS. We plan on having tend_names part of the nam_stochy namelist to allow this runtime felxibility.
| endif | ||
| #endif | ||
|
|
||
| if (dosppt(domain)) then |
There was a problem hiding this comment.
Could this call be moved out of atm_do_timestep into into atm_core_run?
Just before the call the atm_do_timestep?
|
HI Dustin,
The tend_names array is just a temporary local variable used to pass
whatever needs to be perturbed to the
'stochastic_physics_pattern_apply(...)' subroutine. This local variable is
reused several times within the subroutine, so it cannot be initialized
outside the subroutine or specified in a namelist. (Maybe we can rename the
array to a more general name, since It will also be used for SKEB and SHUM
for non-tendency fields.)
We can discuss where to call the stochastic_physics_pattern_apply(...)
routine. I initially placed it immediately before and after
physics_get_tend(...) for code readability, as that is where the tendencies
from the physics parameterization are gathered.
Ning
…On Wed, May 13, 2026 at 3:07 PM Dustin Swales ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/core_atmosphere/dynamics/mpas_atm_time_integration.F
<#239 (comment)>
:
> @@ -1077,11 +1080,28 @@ subroutine atm_srk3(domain, dt, itimestep, exchange_halo_group)
call mpas_timer_start('physics_get_tend')
rk_step = 1
dynamics_substep = 1
+
+! apply random perturbation pattern to the tendency
Two things. The tendencies being perturbed is hardcoded and not
extensible. Also tend_names doesn't need to be set at each time-step before
applying the pattern (i.e. this could be done during initialization once).
For example, if you extend stochastic_physics_pattern_apply
<https://github.com/dtcenter/stochastic_physics/blob/2f6eace83f662db2ee16cad8f831c012e7be92f5/mpas_stochastic_physics.F#L284>
to perturb more tendencies, you will also need to modify the MPAS source
code here.
A solution would be to make tend_names an allocatable variable that is
set during stochastic_physics_pattern_init, then referenced by
stochastic_physics_pattern_apply. This way it is set once, and doesn't
need to be passed through MPAS .
Also, this allows another host model (e.g., UFS) to control which fields
we want to perturb when using stochastic physucs within MPAS. We plan on
having tend_names part of the nam_stochy namelist to allow this runtime
felxibility.
—
Reply to this email directly, view it on GitHub
<#239 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMHAC4KQ57BAMU3PZVMHYOD42TPZZAVCNFSM6AAAAACXIFTY4GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHM2DEOBVGM3DGNBUGM>
.
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:
***@***.***>
|
Hi @NingWang325. Sometimes lines of code are easier than words. Please see this proposed change to stochastic_physics. All that this does is move the hardcoding of assigning tend_names out of the time-integration phase of MPAS and into the initialization phase of stochastic-physics |
…mes (not including initial output) that are 12 minutes apart.
…i.e. correct the name of the physics suite in the name of the directory).
…c physics; clean up comments in the CI test workflow file.
…ochastic physics.
… the list of variables to output in the history*.nc files.
|
@gsketefian, once @dustinswales' changes are merged into both PRs, can you run the MPAS-Model CI test using the 'hrrrv5' physics suite with SPPT? It should hopefully work as expected (no r[u/v]cuten perturbations will be applied). Thanks! |
|
@gsketefian I see a new stochastic-physics test with a green check mark! |
…d into the artifact (useful when the artifact is too large, e.g. for downloading in a reasonable time, if all files in the run directory are included).
6 participants
This PR enables use of the SPPT scheme of stochastic physics into MPAS-Model. This is addressed in Issue #204.
Main changes:
stochastic_physicscode as a submodule.Makefiles, registryxmlfiles, and fortran files to allow the SPPT stochastic scheme to bue used with MPAS.stochastic_physicscode as a submodule. There is a companion PR into the authoritativestochastic_physicsrepo here.Note that this PR still requires
maketo be used to build MPAS-Model with stochastic physics. The ability to build withcmakewill come in a separate PR.Mandatory Questions
Priority Reviewers