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

Finetune step_limiter! #1912

Merged
merged 12 commits into from
Oct 25, 2024
Merged

Finetune step_limiter! #1912

merged 12 commits into from
Oct 25, 2024

Conversation

SouthEndMusic
Copy link
Collaborator

@SouthEndMusic SouthEndMusic commented Oct 21, 2024

Follow-up of #1911.

Fixes #1897 (?).

Fixes #1838 (how could we test that negative flows where they should not be no longer occur? Maybe add a callback that explicitly checks for non-decreasing states)

I focus in this PR on UserDemand inflow and infiltration because of their importance in coupling.

@SouthEndMusic
Copy link
Collaborator Author

@evetion you might appreciate this first commit; it gets rid of many of the magic hardcoded numbers for threshold values.

@SouthEndMusic
Copy link
Collaborator Author

SouthEndMusic commented Oct 21, 2024

@rleander this is an interesting one for you, this one together with #1911 should fix the problems you noticed, in particular: infiltration and realized user demand should no longer drift away from their demands as the simulation goes on (when the basin does not run dry).

@SouthEndMusic SouthEndMusic requested a review from evetion October 24, 2024 08:28
Copy link
Member

@evetion evetion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some general comments:

For the next time, please refactor in separate PR's, mixing it makes the PR and the git history in the future hard to read. I do like the refactor, tackling the magic numbers and the basin complexity 👍🏻.

Could you provide a comment in the PR description on what you introduce and why? I'll give more detailed comments in the code below.

After reading it completely, my main confusion is that we clamp the minimum flow out of a basin and not the maximum flow? I thought the reduction factors trigger so a (maximum) flow cannot empty a basin.

core/src/util.jl Show resolved Hide resolved
core/src/model.jl Show resolved Hide resolved
core/src/parameter.jl Show resolved Hide resolved
core/src/parameter.jl Show resolved Hide resolved
core/src/parameter.jl Show resolved Hide resolved
core/src/solve.jl Show resolved Hide resolved
core/test/utils_test.jl Show resolved Hide resolved
core/src/solve.jl Show resolved Hide resolved
core/src/solve.jl Show resolved Hide resolved
core/src/util.jl Outdated Show resolved Hide resolved
@SouthEndMusic SouthEndMusic merged commit 201b18f into main Oct 25, 2024
27 checks passed
@SouthEndMusic SouthEndMusic deleted the limiter3 branch October 25, 2024 11:59
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.

Taming cumulative flows Document known issue: (small) negative flows from e.g. Terminals
3 participants