feat(scheduling): Add multiple maxima and minima constraints into StorageScheduler

[victorgarcia98]

This PR allows to set multiple maxima and minima SOC values as timeseries. These parameters can be passed into StorageScheduler in flex-model.

Closes #575.

Applications:

• With soc-max and soc-min users can define a global maximum and minimum, respected during the whole scheduling period. I think of these two values as hard limits.
• With soc-minima, users can define what is called soc-max-preference in Issue Handle SoC targets that exceed the maximum SoC #575.
• soc-maxima can be used to apply hourly restrictions in congested hours.

Please, let me know your thoughts on this new feature.

[Flix6x]

Nice feature. Here are some comments from a code read. I still need to think a bit about whether we are now covering our intended use case from Issue #575.

What happens if a target exceeds the maxima (to such an extent that maxima may have to be ignored even a couple of time steps before the target)? Is it the client's responsibility to present a solvable problem?

[victorgarcia98]

What happens if a target exceeds the maxima (to such an extent that maxima may have to be ignored even a couple of time steps before the target)? Is it the client's responsibility to present a solvable problem?

Good question!

This could happen the same for the minima, were the user could raise the minima with a low target after it.

I'm not sure it will lead to an unfeasible problem as the derivate_max is set to capacity, so it could potentially discharge/charge the full storage in a time period (which is something we should discourage).

It would be a problem if there were more than one of the constraints (target, maxima and minima) defined in the same time slot, being incompatible i.e not fulfilling the condition maxima >= target >= minima.

---

Off topic

I think we should include the resolution into the calculations of derivative_max and derivative_min:

device_constraints[0]["derivative min"] = (
                sensor.get_attribute("capacity_in_mw") * -1 * ( resolution / timedelta(hours=1))
            )

That way, If the storage has a limit of 1MW -> 1MWh in 1 hour is equivalent to a limit 250kWh in 15min.

[Flix6x]

Upon further reflection, I believe this PR does in fact resolve #575, by implementing the first approach suggested there. We should still add documentation:

• The new fields should at least be added to Example B of the trigger endpoint docstring.
• A changelog entry
• By now we have accumulated quite some scheduling options (in Example B) that aren't really explained in detail anywhere else. I suggest we open an Issue to add a new documentation section (e.g. to https://flexmeasures.readthedocs.io/en/latest/tut/forecasting_scheduling.html) where we can discuss some scheduling problems. There we can then also address the case detailed in Handle SoC targets that exceed the maximum SoC #575, and what the client can do to set up this problem as a feasible scheduling problem. This will require some combination of using the soc-maxima and soc-minima fields, instead of the soc-max and soc-targets fields. Something like:
  • setting soc-maxima to a list of values equal to the normally preferred maximum value, for each time step, but excluding some time range around each soc-target (to make the problem feasible),
  • setting the soc-minima to a list of 100% values, for each soc-target datetime.

One more thing: we should be able to raise informative validation errors by checking feasibility of constraints over consecutive time steps. For example: $SOC_{min}(t+1) \leq SOC_{max}(t) + power_{max}(t)$. Could also be a follow-up issue.

Can you open a new issue or discussion for the off-topic comment? I'll add my thoughts there.

[Flix6x]

Pretty amazing stuff you did with the constraint validation! 😎

[Flix6x]

Actually, note to self: we still need to update the API changelog.