Replies: 3 comments 3 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
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>
|
Beta Was this translation helpful? Give feedback.
-
@anirudh-ramesh, I opened #618, let me know what needs to be clearer. |
Beta Was this translation helpful? Give feedback.
-
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:
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.
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.
Beta Was this translation helpful? Give feedback.
All reactions