flexmeasures.data.models.planning.linear_optimization

Functions

flexmeasures.data.models.planning.linear_optimization.device_scheduler(device_constraints: list[DataFrame], ems_constraints: DataFrame | list[DataFrame], commitment_quantities: list[Series] | None = None, commitment_downwards_deviation_price: list[Series] | list[float] | None = None, commitment_upwards_deviation_price: list[Series] | list[float] | None = None, commitments: list[DataFrame] | list[Commitment] | None = None, initial_stock: float | list[float] = 0, stock_groups: dict[int, list[int]] | None = None, ems_constraint_groups: list[list[int]] | None = None, device_power_bands: list[list[tuple[float, float]] | None] | None = None, device_mode_commodity_ranges: list[list[dict[int, tuple[float, float]]] | None] | None = None) → tuple[list[Series], float, SolverResults, ConcreteModel]

This generic device scheduler is able to handle an EMS with multiple devices, with various types of constraints on the EMS level and on the device level, and with multiple market commitments on the EMS level. A typical example is a house with many devices. The commitments are assumed to be with regard to the flow of energy to the device (positive for consumption, negative for production). The solver minimises the costs of deviating from the commitments.

Parameters:

  • device_constraints – Device constraints are on a device level. Handled constraints (listed by column name): max: maximum stock assuming an initial stock of zero (e.g. in MWh or boxes) min: minimum stock assuming an initial stock of zero equal: exact amount of stock (we do this by clamping min and max) efficiency: amount of stock left at the next datetime (the rest is lost) derivative max: maximum flow (e.g. in MW or boxes/h) derivative min: minimum flow derivative equals: exact amount of flow (we do this by clamping derivative min and derivative max) derivative down efficiency: conversion efficiency of flow out of a device (flow out : stock decrease) derivative up efficiency: conversion efficiency of flow into a device (stock increase : flow in) stock delta: predefined stock delta to apply to the storage device. Positive values cause an increase and negative values a decrease

  • ems_constraints –

    EMS constraints are on an EMS level. Handled constraints (listed by column name):

    derivative max: maximum flow derivative min: minimum flow

    May be a single DataFrame (the constraint is applied to the summed flow of all devices), or a list of DataFrames (one per device group). In the latter case, ems_constraint_groups lists the device indices each DataFrame applies to. The StorageScheduler uses one device group per commodity, so each commodity gets its own EMS-level capacity constraint.

  • ems_constraint_groups – For each EMS constraint DataFrame, the list of device indices it applies to. When omitted, each EMS constraint is applied to the summed flow of all devices (legacy behaviour). A device may appear in more than one group.

  • commitments – Commitments are on an EMS level by default. Handled parameters (listed by column name): quantity: for example, 5.5 downwards deviation price: 10.1 upwards deviation price: 10.2 group: 1 (defaults to the enumerate time step j) device: 0 (corresponds to device d; if not set, commitment is on an EMS level)

  • initial_stock – initial stock for each device. Use a list with the same number of devices as device_constraints, or use a single value to set the initial stock to be the same for all devices.

  • device_power_bands – optional per-device list of signed power bands (min, max), in flow units (e.g. MW, positive for consumption). A device with bands must operate within one of its bands at every time step (see S2 operation modes); this introduces binary variables (one per device per band per time step). Use None (per device or for the whole argument) for devices without band restrictions.

  • device_mode_commodity_ranges – optional per-device generalisation of device_power_bands to multiple commodities (S2 FRBC.OperationModeElement.power_ranges). For a device d that carries operation modes, this is a list parallel to device_power_bands[d] (one entry per mode/band). Each entry maps other device indices (the coupled commodities, e.g. the fuel and heat flows of a cogeneration unit) to a signed pair (c0, c1) in flow units, giving that commodity’s flow at the mode’s two factor extremes: c0 at factor 0 (the banded device’s own band minimum) and c1 at factor 1 (its band maximum). Sign is resolved upstream from the mode’s consumption-range/production-range keys, so these values are already signed and need not be ordered. When mode b is active, a single operation-mode factor lambda in [0, 1] (shared across all commodities of that mode) sets the banded device’s own power to pmin_b + lambda * (pmax_b - pmin_b) and each coupled commodity’s power to c0 + lambda * (c1 - c0). This ties the commodities affinely: the factor-0 endpoints are the per-commodity fixed no-load flows (gated by the mode’s binary), and the shared factor makes the marginal (proportional) part move in lockstep. Use None (per device or for the whole argument) for single-commodity operation modes, which behave exactly as before.

Potentially deprecated arguments:
commitment_quantities: amounts of flow specified in commitments (both previously ordered and newly requested)

  • e.g. in MW or boxes/h

commitment_downwards_deviation_price: penalty for downwards deviations of the flow

  • e.g. in EUR/MW or EUR/(boxes/h)

  • either a single value (same value for each flow value) or a Series (different value for each flow value)

commitment_upwards_deviation_price: penalty for upwards deviations of the flow

Separate costs for each commitment are stored in a dictionary under model.commitment_costs (indexed by commitment).

All Series and DataFrames should have the same resolution.

For now, we pass in the various constraints and prices as separate variables, from which we make a MultiIndex DataFrame. Later we could pass in a MultiIndex DataFrame directly.

flexmeasures.data.models.planning.linear_optimization.validate_highs_options(options: dict) → None

Raise if HiGHS would refuse any of these options.

Pyomo’s appsi_highs interface applies solver options without checking HiGHS’ return status, so an unknown name, an invalid value, or a feature missing from the installed HiGHS build is otherwise ignored without a word. That silently turns a mis-typed option into a no-op, and a benchmark of it into a false negative. Probing a throwaway Highs instance surfaces the rejection instead.