Multiple peak consumption prices not working

[devansh287]

The introduction of various fields related to peak power consumption and production for the scheduler has been quite helpful. However, for the use case we are modeling, have two different peak power prices in the same day. @nhoening suggested that I look at https://flexmeasures.readthedocs.io/stable/api/notation.html#variable-quantities for different ways we can fill the site-peak-consumption-price field in the flex-context. Whenever I pass in a variable quantity with multiple values, be it via specific time ranges or a reference to a sensor, each time I got the following exception:

HANDLING RQ SCHEDULING EXCEPTION: <class 'ValueError'>: Commitment groups cannot have non-unique upwards deviation prices.

Here is a sample of a flex-context that I passed in:

flex_context_trade {
    "inflexible-device-sensors": [
        11
    ],
    "consumption-price": {
        "sensor": 8
    },
    "production-price": {
        "sensor": 9
    },
    "site-peak-consumption": "4kW",
    "site-peak-consumption-price": [
        {
            "start": "2025-02-05T08:00:00+00:00",
            "duration": "PT3H",
            "value": "10.1 SEK/kWh"
        },
        {
            "start": "2025-02-05T11:00:00+00:00",
            "duration": "PT4H",
            "value": "20 SEK/kWh"
        }
    ],
    "site-power-capacity": "13.8kW"
}

To investigate further, we added a stack trace during exception handling in the flexmeasures/cli/jobs.py file as follows.

def handle_worker_exception(job, exc_type, exc_value, traceback):
    """
    Just a fallback, usually we would use the per-queue handler.
    """
    queue_name = job.origin
    click.echo(f"HANDLING RQ 1 {queue_name.upper()} EXCEPTION: {exc_type}: {exc_value}")
    # get a stack trace
    import traceback as tb
    tb.print_tb(traceback)
    # continue execution
    job.meta["exception"] = exc_value
    job.save_meta()

This was the stack trace we got. It looks like we are getting a problem with the convert_commitments_to_subcommitments function in flexmeasures/data/models/planning/linear_optimization.py:

2025-02-03 11:01:17   File "/usr/local/lib/python3.10/dist-packages/rq/worker.py", line 1430, in perform_job
2025-02-03 11:01:17     rv = job.perform()
2025-02-03 11:01:17   File "/usr/local/lib/python3.10/dist-packages/rq/job.py", line 1280, in perform
2025-02-03 11:01:17     self._result = self._execute()
2025-02-03 11:01:17   File "/usr/local/lib/python3.10/dist-packages/rq/job.py", line 1317, in _execute
2025-02-03 11:01:17     result = self.func(*self.args, **self.kwargs)
2025-02-03 11:01:17   File "/usr/local/lib/python3.10/dist-packages/flexmeasures/data/services/scheduling.py", line 323, in make_schedule
2025-02-03 11:01:17     consumption_schedule: SchedulerOutputType = scheduler.compute()
2025-02-03 11:01:17   File "/usr/local/lib/python3.10/dist-packages/flexmeasures/data/models/planning/storage.py", line 883, in compute
2025-02-03 11:01:17     ems_schedule, expected_costs, scheduler_results, model = device_scheduler(
2025-02-03 11:01:17   File "/usr/local/lib/python3.10/dist-packages/flexmeasures/data/models/planning/linear_optimization.py", line 208, in device_scheduler
2025-02-03 11:01:17     commitments, commitment_mapping = convert_commitments_to_subcommitments(commitments)
2025-02-03 11:01:17   File "/usr/local/lib/python3.10/dist-packages/flexmeasures/data/models/planning/linear_optimization.py", line 186, in convert_commitments_to_subcommitments
2025-02-03 11:01:17     raise ValueError(

[Flix6x]

Great to hear the new contracts are being put to use!

To help, I need to understand more about the use case you are aiming for. Is it:

1. to price the single highest consumption peak (higher than 4 kW) between 8 AM and 3 PM, and to price it with either price A or price B, depending on when the peak occurred?

2. Or is it to price the single highest consumption peak for each price interval (above 4 kW)? So the biggest peak between 8 AM and 11 AM gets price A and the biggest peak between 11 AM and 3 PM gets price B.

3. Or is your intended use case to price every consumption peak (above 4 kW) with price A or price B depending on when each peak occurred?

If it's the latter, I think the consumption capacity breach price would better suit your use case, in combination with a site-consumption-capacity defined only for those hours. Let me know if this is the case and I can help spec an example.

Option 2 is a use case I want to support soon, but right now we should do a better job informing the user that this is not implemented yet.

Option 1 is not so trivial.

[devansh287]

Appreciate your response, @Flix6x!

Yes, we were thinking of option number 2. Given that is already on your roadmap, we are good.