Add flow limiter (step_limiter!)
#1904
Conversation
|
It is indeed a fix for #1900, which is one way in which the flows have to be 'tamed' as discussed in #1897. Even though it is not a global fix, I think this PR is a helpful one, as it enforces properties of the solution which we want to be strictly true for any set of solver settings, e.g.
With the ever increasing norm of the state there is still the possibility that the solution slowly drifts away from the physics in ways we cannot capture in the |
| @@ -718,3 +699,114 @@ function formulate_flows!( | |||
| formulate_flow!(du, user_demand, p, t, current_storage, current_level) | |||
| end | |||
| end | |||
|
|
|||
| """ | |||
| Clamp the cumulative flow states between bounds given my minimum and maximum | |||
There was a problem hiding this comment.
| Clamp the cumulative flow states between bounds given my minimum and maximum | |
| Clamp the cumulative flow states between within the minimum and maximum |
| allocation, | ||
| ) = p | ||
|
|
||
| # TabulatedRatingCurve |
There was a problem hiding this comment.
It would be good to also describe what/how/why is being limited here. In this case, we know that a TaublatedRatingCurve has a flow bounded by [0.0, Inf] and has an active component?
| ) | ||
| end | ||
|
|
||
| # Pump |
There was a problem hiding this comment.
This one requires less documentation, because it uses the Pump properties directly?
Fixes #1900.
Drainage infiltration MWE
Main branch
This branch
Conclusions
Having zero forcing when zero forcing is expected is now enforced properly. In the same way, I'm pretty sure forcing will now never exceed the given flux, and flow should be non-negative where expected.
Having total forcing when the basin is not in the low storage factor regime is harder to enforce, because there is no exact way to infer whether the basin storage passed through the reduction factor regime in the last timestep. A conservative heuristic might suffice here though.
Performance comparisons
Main branch
this branch