Internal API

Default DeviceModel attributes shared by every formulation that bridges a bilinear/quadratic term to IOM's approximation API (HydroTurbineBilinearDispatch, QuadraticLossConverter, HVDCTwoTerminalVSC). This is the single source of both the default values and the per-attribute documentation; the formulations splice it into their get_default_attributes (adding only formulation-specific extras).

• "bilinear_approximation" (default "none"): the approximation scheme for the bilinear product. "none" keeps it exact (an NLP needing a nonlinear solver such as Ipopt); "bin2", "hybs", "nmdt", "dnmdt" are tolerance-driven linearizations (mixed-integer linear).
• "bilinear_quadratic_method" (default "solver_sos2"): the inner quadratic PWL method used by the "bin2" and "hybs" schemes. Supported: "solver_sos2", "manual_sos2", "sawtooth"; "bin2" also accepts "nmdt" and "dnmdt".
• "bilinear_relative_tolerance" (default 0.05): approximation gap as a fraction of the product magnitude — the default sizing knob.
• "bilinear_absolute_tolerance" (default nothing): approximation gap in absolute (product) units.

Exactly one of the two tolerances must be set (see _resolve_tolerance); the set value must be finite and > 0.

Attribute key indicating if transformer controls are enabled. Available on any DeviceModel where _control_supported is true.

These types share constructors.

If the name of an extraneous file that appears in simulation outputs matches one of these regexes, it is safe to ignore

Marks a row the bundle writer derived from a model's realized parameter values. One marker only: IS resolves a by-name read as a subset match on features, so a rebuild's plain get_time_series(Deterministic, component, name) still finds the row, and the partition merge can list every input row without knowing the parameter keys. No parameter/model feature here — two parameters reading one series would make two rows and an ambiguous read.

Branch DeviceModel attribute. When true, the end buses of every device in the model are kept out of the network reduction, so each device keeps its own arc. Defaults to false.

DeviceModel attribute key selecting which PowerNetworkMatrices function aggregates the individual circuit ratings of a PNM.BranchesParallel into a single maximum flow limit. Valid values: "single_element_contingency" (default; N-1, post-trip surviving capacity), "sum_of_max" (plain Σ Sᵢ), "impedance_averaged" (susceptance-weighted average). PNM.MixedBranchesParallel groups always use sum_of_max.

Feature key carrying the encoded IOM.ParameterKey a parameter row belongs to.

The owner id every parameter array row is written under. No component ever holds this id, so a parameter row never shows up in a restored component's own list_time_series_metadata.

Upward reserve products a device can supply: up-direction reserves plus OfflineReserve (non-spinning is upward-only). Excludes GroupReserve - devices serve a group's members, never the group itself.

Abstract type for dynamic ratings of AC branches

Abstract type for hybrid reserve variables (both PCC-boundary and subcomponent).

Abstract type for per-subcomponent reserve allocations inside a hybrid system that do not have a Discharge/Charge axis (thermal and renewable subcomponents).

Abstract type for variables representing flows internal to a PSY.HybridSystem.

Abstract supertype for two-terminal voltage-source converter (VSC) HVDC formulations. Models per-terminal converters with quadratic / two-term losses ($a I^2 + b |I| + c$), a shared signed cable current, an explicit DC-side cable resistance ($v_f - v_t = (1/g) \cdot I$), and (on AC networks) independent reactive-power control bounded by per-terminal PQ capability.

Formulation builds under every network model. Default.

Formulation needs a full AC network; the linear-programming AC cold-start approximation (LPACC, LPACCNetworkModel) linearizes the reactive layer and cannot build it.

Struct to create the constraint to balance power across specified areas. For more information check Network Formulations.

The specified constraint is generally formulated as:

\[\sum_{c \in \text{components}_a} p_t^c = 0, \quad \forall a\in \{1,\dots, A\}, t \in \{1, \dots, T\}\]

Auxiliary Variable for line power flow outputs from power flow evaluation

Trait axis describing the flow-slack machinery a branch formulation builds under a given network formulation. Concrete specs carry the container metas the machinery uses, so consumers (validation gate, objective pricing, tests) read the same declaration the constructors build from. Declared per (formulation, network) pair via slack_spec.

Defining constraint for the AC apparent current of a converter under an AC network model: $I_{ac}^2 \, V_{ac}^2 = p^2 + q^2$, where $V_{ac}^2$ is the AC bus voltage magnitude squared ($v_m^2$ under ACP, $v_r^2 + v_i^2$ under ACR/IVR), p the terminal/converter AC active flow and q the reactive injection. One entry per terminal/converter per time step.

Struct to create the constraints that decide the balance of AC and DC power of the converter.

The specified constraints are formulated as:

\[\begin{align*} & p_ac = p_dc - loss_t \quad \forall t \in \{1,\dots, T\} \\ & loss_t = a i_c^2 + b i_c + c \\ \end{align*}\]

Apparent-power capability disk for an InterconnectingConverter under an AC network model: $p^2 + q^2 \le \text{rating}^2$, with p the converter ActivePowerVariable and q the converter ReactivePowerVariable. One entry per converter per time step.

Parameter to define cost function coefficient

Struct to create the constraints that set the absolute value for the current to use in losses through a lossy Interconnecting Power Converter. The specified constraint is formulated as:

\[\begin{align*} & i_c^{dc} = i_c^+ - i_c^-, \quad \forall t \in \{1,\dots, T\} \\ & i_c^+ \le I_{max} \cdot \nu_c, \quad \forall t \in \{1,\dots, T\} \\ & i_c^+ \le I_{max} \cdot (1 - \nu_c), \quad \forall t \in \{1,\dots, T\} \end{align*}\]

Struct to create the constraints that set the current flowing through a DC line.

\[\begin{align*} & i_l^{dc} = \frac{1}{r_l} (v_{from,l} - v_{to,l}), \quad \forall t \in \{1,\dots, T\} \end{align*}\]

Struct to define the creation of HVDC DC Line Current Flow

Docs abbreviation: $\i_{d}$

Auxiliary Variable of DC Current Variables for DC Lines formulations Docs abbreviation: $p_l^{loss}$

DCP: a Ybus, plus a MODF derived from that same Ybus when the template is security constrained.

Expression for PowerSystems.System that keep track of the energy balance for the system in medium term planning

Struct to create the constraint that sets the reactive power to the power factor in the RenewableConstantPowerFactor formulation for renewable units.

For more information check RenewableGen Formulations.

The specified constraint is formulated as:

\[q_t^\text{re} = \text{pf} \cdot p_t^\text{re}, \quad \forall t \in \{1,\dots, T\}\]

One metaed upper/lower slack pair per flow/current definition equality row, one pair per meta (StaticBranchBounds on the AC natives: the Ohm's-law rows; IVR adds the terminal current-definition rows).

Parameter to define Flow From_To limit time series

Struct to dispatch the creation of HVDC Received Flow at From Bus Variables for HVDCTwoTerminalPiecewiseLoss. Injection convention: enters the from-bus ActivePowerBalance with +1.0 (an injection at its own terminal).

Docs abbreviation: $x$

Struct to dispatch the creation of HVDC Received Flow at To Bus Variables for HVDCTwoTerminalPiecewiseLoss. Injection convention: enters the to-bus ActivePowerBalance with +1.0 (an injection at its own terminal).

Docs abbreviation: $y$

Cable Ohm's law for a two-terminal HVDC link with explicit DC resistance:

\[v_f - v_t = (1/g) \cdot I\]

Struct to create the constraint that calculates the AC Current flowing into the AC side of the inverter.

\[i_ ext{ac}^i = \sqrt{6} \frac{N^i}{\pi}I_d\]

Struct to define the creation of HVDC AC Line Current flowing into the AC side of Inverter

Docs abbreviation: $\i_{ac}^i$

Inverter AC-side active power delivery of a TwoTerminalLCCLine under HVDCTwoTerminalLCC, in p.u. (system base). Positive when the line transfers power from -> to; enters the to-bus ActivePowerBalance with +1.0 (an injection).

Struct to create the constraint that calculates the Inverter DC line voltage.

\[v_d^i = \frac{3}{\pi}N^i \left( \sqrt{2}rac{a^i v_\text{ac}^i}{t^i}\cos{\gamma^i}-X^i I_d \right)\]

Struct to define the creation of HVDC DC Line Voltage at Inverter Side

Docs abbreviation: $\v_{d}^i$

Struct to define the creation of HVDC Inverter Extinction Angle Variable

Docs abbreviation: $\gamma^i$

Struct to create the constraint that calculates the Inverter Overlap Angle.

\[\mu^i = \arccos \left( \cos\gamma^i - \frac{\sqrt{2} I_d X^i t^r}{a^i v_\text{ac}^i} \right) - \gamma^i\]

Struct to define the creation of HVDC Inverter Overlap Angle Variable

Docs abbreviation: $\mu^i$

Struct to create the constraint that calculates the AC Power injection at the AC side of the inverter.

\[\begin{align*} p_\text{ac}^i = \sqrt{3} i_\text{ac}^i \frac{a^i v_\text{ac}^i}{t^i}\cos{\phi^i} \\ q_\text{ac}^i = \sqrt{3} i_\text{ac}^i \frac{a^i v_\text{ac}^i}{t^i}\sin{\phi^i} \\ \end{align*}\]

Struct to create the constraint that calculates the Inverter Power Factor Angle.

\[\phi^i = \arctan \left( \frac{2\mu^i + \sin(2\gamma^i) - \sin(2(\mu^i + \gamma^i))}{\cos(2\gamma^i) - \cos(2(\mu^i + \gamma^i))} \right)\]

Struct to define the creation of HVDC Inverter Power Factor Angle Variable

Docs abbreviation: $\phi^i$

Inverter AC-side reactive power consumption of a TwoTerminalLCCLine under HVDCTwoTerminalLCC, in p.u. (system base). Consumed at the to bus (-1.0 in ReactivePowerBalance).

Struct to define the creation of HVDC Tap Setting at Inverter Transformer

Docs abbreviation: $\t^i$

Struct to dispatch the creation of HVDC Piecewise Binary Loss Variables

Docs abbreviation: $z$

Struct to dispatch the creation of HVDC Piecewise Loss Variables

Docs abbreviation: $h$ or $w$

Struct to create the constraints that set the power balance across a lossy HVDC two-terminal line.

For more information check Branch Formulations.

The specified constraints are formulated as:

\[\begin{align*} & f_t^\text{to-from} - f_t^\text{from-to} \le L_1 \cdot f_t^\text{to-from} - L_0,\quad \forall t \in \{1,\dots, T\} \\ & f_t^\text{from-to} - f_t^\text{to-from} \ge L_1 \cdot f_t^\text{from-to} + L_0,\quad \forall t \in \{1,\dots, T\} \\ & f_t^\text{from-to} - f_t^\text{to-from} \ge - M^\text{big} (1 - u^\text{dir}_t),\quad \forall t \in \{1,\dots, T\} \\ & f_t^\text{to-from} - f_t^\text{from-to} \ge - M^\text{big} u^\text{dir}_t,\quad \forall t \in \{1,\dots, T\} \\ \end{align*}\]

Struct to create the constraint that calculates the AC Current flowing into the AC side of the rectifier.

\[i_ ext{ac}^r = \sqrt{6} \frac{N^r}{\pi}I_d\]

Struct to define the creation of HVDC AC Line Current flowing into the AC side of Rectifier

Docs abbreviation: $\i_{ac}^r$

Rectifier AC-side active power draw of a TwoTerminalLCCLine under HVDCTwoTerminalLCC, in p.u. (system base). Positive when the line transfers power from -> to; enters the from-bus ActivePowerBalance with -1.0 (a withdrawal).

Struct to create the constraint that calculates the Rectifier DC line voltage.

\[v_d^r = \frac{3}{\pi}N^r \left( \sqrt{2}rac{a^r v_\text{ac}^r}{t^r}\cos{\alpha^r}-X^r I_d \right)\]

Struct to define the creation of HVDC DC Line Voltage at Rectifier Side

Docs abbreviation: $\v_{d}^r$

Struct to define the creation of HVDC Rectifier Delay Angle Variable

Docs abbreviation: $\alpha^r$

Struct to create the constraint that calculates the Rectifier Overlap Angle.

\[\mu^r = \arccos \left( \cos\alpha^r - \frac{\sqrt{2} I_d X^r t^r}{a^r v_\text{ac}^r} \right) - \alpha^r\]

Struct to define the creation of HVDC Rectifier Overlap Angle Variable

Docs abbreviation: $\mu^r$

Struct to create the constraint that calculates the AC Power injection at the AC side of the rectifier.

\[\begin{align*} p_\text{ac}^r = \sqrt{3} i_\text{ac}^r \frac{a^r v_\text{ac}^r}{t^r}\cos{\phi^r} \\ q_\text{ac}^r = \sqrt{3} i_\text{ac}^r \frac{a^r v_\text{ac}^r}{t^r}\sin{\phi^r} \\ \end{align*}\]

Struct to create the constraint that calculates the Rectifier Power Factor Angle.

\[\phi^r = \arctan \left( \frac{2\mu^r + \sin(2\alpha^r) - \sin(2(\mu^r + \alpha^r))}{\cos(2lpha^r) - \cos(2(\mu^r + \alpha^r))} \right)\]

Struct to define the creation of HVDC Rectifier Power Factor Angle Variable

Docs abbreviation: $\phi^r$

Rectifier AC-side reactive power consumption of a TwoTerminalLCCLine under HVDCTwoTerminalLCC, in p.u. (system base). Consumed at the from bus (-1.0 in ReactivePowerBalance).

Struct to define the creation of HVDC Tap Setting at Rectifier Transformer

Docs abbreviation: $\t^r$

Struct to create the constraint that links the AC and DC side of the network.

\[v_d^i = v_d^r - R_d I_d\]

Apparent-power limit at each terminal of a two-terminal VSC HVDC (HVDCTwoTerminalVSC), added only on AC networks. Enforces $|S_k| \le S_k^{\max}$ for $k \in \{f, t\}$ via one of two shapes, selected by the "bilinear_approximation" attribute:

• "none" (exact, NLP): exact disk $p_k^2 + q_k^2 \le (S_k^{\max})^2$.
• any linearizing scheme: linear outer-approximation. The axis-aligned box $|p_k|, |q_k| \le S_k^{\max}$ is added unconditionally; the four diagonal half-planes $|p_k| \pm q_k \le S_k^{\max}\sqrt{2}$ are added when the device-model attribute use_octagon (default true) is on, in which case the intersection is a regular octagon circumscribing the disk (loose by at most ≈8.2% in area).

Per-terminal converter power-balance constraint for two-terminal VSC HVDC:

\[\begin{aligned} p_{ft} &= v_f \cdot I + (a_f I^2 + b_f |I| + c_f) \\ p_{tf} &= -v_t \cdot I + (a_t I^2 + b_t |I| + c_t) \end{aligned}\]

Hybrid-boundary aggregation of reserve quantities offered through the discharge (out) and charge (in) sides of a PSY.HybridSystem.

Reserve quantity offered to the grid through one side of a hybrid PCC. Parametric on ReserveSide.

Status link between a hybrid PCC active-power variable and the reservation variable. Parametric on ReserveSide.

Charge- or discharge-side power limit for the hybrid storage subcomponent including reserve carve-outs. Parametric on ReserveSide.

Mutually-exclusive charge/discharge limit for the hybrid storage subcomponent (no-reserves case). Parametric on ReserveSide.

Active power on the storage subcomponent of a hybrid system. Parametric on ReserveSide.

Reserve allocated to one side of a hybrid system's storage subcomponent. Parametric on ReserveSide.

Bound between thermal subcomponent power and its commitment status (no-reserves case). Parametric on BoundDirection (from IOM).

Struct to model turbine outflow limits

For more information check HydroPowerSimulations Formulations.

The specified constraint is formulated as:

\[\ p_{t} = \Delta t (f^{Tu}_{t-1}(0.5 K_1 (v_{t} + v_{t-1}) + K_2))\]

What one time-series parameter needs to come back as component series: the series name and type the model read, and each parameter label's owner (id, type name). Labels that are not components of the System (network-reduction aggregates) are listed in unresolved; their values stay readable through the parameter rows under the synthetic owner.

Reservoir level target read from the system state

Parameter to define Max Flow limit for interface time series

Parameter to define Min Flow limit for interface time series

Equality-constrains a branch's flow according to its network model. Under StaticBranchBounds flow is stored as a variable, for use in feed-forwards; under StaticBranch it is an expression (BThetaBranchFlow on DCP, PTDFBranchFlow on PTDF) and no such variable is created. For more information check Branch Formulations.

The specified constraint depends on the network model chosen. The most common application is the StaticBranch in a PTDF Network Model:

\[f_t = \sum_{i=1}^N \text{PTDF}_{i,b} \cdot \text{Bal}_{i,t}, \quad \forall t \in \{1,\dots, T\}\]

Trait axis describing which network models a device formulation has a construct_device! path for. The set of network models a formulation builds under cuts across the formulation type hierarchy, so it cannot be expressed as a supertype. Declare one network_support method per formulation; downstream packages extend the gate the same way, which a Union alias could not allow.

The pair builds no flow-slack machinery; use_slacks = true is rejected at validation.

Struct to create the constraint to balance reactive power in nodal formulation. For more information check Network Formulations.

The specified constraint depends on the network model chosen.

Offline-capability band row for commitment formulations whose offline_reserve_in_range_ub trait is false: their commitment-gated range expression stays p + online, and this row adds the offline awards back against the formulation's gated capacity when committed, or the step's available max when not:

p + online + offline <= ts_t - (q_limit - gated) * u

ts_t is mult * ActivePowerTimeSeriesParameter when the DeviceModel maps that series and the device has it, and the static q_limit = pmax otherwise. gated is the formulation's own commitment-gated max (the same value the semicontinuous range row uses): for standard UC, gated = pmax, so the RHS is ts_t regardless of u; for compact UC, gated = pmax - pmin, so the RHS becomes ts_t - pmin * u.

Committed: offline competes with the online products for the gated band. Off: the semi-continuous range row zeroes p and the online awards, leaving offline <= ts_t. Single award variable per (device, service): the device's merged offer curve prices both provision states (documented approximation). With "offline_only" = true on the OfflineReserve ServiceModel, offline awards are forbidden while committed instead (OfflineReserveOffStateConstraint). "exclude_shutdown_step" adds OfflineReserveShutdownConstraint.

HydroCommitmentRunOfRiver uses the hour's limit in both states, p + online + offline <= ts_t, from its ActivePowerTimeSeriesParameter (static pmax for a unit without that series).

Offline awards of services whose ServiceModel sets "offline_only" = true need the unit off: sum(those awards) <= q_limit * (1 - u). A must-run device has no u (always committed), so its row fixes those awards to 0 outright. Scope: thermal unit commitment and HydroCommitmentRunOfRiver; other formulations book OfflineReserve awards against their headroom and are not restricted.

Offline awards of services whose ServiceModel sets "exclude_shutdown_step" = true are forbidden in the time step a unit goes off: sum(those awards) <= q_limit * (1 - u_{t-1} + u_t), with u_0 from the DeviceStatus initial condition (the initialization solve's commitment when the model initializes, the PSY status otherwise). The right-hand side is 0 only when u_{t-1} = 1 and u_t = 0. Built for thermal unit commitment (a must-run device never goes off and gets no row) and HydroCommitmentRunOfRiver, whose constructor adds the DeviceStatus initial condition only under this attribute. Rows are keyed (device, t).

Struct to create the constraint to limit active power output expressions. For more information check Device Formulations.

The specified constraint depends on the UpperBound and LowerBound expressions, but in its most basic formulation is of the form:

\[P^\text{min} \le p_t^\text{out} \le P^\text{max}, \quad \forall t \in \{1,\dots,T\}\]

PTDF families: a PTDF, plus an optional MODF, both wrapping one factorization core.

The InfraStore-backed store for optimization parameters.

Parameters are written here rather than into an outputs dataset so the bundle carries a real InfraStore store. The System document's association rows are exported from this same store, which is what makes every uri resolve on read — InfraStore refuses a catalog row naming an array it does not hold.

This is the only place in PowerOperationsModels or PowerSimulations that knows InfraStore exists.

ParameterTimeSeriesStore(

) -> PowerOperationsModels.ParameterTimeSeriesStore

A fresh, writable, in-memory parameter store.

Struct to create the constraint to participation assignments limits in the active power reserves. For more information check Service Formulations.

The constraint is as follows:

\[r_{d,t} \le \text{Req} \cdot \text{PF} ,\quad \forall d\in \mathcal{D}_s, \forall t\in \{1,\dots, T\} \quad \text{(static requirement)} \\ r_{d,t} \le \text{RequirementTimeSeriesParameter}_{t} \cdot \text{PF}\quad \forall d\in \mathcal{D}_s, \forall t\in \{1,\dots, T\}, \quad \text{(time-varying requirement)}\]

Block-offer delta variable for a per-device ancillary-service (reserve) OFFER. Sparse, keyed (service_name, device_name, segment, time) - the 4D (service, device, segment, time) cost structure on top of the 3D (service, device, time) reserve award ActivePowerReserveVariable.

Struct to create the PiecewiseLinearUpperBoundConstraint associated with a specified variable.

See Piecewise linear cost functions for more information.

Auxiliary Variables that are calculated using a PowerFlowEvaluationModel

Auxiliary Variable for the line active flow in the from -> to direction from power flow evaluation

Auxiliary Variable for the active power loss on a line from AC power flow evaluation.

Auxiliary Variable for the line active flow in the to -> from direction from power flow evaluation

Auxiliary Variable for the line reactive flow in the from -> to direction from power flow evaluation

Auxiliary Variable for the line reactive flow in the to -> from direction from power flow evaluation

Config-side adapter that wraps a power-flow model (e.g. a PowerFlows PowerFlowEvaluationModel such as ACPowerFlow()) as an IOM.AbstractEvaluator so it can be stored on a NetworkModel's EvaluationContainer. IOM owns the abstract evaluator interface but carries no PowerFlows dependency, so the concrete adapter lives here (and is unwrapped by the PowerFlows extension's add_power_flow_data!). Kept type-generic so POM core needs no PowerFlows types.

Auxiliary Variable for the loss factors from AC power flow evaluation that are calculated using the Jacobian matrix

Auxiliary Variable for the bus angle outputs from power flow evaluation

Auxiliary Variable for the bus voltage magnitude outputs from power flow evaluation

Auxiliary Variable for the voltage stability factors from AC power flow evaluation that are calculated using the Jacobian matrix

Auxiliary Variable for Thermal Generation Models that solve for power above min

One one-sided upper slack per meta relaxing a quadratic limit row (StaticBranch on the AC natives: the meta-less apparent-power limit; IVR adds the "c_from"/"c_to" terminal current-magnitude limits).

Formulation whose defining feature is its reactive-power behavior; only the networks with a reactive-power balance (ACP/ACR/IVR/LPACC) build it. Building it on an active-power-only network would silently discard that feature, so those networks are rejected instead of dropped.

Struct to create the constraint to limit reactive power expressions. For more information check Device Formulations.

The specified constraint depends on the UpperBound and LowerBound expressions, but in its most basic formulation is of the form:

\[Q^\text{min} \le q_t \le Q^\text{max}, \quad \forall t \in \{1,\dots,T\}\]

Bounds the absolute charge- or discharge-power step change between consecutive time steps, penalizing oscillation. Active only when the hybrid "regularization" attribute is set. Parametric on ReserveSide.

Non-negative slack variable bounding the absolute step change in charge or discharge power between consecutive time steps. Carried into the objective with a small fixed penalty when the hybrid "regularization" attribute is set.

One branch as the reduction-aware builders see it. Build with _representative_branches (one per arc, for constraint rows) or _all_branches (one per reporting row, for variables), and iterate with _foreach_branch.

B is either a PSY.Device, a PNM.AbstractReductionAggregate, or PNM.ThreeWindingTransformerCircuit.

Struct to create the constraint for ensuring that NonSpinning Reserve can be delivered from turn-off thermal units.

For more information check Service Formulations for NonSpinningReserve.

The constraint is as follows:

\[r_{d,t} \le (1 - u_{d,t}^\text{th}) \cdot R^\text{limit}_d, \quad \forall d \in \mathcal{D}_s, \forall t \in \{1,\dots, T\}\]

One meta-less upper/lower slack pair per branch relaxing the network's rating rows (FlowRateConstraint lb/ub) or, on PTDF-family networks with StaticBranchBounds, the PTDFBranchFlow == FlowActivePowerVariable flow-definition equality.

The window grid a run realized: one forecast window per execution, horizon_count steps each. Every forecast row in a bundle is shaped to this grid. InfraStore requires all forecasts sharing a (resolution, interval) to agree on count, initial time and horizon, and the parameter rows already have the run's shape, so the cost copies must take it too.

Parameter to define active power in time series

Parameter to define active power in time series

Struct to create the start-up initial condition constraints for ThermalMultiStart.

For more information check ThermalGen Formulations for ThermalMultiStartUnitCommitment.

Abstract used for StorageRegularization variables

Aggregation of reserve variables allocated to the storage subcomponent of a hybrid system (or a standalone storage device).

Parameter to define Flow To_From limit time series

Supertype for the constraints a controlled transformer circuit imposes, one per PSY.TransformerControlObjective that POM models.

Struct to limit the turbine flow

\[QW^{min} \le \sum_{j \in J(i)}^T wq_{jt} \le QW^{max},\]

VariableTarget(variable_type, device_type, device_name)

One device's optimization variable: what a state-dependent condition reads, and what a runtime is asked to resolve for it.

Ybus-only families: no factorization, no sensitivity matrices.

_get_initial_condition_type(
    _::Type{RampConstraint},
    _::Type{<:PowerSystems.ThermalGen},
    _::Type{<:AbstractThermalFormulation}
) -> Type{PowerOperationsModels.DeviceAboveMinPower}

This function gets the data for the generators for ramping constraints of thermal generators

add_pwl_term_delta!(
    dir::InfrastructureOptimizationModels.OfferDirection,
    container::OptimizationContainer,
    component::InfrastructureSystems.InfrastructureSystemsComponent,
    _::PowerSystems.OfferCurveCost,
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    _::Type{V<:AbstractDeviceFormulation}
)

Add PWL objective terms using the delta (incremental/block-offer) formulation for static (non-time-series-backed) PSY.OfferCurveCost cost functions.

add_pwl_term_delta!(
    container::OptimizationContainer,
    component::PowerSystems.AbstractReserve,
    _::InfrastructureSystems.CostCurve,
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    _::Type{V<:AbstractServiceFormulation}
) -> Vector{JuMP.AffExpr}

Add the delta PWL objective terms for an operating reserve demand curve (ORDC) service (StepwiseCostReserve over an OnlineReserve/OfflineReserve carrying a demand curve).

add_pwl_term_lambda!(
    container::OptimizationContainer,
    component::PowerSystems.ThermalGen,
    cost_function::Union{InfrastructureSystems.CostCurve{InfrastructureSystems.PiecewisePointCurve}, InfrastructureSystems.FuelCurve{InfrastructureSystems.PiecewisePointCurve}},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    _::Type{V<:ThermalDispatchNoMin}
) -> Vector{JuMP.AffExpr}

Add PWL cost terms for ThermalDispatchNoMin formulation. Rejects non-convex or negative-slope PWL data since ThermalDispatchNoMin cannot use SOS-2 formulations.

add_to_expression!(
    container::OptimizationContainer,
    _::Type{ActivePowerBalance},
    _::Type{FlowActivePowerFromToVariable},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    _::DeviceModel{T<:PowerSystems.ACTransmission, W<:AbstractBranchFormulation},
    network_model::NetworkModel{<:Union{ACPNetworkModel, ACRNetworkModel, DCPLLNetworkModel, IVRNetworkModel, LPACCNetworkModel}}
)

FlowActivePowerFromToVariable contribution to ActivePowerBalance for ACP, ACR, and DCPLL: subtracted from the from-bus nodal balance (power leaves from-bus).

add_to_expression!(
    container::OptimizationContainer,
    _::Type{ActivePowerBalance},
    _::Type{FlowActivePowerToFromVariable},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    _::DeviceModel{T<:PowerSystems.ACTransmission, W<:AbstractBranchFormulation},
    network_model::NetworkModel{<:Union{ACPNetworkModel, ACRNetworkModel, DCPLLNetworkModel, IVRNetworkModel, LPACCNetworkModel}}
)

FlowActivePowerToFromVariable contribution to ActivePowerBalance for ACP, ACR, DCPLL, and IVR: subtracted from the to-bus nodal balance (power leaves to-bus).

add_to_expression!(
    container::OptimizationContainer,
    _::Type{ReactivePowerBalance},
    _::Type{U<:Union{FlowReactivePowerFromToVariable, FlowReactivePowerToFromVariable}},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    _::DeviceModel{T<:PowerSystems.ACTransmission, W<:AbstractBranchFormulation},
    network_model::NetworkModel{<:Union{ACPNetworkModel, ACRNetworkModel, IVRNetworkModel, LPACCNetworkModel}}
)

FlowReactivePower{From,To} branch contribution to ReactivePowerBalance for ACPNetworkModel and ACRNetworkModel. Each directional reactive flow is subtracted from its originating terminal's reactive balance; the terminal is resolved from the variable type.

add_to_expression!(
    container::OptimizationContainer,
    _::Type{ReactivePowerBalance},
    _::Type{U<:Union{FlowReactivePowerFromToVariable, FlowReactivePowerToFromVariable}},
    devices::Array{T<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{T<:PowerSystems.TwoTerminalHVDC, W<:AbstractBranchFormulation},
    network_model::NetworkModel{<:Union{ACPNetworkModel, ACRNetworkModel, IVRNetworkModel, LPACCNetworkModel}}
)

HVDC two-terminal lossless reactive flow → ReactivePowerBalance for ACPNetworkModel, ACRNetworkModel, and IVRNetworkModel. Mirrors the AC ACP/ACR/IVR convention: each directional reactive flow leaves its originating bus, so subtract at that terminal (resolved from the variable type).

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:ActivePowerTimeSeriesParameter},
    devices::Array{V<:PowerSystems.MotorLoad, 1},
    model::DeviceModel{V<:PowerSystems.MotorLoad, W<:StaticPowerLoad},
    network_model::NetworkModel{AreaBalanceNetworkModel}
)

Motor load implementation to add constant power to ActivePowerBalance expression for AreaBalanceNetworkModel

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:Union{PowerOperationsModels.HVDCActivePowerReceivedFromVariable, PowerOperationsModels.HVDCActivePowerReceivedToVariable}},
    devices::Array{V<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{V<:PowerSystems.TwoTerminalHVDC, W<:HVDCTwoTerminalPiecewiseLoss},
    network_model::NetworkModel{AreaBalanceNetworkModel}
)

PWL received HVDC contribution to the AreaBalance area balances. Each received terminal contributes +1.0 at its own terminal's area row: a line crossing areas is a genuine inter-area interchange (with the loss included), and a line internal to one area nets out to -(losses).

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:ActivePowerTimeSeriesParameter},
    devices::Array{V<:PowerSystems.MotorLoad, 1},
    device_model::DeviceModel{V<:PowerSystems.MotorLoad, W<:StaticPowerLoad},
    network_model::NetworkModel{CopperPlateNetworkModel}
)

Motor load implementation to add parameters to SystemBalanceExpressions CopperPlate

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerVariable},
    devices::Array{V<:PowerSystems.ACBranch, 1},
    _::DeviceModel{V<:PowerSystems.ACBranch, W<:AbstractBranchFormulation},
    network_model::NetworkModel{CopperPlateNetworkModel}
)

Implementation of addtoexpression! for lossless branch/network models

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::Array{V<:PowerSystems.StaticInjection, 1},
    device_model::DeviceModel{V<:PowerSystems.StaticInjection, W<:AbstractDeviceFormulation},
    network_model::NetworkModel{CopperPlateNetworkModel}
)

Default implementation to add variables to SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:Union{PowerOperationsModels.HVDCActivePowerReceivedFromVariable, PowerOperationsModels.HVDCActivePowerReceivedToVariable}},
    devices::Array{V<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{V<:PowerSystems.TwoTerminalHVDC, W<:HVDCTwoTerminalPiecewiseLoss},
    network_model::NetworkModel{CopperPlateNetworkModel}
)

PWL received HVDC contribution to the CopperPlate system balance. Each received terminal contributes +1.0 at its own terminal's reference-bus row, so a line whose terminals share one subnetwork nets out to -(losses) and a line crossing subnetworks transfers the sent/received power between the rows with the loss included.

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:SystemBalanceExpressions},
    _::Type{U<:InfrastructureSystems.Optimization.TimeSeriesParameter},
    devices::Array{V<:PowerSystems.ElectricLoad, 1},
    device_model::DeviceModel{V<:PowerSystems.ElectricLoad, W<:AbstractLoadFormulation},
    network_model::NetworkModel{CopperPlateNetworkModel}
)

Electric Load implementation to add parameters to Copperplate SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:SystemBalanceExpressions},
    _::Type{U<:InfrastructureSystems.Optimization.TimeSeriesParameter},
    devices::Array{V<:PowerSystems.StaticInjection, 1},
    device_model::DeviceModel{V<:PowerSystems.StaticInjection, W<:AbstractDeviceFormulation},
    network_model::NetworkModel{CopperPlateNetworkModel}
)

Default implementation to add parameters to Copperplate SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerToFromVariable},
    devices::Array{V<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{V<:PowerSystems.TwoTerminalHVDC, W<:PowerOperationsModels.AbstractTwoTerminalDCLineFormulation},
    network_model::NetworkModel{PTDFNetworkModel}
)

Default implementation to add branch variables to SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:ActivePowerTimeSeriesParameter},
    devices::Array{V<:PowerSystems.MotorLoad, 1},
    model::DeviceModel{V<:PowerSystems.MotorLoad, W<:StaticPowerLoad},
    network_model::NetworkModel{X<:AbstractNetworkModel}
)

Motor load implementation to add constant power to ActivePowerBalance expression

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:ActivePowerTimeSeriesParameter},
    devices::Array{V<:PowerSystems.MotorLoad, 1},
    device_model::DeviceModel{V<:PowerSystems.MotorLoad, W<:StaticPowerLoad},
    network_model::NetworkModel{X<:AbstractPTDFNetworkModel}
)

Motor Load implementation to add constant motor power to PTDF SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerFromToVariable},
    devices::Array{V<:PowerSystems.Branch, 1},
    _::DeviceModel{V<:PowerSystems.Branch, W<:AbstractDeviceFormulation},
    network_model::NetworkModel{X<:AbstractNetworkModel}
)

Default implementation to add branch variables to SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerFromToVariable},
    devices::Array{V<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{V<:PowerSystems.TwoTerminalHVDC, W<:PowerOperationsModels.AbstractTwoTerminalDCLineFormulation},
    network_model::NetworkModel{X<:AbstractPTDFNetworkModel}
)

Default implementation to add branch variables to SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerFromToVariable},
    devices::Array{V<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{V<:PowerSystems.TwoTerminalHVDC, W<:PowerOperationsModels.AbstractTwoTerminalDCLineFormulation},
    network_model::NetworkModel{X<:CopperPlateNetworkModel}
)

Default implementation to add branch variables to SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerToFromVariable},
    devices::Array{V<:PowerSystems.ACBranch, 1},
    _::DeviceModel{V<:PowerSystems.ACBranch, W<:AbstractDeviceFormulation},
    network_model::NetworkModel{X<:AbstractNetworkModel}
)

Default implementation to add branch variables to SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerToFromVariable},
    devices::Array{V<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{V<:PowerSystems.TwoTerminalHVDC, W<:PowerOperationsModels.AbstractTwoTerminalDCLineFormulation},
    network_model::NetworkModel{X<:CopperPlateNetworkModel}
)

Default implementation to add branch variables to SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerVariable},
    devices::Array{V<:PowerSystems.ACBranch, 1},
    _::DeviceModel{V<:PowerSystems.ACBranch, W<:AbstractBranchFormulation},
    network_model::NetworkModel{X<:AbstractActivePowerModel}
)

Implementation of addtoexpression! for lossless branch/network models

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerVariable},
    devices::Array{V<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{V<:PowerSystems.TwoTerminalHVDC, W<:AbstractBranchFormulation},
    network_model::NetworkModel{X<:PTDFNetworkModel}
)

Implementation of addtoexpression! for lossless branch/network models

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerVariable},
    devices::Array{V<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{V<:PowerSystems.TwoTerminalHVDC, W<:AbstractBranchFormulation},
    network_model::NetworkModel{X<:Union{ACPNetworkModel, ACRNetworkModel, DCPLLNetworkModel, DCPNetworkModel, IVRNetworkModel, LPACCNetworkModel, NFANetworkModel}}
)

HVDC two-terminal lossless active-power flow contribution to ActivePowerBalance.

Wires the single FlowActivePowerVariable directly: subtracts at the from-bus, adds at the to-bus. Used by every native nodal network model.

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:HVDCLosses},
    devices::Array{V<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{V<:PowerSystems.TwoTerminalHVDC, W<:HVDCTwoTerminalDispatch},
    network_model::NetworkModel{X<:Union{CopperPlateNetworkModel, PTDFNetworkModel}}
)

Default implementation to add branch variables to SystemBalanceExpressions.

Handles HVDCs internal to a subnetwork, by subtracting losses from power in subnetwork.

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::Array{V<:PowerSystems.StaticInjection, 1},
    device_model::DeviceModel{V<:PowerSystems.StaticInjection, W<:AbstractDeviceFormulation},
    network_model::NetworkModel{X<:PTDFNetworkModel}
)

Default implementation to add variables to SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:PowerOperationsModels.HVDCInverterActivePowerVariable},
    devices::Array{V<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{V<:PowerSystems.TwoTerminalHVDC, W<:HVDCTwoTerminalLCC},
    network_model::NetworkModel{X<:AbstractReactivePowerNetworkModel}
)

HVDC LCC implementation to add ActivePowerBalance expression for HVDCInverterActivePowerVariable variable

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:PowerOperationsModels.HVDCRectifierActivePowerVariable},
    devices::Array{V<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{V<:PowerSystems.TwoTerminalHVDC, W<:HVDCTwoTerminalLCC},
    network_model::NetworkModel{X<:AbstractReactivePowerNetworkModel}
)

HVDC LCC implementation to add ActivePowerBalance expression for HVDCRectifierActivePowerVariable variable

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:PowerOperationsModels.RealizedShiftedLoad},
    devices::Array{V<:PowerSystems.ShiftablePowerLoad, 1},
    device_model::DeviceModel{V<:PowerSystems.ShiftablePowerLoad, W<:PowerLoadShift},
    network_model::NetworkModel{X<:AbstractNetworkModel}
)

Electric Load implementation to add the realized shifted load to ActivePowerBalance expressions for any network model. Targets come from _balance_expression_targets (nodal bus, system, area, or PTDF/AreaPTDF system+bus pair), matching how every other injection enters the balance; the multiplier -1.0 matches get_variable_multiplier(::Type{<:VariableType}, ::Type{<:PSY.ElectricLoad}, ::Type{<:AbstractLoadFormulation}), the sign convention shared by every load formulation.

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:Union{PowerOperationsModels.HVDCActivePowerReceivedFromVariable, PowerOperationsModels.HVDCActivePowerReceivedToVariable}},
    devices::Array{V<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{V<:PowerSystems.TwoTerminalHVDC, W<:HVDCTwoTerminalPiecewiseLoss},
    network_model::NetworkModel{X<:AbstractPTDFNetworkModel}
)

PWL implementation to add received HVDC branch variables to SystemBalanceExpressions. Both received terminals contribute +1.0 at their terminal's nodal and system rows; the from/to terminal is resolved from the variable type.

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:Union{PowerOperationsModels.HVDCActivePowerReceivedFromVariable, PowerOperationsModels.HVDCActivePowerReceivedToVariable}},
    devices::Array{V<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{V<:PowerSystems.TwoTerminalHVDC, W<:HVDCTwoTerminalPiecewiseLoss},
    network_model::NetworkModel{X<:Union{ACPNetworkModel, ACRNetworkModel, DCPLLNetworkModel, DCPNetworkModel, IVRNetworkModel, LPACCNetworkModel, NFANetworkModel}}
)

PWL received HVDC active power contribution to the nodal ActivePowerBalance for the native nodal network models (AC and DC). Both received terminals contribute +1.0 at their own bus, mirroring the PTDF PWL wiring; under the AC natives the link offers no reactive power.

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ReactivePowerBalance},
    _::Type{U<:ReactivePowerTimeSeriesParameter},
    devices::Array{V<:PowerSystems.MotorLoad, 1},
    model::DeviceModel{V<:PowerSystems.MotorLoad, W<:StaticPowerLoad},
    network_model::NetworkModel{X<:ACPNetworkModel}
)

Motor load implementation to add constant power to ActivePowerBalance expression

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:ReactivePowerBalance},
    _::Type{U<:Union{PowerOperationsModels.HVDCInverterReactivePowerVariable, PowerOperationsModels.HVDCRectifierReactivePowerVariable}},
    devices::Array{V<:PowerSystems.TwoTerminalHVDC, 1},
    _::DeviceModel{V<:PowerSystems.TwoTerminalHVDC, W<:HVDCTwoTerminalLCC},
    network_model::NetworkModel{X<:AbstractReactivePowerNetworkModel}
)

HVDC LCC: both terminals' reactive power consumption is consumed at their own bus (-1.0) in ReactivePowerBalance. The rectifier/inverter terminal is resolved from the variable type.

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:SystemBalanceExpressions},
    _::Type{U<:InfrastructureSystems.Optimization.TimeSeriesParameter},
    devices::Array{V<:PowerSystems.Device, 1},
    model::DeviceModel{V<:PowerSystems.Device, W<:AbstractDeviceFormulation},
    network_model::NetworkModel{X<:AbstractNetworkModel}
)

Default implementation to add parameters to SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:SystemBalanceExpressions},
    _::Type{U<:InfrastructureSystems.Optimization.TimeSeriesParameter},
    devices::Array{V<:PowerSystems.ElectricLoad, 1},
    model::DeviceModel{V<:PowerSystems.ElectricLoad, W<:AbstractLoadFormulation},
    network_model::NetworkModel{X<:AbstractNetworkModel}
)

Generic electric load implementation to add parameters to SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:SystemBalanceExpressions},
    _::Type{U<:InfrastructureSystems.Optimization.TimeSeriesParameter},
    devices::Array{V<:PowerSystems.ElectricLoad, 1},
    device_model::DeviceModel{V<:PowerSystems.ElectricLoad, W<:AbstractLoadFormulation},
    network_model::NetworkModel{X<:AbstractPTDFNetworkModel}
)

Electric Load implementation to add parameters to PTDF SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:SystemBalanceExpressions},
    _::Type{U<:InfrastructureSystems.Optimization.TimeSeriesParameter},
    devices::Array{V<:PowerSystems.StaticInjection, 1},
    device_model::DeviceModel{V<:PowerSystems.StaticInjection, W<:AbstractDeviceFormulation},
    network_model::NetworkModel{X<:AbstractPTDFNetworkModel}
)

Default implementation to add parameters to SystemBalanceExpressions

add_to_expression!(
    container::OptimizationContainer,
    _::Type{T<:SystemBalanceExpressions},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::Array{V<:PowerSystems.StaticInjection, 1},
    model::DeviceModel{V<:PowerSystems.StaticInjection, W<:AbstractDeviceFormulation},
    network_model::NetworkModel{X<:AbstractNetworkModel}
)

Default implementation to add device variables to SystemBalanceExpressions

add_variables!(
    container::OptimizationContainer,
    _::Type{V<:InfrastructureSystems.Optimization.VariableType},
    _::Array{T<:PowerSystems.ACTransmission, 1},
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, F<:AbstractBranchFormulation},
    network_model::NetworkModel{<:Union{ACPNetworkModel, ACRNetworkModel, DCPLLNetworkModel, DCPNetworkModel, IVRNetworkModel, LPACCNetworkModel, NFANetworkModel, AbstractPTDFNetworkModel}}
)

Branch variables for reduction-aware networks. Every entry of a reduced arc aliases the same underlying JuMP variable.

get_min_max_limits(
    x::PowerSystems.HydroGen,
    _::Type{<:ActivePowerVariableLimitsConstraint},
    _::Type{<:PowerOperationsModels.AbstractHydroReservoirFormulation}
) -> Any

Min and max active Power Variable limits

get_min_max_limits(
    x::PowerSystems.HydroGen,
    _::Type{<:PowerOperationsModels.ReactivePowerVariableLimitsConstraint},
    _::Type{<:PowerOperationsModels.AbstractHydroReservoirFormulation}
) -> Any

Min and max reactive Power Variable limits

get_min_max_limits(
    x::PowerSystems.HydroPumpTurbine,
    _::Type{<:ActivePowerVariableLimitsConstraint},
    _::Type{<:PowerOperationsModels.AbstractHydroPumpFormulation}
) -> @NamedTuple{min::Float64, max::Float64}

Min and max active Power Variable limits

get_min_max_limits(
    x::PowerSystems.HydroPumpTurbine,
    _::Type{<:InputActivePowerVariableLimitsConstraint},
    _::Type{<:PowerOperationsModels.AbstractHydroPumpFormulation}
) -> @NamedTuple{min::Float64, max::Float64}

Min and max active pump Power Variable limits

get_min_max_limits(
    x::PowerSystems.HydroPumpTurbine,
    _::Type{<:PowerOperationsModels.ReactivePowerVariableLimitsConstraint},
    _::Type{<:PowerOperationsModels.AbstractHydroPumpFormulation}
) -> Union{Nothing, @NamedTuple{min::Float64, max::Float64}}

Min and max reactive Power Variable limits for hydro pump/turbine formulations.

get_min_max_limits(
    x::PowerSystems.HydroTurbine,
    _::Type{<:ActivePowerVariableLimitsConstraint},
    _::Type{<:PowerOperationsModels.AbstractHydroUnitCommitment}
) -> @NamedTuple{min::Float64, max::Float64}

Min and max active Power Variable limits

get_min_max_limits(
    d::PowerSystems.Storage,
    _::Type{StateofChargeLimitsConstraint},
    _::Type{<:PowerOperationsModels.AbstractStorageFormulation}
) -> @NamedTuple{min::Float64, max::Float64}

Min and max limits for Energy Capacity Constraint and AbstractStorageFormulation

get_min_max_limits(
    device::PowerSystems.ThermalGen,
    _::Type{ActivePowerVariableLimitsConstraint},
    _::Type{<:InfrastructureOptimizationModels.AbstractThermalDispatchFormulation}
) -> @NamedTuple{min::Float64, max::Float64}

Min and max active power limits of generators for thermal dispatch formulations

get_min_max_limits(
    device::PowerSystems.ThermalGen,
    _::Type{ActivePowerVariableLimitsConstraint},
    _::Type{<:InfrastructureOptimizationModels.AbstractThermalUnitCommitment}
) -> @NamedTuple{min::Float64, max::Float64}

Min and max active power limits of generators for thermal unit commitment formulations

get_min_max_limits(
    device::PowerSystems.ThermalGen,
    _::Type{ActivePowerVariableLimitsConstraint},
    _::Type{<:PowerOperationsModels.AbstractCompactUnitCommitment}
) -> @NamedTuple{min::Float64, max::Float64}

Min and Max active power limits for Compact Unit Commitment

get_min_max_limits(
    device::PowerSystems.ThermalGen,
    _::Type{ActivePowerVariableLimitsConstraint},
    _::Type{ThermalCompactDispatch}
) -> @NamedTuple{min::Float64, max::Float64}

Min and max active power limits of generators for thermal dispatch compact formulations

get_min_max_limits(
    device::PowerSystems.ThermalGen,
    _::Type{ActivePowerVariableLimitsConstraint},
    _::Type{ThermalDispatchNoMin}
) -> @NamedTuple{min::Float64, max::Float64}

Min and max active power limits of generators for thermal dispatch no minimum formulations

get_min_max_limits(
    device::PowerSystems.ThermalGen,
    _::Type{ActivePowerVariableLimitsConstraint},
    _::Type{ThermalMultiStartUnitCommitment}
) -> @NamedTuple{min::Float64, max::Float64}

Min and max active power limits for multi-start unit commitment formulations

get_min_max_limits(
    device::PowerSystems.ThermalGen,
    _::Type{PowerOperationsModels.ReactivePowerVariableLimitsConstraint},
    _::Type{<:InfrastructureOptimizationModels.AbstractThermalDispatchFormulation}
) -> Union{Nothing, @NamedTuple{min::Float64, max::Float64}}

Reactive power limits of generators for all dispatch formulations

get_min_max_limits(
    device::PowerSystems.ThermalGen,
    _::Type{PowerOperationsModels.ReactivePowerVariableLimitsConstraint},
    _::Type{<:InfrastructureOptimizationModels.AbstractThermalUnitCommitment}
) -> Union{Nothing, @NamedTuple{min::Float64, max::Float64}}

Reactive power limits of generators when there CommitmentVariables

_add_both_terminals_to_nodal!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::Array{V<:PowerSystems.Component, 1},
    network_model::NetworkModel
)

Add a lossless branch/HVDC flow variable to both terminal nodal balances: -1.0 at the from-bus (power leaves) and +1.0 at the to-bus.

_add_compact_on_to_balance!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    _::Type{U<:OnVariable},
    devices::Array{V<:PowerSystems.ThermalGen, 1},
    network_model::NetworkModel,
    _::DeviceModel{V<:PowerSystems.ThermalGen, W}
)

Add a compact unit-commitment OnVariable to a balance expression. Must-run units have On ≡ 1, so their p_min contribution enters as a constant; all others contribute p_min * get_variable_multiplier(U, V, W) * On[name, t]. Targets come from _balance_expression_targets, so this is correct for every network model (nodal, area, system, PTDF).

_add_constant_power_to_balance!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    devices::Array{V<:PowerSystems.Component, 1},
    network_model::NetworkModel
)

Add a constant device power (e.g. a StaticPowerLoad motor load) to a balance expression with multiplier -1.0. Active vs reactive power is selected by the expression type T via _constant_power; targets come from _balance_expression_targets.

_add_current_magnitude_limits!(
    container::OptimizationContainer,
    _::Type{T<:PowerSystems.ACTransmission},
    rating2::AbstractVector,
    meta::String,
    real_var,
    imag_var,
    slack
)

Add the real² + imag² ≤ rating² current-magnitude limit for one terminal (meta), one constraint per (name, t). rating2 pairs each branch name to its squared rating.

_add_directional_flow_rate_limits!(
    container::OptimizationContainer,
    _::Type{ConsKey<:InfrastructureSystems.Optimization.ConstraintType},
    _::Type{PVar<:InfrastructureSystems.Optimization.VariableType},
    _::Type{QVar<:InfrastructureSystems.Optimization.VariableType},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, U<:AbstractBranchFormulation},
    network_model::NetworkModel
)

Shared builder for directional apparent-power rate limit constraints under ACPNetworkModel.

Constrains pflow^2 + qflow^2 ≤ rating^2 for the directional active/reactive flow variable pair (PVar/QVar) and stores the result under the constraint key ConsKey. Under an active network reduction it covers each reduced arc exactly once (the flow variables are shared per arc), with the rating from the reduction entry's equivalent parameters.

_add_hvdc_copperplate_flow!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::Array{V<:PowerSystems.Component, 1},
    network_model::NetworkModel{CopperPlateNetworkModel},
    multiplier::Float64
)

Add an HVDC flow variable to a CopperPlate system balance. The flow only matters across subnetworks (it leaves one reference bus and arrives at another), so it contributes multiplier at the to-side reference bus for inter-subnetwork arcs.

_add_load_ts_parameter_to_balance!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    _::Type{U<:InfrastructureSystems.Optimization.TimeSeriesParameter},
    devices::Array{V<:PowerSystems.ElectricLoad, 1},
    network_model::NetworkModel,
    model::DeviceModel{V<:PowerSystems.ElectricLoad, W}
)

Add an electric-load time-series parameter to a balance expression. Mirrors _add_ts_parameter_to_balance! but falls back to a unit value scaled by get_multiplier_value(U, d, W) (with a warning) when a device lacks the time series.

_add_modf_post_contingency_flow_expressions!(
    container::OptimizationContainer,
    _::Type{T<:PostContingencyBranchFlow},
    model::DeviceModel{V<:PowerSystems.ACTransmission, F<:PowerOperationsModels.AbstractSecurityConstrainedStaticBranch},
    network_model::NetworkModel,
    nodal_injection_expressions::Matrix{JuMP.AffExpr}
)

Shared MODF post-contingency expression builder: for every monitored arc m and registered outage k,

expr[m, k, t] = Σ_bus MODF[m, k][bus] * nodal_injection_expressions[bus, t]
                + Σ_adj delta_adj[t] * (MODF[m, k][from_adj] − MODF[m, k][to_adj])

nodal_injection_expressions must hold the per-bus active-power injections in the same bus order as the MODF columns. On PTDF networks the ActivePowerBalance expression IS the injection vector (flows are not variables there), and it already includes every arc's shift-injection pair — the adjustments remove the pairs of the arcs the outage trips. On DCP the injections are recovered from the balance's branch-flow terms (see _dcp_nodal_injection_expressions) and carry no shift pairs at all; that is consistent only because security-constrained DCP models reject every shifted transformer at validation.

_add_offline_shutdown_rows!(
    rows,
    jump_model::JuMP.Model,
    name::String,
    q_limit::Float64,
    awards,
    varbin,
    status0,
    time_steps
)

OfflineReserveShutdownConstraint rows of device name: the offline awards in awards ((service name, award variable) pairs) are 0 in the step it goes off, sum(awards) <= q_limit * (1 - u_{t-1} + u_t) with u_0 = status0. The right-hand side is 0 when the unit goes off, q_limit while its status holds and 2 * q_limit when it starts.

_add_onstatus_parameter_to_balance!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    _::Type{U<:OnStatusParameter},
    devices::Array{V<:PowerSystems.ThermalGen, 1},
    network_model::NetworkModel,
    _::DeviceModel{V<:PowerSystems.ThermalGen, W}
)

Add a thermal OnStatusParameter to a balance expression with the device-specific get_expression_multiplier(U, T, d, W), targets from _balance_expression_targets.

_add_pmin_scaled_on_to_balance!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    _::Type{U<:OnVariable},
    devices::Array{V<:PowerSystems.ThermalGen, 1},
    network_model::NetworkModel,
    _::DeviceModel{V<:PowerSystems.ThermalGen, W}
)

Add a compact unit-commitment OnVariable scaled by per-device p_min. Must-run units have On ≡ 1 and are left out of the OnVariable container entirely, so their p_min contribution enters as a constant; all others scale the variable. Used by the CopperPlate and PTDF compact-UC methods.

_add_post_contingency_sparse_constraints!(
    container::OptimizationContainer,
    ::Type{T<:InfrastructureSystems.Optimization.ConstraintType},
    ::Type{V<:PowerSystems.ACTransmission};
    meta
)

Register an empty SparseAxisArray keyed by (outage_id::String, monitored_name::String, t::Int) for the given constraint type and meta tag.

_add_post_contingency_sparse_expression!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureOptimizationModels.PostContingencyExpressions},
    _::Type{V<:PowerSystems.ACTransmission},
    resolved::Vector{Pair{Int64, Vector{PowerOperationsModels.RepresentativeBranch}}},
    time_steps::UnitRange{Int64}
) -> JuMP.Containers.SparseAxisArray{JuMP.AffExpr, 3, Tuple{String, String, Int64}}

Pre-allocate a SparseAxisArray keyed by (outage_id::String, monitored_name::String, t::Int) holding JuMP.AffExpr zeros for every entry produced by _resolve_monitored_branches. The pre-fill is required so the parallel PTDF expression build below cannot race on Dict resize.

_add_row!(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    owner_id::Integer,
    owner_type::AbstractString,
    ts::InfrastructureSystems.TimeSeriesData
) -> InfrastructureSystems.TimeSeriesKey

Add one row to store, under owner_id/owner_type (or a component's own id/type). One spot for the owner-category argument every IS.add_time_series! call here repeats.

_add_terminal_flow_to_nodal!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::Array{V<:PowerSystems.Component, 1},
    network_model::NetworkModel,
    multiplier::Float64
)

Add a single directional branch/HVDC terminal flow variable to a nodal balance expression. The terminal bus is fixed by the variable type U via _terminal_bus and multiplier is the signed nodal contribution. Shared by the ACP branch-flow methods and the HVDC LCC/VSC terminal methods.

_add_terminal_flow_to_ptdf_balance!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::Array{V<:PowerSystems.Component, 1},
    network_model::NetworkModel{X<:AbstractPTDFNetworkModel},
    multiplier::Float64
)

Add a single directional HVDC flow variable to both the nodal and the system/area balance of a PTDF network. The variable contributes multiplier at the chosen terminal's nodal bus, and the same at that terminal's reference bus when the arc crosses subnetworks. The terminal (from/to) is fixed by the variable type U via _terminal_bus for both the nodal and reference-bus entry.

_add_ts_parameter_to_balance!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    _::Type{U<:InfrastructureSystems.Optimization.TimeSeriesParameter},
    devices::Array{V<:PowerSystems.Device, 1},
    network_model::NetworkModel,
    _::DeviceModel{V<:PowerSystems.Device, W}
)

Add a device time-series parameter to a balance expression. The contributed term is multiplier[name, t] * parameter[name, t], with targets from _balance_expression_targets.

_add_variable_to_balance!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::Array{V<:PowerSystems.StaticInjection, 1},
    network_model::NetworkModel,
    _::DeviceModel{V<:PowerSystems.StaticInjection, W}
)

Add a device variable to a balance expression for any network model. Targets come from _balance_expression_targets and the inner write from _apply_term_to_targets!; the contributed term is get_variable_multiplier(U, V, W) * variable[name, t].

_all_branches(
    network_model::NetworkModel,
    ::Type{T<:PowerSystems.ACTransmission};
    number_to_name
) -> Vector{PowerOperationsModels.RepresentativeBranch}

One entry per reporting row, for variable container axes: every segment of a series chain gets its own row, because a lossless chain carries the same flow in each, while a parallel group gets one row at whatever depth it sits. A parallel member is therefore not an axis key – reach its row with _representative_branch, which redirects.

_apply_term_to_targets!(
    _::Tuple{},
    _::Union{Float64, JuMP.AbstractJuMPScalar},
    _::Float64,
    _::Int64
)

Apply a value * multiplier term to each (expression_matrix, row_index) target a device contributes to, as resolved by _balance_expression_targets: one target for single-bus/area/system network models, two for PTDF/AreaPTDF (a nodal entry plus a system/area entry).

Tail recursion keeps the heterogeneous length-1/length-2 tuples type stable; the compiler unrolls it.

_assert_flow_expression_dimensions(
    name::AbstractString,
    n_col::Int64,
    nodal_balance_expressions::Matrix{JuMP.AffExpr}
)

Error if a PTDF/MODF column length differs from the nodal-balance bus dimension. Prevents a downstream @inbounds out-of-bounds read; a mismatch means the matrix and container used different network reductions.

_balance_expression_targets(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    network_model::NetworkModel,
    d::PowerSystems.Component
) -> Tuple{Tuple{Any, Int64}}

Resolve, for a device under a given network model, the set of (expression_matrix, row_index) entries that the device's injection contributes to.

This is the only axis on which the many device-injection add_to_expression! methods differ; the _add_*_to_balance! helpers pair this resolver with a per-device term and share _apply_term_to_targets! for the inner write, keeping the device/time loop short. Dispatch is on disjoint network-model subtrees, so no ambiguity:

• <:AbstractNetworkModel — nodal bus only (default AC models; also the security-constrained PTDF variants, matching prior variable-method behavior)
• CopperPlateNetworkModel — system reference bus only
• AreaBalanceNetworkModel — area only
• PTDFNetworkModel / AreaPTDFNetworkModel — system/area entry plus nodal bus

_build_bilinear_config(
    method::String,
    quad_method::String,
    tolerance::Float64,
    delta_x::Float64,
    delta_y::Float64
) -> Union{InfrastructureOptimizationModels.NoBilinearApproxConfig, InfrastructureOptimizationModels.DNMDTBilinearConfig, InfrastructureOptimizationModels.NMDTBilinearConfig, InfrastructureOptimizationModels.Bin2Config, InfrastructureOptimizationModels.HybSConfig}

Build the IOM bilinear config consumed by IOM._add_bilinear_approx! from string attribute values, sizing the discretization from tolerance and the per-device domain widths (delta_x, delta_y).

method selects the bilinear approximation scheme: "bin2", "hybs", "nmdt", "dnmdt", or "none". quad_method selects the inner quadratic PWL method used by the "bin2" and "hybs" schemes ("solver_sos2", "manual_sos2", "sawtooth", and — for "bin2" only — "nmdt", "dnmdt"); it is ignored by the other schemes.

Each IOM tolerance_depth / tolerance_epigraph_depth helper inverts its method's worst-case-gap bound and allocates the error budget across the inner quadratic, so POM never sizes the inner quad by hand — it just builds the inner quad at the returned depth (with the IOM-default epigraph_depth).

Errors when method or quad_method is unrecognized, when quad_method is invalid for the selected scheme, or when tolerance is non-finite or ≤ 0.

_build_catalog(
    matrix,
    branch_models::Dict{Symbol, DeviceModel}
) -> Any

This build's branch index. The template's branch filters restrict which branches get flow variables – an optimization concern, so it lives in the build's catalog rather than in the reduction, which stays exactly as the matrix produced it.

An unfiltered template reuses the matrix's own catalog; there is nothing to restrict.

_build_device_model_events!(
    template::PowerOperationsProblemTemplate,
    sys::PowerSystems.System
)

For each event model attached to the template: validate its time-series mapping, populate attribute_device_map (attribute id → concrete device type → device names) from the system's supplemental attributes, and distribute the event model to every DeviceModel in the template whose device type carries the attribute and supports events.

_build_device_model_outages!(
    template::InfrastructureOptimizationModels.AbstractProblemTemplate,
    sys::PowerSystems.System
)

Populate device_model.outages for every security-constrained (SC) branch device model in the template, in a single pass over the system's outage supplemental attributes. DeviceModel{D, SC} claims an outage iff D is among the types of the outaged (attached) components. The inner dict carries the per-modeled-type breakdown of monitored component names.

Selection semantics:

• If m.outages is non-empty when this runs, the user explicitly listed UUIDs via the constructor kwarg. Restrict to those UUIDs only; warn for any user-listed UUID that produced no D-type entry.
• If m.outages is empty, auto-discover. Honor "include_planned_outages" on m's attributes (default false) — PlannedOutages are skipped on the auto-discover path unless the attribute is true.

The monitored set is exactly what each outage lists in its monitored_components; an outage with empty monitored_components is treated as "monitor nothing" (a warning is emitted). A monitored component whose type is not a modeled PSY.ACTransmission branch type is reported once per type and skipped, as is an unavailable one: it is absent from the branch catalog and so cannot resolve to a representative arc.

_check_interface_branches(
    template::PowerOperationsProblemTemplate,
    sys::PowerSystems.System,
    _::NetworkModel{N<:AbstractNetworkModel}
)

Reject a template whose transmission interfaces include a branch the model builds no flow for: either the branch's type has no branch model in the template, or that branch model's filter_function (or subsystem) excludes the branch. Either way the interface's flow expression would silently omit the branch, so the template is rejected and the user must make the filter and the interface definitions consistent.

_consolidate_device_model_outages_with_modf!(
    branch_models::Dict{Symbol, DeviceModel},
    modf_matrix::PowerNetworkMatrices.VirtualMODF
)

Drop outages from each outage-aware-branch DeviceModel whose UUID isn't registered on modf_matrix; without this they'd KeyError downstream in post-contingency expression construction. PNM's _register_outages! silently skips outages it can't convert to a NetworkModification, so the model-side view of m.outages can be a strict superset of what's actually usable.

_constant_power(_::Type{<:ActivePowerBalance}, d) -> Any

Constant device power for a StaticPowerLoad-style injection. Active vs reactive is already encoded in the balance-expression type, so it is resolved by dispatch rather than by passing a getter.

_copy_cost_time_series!(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    c::PowerSystems.Component,
    key::InfrastructureSystems.TimeSeriesKey,
    ts::InfrastructureSystems.Forecast,
    windows::PowerOperationsModels.RunWindows
) -> InfrastructureSystems.TimeSeriesKey

Re-window a forecast cost onto windows: one window per run execution, horizon_count steps each, read starting at each of windows.initial_times.

A horizon under two steps cannot hold a re-windowed forecast (InfraStore's own floor; see parameter_store_from_model for the identical constraint on parameter rows) — every run this short writes no parameter rows either, so nothing downstream depends on this cost sharing their grid, and the original series is copied verbatim instead. Skipping it outright is not an option: sys's own cost still points at the original series, and every reader of the key map (write_outputs_system_bundle!'s PSY.to_openapi remap, decision_model.jl's system_to_file path) requires an entry for every association id sys still references.

_copy_cost_time_series!(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    c::PowerSystems.Component,
    _::InfrastructureSystems.TimeSeriesKey,
    ts::InfrastructureSystems.StaticTimeSeries,
    _::PowerOperationsModels.RunWindows
) -> Union{InfrastructureSystems.TimeSeriesKey{T} where T<:(InfrastructureSystems.NonSequentialTimeSeries), InfrastructureSystems.TimeSeriesKey{T} where T<:(InfrastructureSystems.SingleTimeSeries)}

Copy a static series verbatim into store, under c's own document id and type. No make_time_array round trip: the original series object goes in as-is. Statics have no cross-forecast compatibility constraint, so no re-windowing is needed.

_copy_existing_post_contingency_expressions!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureOptimizationModels.PostContingencyExpressions},
    _::Type{V<:PowerSystems.ACTransmission},
    expression_container::JuMP.Containers.SparseAxisArray,
    resolved::Vector{Pair{Int64, Vector{PowerOperationsModels.RepresentativeBranch}}},
    time_steps::UnitRange{Int64}
) -> Vector{Pair{Int64, Vector{PowerOperationsModels.RepresentativeBranch}}}

Pre-pass for the multi-component outage dedup: copy already-built entries into expression_container and return the residual resolved shape that still needs fresh computation. Returns resolved unchanged when no other-V container exists.

_cost_time_series_keys(
    _::PowerSystems.Component
) -> Vector{InfrastructureSystems.TimeSeriesKey}

Every TimeSeriesKey component c's operation cost holds, or an empty vector for a component type that carries no operation_cost field. One method per abstract type that covers only components with an operation_cost; never isa/hasfield on Component.

_cost_time_series_keys(
    c::Union{PowerSystems.OfflineReserve, PowerSystems.OnlineReserve}
) -> Vector{InfrastructureSystems.TimeSeriesKey}

An online/offline/group reserve's own TimeSeriesKey, when its demand-curve variable is time-series-backed, else none. A reserve's variable curve is not an operation_cost, so it is not reached by the PSY.get_time_series_keys(PSY.get_operation_cost(c)) methods above; it is exported to the document the same way a device's cost is (PowerSystems.convert_cost_to_openapi on the curve's TimeSeriesFunctionData), so it must be copied here too or the exported document ends up with a dangling association id.

_current_rating(
    rep::PowerOperationsModels.RepresentativeBranch,
    model::DeviceModel
) -> Any

Current rating of the arc: apparent-power rating over the lowest endpoint voltage it can see, so the bound holds across the whole voltage band.

_dcp_nodal_injection_expressions(
    container::OptimizationContainer,
    bus_axis::Vector{Int64}
) -> Matrix{JuMP.AffExpr}

Nodal active-power injection expressions on a DCP network, with rows ordered by bus_axis (the MODF bus axis) so that row i multiplies MODF column entry i.

The DCP ActivePowerBalance cannot be used directly in the MODF product: it holds the injections PLUS the branch-flow variables and is constrained to zero, so its MODF-weighted sum is identically vacuous. The nodal balance constraint enforces injections[bus] = -flow_terms[bus] exactly, so the injection is recovered by keeping only the balance terms whose variables are AC branch FlowActivePowerVariables and negating them.

The DCP balance bus axis comes from Dict-ordered reduction-map keys, so rows are resolved through the container's axis lookup by bus number instead of assuming positional agreement with the MODF axis.

_demand_services(
    model::ServiceModel,
    services::Vector{<:PowerSystems.AbstractReserve}
) -> Vector

Services in services that impose a demand of their own under model's formulation.

_deployed_fraction_key(
    container::OptimizationContainer,
    device_model::DeviceModel,
    service::PowerSystems.AbstractReserve
) -> Any

The deployed-fraction parameter key covering service through device_model's registered service models, or nothing when the reserve's fraction is its fixed scalar: no service model covers it, or it carries no deployed-fraction profile.

_directional_flow_rating(
    rep::PowerOperationsModels.RepresentativeBranch,
    model::DeviceModel
) -> Any

_branch_rating with a zero guard, for the flow limits that would otherwise pin the arc to zero flow.

_emergency_flow_limits(
    branch::PowerSystems.ACTransmission
) -> NamedTuple{(:min, :max), <:Tuple{Any, Any}}

Post-contingency (emergency) flow limits of the arc. PNM.get_equivalent_emergency_rating covers raw devices, reduction aggregates and three-winding circuits alike — it returns rating_b and falls back to rating where rating_b is undefined — and is already system-base per-unit, so it takes no u"SU".

_excludes_shutdown_step(
    model::DeviceModel
) -> Union{Missing, Bool}

Whether an OfflineReserve service on model sets "exclude_shutdown_step". Gates the hydro DeviceStatus initial condition that OfflineReserveShutdownConstraint reads, so models without the rule keep their initial-condition set.

_find_shared_post_contingency_constraint_sources(
    container::OptimizationContainer,
    _::Type{T<:PowerOperationsModels.PostContingencyConstraintType},
    _::Type{V<:PowerSystems.ACTransmission},
    outage_id::String,
    name::String,
    t::Int64
) -> Tuple{Union{Nothing, JuMP.Containers.SparseAxisArray}, Union{Nothing, JuMP.Containers.SparseAxisArray}}

Constraint counterpart to _find_shared_post_contingency_expression_source. Returns (lb_source, ub_source) SparseAxisArrays in one scan; either slot is nothing when no shared container of that meta exists.

_find_shared_post_contingency_slack_sources(
    container::OptimizationContainer,
    _::Type{V<:PowerSystems.ACTransmission},
    outage_id::String,
    name::String,
    t::Int64
) -> Tuple{Union{Nothing, JuMP.Containers.DenseAxisArray, JuMP.Containers.SparseAxisArray}, Union{Nothing, JuMP.Containers.DenseAxisArray, JuMP.Containers.SparseAxisArray}}

Locate the post-contingency slack variable containers that a shared constraint for (outage_id, name, t) already references, registered by the source DeviceModel under a component type other than V. Returns (ub_source, lb_source); either slot is nothing when the shared constraint was built without that slack (the source model had use_slacks = false). Lets a reusing model alias those refs into its own slack container so get_variable/has_container_key stay consistent with the constraints it reuses, regardless of branch-model build order.

_foreach_branch(f, reps)

Used for specializing the device loop per concrete RepresentativeBranch.

_get_data_for_tdc(
    initial_conditions_on::Array{T<:InitialCondition, 1},
    initial_conditions_off::Array{U<:InitialCondition, 1},
    resolution::Dates.TimePeriod
) -> Tuple{Matrix{InitialCondition}, Vector{@NamedTuple{up::Float64, down::Float64}}}

If the fraction of hours that a generator has a duration constraint is less than the fraction of hours that a single time_step represents then it is not binding.

_has_offline_reserve_service(model::DeviceModel) -> Bool

Whether a DeviceModel carries an OfflineReserve service. Gates the OfflineReserveBandConstraint so that models without offline reserves build exactly the classic single semi-continuous band row.

_has_other_v_container(
    container_dict,
    _::Type{T},
    _::Type{V<:PowerSystems.ACTransmission}
) -> Bool

Fast-path precheck: returns true iff any container of entry type T exists under a component type other than V.

_has_reserve_demand(
    _::ServiceModel{<:PowerSystems.AbstractReserve, <:AbstractReservesFormulation},
    service::PowerSystems.AbstractReserve
) -> Bool

Whether service has a demand driver under model's formulation. Requirement-based formulations (RangeReserve, RampReserve, NonSpinningReserve) use requirement; StepwiseCostReserve uses the operating reserve demand curve, and ignores requirement entirely.

_has_ts_requirement(
    model::ServiceModel,
    s::PowerSystems.AbstractReserve
) -> Bool

Whether a reserve's requirement is scaled by an attached requirement time series.

Resolves the series name from the ServiceModel's time_series_names (a user can override the name there), and deliberately does not pin the series' concrete TimeSeriesData type (Deterministic in recurrent solves, SingleTimeSeries otherwise). Returns false when the model declares no requirement series name (the formulation carries no requirement parameter).

_hvdc_end_caps(
    d::PowerSystems.TwoTerminalHVDC
) -> NamedTuple{(:from, :to), <:Tuple{Any, Any}}

Active-power cap at each end of a two-terminal HVDC line, system base: the line rating, tightened by the converter rating at that end. rating_from/rating_to default to 1e8, which leaves rating as the cap.

_initial_status(
    container::OptimizationContainer,
    _::Type{V<:PowerSystems.Device}
) -> Dict{String, Union{Float64, JuMP.VariableRef}}

Commitment of each V device before the first time step, from its DeviceStatus initial condition: the initialization solve's step-1 commitment when the model initializes, is_online(d) otherwise. Must-run thermal devices carry no value and are left out.

_input_row_exists(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    _::Type{T<:InfrastructureSystems.TimeSeriesData},
    owner_id::Int64,
    name::String
) -> Bool

Whether this store already has an input row for (owner_id, name) of exactly T. Scoped by type, not just (owner, name): a Deterministic input row (decision models) and a SingleTimeSeries input row (the emulation model) are different series derived from the same underlying source, and a shared bundle – the Emulator aggregator borrows a decision model's bundle when it has none of its own – can legitimately hold one of each for the same owner and name. Scoping the existence check by type keeps them from colliding under write-once.

_is_offline(_::PowerSystems.OfflineReserve) -> Bool

Whether a reserve is non-spinning: OfflineReserve vs everything else under AbstractReserve.

_is_offline_reserve(
    _::Type{<:PowerSystems.AbstractReserve}
) -> Bool

Whether a reserve type is an offline (non-spinning) product. Trait form of the OfflineReserve check used by the offline-capability machinery.

_loss_curve_value(
    curve::InfrastructureSystems.LossCurve,
    d::PowerSystems.Component,
    system_base::Float64
) -> InfrastructureSystems.ValueCurve

Unwrap a LossCurve to its plain ValueCurve, rescaled to system base regardless of the unit system it was authored in.

_max_abs(bounds) -> Any

Characteristic magnitude of a variable over its per-device bounds (max|x| across all devices). Used to turn a relative tolerance into an absolute one — see _resolve_tolerance.

_maybe_add_reactive_power_constraints!(
    container::OptimizationContainer,
    devices,
    model::DeviceModel{D<:PowerSystems.Device, F},
    network_model::NetworkModel,
    constraint_type::Type{<:InfrastructureSystems.Optimization.ConstraintType},
    variable_type::Type{<:InfrastructureSystems.Optimization.VariableType}
)

Variable-typed form: adds a reactive-power constraint built from a specific variable (the 6-arg add_constraints! form) on AC networks; no-op on active-power-only networks.

_maybe_add_reactive_power_constraints!(
    container::OptimizationContainer,
    devices,
    model::DeviceModel{D<:PowerSystems.Device, F},
    network_model::NetworkModel,
    constraint_type::Type{<:InfrastructureSystems.Optimization.ConstraintType}
)

Add a reactive-power-related constraint for a device on AC networks.

_maybe_add_reactive_power_variables!(
    container::OptimizationContainer,
    devices,
    model::DeviceModel{D<:PowerSystems.Device, F},
    network_model::NetworkModel,
    var_types
)

Add reactive-power variables for a device and register them in the system's ReactivePowerBalance expression. var_types is a tuple/iterable of VariableType subtypes; each is added via add_variables! and then linked into ReactivePowerBalance via add_to_expression!. The caller's device-specific add_to_expression! methods are responsible for the actual bus mapping and sign convention.

_offline_hourly_limit(
    container::OptimizationContainer,
    model::DeviceModel{V<:PowerSystems.Device},
    d::PowerSystems.Device,
    q_limit::Float64
) -> Vector

Available maximum of d in each time step for the offline band: mult[name, t] * ts_t from its ActivePowerTimeSeriesParameter, or q_limit (static pmax) in every step when model maps no such series or d has none.

_offline_reserve_awards(
    container::OptimizationContainer,
    model::DeviceModel,
    _::Type{V<:PowerSystems.Device}
) -> Vector{Tuple{String, Union{JuMP.Containers.DenseAxisArray, JuMP.Containers.SparseAxisArray}, Set{String}, Bool, Bool}}

Offline services on model that devices of type V contribute to, for the OfflineReserveBandConstraint builders: (service name, award variable, member names, offline_only, exclude_shutdown_step) per service; the flags are ServiceModel attributes.

_ordc_is_ts(s::PowerSystems.AbstractReserve) -> Bool

Whether a reserve's or group's ORDC curve is time-varying. Dispatches on the value-curve type (no isa).

_outage_shift_adjustments(
    modf_matrix::PowerNetworkMatrices.VirtualMODF,
    outage_spec::PowerNetworkMatrices.ContingencySpec,
    controlled_rows::Dict{Tuple{Int64, Int64}, Tuple{PowerOperationsModels.RepresentativeBranch, Vector{JuMP.VariableRef}}},
    time_steps::UnitRange{Int64}
) -> Vector{PowerOperationsModels.OutageShiftAdjustment}

The shift-injection adjustments of one registered contingency. On PTDF networks the nodal balance carries every arc's ±b·α pair, so a tripped shifter's pair must be taken back out before the MODF row multiplies the injections:

expr[m, k, t] += Σ_adj delta[t] · (MODF[m, k][from_pos] − MODF[m, k][to_pos])

A phase-controlled arc is a single circuit alone on its arc, so its modification is a full removal and -b · PhaseShifterAngle[t] is the whole injection it loses.

_parameter_rows(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    key::ParameterKey,
    extra_features::Dict{String}
) -> Vector{InfrastructureSystems.TimeSeriesMetadata}

The parameter-owner rows this store holds for key (further narrowed by extra_features, e.g. "model"). Shared by every parameter reader below.

_provenance(rep) -> Any

How the arc this branch occupies came to exist. Read off the entry rather than stored: B is concrete per specialization, so this resolves statically and costs nothing.

PNM used to hand out a Symbol naming the internal map an entry came from, and this struct kept it alongside the entry that symbol was used to fetch. The entry answers the question.

_quadratic_converter_loss_expr(
    a::Float64,
    b::Float64,
    c::Float64,
    i_sq_t::JuMP.AffExpr,
    abs_i_t::JuMP.VariableRef
) -> JuMP.AffExpr

_quadratic_converter_loss_expr(a, b, c, i_sq_t, abs_i_t)

Build the per-timestep converter loss expression a·I² + b·|I| + c.

In MILP formulations the isqt is still an AffExpr.

The iszero guards avoid adding 0s to the JuMP expression which might slightly hurt the solver.

_rate_rhs_squared(rating) -> Any

Squared apparent-power rate-limit RHS: rating^2.

The single source of truth for the right-hand side of p² + q² ≤ rating² apparent-power constraints (and cr² + ci² ≤ c_rating² current-magnitude limits). Callers pass the already-resolved rating value:

• static path: a Float64 rating (e.g. from branch_rating) → hand-check 2.0 → 4.0.
• time-series path: the param * mult product (rating_factor · rating), an apparent-power value that must be squared to match the static rating² RHS.

Squaring here — rather than at each @constraint site — is the point: the historical shipped-bug class is a bare rating (not rating²) on an apparent-power constraint. Keeping the exponent in one function makes every rate limit route through the same math.

_representative_branch(
    network_model::NetworkModel,
    ::Type{T<:PowerSystems.ACTransmission},
    name::AbstractString;
    number_to_name
) -> PowerOperationsModels.RepresentativeBranch

The RepresentativeBranch carrying component name of type T. A component absorbed into a reduction is redirected to the entry that represents it.

_representative_branches(
    network_model::NetworkModel,
    ::Type{T<:PowerSystems.ACTransmission},
    ::Type{C<:InfrastructureSystems.Optimization.ConstraintType};
    number_to_name
) -> Vector{PowerOperationsModels.RepresentativeBranch}

One RepresentativeBranch per reduced arc of T not already claimed for the constraint family C, in the axis order the constraint containers must be sized with.

Pass number_to_name (from _retained_number_to_name) whenever the builder reads endpoint bus names; builders with no sys in scope may omit it.

_reserve_direction(
    _::PowerSystems.Reserve{T<:PowerSystems.ReserveDirection}
) -> Type{T} where T<:PowerSystems.ReserveDirection

Direction of a reserve. OfflineReserve (non-spinning) has no direction type parameter and is upward-only in every US market, so it maps to PSY.ReserveUp.

_reset_reduced_branch_tracker!(
    model::NetworkModel,
    number_of_steps::Int64
)

Install a fresh branch-reduction tracker on model sized for number_of_steps. The tracker lives behind IOM.AbstractBranchReductionTracker and is nothing until network model instantiation reaches this point.

_resolve_monitored_branches(
    device_model::DeviceModel,
    network_model::NetworkModel
) -> Vector{Pair{Int64, Vector{PowerOperationsModels.RepresentativeBranch}}}

For each outage in device_model.outages, resolve every monitored component (across every monitored type) to the RepresentativeBranch of its arc in the active reduction graph. Duplicate arcs within an outage are collapsed per-type. Outages sorted by UUID for deterministic axes.

_resolve_tolerance(
    absolute,
    relative,
    scale::Float64
) -> Float64

Resolve the absolute bilinear/quadratic approximation tolerance from the absolute and relative attribute values. A relative tolerance is scaled to absolute by the characteristic product/term magnitude scale (τ_abs = relative · scale). Exactly one of absolute/relative must be set (the other nothing); it is an error for both or neither to be set. The resolved tolerance must be finite and > 0.

_scheduled_power_variable(
    _::Type{<:AbstractDeviceFormulation}
) -> Type{PowerAboveMinimumVariable}

The variable a device formulation schedules power through. Most formulations schedule ActivePowerVariable directly; compact formulations schedule PowerAboveMinimumVariable instead, so a SemiContinuousFeedforward attached to one of those must be checked against PowerAboveMinimumVariable, not the default.

_scheduled_power_variable(
    _::Type{<:ThermalCompactDispatch}
) -> Type{PowerAboveMinimumVariable}

Compact formulations schedule PowerAboveMinimumVariable rather than ActivePowerVariable, so has_semicontinuous_feedforward must check a SemiContinuousFeedforward against that variable instead of the default.

_service_container_meta(
    service::PowerSystems.Service
) -> String

Meta string identifying one service inside the device-side reserve containers (ancillary-service variables, TotalReserveOffering expressions, coverage constraints). Always derive it from the service INSTANCE: a ServiceModel's type parameter can be partially applied (OnlineReserve{ReserveUp}, a UnionAll) while the containers are written with the fully concrete instance type, and the two spellings do not match.

_service_model_for(
    device_model::DeviceModel,
    service::PowerSystems.Service
) -> Union{Nothing, ServiceModel}

The ServiceModel in device_model that covers service, or nothing when the device model registers no model for that service's type.

Mirrors the type match the hydro served-reserve wiring already performs: a ServiceModel's component type can be partially applied (OnlineReserve{ReserveUp}, a UnionAll), so the comparison is typeof(service) <: get_component_type(service_model).

_source_irreducible_buses(
    reduction::PowerNetworkMatrices.NetworkReductionData
) -> Vector{Int64}

The user-supplied irreducible bus set an already-applied reduction was built with.

_terminal_bus(
    _::Type{FlowActivePowerFromToVariable},
    arc
) -> PowerSystems.Component

Select the bus of arc that a directional flow variable lands on: from-side variables (FromTo / ReceivedFrom / VSC From) resolve to the from-bus, to-side variables (ToFrom / ReceivedTo / VSC To) to the to-bus.

The terminal is fixed by the variable type, so it is resolved by dispatch rather than passed as an argument. One method per variable type (rather than a 5-member Union per side, which exceeds the union-splitting threshold).

_validate_reserve_provision!(
    template::PowerOperationsProblemTemplate
)

Reject a contributing device whose formulation cannot bound a reserve award (supports_reserve_provision); such a device would sell capacity limited only by its nameplate rating, uncoupled from its dispatch and from its other services.

_warn_no_hvdc_reactive_capability(devices)

Warn when a two-terminal HVDC whose reactive flows are wired into the nodal ReactivePowerBalance cannot carry any reactive power. HVDCTwoTerminalLossless bounds FlowReactivePower{FromTo,ToFrom}Variable by the device's reactive power limits, and PSY.TwoTerminalVSCLine/PSY.TwoTerminalLCCLine default both limit pairs to (min = 0.0, max = 0.0), which pins the terminal's reactive flow to zero. That is valid data (the converter offers no reactive support), so this is a warning and not an error, but it can silently make an AC model infeasible.

_window_timestamps(
    windows::PowerOperationsModels.RunWindows
) -> Vector

The per-step timestamps the first window in windows covers.

_write_input!(
    _::PowerOperationsModels.ParameterTimeSeriesStore,
    _::Type{<:InfrastructureSystems.TimeSeriesData},
    d::PowerOperationsModels.InputSeriesDescriptor,
    _::JuMP.Containers.DenseAxisArray{Float64, 3, Ax, L} where {Ax, L<:Tuple{JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup}},
    _::PowerOperationsModels.RunWindows
)

A 3-D parameter has no input-series counterpart in this store; warn and skip it.

_write_outputs_bundle!(
    model,
    sys::PowerSystems.System,
    sys_dir::AbstractString
)

Build model's outputs-system bundle at sys_dir and write it, unless one is already there — re-solving into an existing directory must not rewrite the bundle.

add_cost_expressions!(
    container::OptimizationContainer,
    devices::Array{D<:PowerSystems.Component, 1},
    model::DeviceModel{D<:PowerSystems.Component, W<:AbstractDeviceFormulation}
)

Default cost-expression setup: register only ProductionCostExpression.

add_cost_expressions!(
    container::OptimizationContainer,
    devices::Array{D<:PowerSystems.RenewableGen, 1},
    model::DeviceModel{D<:PowerSystems.RenewableGen, W<:PowerOperationsModels.AbstractRenewableDispatchFormulation}
)

Renewable dispatch formulations track production cost, fixed cost, VOM cost, and curtailment cost. CurtailmentCostExpression is a direct CostExpressions subtype (not a ConstituentCostExpression), so it does not propagate into ProductionCostExpression — curtailment is reported standalone.

add_cost_expressions!(
    container::OptimizationContainer,
    devices::Array{D<:PowerSystems.ThermalGen, 1},
    model::DeviceModel{D<:PowerSystems.ThermalGen, W<:AbstractThermalFormulation}
)

Thermal generators get the full constituent decomposition. Constituent expressions auto-propagate into ProductionCostExpression (see IOM _propagate_to_production_cost!), so we register the aggregate as well as the parts. FuelConsumptionExpression is added only when at least one device has a FuelCurve, mirroring the existing FuelConsumption specialization.

add_curtailment_cost!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.VariableType},
    devices::Array{V<:PowerSystems.RenewableGen, 1},
    _::Type{U<:AbstractDeviceFormulation}
)

Iterate the device set and route each renewable's curtailment_cost into CurtailmentCostExpression. Devices whose operation cost has no curtailment_cost field, or where the field is nothing, are skipped.

add_expressions!(
    container::OptimizationContainer,
    _::Type{BThetaBranchFlow},
    sys::PowerSystems.System,
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranch},
    network_model::NetworkModel{DCPNetworkModel}
)

Add the B-θ branch-flow expression for ACBranch StaticBranch under DCPNetworkModel:

BThetaBranchFlow = b * (va_fr - va_to - shift)

with the DC b/shift pair described on the NetworkFlowConstraint builder above, so the b·shift offset matches PNM's arc_dc_shift_injection.

add_expressions!(
    container::OptimizationContainer,
    _::Type{T<:FuelConsumptionExpression},
    devices::Array{D<:PowerSystems.Component, 1},
    model::DeviceModel{D<:PowerSystems.Component, W<:AbstractDeviceFormulation}
)

Specialized implementation for FuelConsumptionExpression that checks for fuel curves.

add_expressions!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    devices::Array{D<:PowerSystems.Component, 1},
    model::DeviceModel{D<:PowerSystems.Component, W<:AbstractDeviceFormulation}
)

Generic implementation to add expression containers for devices.

add_expressions!(
    container::OptimizationContainer,
    _::Type{T<:CostExpressions},
    services::Array{D<:PowerSystems.Component, 1},
    model::ServiceModel{V<:PowerSystems.AbstractReserve, W<:AbstractReservesFormulation}
)

Cost-expression container for reserve services, e.g. ProductionCostExpression for an operating reserve demand curve: one dense (service_name, time) container per service type, the same shape as the device ProductionCostExpression. Read and written by add_to_expression!(container, ::CostExpressions, cost, ::AbstractReserve, t).

add_expressions!(
    container::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    devices::Array{D<:PowerSystems.Component, 1},
    model::ServiceModel{V<:PowerSystems.AbstractReserve, W<:AbstractReservesFormulation}
)

Generic implementation for service models with reserves.

add_feedforward_constraints!(
    container::OptimizationContainer,
    _::DeviceModel,
    devices::Array{T<:PowerSystems.Component, 1},
    ff::FixValueFeedforward
)

Pins a variable in this model to a quantity read from the system state.

variable[name, t] == param[name, t] * multiplier[name, t]

NOTE (deviation from PowerSimulations): PSI applies this with JuMP.fix. That only works when the parameter container holds Float64; under built_for_recurrent_solves — the only mode in which a feedforward is ever used — the container holds JuMP parameters (JuMP.VariableRef), and JuMP.fix rejects the resulting AffExpr. PSI never hits this because it exercises FixValueFeedforward only on services, never on a DeviceModel. An equality constraint is what PSI's own docstring describes, works in both storage modes, and tracks the parameter automatically when it is repopulated.

add_feedforward_constraints!(
    container::OptimizationContainer,
    _::DeviceModel{T<:PowerSystems.Storage, U<:PowerOperationsModels.AbstractStorageFormulation},
    devices::Array{T<:PowerSystems.Storage, 1},
    ff::EnergyTargetFeedforward
)

Constructs a constraint holding a storage energy variable to a minimum target read from the system state at target_period, relaxed by a StorageEnergyShortageVariable slack penalized in the objective at penalty_cost. The slack exists only at the last time step, so target_period must be the horizon end.

variable[name, target_period] + slack[name, target_period] >= param[name, target_period] * multiplier[name, target_period]

add_feedforward_constraints!(
    container::OptimizationContainer,
    model::DeviceModel{T<:PowerSystems.HydroGen, U<:PowerOperationsModels.AbstractHydroFormulation},
    devices::Array{T<:PowerSystems.HydroGen, 1},
    _::HydroUsageLimitFeedforward
)

Constructs a constraint bounding a hydro unit's cumulative active power usage, summed over the full model horizon, to a hydro energy usage limit read from the system state.

fraction_of_hour * sum(power[name, :]) <= param[name, end]

add_feedforward_constraints!(
    container::OptimizationContainer,
    _::DeviceModel{T<:PowerSystems.Component, U<:AbstractDeviceFormulation},
    devices::Array{T<:PowerSystems.Component, 1},
    ff::LowerBoundFeedforward
)

Constructs a parameterized lower bound constraint that holds the affected variable to a quantity read from the system state.

variable[name, t] >= param[name, t] * multiplier[name, t]

With add_slacks = true the bound is relaxed by a non-negative slack penalized at BALANCE_SLACK_COST:

variable[name, t] + slack[name, t] >= param[name, t] * multiplier[name, t]

add_feedforward_constraints!(
    container::OptimizationContainer,
    _::DeviceModel{T<:PowerSystems.HydroReservoir, U<:AbstractDeviceFormulation},
    devices::Array{T<:PowerSystems.HydroReservoir, 1},
    ff::ReservoirTargetFeedforward
)

Constructs a constraint holding a reservoir variable to a minimum target read from the system state at target_period, relaxed by a HydroEnergyShortageVariable slack penalized in the objective at penalty_cost.

variable[name, target_period] + slack[name, target_period] >= param[name, target_period] * multiplier[name, target_period]

add_feedforward_constraints!(
    container::OptimizationContainer,
    _::DeviceModel{T<:PowerSystems.Component, U<:AbstractDeviceFormulation},
    devices::Array{T<:PowerSystems.Component, 1},
    ff::Union{EnergyLimitFeedforward, ReservoirLimitFeedforward}
)

Constructs a constraint bounding the sum of a variable over consecutive blocks of number_of_periods time steps to a per-block limit read from the system state. The reservoir and storage variants differ only in the parameter each reads.

sum(variable[name, t] for t in block) <= sum(param[name, t] * multiplier[name, t] for t in block)

add_feedforward_constraints!(
    container::OptimizationContainer,
    _::DeviceModel{T<:PowerSystems.Component, U<:AbstractDeviceFormulation},
    devices::Array{T<:PowerSystems.Component, 1},
    ff::UpperBoundFeedforward
)

Constructs a parameterized upper bound constraint that holds the affected variable to a quantity read from the system state.

variable[name, t] <= param[name, t] * multiplier[name, t]

With add_slacks = true the bound is relaxed by a non-negative slack penalized at BALANCE_SLACK_COST:

variable[name, t] - slack[name, t] <= param[name, t] * multiplier[name, t]

add_feedforward_constraints!(
    container::OptimizationContainer,
    _::DeviceModel{T<:PowerSystems.HydroReservoir, U<:AbstractDeviceFormulation},
    devices::Array{T<:PowerSystems.HydroReservoir, 1},
    _::WaterLevelBudgetFeedforward
)

Constructs a constraint that bounds a reservoir's cumulative outgoing water flow, summed over the full model horizon, to the water usage budget read from the system state.

sum(water_out[name, :]) <= sum(param[name, :])

add_parameterized_rating_constraints!(
    container::OptimizationContainer,
    con_ub::JuMP.Containers.DenseAxisArray,
    con_lb::JuMP.Containers.DenseAxisArray,
    flow::JuMP.Containers.DenseAxisArray,
    name::AbstractString,
    param,
    mult::JuMP.Containers.DenseAxisArray
)

Fill a symmetric, time-varying rating bound into pre-created lb/ub constraint containers, for a single branch name:

flow[name, t] <=  rating[t]
flow[name, t] >= -rating[t]

with rating[t] = param[t] * mult[name, t] (a parameterized rating that varies per time step). This is the parameterized-RHS counterpart to the scalar-limit add_slacked_range_constraints!: the RHS is a time series, so it is not covered by the scalar range helper. The lb/ub containers must already exist (the static path creates them over all branch names); this only fills the entries for name. The slack-relaxed variant takes the slack containers as trailing arguments.

add_reserve_range_constraints!(
    container::OptimizationContainer,
    _::Type{T<:InputActivePowerVariableLimitsConstraint},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::Array{V<:PowerSystems.Component, 1},
    model::DeviceModel{V<:PowerSystems.Component, W<:AbstractDeviceFormulation},
    _::Type{X<:AbstractNetworkModel}
)

Constructs min/max range constraint from device variable and reservation decision variable.

varcts[name, t] <= limits.max * (1 - varbin[name, t])

varcts[name, t] >= limits.min * (1 - varbin[name, t])

where limits in constraint_infos.

LaTeX

$0 \leq x^{cts} \leq limits^{max} (1 - x^{bin}), \text{ for } limits^{min} = 0$

$limits^{min} (1 - x^{bin}) \leq x^{cts} \leq limits^{max} (1 - x^{bin}), \text{ otherwise }$

add_reserve_range_constraints!(
    container::OptimizationContainer,
    _::Type{T<:Union{ActivePowerVariableLimitsConstraint, PowerOperationsModels.OutputActivePowerVariableLimitsConstraint, PowerOperationsModels.ReactivePowerVariableLimitsConstraint}},
    _::Type{U<:InfrastructureSystems.Optimization.ExpressionType},
    devices::Array{W<:PowerSystems.Component, 1},
    model::DeviceModel{W<:PowerSystems.Component, X<:AbstractDeviceFormulation},
    _::Type{Y<:AbstractNetworkModel}
)

Constructs min/max range constraint from device variable and reservation decision variable.

varcts[name, t] <= limits.max * varbin[name, t]

varcts[name, t] >= limits.min * varbin[name, t]

where limits in constraint_infos.

LaTeX

$limits^{min} x^{bin} \leq x^{cts} \leq limits^{max} x^{bin},$

add_reserve_range_constraints!(
    container::OptimizationContainer,
    _::Type{T<:Union{ActivePowerVariableLimitsConstraint, PowerOperationsModels.OutputActivePowerVariableLimitsConstraint, PowerOperationsModels.ReactivePowerVariableLimitsConstraint}},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::Array{W<:PowerSystems.Component, 1},
    model::DeviceModel{W<:PowerSystems.Component, X<:AbstractDeviceFormulation},
    _::Type{Y<:AbstractNetworkModel}
)

Constructs min/max range constraint from device variable and reservation decision variable.

varcts[name, t] <= limits.max * varbin[name, t]

varcts[name, t] >= limits.min * varbin[name, t]

where limits in constraint_infos.

LaTeX

$limits^{min} x^{bin} \leq x^{cts} \leq limits^{max} x^{bin},$

check_activeservice_variables(
    container::OptimizationContainer,
    contributing_services::Array{T<:PowerSystems.Service, 1}
)

This function checks if the variables for reserves were created

close_parameter_store!(
    store::PowerOperationsModels.ParameterTimeSeriesStore
)

Close the InfraStore handle store owns.

construct_lhs_parameters!(
    container::OptimizationContainer,
    template::PowerOperationsProblemTemplate,
    sys::PowerSystems.System
)

Create the left-hand-side parameter containers every service model declares, before device argument construction: devices write a service's coefficients during their own argument stage, which runs before the service's.

copy_cost_time_series!(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    sys::PowerSystems.System,
    windows::PowerOperationsModels.RunWindows
) -> Dict{Int64, Int64}

Copy every time series a System component's operation cost holds into store, under that component's own id and type, and return the map from each series' original association_id to the association id it was written under.

Not derived from parameter arrays: start-up costs are 3-tuples, offer curves split into slope/breakpoint arrays, and re-deriving a cost series from a parameter array risks a unit mismatch. This copies the System's own series instead: statics verbatim, forecasts re-windowed onto the run grid windows (or copied verbatim too, on a horizon too short to re-window).

deployed_fraction_values(
    container::OptimizationContainer,
    device_model::DeviceModel,
    service::PowerSystems.AbstractReserve
) -> Vector{Float64}

Per-time-step deployed fraction for service as a reserve covered by device_model: deployed_fraction * profile[t] read from the DeployedFractionParameter container when the reserve carries a profile, otherwise the scalar deployed_fraction at every step.

The values are written into constraints as fixed coefficients. A model holding a profile is rebuilt every simulation step, so each build reads the refreshed container.

generate_formulation_combinations(

) -> Dict{String, Vector{Any}}
generate_formulation_combinations(
    sys
) -> Dict{String, Vector{Any}}

Generate valid combinations of devicetype/formulation and servicetype/formulation. Return vectors of dictionaries with Julia types.

Arguments

• sys::Union{Nothing, System}: If set, only include component types present in the system.

get_branch_argument_constraint_axis(
    branch_catalog::PowerNetworkMatrices.BranchCatalog,
    reduced_branch_tracker::PowerOperationsModels.BranchReductionOptimizationTracker,
    _::Array{T<:InfrastructureSystems.InfrastructureSystemsComponent, 1},
    _::Type{U<:InfrastructureSystems.Optimization.ConstraintType}
) -> Union{Vector{Any}, Vector{String}}

Representative branch-name axis for a constraint family U over components of type T under an active network reduction.

Every member of a reduced arc (series segments, parallel groups, across branch types) shares one set of flow variables, so the arc's physics must be constrained exactly once. This returns one branch name per reduced arc of T not already claimed for U, recording the claim in reduced_branch_tracker so the guarantee holds across separate construct_device! calls. Constraint containers must be sized with the returned names.

get_branch_with_time_series(
    branch::InfrastructureSystems.InfrastructureSystemsComponent,
    _::Type{V<:InfrastructureSystems.TimeSeriesData},
    ts_name::String
) -> Any

Find the first device within a reduction entry that has the given time series. Delegates to PNM, which handles BranchesParallel, BranchesSeries, ThreeWindingTransformerCircuit, and plain ACTransmission entries.

get_power_flow_model(
    ev::PowerOperationsModels.PowerFlowEvaluator
) -> Any

Return the wrapped power-flow model from a PowerFlowEvaluator.

get_ptdf_orientation_sign(
    branch_catalog::PowerNetworkMatrices.BranchCatalog,
    _::Type{T<:PowerSystems.ACTransmission},
    name::AbstractString
) -> Float64

Sign relating a branch's native from→to flow to the PTDF column used for its PTDFBranchFlow. Returns -1.0 only for a series-reduction member whose native orientation is :ToFrom relative to the merged path; +1.0 otherwise. name may be a reduced-arc entry name or the name of a component absorbed into one.

get_startup_shutdown_limits(
    device,
    _::Type{ActivePowerVariableLimitsConstraint},
    _::Type{<:PowerOperationsModels.AbstractCompactUnitCommitment}
) -> @NamedTuple{startup::Float64, shutdown::Float64}

Startup shutdown limits for Compact Unit Commitment

get_startup_shutdown_limits(
    device::PowerSystems.ThermalMultiStart,
    _::Type{ActivePowerVariableLimitsConstraint},
    _::Type{ThermalMultiStartUnitCommitment}
) -> @NamedTuple{startup::Float64, shutdown::Float64}

Startup and shutdown active power limits for Compact Unit Commitment

has_parameter_rows(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    key::ParameterKey;
    extra_features
) -> Bool

Whether this store holds any parameter row for key (narrowed by extra_features).

has_semicontinuous_feedforward(model::DeviceModel) -> Bool

Whether model carries any SemiContinuousFeedforward at all, regardless of which variables it affects. The commitment status then arrives as a variable-valued parameter, so formulations must not also build a float-valued OnStatusParameter for it.

has_semicontinuous_feedforward(
    model::DeviceModel,
    _::Type{T<:Union{InfrastructureSystems.Optimization.ExpressionType, InfrastructureSystems.Optimization.VariableType}}
) -> Bool

Whether model carries a SemiContinuousFeedforward whose affected values include T.

Device formulations use this to suppress their own range constraints: when the commitment status arrives as a parameter read from the system state, the semicontinuous feedforward constraints replace the formulation's native bounds. Adding both would double-constrain the variable.

has_waterbudget_feedforward(model::DeviceModel) -> Bool

Whether model carries a WaterLevelBudgetFeedforward.

initial_condition_default(
    _::InfrastructureSystems.Optimization.InitialConditionType,
    _::InfrastructureSystems.InfrastructureSystemsComponent,
    _::Union{AbstractDeviceFormulation, AbstractServiceFormulation}
) -> Float64

Extension point for downstream packages to define default values for initial conditions.

initial_condition_variable(
    ic_type::InfrastructureSystems.Optimization.InitialConditionType,
    component::PowerSystems.Component,
    formulation::Union{AbstractDeviceFormulation, AbstractServiceFormulation}
) -> EnergyVariable

Extension point for downstream packages to define how to map initial condition types to variable types for specific device formulations.

This function should be implemented by packages like PowerOperationsModels to specify which variable type corresponds to a given initial condition type for a particular device and formulation.

Arguments

• ic_type: An instance of an InitialConditionType (e.g., DeviceStatus(), DevicePower())
• component: The device component
• formulation: An instance of the device formulation

Returns

A VariableType instance that corresponds to this initial condition.

is_input_parameter(
    _::ParameterKey,
    pc::InfrastructureOptimizationModels.ParameterContainer
) -> Bool

Whether key's realized values are a component input series the bundle recasts. IOM only ever pairs TimeSeriesAttributes with a TimeSeriesParameter key, so the attributes check alone decides it.

is_online(d::PowerSystems.Component) -> Union{Missing, Bool}

is_online(d) -> Bool

Whether d is on at the start of the horizon: its status is ONLINE or STARTUP. The initial conditions and the OnVariable warm start read this instead of the raw enum.

list_input_series(
    store::PowerOperationsModels.ParameterTimeSeriesStore
) -> Vector{InfrastructureSystems.TimeSeriesMetadata}

Every input row this store holds, any owner — the rows carrying INPUT_ROW_FEATURES.

make_system_expressions!(
    container::OptimizationContainer,
    subnetworks::Dict{Int64, Set{Int64}},
    _::Vector{Int64},
    _::Type{<:AbstractActivePowerModel},
    bus_reduction_map::Dict{Int64, Set{Int64}}
)

Fallback for active-power-only models (DCP, NFA, etc.). Creates only ActivePowerBalance on ACBus (no reactive power).

make_system_expressions!(
    container::OptimizationContainer,
    subnetworks::Dict{Int64, Set{Int64}},
    _::Vector{Int64},
    _::Type{<:AbstractNetworkModel},
    bus_reduction_map::Dict{Int64, Set{Int64}}
)

Generic fallback for full power flow models (ACP, ACR, etc.). Creates both ActivePowerBalance and ReactivePowerBalance on ACBus.

network_support(
    _::Type{<:AbstractDeviceFormulation}
) -> PowerOperationsModels.AllNetworksExceptLPACC

network_support(::Type{<:AbstractDeviceFormulation}) -> NetworkSupport

Which network models a device formulation can be constructed under. Defaults to AllNetworks; a formulation whose construct_device! is bound to a narrower network type must declare it here or it fails deep inside build! instead of at template validation.

offline_reserve_in_range_ub(
    _::Type{<:AbstractDeviceFormulation}
) -> Bool

Whether a device formulation folds offline-reserve awards into the commitment-gated range expression (ActivePowerRangeExpressionUB). Defaults to true (the award consumes gated headroom, so an OFF unit cannot supply). Commitment formulations that provide offline capability through OfflineReserveBandConstraint return false.

onvar_cost(
    container::OptimizationContainer,
    cost::PowerSystems.ThermalGenerationCost,
    _::Type{OnVariable},
    d::PowerSystems.ThermalGen,
    _::Type{<:AbstractThermalFormulation},
    t::Int64
) -> Any

Theoretical Cost at power output zero. Mathematically is the intercept with the y-axis

open_parameter_store(
    path::AbstractString
) -> PowerOperationsModels.ParameterTimeSeriesStore

Reopen a persisted parameter store with its catalog, writable in place, so later write_parameter_* calls land directly in the on-disk .h5/.sqlite pair with no re-persist. IS.open_infrastore_store opens its artifacts in place, writable, by default (read_only = false, catalog = :attached); the copy-to-a-temp-location path lives in a different function (open_deserialized_infrastore_store), used only for deserialized System artifacts, and this store never goes through it.

parameter_association_rows(
    store::PowerOperationsModels.ParameterTimeSeriesStore
) -> Any

The association rows the System document declares: every row whose owner is a real component, not the synthetic parameter-array owner. Parameter arrays and windows are the only series written under PARAMETER_ROW_OWNER_ID; every document-declared series (cost copies, input rows) is written under its owning component's own id. Exported from the store that wrote the arrays, so each row's uri names an array the store genuinely holds, and each association_id is the one the catalog will answer for on load.

parameter_slice_labels(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    key::ParameterKey;
    extra_features
) -> Vector{String}

The distinct "axis2" feature values among this store's rows for key (further narrowed by extra_features, e.g. "model"), sorted for a deterministic order. Empty for a 2-D parameter, which carries no "axis2" feature on any of its rows – a caller merging by slice treats that as "merge once, with no axis2 filter" rather than iterating zero times.

parameter_store_from_model(
    model
) -> Tuple{PowerOperationsModels.ParameterTimeSeriesStore, Dict{Int64, Int64}}

Build a fresh ParameterTimeSeriesStore from model's realized parameters and its System's cost time series re-windowed to the run, plus every time-series parameter recast as component-owned input series, ready for write_outputs_system_bundle!.

Writes no parameter arrays, only warns, on a single-point time axis (e.g. horizon = Dates.Hour(1)): IS.SingleTimeSeries, NonSequentialTimeSeries, and Forecast all require at least two points at the InfraStore layer (R32: not something this store patches around). The model's realized parameters stay readable through OptimizationProblemOutputs, only the exported outputs bundle loses them.

parameter_store_of(
    sys::PowerSystems.System
) -> PowerOperationsModels.ParameterTimeSeriesStore

A borrowed view of a System's own already-open store – for a caller that already has this bundle's System loaded (e.g. via PSY.from_file(...; time_series_read_only = true)) and wants to read its realized parameters without opening a second handle to the same sidecar file (InfraStore allows only one open handle per file per process).

The caller must not close_parameter_store! the result: the underlying store is owned by sys's own time series manager, which opened it and will close it.

Every PowerFlowAuxVariableType indexed by components of type C (branch or bus). Which of these a given evaluator provides is decided by _pf_provides_aux_var in PowerFlowsExt.

A tuple, not a Vector, so callers' map keeps each Type{T} concrete. A new PowerFlowAuxVariableType goes here and gets _pf_provides_aux_var methods; test_power_flow_in_the_loop.jl fails if one is missing.

process_import_export_parameters!(
    container::OptimizationContainer,
    devices_in,
    model::DeviceModel
)

Validate ImportExportCosts and add the appropriate parameters

process_market_bid_parameters!(
    container::OptimizationContainer,
    devices_in,
    model::DeviceModel
)
process_market_bid_parameters!(
    container::OptimizationContainer,
    devices_in,
    model::DeviceModel,
    incremental::Bool
)
process_market_bid_parameters!(
    container::OptimizationContainer,
    devices_in,
    model::DeviceModel,
    incremental::Bool,
    decremental::Bool
)

Validate MarketBidCosts and add the appropriate parameters

process_stepwise_cost_reserve_parameters!(
    container::OptimizationContainer,
    model::ServiceModel,
    services::Array{D<:PowerSystems.AbstractReserve, 1}
)

Add the decremental piecewise slope/breakpoint cost parameters for the time-varying operating reserve demand curves in services (those whose variable curve is time-series-backed). Static ORDCs and fixed-requirement reserves carry no such parameters and are skipped.

read_input_time_series(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    md::InfrastructureSystems.TimeSeriesMetadata
) -> Any

The series behind one input row.

read_parameter_array(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    key::ParameterKey;
    extra_features
) -> Dict{String, TimeSeries.TimeArray}

Read back every parameter array row this store holds for key, keyed by its axis-1 label.

read_parameter_windows(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    key::ParameterKey;
    extra_features
) -> Dict{String, Dict{Dates.DateTime, Vector{Float64}}}

Read back every parameter window row this store holds for key, keyed by its axis-1 label and then by each window's initial time.

reserve_scale_values(
    _::Type{UnscaledReserve},
    container::OptimizationContainer,
    _::DeviceModel,
    _::PowerSystems.Service
) -> Vector{Float64}

Per-time-step scale of a reserve award per its ReserveScale.

run_windows(model) -> PowerOperationsModels.RunWindows

One window at the model's initial time. A standalone model has no execution interval; when its Settings leave it unset the horizon stands in, which keeps a single window self-consistent.

search_for_reduced_branch_expression!(
    tracker::PowerOperationsModels.BranchReductionOptimizationTracker,
    arc_tuple::Tuple{Int64, Int64},
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType}
) -> Bool

Register the wiring of arc_tuple's shared variable of type U into the balance expression of type T. Returns true when the arc was already wired by a previous entry (same or different branch type) — the caller must skip it to avoid double-counting the shared variable in the balance.

search_for_reduced_branch_parameter!(
    tracker::PowerOperationsModels.BranchReductionOptimizationTracker,
    arc_tuple::Tuple{Int64, Int64},
    _::Type{T<:InfrastructureSystems.Optimization.ParameterType}
) -> Tuple{Bool, Vector{Union{Float64, JuMP.VariableRef}}}

Look up (or register) the tracker entry for arc_tuple and ParameterType T. Stores Float64 values when built_for_recurrent_solves is false, or JuMP.VariableRef objects (JuMP parameters) when true, so that shared arcs across different branch types reuse the same underlying parameter object. Returns (has_entry, tracker_vector).

search_for_reduced_branch_variable!(
    tracker::PowerOperationsModels.BranchReductionOptimizationTracker,
    arc_tuple::Tuple{Int64, Int64},
    _::Type{T<:InfrastructureSystems.Optimization.VariableType}
) -> Tuple{Bool, Vector{JuMP.VariableRef}}

Look up (or register) the tracker entry for arc_tuple and VariableType T. Returns (has_entry, tracker_vector) where has_entry is true when the arc was already registered by a previous call (i.e. a parallel/reduced branch of a different device type already created the variable).

seed_reserve_range_expressions!(
    _::OptimizationContainer,
    _::PowerSystems.System,
    _::ServiceModel,
    _::Dict{Symbol, DeviceModel}
)

Create each contributing device type's reserve range expression container, sized over that device model's full available component set.

Runs once per service model, before any service wires awards in, so services of the same type with contributor sets that do not nest all index an axis that holds their devices.

serialize_formulation_combinations(

) -> Dict{String, Vector{Any}}
serialize_formulation_combinations(
    sys
) -> Dict{String, Vector{Any}}

Generate valid combinations of devicetype/formulation and servicetype/formulation. Return vectors of dictionaries with Julia types encoded as strings.

Arguments

• sys::Union{Nothing, System}: If set, only include component types present in the system.

slack_spec(
    _::Type{<:AbstractDeviceFormulation},
    _::Type{<:AbstractNetworkModel}
) -> PowerOperationsModels.EqualityPairSlacks{8}

slack_spec(::Type{<:AbstractDeviceFormulation}, ::Type{<:AbstractNetworkModel}) -> BranchSlackSpec

The flow-slack machinery a branch formulation builds under a network formulation. Defaults to NoBranchSlacks: a pair with no declared machinery rejects use_slacks = true at template validation. One method per (formulation, network family) pair that genuinely builds slacks — extend the table the same way network_support is extended, never with a Union alias enumerating formulations.

supports_flow_slacks(
    _::Type{F<:AbstractDeviceFormulation},
    _::Type{N<:AbstractNetworkModel}
) -> Bool

supports_flow_slacks(::Type{<:AbstractDeviceFormulation}, ::Type{<:AbstractNetworkModel}) -> Bool

Whether a branch formulation's flow slacks have something to attach to under this network model: a flow-defining equality (Ohm's law / DC angle relation), a rating constraint row, or a quadratic limit the slack can relax. Derived from slack_spec — a pair supports slacks exactly when its spec declares machinery, so the gate cannot drift from what the constructors build. Extend by declaring a slack_spec method, not by overriding this function.

supports_reserve_provision(
    _::Type{<:AbstractDeviceFormulation}
) -> Bool

Whether a device formulation can provide reserve. Qualifying requires making the device's output a decision and putting that decision in the objective: the range expression ties the award to the dispatch, and objective participation is what prices the capacity.

The load family defaults to false and opts in per formulation in electric_loads.jl; generation and storage keep the permissive default.

transfer_initial_conditions!(
    target::InfrastructureOptimizationModels.AbstractOptimizationModel,
    source::InfrastructureOptimizationModels.AbstractOptimizationModel
)

Transfer initial conditions from a solved source model to a target model.

Reads the last-timestep variable values from the source and sets them as initial conditions on the target. Uses the IC-type-to-variable-type mapping to determine which variable to read for each IC.

PSI handles this same thing by adding another layer of abstractions, using SimulationState and reading/writing to ModelStore. But it's useful to be able to do the same thing here in POM without those abstractions, for testing purposes.

write_formulation_combinations(filename::AbstractString)
write_formulation_combinations(
    filename::AbstractString,
    sys
)

Generate valid combinations of devicetype/formulation and servicetype/formulation and write the output to a JSON file.

Arguments

• sys::Union{Nothing, System}: If set, only include component types present in the system.

write_input_forecast_row!(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    owner_id::Int64,
    owner_type::String,
    name::String,
    data::AbstractDict{Dates.DateTime, <:AbstractVector},
    resolution::Dates.Period,
    interval::Dates.Period
) -> Bool

Add one component-owned Deterministic input row, declared in the document. Returns false without writing when this (owner, name) already has a Deterministic input row: two parameters may read the same series, and a re-merge may see rows it wrote before.

write_input_forecasts!(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    d::PowerOperationsModels.InputSeriesDescriptor,
    windows::AbstractDict{Dates.DateTime, <:JuMP.Containers.DenseAxisArray{Float64, 2, Ax, L} where {Ax, L<:Tuple{JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup}}},
    resolution::Dates.Period,
    interval::Dates.Period
)

One Deterministic per resolved label, its windows sliced from windows (each a (label, time) array keyed by the execution's initial time).

write_input_series!(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    d::PowerOperationsModels.InputSeriesDescriptor,
    array::JuMP.Containers.DenseAxisArray{Float64, 2, Ax, L} where {Ax, L<:Tuple{JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup}},
    timestamps::AbstractVector{Dates.DateTime},
    resolution::Dates.Period
)

One SingleTimeSeries per resolved label, from a (label, time) array.

write_input_series_row!(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    owner_id::Int64,
    owner_type::String,
    name::String,
    values::AbstractVector{Float64},
    initial_timestamp::Dates.DateTime,
    resolution::Dates.Period
) -> Bool

Static counterpart of write_input_forecast_row!, for emulation models. Returns false without writing when this (owner, name) already has a SingleTimeSeries input row – a Deterministic input row for the same (owner, name) (e.g. a decision model's, in a bundle the Emulator aggregator borrows) does not block this write; see _input_row_exists.

write_model_inputs!(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    sys::PowerSystems.System,
    container::OptimizationContainer,
    windows::PowerOperationsModels.RunWindows
)

Recast every time-series parameter of a standalone model as component-owned input series, one window at the model's initial time. Skips a horizon under two steps: InfraStore needs at least two points per series, and parameter_store_from_model already warned about it.

write_outputs_system_bundle!(
    sys::PowerSystems.System,
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    key_map::AbstractDict{Int64, Int64},
    bundle_dir::AbstractString
)

Write an outputs bundle: the System document plus the parameter store it points at.

The layout is PowerSystems' ordinary directory form, so PSY.from_file(bundle_dir) reads it with no special casing and PowerAnalytics needs no changes. What differs from a normal bundle is only which series the sidecar holds — the parameters the model used, not a second copy of the System's original series — and that the sidecar keeps its catalog, so parameters the document does not declare stay readable.

key_map sends each time-series-backed cost's association_id to the parameter series that replaces it, so the restored System's costs resolve against the sidecar.

The store is persisted first and the rows exported from that same store, so every row names an array already on disk.

write_parameter_array!(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    key::ParameterKey,
    array::JuMP.Containers.DenseAxisArray{var"#s3372", 2, Ax, L} where {var"#s3372", Ax, L<:Tuple{JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup}},
    timestamps::AbstractVector{Dates.DateTime},
    resolution::Dates.Period;
    extra_features
)

Store one parameter array's realized values under the synthetic parameter owner, one SingleTimeSeries per axis-1 label. Never becomes a document row: it is read back through read_parameter_array, not through the restored System's own component listing.

resolution is passed explicitly rather than inferred from timestamps, and data is built directly from array rather than routed through IS.TimeSeries.TimeArray: a single-time-step array (e.g. a model built with horizon = Dates.Hour(1)) gives SingleTimeSeries only one timestamp, and IS.check_resolution requires at least two timestamps to validate a resolution against, TimeArray-backed or not. timestamps is always a range(initial_time; step = resolution, length = ...) in every caller, so the stride is already correct by construction — initial_timestamp/resolution alone are enough to place data.

write_parameter_array!(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    key::ParameterKey,
    array::JuMP.Containers.DenseAxisArray{var"#s3372", 3, Ax, L} where {var"#s3372", Ax, L<:Tuple{JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup}},
    timestamps::AbstractVector{Dates.DateTime},
    resolution::Dates.Period;
    extra_features
)

Store one 3-D parameter array's realized values, one SingleTimeSeries per (axis-1 label, axis-2 label) slice, the axis-2 label carried in the "axis2" feature. Time is the last axis, matching PSI's HDF5 layout ((label, label2, time)). Delegates to the 2-D method per axis-2 slice; only the slice and the "axis2" feature differ.

write_parameter_windows!(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    key::ParameterKey,
    windows::AbstractDict{Dates.DateTime, <:JuMP.Containers.DenseAxisArray{var"#s3355", 2, Ax, L} where {var"#s3355", Ax, L<:Tuple{JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup}}},
    resolution::Dates.Period,
    interval::Dates.Period;
    extra_features
)

Store one parameter's realized per-execution windows under the synthetic parameter owner, one PSY.Deterministic per axis-1 label, keyed by each window's initial time. Never becomes a document row: it is read back through read_parameter_windows.

write_parameter_windows!(
    store::PowerOperationsModels.ParameterTimeSeriesStore,
    key::ParameterKey,
    windows::AbstractDict{Dates.DateTime, <:JuMP.Containers.DenseAxisArray{var"#s3358", 3, Ax, L} where {var"#s3358", Ax, L<:Tuple{JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup}}},
    resolution::Dates.Period,
    interval::Dates.Period;
    extra_features
)

Store one 3-D parameter window set. Not supported: a 3-D window has no Deterministic counterpart in this store, so this errors naming the key rather than silently dropping the third axis.