For some tasks, like for estimating hydro power water value or for scheduling with forecast errors, there should be a temporal structure that allows to branch the timeline. A simple branching structure could look like this:
Stochastic models are typically rolling models (although a single shot investment model with one common time step with investment decisions and then n branches to present alternative operational futures is a valid use case too). So, after the first decisions, the next step could be like this:
In practice, stochastic models realise only the timesteps where there is no uncertainty (no branches). So, the first solve realises timesteps 01-03, and the second solve timesteps 04-05 (timestep 00 contains initial conditions and in the second solve so does timestep 03).
FlexTool code already contains the required dimension to represent stochastics: period (d). What's needed is 1) a branching time structure, 2) a way to enter stochastic data and 3) way to choose what parts of the model are stochastic.
Branching time structure
The set dtttdt will suffice, but the branching needs to be established. The last dt (d_previous and t_previous_within_solve) will, in a stochastic tree, point to the same timestep whenever branching happens: [d01, t04, N/A, N/A, d0, t03] and [d02, t04, N/A, N/A, d00, t03]. The set creation probably needs to be implemented in flextoolrunner.py to take into account the complexities in rolling.
Entering stochastic data
Stochastic data has an additional dimension: branch. Therefore, all time series can also be given with one more dimension. If some parameter does not contain stochastic data, but the model is stochastic - then it's assumed that the parameter is the same in all branches for a given time step. When a time series is given as stochastic, but the model (or that part of the model) is deterministic, then the deterministic time series need to be parsed from the stochastic data. We could also require the user to provide deterministic data for deterministic models - TBD (the data could be in separate alternatives).
Choosing what parts of the model are stochastic
It's really variables that are finally either stochastic or deterministic. However, we choose the stochastic method for nodes, units and connections. If a node is stochastic, then its state (and its investments) are stochastic variables in the stochastic branches. If a connection is stochastic, then its flows (and its investments) are stochastic variables. If a unit is stochastic, then it could have stochastic flows, online status or both (plus investments). If unit has stochastic online, then also flows should be stochastic. However, it can be desirable to have deterministic online variable but stochastic flow variables. So, the method for units should have options: deterministic, flow_only, online_and_flow. If unit (or the others) have any stochastic variables, then also investments should be stochastic (and no need for separate method). Of course, in most use cases, there are no investment variables in the stochastic branches.
As it can be cumbersome to set method for every unit, node and connection separately, stochastic method is to be implemented through groups. All group members will inherit the method choice.
For some tasks, like for estimating hydro power water value or for scheduling with forecast errors, there should be a temporal structure that allows to branch the timeline. A simple branching structure could look like this:
Stochastic models are typically rolling models (although a single shot investment model with one common time step with investment decisions and then n branches to present alternative operational futures is a valid use case too). So, after the first decisions, the next step could be like this:
In practice, stochastic models realise only the timesteps where there is no uncertainty (no branches). So, the first solve realises timesteps 01-03, and the second solve timesteps 04-05 (timestep 00 contains initial conditions and in the second solve so does timestep 03).
FlexTool code already contains the required dimension to represent stochastics: period (d). What's needed is 1) a branching time structure, 2) a way to enter stochastic data and 3) way to choose what parts of the model are stochastic.
Branching time structure
The set dtttdt will suffice, but the branching needs to be established. The last dt (d_previous and t_previous_within_solve) will, in a stochastic tree, point to the same timestep whenever branching happens: [d01, t04, N/A, N/A, d0, t03] and [d02, t04, N/A, N/A, d00, t03]. The set creation probably needs to be implemented in flextoolrunner.py to take into account the complexities in rolling.
Entering stochastic data
Stochastic data has an additional dimension: branch. Therefore, all time series can also be given with one more dimension. If some parameter does not contain stochastic data, but the model is stochastic - then it's assumed that the parameter is the same in all branches for a given time step. When a time series is given as stochastic, but the model (or that part of the model) is deterministic, then the deterministic time series need to be parsed from the stochastic data. We could also require the user to provide deterministic data for deterministic models - TBD (the data could be in separate alternatives).
Choosing what parts of the model are stochastic
It's really variables that are finally either stochastic or deterministic. However, we choose the stochastic method for nodes, units and connections. If a node is stochastic, then its state (and its investments) are stochastic variables in the stochastic branches. If a connection is stochastic, then its flows (and its investments) are stochastic variables. If a unit is stochastic, then it could have stochastic flows, online status or both (plus investments). If unit has stochastic online, then also flows should be stochastic. However, it can be desirable to have deterministic online variable but stochastic flow variables. So, the method for units should have options: deterministic, flow_only, online_and_flow. If unit (or the others) have any stochastic variables, then also investments should be stochastic (and no need for separate method). Of course, in most use cases, there are no investment variables in the stochastic branches.
As it can be cumbersome to set method for every unit, node and connection separately, stochastic method is to be implemented through groups. All group members will inherit the method choice.