-
Created by
Klaudia Horváth, last updated on 04-02-2026
8 minute read
(Some smaller fixes are not listed here, only the larger changes)
2025.08.25. (svn478-481) Fix shortage calculation for "HandhavingPeil". It was too much shortage, because "realisatie" was not calculated correctly. Now "HandhavingPeil" is calculated on nodes and branches and summed up.
2025.07.18 (svn477) Undo commit 476 and fix handhaving peil demand on nodes. This results in higher shortages. When we removed (svn467) the "HandhavingPeil" demand from the large water bodies, it was accidentally removed from all the nodes. This is about 10 locations, including WMWest demand, where it can be about 2.5 m3/s. In this commit we fix it, and add it back. That means an increase in shortages, due to the increase of demand. For a tested year it can be maximum 5m3/s per region, in average it is less than 1m3/s per region.
2025.03.13. (svn469) Remove watertekort from the lakes from LHM import
2025.03.12. (svn467) Remove NWPeilwatervraag from the following QWAST branches: IJsselmeer, IJsselmeer Uitlaat, Markermeer_Doorvoer_IJsselmeer, Zuiderzeeland_DoorvoerMM_RM, Randmeren_LozingOp_MM because it is already taken into account because they have volume. Fix: NWPeilwatervraag was not applied to any other branches, it is fixed now.
Fix the NWPeilwatervraag that was not assigned correctly to all branches (was underestimated for most branches, similar to NR demand, for QIn).
The water demand to keep the waterbodies level (NWPeilwatervraag) is set in QWAST as QIn, QWAST requires so much water to enter to the given branch. However, there are 3 water bodies with volume in QWAST, hence having their own demand for keeping the level, so the corresponding LHM water demand should not be coupled to them. Until this version this demand was coupled to these branches, from this version these demands are removed. There are the following:
DM element | QWAST element |
IJsselmeer and Randmeren Noord | IJsselmeer |
IJsselmeer NoordOost | IJsselmeer Uitlaat |
IJsselmeer NoordWest | IJsselmeer Uitlaat |
Markermeer (6058) | Markermeer_Doorvoer_IJsselmeer |
Randmere Oost (6059) | Zuiderzeeland_DoorvoerMM_RM |
Eemmeer | Randmeren_LozingOp_MM |
2025.03.07. (svn463) Model fails when physical limitations are not met
2025.03.04. (svn460) Make default flushing (if chl is high by Kinderdijk) zero instead of 30 for Lek-Hagestein. For the validation it was left (accidentally) at 30.
2025.02.28. (svn459) Increase capacities to be able to deliver water demand: NKKanaal_Uitlaat from 10 to 14 and Zaan_LozingOp_NZK from 2 to 2.5. These actions will stop the constant shortage at region Noord-Holland.
2025.02.27. (svn455) Bernhard sluizen maximum limiting discharge relationship is corrected
2025.02.18. (svn451) Include solver fallback option. Note: the solver flag is also removed from global properties, as it has no meaning any more
2025.02.18. (svn450) Doorspoel vraag (flushing demand) is now considered to be satisfied also if the flow is going to the other direction.
2025.02.14. (svn449) Upgrade RTC-Tools to 2.7.0a3
2025.02.14. (svn448) DM knoop DMknoop_60401, Nieuwegein is coupled to Doorslag aanvoerder instead of Beatrixsluizen because there was a doospoelvraag that was higher than its capacity
2025.02.10. (svn446) Include HandhavingPeil on the demand nodes (before this term was not taken into account as demand but the shortage was calculated)
2025.02.05. (svn444) Fix id map for chloride import and fix the calculation of shortages on region level for the display
2025.01.30. (svn440) Set the default capacity of Bernhardsluizen to 100, and it is a setting to decrease the capacity based on Lobith discharge
2025.01.30. (svn437) Set back the default capacity of the branch Krimpenerwaard to zero (from 5.5) to be compatible with BP18. For the new LHM it should be 5.5.
List of changes in QWAST between 2025.01.30 and the BP (2019.10.16) per category
Here only the changes are listed that could possibly have effect on the calculation results. The changes are grouped by functionality to make the search easier.
General changes
2024.07.04. Chloride location was changed from to 17618 (from 14828). This means much higher chloride values. Location “HollandseIJssel1_17618.000” is on the Hollandsche IJssel side of the Hollandse IJssel storm surge barrier (Algera barrier). In the LSM/RMM model, QWAST now apparently uses location (Sobek calculation point, not observation point) “HollandseIJssel1_14829.000”. That is 2.8 km further upstream. I think it would be better to use the location closer to the barrier, so I would rather use that 17618.00 location. From a random LSM sum within NWM, I see the following progression for these 2 locations, fairly comparable, but of course it is about when the threshold value is exceeded. That is the case earlier/more often at location 17_618.00.
2024.07.04. Some small changes to make the optimization more stable, (minimums and maximums) that can cause slight difference in output.
2019.12.28. Implement small changes to correct the treatment / reading of district demand (probably after validation, before calculation of the measures, commits 234, 235, 236, 258, 307, 311)
2020.01.23. Amsterdam Zuidoost and Centraal Dommel belongs to the correct region
2020.03.13. Dm tak Krimpenerwaard is also coupled (DMtak_4040)
2020.08.05. The branch ARK_ZeesluisMuiden_MM is now closed in the direction to Markermeer, Evaporation is added to TotalenGebieden calculation
2024.05.15. Fix: the level of the lakes started winter 2 October instead of 1, FIX
2024.06.28. Fix: Before only the branches (takken) were included and not the nodes (knopen), now it is the general term (QSTlateralen). It means that before the region values might have been underestimated.
2024.07.01 Fix: For Hoofdwatersysteem the multiplier for NW_HandhavingMinPeil was set to zero. That means that the demand was not used.
2024.08.22. LHM: Nieuwe wateweg is part of the Hoofdwatersysteem instead of Zuid Westelijk estuariumgebied - met aanvoer - this is important when putting multipliers or post-processing for regions.
2024.09.19. LHM: Increase maximum (not conditional) capacity of KWA_Krimpenerwaard branch to be able to accommodate the continuous LHM flushing discharge from zero to 5.5
Different discharge distribution / different elevation
2022.03.09. (svn333) The bottom elevation becomes scenario dependent
2022.09.07. (svn335) The scenario dependency is removed, it it is a global property and the user can choose which elevation to be used
2024.04.17 (svn381) 2018 is the default
2024.06.07. (svn398) Verdeelsleutels updated, based on Excel sheet van Geert, based on IRM corr calculation, which is based on D-Hydro calculations and a correction
Lake levels
Markermeer
2023.06.16. (svn 357) PEIL Change the peilbeheer of Markermeer: now it is the same as IJsselmeer, you can use the "najaarpeil". Randmeren stay the same, no "najaarpeil." For Markermeer, most of the periods the min zomer is just changed to min najaar, so it is just an option. However, between 03.12-03.21, the streef zomer is changed to max zomer, so this is indeed a difference.
03.12 - 03.21 Min goal prio 13 Instead of streef zomer , but H_max_zonder
08.22-09.01 Min goal prio 13 is: Instead of (streef zonder+min zomer)/2 it is (streef zonder+min najaar)/2
09.02-10.01 Min goal prio 13 is: Instead of Hmin zomer it is Hmin najaar
08.22-09.01 Max goal prio 13 is: Instead of (streef zomder+min zomer)/2 it is (streef zomder+min najaar)/2
09.02-09.21 Max goal prio 13 is: Instead of (streef zonder+min zomer)/2 it is (streef zomder+min najaar)/2
09.22-10.01 Max goal prio 13 is: Instead of Hmin zomer it is Hmin najaar
2024.05.15. (svn388) Markermeer: change the switch between 10.01 and 10.02 to 09.30 to 10.01
2024.07.04. (svn414) Introduce winter streef peil, it is used often to H min winter. It is a possible setting, not a difference (if the default H min winter and H streef winter is the same)!
10.01-03.01 Min goal prio 13: Instead of H min winter is H streef winter
03.02-03.12 Min goal prio 13: Instead of (H max zomer + H min winter)/ 2 is (H max zomer + H streef winter)/ 2
10.01-03.01 Max goal prio 13: Instead of H min winter is H streef winter
03.02-03.12 Max goal prio 13: Instead of (H max zomer + H min winter)/ 2 is (H max zomer + H streef winter)/ 2
2024.07.10. (svn422) Introduce winter streef peil in other periods, it is used often to H min najaar. It does not cause difference with the defaults.
08.22-09.01 Min goal prio 13: Instead of (H streef zomer + H min najaar)/2 is (H streef zomder + H streef winter ) / 2
09.02-09.30 Min goal prio 13: Instead of H min najaar is H streef winter
08.22-09.01 Max goal prio 13: Instead of (H streef zomer + H min najaar)/2 is (H streef zomder + H streef winter ) / 2
09.02-09.30 Max goal prio 13: Instead of (H streef zomer + H min najaar)/2 is (H streef zomder + H streef winter ) / 2
Randmeren
2024.07.04. (svn414) This change made it possible for the user to give a winter desired level. With the default settings it does not cause any change. The excel documentation file of the "Randmeren" should be updated.
10.22-03.01 Max goal prio 13: Instead of H min winter is H streef winter
03.02-03.11 Max goal prio 13: Instead of (H max zomer + H min winter)/ 2 is (H max zomer + H streef winter)/ 2
03.12-03.21 Max goal prio 13: Instead of (H max zomer + H min winter)/ 3 is (H max zomer + H streef winter)/ 3
10.12-10.21 Max goal prio 13: Instead of (H max zomer + H min winter)/ 3 is (H max zomer + H streef winter)/ 3
IJsselmeer
2019.07.23. (svn217) This change introduces the concept of "min najaar" level. The default value is the same as min zomer, so it does not change the behaviour.
08.22-09.01 Min goal prio 13 is: Instead of (streef zomer+min zomer)/2 it is (streef zonder+min najaar)/2
09.02-10.01 Min goal prio 13 is: Instead of Hmin zomer it is Hmin najaar
08.22-09.01 Max goal prio 13 is: Instead of (streef zomer+min zomer)/2 it is (streef zomder+min najaar)/2
09.02-09.21 Max goal prio 13 is: Instead of (streef zomer+min zomer)/2 it is (streef zomder+min najaar)/2
09.22-10.01 Max goal prio 13 is: Instead of Hmin zomer it is Hmin najaar
2024.05.15. (svn388) IJsselmeer: change the switch between 10.01 and 10.02 to 09.30 to 10.01
2024.07.04. (svn414) Introduce winter streef peil, it is used often to H min winter. It is a possible setting, not a difference (if the default H min winter and H streef winter is the same)!
10.01-03.01 Min goal prio 13: Instead of H min winter is H streef winter
03.02-03.12 Min goal prio 13: Instead of (H max zomer + H min winter)/ 2 is (H max zomer + H streef winter)/ 2
10.01-03.01 Max goal prio 13: Instead of H min winter is H streef winter
03.02-03.12 Max goal prio 13: Instead of (H max zomer + H min winter)/ 2 is (H max zomer + H streef winter)/ 2
2024.07.10. (svn422) Introduce winter streef peil in other periods, it is used often to H min najaar. It does not cause difference with the defaults.
08.22-09.01 Min goal prio 13: Instead of (H streef zomer + H min najaar)/2 is (H streef zomer + H streef winter ) / 2
09.02-09.30 Min goal prio 13: Instead of H min najaar is H streef winter
08.22-09.01 Max goal prio 13: Instead of (H streef zomer + H min najaar)/2 is (H streef zomer + H streef winter ) / 2
09.02-09.21 Max goal prio 13: Instead of (H streef zomer + H min najaar)/2 is (H streef zomer + H streef winter ) / 2
Values
2019.07.23. (svn217) Introduce Hmin_najaar, -0.4 for all three lakes
2023.06.16. (svn357) Remove value Hmin_najaar from randmeren (it is not used anyway)
2024.04.24. (svn382) New defaults for LHM: Hstreef_zomer is instead of -0.2 is -0.15
Bernhardsluizen
The changes in Bernhardsluizen: now it is possible to set minimum and maximum capacity depending on the discharge at Lobith. Note: now the default is 60 m3/s below the limit and 5 m3/s above. Before it was maximum 100 m3/s.
