Multi-device Scheduling

[victorgarcia98]

In order to expose the full potential of the device_scheduler, @Flix6x and I had a session to discuss how to describe the scheduling message for multiple devices.

To exemplify how it would look, let us present the outcome of the discussion:

URI: sensors/0/schedules/trigger

Body

{
    "flex-model" : [
        {"sensor" : 0, "power-capacity" : "1MW"},
        {"sensor" : 1, "power-capacity" : "10kW", "soc-maxima" : []},
        {"sensor" : 2, "soc-at-start" : 10.0},
    ],
    "flex-context" : {
        "topology" : [
            {
                "sensor" : 1,
                "topology" : [
                    {"sensor" : 3, "consumption-price-sensor" : 10},
                    {"sensor" : 4, "production-price-sensor" : 11},
                    {"sensor" : 14, "production-price-sensor" : 11},
                    {"sensor" : 15, "production-price-sensor" : 11}
                ]
            },
            {"sensor" : 2},
            {"sensor" : 15, "production-price-sensor" : 12}
        ],
        "consumption-price-sensor" : 8,
        "production-price-sensor" : 9,
        "inflexible-device-sensors" : [14, 15]
    }
}

General notes:

• The top level of the message remains the same as before(flex-model and flex-context as the unique keys). This will facilitate backwards compatibility.
• The flex context includes a new key: topology. This field describes a tree of devices which helps us to introduce intermediate power constraints and different price sensors for each of the groups.
  • Each of the terminal nodes describe either a flexible or inflexible device. The inflexible devices must be defined in the inflexible-device-sensors field.
  • If the topology field is defined in the element, it defines a group of devices which, in turn, could define sub-groups.
• In favor of keeping backwards compatibility, the flex model can be of one of the following types:
  • Dict: current description of 1 storage device with the starting soc, soc maxima and minima, etc.
  • List: describe the time-varying parameters such as the starting soc, soc maxima, minima, etc... for each of the devices or groups defined in topology.

How expressive is this schema?

Some constraints that we can define:

• Different prices per group of devices
• Different power constraints for each group of devices.

Some constraints that we can't establish:

• Impose constraints on the aggregate effect of devices that don't belong to the same group. So let's say we have two groups (A,B) and (C,D) and we want to make power(A) + power(B) < max_power. This could be useful in case of delivering ancillary services where two or more batteries in different sites are part of the same group.

This schema also aligns very well with the DataGenerator description.

Follow-up tasks

(feel free to add to this list)

• Decide whether to create a new scheduler (l'll make reference to this as the MultiDeviceScheduler) or reuse the StorageScheduler.
  • On one side, the MultiDeviceSchedulerwill allow to schedule a single storage device so it will cover the existing scope of the StorageScheduler. On the other side, we are relying on the type to trigger the fallback mechanism. Moreover, the new scheduler might come with bugs and we might want to battle test it for a while (e.g. with internal projects) and phase out the StorageScheduler.
• Decide which features will the first version of the MultiDeviceScheduler implement:
  • Different prices per group
  • Intermediate power constraints
  • Fixing binary constraints for elements that we know that will be only consume or produce (e.g. 1 directional chargepoint)
• The MultiDeviceScheduler will return a list of output BeliefDataFrames and the existing infra should support saving the resulting beliefs. This goes inline with what the DataGenerator does.
• Create a new tutorial where the user schedules multiple devices. (Given that the descriptions can we quite long, should we use the FlexMeasures client?)
• Plan how to call the scheduler via the CLI.

What do you think @Flix6x and @nhoening?

[nhoening]

Thanks!

1. For multiple sensors, ideally we could place such an endpoint under assets//schedules/trigger right? That's where I would expect a nested flex-model and flex-context
2. We are Price devices distinctively in scheduling #618 consumption-price-sensors-per-device and production-price-sensors-per-device. To be clear, would your suggested topology make that PR redundant? (we might re-use it partly here)? It would be a more generic solution, of course.
3. About the actual solver: The most crucial feature we enable here is the ability to schedule multiple assets within one optimization. Why do we have to decide which features to add in a first implementation? That said, I don't know what "Intermediate power constraints" are, and the third idea seems the most relevant to real cases we see in the near future, although I don't know what the positive impact of "Fixing binary constraints" is - can you name them?

[Flix6x]

Independent of the location of this discussion, I already place a few questions:

1. For multiple sensors, ideally we could place such an endpoint under assets/<id>/schedules/trigger right? That's where I would expect a nested flex-model and flex-context
2. We are working on consumption-price-sensors-per-device and production-price-sensors-per-device. To be clear, would your suggested topology make that PR redundant? (we might re-use it partly here)? It would be a more generic solution, of course.
3. About the actual solver: The most crucial feature we enable here is the ability to schedule multiple assets within one optimization. Why do we have to decide which features to add in a first implementation? That said, I don't know what "Intermediate power constraints" are, and the third idea seems the most relevant to real cases we see in the near future, although I don't know what the positive impact of "Fixing binary constraints" is - can you name them?

Originally posted by @nhoening in #531 (reply in thread)

1. I view this as corresponding with the idea of defining topologies on assets, which I like. I'm reminded of an earlier comment of mine:

   To me, the flex-model should live (and be configurable) on the sensor, and the flex-context should live (and be configurable) on the asset.

   Practically, it also means moving the sensor ID 0 into the body, e.g. as follows:

   {
       "flex-model" : [
           {"sensor" : 0, "power-capacity" : "1MW"},
           {"sensor" : 1, "power-capacity" : "10kW", "soc-maxima" : []},
           {"sensor" : 2, "soc-at-start" : 10.0},
       ],
       "flex-context" : {
           "sensor": 0,
           "topology" : [
               {
                   "sensor" : 1,
                   "topology" : [
                       {"sensor" : 3, "consumption-price-sensor" : 10},
                       {"sensor" : 4, "production-price-sensor" : 11},
                       {"sensor" : 14, "production-price-sensor" : 11},
                       {"sensor" : 15, "production-price-sensor" : 11}
                   ]
               },
               {"sensor" : 2},
               {"sensor" : 15, "production-price-sensor" : 12}
           ],
           "consumption-price-sensor" : 8,
           "production-price-sensor" : 9,
           "inflexible-device-sensors" : [14, 15]
       }
   }
   

2. Not redundant, but outdated and more likely to be incompatible.

3. The three features mentioned (group-level prices and power constraints, and fixing binary constraints) are not MVP features imo. FYI:

   • Intermediate power constraints are power constraints that are not on the site level or on the device level, but on the level of intermediate branching points, such as electrical groups with fuses, and Charge Points with multiple plugs.
   • Fixing binary constraints is one (untested) idea that may help the solver reach solutions faster.

[nhoening]

I'm not sure I get this:

"flex-context" : {
        "sensor": 0,

This means: this flex-context tells us that sensor 0 is the power sensor to be optimized when someone asks us to schedule the asset which this flex-context represents?

Does "sensor": 0 here correspond to "flexible-device-sensors": [37, 38] from your earlier comment?

[Flix6x]

Sensor ID 0 would be the site's (aggregate) power sensor.

Does "sensor": 0 here correspond to "flexible-device-sensors": [37, 38] from your earlier comment?

No, in that example IDs 37 and 38 were individual flexible devices. For the example in this discussion, here's a possible legend of assets that each power sensor could have been assigned to:

• 0: site (1MW capacity, with consumption and production priced according to an energy contract)
  • 1: electrical group (10 kW capacity)
    • 3: ventilation (with consumption penalized; e.g. by wear-and-tear)
    • 4, 5 and 10: diesel generators (with production penalized; e.g. by fuel prices)
  • 2: battery
  • 15: solar (with production subsidized)

[Flix6x]

I'll now edit the price sensor IDs above to have this legend make more sense.

[nhoening]

Proposal to make this into a project - with sub-issues as follows:

1. Extend schemas for the extended flex-model and flex-context
2. Create MultiDeviceScheduler who can work with them
3. Create API endpoint for scheduling asset. Early version, expects flex-model and flex-context as attributes.

Retrieving the schedules can actually still happen per sensor, so for a POC we do not need to adapt that yet.

Feel free to criticize / extend

[Flix6x]

I created https://github.com/FlexMeasures/flexmeasures/projects/20

[nhoening]

That project link still works, but it has been migrated to a new-style GitHub project here: https://github.com/orgs/FlexMeasures/projects/1/views/1

[nhoening]

Work has started in #1065