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. There are three different internal time steps: 1/12 hrs, 1/6 hrs, and 1 hr. The time step is 1 hr 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 1/6 hrs when the precip is less than or equal to 1 cm/h and there is no ponded head. The time step is 1/12 hrs (the value we have been using for the vast majority of LGAR's development) when ponded head is greater than 0, or when precip is greater than 1 cm/h.
Removals
Changes
-Updated README in configs to include adaptive_timestep.
-If the model uses a fixed time step, then the GIUH ordinates and queue are unaffected (the model time step and resolution of the GIUH ordinates and queue will be the same). However, when the model uses an adaptive time step, the GIUH ordinates and queue are initialized with the smallest internal time step, which is 5 minutes. Input for the GIUH convolution integral is then always resampled to match its resolution. Therefore, the model time step is adaptive, but the resolution of the GIUH queue / ordinates are fixed. An alternative approach I developed but decided against was to just compute the GIUH at the hourly resolution, as the model outputs hourly data.
-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