Scheduling: features for emerging markets

[nhoening]

We heard about two feature requests that are relevant to emerging markets. Both would mostly require work in enabling more information to be added into the scheduling API, and little work in the actual scheduler.

These are the functional requirements:

1. Let inflexible sensors be priced by distinct price sensors

Use case: government gives different subsidy to wind & solar, so their prices differ.
We'd need a way to indicate different pricing sensor IDs per inflexible sensor ID in the API, and let the scheduler work with that.

2. Let some storage activities be fed in through the API as (semi-)fixed constraint.

Use case: Some outside constraints which are (currently) not handled within FlexMeasures (e.g. a pre-known blackout) need to come out in the schedules (e.g. that a battery discharges at the rate a factory needs to work throughout the blackout hours).

Some business logic outside of FlexMeasures computes a few energy values (e.g. X kWh per interval) and feeds these into the FlexMeasures scheduling AI as constraints. The scheduler needs to receive and respect them.

So in that sense, it is similar to the first feature. However, it might lead to unfeasibility (e.g. the battery cannot be charged enough in time to satisfy all these intervals discharge) - that is okay in v1 from a business perspective. Technically, we should thus find a way that unfeasibility does not lead to an error, but to a schedule, which satisfies as many of these intervals discharges as possible. One idea for this: Attach a high reward (make it very attractive in the internal optimization problem). Then, the scheduler will attempt to fit in as many as possible.

I'm putting these feature descriptions in this discussion, so we can first see if I'm correctly describing them & invite comments on this level from the community. We then plan to shortly move this into two issues and eventually PRs.

[Flix6x]

For the second feature, I'd recommend to model this as an additional layer of commitments, which include some penalty for deviating from them. I'd not impose assumptions with regards to what that penalty is, but rather let the user decide via the API.

Note that our core scheduler already allows layering commitments, with this kind of use case in mind. The API functionality to set up the scheduling problem with layered commitments is missing, though.

[arjunthenerd]

We may want to address the 2nd requirement in 2 or 3 phases. In the first phase the scheduler will not look at the underlying constraints and will execute the scheduled requirement as is programed through the API. We will leave the onus of looking at the penalty outside the scope of FlexMeasures in the beta version. In version 1.0 we will look at the commitment layer and deviation tolerance based on the inputs we get from our first set of Beta customers

[Flix6x]

Excellent. For communicating the set of constraints, which is itself a time series, I'd suggest we add an API field that allows setting power equality constraints to the scheduler, by means of referring to the sensor id of the sensor used to store the constraints. The constraints can then be posted separately as sensor data, before triggering a schedule. This keeps the flex-model simple and also allows you to build up a history of the constraints as sensor data.

[arjunthenerd]

I will review with anirudh and get back to you tomorrow eod india time

…

On Mon, 27 Mar 2023, 19:40 Felix Claessen, ***@***.***> wrote: Excellent. For communicating the set of constraints, which is itself a time series, I'd suggest we add an API field that allows setting power equality constraints to the scheduler, by means of referring to the sensor id of the sensor used to store the constraints. The constraints can then be posted separately as sensor data, before triggering a schedule. This keeps the flex-model simple and also allows you to build up a history of the constraints as sensor data. — Reply to this email directly, view it on GitHub <#615 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6YY545TQABFZ3K367MCOFTW6GNT3ANCNFSM6AAAAAAWHQTRTY> . You are receiving this because you commented.Message ID: ***@***.*** com>

[arjunthenerd]

Could we connect today or tomorrow and understand who will do what and the timelines?

[nhoening]

@anirudh-ramesh, I opened #618, let me know what needs to be clearer.