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

Fix for instances of dt = 0 when using adaptive time stepping #1398

Merged
merged 1 commit into from
Feb 12, 2021
Merged

Fix for instances of dt = 0 when using adaptive time stepping #1398

merged 1 commit into from
Feb 12, 2021

Conversation

weiwangncar
Copy link
Collaborator

@weiwangncar weiwangncar commented Feb 8, 2021

Fix for instances of dt = 0 when using adaptive time stepping

TYPE: bug fix

KEYWORDS: adaptive time stepping, time step

SOURCE: internal, reported from two sources

DESCRIPTION OF CHANGES:
Problem:
When using adaptive time stepping, and when option step_to_output_time is used, time step can be zero and cause the model to stop. The problem occurs in part because the function real_time becomes less accurate when feeding a large value of time interval, i.e. time since the simulation start time.

Solution:
This PR fixes the issue by changing the time interval calculation from relative to simulation start time to model start time, i.e. restart time.

ISSUE: For use when this PR closes an issue.
Fixes #1369

LIST OF MODIFIED FILES:
M dyn_em/adapt_timestep_em.F

TESTS CONDUCTED:

  1. Test shows the fix prevents dt=0 from occurring in a case previously failed.

This is some prints from a failed run:
Timing for main (dt=293.68): time 2001-07-07_08:00:52 on domain 1: 0.16209 elapsed seconds
Timing for main (dt=296.62): time 2001-07-07_08:05:48 on domain 1: 0.78269 elapsed seconds
Timing for main (dt=299.59): time 2001-07-07_08:10:48 on domain 1: 0.16217 elapsed seconds
Timing for main (dt=299.59): time 2001-07-07_08:15:48 on domain 1: 0.15795 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:20:48 on domain 1: 0.78560 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:25:48 on domain 1: 0.15789 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:30:48 on domain 1: 0.16164 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:35:48 on domain 1: 0.77986 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:40:48 on domain 1: 0.16140 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:45:48 on domain 1: 0.15741 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:50:48 on domain 1: 0.78672 elapsed seconds
Timing for main (dt=264.00): time 2001-07-07_08:55:12 on domain 1: 0.15702 elapsed seconds
d01 2001-07-07_08:55:12+04/25 L353 dtInterval are 287 21 25 0
Timing for main (dt=287.84): time 2001-07-07_09:00:00 on domain 1: 0.19389 elapsed seconds
Timing for Writing wrfout_d01_2001-07-07_09:00:00 for domain 1: 1.69693 elapsed seconds
d01 2001-07-07_09:00:00 L353 dtInterval are 0 0 25 0

After the fix:
Timing for main (dt=293.77): time 2001-07-07_08:01:12 on domain 1: 0.16144 elapsed seconds
Timing for main (dt=296.71): time 2001-07-07_08:06:09 on domain 1: 0.78215 elapsed seconds
Timing for main (dt=299.68): time 2001-07-07_08:11:08 on domain 1: 0.16142 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:16:08 on domain 1: 0.15739 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:21:08 on domain 1: 0.78563 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:26:08 on domain 1: 0.15712 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:31:08 on domain 1: 0.16140 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:36:08 on domain 1: 0.78050 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:41:08 on domain 1: 0.16107 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:46:08 on domain 1: 0.15700 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_08:51:08 on domain 1: 0.78609 elapsed seconds
Timing for main (dt=265.54): time 2001-07-07_08:55:34 on domain 1: 0.15656 elapsed seconds
d01 2001-07-07_08:55:34+93/** L353 dtInterval are 265 107 200 0
Timing for main (dt=265.54): time 2001-07-07_09:00:00 on domain 1: 0.19076 elapsed seconds
Timing for Writing wrfout_d01_2001-07-07_09:00:00 for domain 1: 1.70416 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_09:05:00 on domain 1: 2.48374 elapsed seconds
Timing for main (dt=300.00): time 2001-07-07_09:10:00 on domain 1: 0.16118 elapsed seconds

  1. Passed all Jenkins tests.

RELEASE NOTE: Fix for reported instances of dt = 0 when using adaptive time stepping together and when step_to_output_time is set to true.

@davegill
Copy link
Contributor

davegill commented Feb 9, 2021

@weiwangncar
Did this fix one of the known trouble cases? If so, can we report that?

There are adaptive time step cases in the regression test. Would you include the jenkins status in this PR commit message.

@weiwangncar
Copy link
Collaborator Author

@davegill It passed all Jenkins tests:

Test Type              | Expected  | Received |  Failed
= = = = = = = = = = = = = = = = = = = = = = = =  = = = =
Number of Tests        : 19           18
Number of Builds       : 48           46
Number of Simulations  : 163           161        0
Number of Comparisons  : 103           102        0

Failed Simulations are: 
None
Which comparisons are not bit-for-bit: 
None

@weiwangncar weiwangncar merged commit b71e0a8 into wrf-model:develop Feb 12, 2021
vlakshmanan-scala pushed a commit to scala-computing/WRF that referenced this pull request Apr 4, 2024
… stepping (wrf-model#1398)

Fix for instances of dt = 0 when using adaptive time stepping

TYPE: bug fix

KEYWORDS: adaptive time stepping, time step

SOURCE: internal, reported from two sources

DESCRIPTION OF CHANGES:
Problem:
When using adaptive time stepping, and when option step_to_output_time is used, time step can be zero and cause the model to stop. The problem occurs in part because the function real_time becomes less accurate when feeding a large value of time interval, i.e. time since the simulation start time.

Solution:
This PR fixes the issue by changing the time interval calculation from relative to simulation start time to model start time, i.e. restart time.

ISSUE: For use when this PR closes an issue.
Fixes wrf-model#1369

LIST OF MODIFIED FILES:
M dyn_em/adapt_timestep_em.F

TESTS CONDUCTED:

- Test shows the fix prevents dt=0 from occurring in a case previously failed.
- Passed all Jenkins tests.

RELEASE NOTE: Fix for instances of dt = 0 when using adaptive time stepping together and when step_to_output_time is set to true.
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