Setting a final reservoir level - UC APG CR 25 #1145
Replies: 6 comments 5 replies
-
|
From my understanding, this change comes in two parts:
Let's say that the 1st part only requires development. However, the 2nd part is somewhat trickier. You mentioned it, infeasible problems can appear in some cases when inflows are too low or too high to reach the final level. Another issue is overflows. The reservoir level cannot go above 100%, so when it does, water is lost to overflow, it "disappears". This constraint is imposed in 2 ways depending on the configuration (condition to be checked)
In both cases, the overflow is unknown before running the yearly simulation. As a consequence, so is the final level since Final level = Initial level + inflows + efficiency*pumped - turbined - overflow It is my opinion that a bit more R&D work is required to properly handle overflows. Discussions are ongoing internally on that topic. That's the only difficulty I identify. |
Beta Was this translation helpful? Give feedback.
-
|
When there are overflows, the final reservoir level won't be reached. There is no easy way to change it for now as you said. |
Beta Was this translation helpful? Give feedback.
-
Initial levels are given in sc. builder data. For the sake of consistency, final levels should be as well. If no final level is provided by the user, we should stick to the current, default behavior. |
Beta Was this translation helpful? Give feedback.
-
|
If we make scenarios for rule curves, then I think it would make sense to define initial and final levels inside of the first and final day of the rule curves. If we don't, we'll have to make sure that when we select which scenario to use for the rule curve, the initial and final reservoir levels we specify for that year are compatible with it. We could also only need one tab in the reservoir builder window, instead of 3 as we would end up doing right now. |
Beta Was this translation helpful? Give feedback.
-
They are specified in the sc. builder data, under tag "hl". Note that this initial level may apply to Jan 1st, but also Feb 1st, etc. It may be the case also for final levels. You may consider partial years, or forbid them (partial year & final level are incompatible options). |
Beta Was this translation helpful? Give feedback.
-
|
As the hydro heuristic is done for the whole year, the final reservoir level specified will have to mean "final reservoir level at the end of the year" and not "final reservoir level at the end of the simulation period". Changing that would require substantially more work as it would mean modifying the heuristics in depth. Moreover, some users might want to use a "final reservoir level at the end of the year" even while computing part of a year. So I think this is what we should be going for. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
How to conduct pre-check 1 if the initialization of the reservoir level is not set to January!? |
Beta Was this translation helpful? Give feedback.
-
|
For the choice of the initial reservoir level, there are 2 possibilities:
See src/solver/simulation/solver.hxx. In my opinion, it's necessary to check that Where the 1st month is 1st month of the simulation, and last month is the last month of the simulation. Indeed, this check is only required if pumping = false. Otherwise it's possible to pump to try to reach the final reservoir level. |
Beta Was this translation helpful? Give feedback.
-
|
Hi all,
|
Beta Was this translation helpful? Give feedback.
-
Logic of the change
Setting a final reservoir level target for any reservoir.
The need is to allow the user to specify a final hydro reservoir level for any reservoir to be reached at the end of a given MC year. The final reservoir level can be different from one MC year to the other.
1. UI Change
2. File storage changes
The same files are to be used as nowadays. The only change will occur inside of the StudyPath/settings/scenariobuilder.dat file. Inside of this file, the data for the hydro final level should be called
hfl, areaName, year = value. We should not change the current way of storing hydro level data (hl -> hil), in order not to cause incompatibility problems.3. Pre-Launch checks
a) Before launching the simulation, Antares will check for each MC year that the reservoir level difference between the beginning and the end of the year is inferior to the yearly inflows: reservoir levelday 365 – reservoir levelday 1 ≤ yearly inflows. Otherwise, an error will be raised and the simulation will stop.
Note: This test should not be required if the asset has pumping capabilities and the heuristic can handle a negative import target. Is it the case today ?
b) Before launching the simulation, Antares will also check that the final reservoir level set by the user is within the rule curves for the final day. Otherwise, an error will be raised and the simulation will stop. If no final reservoir level is explicitly specified by the user, the default behavior is to use the initial reservoir level as a target. If the final reservoir level is not specified and the initial reservoir level is not within the rule, then no error is to be displayed, and the heuristic will aim for
final reservoir level = min (Final Lev High, max (Final Lev Low, Initial Reservoir level)).c) In case the reservoir is managed with one of the following modes:
- Water values only
- Water values with heuristics and definition of a leeway
The final reservoir level set by the user will be ignored and a warning will be displayed for the user.
d) Reaching the final reservoir level, different from the initial reservoir level value, is only possible if the simulation period is equal to 365 days (entire year). If the end of the simulation is set to a shorter period, or the reservoir level is not initialized in January, an error will be reported, and the simulation stopped.
4. Heuristic changes
The behavior of Antares needs to be modified to take into account this new constraint: for reservoirs which are in the reservoir management mode, the amount of yearly inflows to be allocated by the hydro heuristics needs to be adjusted to take into account the difference between the initial and the final reservoir level.
Normal, default Case, full year simulation with initial reservoir level in January
In Antares code monthly-heuristics is giving the following set of linear equations to the h20_monthly-solver:
ResLev-1 - ResLev-0 + Generation-0 = Inflows-0
ResLev-2 - ResLev-1 + Generation-1 = Inflows-1
[...]
ResLev-11 - ResLev-10 + Generation-10 = Inflows-10
ResLev-0 - ResLev-11 + Generation-11 = Inflows-11
*ResLev-els & Generation-s are variables while Inflows are constants on the RHS
**ResLev-0 is fixed -> upper and lower bounds -> Xmin=Xmax= Initial Reservoir Level
The last equation can be written as:
ResLev-11 - Generation-11 = ResLev-0 - Inflows-11
If we add$\Delta_{ResLev}$ (in % of reservoir level) to the last equation RHS:$\Delta_{ResLev}$ $\Delta_{ResLev}$ . We can do this adjustment directly in the h20_monthly_solver. However, this is equivalent to adding $\Delta_{Inflow}$ (in % of reservoir level) to the last equation RHS (or in fact to any of the 12 equations). So, we can just adjust the monthly inflow values before passing them to the h20_monthly_solver. It is important now to clarify that the adjustment of the inflows must be ONLY done for the MONTHLY heuristics. Inflow values passed to the DAILY heuristic must not be changed. Daily heuristic will reach the MOL and MOG with the available inflows.
ResLev-11 - Generation-11 = ResLev-0 - Inflows-11 +
Monthly-heuristics is going to set MOG (monthly optimal generations) and MOL (monthly optimal levels) so that at the end of the simulation, difference between ResLev-0 and final reservoir level is
Milos tested it and it seems to work as expected. The final reservoir level is always reached if possible (no overflows). With the proper amount of available inflows of course.
Note:
#### Reservoir level not initialized in January#### Simulation of a partial year### 5. Scenarization5. Testing
Overall Behaviour
It is necessary to verify that the user-specified final reservoir level is reached at the end of the simulation year.
It is also necessary to check if the correct error messages are triggered.
A simple test case is created to test the implementation. https://rteinternational.sharepoint.com/:u:/s/AntaresUser'sClub-Interne/Ea8R7E4NyaRMhVYqhEkxLpcBKL-1sTqR4mTlBaadY6-tVA?e=llNub6
An area named Area is added inside the test network.
The following features are added to the Area:
Jan | 100 MW / per hour
Feb-Apr | 50 MW / per hour
Maj-Avg | 150 MW / per hour
Sep-Nov | 50 MW / per hour
Dec | 100 MW / per hour
Jan-Apr | 5000 MWh / per day
Maj-Avg | 600 MW / per day
Sep-Dec | 1000 MWh / per day
Relevant global setting:
Created area: Area is copy-pasted and the new area is named Area-2. No links are created between the two areas. For Area-2, in the Scenario Builder, Hydro Final Levels are left as “init” for both MC years. If implemented correctly, for Area-2, Hydro Final Levels will be identical to Hydro Initial Levels at the end of the simulation.
Simulation is run.
Results for area: Area. In output column H.LEV[%]. At the final hour specified final reservoir level should be reached for both simulated MC years.
Results for area: Area-2. In output column H.LEV[%]. At the final hour reservoir level should be identical to the initial reservoir level for both simulated MC years.
Additional check. The sum of the output column H.INFL[MWh] for Area and Area-2 should be identical (applies for both MC-years). This verifies that daily/monthly inflow values were not corrupted when implementing the final reservoir level. The sum of output-inflow values should be the same as the sum of input-Hydro Storage values. But due to int rounding, it is hard to verify this.
Error Messages
Error triggering is checked using the same model, with different settings:
Questions:
Beta Was this translation helpful? Give feedback.
All reactions