diff --git a/documentation/features/scheduling.rst b/documentation/features/scheduling.rst index e13e6d2a54..959fa14845 100644 --- a/documentation/features/scheduling.rst +++ b/documentation/features/scheduling.rst @@ -39,7 +39,7 @@ The flex-context The ``flex-context`` is independent of the type of flexible device that is optimized, or which scheduler is used. With the flexibility context, we aim to describe the system in which the flexible assets operate, such as its physical and contractual limitations. -For multi-commodity scheduling problems, the flex-context can be defined separately per commodity (e.g. electricity and gas), using the ``commodities`` field. +For multi-commodity scheduling problems, the flex-context can be defined separately per commodity (e.g. electricity and gas). Fields can have fixed values, but some fields can also point to sensors, so they will always represent the dynamics of the asset's environment (as long as that sensor has current data). The full list of flex-context fields follows below. @@ -65,6 +65,12 @@ And if the asset belongs to a larger system (a hierarchy of assets), the schedul * - ``inflexible-device-sensors`` - |INFLEXIBLE_DEVICE_SENSORS.example| - .. include:: ../_autodoc/INFLEXIBLE_DEVICE_SENSORS.rst + * - ``aggregate-consumption`` + - |AGGREGATE_CONSUMPTION.example| + - .. include:: ../_autodoc/AGGREGATE_CONSUMPTION.rst + * - ``aggregate-production`` + - |AGGREGATE_PRODUCTION.example| + - .. include:: ../_autodoc/AGGREGATE_PRODUCTION.rst * - ``aggregate-power`` - |AGGREGATE_POWER.example| - .. include:: ../_autodoc/AGGREGATE_POWER.rst diff --git a/documentation/index.rst b/documentation/index.rst index a771ccb589..c111d19a41 100644 --- a/documentation/index.rst +++ b/documentation/index.rst @@ -175,6 +175,8 @@ In :ref:`getting_started`, we have some helpful tips how to dive into this docum tut/toy-example-expanded tut/toy-example-multiasset-curtailment tut/flex-model-v2g + tut/multi-feed-storage + tut/multi-commodity tut/toy-example-process tut/toy-example-reporter tut/posting_data diff --git a/documentation/tut/multi-commodity.rst b/documentation/tut/multi-commodity.rst new file mode 100644 index 0000000000..35f3631efd --- /dev/null +++ b/documentation/tut/multi-commodity.rst @@ -0,0 +1,271 @@ +.. _tut_multi_commodity: + +A flex-modeling tutorial for storage: Multiple commodities (gas & electricity) +------------------------------------------------------------------------------ + +The :ref:`multi-feed storage tutorial ` showed that the ``flex-model`` can be a *list*, so that several devices are scheduled together in one call. +Those devices all acted on the same commodity (electricity). But many real sites mix commodities — electricity *and* gas, for instance — each with its own price. + +FlexMeasures handles this with two ingredients: + +- a ``commodity`` field on each device in the ``flex-model``, and +- a per-commodity price listing in the ``flex-context``. + +In this tutorial we schedule a small hybrid site with one device on each commodity, and read back a cost breakdown that is tracked *per commodity*. +(For a more general introduction to flex modeling, see :ref:`describing_flexibility`. For the single-commodity, multi-device case, see :ref:`tut_multi_feed_storage`.) + + +The use case +============ + +A site has two flexible-ish devices, each acting on a different commodity: + +- A **battery** on the ``electricity`` commodity: 20 kW power, 100 kWh capacity, 95% charging and discharging efficiency. It starts at 20 kWh and must reach 80 kWh by 23:00. +- A **gas boiler** on the ``gas`` commodity: it draws a **constant 1 kW** of gas every hour, modelled as a fixed load (it is not really flexible, but it still incurs a commodity cost we want to account for). + +Prices are flat, but *different per commodity*: + +- Electricity: **100 EUR/MWh** (consumption and production) +- Gas: **50 EUR/MWh** + +We want the scheduler to optimise the battery against the electricity price, run the boiler at its fixed gas baseline, and report electricity and gas costs separately. + + +Building the flex model +======================= + +As in the multi-feed tutorial, the ``flex-model`` is a **list** with one entry per device. +What is new here is the ``commodity`` field, which tells the scheduler *which price signal* applies to each device. It defaults to ``"electricity"``. + +.. code-block:: json + + { + "flex-model": [ + { + "sensor": 1, + "commodity": "electricity", + "state-of-charge": {"sensor": 3}, + "soc-at-start": 20.0, + "soc-min": 0.0, + "soc-max": 100.0, + "soc-targets": [ + {"datetime": "2024-01-01T23:00:00+01:00", "value": 80.0} + ], + "power-capacity": "20 kW", + "charging-efficiency": 0.95, + "discharging-efficiency": 0.95 + }, + { + "sensor": 2, + "commodity": "gas", + "power-capacity": "30 kW", + "consumption-capacity": "30 kW", + "production-capacity": "0 kW", + "soc-usage": ["1 kW"], + "soc-min": 0.0, + "soc-max": 0.0, + "soc-at-start": 0.0 + } + ] + } + +Here, sensor ``1`` is the battery's power sensor, sensor ``2`` is the boiler's power sensor, and sensor ``3`` is the battery's instantaneous ``state-of-charge`` sensor (referenced from the battery entry so the scheduler records its charge level). + +A few things to note: + +- **The battery is a normal storage device** (``soc-at-start``, ``soc-min``, ``soc-max``, ``soc-targets``), tagged with ``"commodity": "electricity"``. +- **The boiler is modelled as a fixed load.** With ``soc-min`` and ``soc-max`` both 0, it can store nothing; ``soc-usage`` of ``1 kW`` forces it to consume exactly 1 kW of gas every hour, which the optimiser cannot change. ``production-capacity`` of 0 kW means it can never feed back. + +The prices live in the ``flex-context``. For a single commodity you would pass ``consumption-price`` and ``production-price`` directly. For **multiple commodities**, you instead provide a ``commodities`` list, one entry per commodity: + +.. code-block:: json + + { + "flex-context": { + "commodities": [ + { + "commodity": "electricity", + "consumption-price": "100 EUR/MWh", + "production-price": "100 EUR/MWh" + }, + { + "commodity": "gas", + "consumption-price": "50 EUR/MWh", + "production-price": "50 EUR/MWh" + } + ] + } + } + +Each device's costs are then evaluated against the prices of *its own* commodity: the battery against electricity, the boiler against gas. + +.. note:: All commodities in one scheduling problem must share the same currency (here, EUR). The prices themselves can of course differ, and may be time series or sensors just like any other price in FlexMeasures. + + +Triggering the schedule +======================= + +We schedule on the **site asset**, so that FlexMeasures considers both devices together in a single optimisation. + +.. tabs:: + + .. tab:: CLI + + .. code-block:: bash + + $ flexmeasures add schedule \ + --asset 1 \ + --start 2024-01-01T00:00+01:00 \ + --duration PT24H \ + --flex-model flex-model-multi-commodity.json \ + --flex-context flex-context-multi-commodity.json + New schedule is stored. + + .. tab:: API + + Example call: `[POST] http://localhost:5000/api/v3_0/assets/1/schedules/trigger <../api/v3_0.html#post--api-v3_0-assets-id-schedules-trigger>`_: + + .. code-block:: json + + { + "start": "2024-01-01T00:00:00+01:00", + "duration": "PT24H", + "flex-model": [ + { + "sensor": 1, + "commodity": "electricity", + "state-of-charge": {"sensor": 3}, + "soc-at-start": 20.0, + "soc-min": 0.0, + "soc-max": 100.0, + "soc-targets": [ + {"datetime": "2024-01-01T23:00:00+01:00", "value": 80.0} + ], + "power-capacity": "20 kW", + "charging-efficiency": 0.95, + "discharging-efficiency": 0.95 + }, + { + "sensor": 2, + "commodity": "gas", + "power-capacity": "30 kW", + "consumption-capacity": "30 kW", + "production-capacity": "0 kW", + "soc-usage": ["1 kW"], + "soc-min": 0.0, + "soc-max": 0.0, + "soc-at-start": 0.0 + } + ], + "flex-context": { + "commodities": [ + { + "commodity": "electricity", + "consumption-price": "100 EUR/MWh", + "production-price": "100 EUR/MWh" + }, + { + "commodity": "gas", + "consumption-price": "50 EUR/MWh", + "production-price": "50 EUR/MWh" + } + ] + } + } + + .. tab:: FlexMeasures Client + + Using the `FlexMeasures Client `_: + + .. code-block:: python + + schedule = await client.trigger_and_get_schedule( + asset_id=1, # the site asset + start="2024-01-01T00:00:00+01:00", + duration="PT24H", + flex_model=[ + { + "sensor": 1, # battery power sensor + "commodity": "electricity", + "state-of-charge": {"sensor": 3}, # battery SoC sensor + "soc-at-start": 20.0, + "soc-min": 0.0, + "soc-max": 100.0, + "soc-targets": [ + {"datetime": "2024-01-01T23:00:00+01:00", "value": 80.0} + ], + "power-capacity": "20 kW", + "charging-efficiency": 0.95, + "discharging-efficiency": 0.95, + }, + { + "sensor": 2, # boiler power sensor + "commodity": "gas", + "power-capacity": "30 kW", + "consumption-capacity": "30 kW", + "production-capacity": "0 kW", + "soc-usage": ["1 kW"], + "soc-min": 0.0, + "soc-max": 0.0, + "soc-at-start": 0.0, + }, + ], + flex_context={ + "commodities": [ + { + "commodity": "electricity", + "consumption-price": "100 EUR/MWh", + "production-price": "100 EUR/MWh", + }, + { + "commodity": "gas", + "consumption-price": "50 EUR/MWh", + "production-price": "50 EUR/MWh", + }, + ] + }, + ) + +The scheduler returns one schedule per device (stored on sensors ``1`` and ``2``) and a single commitment-cost result that breaks the cost down per commodity. + + +What to expect +============== + +The asset chart shows both commodities together, with the battery's stock level in between: + +.. image:: https://github.com/FlexMeasures/screenshots/raw/main/tut/multi-commodity.png + :align: center + :alt: Asset-level chart of the hybrid site, showing battery power, battery state of charge, and the gas boiler. +| + +Reading the chart top to bottom: + +- **Battery power (electricity)** charges at its full 20 kW for the first three hours, then makes one partial-power step to land exactly on the 80 kWh target, and sits idle for the rest of the day. In the final hour it discharges at −20 kW. Because the electricity price is flat, there is no cheaper window to wait for, so it simply charges as early as possible (``prefer-charging-sooner`` is on by default). +- **Battery state of charge** makes the effect of that power schedule explicit: the stock rises from the 20 kWh ``soc-at-start``, reaches the 80 kWh target during the morning, holds there through the idle hours, and drops in the final hour as the battery discharges. This is the charge level you would otherwise have to infer from the power curve. +- **Gas boiler (gas)** runs at exactly 1 kW every single hour. The ``soc-usage`` field makes this a fixed load that the optimiser cannot shift — its only effect on the result is the gas cost it incurs. + +The schedules match the cost figures reported by the scheduler: + +.. code-block:: text + + Electricity (battery) + Net charge needed : 80 kWh − 20 kWh = 60 kWh stored + Grid draw : 60 kWh ÷ 0.95 = 63.16 kWh + Charge cost : 63.16 kWh × 100 EUR/MWh ≈ 6.32 EUR + Discharge credit : 20 kWh × 100 EUR/MWh = −2.00 EUR + Net electricity ≈ 4.32 EUR + + Gas (boiler) + Consumption : 1 kW × 24 h = 24 kWh + Gas cost : 0.024 MWh × 50 EUR/MWh = 1.20 EUR + + Total = 5.52 EUR + +The commitment-cost result keeps these as separate entries — ``electricity net energy`` (≈ 4.32 EUR) and ``gas net energy`` (1.20 EUR) — so you can always see how much each commodity contributed. +Because the gas price (50 EUR/MWh) is half the electricity price, serving the constant baseline with gas rather than electricity is the cheaper choice for that part of the load. + +.. note:: This same pattern extends to more devices and more commodities. Add further entries to the ``flex-model`` list (each with its ``commodity``) and a matching entry in the ``flex-context`` ``commodities`` list. As long as all commodities share one currency, FlexMeasures optimises them together and reports each commodity's cost on its own. + +We hope this demonstration helped to illustrate multi-commodity scheduling. +To revisit scheduling several devices that share a single commodity and stock, head back to :ref:`tut_multi_feed_storage`. diff --git a/documentation/tut/multi-feed-storage.rst b/documentation/tut/multi-feed-storage.rst new file mode 100644 index 0000000000..d74ac306e2 --- /dev/null +++ b/documentation/tut/multi-feed-storage.rst @@ -0,0 +1,224 @@ +.. _tut_multi_feed_storage: + +A flex-modeling tutorial for storage: Multiple feeds into shared stock +---------------------------------------------------------------------- + +So far, our storage tutorials have considered a single power port charging and discharging a single battery. +But what if a battery is fed by *more than one* inverter, each with its own power rating and efficiency? + +This is a common situation in practice: a single storage tank or battery pack is connected to several converters, and they all charge and discharge the *same* pool of energy. +FlexMeasures supports this through what we call **multiple feeds into a shared stock**: several flexible devices are scheduled together, while they all point at one shared ``state-of-charge`` sensor. + +In this tutorial we will model exactly such a system and let the scheduler decide which inverter to use, and when, taking each inverter's efficiency into account. +(For a more general introduction to flex modeling, see :ref:`describing_flexibility`. For a single-device storage walk-through, see :ref:`tut_v2g`.) + + +The use case +============ + +Consider a single battery with two inverters feeding it, and a single state-of-charge sensor for the battery: + +- Both inverters can charge and discharge the battery, but with **different efficiencies**. +- The battery has a **single state of charge** that both inverters affect. +- The scheduler should recognise the shared stock and optimise accordingly, without duplicating baselines or costs. + +Concretely, we model: + +- A ``battery`` asset, with a ``power`` sensor (the aggregate) and an instantaneous ``state-of-charge`` sensor (in kWh). +- Two ``inverter`` assets (``inverter 1`` and ``inverter 2``), each with its own ``power`` sensor, rated at 20 kW. +- Inverter 1 is symmetric and efficient in both directions (95% charging, 95% discharging). +- Inverter 2 charges almost loss-free (99%) but discharges poorly (45%). + +The battery starts at 20 kWh, may not drop below 10 kWh or exceed 200 kWh, and has to reach a target of 189 kWh at noon. + + +Building the flex model +======================= + +The key idea is that the ``flex-model`` is a **list**, with one entry per flexible device, plus one entry that describes the shared stock. +Each inverter entry references its own power sensor *and* the same ``state-of-charge`` sensor. +The final entry (without a power ``sensor``) carries the constraints that apply to the shared stock itself: the start, the bounds, and the target. + +.. code-block:: json + + { + "flex-model": [ + { + "sensor": 1, + "state-of-charge": {"sensor": 4}, + "power-capacity": "20 kW", + "charging-efficiency": 0.95, + "discharging-efficiency": 0.95 + }, + { + "sensor": 2, + "state-of-charge": {"sensor": 4}, + "power-capacity": "20 kW", + "charging-efficiency": 0.99, + "discharging-efficiency": 0.45 + }, + { + "state-of-charge": {"sensor": 4}, + "soc-at-start": 20.0, + "soc-min": 10, + "soc-max": 200.0, + "soc-targets": [ + {"datetime": "2024-01-01T12:00:00+01:00", "value": 189.0} + ] + } + ] + } + +Here, sensors ``1`` and ``2`` are the power sensors of inverter 1 and inverter 2, respectively, and sensor ``4`` is the shared ``state-of-charge`` sensor on the battery. + +A few things to note: + +- **Each device points at the same ``state-of-charge`` sensor.** This is what tells FlexMeasures that the devices share one stock. The scheduler links the energy balance of all feeds to that single state of charge, rather than tracking a separate stock per device. +- **The shared-stock entry has no power ``sensor``.** It only carries the storage-level fields (``soc-at-start``, ``soc-min``, ``soc-max``, ``soc-targets``), which describe the battery as a whole and must therefore not be repeated per inverter. +- **Per-device efficiencies live in the device entries.** ``charging-efficiency`` and ``discharging-efficiency`` differ between the two inverters, which is exactly the difference the scheduler will exploit. + +.. note:: The ``state-of-charge`` sensor should have an instantaneous resolution (``PT0M``), since it records a stock value at a point in time rather than a quantity accumulated over an interval. See the ``state-of-charge`` field in :ref:`flex_models_and_schedulers`. + +For the costs, we use a flat tariff in this example, so price differences over time do not drive the schedule, only the efficiency differences do: + +.. code-block:: json + + { + "flex-context": { + "consumption-price": "100 EUR/MWh", + "production-price": "100 EUR/MWh" + } + } + + +Triggering the schedule +======================= + +We schedule on the **battery asset**, so that FlexMeasures considers both inverters together as feeds into the battery's shared stock. + +.. tabs:: + + .. tab:: CLI + + .. code-block:: bash + + $ flexmeasures add schedule \ + --asset 1 \ + --start 2024-01-01T00:00+01:00 \ + --duration PT24H \ + --flex-model flex-model-multi-feed.json \ + --flex-context flex-context-flat-price.json + New schedule is stored. + + .. tab:: API + + Example call: `[POST] http://localhost:5000/api/v3_0/assets/1/schedules/trigger <../api/v3_0.html#post--api-v3_0-assets-id-schedules-trigger>`_: + + .. code-block:: json + + { + "start": "2024-01-01T00:00:00+01:00", + "duration": "PT24H", + "flex-model": [ + { + "sensor": 1, + "state-of-charge": {"sensor": 4}, + "power-capacity": "20 kW", + "charging-efficiency": 0.95, + "discharging-efficiency": 0.95 + }, + { + "sensor": 2, + "state-of-charge": {"sensor": 4}, + "power-capacity": "20 kW", + "charging-efficiency": 0.99, + "discharging-efficiency": 0.45 + }, + { + "state-of-charge": {"sensor": 4}, + "soc-at-start": 20.0, + "soc-min": 10, + "soc-max": 200.0, + "soc-targets": [ + {"datetime": "2024-01-01T12:00:00+01:00", "value": 189.0} + ] + } + ], + "flex-context": { + "consumption-price": "100 EUR/MWh", + "production-price": "100 EUR/MWh" + } + } + + .. tab:: FlexMeasures Client + + Using the `FlexMeasures Client `_: + + .. code-block:: python + + schedule = await client.trigger_and_get_schedule( + asset_id=1, # the battery asset + start="2024-01-01T00:00:00+01:00", + duration="PT24H", + flex_model=[ + { + "sensor": 1, # inverter 1 power sensor + "state-of-charge": {"sensor": 4}, + "power-capacity": "20 kW", + "charging-efficiency": 0.95, + "discharging-efficiency": 0.95, + }, + { + "sensor": 2, # inverter 2 power sensor + "state-of-charge": {"sensor": 4}, + "power-capacity": "20 kW", + "charging-efficiency": 0.99, + "discharging-efficiency": 0.45, + }, + { + "state-of-charge": {"sensor": 4}, # shared stock + "soc-at-start": 20.0, + "soc-min": 10, + "soc-max": 200.0, + "soc-targets": [ + {"datetime": "2024-01-01T12:00:00+01:00", "value": 189.0} + ], + }, + ], + flex_context={ + "consumption-price": "100 EUR/MWh", + "production-price": "100 EUR/MWh", + }, + ) + + +The scheduler returns one schedule per inverter (stored on sensors ``1`` and ``2``), the resulting state of charge (stored on the shared ``state-of-charge`` sensor ``4``), and a single, aggregated commitment-cost result. +Note that the costs are *not* duplicated per device: because the inverters feed one shared stock, FlexMeasures computes a single energy balance and a single cost. + + +What to expect +============== + +With a flat tariff, the schedule is driven purely by the efficiency differences between the two inverters. +The scheduler specialises each inverter for the operation it is best at: + +- **Charging** happens through **inverter 2** (99% charging efficiency). It charges continuously from the start until the battery reaches the 189 kWh target at noon. Inverter 1 stays idle while charging. +- **Discharging** happens through **inverter 1** (95% discharging efficiency, versus only 45% for inverter 2). After the target is reached, inverter 1 discharges the battery back down towards its ``soc-min`` of 10 kWh. Inverter 2 stays idle while discharging. + +So, even though both inverters *can* both charge and discharge, the optimiser uses inverter 2 only to charge and inverter 1 only to discharge — each inverter ends up doing what it is most efficient at. + +.. image:: https://github.com/FlexMeasures/screenshots/raw/main/tut/multi-feed-asset.png + :align: center +| + +Reading the chart top to bottom: + +- **Inverters** (top panel) shows the power schedule of both feeds together. Inverter 2 (the 99%-efficient charger) runs at its full +20 kW from the start of the horizon and tapers off in a single partial step once the target is reached — it only ever charges. Inverter 1 (the 95%-efficient discharger) stays idle while the battery fills, then runs at -20 kW late in the horizon — it only ever discharges. Even though both inverters *can* do both, the optimiser specialises each for the operation it is most efficient at. +- **Shared storage** (bottom panel) shows the *single* ``state-of-charge`` sensor that both inverters feed. It starts at the 20 kWh ``soc-at-start``, climbs while inverter 2 charges, reaches and briefly holds the 189 kWh target, and then falls as inverter 1 discharges — bottoming out at the 10 kWh ``soc-min``. This one curve is the combined effect of both feeds, which is exactly what "shared stock" means. + +The net energy cost over the horizon is small (about 0.066 EUR at 100 EUR/MWh), and reflects only the energy lost to the inverter efficiencies, since charging and discharging happen at the same flat price. + +.. note:: This same pattern generalises beyond two inverters and beyond batteries. Any number of devices can feed a shared stock — for example, several heat pumps charging one thermal buffer — as long as each device entry references the same ``state-of-charge`` sensor and a single entry carries the shared-stock constraints. + +We hope this demonstration helped to illustrate how FlexMeasures schedules multiple feeds into a shared stock. +For modelling a single storage device in more depth, head back to :ref:`tut_v2g`. diff --git a/flexmeasures/api/common/schemas/scheduling.py b/flexmeasures/api/common/schemas/scheduling.py index f33c5ee555..92c02329e5 100644 --- a/flexmeasures/api/common/schemas/scheduling.py +++ b/flexmeasures/api/common/schemas/scheduling.py @@ -1,6 +1,6 @@ from flexmeasures.api.common.schemas.utils import make_openapi_compatible from flexmeasures.data.schemas.scheduling.storage import StorageFlexModelSchema -from flexmeasures.data.schemas.scheduling import FlexContextSchema +from flexmeasures.data.schemas.scheduling import CommodityFlexContextSchema from flexmeasures.data.schemas.sensors import SensorIdField @@ -18,4 +18,4 @@ } ], ) -flex_context_schema_openAPI = make_openapi_compatible(FlexContextSchema) +flex_context_schema_openAPI = make_openapi_compatible(CommodityFlexContextSchema) diff --git a/flexmeasures/api/v3_0/assets.py b/flexmeasures/api/v3_0/assets.py index e4599e2737..5e645b2216 100644 --- a/flexmeasures/api/v3_0/assets.py +++ b/flexmeasures/api/v3_0/assets.py @@ -96,12 +96,14 @@ def __init__(self, *args, **kwargs): kwargs["exclude"] = ["asset"] super().__init__(*args, **kwargs) - flex_context = fields.Nested( - flex_context_schema_openAPI, - load_default={}, + flex_context = fields.List( + fields.Nested( + flex_context_schema_openAPI(), + ), + load_default=[], data_key="flex-context", metadata=dict( - description="The flex-context is validated according to the scheduler's `FlexContextSchema`.", + description="Flex-context per commodity. The flex-context is validated according to the scheduler's `FlexContextSchema`.", ), ) flex_model = fields.List( diff --git a/flexmeasures/data/models/planning/__init__.py b/flexmeasures/data/models/planning/__init__.py index d7fbbb43b9..0f8c606d2f 100644 --- a/flexmeasures/data/models/planning/__init__.py +++ b/flexmeasures/data/models/planning/__init__.py @@ -14,7 +14,7 @@ from flexmeasures.data import db from flexmeasures.data.models.time_series import Sensor from flexmeasures.data.models.generic_assets import GenericAsset as Asset -from flexmeasures.utils.coding_utils import deprecated +from flexmeasures.utils.coding_utils import deprecated, merge_or_append from .exceptions import WrongEntityException @@ -220,8 +220,19 @@ def collect_flex_config(self): asset = self.asset else: asset = self.sensor.generic_asset + + # Merge the passed flex_context with the db_flex_context by matching commodities db_flex_context = asset.get_flex_context() - self.flex_context = {**db_flex_context, **self.flex_context} + if isinstance(self.flex_context, dict): + self.flex_context = {**db_flex_context, **self.flex_context} + elif isinstance(self.flex_context, list): + # Currently, db_flex_context is always a dict describing only electricity + merge_or_append( + db_flex_context, + self.flex_context, + match_key="commodity", + match_value="electricity", + ) # Merge the passed flex_model with the db_flex_model by matching asset IDs db_flex_model = asset.get_flex_model() diff --git a/flexmeasures/data/models/planning/storage.py b/flexmeasures/data/models/planning/storage.py index aba6b95132..7ed42097d1 100644 --- a/flexmeasures/data/models/planning/storage.py +++ b/flexmeasures/data/models/planning/storage.py @@ -8,7 +8,7 @@ import pandas as pd import numpy as np from flask import current_app - +from marshmallow import ValidationError from flexmeasures import Asset, Sensor from flexmeasures.data import db @@ -32,6 +32,7 @@ from flexmeasures.data.models.planning.exceptions import InfeasibleProblemException from flexmeasures.data.schemas.scheduling.storage import StorageFlexModelSchema from flexmeasures.data.schemas.scheduling import ( + CommodityFlexContextSchema, FlexContextSchema, MultiSensorFlexModelSchema, ) @@ -1300,6 +1301,8 @@ def convert_to_commitments( for d, flex_model_d in enumerate(flex_model): commitment = FlowCommitment( device=d, + # todo: is flex_model_d guaranteed to have "commodity? Consider defaulting the device commodity to "electricity" + # todo: should there not be something matching the "commodity" from the commitment_spec (default to "electricity") to the device commodity? device_group=flex_model_d["commodity"], **commitment_spec, ) @@ -1337,8 +1340,48 @@ def deserialize_flex_config(self): self.flex_model = {} self.collect_flex_config() - self.flex_context = FlexContextSchema().load(self.flex_context) + self._deserialize_flex_context() + self._deserialize_flex_model() + + def _deserialize_flex_context(self): + if isinstance(self.flex_context, dict): + # Load the one flex-context for electricity + self.flex_context = FlexContextSchema().load(self.flex_context) + elif isinstance(self.flex_context, list): + # Load each flex-context per commodity + for g, commodity_flex_context in enumerate(self.flex_context): + self.flex_context[g] = CommodityFlexContextSchema().load( + commodity_flex_context + ) + + # Ensure all flex-contexts share the same currency unit + # todo: move this into a validator for FlexContextSchema.commodity_contexts? + shared_currency_unit = None + for commodity_flex_context in self.flex_context: + shared_currency_unit = commodity_flex_context["shared_currency_unit"] + if shared_currency_unit is None: + shared_currency_unit = commodity_flex_context[ + "shared_currency_unit" + ] + elif ( + commodity_flex_context["shared_currency_unit"] + != shared_currency_unit + ): + raise ValidationError( + f"All prices in the flex-context must share the same currency unit (in this case: '{shared_currency_unit}')." + ) + + # Nest the flex-contexts per commodity under the commodity_contexts field + self.flex_context = dict( + commodity_contexts=self.flex_context, + shared_currency_unit=shared_currency_unit, + ) + else: + raise TypeError( + f"Unsupported type of flex-context: '{type(self.flex_context)}'" + ) + def _deserialize_flex_model(self): if isinstance(self.flex_model, dict): if self.sensor.generic_asset.asset_type.name in storage_asset_types: self.ensure_soc_at_start() diff --git a/flexmeasures/data/models/planning/tests/test_commitments.py b/flexmeasures/data/models/planning/tests/test_commitments.py index 49528382d4..d9ffc8a2dc 100644 --- a/flexmeasures/data/models/planning/tests/test_commitments.py +++ b/flexmeasures/data/models/planning/tests/test_commitments.py @@ -763,20 +763,18 @@ def test_mixed_gas_and_electricity_assets(app, db): }, ] - flex_context = { - "commodities": [ - { - "commodity": "electricity", - "consumption-price": "100 EUR/MWh", # electricity price - "production-price": "100 EUR/MWh", - }, - { - "commodity": "gas", - "consumption-price": "50 EUR/MWh", # gas price - "production-price": "50 EUR/MWh", - }, - ] - } + flex_context = [ + { + "commodity": "electricity", + "consumption-price": "100 EUR/MWh", # electricity price + "production-price": "100 EUR/MWh", + }, + { + "commodity": "gas", + "consumption-price": "50 EUR/MWh", # gas price + "production-price": "50 EUR/MWh", + }, + ] scheduler = StorageScheduler( asset_or_sensor=battery, diff --git a/flexmeasures/data/schemas/scheduling/__init__.py b/flexmeasures/data/schemas/scheduling/__init__.py index 3cd8dc50d3..58cb2ac8b3 100644 --- a/flexmeasures/data/schemas/scheduling/__init__.py +++ b/flexmeasures/data/schemas/scheduling/__init__.py @@ -23,6 +23,7 @@ VariableQuantityField, SensorIdField, SensorReference, + OutputSensorReferenceSchema, ) from flexmeasures.data.schemas.scheduling import metadata from flexmeasures.data.schemas.units import UnitField @@ -143,6 +144,8 @@ class DBCommitmentSchema(CommitmentSchema, NoTimeSeriesSpecs): class SharedSchema(Schema): + """Shared schema for fields common across commodities in flex-context and commodity-context.""" + consumption_price = VariableQuantityField( "/MWh", required=False, @@ -233,51 +236,7 @@ class SharedSchema(Schema): metadata=metadata.SITE_PEAK_PRODUCTION_PRICE.to_dict(), ) - commitments = fields.Nested( - CommitmentSchema, - data_key="commitments", - required=False, - many=True, - metadata=metadata.COMMITMENTS.to_dict(), - ) - - inflexible_device_sensors = fields.List( - SensorIdField(), - data_key="inflexible-device-sensors", - metadata=metadata.INFLEXIBLE_DEVICE_SENSORS.to_dict(), - ) - - -class CommodityFlexContextSchema(SharedSchema): - commodity = fields.Str( - required=False, - load_default="electricity", - data_key="commodity", - metadata=metadata.COMMODITY_FLEX_CONTEXT.to_dict(), - ) - - def __init__(self, *args, **kwargs): - super().__init__(*args, **kwargs) - - commodity_field = self.fields.pop("commodity") - self.fields = OrderedDict( - [("commodity", commodity_field), *self.fields.items()] - ) - - -class FlexContextSchema(SharedSchema): - """This schema defines fields that provide context to the portfolio to be optimized.""" - - commodity_contexts = fields.Nested( - CommodityFlexContextSchema, - data_key="commodities", - required=False, - many=True, - metadata=dict( - description="For multi-commodity scheduling problems, the above fields can be set here per commodity.", - ), - ) - # Device commitments + # Breach prices for device capacity constraints consumption_breach_price = VariableQuantityField( "/MW", data_key="consumption-breach-price", @@ -306,12 +265,13 @@ class FlexContextSchema(SharedSchema): value_validator=validate.Range(min=0), metadata=metadata.SOC_MAXIMA_BREACH_PRICE.to_dict(), ) + + # Relaxation fields relax_constraints = fields.Bool( data_key="relax-constraints", load_default=False, metadata=metadata.RELAX_CONSTRAINTS.to_dict(), ) - # Dev fields relax_soc_constraints = fields.Bool( data_key="relax-soc-constraints", load_default=False, @@ -328,17 +288,32 @@ class FlexContextSchema(SharedSchema): metadata=metadata.RELAX_SITE_CAPACITY_CONSTRAINTS.to_dict(), ) - # Energy commitments - # todo: deprecated since flexmeasures==0.23 - consumption_price_sensor = SensorIdField(data_key="consumption-price-sensor") - production_price_sensor = SensorIdField(data_key="production-price-sensor") + commitments = fields.Nested( + CommitmentSchema, + data_key="commitments", + required=False, + many=True, + metadata=metadata.COMMITMENTS.to_dict(), + ) - # todo: group by month start (MS), something like a commitment resolution, or a list of datetimes representing splits of the commitments - aggregate_power = VariableQuantityField( - to_unit="MW", - data_key="aggregate-power", + inflexible_device_sensors = fields.List( + SensorIdField(), + data_key="inflexible-device-sensors", + metadata=metadata.INFLEXIBLE_DEVICE_SENSORS.to_dict(), + ) + + # Aggregate output sensors + aggregate_consumption = fields.Nested( + OutputSensorReferenceSchema, required=False, - metadata=metadata.AGGREGATE_POWER.to_dict(), + data_key="aggregate-consumption", + metadata=metadata.AGGREGATE_CONSUMPTION.to_dict(), + ) + aggregate_production = fields.Nested( + OutputSensorReferenceSchema, + required=False, + data_key="aggregate-production", + metadata=metadata.AGGREGATE_PRODUCTION.to_dict(), ) def set_default_breach_prices( @@ -357,6 +332,109 @@ def set_default_breach_prices( ) return data + @validates_schema(pass_original=True) + def _try_to_convert_price_units(self, data: dict, original_data: dict, **kwargs): + """Convert price units to the same unit and scale if they can (incl. same currency).""" + + shared_currency_unit = None + previous_field_name = None + for field in self.declared_fields: + if field[-5:] == "price" and field in data: + price_field = self.declared_fields[field] + price_unit = price_field._get_unit(data[field]) + currency_unit = str( + ( + ur.Quantity(price_unit) / ur.Quantity(f"1{price_field.to_unit}") + ).units + ) + + if shared_currency_unit is None: + shared_currency_unit = str( + ur.Quantity(currency_unit).to_base_units().units + ) + previous_field_name = price_field.data_key + if not units_are_convertible(currency_unit, shared_currency_unit): + field_name = price_field.data_key + original_price_unit = price_field._get_original_unit( + original_data[field_name], data[field] + ) + error_message = f"Invalid unit. A valid unit would be, for example, '{shared_currency_unit + price_field.to_unit}' (this example uses '{shared_currency_unit}', because '{previous_field_name}' used that currency). However, you passed an incompatible price ('{original_price_unit}') for the '{field_name}' field." + if shared_currency_unit not in price_unit: + error_message += f" Also note that all prices in the flex-context must share the same currency unit (in this case: '{shared_currency_unit}')." + raise ValidationError(error_message, field_name=field_name) + if shared_currency_unit is not None: + data["shared_currency_unit"] = shared_currency_unit + elif sensor := data.get("consumption_price_sensor"): + data["shared_currency_unit"] = self._to_currency_per_mwh(sensor.unit) + elif sensor := data.get("production_price_sensor"): + data["shared_currency_unit"] = self._to_currency_per_mwh(sensor.unit) + else: + data["shared_currency_unit"] = "EUR" + return data + + @staticmethod + def _to_currency_per_mwh(price_unit: str) -> str: + """Convert a price unit to a base currency used to express that price per MWh. + + >>> FlexContextSchema()._to_currency_per_mwh("EUR/MWh") + 'EUR' + >>> FlexContextSchema()._to_currency_per_mwh("EUR/kWh") + 'EUR' + """ + currency = str(ur.Quantity(price_unit + " * MWh").to_base_units().units) + return currency + + +class CommodityFlexContextSchema(SharedSchema): + commodity = fields.Str( + required=False, + load_default="electricity", + data_key="commodity", + metadata=metadata.COMMODITY_FLEX_CONTEXT.to_dict(), + ) + + # For flex-context listings (per commodity), default relax_constraints to True + relax_constraints = fields.Bool( + data_key="relax-constraints", + load_default=True, + metadata=metadata.RELAX_CONSTRAINTS.to_dict(), + ) + + def __init__(self, *args, **kwargs): + super().__init__(*args, **kwargs) + + commodity_field = self.fields.pop("commodity") + self.fields = OrderedDict( + [("commodity", commodity_field), *self.fields.items()] + ) + + +class FlexContextSchema(SharedSchema): + """This schema defines fields that provide context to the portfolio to be optimized.""" + + commodity_contexts = fields.Nested( + CommodityFlexContextSchema, + data_key="commodities", + required=False, + many=True, + metadata=dict( + description="For multi-commodity scheduling problems, the above fields can be set here per commodity.", + ), + ) + + # Energy commitments + # todo: deprecated since flexmeasures==0.23 + consumption_price_sensor = SensorIdField(data_key="consumption-price-sensor") + production_price_sensor = SensorIdField(data_key="production-price-sensor") + + # todo: group by month start (MS), something like a commitment resolution, or a list of datetimes representing splits of the commitments + aggregate_power = VariableQuantityField( + to_unit="MW", + data_key="aggregate-power", + required=False, + metadata=metadata.AGGREGATE_POWER.to_dict(), + ) + @validates("aggregate_power") def validate_aggregate_power_is_sensor( self, @@ -370,6 +448,42 @@ def validate_aggregate_power_is_sensor( if not isinstance(aggregate_power, Sensor): raise ValidationError("The `aggregate-power` field can only be a Sensor.") + @validates("commodity_contexts") + def validate_commodity_contexts_shared_currency( + self, commodity_contexts: list[dict], **kwargs + ): + """Validate that all prices across commodity contexts share the same currency.""" + if not commodity_contexts: + return + + shared_currency_unit = None + + for context in commodity_contexts: + # Check all price fields in this context + for field_name, field_value in context.items(): + if field_name.endswith("_price") and field_value is not None: + # Get the price unit + if hasattr(field_value, "units"): + price_unit = str(field_value.units) + elif isinstance(field_value, ur.Quantity): + price_unit = str(field_value.units) + else: + continue + + # Extract currency from the price unit + # Price units are typically like "EUR/MWh" or "USD/MW" + # Split by "/" and take first part as currency + currency_unit = price_unit.split("/")[0].strip() + + if shared_currency_unit is None: + shared_currency_unit = str( + ur.Quantity(currency_unit).to_base_units().units + ) + elif not units_are_convertible(currency_unit, shared_currency_unit): + raise ValidationError( + "all prices in the flex-context must share the same currency unit" + ) + @validates_schema(pass_original=True) def check_prices(self, data: dict, original_data: dict, **kwargs): """Check assumptions about prices. @@ -466,57 +580,6 @@ def check_prices(self, data: dict, original_data: dict, **kwargs): return data - def _try_to_convert_price_units(self, data: dict, original_data: dict): - """Convert price units to the same unit and scale if they can (incl. same currency).""" - - shared_currency_unit = None - previous_field_name = None - for field in self.declared_fields: - if field[-5:] == "price" and field in data: - price_field = self.declared_fields[field] - price_unit = price_field._get_unit(data[field]) - currency_unit = str( - ( - ur.Quantity(price_unit) / ur.Quantity(f"1{price_field.to_unit}") - ).units - ) - - if shared_currency_unit is None: - shared_currency_unit = str( - ur.Quantity(currency_unit).to_base_units().units - ) - previous_field_name = price_field.data_key - if not units_are_convertible(currency_unit, shared_currency_unit): - field_name = price_field.data_key - original_price_unit = price_field._get_original_unit( - original_data[field_name], data[field] - ) - error_message = f"Invalid unit. A valid unit would be, for example, '{shared_currency_unit + price_field.to_unit}' (this example uses '{shared_currency_unit}', because '{previous_field_name}' used that currency). However, you passed an incompatible price ('{original_price_unit}') for the '{field_name}' field." - if shared_currency_unit not in price_unit: - error_message += f" Also note that all prices in the flex-context must share the same currency unit (in this case: '{shared_currency_unit}')." - raise ValidationError(error_message, field_name=field_name) - if shared_currency_unit is not None: - data["shared_currency_unit"] = shared_currency_unit - elif sensor := data.get("consumption_price_sensor"): - data["shared_currency_unit"] = self._to_currency_per_mwh(sensor.unit) - elif sensor := data.get("production_price_sensor"): - data["shared_currency_unit"] = self._to_currency_per_mwh(sensor.unit) - else: - data["shared_currency_unit"] = "EUR" - return data - - @staticmethod - def _to_currency_per_mwh(price_unit: str) -> str: - """Convert a price unit to a base currency used to express that price per MWh. - - >>> FlexContextSchema()._to_currency_per_mwh("EUR/MWh") - 'EUR' - >>> FlexContextSchema()._to_currency_per_mwh("EUR/kWh") - 'EUR' - """ - currency = str(ur.Quantity(price_unit + " * MWh").to_base_units().units) - return currency - EXAMPLE_UNIT_TYPES: Dict[str, list[str]] = { "commodity": ["electricity", "gas"], @@ -529,6 +592,26 @@ def _to_currency_per_mwh(price_unit: str) -> str: } UI_FLEX_CONTEXT_SCHEMA: Dict[str, Dict[str, Any]] = { + "aggregate-consumption": { + "default": None, + "description": rst_to_openapi(metadata.AGGREGATE_CONSUMPTION.description), + # todo: the field type is defined in asset_context.html in 3 places? + # "types": { + # "backend": "typeTwo", + # "ui": "A sensor which records the scheduled aggregate consumption.", + # }, + "example-units": EXAMPLE_UNIT_TYPES["power"], + }, + "aggregate-production": { + "default": None, + "description": rst_to_openapi(metadata.AGGREGATE_PRODUCTION.description), + # todo: the field type is defined in asset_context.html in 3 places? + # "types": { + # "backend": "typeTwo", + # "ui": "A sensor which records the scheduled aggregate production.", + # }, + "example-units": EXAMPLE_UNIT_TYPES["power"], + }, "consumption-price": { "default": None, # Refers to default value of the field "description": rst_to_openapi(metadata.CONSUMPTION_PRICE.description), diff --git a/flexmeasures/data/schemas/scheduling/metadata.py b/flexmeasures/data/schemas/scheduling/metadata.py index 7463579864..88d40b9ef9 100644 --- a/flexmeasures/data/schemas/scheduling/metadata.py +++ b/flexmeasures/data/schemas/scheduling/metadata.py @@ -42,9 +42,37 @@ def to_dict(self): example=[3, 4], ) AGGREGATE_POWER = MetaData( - description="""Sensor used to record the aggregate power schedule of all flexible and inflexible devices involved when scheduling this asset.""", + description="""[Deprecated field] Sensor used to record the aggregate power schedule of all flexible and inflexible devices involved when scheduling this asset. +To avoid using the field, use ``aggregate-consumption`` or ``aggregate-production`` instead, which make clear the sign convention. +""", example={"sensor": 9}, ) +AGGREGATE_CONSUMPTION = MetaData( + description="""Sensor used to record the aggregate consumption schedule of all flexible and inflexible devices involved when scheduling this asset. + +The sign convention is determined by the key name, and is stored on the sensor itself using the ``consumption_is_positive`` attribute. + +Depending on which output sensors are defined: + +- **Only** ``aggregate-consumption`` **defined**: the full aggregate power schedule is stored on this sensor using the + consumption-positive sign convention (consumption positive, production negative). +- **Only** ``aggregate-production`` **defined**: the full aggregate power schedule is stored on the aggregate-production sensor + with the production-positive convention (production positive, consumption negative). +- **Both defined**: only the non-negative part of the aggregate schedule is stored on this sensor (zero for + time steps with net production), and only the non-positive part (sign-flipped) is stored on the + aggregate-production sensor. +""", + example={"sensor": 10}, +) +AGGREGATE_PRODUCTION = MetaData( + description="""Sensor used to record the aggregate production schedule of all flexible and inflexible devices involved when scheduling this asset. + +The sign convention is determined by the key name, and is stored on the sensor itself using the ``consumption_is_positive`` attribute. + +See the ``aggregate-consumption`` field for the full description of the split logic when both sensors are defined. +""", + example={"sensor": 11}, +) COMMITMENTS = MetaData( description="Prior commitments. Support for this field in the UI is still under further development, but you can find more information in :ref:`commitments`.", example=[], @@ -217,7 +245,7 @@ def to_dict(self): The sign convention is determined by the key name, and is stored on the sensor itself using the ``consumption_is_positive`` attribute. -See ``consumption`` for the full description of the split logic when both sensors are defined. +See the ``consumption`` field for the full description of the split logic when both sensors are defined. """, example={"sensor": 15}, ) diff --git a/flexmeasures/data/schemas/scheduling/storage.py b/flexmeasures/data/schemas/scheduling/storage.py index 07ad3b46c9..60d9da3448 100644 --- a/flexmeasures/data/schemas/scheduling/storage.py +++ b/flexmeasures/data/schemas/scheduling/storage.py @@ -20,7 +20,7 @@ from flexmeasures.data.schemas.scheduling import metadata from flexmeasures.data.schemas.sensors import ( SensorReference, - SensorReferenceSchema, + OutputSensorReferenceSchema, VariableQuantityField, ) from flexmeasures.utils.unit_utils import ( @@ -44,15 +44,6 @@ total=False, # not all are required (just value, which we can say in 3.11) ) -# Keys used by SensorReferenceSchema to carry source-filter options. -# Present as non-None values when the caller added a source filter. -_SENSOR_REFERENCE_SOURCE_FILTER_KEYS = ( - "source_types", - "exclude_source_types", - "sources", - "source_account", -) - class EfficiencyField(QuantityField): """Field that deserializes to a Quantity with % units. @@ -104,11 +95,11 @@ class StorageFlexModelSchema(Schema): ) consumption = fields.Nested( - SensorReferenceSchema, + OutputSensorReferenceSchema, metadata=metadata.CONSUMPTION.to_dict(), ) production = fields.Nested( - SensorReferenceSchema, + OutputSensorReferenceSchema, metadata=metadata.PRODUCTION.to_dict(), ) @@ -350,20 +341,6 @@ def validate_state_of_charge( "The `state-of-charge` field can only be a Sensor or a time series." ) - @validates("consumption") - def validate_consumption_has_no_source_filters(self, value: dict, **kwargs): - if isinstance(value, dict) and any( - value.get(key) is not None for key in _SENSOR_REFERENCE_SOURCE_FILTER_KEYS - ): - raise ValidationError("The `consumption` field cannot use source filters.") - - @validates("production") - def validate_production_has_no_source_filters(self, value: dict, **kwargs): - if isinstance(value, dict) and any( - value.get(key) is not None for key in _SENSOR_REFERENCE_SOURCE_FILTER_KEYS - ): - raise ValidationError("The `production` field cannot use source filters.") - @validates("asset") def validate_asset(self, asset: Asset, **kwargs): if self.sensor is not None and self.sensor.asset != asset: @@ -448,8 +425,8 @@ class DBStorageFlexModelSchema(Schema): Schema for flex-models stored in the db. Supports fixed quantities and sensor references, while disallowing time series specs. """ - consumption = fields.Nested(SensorReferenceSchema) - production = fields.Nested(SensorReferenceSchema) + consumption = fields.Nested(OutputSensorReferenceSchema) + production = fields.Nested(OutputSensorReferenceSchema) soc_min = VariableQuantityField( to_unit="MWh", @@ -591,20 +568,6 @@ def __init__(self, *args, **kwargs): for field in self.declared_fields } - @validates("consumption") - def validate_consumption_has_no_source_filters(self, value: dict, **kwargs): - if isinstance(value, dict) and any( - value.get(key) is not None for key in _SENSOR_REFERENCE_SOURCE_FILTER_KEYS - ): - raise ValidationError("The `consumption` field cannot use source filters.") - - @validates("production") - def validate_production_has_no_source_filters(self, value: dict, **kwargs): - if isinstance(value, dict) and any( - value.get(key) is not None for key in _SENSOR_REFERENCE_SOURCE_FILTER_KEYS - ): - raise ValidationError("The `production` field cannot use source filters.") - @validates_schema def forbid_time_series_specs(self, data: dict, **kwargs): """Do not allow time series specs for the flex-model fields saved in the db.""" diff --git a/flexmeasures/data/schemas/sensors.py b/flexmeasures/data/schemas/sensors.py index fc510adf05..72694534a6 100644 --- a/flexmeasures/data/schemas/sensors.py +++ b/flexmeasures/data/schemas/sensors.py @@ -979,11 +979,7 @@ def event_resolution(self) -> timedelta: return self.sensor.event_resolution -class SensorReferenceSchema(Schema): - """Sensor reference with optional source filters.""" - - class Meta: - description = "Sensor reference from which to look up a variable quantity." +class SharedSensorReferenceSchema(Schema): sensor = SensorIdField( required=True, @@ -991,6 +987,20 @@ class Meta: description="ID of the sensor on which the data is recorded.", ), ) + + +class OutputSensorReferenceSchema(SharedSensorReferenceSchema): + """Sensor reference for recording generated data.""" + + ... + + +class SensorReferenceSchema(SharedSensorReferenceSchema): + """Sensor reference with optional source filters.""" + + class Meta: + description = "Sensor reference from which to look up a variable quantity." + source_types = fields.List( fields.String(), load_default=None, diff --git a/flexmeasures/data/schemas/tests/test_scheduling.py b/flexmeasures/data/schemas/tests/test_scheduling.py index 3d4450580e..aef5fbef9d 100644 --- a/flexmeasures/data/schemas/tests/test_scheduling.py +++ b/flexmeasures/data/schemas/tests/test_scheduling.py @@ -790,52 +790,6 @@ def test_flex_context_schema_rejects_filtered_aggregate_power( assert "cannot use source filters" in str(exc_info.value) -def test_storage_flex_model_schema_rejects_filtered_consumption( - setup_dummy_sensors, setup_sources, db -): - _, _, _, power_sensor = setup_dummy_sensors - seita_source = setup_sources["Seita"] - db.session.flush() - - for schema in [ - StorageFlexModelSchema(start=datetime(2026, 6, 1), sensor=None), - DBStorageFlexModelSchema(), - ]: - with pytest.raises(ValidationError) as exc_info: - schema.load( - { - "consumption": { - "sensor": power_sensor.id, - "sources": [seita_source.id], - } - } - ) - assert "cannot use source filters" in str(exc_info.value) - - -def test_storage_flex_model_schema_rejects_filtered_production( - setup_dummy_sensors, setup_sources, db -): - _, _, _, power_sensor = setup_dummy_sensors - seita_source = setup_sources["Seita"] - db.session.flush() - - for schema in [ - StorageFlexModelSchema(start=datetime(2026, 6, 1), sensor=None), - DBStorageFlexModelSchema(), - ]: - with pytest.raises(ValidationError) as exc_info: - schema.load( - { - "production": { - "sensor": power_sensor.id, - "sources": [seita_source.id], - } - } - ) - assert "cannot use source filters" in str(exc_info.value) - - @pytest.mark.parametrize( ["flex_model", "fails"], [ @@ -953,22 +907,231 @@ def test_flex_model_schemas( for schema, fail in zip(schemas, fails): if fail: - with pytest.raises(ValidationError) as e_info: + with pytest.raises(ValidationError) as e_info: # noqa: F841 schema.load(flex_model) - for field_name, expected_message in fail.items(): - assert field_name in e_info.value.messages - if field_name in ["soc-gain", "soc-usage"]: - for index, message_list in e_info.value.messages[ - field_name - ].items(): - assert message_list[0] == expected_message[index][0] - else: - # Check all messages for the given field for the expected message - assert any( - [ - expected_message in message - for message in e_info.value.messages[field_name] - ] - ) + + +@pytest.mark.parametrize( + ["flex_context", "fails"], + [ + # Test aggregate-consumption field with sensor reference + ( + {"aggregate-consumption": {"sensor": "consumption-price in SEK/MWh"}}, + False, + ), + # Test aggregate-production field with sensor reference + ( + {"aggregate-production": {"sensor": "production-price in SEK/MWh"}}, + False, + ), + # Test both aggregate fields together + ( + { + "aggregate-consumption": {"sensor": "consumption-price in SEK/MWh"}, + "aggregate-production": {"sensor": "production-price in SEK/MWh"}, + }, + False, + ), + # Test that relax_constraints defaults to False in FlexContextSchema + ( + {"site-power-capacity": "1 MVA"}, + False, + ), + # Test breach prices moved to SharedSchema + ( + { + "consumption-breach-price": "100 EUR/MW", + "production-breach-price": "100 EUR/MW", + }, + False, + ), + # Test soc breach prices moved to SharedSchema + ( + { + "soc-minima-breach-price": "1000 EUR/MWh", + "soc-maxima-breach-price": "1000 EUR/MWh", + }, + False, + ), + ], +) +def test_shared_schema_fields_in_flex_context( + db, app, setup_site_capacity_sensor, setup_price_sensors, flex_context, fails +): + """Test that SharedSchema fields are accessible in FlexContextSchema.""" + schema = FlexContextSchema() + + # Replace sensor name with sensor ID + sensors_to_pick_from = {**setup_site_capacity_sensor, **setup_price_sensors} + for field_name, field_value in flex_context.items(): + if isinstance(field_value, dict) and "sensor" in field_value: + sensor_name = field_value["sensor"] + if sensor_name in sensors_to_pick_from: + flex_context[field_name]["sensor"] = sensors_to_pick_from[ + sensor_name + ].id + + check_schema_loads_data(schema=schema, data=flex_context, fails=fails) + + +@pytest.mark.parametrize( + ["commodity_contexts", "fails"], + [ + # Test single commodity pass validation and defaults relax_constraints to True + ( + [ + { + "commodity": "electricity", + "site-power-capacity": "1 MVA", + } + ], + False, + ), + # Likewise for multiple commodities, relax_constraints should default to True for each + ( + [ + { + "commodity": "electricity", + "site-power-capacity": "1 MVA", + }, + { + "commodity": "heat", + "site-power-capacity": "500 kW", + }, + ], + False, + ), + # Test aggregate fields in commodity context pass validation + ( + [ + { + "commodity": "electricity", + "aggregate-consumption": {"sensor": "consumption-price in SEK/MWh"}, + "aggregate-production": {"sensor": "production-price in SEK/MWh"}, + } + ], + False, + ), + # Test breach prices in commodity context pass validation + ( + [ + { + "commodity": "electricity", + "consumption-breach-price": "100 EUR/MW", + "production-breach-price": "100 EUR/MW", + } + ], + False, + ), + ], +) +def test_commodity_flex_context_defaults( + db, app, setup_site_capacity_sensor, setup_price_sensors, commodity_contexts, fails +): + """Test that CommodityFlexContextSchema has correct defaults, especially relax_constraints=True.""" + from flexmeasures.data.schemas.scheduling import CommodityFlexContextSchema + + # Replace sensor name with sensor ID + sensors_to_pick_from = {**setup_site_capacity_sensor, **setup_price_sensors} + for context in commodity_contexts: + for field_name, field_value in context.items(): + if isinstance(field_value, dict) and "sensor" in field_value: + sensor_name = field_value["sensor"] + if sensor_name in sensors_to_pick_from: + context[field_name]["sensor"] = sensors_to_pick_from[sensor_name].id + + # Test loading each commodity context + schema = CommodityFlexContextSchema() + for context in commodity_contexts: + if fails: + with pytest.raises(ValidationError) as e_info: + loaded = schema.load(context) + print(f"Returned error message: {e_info.value.messages}") else: - schema.load(flex_model) + loaded = schema.load(context) + # Verify relax_constraints defaults to True in CommodityFlexContextSchema + assert loaded.get("relax_constraints", True) is True + + +@pytest.mark.parametrize( + ["flex_context_listing", "fails"], + [ + # Test flex-context listing with mixed currencies should fail + ( + { + "commodities": [ + { + "commodity": "electricity", + "consumption-price": "1 EUR/MWh", + }, + { + "commodity": "heat", + "consumption-price": "1 USD/MWh", + }, + ] + }, + { + "commodities": "all prices in the flex-context must share the same currency unit" + }, + ), + # Test flex-context listing with same currencies should pass + ( + { + "commodities": [ + { + "commodity": "electricity", + "consumption-price": "1 EUR/MWh", + }, + { + "commodity": "heat", + "consumption-price": "2 EUR/MWh", + }, + ] + }, + False, + ), + # Test flex-context listing with breach prices sharing currency + ( + { + "commodities": [ + { + "commodity": "electricity", + "consumption-breach-price": "100 EUR/MW", + "production-breach-price": "10 cEUR/kW", + } + ] + }, + False, + ), + # Test flex-context listing with mixed breach price currencies should fail + ( + { + "commodities": [ + { + "commodity": "electricity", + "consumption-breach-price": "100 EUR/MW", + }, + { + "commodity": "heat", + "consumption-breach-price": "100 USD/MW", + }, + ] + }, + { + "commodities": "all prices in the flex-context must share the same currency unit" + }, + ), + ], +) +def test_flex_context_listing_shared_currency( + db, + app, + setup_site_capacity_sensor, + setup_price_sensors, + flex_context_listing, + fails, +): + """Test that flex-context listings enforce shared currency across commodities.""" + schema = FlexContextSchema() + + check_schema_loads_data(schema=schema, data=flex_context_listing, fails=fails) diff --git a/flexmeasures/ui/static/openapi-specs.json b/flexmeasures/ui/static/openapi-specs.json index 62a2bc16d7..9a6c7d9647 100644 --- a/flexmeasures/ui/static/openapi-specs.json +++ b/flexmeasures/ui/static/openapi-specs.json @@ -4556,98 +4556,31 @@ ], "additionalProperties": false }, - "CommodityFlexContext": { + "OutputSensorReference": { + "type": "object", + "properties": { + "sensor": { + "type": "integer", + "description": "ID of the sensor on which the data is recorded." + } + }, + "required": [ + "sensor" + ], + "additionalProperties": false + }, + "FlexContextOpenAPISchema": { "type": "object", "properties": { "commodity": { "type": "string", "default": "electricity", - "description": "Commodity to which this part of the flex-context applies.\nDefaults to ``\"electricity\"``.\n", + "description": "Commodity to which this part of the flex-context applies.\nDefaults to \"electricity\".\n", "examples": [ "electricity", "gas" ] }, - "consumption-price": { - "description": "The commodity price (e.g. electricity price) applied to the site's aggregate consumption. Can be (a sensor recording) market prices, but also CO\u2082 intensity\u2014whatever fits your optimization problem. [#old_consumption_price_field]_", - "examples": [ - { - "sensor": 5 - }, - "0.29 EUR/kWh" - ] - }, - "production-price": { - "description": "The commodity price (e.g. electricity price) applied to the site's aggregate production. Can be (a sensor recording) market prices, but also CO\u2082 intensity\u2014whatever fits your optimization problem, as long as the unit matches the ``consumption-price`` unit. [#old_production_price_field]_", - "example": "0.12 EUR/kWh" - }, - "site-power-capacity": { - "description": "Maximum achievable power at the site's grid connection point, in either direction.\nBecomes a hard constraint in the optimization problem, which is especially suitable for physical limitations. [#asymmetric]_ [#minimum_capacity_overlap]_\n", - "example": "45kVA" - }, - "site-consumption-capacity": { - "description": "Maximum consumption power at the site's grid connection point.\nIf ``site-power-capacity`` is defined, the minimum between the ``site-power-capacity`` and ``site-consumption-capacity`` will be used. [#consumption]_\nIf a ``site-consumption-breach-price`` is defined, the ``site-consumption-capacity`` becomes a soft constraint in the optimization problem.\nOtherwise, it becomes a hard constraint. [#minimum_capacity_overlap]_\n", - "example": "45kW" - }, - "site-production-capacity": { - "description": "Maximum production power at the site's grid connection point.\nIf ``site-power-capacity`` is defined, the minimum between the ``site-power-capacity`` and ``site-production-capacity`` will be used. [#production]_\nIf a ``site-production-breach-price`` is defined, the ``site-production-capacity`` becomes a soft constraint in the optimization problem.\nOtherwise, it becomes a hard constraint. [#minimum_capacity_overlap]_\n", - "example": "0kW" - }, - "site-consumption-breach-price": { - "description": "This **penalty value** is used to discourage the violation of the ``site-consumption-capacity`` constraint in the flex-context.\nIt effectively treats the capacity as a **soft constraint**, allowing the scheduler to exceed it when necessary but with a high cost.\nThe scheduler will attempt to minimize this cost.\nIt must use the same currency as the other price settings and cannot be negative.\nThe field may define (a sensor recording) contractual penalties, or a theoretical penalty influencing how badly breaches should be avoided. [#penalty_field]_ [#breach_field]_\n", - "example": "1000 EUR/kW" - }, - "site-production-breach-price": { - "description": "This **penalty value** is used to discourage the violation of the ``site-production-capacity`` constraint in the flex-context.\nIt effectively treats the capacity as a **soft constraint**, allowing the scheduler to exceed it when necessary but with a high cost.\nThe scheduler will attempt to minimize this cost.\nIt must use the same currency as the other price settings and cannot be negative.\nThe field may define (a sensor recording) contractual penalties, or a theoretical penalty influencing how badly breaches should be avoided. [#penalty_field]_ [#breach_field]_\"\n", - "example": "1000 EUR/kW" - }, - "site-peak-consumption": { - "default": "0.0 MW", - "description": "The site's previously achieved achieved peak consumption.\nThis value forms the baseline for new peak charges, since any peaks up to this level represent sunk costs.\nDefaults to 0 kW.\n", - "example": { - "sensor": 7 - } - }, - "site-peak-consumption-price": { - "description": "Per-kW price applied to any consumption that exceeds the site's previously achieved peak consumption.\nThis price reflects the cost of increasing the site\u2019s peak further and is used by the scheduler to motivate peak shaving.\nIt must use the same currency as the other price settings and cannot be negative.\nFor large connections, this price is usually stated explicitly on the tariff sheets of their network operator. [#penalty_field]_\n", - "example": "260 EUR/MW" - }, - "site-peak-production": { - "default": "0.0 MW", - "description": "The site's previously achieved achieved peak production.\nThis value forms the baseline for new peak charges, since any peaks up to this level represent sunk costs.\nDefaults to 0 kW.\n", - "example": { - "sensor": 8 - } - }, - "site-peak-production-price": { - "description": "Per-kW price applied to any production that exceeds the site's previously achieved peak production.\nThis price reflects the cost of increasing the site\u2019s peak further and is used by the scheduler to motivate peak shaving.\nIt must use the same currency as the other price settings and cannot be negative.\nFor large connections, this price is usually stated explicitly on the tariff sheets of their network operator. [#penalty_field]_\n", - "example": "260 EUR/MW" - }, - "commitments": { - "description": "Prior commitments. Support for this field in the UI is still under further development, but you can find more information in :ref:`commitments`.", - "example": [], - "type": "array", - "items": { - "$ref": "#/components/schemas/Commitment" - } - }, - "inflexible-device-sensors": { - "type": "array", - "description": "Power sensors representing devices that are relevant, but not flexible in the timing of their demand/supply.\nFor example, a sensor recording rooftop solar power that is connected behind the main meter, and whose production falls under the same contract as the flexible device(s) being scheduled.\nTheir power demand cannot be adjusted but still matters for finding the best schedule for other devices.\nMust be a list of integers.\n", - "example": [ - 3, - 4 - ], - "items": { - "type": "integer" - } - } - }, - "additionalProperties": false - }, - "FlexContextOpenAPISchema": { - "type": "object", - "properties": { "consumption-price": { "description": "The commodity price (e.g. electricity price) applied to the site's aggregate consumption. Can be (a sensor recording) market prices, but also CO\u2082 intensity\u2014whatever fits your optimization problem.", "examples": [ @@ -4712,32 +4645,6 @@ "example": "260 EUR/MW", "$ref": "#/components/schemas/VariableQuantityOpenAPI" }, - "commitments": { - "description": "Prior commitments. Support for this field in the UI is still under further development, but you can find more information in the docs.", - "example": [], - "type": "array", - "items": { - "$ref": "#/components/schemas/Commitment" - } - }, - "inflexible-device-sensors": { - "type": "array", - "description": "Power sensors representing devices that are relevant, but not flexible in the timing of their demand/supply.\nFor example, a sensor recording rooftop solar power that is connected behind the main meter, and whose production falls under the same contract as the flexible device(s) being scheduled.\nTheir power demand cannot be adjusted but still matters for finding the best schedule for other devices.\nMust be a list of integers.\n", - "example": [ - 3, - 4 - ], - "items": { - "type": "integer" - } - }, - "commodities": { - "description": "For multi-commodity scheduling problems, the above fields can be set here per commodity.", - "type": "array", - "items": { - "$ref": "#/components/schemas/CommodityFlexContext" - } - }, "consumption-breach-price": { "description": "This penalty value is used to discourage the violation of the consumption-capacity constraint in the flex-model.\nIt effectively treats the capacity as a soft constraint, allowing the scheduler to exceed it when necessary but with a high cost.\nThe scheduler will attempt to minimize this cost.\nIt must use the same currency as the other price settings and cannot be negative.\n", "example": "10 EUR/kW", @@ -4760,7 +4667,7 @@ }, "relax-constraints": { "type": "boolean", - "default": false, + "default": true, "description": "If True (default is False), several constraints are relaxed by setting default breach prices within the optimization problem, leading to the default priority:\n\n1. Avoid breaching the site consumption/production capacity.\n2. Avoid not meeting SoC minima/maxima.\n3. Avoid breaching the desired device consumption/production capacity.\n\nWe recommend to set this field to True to enable the default prices and associated priorities as defined by FlexMeasures.\nFor tighter control over prices and priorities, the breach prices can also be set explicitly (the relevant fields have breach-price in their name).\n", "example": true }, @@ -4782,18 +4689,38 @@ "description": "If True, avoids breaching the site consumption/production capacity as a relaxed constraint.", "example": true }, - "consumption-price-sensor": { - "type": "integer" + "commitments": { + "description": "Prior commitments. Support for this field in the UI is still under further development, but you can find more information in the docs.", + "example": [], + "type": "array", + "items": { + "$ref": "#/components/schemas/Commitment" + } }, - "production-price-sensor": { - "type": "integer" + "inflexible-device-sensors": { + "type": "array", + "description": "Power sensors representing devices that are relevant, but not flexible in the timing of their demand/supply.\nFor example, a sensor recording rooftop solar power that is connected behind the main meter, and whose production falls under the same contract as the flexible device(s) being scheduled.\nTheir power demand cannot be adjusted but still matters for finding the best schedule for other devices.\nMust be a list of integers.\n", + "example": [ + 3, + 4 + ], + "items": { + "type": "integer" + } }, - "aggregate-power": { - "description": "Sensor used to record the aggregate power schedule of all flexible and inflexible devices involved when scheduling this asset.", + "aggregate-consumption": { + "description": "Sensor used to record the aggregate consumption schedule of all flexible and inflexible devices involved when scheduling this asset.\n\nThe sign convention is determined by the key name, and is stored on the sensor itself using the consumption_is_positive attribute.\n\nDepending on which output sensors are defined:\n\n- Only aggregate-consumption defined: the full aggregate power schedule is stored on this sensor using the\n consumption-positive sign convention (consumption positive, production negative).\n- Only aggregate-production defined: the full aggregate power schedule is stored on the aggregate-production sensor\n with the production-positive convention (production positive, consumption negative).\n- Both defined: only the non-negative part of the aggregate schedule is stored on this sensor (zero for\n time steps with net production), and only the non-positive part (sign-flipped) is stored on the\n aggregate-production sensor.\n", "example": { - "sensor": 9 + "sensor": 10 }, - "$ref": "#/components/schemas/SensorReference" + "$ref": "#/components/schemas/OutputSensorReference" + }, + "aggregate-production": { + "description": "Sensor used to record the aggregate production schedule of all flexible and inflexible devices involved when scheduling this asset.\n\nThe sign convention is determined by the key name, and is stored on the sensor itself using the consumption_is_positive attribute.\n\nSee the aggregate-consumption field for the full description of the split logic when both sensors are defined.\n", + "example": { + "sensor": 11 + }, + "$ref": "#/components/schemas/OutputSensorReference" } }, "additionalProperties": false @@ -6176,14 +6103,14 @@ "example": { "sensor": 14 }, - "$ref": "#/components/schemas/SensorReference" + "$ref": "#/components/schemas/OutputSensorReference" }, "production": { - "description": "Sensor used to record the scheduled power as seen from a production perspective.\n\nThe sign convention is determined by the key name, and is stored on the sensor itself using the consumption_is_positive attribute.\n\nSee consumption for the full description of the split logic when both sensors are defined.\n", + "description": "Sensor used to record the scheduled power as seen from a production perspective.\n\nThe sign convention is determined by the key name, and is stored on the sensor itself using the consumption_is_positive attribute.\n\nSee the consumption field for the full description of the split logic when both sensors are defined.\n", "example": { "sensor": 15 }, - "$ref": "#/components/schemas/SensorReference" + "$ref": "#/components/schemas/OutputSensorReference" }, "soc-at-start": { "type": "string", @@ -6371,9 +6298,12 @@ } }, "flex-context": { - "default": {}, - "description": "The flex-context is validated according to the scheduler's `FlexContextSchema`.", - "$ref": "#/components/schemas/FlexContextOpenAPISchema" + "type": "array", + "default": [], + "description": "Flex-context per commodity. The flex-context is validated according to the scheduler's `FlexContextSchema`.", + "items": { + "$ref": "#/components/schemas/FlexContextOpenAPISchema" + } }, "sequential": { "type": "boolean", diff --git a/flexmeasures/ui/templates/assets/asset_context.html b/flexmeasures/ui/templates/assets/asset_context.html index 5c84a5a607..09a1348dfb 100644 --- a/flexmeasures/ui/templates/assets/asset_context.html +++ b/flexmeasures/ui/templates/assets/asset_context.html @@ -380,7 +380,7 @@
Edit {{ asset.name }}'s flex-context
setTimeout(() => { const card = document.getElementById(`${fieldName}-control`); - const isOnlySensorField = (fieldName === "inflexible-device-sensors" || fieldName === "consumption-price" || fieldName === "production-price" || fieldName === "aggregate-power"); + const isOnlySensorField = (fieldName === "inflexible-device-sensors" || fieldName === "consumption-price" || fieldName === "production-price" || fieldName === "aggregate-power" || fieldName === "aggregate-consumption" || fieldName === "aggregate-production"); card.classList.add('border-on-click'); // Add border to the clicked card flexOptionsContainer.appendChild(renderFlexInputOptions(fieldName, isOnlySensorField)); handleFlexSelectChange(fieldName); @@ -608,7 +608,7 @@
Edit {{ asset.name }}'s flex-context
document.querySelectorAll(".card-highlight").forEach(el => el.classList.remove("border-on-click")); // Remove border from all cards card.classList.add("border-on-click"); // Add border to the clicked card handleFlexSelectChange(fieldName); - const isOnlySensorField = (fieldName === "inflexible-device-sensors" || fieldName === "consumption-price" || fieldName === "production-price" || fieldName === "aggregate-power"); + const isOnlySensorField = (fieldName === "inflexible-device-sensors" || fieldName === "consumption-price" || fieldName === "production-price" || fieldName === "aggregate-power" || fieldName === "aggregate-consumption" || fieldName === "aggregate-production"); flexOptionsContainer.appendChild(renderFlexInputOptions(fieldName, (isOnlySensorField))); setActiveCard(card); // Store active card in local storage @@ -720,7 +720,7 @@
Edit {{ asset.name }}'s flex-context
if (storedActiveCard && activeCard()) { const flexId = (activeCard() ? activeCard().id : null).slice(0, -8); if (assetFlexContext[storedActiveCard]) { - const isOnlySensorField = (flexId === "inflexible-device-sensors" || flexId === "consumption-price" || flexId === "production-price" || flexId === "aggregate-power"); + const isOnlySensorField = (flexId === "inflexible-device-sensors" || flexId === "consumption-price" || flexId === "production-price" || flexId === "aggregate-power" || flexId === "aggregate-consumption" || flexId === "aggregate-production"); setTimeout(() => { flexOptionsContainer.innerHTML = ""; flexOptionsContainer.appendChild(renderFlexInputOptions(flexId, isOnlySensorField)); diff --git a/flexmeasures/ui/tests/test_utils.py b/flexmeasures/ui/tests/test_utils.py index 4925ed44a2..eff2114fc6 100644 --- a/flexmeasures/ui/tests/test_utils.py +++ b/flexmeasures/ui/tests/test_utils.py @@ -92,7 +92,10 @@ def test_ui_flexcontext_schema(): assert ( schema_keys == ui_flexcontext_schema_fields - ), "If this test fails, you may have added a new flex-context field, but forgot about UI support." + ), "If this fails, you may have added a new flex-context field, but forgot about UI support." + assert ( + schema_keys - set(exclude_fields) == schema_keys + ), "If this fails, you may have added UI support for a new flex-context field, but forgot to remove it from exclude_fields." def test_ui_flexmodel_schema(): diff --git a/flexmeasures/utils/coding_utils.py b/flexmeasures/utils/coding_utils.py index 1ed43ce1f2..894846aa10 100644 --- a/flexmeasures/utils/coding_utils.py +++ b/flexmeasures/utils/coding_utils.py @@ -2,6 +2,7 @@ from __future__ import annotations +from typing import Any import functools import time import inspect @@ -11,6 +12,34 @@ from flask import current_app +def merge_or_append( + item: dict[str, Any], + items: list[dict[str, Any]], + match_key: str, + match_value: str | None = None, +) -> None: + """Merge `item` into the first dictionary in `items` with the same value for `key`, preserving its position in the sequence. + + Values from `item` take precedence when keys overlap. If no matching + dictionary is found, `item` is appended to the end of `items`. + + :param item: The dictionary to merge or append. + :param items: A mutable sequence of dictionaries to update. + :param match_key: The dictionary key used to determine whether two items match. + :param match_value: The value used to determine whether two items match. + + :returns: None. The `items` sequence is modified in place. + """ + match_value = item.get(match_key) or match_value + + for i, existing in enumerate(items): + if existing.get(match_key) == match_value: + items[i] = existing | item + return + + items.append(item) + + def delete_key_recursive(value, key): """Delete key in a multilevel dictionary""" if isinstance(value, dict): diff --git a/tests/documentation/test_schemas.py b/tests/documentation/test_schemas.py index 0a85803103..fab2946647 100644 --- a/tests/documentation/test_schemas.py +++ b/tests/documentation/test_schemas.py @@ -13,6 +13,8 @@ "RELAX_CAPACITY_CONSTRAINTS", "RELAX_SITE_CAPACITY_CONSTRAINTS", "RELAX_SOC_CONSTRAINTS", + "COMMODITY_FLEX_CONTEXT", # Documented as "commodity" in flex-context section + "COMMODITY_FLEX_MODEL", # Documented as "commodity" in flex-model section }