Create RelaxedStorageScheduler

[Flix6x]

We sometimes come across infeasible scheduling problems, most often due to a set of SoC constraints that cannot be solved. Our idea is to replace hard (SoC) constraints with additional cost components in the cost function. This is particularly suitable for the soc-maxima and soc-minima fields in the flex-model, as these are often constructed based on a user preference rather than a physical constraint in storage capacity.

Price modelling

Penalizing the transgression requires an associated price. Ideas to model such a price:

• Model it as some factor higher than the order of magnitude of (power) commitment prices. This is similar to how we modelled the preference to keep the SoC high (charge sooner, discharge later)
• Allow toggling the behaviour through the API. Also similar to how we allow toggling the preference to keep the SoC high.
• Allow more detailed control by setting a distinct transgression price (or one for each possible transgression) in the flex-model (I don't think this is needed).
• Allow exact control over the associated price at any time, by modelling it as sensor data, and passing the relevant sensor ID in the flex-model (I don't think this is needed).

Problem complexity

I believe the cost function will remain linear.

$$ \min [oldCostComponents + newCostCostcomponents ] $$

where:

$$ oldCostComponents = \sum_{c,j} \Delta_{up}(c,j) \cdot Price_{up}(c,j) + \Delta_{down}(c,j) \cdot Price_{down}(c,j) $$

$$ newCostComponents = StockTransgression_{up} \cdot StockTransgressionPrice_{up} + StockTransgression_{down} \cdot StockTransgressionPrice_{down} $$

$$ StockTransgression_{up} = \begin{cases} Stock(d,j) - Stock_{max}(d,j) & \text{if } Stock(d,j) > Stock_{max}(d,j) \\ 0 & \text{otherwise} \end{cases} $$

$$ StockTransgression_{down} = \begin{cases} Stock_{min}(d,j) - Stock(d,j) & \text{if } Stock(d,j) < Stock_{min}(d,j) \\ 0 & \text{otherwise} \end{cases} $$

Generalized modelling

The new cost components are quite close to the modelling concept of applying multiple commitments to a given schedule. The device scheduler may be generalized to accommodate commitments on a given SoC rather than on a given power level. This would open up the possibility of specifying multiple SoC commitments (we'd then sum over the SoC commitments, too), and the possibility of having SoC commitments on both a device level and on a site level (and possibly for intermediate groupings, e.g. two power-to-heat systems leading to a shared heat storage).

The corresponding model:

$$ newCostComponents = \sum_{c,j} StockDeviation_{up}(c,j) \cdot StockPrice_{up}(c,j) + StockDeviation_{down}(c,j) \cdot StockPrice_{down}(c,j) $$

With SoC coupling constraints (on the site level):

$$ \sum_d Stock^{ems}(d,j) = \sum_c StockCommitment(c,j) + StockDeviation_{up}(c,j) + StockDeviation_{down}(c,j) $$

For example, the previous model described above can be captured as follows:

For $c=0$, associated with a SoC commitment to $Stock_{max}(d,j)$:

$$ StockPrice_{up}(0,j) = StockTransgressionPrice_{up} $$

$$ StockPrice_{down}(0,j) = 0 $$

And similarly for $c=1$, associated with a SoC commitment to $Stock_{min}(d,j)$:

$$ StockPrice_{up}(1,j) =0 $$

$$ StockPrice_{down}(1,j) = - StockTransgressionPrice_{down} $$

[victorgarcia98]

Good idea!

I suggest calling it SoftStorageScheduler or RelaxedStorageScheduler because I feel this could be the very first options for some settings like in Electric mobility.

Regarding the implementation, I think we can make this into the current device_scheduler by parameterizing the problem. We can leave the StockTransgression_, setting the cost of Transgression to 0 (fillna(0)) and fixing the variable.

One way to implement the following constraints:

$$ StockTransgression_{up} = \begin{cases} Stock(d,j) - Stock_{max}(d,j) & \text{if } Stock(d,j) > Stock_{max}(d,j) \\ 0 & \text{otherwise} \end{cases} $$

is with the two inequalities below:

$$ \begin{aligned} StockTransgression_{up} & \geq Stock(d,j) - Stock_{max}(d,j) \\ StockTransgression_{up} & \geq 0 \end{aligned} $$

which are convex and linear.

[victorgarcia98]

Additionally, we might introduce some limits to the transgression:

$$ StockTransgression_{up} \leq SomeParameter $$

This would allow two useful cases:

• If $SomeParameter = 0$, we have the tight model back
• If $SomeParameter = k &gt; 0$, we can limit the transgression and, at the same time, minimizing it.