You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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).
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.
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:
Problem complexity
I believe the cost function will remain linear.
where:
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:
With SoC coupling constraints (on the site level):
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)$ :
And similarly for$c=1$ , associated with a SoC commitment to $Stock_{min}(d,j)$ :
The text was updated successfully, but these errors were encountered: