Rolling window optimization

[jkiviluo]

Rolling window optimization can currently be performed by setting the solve sequence manually, but this would be very impractical for hundreds of roll forwards.

As we want to enable nested rolling windows (e.g. investment at the highest level, water value calculation in the middle and then dispatch at the bottom), solve objects should have an optional parameter include_solve. When set, it would call the named lower level solve, which can then be a set of rolling solves when using rolling_window value for the solve_mode in the lower level solve (as defined below). If the calling (higher level) solve is itself a rolling solve, it will then include the lower level (rolling) solve between every roll forward it takes. solves parameter of model class will need to hold only the solves for the highest level.

For rolling solves, we should add parameters that allow to define the roll forward properties for a 'solve' object:

• rolling_solve_horizon (initially hours, but could also be a map that defines the time resolution for different timeblocks in the solve, i.e. decreasing resolution with increasing horizon)
• rolling_solve_jump (hours)
• optional rolling_start_time (timestamp index that needs to be found from the block_duration parameter of timeBlockSet). This would not be needed when there is a higher level solve that sets the start time.
• rolling_duration (hours). This also potentially optional since it could be deduced from the upper level solve when that's available.

There needs to be an update of parameters that choose what values to fix/lock/keep form specific solves. There is another issue for that: https://github.com/irena-flextool/flextool/issues/58

FlexToolRunner.py will then generate the solve sequence the model will need.

[jkiviluo]

[jkiviluo]

Has been implemented with 10d7e48770ef54e27c6403a23af0165b886141ef