Skip to content
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

Rework check_timestep to be based on change_max #844

Merged
merged 6 commits into from
Apr 10, 2020
Merged

Conversation

maxpkatz
Copy link
Member

@maxpkatz maxpkatz commented Apr 9, 2020

PR summary

check_timestep is currently effectively useless for CFL violations that occur as the result of an advance, since it only refers to old data, and for burning timestep limiting it uses an average of the old and new data. With this change, we unify how they are used so that they both refer to only the new data, and reject any timestep that would cause dt to shrink by more than a factor of change_max. check_timestep is now effectively the inverse operation of how change_max is used in estdt: whereas in estdt, change_max allows the timestep to grow by no more than that factor, in
check_timestep it allows the timestep to shrink by no more than that factor without doing a retry. In effect, this prevents the state from changing too much in either direction in a single timestep.

PR checklist

  • test suite needs to be run on this PR
  • this PR will change answers in the test suite
  • all functions have docstrings as per the coding conventions
  • the CHANGES file has been updated
  • if appropriate, this change is described in the docs

check_timestep is currently effectively useless for CFL violations that
occur as the result of an advance, since it only refers to old data, and
for burning timestep limiting it uses an average of the old and new data.
With this change, we unify how they are used so that they both refer to
only the new data, and reject any timestep that would cause dt to shrink
by more than a factor of change_max. check_timestep is now effectively the
inverse operation of how change_max is used in estdt: whereas in estdt,
change_max allows the timestep to grow by no more than that factor, in
check_timestep it allows the timestep to shrink by no more than that factor
without doing a retry. In effect, this prevents the state from changing too
much in either direction in a single timestep.
@zingale
Copy link
Member

zingale commented Apr 10, 2020

@zingale zingale merged commit 835e5ad into development Apr 10, 2020
@zingale zingale deleted the check_timestep branch April 10, 2020 01:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants