Time limit for deferrable loads

[michaelpiron]

This pull request introduces a new parameter, allowing the user to specify a time limit for each deferrable load (in MPC optimization).

The new parameter in the optimizer, called def_end_timestep, is defined as "The timestep before which each deferrable load should operate."
The optimizer will get an extra constraint stating that the deferrable load should not consume any energy after the specified timestep. If a value of 0 (or negative) is provided, no extra constraint is added.

Example: "def_end_timestep": [3,0]
This is the case of two deferrable loads, whereby the first load should operate in the first three timesteps of the optimization window. The second load can use the complete optimization window (cf the value of 0).

There's also a check that the available timeframe until def_end_timestep is > the timesteps needed to run the load for the specified operating hours (def_total_hours). If not, the def_end_timestep is updated automatically to respect that constraint.

[codecov]

Codecov Report

Attention: 5 lines in your changes are missing coverage. Please review.

Comparison is base (5691360) 89.52% compared to head (04dae29) 89.56%.
Report is 5 commits behind head on master.

Files	Patch %	Lines
src/emhass/optimization.py	82.75%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #153      +/-   ##
==========================================
+ Coverage   89.52%   89.56%   +0.03%     
==========================================
  Files           6        6              
  Lines        1442     1485      +43     
==========================================
+ Hits         1291     1330      +39     
- Misses        151      155       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[michaelpiron]

OK, automated tests have passed. I will continue doing functional testing, therefore changed it into a draft PR

[michaelpiron]

Edge cases are working as expected:

Edge case: start > end

[davidusb-geek]

Ok so this will catch incoherent time windows entered by the user?
If the proposed window is 0 --> 0 it means that no windows is defined for that deferrable load?

[michaelpiron]

Ok so this will catch incoherent time windows entered by the user? If the proposed window is 0 --> 0 it means that no windows is defined for that deferrable load?

Correct. I only enforce an extra constraint if the specified def_start_timestep & def_end_timestep are valid, making chances of a successful optimization as high as possible.

More concretely:

• Start = 0 means: start of the prediction horizon window. No constraint added
• End = 0 means: end of the prediction horizon window. No constraint added
• If user specifies a negative value for start or end, the value will be changed to 0. No constraint added
• If start timestep > end timestep the optimizer will not take it into account. (Both start & end timestep are changed to 0). No constraint added
• If the number of timesteps between start & end is too short to meet the def_total_hours constraint, a warning message will be shown in the log, warning the user that the optimizer won't find an feasible solution. Constraints for start & end timestep are enforced and optimization continues. I tried to find a logic to automatically make the defined optimization window longer, but there's too many degrees of freedom (put the start earlier? put the end later? a bit of both?)

[michaelpiron]

Happy flow

Example of a valid case:
The car needs to charge 2h at nominal power. I specify a timewindow of 7 timesteps = 3.5h (between 17h30 & 21h)

Forcing the deferrable load 1 to operate between 17h30 and 21h:

Outcome:

[michaelpiron]

Edge case: timewindow too short

Example case where the defined timewindow for deferrable load 1 is too short to meet the def_total_hours constraint:
The car needed to charge 2h at nominal power. I specified a timewindow of 1 timestep = 0.5h:

Result:

[michaelpiron]

Day-ahead optimization

Day ahead optimization also works with the timewindow constraints.

However, DA optimization doesn't take the timewindow constraints as runtime parameters (just like def_total_hours for example), but rather takes the constraints from the add-on configuration screen:

Log of the optimization:

Result:

[michaelpiron]

Edge case: end optimization window deferrable load > prediction horizon

If the user specified a timewindow that goes beyond the prediction horizon, the timewindow is adjusted automatically.
In the case below, the prediction horizon has 26 timesteps.

[michaelpiron]

Code is ready for review

[davidusb-geek]

Day-ahead optimization

Day ahead optimization also works with the timewindow constraints.

However, DA optimization doesn't take the timewindow constraints as runtime parameters (just like def_total_hours for example), but rather takes the constraints from the add-on configuration screen

In this specific example for day-ahead optimization no constraint was added to the LP problem right?

[michaelpiron]

Day-ahead optimization

Day ahead optimization also works with the timewindow constraints.
However, DA optimization doesn't take the timewindow constraints as runtime parameters (just like def_total_hours for example), but rather takes the constraints from the add-on configuration screen

In this specific example for day-ahead optimization no constraint was added to the LP problem right?

There was: deferrable load 1 was only allowed to operate after the first timestep.

[davidusb-geek]

There was: deferrable load 1 was only allowed to operate after the first timestep.

Yes but then what is the meaning of fixing end-timestep to zero? that's the bit I don't get

[michaelpiron]

There was: deferrable load 1 was only allowed to operate after the first timestep.

Yes but then what is the meaning of fixing end-timestep to zero? that's the bit I don't get

The zero for def_end_timestep means that we don't impose an end limit, so the endpoint equals the end of the prediction horizon.

I've visualized some cases:
Yellow is the prediction horizon of the optimization. The blue bars are the deferrable load timewindows that correspond to the provided [start, end] timesteps:

[michaelpiron]

Day-ahead optimization

Here's another example of DA optimization with specified timewindow for deferrable load 1:
EMHASS config:
Deferrable load only allowed between timestep 3 & 9

[davidusb-geek]

Ok, understood. Thanks for the clarifications.

[davidusb-geek]

There was: deferrable load 1 was only allowed to operate after the first timestep.

Yes but then what is the meaning of fixing end-timestep to zero? that's the bit I don't get

The zero for def_end_timestep means that we don't impose an end limit, so the endpoint equals the end of the prediction horizon.

I've visualized some cases: Yellow is the prediction horizon of the optimization. The blue bars are the deferrable load timewindows that correspond to the provided [start, end] timesteps:

It may be a good idea to put this image somewhere in the documentation. We can add a section about using this new feature in the Example configurations page.
What do you think?

[michaelpiron]

Hi David, I was thinking the same. Let me see if I can find some time to do this.

[michaelpiron]

@davidusb-geek will have some time on Tuesday to work on documentation. Will make a new pull request for that