-
Notifications
You must be signed in to change notification settings - Fork 6
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
DiscreteControl doesn't seem to pass correct control_state to Outlets #1637
Comments
Thanks for the report. Good to look into this
Have you looked at |
Hi @visr , is this one to check before pushing out the release ? |
I don't really see an error, but perhaps I am misunderstanding. In any case this should be done with ContinueousControl once #1602 is released. What I don't follow is you seem to expect that the upstream Basin level is equal to the set @DanielTollenaar feel free to reopen if I miss something. |
What dit we do
We build a model with DiscreteControl node (node_id 1000002):
For the remainder we focus on the diversion at Borgharen (node_id = 7764), Julianakanaal (node_id = 7925) and verbindingskanaal (node_id = 7759). We use a steady-state model with bc 450 m3/s at Monsin available via transfer: https://we.tl/t-Ybsly5S9hX
Expected result
At 450 m3/s we would be at control_state
Monsin_186
(see DiscreteControl / condition):That would give us an
min_crest_level
at node_id's 7759, 7764 and 7925 of 44.21 m NAP (see Outlet / static). Thereby we would expect a water-level at the upstream Basin (node_id 7706) of +/- 44.2 m NAP:Actual result
We see a water-level of > 48.09m NAP at Basin 7706, which is much higher than expected. This level corresponds at the highest control_states in our table, which should apply at discharges > 7100 m3/s at Monsin:
Additional information
Our analysis stops here, we suspect the controller some-how got lost. If we could see the actual
crest_level
ofOutlet
during simulation, andcontrol_state
atDiscreteControl
we could verify further. Would it be an idea to user-define storage of results for different node-types in a results-section of the toml-file (following SOBEK functionality)?The text was updated successfully, but these errors were encountered: