Timewindow treated differently from DAH to MPC optimization since update to 0.11.2 from 0.10.6

[charliesjc]

Since 0.11.2 I've been seeing Infeasible on MPC calcs. I ran some tests and noticed that the same data is generating a different time window in MPC vs DAH. See the below logs:

Day-ahead:

2024-11-27 12:38:07,645 - web_server - INFO - Passed runtime parameters: {'def_total_hours': [2, 1], 'def_start_timestep': [0, 0], 'def_end_timestep': [6, 6], 'pv_power_forecast': [2377, 3163, 3449, 3749, 3500, 3379, 3196, 2844, 2371, 1291, 924, 274, 175, 96, 41, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 14, 65, 132, 397, 528, 968, 1122, 2738, 2988, 3906, 4047, 4574, 4501, 4824, 4620, 4392, 4117, 3793, 3428, 2090, 1747, 587, 417, 259, 121, 9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 15, 63, 123, 371, 490, 896, 1047, 2550, 2779, 3618, 3754], 'load_cost_forecast': [2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 7.29, 7.29, 7.29, 7.29, 7.29, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 7.29, 7.29, 7.29, 7.29, 7.29, 7.29, 7.29, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 7.29, 7.29, 7.29, 7.29, 7.29, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72], 'prediction_horizon': 60, 'soc_init': 0.83, 'soc_final': 0.9, 'freq': 30}

2024-11-27 12:38:07,646 - web_server - INFO -  >> Setting input data dict

2024-11-27 12:38:07,646 - web_server - INFO - Setting up needed data

2024-11-27 12:38:07,647 - web_server - INFO - Retrieving weather forecast data using method = list

2024-11-27 12:38:07,648 - web_server - INFO - Retrieving data from hass for load forecast using method = naive

2024-11-27 12:38:07,648 - web_server - INFO - Retrieve hass get data method initiated...

2024-11-27 12:38:09,506 - web_server - INFO -  >> Performing dayahead optimization...

2024-11-27 12:38:09,506 - web_server - INFO - Performing day-ahead forecast optimization

2024-11-27 12:38:09,510 - web_server - INFO - Perform optimization for the day-ahead

2024-11-27 12:38:09,534 - web_server - DEBUG - Deferrable load 0: Proposed optimization window: 0 --> 6

2024-11-27 12:38:09,534 - web_server - DEBUG - Deferrable load 0: Validated optimization window: 0 --> 6

2024-11-27 12:38:09,536 - web_server - DEBUG - Deferrable load 1: Proposed optimization window: 0 --> 6

2024-11-27 12:38:09,536 - web_server - DEBUG - Deferrable load 1: Validated optimization window: 0 --> 6

2024-11-27 12:38:09,582 - web_server - WARNING - Solver default unknown, using default

MPC:

2024-11-27 12:38:26,867 - web_server - INFO - Passed runtime parameters: {'def_total_hours': [2, 1], 'def_start_timestep': [0, 0], 'def_end_timestep': [6, 6], 'pv_power_forecast': [2377, 3163, 3449, 3749, 3500, 3379, 3196, 2844, 2371, 1291, 924, 274, 175, 96, 41, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 14, 65, 132, 397, 528, 968, 1122, 2738, 2988, 3906, 4047, 4574, 4501, 4824, 4620, 4392, 4117, 3793, 3428, 2090, 1747, 587, 417, 259, 121, 9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 15, 63, 123, 371, 490, 896, 1047, 2550, 2779, 3618, 3754], 'load_cost_forecast': [2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 7.29, 7.29, 7.29, 7.29, 7.29, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 7.29, 7.29, 7.29, 7.29, 7.29, 7.29, 7.29, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 7.29, 7.29, 7.29, 7.29, 7.29, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72, 2.72], 'prediction_horizon': 60, 'soc_init': 0.83, 'soc_final': 0.9, 'freq': 30}

2024-11-27 12:38:26,867 - web_server - INFO -  >> Setting input data dict

2024-11-27 12:38:26,868 - web_server - INFO - Setting up needed data

2024-11-27 12:38:26,870 - web_server - INFO - Retrieve hass get data method initiated...

2024-11-27 12:38:27,606 - web_server - INFO - Retrieving weather forecast data using method = list

2024-11-27 12:38:27,607 - web_server - INFO - Retrieving data from hass for load forecast using method = naive

2024-11-27 12:38:27,607 - web_server - INFO - Retrieve hass get data method initiated...

2024-11-27 12:38:29,464 - web_server - INFO -  >> Performing naive MPC optimization...

2024-11-27 12:38:29,464 - web_server - INFO - Performing naive MPC optimization

2024-11-27 12:38:29,467 - web_server - INFO - Perform an iteration of a naive MPC controller

2024-11-27 12:38:29,491 - web_server - DEBUG - Deferrable load 0: Proposed optimization window: 10 --> 6

2024-11-27 12:38:29,491 - web_server - WARNING - Deferrable load 0 : Invalid timeframe for deferrable load (start timestep is not <= end timestep). Continuing optimization without timewindow constraint.

2024-11-27 12:38:29,491 - web_server - DEBUG - Deferrable load 0: Validated optimization window: 0 --> 0

2024-11-27 12:38:29,493 - web_server - DEBUG - Deferrable load 1: Proposed optimization window: 6 --> 6

2024-11-27 12:38:29,493 - web_server - WARNING - Deferrable load 1 : Available timeframe is shorter than the specified number of hours to operate. Optimization will fail.

2024-11-27 12:38:29,493 - web_server - DEBUG - Deferrable load 1: Validated optimization window: 6 --> 6

2024-11-27 12:38:29,527 - web_server - WARNING - Solver default unknown, using default

I've just noticed that the 10 and the 6 it's using for the start of the window are coming from the config.json file. It's ignoring the start timesteps that I've passed in, but only on the MPC calc.

[charliesjc]

I seem to have fixed it. I changed def_start_timestep to start_timesteps_of_each_deferrable_load and it works correctly in MPC calcs now. It seems to be picking up def_start_timestep correctly for DAH though. I have now updated all my runtime keys to the latest versions.