Skip to content

Change default value of atmosphere core config_number_of_sub_steps from 2 to 4 - #1496

Open
mgduda wants to merge 1 commit into
MPAS-Dev:hotfix-v8.4.2from
mgduda:atmosphere/sub_steps_default_4
Open

Change default value of atmosphere core config_number_of_sub_steps from 2 to 4#1496
mgduda wants to merge 1 commit into
MPAS-Dev:hotfix-v8.4.2from
mgduda:atmosphere/sub_steps_default_4

Conversation

@mgduda

@mgduda mgduda commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

This PR changes the default value of the atmosphere core namelist option config_number_of_sub_steps from 2 to 4 in the Registry.xml file. This change addresses an issue in convection-permitting simulations where noise can sometimes appear in the jet streams using the previous default value (config_number_of_sub_steps = 2). The noise, when present, also produces unphysical features in horizontal kinetic energy spectra at high wavenumbers.

Note: Increasing the number of sub-steps from 2 to 4 can be expected to increase the computational cost of the dynamics by ~10%, and the computational cost of a full-physics simulation by ~5%.

…om 2 to 4

This commit changes the default value of the atmosphere core namelist option
config_number_of_sub_steps from 2 to 4 in the Registry.xml file. This change
addresses an issue in convection-permitting simulations where noise can
sometimes appear in the jet streams using the previous default value
(config_number_of_sub_steps = 2). The noise, when present, also produces
unphysical features in horizontal kinetic energy spectra at high wavenumbers.
@mgduda
mgduda marked this pull request as ready for review July 28, 2026 23:27
@mgduda
mgduda requested a review from jeguerra-2025 July 28, 2026 23:27

@jeguerra-2025 jeguerra-2025 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a fine default setting if it promotes an overall more stable time integration of the model. I'm confident it does. But, if it results in a ~10% runtime penalty, can we look for a way of compensating for that added cost? Does the added stability allow us to use a slightly longer time step for example?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants