Issues in nested solves

[jkiviluo]

When higher level solves have a coarser resolution than the lower level solves, the last timestamp does not align and the fixing of storage cannot be passed to the lower level (there is no timestamp with fix data available from the higher level solve that would match with the timestamp in the lower level). E.g. storage_solve is using new_stepDuration 4 and the dispatch_solve uses the original hourly resolution. The last timestamp will be off by three steps. A possible solution is that FlexToolRunner.py should check the closest previous timestep from the upper level solve to match the last time step of the next lower level roll and ask flexModel3.mod to write that into a file (it has to use the timestamp of the upper level solve). Then, there needs to be a map between the matching upper level solve and the lower level solve timestamps, so that the lower level solve can pick the matching timestep from the fix_storage_quantity.csv. This map is a separate file generated by FlexToolRunner.py.

rolling_start_time is not working. Setting it to e.g. t00002 does not change the start time.

When trying to fix storages twice (e.g. invest_solve fixes storage end levels for storage_solve and storage_solve fixes storage end levels for dispatch_solve), then fix_storage_quantity.csv will get the same elements with exactly the same dimension names (period, step, node) more than once, and MathProg will fail (as it should, since it cannot distinguish).

If someone is using a constant value for inflow, time series aggregation is probably not working (didn't check, but appears that way).

[jkiviluo]

There is a branch that has started this work. See: https://github.com/irena-flextool/flextool/tree/fix_nested_solves