generated from NOAA-OWP/owp-open-source-project-template
-
Notifications
You must be signed in to change notification settings - Fork 4
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
Ptl add adaptive timestep #25
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ajkhattak
requested changes
Jun 11, 2024
…he config file, it defaults to false.
…as the smallest adaptive time step for the rest of the model. If the adaptive time step is off, the giuh time step will be the same as the timestep input in the config file.
…ive time step strategy does not alter the function in giuh.c because this function is used in multiple models. So, the adaptive time step method has been altered such that the giuh is computed at the hourly time step rather than at the sub timestep. This allows for the giuh fxn to be unaltered, and has the added bonus of not reqiring resampling for the giuh based on time step.
…ng from min and max time step values
… removing hardcoding for internal time steps and replacing with user specified minimum time step, and establishing a maximum time step equal to the forcing resolution
peterlafollette
force-pushed
the
PTL_add_adaptive_timestep
branch
from
June 11, 2024 19:55
0f480b9
to
38e8037
Compare
ajkhattak
approved these changes
Jun 26, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me!
hellkite500
pushed a commit
to hellkite500/LGAR-C
that referenced
this pull request
Jul 10, 2024
* adding the capability for an adaptive time step. If not provided in the config file, it defaults to false. * updating readme * updating readme * updating giuh fxn with adaptive time step * giuh now uses a fixed time step that is hardcoded to be the the same as the smallest adaptive time step for the rest of the model. If the adaptive time step is off, the giuh time step will be the same as the timestep input in the config file. * updating readme in configs * cleaned up code that was used for debugging * updating Phillipsburg config file * cleaned up code that was used for debugging * After chatting with Ahmad, we determined that it is best if the adaptive time step strategy does not alter the function in giuh.c because this function is used in multiple models. So, the adaptive time step method has been altered such that the giuh is computed at the hourly time step rather than at the sub timestep. This allows for the giuh fxn to be unaltered, and has the added bonus of not reqiring resampling for the giuh based on time step. * updating in response to comments, mostly focused on removing hardcoding from min and max time step values * more changes in response to comments, including formatting of giuh.c, removing hardcoding for internal time steps and replacing with user specified minimum time step, and establishing a maximum time step equal to the forcing resolution * removing code that was commented out --------- Co-authored-by: Peter La Follette <[email protected]> Co-authored-by: Peter La Follette <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adaptive time step was added and tested for stability.
Additions
-The model can now run with an adaptive time step. The adaptive time step can be turned on or off in the config file. If it is not specified in the config file, it defaults to false. The time step is equal to the forcing resolution when precip and ponded head are 0, which saves a lot of runtime in arid areas where large periods of time will not have precip. The time step is equal to two times a user specified minimum time step when the precip is less than or equal to 1 cm/h and there is no ponded head. The time step is equal to a user specified minimum time step (which is just taken from "timestep" in the config file when "adaptive_timestep" is set to true) when ponded head is greater than 0, or when precip is greater than 1 cm/h. The time step can not be greater than the forcing data resolution, and this is enforced.
Removals
Changes
-Updated README in configs to include adaptive_timestep.
-The giuh convolution integral is now computed at the temporal resolution of the forcing data rather than at the resolution of the sub timestep. The giuh ordinates are still resampled, but to the resolution of the forcing data rather than to the internal time step, which effectively means that the giuh ordinates are not resampled if the forcing data resolution is 1 hour.
-Discovered a bug where theta is very close to theta_r, and convergence might be possible, but the function lgar_theta_mass_balance doesn't converge after a few minutes. The bug comes from the fact that the condition (fabs(delta_mass - delta_mass_prev) < 1E-15) doesn't trigger; the change in mass is indeed small, but it is 1E-11 rather than 1E-15 and changes very slowly, just because of the sensitivity of the theta-psi relationship for some parameter sets in particular. Rather than changing the tolerance to be less strict, I added a new check where the loop will break for extremely large psi values, which have limited physical meaning in the first place.
-Changed the psi value at which calc_Se_from_h returns 1.0 to be 1E-10 rather than 1E-1, making the function accurate for small psi values. There are some cases where we need Se values that are very close to but slightly less than 1, for psi values that are less than 1E-1.
Testing
Screenshots
Notes
Todos
Checklist
Testing checklist
Target Environment support
Accessibility
Other