Time horizon management

[SGeeversAtVortech]

In GitLab by @BernhardBecker on Aug 28, 2018, 12:11

Feature request: time horizon management for RTC-Tools with different periods and time step definitions as follows.
The terms and concept described below match more or less the Delft-FEWS concept and has also been applied in RTC-Tools 1. The user can specify the different periods in a file (pi_run.xml or a csv file) or in python. Default settings are applied if not user-specified.

Simulation period: the full period a run is active on, historic period + forecast period. Default: as is.

t0: point in time for initial conditions, separates historic and forecast period. Reads t-zero and represents present time in a scenario. Default: as is.

forecast period: the period the optimization is carried out for, starts with t0 and ends with the end of the simulation period. Default: identically to similation period.

historic period: past, computations use time series values from this period in order to compute e. g. week average values for state-dependent goals in the first time steps of the forecast period. Optimization variables must be given for the historic period. Default: no historic period, work with initial conditions only. Ends with t0.

computing time step dt: the time step for the system model, e. g. one hour, also referred to as "time step". Default: as is.

optimization period dto: the period an optimization is carried out for. The optimization time step can be the computing time step or multiple computing time steps. Initial values are taken from the previous computing time step, which is the last computing time step from the previous optimization time step. Default: identically to forecast period (as is, use case 2 from below).

forecast time step dtf: the time step for the forecast period. After terminating one optimization, t + dtf determines the beginning of the next optimization. Default: dtf = dto. dtf can be equal to or larger than dt. It makes no sense, but it is in principle possible to have dtf > dto.

Use cases:

(1) If the optimization time step is equal to the computing time step, we have a simple approach à la RIBASIM. The optimization is carried out for the current time step only. In this case it is not possible to optimize storage of a reservoir to bridge future periods of scarcity. This is currently applied for the NHI project. The simulation period is usually in the order of years or centuries.

(2) Optimization time step has the length of the forecasting period. This is a common case for operational systems, where the optimization is carried out until the end of the simulation period (i. e. end of the forecasting period). Usually, the simulation period is short (order of days, weeks or months).

(3): Optimization time step comprises multiple computing time steps, and the forecast period consists of multiple optimization time steps, and the forecast time step is equal to the optimization time step. This applies for optimization studies for planning, for example for reservoir management. A reservoir lake usually is maintained as year storage, this means it must be operated in such a way that water from a wet period is stored such that all water demand during the dry period can be maintained. Multiple years are computed in sequence (e. g. 100 years for climate change studies), but the optimization is carried out for a year only. An example for such a configuration: the forecasting period is 100 years, dt = 1 month, dtf = 1 year = 12 * dt, dto = dtf. Questions to be addressed with this approach are for example: the derivation of rule curves for reservoir management (would be interesting to derive them for different operational periods: why not two years instead of 1 year?), system failure under design scenarios, climate change stress test of dams.

[SGeeversAtVortech]

In GitLab by @jarsarasty on Jun 4, 2024, 10:48

@BernhardBecker , this is probably relevant to the documentation of the closed-loop script.