Public API Reference

Ordered event parameter types a runtime must update for a device under an outage event. The order is load-bearing: the countdown carries the outage's memory, so it is written first and the availability derived from it is written last, with the balance offsets in between.

Full AC power flow in rectangular voltage coordinates (vr, vi). Physics-equivalent to ACPNetworkModel; on the same system both solve the identical nonlinear program and therefore reach the same optimal objective value.

Abstract type for Branch Formulations (a.k.a Models)

Example

import PowerOperationsModels
const POM = PowerOperationsModels
struct MyCustomBranchFormulation <: IOM.AbstractBranchFormulation end

Abstract type for a value an AbstractEventCondition needs from a runtime. POM declares what is needed; the runtime resolves it.

Abstract type for the condition that triggers an event. POM stores conditions as data; evaluating them requires a simulation runtime and happens outside this package.

Supertype for single-period (decision) operation problems solved by DecisionModel.

Supertype for rolling-horizon (emulation) operation problems solved by EmulationModel.

Umbrella supertype for every PowerOperationsModels optimization problem. A DecisionModel/EmulationModel parameterized over a subtype of this is a POM operation model; dispatch on DecisionModel{<:AbstractPowerOperationProblem} selects the POM-side implementations of IOM's extension points.

Abstract supertype for InterconnectingConverter formulations with quadratic losses.

Networks that carry a reactive power balance and an AC voltage representation: ACP, ACR, IVR and LPACC. This is the exact complement of AbstractActivePowerModel among the network models, and it is the set of networks the LCC converter and other reactive-aware branch formulations require. Dispatch on it instead of enumerating the concrete networks; a new reactive-capable network formulation should subtype it to inherit those methods.

Abstract supertype for controllable shunt formulations. All subtypes model reactive compensation devices (PSY.SwitchedAdmittance, PSY.FACTSControlDevice) that dispatch a continuous susceptance $b \in [b_{\min}, b_{\max}]$ and inject $Q = b \cdot V^2$ into the reactive nodal balance. Only valid under AC network models; dropped from DC templates automatically via models_reactive_power.

Imposed by transformer circuits with ACTIVEPOWERFLOW control on a branch formulation with controls enabled.

Parameter to define active power in time series

Struct to create the constraint to limit active power expressions by a time series parameter. For more information check Device Formulations.

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

\[p_t^{in} \le \text{ActivePowerTimeSeriesParameter}_t, \quad \forall t \in \{1,\dots,T\}\]

Parameter to define active power offset during an event.

Parameter to define active power out time series

Struct to create the constraint to limit active power expressions by a time series parameter. For more information check Device Formulations.

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

\[p_t^{out} \le \text{ActivePowerTimeSeriesParameter}_t, \quad \forall t \in \{1,\dots,T\}\]

Struct to create the constraint that bounds a device's active power expression by its available capacity during an outage event.

\[p_t \le P^\text{max} \cdot \text{status}_t, \quad \forall t \in \{1,\dots,T\}\]

Constraint to limit the active power pump variable during an event

Struct to create the constraint that limits the pump power based on the reservoir variable for hydro pump formulations.

For more information check HydroPowerSimulations Formulations.

The specified constraint is formulated as:

\[p^\text{pump}_t \le P^\text{max,pump} \cdot (1 - \text{ReservationVariable}_t),\]

Struct to dispatch the creation of a variable for pumped power in a hydro pump turbine (in MWh).

Struct to create the constraint that limits the pump power for hydro pump formulations.

For more information check HydroPowerSimulations Formulations.

The specified constraint is formulated as:

\[p^\text{pump}_t \le \text{ActivePowerTimeSeriesParameter}_t,\]

Struct to dispatch the creation of Active Power Reserve Variables

Docs abbreviation: $r$

Parameter to define active power time series

Struct to create the constraint to limit active 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:

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

Struct to create the constraint to limit active power expressions by a time series parameter. For more information check Device Formulations.

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

\[p_t \le \text{ActivePowerTimeSeriesParameter}_t, \quad \forall t \in \{1,\dots,T\}\]

Struct to create the constraint for starting up ThermalMultiStart units. For more information check ThermalGen Formulations for ThermalMultiStartUnitCommitment.

The specified constraint is formulated as:

\[\max\{P^\text{th,max} - P^\text{th,shdown}, 0\} \cdot w_1^\text{th} \le u^\text{th,init} (P^\text{th,max} - P^\text{th,min}) - P^\text{th,init}\]

Ancillary service fraction assigned to Storage Charging to product p

Docs abbreviation: $sb^{stc}_{p,t}$

Ancillary service fraction assigned to Storage Discharging to product p

Docs abbreviation: $sb^{std}_{p,t}$

Branch voltage-angle-difference limits: angmin ≤ vafr - vato ≤ angmax.

Approximation to represent inter-area flow with each area represented as a single node.

Linear active power approximation using the power transfer distribution factor PTDF matrix. Balancing areas as well as synchrounous regions.

Parameter to record that the component changed in the availability status

Parameter to define component availability status updated from the system state

Branch active-power flow expression for the B-θ (DC) network model: b·(θ_from - θ_to - shift), with the DC susceptance b = 1/(tap·x) and the DC phase shift. Under DCPNetworkModel with StaticBranch the flow is this expression (not a decision variable); FlowRateConstraint rows are written directly on it. Reportable as an output, mirroring PTDFBranchFlow.

Imaginary component of the from-terminal branch current in the IVR formulation, indexed by (branchname, t). Bounded ±(ratea / vmin).

Docs abbreviation: $c_i^{fr}$

Real component of the from-terminal branch current in the IVR formulation, indexed by (branchname, t). Bounded ±(ratea / vmin).

Docs abbreviation: $c_r^{fr}$

Imaginary component of the to-terminal branch current in the IVR formulation, indexed by (branchname, t). Bounded ±(ratea / vmin).

Docs abbreviation: $c_i^{to}$

Real component of the to-terminal branch current in the IVR formulation, indexed by (branchname, t). Bounded ±(ratea / vmin).

Docs abbreviation: $c_r^{to}$

Parameter to define the dynamic rating time series of a branch

Imaginary component of the series (through-impedance) branch current in the IVR formulation, indexed by (branchname, t). Bounded ±(ratea / vmin).

Docs abbreviation: $c_{si}$

Real component of the series (through-impedance) branch current in the IVR formulation, indexed by (branchname, t). Bounded ±(ratea / vmin).

Docs abbreviation: $c_{sr}$

Charge / inflow side of a storage or hybrid PCC.

Struct to dispatch the creation of Cold Start Variable for Thermal units with temperature considerations

Docs abbreviation: $x^\text{th}$

Struct to create the commitment constraint between the on, start, and stop variables. For more information check ThermalGen Formulations.

The specified constraints are formulated as:

\[u_1^\text{th} = u^\text{th,init} + v_1^\text{th} - w_1^\text{th} \\ u_t^\text{th} = u_{t-1}^\text{th} + v_t^\text{th} - w_t^\text{th}, \quad \forall t \in \{2,\dots,T\} \\ v_t^\text{th} + w_t^\text{th} \le 1, \quad \forall t \in \{1,\dots,T\}\]

Struct to add a constant maximum transmission flow for specified interface

ContinuousCondition()

Event condition that is triggered at all timesteps.

Non-negative AC apparent current at the from-terminal of a TwoTerminalVSCLine under an AC network model: $I_{ac,f}^2 \, V_{ac,f}^2 = p_{ft}^2 + q_f^2$. Docs abbreviation: $i_f^{ac}$

Non-negative AC apparent current at the to-terminal of a TwoTerminalVSCLine under an AC network model: $I_{ac,t}^2 \, V_{ac,t}^2 = p_{tf}^2 + q_t^2$. Docs abbreviation: $i_t^{ac}$

Non-negative AC apparent current $I_{ac} = \sqrt{p^2 + q^2}/|V_{ac}|$ at the AC terminal of an InterconnectingConverter under an AC network model. The converter loss is parameterized on this current (instead of the DC cable current) so reactive loading incurs loss. Defined by $I_{ac}^2 \, V_{ac}^2 = p^2 + q^2$. Docs abbreviation: $i_c^{ac}$

Struct to dispatch the creation of DC Converter Current Variables for DC formulations Docs abbreviation: $i_c^{dc}$

Struct to create the constraint to balance power in the copperplate model. For more information check Network Formulations.

The specified constraint is generally formulated as:

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

Infinite capacity approximation of network flow to represent entire system with a single node.

Struct to dispatch the creation of bus-pair Cosine Approximation Variables (cs) for the LPAC formulation, indexed by branch.

Docs abbreviation: $cs$

LPAC convex cosine relaxation: cs ≤ 1 - (1-cos(vadmax))/vadmax² · (vafr - vato)².

Non-negative LP surrogate for the absolute value of a DC current variable (abs_i ≥ i, abs_i ≥ -i, abs_i ≥ 0; tight at optimum because the loss term b · abs_i is minimized via the generation-cost objective). Used by both two-terminal HVDC links (cable current) and interconnecting converters. Docs abbreviation: $|i|^{dc}$

IVR terminal-current apparent-power limit: cr² + ci² ≤ crating² where crating = rate_a / vmin.

Struct to dispatch the variable of DC Current Variables for DC Lines formulations Docs abbreviation: $i_l^{dc}$

Lossy Line Abstract Model

Default concrete template-driven decision problem. The M used when a DecisionModel is built from a template without an explicit problem type.

Default concrete template-driven emulation problem. The M used when an EmulationModel is built from a template without an explicit problem type.

Profile of a reserve's deployed fraction, scaled by the reserve's deployed_fraction field.

The fraction multiplies a reserve award, so this is a left-hand-side parameter: its container holds numbers in every build mode, and its values are written into constraints as fixed coefficients. A model holding one is rebuilt every simulation step.

Reserve aggregation that scales the multiplier by deployed_fraction.

Discharge / outflow side of a storage or hybrid PCC.

DiscreteEventCondition(condition_function::Function)

Event condition driven by a user-defined function evaluated by the simulation runtime.

Struct to create the duration constraint for commitment formulations, i.e. min-up and min-down.

For more information check ThermalGen Formulations.

Struct to create the constraint that limits the budget for reservoir formulations.

For more information check HydroPowerSimulations Formulations.

The specified constraint is formulated as:

\[\sum_{t=1}^T p^\text{hy}_t \le \sum_{t=1}^T \text{EnergyBudgetTimeSeriesParameter}_t,\]

Parameter to define energy budget time series for hydro generators

Struct to create the constraint that limits the pump power for hydro pump formulations.

For more information check HydroPowerSimulations Formulations.

The specified constraint is formulated as:

\[e^\text{pump}_t \le \text{EnergyCapacityTimeSeriesParameter}_t,\]

Parameter to define energy capacity limits for hydro pump-turbine time series

EnergyLimitFeedforward(
    component_type::Type{<:PSY.Component},
    source::Type{T},
    affected_values::Vector{DataType},
    number_of_periods::Int,
    meta = CONTAINER_KEY_EMPTY_META
) where {T}

Bounds the sum of a variable over consecutive blocks of number_of_periods time steps to a per-block energy limit read from the system state. For example, in a 24-step model, number_of_periods = 24 builds a single constraint over the whole horizon, while number_of_periods = 12 builds two constraints, one per 12-step block. number_of_periods must divide the horizon length evenly.

Arguments:

• component_type::Type{<:PSY.Component} : Specify the type of component on which the Feedforward will be applied
• source::Type{T} : The VariableType, ParameterType, or AuxVariableType naming the quantity in the system state that the Feedforward reads
• affected_values::Vector{DataType} : Specify the variable the energy limit will be applied to
• number_of_periods::Int : The number of consecutive time steps each constraint sums over

Parameter to define energy limit

Struct to create the constraint that set-up the target for reservoir formulations.

For more information check HydroPowerSimulations Formulations.

The specified constraint is formulated as:

\[e_t + e^\text{shortage} + e^\text{surplus} = \text{EnergyTargetTimeSeriesParameter}_t, \quad \forall t \in \{1,\dots, T\}\]

EnergyTargetFeedforward(
    component_type::Type{<:PSY.Component},
    source::Type{T},
    affected_values::Vector{DataType},
    target_period::Int,
    penalty_cost::Float64,
    meta = CONTAINER_KEY_EMPTY_META
) where {T}

Holds a storage energy variable to a minimum target read from the system state at target_period, relaxed by a shortage slack penalized in the objective. target_period must be the last step of the horizon: the storage shortage slack is only defined there.

Arguments:

• component_type::Type{<:PSY.Component} : Specify the type of component on which the Feedforward will be applied
• source::Type{T} : The VariableType, ParameterType, or AuxVariableType naming the quantity in the system state that the Feedforward reads
• affected_values::Vector{DataType} : Specify the variable the energy target will be applied to
• target_period::Int : The time step at which the target is enforced; must be the last step of the horizon.
• penalty_cost::Float64 : The objective penalty applied to the shortage slack

Parameter to define energy storage target level time series for hydro generators

Struct to dispatch the creation of a variable for energy storage level (state of charge)

Docs abbreviation: $e$

EventKey(::Type{T}, ::Type{U})

Key identifying an event of contingency type T applied to devices of concrete type U. Used as the key of the DeviceModel.events dict. Errors if U is abstract.

EventModel(contingency_type, condition; timeseries_mapping, attributes)

Container binding a PSY.Contingency supplemental-attribute type to a trigger condition and time-series mapping. Attach to a template with set_event_model!(template, event_model); build-time discovery populates attribute_device_map (outage attribute id → device type → device names) and distributes the event to the matching DeviceModels.

Struct to create the constraint that limits the hydro usage for hydro formulations.

For more information check HydroPowerSimulations Formulations.

The specified constraint is formulated as:

\[\sum_{t=1}^T E^\text{hy}_t \le \text{HydroUsageLimitParameter}_T,\]

Constraint limiting the water level budget of a reservoir to a budget read from the system state.

Struct to create the equality constraint that pins a variable to a quantity read from the system state.

For more information check Feedforward Formulations.

The specified constraint is formulated as:

\[\begin{align*} & \text{AffectedVariable}_t = \text{SourceVariableParameter}_t \cdot \text{multiplier}_t, \quad \forall t \in \{1,\dots, T\} \end{align*}\]

Struct to create the constraint for lower bound feedforward limits.

For more information check Feedforward Formulations.

The specified constraint is formulated as:

\[\begin{align*} & \text{AffectedVariable}_t + p_t^\text{ff,lbsl} \ge \text{SourceVariableParameter}_t \cdot \text{multiplier}_t, \quad \forall t \in \{1,\dots, T\} \end{align*}\]

The slack term is present only when the feedforward is built with add_slacks = true.

Struct to create the constraint for semicontinuous feedforward limits.

The commitment status is an OnStatusParameter read from the system state, not a commitment variable this model solves for. It enters the range expressions scaled by the device's limits, which is why the formulation's own range constraints are suppressed rather than added alongside these.

For more information check Feedforward Formulations.

The specified constraint is formulated as:

\[\begin{align*} & \text{ActivePowerRangeExpressionUB}_t := p_t^\text{th} - \text{OnStatusParameter}_t P^\text{th,max} \le 0, \quad \forall t\in \{1, \dots, T\} \\ & \text{ActivePowerRangeExpressionLB}_t := p_t^\text{th} - \text{OnStatusParameter}_t P^\text{th,min} \ge 0, \quad \forall t\in \{1, \dots, T\} \end{align*}\]

Compact formulations schedule $p_t^\text{th}$ above the minimum, so their multipliers are $P^\text{th,max} - P^\text{th,min}$ and $0$ instead.

Struct to create the constraint for upper bound feedforward limits.

For more information check Feedforward Formulations.

The specified constraint is formulated as:

\[\begin{align*} & \text{AffectedVariable}_t - p_t^\text{ff,ubsl} \le \text{SourceVariableParameter}_t \cdot \text{multiplier}_t, \quad \forall t \in \{1,\dots, T\} \end{align*}\]

The slack term is present only when the feedforward is built with add_slacks = true.

FixValueFeedforward(
    component_type::Type{<:PSY.Component},
    source::Type{T},
    affected_values::Vector{DataType},
    meta = CONTAINER_KEY_EMPTY_META
) where {T}

Fixes a Variable or Parameter Value in the model to a quantity read from the system state. Is the only Feed Forward that can be used with a Parameter or a Variable as the affected value.

Arguments:

• component_type::Type{<:PSY.Component} : Specify the type of component on which the Feedforward will be applied
• source::Type{T} : The VariableType or AuxVariableType naming the quantity in the system state that the Feedforward reads
• affected_values::Vector{DataType} : Specify the variable on which the fix value will be applied from the state values

Fixed-susceptance shunt injecting Q = b_nominal·V² into the reactive nodal balance with a non-dispatched b_nominal (SwitchedAdmittance: the engaged susceptance, solved_admittance when set and the engaged blocks otherwise; FACTSControlDevice: the reactive-power setpoint on system base). The susceptance is not a decision variable and there is no voltage-control objective. This is the only shunt formulation valid under LPACCNetworkModel, where V² linearizes to 1 + 2φ; it also builds on ACP/ACR/IVR. Dropped from DC templates automatically via models_reactive_power.

Struct to dispatch the creation of unidirectional Active Power Flow Variables

Docs abbreviation: $f^\text{from-to}$

Struct to dispatch the creation of active power flow lower bound slack variables. Used when there is not enough flow through the branch in the reverse direction.

Docs abbreviation: $f^\text{sl,lo}$

Struct to dispatch the creation of active power flow upper bound slack variables. Used when there is not enough flow through the branch in the forward direction.

Docs abbreviation: $f^\text{sl,up}$

Struct to dispatch the creation of unidirectional Active Power Flow Variables

Docs abbreviation: $f^\text{to-from}$

Struct to dispatch the creation of bidirectional Active Power Flow Variables

Docs abbreviation: $f$

Struct to create the constraint that sets the apparent power flow limits on a branch.

For more information check Branch Formulations.

The specified constraint is formulated as:

\[-R^\text{max} \le f_t \le R^\text{max}, \quad \forall t \in \{1,\dots,T\}\]

Constrains the upper and lower bounds of a branch's flow, which is equality-constrained by NetworkFlowConstraints.

For more information check Branch Formulations.

The specified constraint is formulated as:

\[\begin{align*} & f_t - f_t^\text{sl,up} \le R^\text{max},\quad \forall t \in \{1,\dots, T\} \\ & f_t + f_t^\text{sl,lo} \ge -R^\text{max},\quad \forall t \in \{1,\dots, T\} \end{align*}\]

Struct to create the constraint for branch flow rate limits from the 'from' bus to the 'to' bus. For more information check Branch Formulations.

Struct to create the constraint for branch flow rate limits from the 'to' bus to the 'from' bus. For more information check Branch Formulations.

Struct to dispatch the creation of unidirectional Reactive Power Flow Variables

Docs abbreviation: $f^\text{q,from-to}$

Struct to dispatch the creation of unidirectional Reactive Power Flow Variables

Docs abbreviation: $f^\text{q,to-from}$

Decision problems whose build/validate behavior is fully driven by the ProblemTemplate (the common case). DecisionModel{<:GenericPowerDecisionProblem} gets the generic template-driven build_model!/validate_template methods.

Emulation problems whose build/validate behavior is fully driven by the ProblemTemplate.

Group analogue of RangeReserve: the awards of a PSY.GroupReserve's contributing services must together meet the group's specified requirement. Not named GroupReserve to avoid clashing with the PSY.GroupReserve component type.

Group analogue of StepwiseCostReserve: one elastic demand curve (the PSY.GroupReserve's variable) is met by the summed awards of its contributing services - one demand, one clearing price, with offers and caps living on the members. Ignores the group's requirement.

DC-terminal active-power control constraint for VoltageControlVSC and VoltageControlConverter devices. Exactly one constraint entry per terminal per time step is always created (count-invariant across control modes); only the coefficients differ by mode:

• DC_VOLTAGE (terminal DC voltage regulation):

  \[v_{dc,t} = \text{setpoint}\]

• DC_POWER (active-power setpoint):

  \[p_t = \text{setpoint}\]

• DC_VOLTAGE_DROOP (droop control):

  \[v_{dc,t} + \text{droop\_gain} \cdot p_t = \text{setpoint}\]

Constraint containers use meta = "from" and meta = "to" to distinguish the two per-terminal entries for two-terminal links. Only valid under AC network models; VoltageControlVSC and VoltageControlConverter are dropped from DC templates automatically via models_reactive_power.

Struct to dispatch the creation of HVDC Flow Direction Auxiliary Variables

Docs abbreviation: $u^\text{dir}$

DC-side voltage at the from-terminal of a two-terminal HVDC link. Used by the HVDCTwoTerminalVSC formulation. Docs abbreviation: $v_f^{dc}$

Struct to dispatch the creation of HVDC Losses Auxiliary Variables

Docs abbreviation: $\ell$

Reactive power injected at the from-terminal AC bus by a two-terminal HVDC link. Added only when the formulation runs on an AC network model. Docs abbreviation: $q_f$

Reactive power injected at the to-terminal AC bus by a two-terminal HVDC link. Added only when the formulation runs on an AC network model. Docs abbreviation: $q_t$

DC-side voltage at the to-terminal of a two-terminal HVDC link. Used by the HVDCTwoTerminalVSC formulation. Docs abbreviation: $v_t^{dc}$

Branch type to represent lossy power flow on DC lines

Branch type to represent non-linear LCC (line commutated converter) model on two-terminal DC lines

Branch type to represent lossless power flow on DC lines

Branch type to represent piecewise lossy power flow on two terminal DC lines

Branch type to avoid flow constraints

Two-terminal VSC formulation: the per-terminal $v \cdot I$ / $I^2$ losses are bridged to IOM's approximation API and the apparent-power limit $p^2 + q^2 \le \text{rating}^2$ is enforced as the exact disk (default "none", NLP) or, under a linearizing scheme, a linear outer-approximation — a box, plus an octagon when the "use_octagon" attribute (default true) is on. See BILINEAR_APPROX_DEFAULT_ATTRIBUTES for the approximation attributes; here "bilinear_quadratic_method" also sizes the standalone I² loss term for every scheme.

Struct to dispatch the creation of Hot Start Variable for Thermal units with temperature considerations

Docs abbreviation: $z^\text{th}$

HybridDispatchWithReserves

Device formulation for a hybrid system (single point of common coupling (PCC) with renewable, thermal, and storage subcomponents) that participates in both energy and ancillary services markets. Implements a centralized production cost model where the hybrid plant's net power at the PCC is constrained by $P_{\max,\text{pcc}}$ and ancillary service allocations ($sb^{\text{out}}_{p,t}$, $sb^{\text{in}}_{p,t}$) are assigned to internal assets (thermal, renewable, charge, discharge) per the four-quadrant ancillary service model. Reserve participation is enabled by attaching a service model to the hybrid (set_service_model! + add_service!); when no service is attached the formulation collapses to an energy-only hybrid dispatch.

Use with a hybrid system in a DeviceModel for unit commitment or economic dispatch.

Variables:

• ActivePowerOutVariable:

  • Domain: [0.0, $P_{\max,\text{pcc}}$]
  • Symbol: $p^{\text{out}}_t$

• ActivePowerInVariable:

  • Domain: [0.0, $P_{\max,\text{pcc}}$]
  • Symbol: $p^{\text{in}}_t$

• ReservationVariable (only when "reservation" => true):

  • Domain: {0, 1}
  • Symbol: $u^{\text{st}}_t$ (1 = discharge mode, 0 = charge mode)

• HybridThermalActivePower:

  • Domain: [0.0, $P_{\max,\text{th}}$] when on
  • Symbol: $p^{\text{th}}_t$

• OnVariable:

  • Domain: {0, 1}
  • Symbol: $u^{\text{th}}_t$

• HybridRenewableActivePower:

  • Domain: [0.0, $P^{*,\text{re}}_t$]
  • Symbol: $p^{\text{re}}_t$

• HybridStorageSubcomponentPower{ChargeSide}:

  • Domain: [0.0, $P_{\max,\text{ch}}$]
  • Symbol: $p^{\text{ch}}_t$

• HybridStorageSubcomponentPower{DischargeSide}:

  • Domain: [0.0, $P_{\max,\text{ds}}$]
  • Symbol: $p^{\text{ds}}_t$

• EnergyVariable:

  • Domain: [0.0, $E_{\max,\text{st}}$]
  • Symbol: $e^{\text{st}}_t$

• HybridStorageReservation (only when "storage_reservation" => true):

  • Domain: {0, 1}
  • Symbol: $ss^{\text{st}}_t$ (0 = charge, 1 = discharge)

• HybridPCCReserveVariable{DischargeSide} (only when services are attached):

  • Domain: [0.0, ]
  • Symbol: $sb^{\text{out}}_t$

• HybridPCCReserveVariable{ChargeSide} (only when services are attached):

  • Domain: [0.0, ]
  • Symbol: $sb^{\text{in}}_t$

• RegularizationVariable{ChargeSide}, RegularizationVariable{DischargeSide} (only when "regularization" => true): non-negative slacks bounding step changes in charge/discharge between consecutive time steps.

Time Series Parameters:

Data requirements:

• Device: A PSY.HybridSystem with at least one of: thermal unit (PSY.get_thermal_unit), renewable unit (PSY.get_renewable_unit), storage (PSY.get_storage), and optionally electric load (PSY.get_electric_load).
• Time series: Forecast time series must be attached to the PSY.HybridSystem itself (not its subcomponents) under the default names above (or custom names passed when adding parameters). The subcomponent-namespaced default names ("RenewableDispatch__max_active_power", "PowerLoad__max_active_power") reflect which subcomponent each forecast describes; the subcomponent is consulted only for the rating used to scale the parameter.

Static Parameters:

• $P_{\max,\text{pcc}}$ = PSY.get_output_active_power_limits(device).max
• $P_{\max,\text{th}}$ = PSY.get_active_power_limits(thermal_unit).max
• $P_{\min,\text{th}}$ = PSY.get_active_power_limits(thermal_unit).min
• $P_{\max,\text{ch}}$ = PSY.get_input_active_power_limits(storage).max
• $P_{\max,\text{ds}}$ = PSY.get_output_active_power_limits(storage).max
• $\eta_{\text{ch}}$ = PSY.get_efficiency(storage).in
• $\eta_{\text{ds}}$ = PSY.get_efficiency(storage).out
• $E_{\max,\text{st}}$ = PSY.get_storage_level_limits(storage).max * PSY.get_storage_capacity(storage, u"SU") * PSY.get_conversion_factor(storage)`
• $E^{\text{st}}_0$ = initial storage energy
• $R^{*}_{p,t}$ = ancillary service deployment forecast for service $p$ at time $t$
• $F_p$ = fraction of $P_{\max,\text{pcc}}$ allowed for service $p$
• $N_p$ = number of periods of compliance for service $p$

Expressions:

Adds $p^{\text{out}}_t$ and $p^{\text{in}}_t$ to ActivePowerBalance for use in network balance constraints. When services are attached, also accumulates reserve expressions (HybridPCCReserveExpression) with unscaled and deployed-reserve scalings across all four combinations of direction (up/down) and side (in/out).

Constraints:

Let $\mathcal{T} = \{1, \dots, T\}$ denote the set of time steps.

PCC and status. When "reservation" => true: HybridStatusOnConstraint{DischargeSide}, HybridStatusOnConstraint{ChargeSide}. When "reservation" => false: OutputActivePowerVariableLimitsConstraint and InputActivePowerVariableLimitsConstraint (no mutual-exclusion binary).

\[\begin{align*} & 0 \leq p^{\text{in}}_t \leq P_{\max,\text{pcc}}, \quad 0 \leq p^{\text{out}}_t \leq P_{\max,\text{pcc}}, \quad \forall t \in \mathcal{T} \\ & u^{\text{st}}_t \in \{0,1\} \quad \text{(when reservation is enabled)} \end{align*}\]

Energy asset balance (HybridEnergyAssetBalanceConstraint). When services are present, served-reserve expressions enter the balance with sign pattern $+\bar{r}^{\text{out,up}} - \bar{r}^{\text{in,up}} - \bar{r}^{\text{out,dn}} + \bar{r}^{\text{in,dn}}$.

\[p^{\text{th}}_t + p^{\text{re}}_t + p^{\text{ds}}_t - p^{\text{ch}}_t - P^{\text{ld}}_t = p^{\text{out}}_t - p^{\text{in}}_t, \quad \forall t \in \mathcal{T}\]

Thermal limits when no services are attached (HybridThermalOnVariableConstraint{UpperBound}, HybridThermalOnVariableConstraint{LowerBound}):

\[u^{\text{th}}_t P_{\min,\text{th}} \leq p^{\text{th}}_t \leq u^{\text{th}}_t P_{\max,\text{th}}, \quad u^{\text{th}}_t \in \{0,1\}, \quad \forall t \in \mathcal{T}\]

Renewable limit (HybridRenewableActivePowerLimitConstraint):

\[0 \leq p^{\text{re}}_t \leq P^{*,\text{re}}_t, \quad \forall t \in \mathcal{T}\]

Storage charge/discharge mutual exclusion when "storage_reservation" => true (HybridStorageStatusOnConstraint{ChargeSide}, HybridStorageStatusOnConstraint{DischargeSide}):

\[\begin{align*} & p^{\text{ch}}_t \leq (1 - ss^{\text{st}}_t) P_{\max,\text{ch}}, \quad p^{\text{ds}}_t \leq ss^{\text{st}}_t P_{\max,\text{ds}}, \quad \forall t \in \mathcal{T} \\ & ss^{\text{st}}_t \in \{0,1\} \end{align*}\]

Storage energy balance (HybridStorageBalanceConstraint):

\[e^{\text{st}}_t = e^{\text{st}}_{t-1} + \Delta t \left( \eta_{\text{ch}} p^{\text{ch}}_t - \frac{p^{\text{ds}}_t}{\eta_{\text{ds}}} \right), \quad \forall t \in \mathcal{T}, \quad e^{\text{st}}_0 = E^{\text{st}}_0\]

When ancillary services are attached: HybridThermalReserveLimitConstraint, HybridRenewableReserveLimitConstraint, HybridStorageReservePowerLimitConstraint{ChargeSide}, HybridStorageReservePowerLimitConstraint{DischargeSide}, ReserveCoverageConstraint, ReserveCoverageConstraintEndOfPeriod, HybridReserveAssignmentConstraint, HybridReserveBalanceConstraint.

End-of-horizon energy target (if "energy_target" => true), HybridEnergyTargetConstraint:

\[e^{\text{st}}_T - e^{\text{st+}} + e^{\text{st-}} = E^{\text{st}}_T\]

Charge/discharge regularization (if "regularization" => true), RegularizationConstraint{ChargeSide}, RegularizationConstraint{DischargeSide}: bound $|p^{\text{ch}}_t - p^{\text{ch}}_{t-1}|$ and $|p^{\text{ds}}_t - p^{\text{ds}}_{t-1}|$ by a non-negative slack carried into the objective.

Example

DeviceModel(
    PSY.HybridSystem,
    HybridDispatchWithReserves;
    attributes = Dict(
        "reservation"         => true,
        "storage_reservation" => true,
        "energy_target"       => false,
        "regularization"      => false,
    ),
)

Attributes

• "reservation" (default true): if true, adds ReservationVariable and uses HybridStatus{Out,In}OnConstraint to mutually exclude PCC charge and discharge. If false, both PCC variables are bounded by simple range constraints.
• "storage_reservation" (default true): if true, adds HybridStorageReservation and uses the ss-multiplied form of the storage power-limit constraints. If false, charge and discharge variables are bounded independently.
• "energy_target" (default false): adds HybridEnergyTargetConstraint at the storage subcomponent.
• "regularization" (default false): adds RegularizationVariable{ChargeSide} and RegularizationVariable{DischargeSide} plus the matching constraints, and a small objective penalty on each, to suppress charge/discharge oscillation.

Objective:

Adds variable cost on HybridThermalActivePower, HybridRenewableActivePower, HybridStorageSubcomponentPower{ChargeSide}, and HybridStorageSubcomponentPower{DischargeSide} from each subcomponent's PSY.get_operation_cost, plus the proportional OnVariable cost (delegated to POM's standard proportional_cost for ThermalGenerationCost, so a hybrid-embedded thermal unit and a standalone copy produce identical objective coefficients). When "regularization" => true, also adds a small per-time-step penalty on the regularization slacks.

Time-series parameter for a hybrid system's electric-load subcomponent demand, normalized by the load's max_active_power.

Equates the hybrid's PCC active-power injection to the sum of internal subcomponent flows (thermal + renewable + storage discharge - storage charge - load) net of served reserves.

Slack variable for the storage energy of a hybrid system being below its end-of-period target. Added when the hybrid "energy_target" attribute is set and penalized in the objective by the storage subcomponent's energy_shortage_cost.

Docs abbreviation: $e^{st-}$

Slack variable for the storage energy of a hybrid system being above its end-of-period target. Added when the hybrid "energy_target" attribute is set and penalized in the objective by the storage subcomponent's energy_surplus_cost.

Docs abbreviation: $e^{st+}$

End-of-period energy target for the storage subcomponent of a hybrid system. Used when the attribute energy_target = true.

Like the storage StateofChargeTargetConstraint, this is a soft equality with non-negative surplus (HybridEnergySurplusVariable, energy above target) and shortage (HybridEnergyShortageVariable, energy below target) slacks penalized in the objective:

\[e^{st}_{T} - e^{st+} + e^{st-} = E^{st}_{T}.\]

Active power dispatched by the renewable subcomponent of a hybrid system.

Upper bound on renewable subcomponent power from the time-series forecast.

Time-series parameter for the maximum active power available from a hybrid system's renewable subcomponent, normalized by the renewable unit's max_active_power rating.

Range constraint on renewable subcomponent power including up/down reserves.

Reserve allocated to the renewable subcomponent of a hybrid system.

Couples the hybrid PCC reserve variables (out + in) to the system-level ActivePowerReserveVariable of each service the hybrid participates in.

Couples the hybrid PCC reserve variables (out + in) to the sum of per-subcomponent reserve allocations (thermal + renewable + charging + discharging).

Energy balance for the storage subcomponent of a hybrid system, including reserve deployment.

Binary reservation variable for the storage subcomponent of a hybrid system.

Active power dispatched by the thermal subcomponent of a hybrid system.

Range constraint on thermal subcomponent power including up/down reserves.

Reserve allocated to the thermal subcomponent of a hybrid system.

Struct to dispatch the creation of a slack variable for shortage on balance constraints

Docs abbreviation: $e^\text{b,shortage}$

Struct to dispatch the creation of a slack variable for surplus on balance constraints

Docs abbreviation: $e^\text{b,surplus}$

Formulation type to add commitment and injection variables constrained by a maximum injection time series for PowerSystems.HydroGen

Formulation type to add injection variables constrained by a maximum injection time series for PowerSystems.HydroGen. Set the "hydro_budget" device-model attribute to true to additionally enforce an energy budget over the horizon.

Formulation type to add reservoir methods with hydro turbines using only energy inflow/outflow variables (no water flow variables) for PowerSystems.HydroReservoir

Auxiliary Variable for Hydro Models that solve for total energy output

Docs abbreviation: $E^\text{hy,out}$

Struct to dispatch the creation of a slack variable for energy storage levels < target storage levels

Docs abbreviation: $e^\text{shortage}$

Struct to dispatch the creation of a slack variable for energy storage levels > target storage levels

Docs abbreviation: $e^\text{surplus}$

Formulation type to add injection variables for a HydroPumpTurbine only using energy variables (no water flow variables) and commitment variables

Formulation type to add injection variables for a HydroPumpTurbine only using energy variables (no water flow variables)

Aux variable which keeps track of water level (head) of hydro reservoirs (in m)

Struct to dispatch the creation of a variable for volume stored in a hydro reservoir (in m3).

Expression for PowerSystems.HydroGen that keep track of served reserve down for energy calculations

Expression for PowerSystems.HydroGen that keep track of served reserve up for energy calculations

Formulation type to add injection variables for a PowerSystems.HydroGen HydroTurbine connected to reservoirs using water flow variables, with the flow×head product bridged to IOM's approximation API — exact by default ("none", an NLP) or a tolerance-driven MILP approximation under a linearizing scheme. See BILINEAR_APPROX_DEFAULT_ATTRIBUTES for the approximation attributes.

Formulation type to add injection variables for a PowerSystems.HydroTurbine only using energy variables (no water flow variables) and commitment variables

Formulation type to add injection variables for a PowerSystems.HydroTurbine only using energy variables (no water flow variables)

Struct to dispatch the creation of a variable for turbined flow rate (in m3/s).

Formulation type to add injection and commitment variables for a PowerSystems.HydroTurbine connected to reservoirs using a linear model with a binary PowerSimulations.OnVariable to decide if the turbine is on or not. The model assumes a shallow reservoir. The head for the conversion between water flow and power can be approximated as a linear function of the water flow on which the head elevation is always the intake elevation.

Formulation type to add injection variables for a HydroTurbine connected to reservoirs using a linear model PowerSystems.HydroGen. The model assumes a shallow reservoir. The head for the conversion between water flow and power can be approximated as a linear function of the water flow on which the head elevation is always the intake elevation.

HydroUsageLimitFeedforward(
    component_type::Type{<:PSY.Component},
    source::Type{T},
    affected_values::Vector{DataType},
    meta = CONTAINER_KEY_EMPTY_META
) where {T}

Bounds 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. The recommended source is the HydroEnergyOutput auxiliary variable.

Arguments:

• component_type::Type{<:PSY.Component} : Specify the type of component on which the Feedforward will be applied
• source::Type{T} : The VariableType, ParameterType, or AuxVariableType naming the quantity in the system state that the Feedforward reads
• affected_values::Vector{DataType} : Specify the HydroUsageLimitParameter container the limit is read into

Hydro energy usage limit read from the system state

Formulation type to constrain hydropower production with an energy block optimization representation of the energy storage capacity and water inflow time series of a reservoir for PowerSystems.HydroGen

Formulation type to add reservoir methods with hydro turbines using water flow variables for PowerSystems.HydroReservoir

Struct to dispatch the creation of a slack variable for water storage levels < target storage levels

Docs abbreviation: $l^\text{shortage}$

Struct to dispatch the creation of a slack variable for water storage levels > target storage levels

Docs abbreviation: $l^\text{surplus}$

Full AC power flow in current-voltage rectangular (IVR) coordinates. Uses branch current variables (terminal and series) with a linear Ohm's law and bilinear branch power that is wired into ActivePowerBalance/ReactivePowerBalance. Exact AC (same optimum as ACPNetworkModel and ACRNetworkModel); advantage is that the Ohm's law is linear in the decision variables, which can improve solver performance on some instances.

Devices inject P/Q unchanged (same as ACP/ACR); only the branch representation differs. construct_network! is shared with ACRNetworkModel via Union dispatch in network_constructor.jl.

Struct to create the constraint to limit the import and exports in a determined period. For more information check Device Formulations.

Formulation type to add import and export model for Source

Parameter to define energy inflow to storage or reservoir time series

Initial condition for volume in reservoir in PowerSystems.HydroReservoir formulations

Struct to create the constraint to limit active power input 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{in} \le P^\text{max}, \quad \forall t \in \{1,\dots,T\}\]

Struct to dispatch the creation of Interface Flow Slack Down variables

Docs abbreviation: $f^\text{sl,dn}$

Struct to dispatch the creation of Interface Flow Slack Up variables

Docs abbreviation: $f^\text{sl,up}$

Linear-programming AC, cold-start (LPAC) convex approximation of the full AC power flow. Models voltage-magnitude deviation phi = |V| - 1 (per bus), the bus-pair cosine variable cs (per branch) with a convex cosine relaxation, and the LPAC-linearized branch power flows. Tractable (convex QCP) and approximate — faster than full AC while modeling reactive power.

Linear-loss InterconnectingConverter formulation. Same transport-style AC/DC transfer as LosslessConverter (the ActivePowerVariable enters the AC-bus ActivePowerBalance with +1 and the DC-bus ActivePowerBalance with -1, so it requires a TransportHVDCNetworkModel), plus a linear loss b·|I| + c withdrawn at the DC bus, where b/c are the proportional/constant terms of the converter's loss_function and |I| is approximated by |P| at nominal DC voltage (1 pu) via a non-negative CurrentAbsoluteValueVariable surrogate bounded below by ±P and pinned to |P| by cost minimization. A loss_function with a non-zero quadratic term is rejected — use QuadraticLossConverter for current-dependent quadratic losses. On AC network models the converter also gets a bounded ReactivePowerVariable injected into ReactivePowerBalance and the apparent-power capability disk $p^2 + q^2 \le \text{rating}^2$.

Lossless InterconnectingConverter Model

Lossless Line struct formulation

Struct to dispatch the creation of Slack variables that relax a LowerBoundFeedforward constraint, penalized in the objective at BALANCE_SLACK_COST

Docs abbreviation: $p^\text{ff,lbsl}$

LowerBoundFeedforward(
    component_type::Type{<:PSY.Component},
    source::Type{T},
    affected_values::Vector{DataType},
    add_slacks::Bool = false,
    meta = CONTAINER_KEY_EMPTY_META
) where {T}

Constructs a parameterized lower bound constraint from a quantity in the system state.

Arguments:

• component_type::Type{<:PSY.Component} : Specify the type of component on which the Feedforward will be applied
• source::Type{T} : The VariableType or AuxVariableType naming the quantity in the system state that the Feedforward reads
• affected_values::Vector{DataType} : Specify the variable on which the lower bound will be applied from the state values
• add_slacks::Bool = false : Add slacks variables to relax the lower bound constraint.

Parameter to define variable lower bound

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

The specified constraint depends on the network model chosen.

Struct to create the non-anticipativity constraint for the PowerLoadShift formulation. This enforces that shift up can only occur after an equal or greater amount of shift down has already been committed, preventing the optimizer from shifting load up before it has been shifted down. The constraint is formulated as:

\[\sum_{\tau=1}^{t} \left( p_\tau^\text{shift,dn} - p_\tau^\text{shift,up} \right) \ge 0, \quad \forall t \in \{1,\dots,T\}\]

Struct to add non spinning reserve requirements larger than specified requirement

Parameter to define energy outflow from storage or reservoir time series

Linear active power approximation using the power transfer distribution factor PTDF matrix.

Struct to dispatch the creation of Phase Shifters Variables

Docs abbreviation: $\theta^\text{shift}$

Parameter to define the dynamic ratings time series of an AC branch for post-contingency condition

Struct to dispatch the creation of post-contingency active power flow lower bound slack variables. Relaxes the post-contingency (N-1) emergency-rate lower-bound constraint when use_slacks = true.

Docs abbreviation: $f^\text{sl,lo,N-1}$

Struct to dispatch the creation of post-contingency active power flow upper bound slack variables. Relaxes the post-contingency (N-1) emergency-rate upper-bound constraint when use_slacks = true.

Docs abbreviation: $f^\text{sl,up,N-1}$

Post-contingency flow-rate limit on monitored branches: -R_m ≤ Σ_j MODF_post[m,c][j]·p_j ≤ R_m, ∀ t, where MODF_post[m,c] is the PNM VirtualMODF column for monitored arc m under contingency c and R_m is the branch emergency rating (system base / per-unit).

Formulation type to enable (continuous) load interruption dispatch

Formulation type to enable (binary) load interruptions

Formulation type to enable load shifting

PowerOperationsProblemTemplate(::Type{T}) where {T<:AbstractNetworkModel}

Creates a model reference of the InfrastructureOptimizationModels Optimization Problem.

Arguments

• model::Type{T<:AbstractNetworkModel}:

Example

template = PowerOperationsProblemTemplate(CopperPlateNetworkModel)

Reuse a factorization core the caller already built — the cheapest reuse, since the PTDF and MODF wrappers are derived from it without re-factorizing the ABA matrix.

Reuse a VirtualPTDF the caller already built, including its populated row cache. Its own reduction becomes the build's reduction; the reduction exceptions derived from the template are not applied, because the matrix already exists.

Only a VirtualPTDF is accepted: it carries the factorization core, so a MODF sharing its reduction can be derived from it. A dense PNM.PTDF carries no core and is deliberately not a valid source.

PresetTimeCondition(time_stamps::Vector{Dates.DateTime})

Event condition that is triggered at pre-determined times.

Quadratic Loss InterconnectingConverter: the v·I / I² loss terms are bridged to IOM's approximation API — exact by default ("none", an NLP) or replaced with tolerance-driven linear surrogates under a linearizing scheme. See BILINEAR_APPROX_DEFAULT_ATTRIBUTES for the approximation attributes; here "bilinear_quadratic_method" also sizes the standalone I² loss term for every scheme.

Struct to create the RampConstraint associated with a specified thermal device or reserve service.

For thermal units, see more information in Thermal Formulations. The constraint is as follows:

\[-R^\text{th,dn} \le p_t^\text{th} - p_{t-1}^\text{th} \le R^\text{th,up}, \quad \forall t\in \{1, \dots, T\}\]

For Ramp Reserve, see more information in Service Formulations. The constraint is as follows:

\[r_{d,t} \le R^\text{th,up} \cdot \text{TF}\quad \forall d\in \mathcal{D}_s, \forall t\in \{1,\dots, T\}, \quad \text{(for ReserveUp)} \\ r_{d,t} \le R^\text{th,dn} \cdot \text{TF}\quad \forall d\in \mathcal{D}_s, \forall t\in \{1,\dots, T\}, \quad \text{(for ReserveDown)}\]

Struct to add reserves to be larger than a specified requirement, with ramp constraints

Struct for to add reserves to be larger than a specified requirement

Imposed by transformer circuits with REACTIVEPOWERFLOW control on a branch formulation with controls enabled.

Parameter to define reactive power offset during an event.

Struct to create the constraint that bounds a device's reactive power by its available capacity squared during an outage event.

\[q_t^2 \le \max\left((Q^\text{max})^2, (Q^\text{min})^2\right) \cdot \text{status}_t, \quad \forall t \in \{1,\dots,T\}\]

Parameter to define reactive power time series

Struct to dispatch the creation of Reactive Power Variables

Docs abbreviation: $q$

Struct to create the constraint to balance shifted power over the user-defined time horizons. For more information check the PowerLoadShift formulation. The specified constraints are formulated as:

\[p_t^\text{realized} \ge 0.0 , \quad \forall k \text{ time horizons}\]

Pins the voltage angle (and, for ACP, voltage magnitude) of a subnetwork's reference (slack) bus.

Component-owned auxiliary voltage-magnitude variable used to regulate a bus voltage under rectangular AC formulations (ACR/IVR), which expose no scalar magnitude primitive. Keyed by the regulating component name and scoped to that component's regulated bus, it is bounded by the regulated bus's voltage limits and tied to the bus by RegulatedVoltageMagnitudeConstraint (vm_reg² == vr² + vi²). Only created under ACR/IVR; under ACP the network VoltageMagnitude is regulated directly.

Docs abbreviation: $v^\text{reg}$

Ties a component-owned RegulatedVoltageMagnitude auxiliary variable to the rectangular voltage components at its regulated bus under ACR/IVR formulations. One entry per regulating device per time step:

\[(v^{\text{reg}}_{d,t})^2 = v_{r,n(d),t}^2 + v_{i,n(d),t}^2, \quad \forall d \in \mathcal{D},\, t \in \{1,\dots,T\}\]

Created by VoltageControlVSC and VoltageControlConverter (and ShuntSusceptanceDispatch for FACTSControlDevice). Under ACP the network VoltageMagnitude is a scalar primitive, so neither this constraint nor RegulatedVoltageMagnitude is added.

Formulation type to add real and reactive injection variables with constant power factor with maximum real power injections constrained by a time series for RenewableGen

Formulation type to add injection variables constrained by a maximum injection time series for RenewableGen

Struct to create the constraint for satisfying active power reserve requirements. For more information check Service Formulations.

The constraint is as follows:

\[\sum_{d\in\mathcal{D}_s} r_{d,t} + r_t^\text{sl} \ge \text{Req},\quad \forall t\in \{1,\dots, T\} \quad \text{(static requirement)} \\ \sum_{d\in\mathcal{D}_s} r_{d,t} + r_t^\text{sl} \ge \text{RequirementTimeSeriesParameter}_{t},\quad \forall t\in \{1,\dots, T\} \quad \text{(time-varying requirement)}\]

Parameter to define requirement time series

Struct to specify the lower and upper bounds of the charge variable considering reserves.

The specified constraints are formulated as:

\[\begin{align*} &p^{st, ch}_{t} + \sum_{p \in \mathcal{P}^{\text{as}_\text{dn}}} sb_{stc,p,t} \leq (1 - \text{ss}^{st}_{t})P^{max,ch}_{st}, \quad \forall t \in \{1,\dots, T\} \\ & p^{st, ch}_{t} - \sum_{p \in \mathcal{P}^{\text{as}_\text{up}}} sb_{stc,p,t} \geq 0, \quad \forall t \in \{1,\dots, T\} \end{align*}\]

Struct to specify all products ancillary service coverage at the beginning of the period for charge and discharge variables. Used when the attribute complete_coverage = true.

The specified constraints are formulated as:

\[\begin{align*} & \sum_{p \in \mathcal{P}^{\text{as}_\text{dn}}} sb_{stc,p,1} \eta^{ch}_{st} N_{p} \Delta t \le E_{st}^{max} - e^{st}_0 \\ & \sum_{p \in \mathcal{P}^{\text{as}_\text{dn}}} sb_{stc,p,t} \eta^{ch}_{st} N_{p} \Delta t \le E_{st}^{max} - e^{st}_{t-1}, \quad \forall t \in \{2,\dots, T\} \\ & \sum_{p \in \mathcal{P}^{\text{as}_\text{up}}} sb_{std,p,1} \frac{1}{\eta^{ds}_{st}} N_{p} \Delta t \leq e^{st}_0 - E^{min}_{st} \\ & \sum_{p \in \mathcal{P}^{\text{as}_\text{up}}} sb_{std,p,t} \frac{1}{\eta^{ds}_{st}} N_{p} \Delta t \leq e^{st}_{t-1}- E^{min}_{st}, \quad \forall t \in \{2,\dots, T\} \end{align*}\]

Struct to specify all products ancillary service coverage at the end of the period for charge and discharge variables. Used when the attribute complete_coverage = true.

The specified constraints are formulated as:

\[\begin{align*} & \sum_{p \in \mathcal{P}^{\text{as}_\text{dn}}} sb_{stc,p,t} \eta^{ch}_{st} N_{p} \Delta t \le E_{st}^{max} - e^{st}_{t}, \quad \forall t \in \{1,\dots, T\} \\ & \sum_{p \in \mathcal{P}^{\text{as}_\text{up}}} sb_{std,p,t} \frac{1}{\eta^{ds}_{st}} N_{p} \Delta t \leq e^{st}_{t}- E^{min}_{st}, \quad \forall t \in \{1,\dots, T\} \end{align*}\]

Struct to specify the individual product ancillary service coverage at the beginning of the period for charge and discharge variables.

The specified constraints are formulated as:

\[\begin{align*} & sb_{stc,p,1} \eta^{ch}_{st} N_{p} \Delta t \le E_{st}^{max} - e^{st}_0, \quad \forall p \in \mathcal{P}^{as_{dn}} \\ & sb_{stc,p,t} \eta^{ch}_{st} N_{p} \Delta t \le E_{st}^{max} - e^{st}_{t-1}, \quad \forall p \in \mathcal{P}^{as_{dn}}, \forall t \in \{2,\dots, T\} \\ & sb_{std,p,1} \frac{1}{\eta^{ds}_{st}} N_{p} \Delta t \leq e^{st}_0 - E^{min}_{st}, \quad \forall p \in \mathcal{P}^{as_{up}} \\ & sb_{std,p,t} \frac{1}{\eta^{ds}_{st}} N_{p} \Delta t \leq e^{st}_{t-1} - E^{min}_{st}, \quad \forall p \in \mathcal{P}^{as_{up}}, \forall t \in \{2,\dots, T\} \end{align*}\]

Struct to specify the individual product ancillary service coverage at the end of the period for charge and discharge variables.

The specified constraints are formulated as:

\[\begin{align*} & sb_{stc,p,t} \eta^{ch}_{st} N_{p} \Delta t \le E_{st}^{max} - e^{st}_{t}, \quad \forall p \in \mathcal{P}^{as_{dn}}, \forall t \in \{1,\dots, T\} \\ & sb_{std,p,t} \frac{1}{\eta^{ds}_{st}} N_{p} \Delta t \leq e^{st}_{t}- E^{min}_{st}, \quad \forall p \in \mathcal{P}^{as_{up}}, \forall t \in \{1,\dots, T\} \end{align*}\]

Struct to specify the lower and upper bounds of the discharge variable considering reserves.

The specified constraints are formulated as:

\[\begin{align*} & p^{st, ds}_{t} + \sum_{p \in \mathcal{P}^{\text{as}_\text{up}}} sb_{std,p,t} \leq \text{ss}^{st}_{t}P^{max,ds}_{st} \quad \forall t \in \{1,\dots, T\} \\ & p^{st, ds}_{t} - \sum_{p \in \mathcal{P}^{ ext{as}_\text{dn}}} sb_{std,p,t} \geq 0, \quad \forall t \in \{1,\dots, T\} \end{align*}\]

Struct to dispatch the creation of Reserve requirement slack variables. Used when there is not reserves in the system to satisfy the requirement.

Docs abbreviation: $r^\text{sl}$

Trait axis selecting how a reserve contribution is scaled into an aggregation: UnscaledReserve (raw multiplier) or DeployedReserve (scaled by deployed_fraction).

Trait axis selecting which side of a storage device or hybrid PCC a reserve variable acts on: DischargeSide (outflow) or ChargeSide (inflow).

Struct to model the transformation from head to volume constraint

\[v_{t} = h_{t} \text{head_to_volume},\]

Struct to create the constraint for hydro reservoir storage

For more information check HydroPowerSimulations Formulations.

The specified constraint is formulated as:

\[\ v_{t} = v_{t-1} + \Delta t (f^{UR}_{t-1} - f^{Sp}_{t-1} - f^{Tu}_{t-1})\]

Struct to model reservoir stored volume/head limits

\[h_{t}^{min} \le h_{t} \le h_{t}^{max},\]

Struct to model the final (target) volume/head storage constraint

\[v_{T} = V^\text{target},\]

ReservoirLimitFeedforward(
    component_type::Type{<:PSY.Component},
    source::Type{T},
    affected_values::Vector{DataType},
    number_of_periods::Int,
    meta = CONTAINER_KEY_EMPTY_META
) where {T}

Bounds the sum of a variable over consecutive blocks of number_of_periods time steps to a per-block limit read from the system state. For example, in a 24-step model, number_of_periods = 24 builds a single constraint over the whole horizon, while number_of_periods = 12 builds two constraints, one per 12-step block. number_of_periods must divide the horizon length evenly.

Arguments:

• component_type::Type{<:PSY.Component} : Specify the type of component on which the Feedforward will be applied
• source::Type{T} : The VariableType, ParameterType, or AuxVariableType naming the quantity in the system state that the Feedforward reads
• affected_values::Vector{DataType} : Specify the variable the reservoir limit will be applied to
• number_of_periods::Int : The number of consecutive time steps each constraint sums over

Reservoir energy limit read from the system state

ReservoirTargetFeedforward(
    component_type::Type{<:PSY.Component},
    source::Type{T},
    affected_values::Vector{DataType},
    target_period::Int,
    penalty_cost::Float64,
    meta = CONTAINER_KEY_EMPTY_META
) where {T}

Holds a reservoir variable to a minimum target read from the system state at a single time step. The bound is relaxed by a HydroEnergyShortageVariable slack, penalized in the objective at penalty_cost, so the model stays feasible when the state's target cannot be reached exactly.

Arguments:

• component_type::Type{<:PSY.Component} : Specify the type of component on which the Feedforward will be applied
• source::Type{T} : The VariableType, ParameterType, or AuxVariableType naming the quantity in the system state that the Feedforward reads
• affected_values::Vector{DataType} : Specify the variable the reservoir target will be applied to
• target_period::Int : The time step at which the target is enforced
• penalty_cost::Float64 : The objective penalty applied to the shortage slack

Reservoir energy target read from the system state

RuntimeStateInput()

Request for the runtime's state object itself, passed through to user code untouched. Declared only by DiscreteEventCondition, whose whole purpose is a predicate POM cannot anticipate; every other condition is a function of declared values.

Security-constrained branch formulation that enforces post-contingency emergency flow limits as inequality constraints on ACTransmission branches under N-k contingency scenarios. The set of contingencies modeled is the union of outages configured on each DeviceModel{<:ACTransmission, <:AbstractSecurityConstrainedStaticBranch} in the template.

Concretely, for every monitored ACTransmission branch and every claimed outage, this formulation adds:

-rate_emergency ≤ post_contingency_flow ≤ rate_emergency

where post_contingency_flow is derived from the modification factors (MODF) provided by PowerNetworkMatrices and rate_emergency comes from the branch's rating_b (falling back to rating only when rating_b is unset), and becomes time-varying when a PostContingencyBranchRatingTimeSeriesParameter is attached.

Outage modeling notes:

• An outage UUID is "claimed" by DeviceModel{D, SC} iff D is among the types of the outaged (associated) components on that outage. A multi-component outage is therefore claimed by every SC DeviceModel whose component type appears in its outaged set; the post-contingency build deduplicates by referencing the first claimer. The OUTAGED component's type — not the monitored components — must be covered by an SC DeviceModel for the outage to contribute any constraints.
• The monitored set is whatever each outage explicitly lists in its monitored_components. There is no implicit "monitor everything" default: an outage with empty monitored_components monitors nothing (a warning is emitted) and contributes no post-contingency constraints. This is deliberate — defaulting to monitoring every branch under every outage would silently produce an N-1-everything-by-everything problem that is intractable for realistic systems; the user must opt in to each monitored branch.
• A monitored component whose type is not a modeled PSY.ACTransmission branch type (either absent from the template, or modeled but not a branch) is skipped (warned once per type at template validation; no post-contingency constraints are built for it).
• PSY.PlannedOutage instances are excluded by default; set attributes = Dict("include_planned_outages" => true) on the DeviceModel to include them.
• Both the monitored AND the outaged component endpoints are pinned in the network reduction (added to irreducible_buses). This prevents radial / degree-two reductions from collapsing the contingency arc out of the reduced topology, which would otherwise leave PNM's MODF column without a matching arc to apply.

SemiContinuousFeedforward(
    component_type::Type{<:PSY.Component},
    source::Type{T},
    affected_values::Vector{DataType},
    meta = CONTAINER_KEY_EMPTY_META
) where {T}

Bounds a variable to zero or to the device's operating range according to a commitment status recorded in the system state. Commonly used to hold the ActivePowerVariable of an Economic Dispatch to the units the system state reports as online. A DeviceModel can carry at most one SemiContinuousFeedforward per component type; attach_feedforward! rejects a second.

Arguments:

• component_type::Type{<:PSY.Component} : Specify the type of component on which the Feedforward will be applied
• source::Type{T} : The VariableType or AuxVariableType naming the quantity in the system state that the Feedforward reads
• affected_values::Vector{DataType} : Specify the variable on which the semicontinuous limit will be applied from the state values

Struct to dispatch the creation of Shifted Down Active Power Variables Docs abbreviation: $p^\text{shift,dn}$

Struct to create the constraint to limit shifted power active power between upper and lower bounds. For more information check the PowerLoadShift formulation. The specified constraints are formulated as:

\[0 \le p_t^\text{shift, dn} \le P_t^\text{lower}, \quad \forall t \in \{1,\dots,T\}\]

Struct to dispatch the creation of Shifted Up Active Power Variables Docs abbreviation: $p^\text{shift,up}$

Struct to create the constraint to limit shifted power active power between upper and lower bounds. For more information check the PowerLoadShift formulation. The specified constraints are formulated as:

\[0 \le p_t^\text{shift, up} \le P_t^\text{upper}, \quad \forall t \in \{1,\dots,T\}\]

Struct to create the constraint to balance shifted power over the user-defined time horizons. For more information check the PowerLoadShift formulation. The specified constraints are formulated as:

\[\sum_{t \in \text{time horizon}_k } p_t^\text{shift,up} - p_t^\text{shift,dn} = 0 , \quad \forall k \text{ time horizons}\]

Coupling constraint linking a controllable shunt's reactive injection to its ShuntSusceptanceVariable and the local bus voltage. Used by ShuntSusceptanceDispatch under all AC network models (ACP/ACR/IVR):

\[Q_{d,t} = b_{d,t} \cdot V_{n(d),t}^2, \quad \forall d \in \mathcal{D},\, t \in \{1,\dots,T\}\]

Under ACP, $V^2 = v_{n(d),t}^2$ (scalar magnitude squared); under ACR/IVR, $V^2 = v_{r,n(d),t}^2 + v_{i,n(d),t}^2$ (rectangular components). The constraint is always created regardless of control mode; the voltage-control objective is applied separately via a JuMP.fix on the regulated bus magnitude.

Continuous controllable shunt susceptance b ∈ [b_min, b_max] injecting Q = b·V² into the reactive nodal balance, for SwitchedAdmittance (continuous relaxation of the switched blocks) and FACTSControlDevice (SVC/STATCOM). Under a voltage control objective the regulated bus voltage is fixed to its setpoint. Only valid under AC network models; dropped from DC templates automatically via models_reactive_power.

Continuous shunt susceptance $b$ (pu on system MVA base) dispatched by ShuntSusceptanceDispatch for PSY.SwitchedAdmittance and PSY.FACTSControlDevice. Bounded by the device susceptance range: for SwitchedAdmittance, the span its blocks can reach (continuous relaxation of discrete steps); for FACTSControlDevice, the per-unit conversion of max_shunt_current. Enters ShuntReactivePowerConstraint as $Q = b \cdot V^2$. Only valid under AC network models.

Docs abbreviation: $b$

Struct to create the start-up time limit constraints for ThermalMultiStart.

For more information check ThermalGen Formulations for ThermalMultiStartUnitCommitment.

StateValueInput(target::VariableTarget)

Request for the runtime's current value of one optimization variable, for one device.

StateVariableValueCondition(variable_type, device_type, device_name, value)

Event condition triggered when the monitored variable equals value (p.u.).

Struct to create the state of charge constraint limits.

The specified constraint is formulated as:

\[E_{st}^{min} \le e^{st}_{t} \le E_{st}^{max}, \quad \forall t \in \{1,\dots, T\}\]

Struct to create the state of charge target constraint at the end of period. Used when the attribute energy_target = true.

The specified constraint is formulated as:

\[e^{st}_{T} + e^{st+} - e^{st-} = E^{st}_{T},\]

Branch type to add unbounded flow variables and use flow constraints

Branch type to add bounded flow variables and use flow constraints

Branch type to avoid flow constraints

Formulation type to add a time series parameter for non-dispatchable ElectricLoad withdrawals to power balance constraints

Struct for to add reserves to be larger than a variable requirement depending of costs

Slack variable for the cycling limits to allow for more charging usage than the allowed limited

Docs nomenclature: $c^{ch-}$

Struct to create the storage cycling limits for the charge variable. Used when cycling_limits = true.

The specified constraint is formulated as:

\[\sum_{t \in \mathcal{T}} \left(\sum_{p \in \mathcal{P}^{\text{as}_\text{dn}}} R^*_{p,t} sb_{stc,p,t} + p^{st,ch}_{t} \right)\eta^{ch}_{st} \Delta t - c^{ch-} \leq C_{st} E^{max}_{st}\]

Struct to create the storage cycling limits for the discharge variable. Used when cycling_limits = true.

The specified constraint is formulated as:

\[\sum_{t \in \mathcal{T}} \left(\sum_{p \in \mathcal{P}^{\text{as}_\text{up}}} R^*_{p,t} sb_{std,p,t} + p^{st,ds}_{t}\right)\frac{1}{\eta^{ds}_{st}} \Delta t - c^{ds-} \leq C_{st} E^{max}_{st}\]

Slack variable for the cycling limits to allow for more discharging usage than the allowed limited

Docs nomenclature: $c^{ds-}$

Formulation type to add storage formulation than can provide ancillary services. If a storage unit does not contribute to any service, then the variables and constraints related to services are ignored.

Example

DeviceModel(
    StorageType, # E.g. EnergyReservoirStorage or GenericStorage
    StorageDispatchWithReserves;
    attributes=Dict(
        "reservation" => true,
        "cycling_limits" => false,
        "energy_target" => false,
        "complete_coverage" => false,
        "regularization" => true,
    ),
    use_slacks=false,
)

The formulation supports the following attributes when used in a PowerSimulations.DeviceModel:

Attributes

• "reservation": Forces the storage to operate exclusively on charge or discharge mode through the entire operation interval. We recommend setting this to false for models with relatively longer time resolutions (e.g., 1-Hr) since the storage can take simultaneous charge or discharge positions on average over the period.
• "cycling_limits": This limits the storage's energy cycling. A single charging (discharging) cycle is fully charging (discharging) the storage once. The calculation uses the total energy charge/discharge and the number of cycles. Currently, the formulation only supports a fixed value per operation period. Additional variables for StorageChargeCyclingSlackVariable and StorageDischargeCyclingSlackVariable are included in the model if use_slacks is set to true.
• "energy_target": Set a target at the end of the model horizon for the storage's state of charge. Currently, the formulation only supports a fixed value per operation period. Additional variables for StorageEnergyShortageVariable and StorageEnergySurplusVariable are included in the model if use_slacks is set to true.

• "reserve_coverage": Couples ancillary-service awards to the physical energy schedule. When true (default), the storage's state of charge must cover each service's sustained deployment (ReserveCoverageConstraint at both period endpoints) and the reserve band is limited by the reservation binary's dispatch side. Set false to DECOUPLE energy and AS, mirroring day-ahead market clearing (e.g., ERCOT DAM): AS awards are bounded by offer quantity and power capability only - no SOC feasibility, no reservation-binary coupling (the binary still governs energy charge/discharge exclusivity), no expected reserve-deployment energy in the SOC balance (deployment is a real-time settlement concept), and complete_coverage is ignored (with a warning).
• "complete_coverage": This attribute implements constraints that require the battery to cover the sum of all the ancillary services it participates in simultaneously. It is equivalent to holding energy in case all the services get deployed simultaneously. This constraint is added to the constraints that cover each service independently and corresponds to a more conservative operation regime.
• "regularization": This attribute smooths the charge/discharge profiles to avoid bang-bang solutions via a penalty on the absolute value of the intra-temporal variations of the charge and discharge power. Solving for optimal storage dispatch can stall in models with large amounts of curtailment or long periods with negative or zero prices due to numerical degeneracy. The regularization term is scaled by the storage device's power limits to normalize the term and avoid additional penalties to larger storage units.

See the Formulation Library for the full mathematical description.

Auxiliary Variable for Storage Models that solve for total energy output

Slack variable for energy storage levels < target storage levels

Docs abbreviation: $e^{st-}$

Slack variable for energy storage levels > target storage levels

Docs abbreviation: $e^{st+}$

Struct to specify the auxiliary constraints for regularization terms in the objective function for the charge variable. Used when the attribute regularization = true.

The specified constraints are formulated as:

\[\begin{align*} & \left(\sum_{p \in \mathcal{P}^{\text{as}_\text{dn}}} R^*_{p,t-1} sb_{stc,p,t-1} + p^{st,ch}_{t-1} - \sum_{p \in \mathcal{P}^{\text{as}_\text{up}}} R^*_{p,t-1} sb_{stc,p,t-1}\right) - \left(\sum_{p \in \mathcal{P}^{\text{as}_\text{dn}}} R^*_{p,t} sb_{stc,p,t} + p^{st,ch}_{t} - \sum_{p \in \mathcal{P}^{\text{as}_\text{up}}} R^*_{p,t} sb_{stc,p,t}\right) \le z^{st, ch}_{t}, \forall t \in \{2,\dots, T\}\\ & \left(\sum_{p \in \mathcal{P}^{\text{as}_\text{dn}}} R^*_{p,t-1} sb_{stc,p,t-1} + p^{st,ch}_{t-1} - \sum_{p \in \mathcal{P}^{\text{as}_\text{up}}} R^*_{p,t-1} sb_{stc,p,t-1}\right) - \left(\sum_{p \in \mathcal{P}^{\text{as}_\text{dn}}} R^*_{p,t} sb_{stc,p,t} + p^{st,ch}_{t} - \sum_{p \in \mathcal{P}^{\text{as}_\text{up}}} R^*_{p,t} sb_{stc,p,t}\right) \ge -z^{st, ch}_{t}, \forall t \in \{2,\dots, T\} \end{align*}\]

Struct to specify the auxiliary constraints for regularization terms in the objective function for the discharge variable. Used when the attribute regularization = true.

The specified constraints are formulated as:

\[\begin{align*} & \left(\sum_{p \in \mathcal{P}^{\text{as}_\text{up}}} R^*_{p,t-1} sb_{std,p,t-1} + p^{st,ds}_{t-1} - \sum_{p \in \mathcal{P}^{\text{as}_\text{dn}}} R^*_{p,t-1} sb_{std,p,t-1}\right) -\left(\sum_{p \in \mathcal{P}^{\text{as}_\text{up}}} R^*_{p,t} sb_{std,p,t} + p^{st,ds}_{t} - \sum_{p \in \mathcal{P}^{\text{as}_ ext{dn}}} R^*_{p,t} sb_{std,p,t}\right) \le z^{st, ds}_{t}, \forall t \in \{2,\dots, T\}\\ & \left(\sum_{p \in \mathcal{P}^{\text{as}_\text{up}}} R^*_{p,t-1} sb_{std,p,t-1} + p^{st,ds}_{t-1} - \sum_{p \in \mathcal{P}^{\text{as}_\text{dn}}} R^*_{p,t-1} sb_{std,p,t-1}\right) -\left(\sum_{p \in \mathcal{P}^{\text{as}_\text{up}}} R^*_{p,t} sb_{std,p,t} + p^{st,ds}_{t} - \sum_{p \in \mathcal{P}^{\text{as}_ ext{dn}}} R^*_{p,t} sb_{std,p,t}\right) \ge -z^{st, ds}_{t}, \forall t \in \{2,\dots, T\} \end{align*}\]

Slack variable for energy storage levels > target storage levels

Docs nomenclature: $z^{st, ch}$

Slack variable for energy storage levels > target storage levels

Docs abbreviation: $z^{st, ds}$

Struct to specify an auxiliary constraint for adding charge and discharge into a single active power reserve variable.

The specified constraint is formulated as:

\[sb_{stc, p, t} + sb_{std, p, t} = r_{p,t}, \quad \forall p \in \mathcal{P}, \forall t \in \{1,\dots, T\}\]

Formulation type to add reactive power dispatch variables for SynchronousCondenser. A condenser supplies only reactive power, so it is only meaningful under network models with a reactive power balance; dropped from DC templates automatically via models_reactive_power.

Struct to dispatch the creation of System-wide slack down variables. Used when there is not enough load curtailment.

Docs abbreviation: $p^\text{sl,dn}$

Struct to dispatch the creation of System-wide slack up variables. Used when there is not enough generation.

Docs abbreviation: $p^\text{sl,up}$

Build the network from the system, applying reductions, honoring the build's reduction exceptions, and sparsifying the derived sensitivity matrices at tolerance. The two are independent knobs on the same construction step.

tolerance is the per-row sparsification cutoff handed to PNM.VirtualFactorCore: a Float64 is an absolute cutoff, a PNM.AutoTolerance a relative, size-adaptive one. It reaches every matrix wrapping that core — PTDF and MODF alike. The default is PNM's own auto rule, so POM does not second-guess it with a fixed cutoff of its own.

A zero-impedance branch reduction is always applied first. Include a ZeroImpedanceBranchReduction to override its parameters; it replaces that step rather than adding one, so its position in the vector is irrelevant. More than one errors.

Continuous off-nominal turns ratio $t \in [t_{\min}, t_{\max}]$ (pu) for a transformer circuit whose control objective is modeled. The variable enters the AC π-model Ohm's law nonlinearly: self terms scale as $1/t^2$, coupling terms scale as $1/t$, so the formulation reduces to StaticBranch when $t = t_m$ (the nominal tap). Warm-started at the transformer's current tap position. Both bounds must be finite and positive (validated at construction time). Only valid under AC network models.

Docs abbreviation: $t$

Formulation type to enable thermal compact commitment without intertemporal (ramp, min on/off time) constraints

Formulation type to enable basic dispatch without any intertemporal (ramp) constraints

Formulation type to enable basic unit commitment representation without any intertemporal (ramp, min on/off time) constraints

Formulation type to enable thermal compact dispatch

Formulation type to enable thermal compact commitment

Formulation type to enable basic dispatch without any intertemporal constraints and relaxed minimum generation. May not work with non-convex PWL cost definitions

Formulation type to enable pg-lib commitment formulation with startup/shutdown profiles

Formulation type to enable standard dispatch with a range and enforce intertemporal ramp constraints

Formulation type to enable standard unit commitment with intertemporal constraints and simplified startup profiles

Auxiliary Variable for Thermal Generation Models to keep track of time elapsed off

Auxiliary Variable for Thermal Generation Models to keep track of time elapsed on

Expression for PowerSystems.HydroReservoir that keep track of total water flow turbined into a reservoir, from all the upstream turbines connected to it

Expression for PowerSystems.HydroReservoir that keep track of total water turbined for a reservoir, from all the downstream turbines connected to it

Expression for PowerSystems.HydroGen that keep track of total water turbined for a turbine, coming from multiple reservoirs

Expression for `PowerSystems.HydroReservoir that keep track of total power into a reservoir, from all the upstream turbines connected to it

Expression for `PowerSystems.HydroReservoir that keep track of total power out of a reservoir, from all the downstream turbines connected to it

Per-device, per-service aggregation of the reserve quantity offered by a storage device (or the storage subcomponent of a hybrid system). One container is created per service participated in, and the per-component reserve variables (charging + discharging) are summed into it. Consumed by HybridReserveBalanceConstraint and used as the right-hand side of the system-level reserve balance.

Expression for `PowerSystems.HydroReservoir that keep track of total spillage water flow rate into a reservoir, from all the upstream reservoirs connected to it

Expression for `PowerSystems.HydroReservoir that keep track of total spillage power into a reservoir, from all the upstream reservoirs connected to it

Transport Lossless HVDC network model. No DC voltage variables are added and DC lines are modeled as lossless power transport elements

Struct to model turbine power output as a function of head

\[p_{t} = \eta \rho g h_{t} f^{Tu}_{t},\]

Reserve aggregation that uses the raw multiplier (1.0).

Struct to dispatch the creation of Slack variables that relax an UpperBoundFeedforward constraint, penalized in the objective at BALANCE_SLACK_COST

Docs abbreviation: $p^\text{ff,ubsl}$

UpperBoundFeedforward(
    component_type::Type{<:PSY.Component},
    source::Type{T},
    affected_values::Vector{DataType},
    add_slacks::Bool = false,
    meta = CONTAINER_KEY_EMPTY_META
) where {T}

Constructs a parameterized upper bound constraint from a quantity in the system state.

Arguments:

• component_type::Type{<:PSY.Component} : Specify the type of component on which the Feedforward will be applied
• source::Type{T} : The VariableType or AuxVariableType naming the quantity in the system state that the Feedforward reads
• affected_values::Vector{DataType} : Specify the variable on which the upper bound will be applied from the state values
• add_slacks::Bool = false : Add slacks variables to relax the upper bound constraint.

Parameter to define variable upper bound

Struct to add a variable maximum transmission flow for specified interface

Struct to dispatch the creation of Voltage Angle Variables for AC/DC formulations

Docs abbreviation: $\theta$

Imposed by transformer circuits with VOLTAGE control on a branch formulation with controls enabled.

AC/DC InterconnectingConverter formulation for AC network models (ACP/ACR/IVR/LPACC). Builds the same DC-side physics as QuadraticLossConverter — the ActivePowerVariable, ConverterCurrent/CurrentAbsoluteValueVariable, the per-DCBus DCVoltage, the DCCurrentBalance wiring and the quadratic ConverterLossConstraint — and adds the AC-side representation: a bounded ReactivePowerVariable injected into ReactivePowerBalance at the converter's AC bus, the apparent-power capability disk $p^2 + q^2 \le \text{rating}^2$, and a count-invariant control layer driven by the converter's ac_control / dc_control modes.

AC control: AC_VOLTAGE regulates the AC bus voltage to ac_setpoint (under ACP by fixing the network VoltageMagnitude; under LPACC by fixing the VoltageDeviation phi = |V| - 1 to ac_setpoint - 1; under ACR/IVR via a component-owned RegulatedVoltageMagnitude aux variable); AC_REACTIVE_POWER is not supported and fails template validation. DC control adds one always-present HVDCDCControlConstraint per converter per time step: DC_VOLTAGE → vdc = dc_setpoint, DC_POWER → p = dc_setpoint, DC_VOLTAGE_DROOP → vdc + dc_voltage_droop * p = dc_setpoint. The aux voltage variable + its constraint and the HVDCDCControlConstraint are created regardless of mode, so variable/constraint containers are identical across all control modes (only per-mode coefficients / JuMP.fix differ). Only valid under AC network models; dropped from DC templates automatically via models_reactive_power. Requires a VoltageDispatchHVDCNetworkModel HVDC network model (for the DCVoltage / DCCurrentBalance DC-side) and finite reactive_power_limits on each converter.

Two-terminal VSC formulation with reactive / voltage control (Family C). Builds the exact same NLP physics as HVDCTwoTerminalVSC — per-terminal converter losses, a shared signed cable current, the DC cable Ohm's law, bounded per-terminal reactive injection into ReactivePowerBalance, and the apparent-power capability disk $p^2 + q^2 \le \text{rating}^2$ — and adds a count-invariant control layer driven by the converter's ac_control_* / dc_control_* modes. AC control pins one already-created variable per terminal with a single JuMP.fix (force = true): AC_VOLTAGE → the regulated AC-bus voltage (the VoltageMagnitude under ACP, the VoltageDeviation phi = |V| - 1 under LPACC, a per-terminal RegulatedVoltageMagnitude aux variable under ACR/IVR), AC_REACTIVE_POWER → the terminal reactive injection, at reactive_power_from / reactive_power_to. DC control adds one always-present HVDCDCControlConstraint per terminal per time step (DC_VOLTAGE / DC_POWER / DC_VOLTAGE_DROOP), so the variable/constraint containers are identical across all control modes. Only valid under AC network models (ACP/ACR/IVR/LPACC); dropped from DC templates automatically via models_reactive_power.

Struct to dispatch the creation of Voltage-Magnitude Deviation Variables (phi = |V| - 1) for the LPAC formulation, indexed by bus.

Docs abbreviation: $\phi$

DC Voltage HVDC network model, where currents are solved based on DC voltage difference between DC buses

Struct to dispatch the creation of Voltage Imaginary-Component Variables for rectangular-coordinate AC formulations

Docs abbreviation: $v_i$

Struct to dispatch the creation of Voltage Magnitude Variables for AC formulations

Docs abbreviation: $v$

Rectangular-coordinate voltage magnitude bounds: vmin² ≤ vr² + vi² ≤ vmax².

Struct to dispatch the creation of Voltage Real-Component Variables for rectangular-coordinate AC formulations

Docs abbreviation: $v_r$

Struct to dispatch the creation of Warm Start Variable for Thermal units with temperature considerations

Docs abbreviation: $y^\text{th}$

Struct to create the constraint that limits the budget for reservoir formulations.

For more information check HydroPowerSimulations Formulations.

The specified constraint is formulated as:

\[\sum_{t=1}^T f^\text{hy}_t \le \sum_{t=1}^T \text{WaterBudgetTimeSeriesParameter}_t,\]

Parameter to define water budget time series for hydro reservoirs. The timeseries must be specified in average water flow in cubic meters per second.

WaterLevelBudgetFeedforward(
    component_type::Type{<:PSY.Component},
    source::Type{T},
    affected_values::Vector{DataType},
    meta = CONTAINER_KEY_EMPTY_META
) where {T}

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

Arguments:

• component_type::Type{<:PSY.Component} : Specify the type of component on which the Feedforward will be applied
• source::Type{T} : The VariableType, ParameterType, or ExpressionType naming the quantity in the system state that the Feedforward reads
• affected_values::Vector{DataType} : Specify the parameter on which the water budget will be applied from the state values

Reservoir water usage budget read from the system state

Struct to dispatch the creation of energy (water) spillage variable representing energy released from a storage/reservoir not injected into the network

Docs abbreviation: $s$

Struct to create the constraint that set-up the target for reservoir formulations. It can use head or volume as the storage variable.

For more information check HydroPowerSimulations Formulations.

The specified constraint is formulated as:

\[l_t + l^\text{shortage} + l^\text{surplus} = \text{WaterTargetTimeSeriesParameter}_t, \quad \forall t \in \{1,\dots, T\}\]

Parameter to define water storage target level time series for hydro reservoirs. It will depend on the ReservoirDataType specified for the reservoir, and can be head in meters or volume in cubic meters.

set_device_model!(
    template::PowerOperationsProblemTemplate,
    component_type::Type{<:PowerSystems.Device},
    formulation::Type{<:AbstractDeviceFormulation}
)

Sets the device model in a template using the component type and formulation. Builds a default DeviceModel

set_device_model!(
    template::PowerOperationsProblemTemplate,
    model::DeviceModel{D<:InfrastructureSystems.InfrastructureSystemsComponent}
)

Sets the device model in a template using a DeviceModel instance. Routes to devices dictionary.

set_device_model!(
    template::PowerOperationsProblemTemplate,
    model::DeviceModel{D<:PowerSystems.Branch}
)

Sets the device model in a template using a DeviceModel instance. Specialization for Branch types - routes to branches dictionary.

set_event_model!(
    template::PowerOperationsProblemTemplate,
    event_model::InfrastructureOptimizationModels.AbstractEventModel
)

set_event_model!(template::PowerOperationsProblemTemplate, event_model)

Attach an outage-event model to the template. At build time the event is validated, its attribute_device_map is populated from the system's supplemental attributes, and it is distributed to every matching DeviceModel.

set_hvdc_network_model!(
    template::PowerOperationsProblemTemplate,
    model::Union{Nothing, AbstractHVDCNetworkModel}
)

Sets the network model in a template.

set_hvdc_network_model!(
    template::PowerOperationsProblemTemplate,
    model::Type{U<:AbstractHVDCNetworkModel}
)

Sets the network model in a template.

set_network_model!(
    template::PowerOperationsProblemTemplate,
    model::NetworkModel
)

Sets the network model in a template.

set_service_model!(
    template::PowerOperationsProblemTemplate,
    service_type::Type{<:PowerSystems.Service},
    formulation::Type{<:AbstractServiceFormulation}
)

Sets the service model in a template using the service type and formulation. One ServiceModel covers every service of its type in the system.

add_constraints!(
    container::OptimizationContainer,
    _::Type{RequirementConstraint},
    service::PowerSystems.GroupReserve,
    contributing_services::Vector{<:PowerSystems.Service},
    model::ServiceModel{SR<:PowerSystems.GroupReserve, GroupRangeReserve}
)

This function creates the requirement constraint that will be attained by the appropriate services

add_constraints!(
    container::OptimizationContainer,
    _::Type{RequirementConstraint},
    service::PowerSystems.GroupReserve,
    contributing_services::Vector{<:PowerSystems.Service},
    model::ServiceModel{SR<:PowerSystems.GroupReserve, GroupStepwiseCostReserve}
)

Clearing constraint for GroupStepwiseCostReserve: the summed member awards cover the group's ServiceRequirementVariable (the demand bought along the group's curve). Its dual is the group clearing price.

add_constraints!(
    _::OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ConstraintType},
    devices::Array{U<:InfrastructureSystems.InfrastructureSystemsComponent, 1},
    model::DeviceModel{U<:InfrastructureSystems.InfrastructureSystemsComponent, F<:AbstractDeviceFormulation},
    network_model::NetworkModel{S}
)

Add constraints to the optimization container.

add_constraints!(
    container::OptimizationContainer,
    _::Type{FlowLimitConstraint},
    devices::Vector{PowerSystems.AreaInterchange},
    model::InfrastructureOptimizationModels.DeviceModelForBranches{PowerSystems.AreaInterchange, StaticBranch},
    _::NetworkModel{T<:AbstractNetworkModel}
)

Add flow constraints for area interchanges

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

Add branch flow rate (rating) inequalities for ACBranch StaticBranch under DCPNetworkModel, directly on the BThetaBranchFlow expression (no defining equality/variable to bound instead). Walks one representative per reduced arc and reuses the shared static/parameterized-rating row builders, mirroring the variable-based FlowRateConstraint DCP builder above but targeting the expression container.

add_constraints!(
    container::OptimizationContainer,
    cons_type::Type{PowerOperationsModels.NetworkFlowConstraint},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranchBounds},
    network_model::NetworkModel{<:AbstractPTDFNetworkModel}
)

Add network flow constraints for ACBranch and NetworkModel with <: AbstractPTDFNetworkModel

add_constraints!(
    container::OptimizationContainer,
    _::Type{PowerOperationsModels.StartupInitialConditionConstraint},
    devices::Array{T<:PowerSystems.ThermalMultiStart, 1},
    model::DeviceModel{T<:PowerSystems.ThermalMultiStart, ThermalMultiStartUnitCommitment},
    _::NetworkModel
)

Constructs contraints that restricts devices to one type of start at a time

Equations

ub: (time_limits[st+1]-1)*δ^{s}(t) + (1 - δ^{s}(t)) * M_VALUE >= sum(1-varbin[name, i]) for i in 1:t) + initial_condition_offtime lb: (time_limits[st]-1)*δ^{s}(t) =< sum(1-varbin[name, i]) for i in 1:t) + initial_condition_offtime

LaTeX

$TS^{s+1}_{g} δ^{s}(t) + (1-δ^{s}(t)) M_VALUE \geq \sum^{t}_{i=1} x^{status}(i) + DT_{g}^{0} \forall t in \{1, \ldots, TS^{s+1}_{g}$

$TS^{s}_{g} δ^{s}(t) \leq \sum^{t}_{i=1} x^{status}(i) + DT_{g}^{0} \forall t in \{1, \ldots, TS^{s+1}_{g}$

add_constraints!(
    container::OptimizationContainer,
    _::Type{StartTypeConstraint},
    devices::Array{T<:PowerSystems.ThermalMultiStart, 1},
    model::DeviceModel{T<:PowerSystems.ThermalMultiStart, ThermalMultiStartUnitCommitment},
    _::NetworkModel
)

Constructs contraints that restricts devices to one type of start at a time

Equations

sum(var_starts[name, s, t] for s in starts) = var_start[name, t]

LaTeX

$\sum^{S_g}_{s=1} δ^{s}(t) \eq x^{start}(t)$

add_constraints!(
    container::OptimizationContainer,
    _::Type{StartupTimeLimitTemperatureConstraint},
    devices::Array{T<:PowerSystems.ThermalMultiStart, 1},
    model::DeviceModel{T<:PowerSystems.ThermalMultiStart, ThermalMultiStartUnitCommitment},
    _::NetworkModel
)

Constructs contraints for different types of starts based on generator down-time

Equations

for t in time_limits[s+1]:T

var_starts[name, s, t] <= sum( var_stop[name, t-i] for i in time_limits[s]:(time_limits[s+1]-1)

LaTeX

$δ^{s}(t) \leq \sum_{i=TS^{s}_{g}}^{TS^{s+1}_{g}} x^{stop}(t-i)$

add_constraints!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::Type{AngleDifferenceConstraint},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    _::DeviceModel{T<:PowerSystems.ACTransmission, U<:AbstractBranchFormulation},
    network_model::NetworkModel{<:Union{ACPNetworkModel, DCPLLNetworkModel, DCPNetworkModel, LPACCNetworkModel}}
)

Add branch angle-difference limit constraints for ACBranch under DCP/ACP/DCPLL/LPACC network models.

Only branches for which PSY.get_angle_limits is defined (currently PSY.Line) and that carry non-trivial limits (i.e. not the ±π defaults) receive a constraint. Branches where the method is not defined are silently skipped.

add_constraints!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::Type{AngleDifferenceConstraint},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    _::DeviceModel{T<:PowerSystems.ACTransmission, U<:AbstractBranchFormulation},
    network_model::NetworkModel{<:Union{ACRNetworkModel, IVRNetworkModel}}
)

Add branch angle-difference limit constraints for ACBranch under the ACR/IVR rectangular coordinate formulations.

Uses the cross-product form: for each limited branch with angle limits (angmin, angmax), tan(angmin)·vvr ≤ vvi ≤ tan(angmax)·vvr where vvr = vrfr·vrto + vifr·vito (≈ vmfr·vmto·cos(Δθ)) vvi = vifr·vrto − vrfr·vito (≈ vmfr·vmto·sin(Δθ))

Matches PowerModels constraint_voltage_angle_difference for AbstractIVRModel. Only branches with non-default, non-±π limits receive a constraint (same filter as the polar form).

add_constraints!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::Type{CosineRelaxationConstraint},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    _::DeviceModel{T<:PowerSystems.ACTransmission, U<:AbstractBranchFormulation},
    network_model::NetworkModel{LPACCNetworkModel}
)

Add the LPAC convex cosine relaxation for ACBranch under LPACCNetworkModel:

cs ≤ 1 - (1 - cos(vad_max))/vad_max² · (va_fr - va_to)²

with vad_max = max(|angmin|, |angmax|). The right-hand side is concave in the angle difference, so the constraint is convex (a quadratic cut bounding cs from above).

add_constraints!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::Type{CurrentLimitConstraint},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, U<:AbstractBranchFormulation},
    network_model::NetworkModel{IVRNetworkModel}
)

Add terminal current-magnitude limit for ACBranch under IVRNetworkModel.

Constrains cr² + ci² ≤ crating² for both from- and to-terminal currents, where crating = rate_a / vmin (Principle 0: always finite).

add_constraints!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::Type{PowerOperationsModels.NetworkFlowConstraint},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, U<:AbstractBranchFormulation},
    network_model::NetworkModel{IVRNetworkModel}
)

Add IVR branch constraints for ACBranch under IVRNetworkModel.

Ten constraints per branch per time step: (1-4) Bilinear power-current linking: pft = vrfr·crfr + vifr·cifr, qft = vifr·crfr - vrfr·cifr ptf = vrto·crto + vito·cito, qtf = vito·crto - vrto·cito (5-6) KCL at from terminal (linear in crfr, cifr, csr, csi, vrfr, vifr). Multiplied through by tm² to stay polynomial. The magnetizing shunt hangs off the bus side of the ideal transformer, so it is not referred through the turns ratio and keeps its tm² factor here: crfr·tm² = tr·csr - ti·csi + (gfr·vrfr - bfr·vifr)·tm² cifr·tm² = tr·csi + ti·csr + (gfr·vifr + bfr·vrfr)·tm² (7-8) KCL at to terminal (linear): crto = -csr + gto·vrto - bto·vito cito = -csi + gto·vito + bto·vrto (9-10) Ohm's law across series impedance Z = r + jx = 1/(g + jb) (linear): vrto·tm² = vrfr·tr + vifr·ti - r·csr·tm² + x·csi·tm² vito·tm² = vifr·tr - vrfr·ti - r·csi·tm² - x·csr·tm²

add_constraints!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::Type{PowerOperationsModels.NetworkLossConstraint},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, U<:AbstractBranchFormulation},
    network_model::NetworkModel{DCPLLNetworkModel}
)

Add the DCPLL quadratic line-loss constraint:

p_fr + p_to >= r * p_fr^2

The sum of the two directional flows must cover the resistive loss. At the cost-minimizing optimum this binds, so the to-bus receives pfr minus the loss. Convex (Ipopt). r is the DC equivalent series resistance from `PNM.arcdc_resistance`.

add_constraints!(
    container::OptimizationContainer,
    _::Type{FlowRateConstraintFromTo},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, U<:AbstractBranchFormulation},
    network_model::NetworkModel{<:Union{ACPNetworkModel, ACRNetworkModel, IVRNetworkModel, LPACCNetworkModel}}
)

Add from-to apparent-power rate limit for ACBranch under native ACP/ACR/LPACC/IVR.

Constrains pft² + qft² ≤ rating².

add_constraints!(
    container::OptimizationContainer,
    _::Type{FlowRateConstraintToFrom},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, U<:AbstractBranchFormulation},
    network_model::NetworkModel{<:Union{ACPNetworkModel, ACRNetworkModel, IVRNetworkModel, LPACCNetworkModel}}
)

Add to-from apparent-power rate limit for ACBranch under native ACP/ACR/LPACC/IVR.

Constrains ptf² + qtf² ≤ rating².

add_constraints!(
    container::OptimizationContainer,
    _::Type{FlowRateConstraint},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, U<:AbstractBranchFormulation},
    network_model::NetworkModel{DCPLLNetworkModel}
)

Slacked flow rate limits for the DCPLL directional active-flow pair.

Built only when use_slacks = true: without slacks the rating is enforced as hard variable bounds (see _set_dcpll_flow_bounds!), which keeps the QCP tighter. Both directions share the branch's slack pair, so exceeding the rating in either direction is priced once.

add_constraints!(
    container::OptimizationContainer,
    _::Type{FlowRateConstraint},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, U<:AbstractBranchFormulation},
    network_model::NetworkModel{DCPNetworkModel}
)

Add branch flow rate (rating) constraints for ACBranch under DCPNetworkModel.

This is a simple lb/ub pair on the FlowActivePowerVariable that does not depend on the PTDF / network-reduction infrastructure used by the AbstractActivePowerModel dispatch.

add_constraints!(
    container::OptimizationContainer,
    cons_type::Type{FlowRateConstraint},
    devices::Array{T<:PowerSystems.ACTransmission, 1},
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, U<:AbstractBranchFormulation},
    network_model::NetworkModel{V<:AbstractActivePowerModel}
)

Add branch rate limit constraints for ACBranch with AbstractActivePowerModel

add_constraints!(
    container::OptimizationContainer,
    T::Type{RampConstraint},
    devices::Array{U<:PowerSystems.ThermalGen, 1},
    model::DeviceModel{U<:PowerSystems.ThermalGen, V<:InfrastructureOptimizationModels.AbstractThermalUnitCommitment},
    _::NetworkModel{W<:AbstractNetworkModel}
)

This function adds the ramping limits of generators when there are CommitmentVariables

add_constraints!(
    container::OptimizationContainer,
    _::Type{PowerOperationsModels.EnergyBalanceExpression},
    _::Type{EnergyBalanceConstraint},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function defines the constraints for the energy balance in a medium term planning problem.

add_constraints!(
    container::OptimizationContainer,
    cons_type::Type{T<:PostContingencyFlowRateConstraint},
    device_model::DeviceModel{V<:PowerSystems.ACTransmission, U<:PowerOperationsModels.AbstractSecurityConstrainedStaticBranch},
    network_model::NetworkModel{X<:AbstractNetworkModel}
)

Add branch post-contingency rate limit constraints for ACBranch considering MODF and Security Constraints

add_constraints!(
    container::OptimizationContainer,
    _::Type{EnergyBalanceConstraint},
    devices::Array{V<:PowerSystems.Storage, 1},
    model::DeviceModel{V<:PowerSystems.Storage, StorageDispatchWithReserves},
    network_model::NetworkModel{X<:AbstractNetworkModel}
)

Add Energy Balance Constraints for AbstractStorageFormulation

add_constraints!(
    container::OptimizationContainer,
    _::Type{T<:Union{ReserveChargeConstraint, ReserveDischargeConstraint}},
    devices::Array{V<:PowerSystems.Storage, 1},
    model::DeviceModel{V<:PowerSystems.Storage, StorageDispatchWithReserves},
    network_model::NetworkModel{X<:AbstractNetworkModel}
)

Reserve-assignment range constraints for discharge (T = ReserveDischargeConstraint) and charge (T = ReserveChargeConstraint) under StorageDispatchWithReserves.

add_constraints!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::Type{PowerOperationsModels.HydroPowerConstraint},
    devices::Vector{PowerSystems.HydroTurbine},
    model::DeviceModel{PowerSystems.HydroTurbine, W<:PowerOperationsModels.AbstractHydroReservoirFormulation},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function defines the constraint for the hydro power generation for the HydroWaterFactorModel.

add_constraints!(
    container::OptimizationContainer,
    _::Type{T<:PowerOperationsModels.HybridThermalOnVariableConstraint},
    devices::Array{V<:PowerSystems.HybridSystem, 1},
    model::DeviceModel{V<:PowerSystems.HybridSystem, W<:AbstractHybridFormulation},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Bound link between thermal subcomponent power and its commitment status (no-reserves case). Parametric on BoundDirection (from IOM): {UpperBound} enforces p_th ≤ max · on_var, {LowerBound} enforces p_th ≥ min · on_var.

add_constraints!(
    container::OptimizationContainer,
    _::Type{HybridRenewableActivePowerLimitConstraint},
    devices::Array{V<:PowerSystems.HybridSystem, 1},
    model::DeviceModel{V<:PowerSystems.HybridSystem, W<:AbstractHybridFormulation},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Cap renewable subcomponent power at the time-series-derived available output (0 ≤ p_renewable[t] ≤ multiplier · ts[t]).

add_constraints!(
    container::OptimizationContainer,
    _::Type{HybridRenewableReserveLimitConstraint},
    devices::Array{V<:PowerSystems.HybridSystem, 1},
    model::DeviceModel{V<:PowerSystems.HybridSystem, W<:AbstractHybridFormulationWithReserves},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Range constraint on renewable subcomponent power accounting for reserves. Mirrors HSS RenewableReserveLimit.

add_constraints!(
    container::OptimizationContainer,
    _::Type{HybridThermalReserveLimitConstraint},
    devices::Array{V<:PowerSystems.HybridSystem, 1},
    model::DeviceModel{V<:PowerSystems.HybridSystem, W<:AbstractHybridFormulationWithReserves},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Range constraint on the thermal subcomponent's active power, accounting for up/down reserve allocations. Mirrors HSS ThermalReserveLimit (HSS add_constraints.jl:1495–1506).

add_constraints!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::Type{EnergyBalanceConstraint},
    devices::Array{V<:PowerSystems.HydroReservoir, 1},
    model::DeviceModel{V<:PowerSystems.HydroReservoir, W<:HydroEnergyModelReservoir},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function defines the constraints for the energy level for the PowerSystems.HydroReservoir using the HydroEnergyModelReservoir formulation.

add_constraints!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::Type{EnergyBudgetConstraint},
    devices::Array{V<:PowerSystems.HydroReservoir, 1},
    model::DeviceModel{V<:PowerSystems.HydroReservoir, W<:HydroEnergyModelReservoir},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function define the budget constraint for the active power budget formulation. $sum(P[t]) <= Budget$

add_constraints!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::Type{ReservoirInventoryConstraint},
    devices::Array{V<:PowerSystems.HydroReservoir, 1},
    model::DeviceModel{V<:PowerSystems.HydroReservoir, W<:HydroWaterFactorModel},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function defines the constraints for the water level (or state of charge) for the HydroWaterFactorModel.

add_constraints!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::Type{TurbinePowerOutputConstraint},
    devices::Array{V<:PowerSystems.HydroTurbine, 1},
    model::DeviceModel{V<:PowerSystems.HydroTurbine, W<:HydroTurbineBilinearDispatch},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function defines the relationship between turbined flow and power produced. The flow×head bilinear product is bridged to IOM's approximation API (_build_bilinear_config / IOM._add_bilinear_approx!): with "bilinear_approximation" => "none" (the default) the product is exact (NLP); a linearizing scheme produces a tolerance-driven MILP approximation.

add_constraints!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::Type{TurbinePowerOutputConstraint},
    devices::Array{V<:PowerSystems.HydroTurbine, 1},
    model::DeviceModel{V<:PowerSystems.HydroTurbine, W<:Union{HydroTurbineWaterLinearCommitment, HydroTurbineWaterLinearDispatch}},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function define the relationship between turbined flow and power produced with constant head

add_constraints!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::Type{WaterBudgetConstraint},
    devices::Array{V<:PowerSystems.HydroReservoir, 1},
    model::DeviceModel{V<:PowerSystems.HydroReservoir, W<:HydroWaterModelReservoir},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function define the budget constraint for the active power budget formulation. $sum(f[t]) <= Budget$

add_constraints!(
    container::OptimizationContainer,
    T::Type{<:ActivePowerVariableLimitsConstraint},
    U::Type{<:InfrastructureSystems.Optimization.VariableType},
    devices::Array{V<:PowerSystems.ThermalMultiStart, 1},
    _::DeviceModel{V<:PowerSystems.ThermalMultiStart, W<:ThermalMultiStartUnitCommitment},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function adds range constraint for the first time period. Constraint (10) from PGLIB formulation

add_constraints!(
    container::OptimizationContainer,
    T::Type{<:PowerOperationsModels.PowerVariableLimitsConstraint},
    U::Type{<:Union{InfrastructureSystems.Optimization.ExpressionType, InfrastructureSystems.Optimization.VariableType}},
    devices::Array{V<:PowerSystems.HydroGen, 1},
    model::DeviceModel{V<:PowerSystems.HydroGen, W<:PowerOperationsModels.AbstractHydroDispatchFormulation},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Add power variable limits constraints for abstract hydro dispatch formulations

add_constraints!(
    container::OptimizationContainer,
    T::Type{<:PowerOperationsModels.PowerVariableLimitsConstraint},
    U::Type{<:Union{InfrastructureSystems.Optimization.ExpressionType, InfrastructureSystems.Optimization.VariableType}},
    devices::Array{V<:PowerSystems.HydroGen, 1},
    model::DeviceModel{V<:PowerSystems.HydroGen, W<:PowerOperationsModels.AbstractHydroUnitCommitment},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Add power variable limits constraints for abstract hydro unit commitment formulations

add_constraints!(
    container::OptimizationContainer,
    T::Type{<:PowerOperationsModels.PowerVariableLimitsConstraint},
    U::Type{<:Union{InfrastructureSystems.Optimization.ExpressionType, InfrastructureSystems.Optimization.VariableType}},
    devices::Array{V<:PowerSystems.ThermalGen, 1},
    model::DeviceModel{V<:PowerSystems.ThermalGen, W<:InfrastructureOptimizationModels.AbstractThermalDispatchFormulation},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Semicontinuous range constraints for thermal dispatch formulations

add_constraints!(
    container::OptimizationContainer,
    T::Type{<:PowerOperationsModels.PowerVariableLimitsConstraint},
    U::Type{<:Union{InfrastructureSystems.Optimization.ExpressionType, InfrastructureSystems.Optimization.VariableType}},
    devices::Array{V<:PowerSystems.ThermalGen, 1},
    model::DeviceModel{V<:PowerSystems.ThermalGen, W<:InfrastructureOptimizationModels.AbstractThermalUnitCommitment},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Semicontinuous range constraints for unit commitment formulations

add_constraints!(
    container::OptimizationContainer,
    T::Type{<:PowerOperationsModels.ReactivePowerVariableLimitsConstraint},
    U::Type{<:ReactivePowerVariable},
    devices::Array{V<:PowerSystems.ElectricLoad, 1},
    _::DeviceModel{V<:PowerSystems.ElectricLoad, W<:PowerOperationsModels.AbstractControllablePowerLoadFormulation},
    network_model::NetworkModel{X<:AbstractNetworkModel}
)

Reactive Power Constraints on Controllable Loads Assume Constant power_factor

add_constraints!(
    container::OptimizationContainer,
    _::Type{<:PowerOperationsModels.ReactivePowerVariableLimitsConstraint},
    _::Type{<:ReactivePowerVariable},
    devices::Array{V<:PowerSystems.RenewableGen, 1},
    _::DeviceModel{V<:PowerSystems.RenewableGen, W<:RenewableConstantPowerFactor},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Reactive Power Constraints on Renewable Gen Constant power_factor

add_constraints!(
    container::OptimizationContainer,
    T::Type{<:PowerOperationsModels.ReactivePowerVariableLimitsConstraint},
    U::Type{<:ReactivePowerVariable},
    devices::Array{V<:PowerSystems.ShiftablePowerLoad, 1},
    _::DeviceModel{V<:PowerSystems.ShiftablePowerLoad, W<:PowerLoadShift},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Reactive power for PowerLoadShift referenced against the RealizedShiftedLoad expression: this formulation never creates an ActivePowerVariable, so the generic AbstractControllablePowerLoadFormulation method above (which reads ActivePowerVariable) does not apply.

add_constraints!(
    container::OptimizationContainer,
    T::Type{ActivePowerPumpReservationConstraint},
    devices::Array{V<:PowerSystems.HydroPumpTurbine, 1},
    model::DeviceModel{V<:PowerSystems.HydroPumpTurbine, W<:PowerOperationsModels.AbstractHydroPumpFormulation},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function defines the constraints for the pump power for the PowerSystems.HydroPumpTurbine.

Enforces power_pump <= pump_max * (1 - reservation): the pump can only draw power when the unit is not reserved for generation.

add_constraints!(
    container::OptimizationContainer,
    T::Type{ActivePowerVariableLimitsConstraint},
    U::Type{<:RangeConstraintLBExpressions},
    devices::Array{V<:PowerSystems.HydroPumpTurbine, 1},
    model::DeviceModel{V<:PowerSystems.HydroPumpTurbine, W<:HydroPumpEnergyCommitment},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Add semicontinuous LB range constraints for HydroPumpEnergyCommitment formulation. Reservation path pairs a reservation-keyed bound ("lb") with an OnVariable-keyed bound ("lb_aux").

add_constraints!(
    container::OptimizationContainer,
    T::Type{ActivePowerVariableLimitsConstraint},
    U::Type{<:RangeConstraintLBExpressions},
    devices::Array{V<:PowerSystems.HydroPumpTurbine, 1},
    model::DeviceModel{V<:PowerSystems.HydroPumpTurbine, W<:HydroPumpEnergyDispatch},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Add semicontinuous LB range constraints for HydroPumpEnergyDispatch formulation

add_constraints!(
    container::OptimizationContainer,
    T::Type{ActivePowerVariableLimitsConstraint},
    U::Type{<:RangeConstraintUBExpressions},
    devices::Array{V<:PowerSystems.HydroPumpTurbine, 1},
    model::DeviceModel{V<:PowerSystems.HydroPumpTurbine, W<:HydroPumpEnergyCommitment},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Add semicontinuous UB range constraints for HydroPumpEnergyCommitment formulation. Reservation path pairs a reservation-keyed bound ("ub") with an OnVariable-keyed bound ("ub_aux").

add_constraints!(
    container::OptimizationContainer,
    T::Type{ActivePowerVariableLimitsConstraint},
    U::Type{<:RangeConstraintUBExpressions},
    devices::Array{V<:PowerSystems.HydroPumpTurbine, 1},
    model::DeviceModel{V<:PowerSystems.HydroPumpTurbine, W<:HydroPumpEnergyDispatch},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Add semicontinuous UB range constraints for HydroPumpEnergyDispatch formulation

add_constraints!(
    container::OptimizationContainer,
    T::Type{ActivePowerVariableLimitsConstraint},
    U::Type{<:Union{RangeConstraintLBExpressions, RangeConstraintUBExpressions}},
    devices::Array{V<:PowerSystems.HydroTurbine, 1},
    model::DeviceModel{V<:PowerSystems.HydroTurbine, W<:HydroTurbineWaterLinearCommitment},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Add semicontinuous range constraints for HydroTurbineWaterLinearCommitment formulation

add_constraints!(
    container::OptimizationContainer,
    _::Type{EnergyBudgetConstraint},
    devices::Array{V<:PowerSystems.HydroGen, 1},
    model::DeviceModel{V<:PowerSystems.HydroGen, W<:HydroDispatchRunOfRiver},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function define the budget constraint for the active power budget formulation. $sum(P[t]) <= Budget$

add_constraints!(
    container::OptimizationContainer,
    _::Type{EnergyTargetConstraint},
    devices::Array{V<:PowerSystems.HydroGen, 1},
    model::DeviceModel{V<:PowerSystems.HydroGen, W<:PowerOperationsModels.AbstractHydroReservoirFormulation},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Add energy target constraints for PowerSystems.HydroGen

add_constraints!(
    container::OptimizationContainer,
    _::Type{EnergyTargetConstraint},
    devices::Array{V<:PowerSystems.HydroReservoir, 1},
    model::DeviceModel{V<:PowerSystems.HydroReservoir, W<:HydroEnergyModelReservoir},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Add energy target constraints for PowerSystems.HydroReservoir

add_constraints!(
    container::OptimizationContainer,
    _::Type{HybridEnergyAssetBalanceConstraint},
    devices::Array{V<:PowerSystems.HybridSystem, 1},
    model::DeviceModel{V<:PowerSystems.HybridSystem, W<:AbstractHybridFormulation},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Energy asset balance: the hybrid's PCC injection equals the sum of subcomponent injections (thermal + renewable + storage discharge - storage charge - load). When ancillary services are attached, served (deployed-fraction) reserve expressions also enter the balance with sign pattern +out_up - in_up - out_down + in_down, mirroring HSS _add_constraints_energyassetbalance_with_reserves!.

add_constraints!(
    container::OptimizationContainer,
    _::Type{HybridReserveAssignmentConstraint},
    devices::Array{V<:PowerSystems.HybridSystem, 1},
    model::DeviceModel{V<:PowerSystems.HybridSystem, W<:AbstractHybridFormulationWithReserves},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Couple the hybrid PCC reserve variables (Out + In, summed across subcomponents) to the system-level ActivePowerReserveVariable for each service the hybrid participates in.

add_constraints!(
    container::OptimizationContainer,
    _::Type{HybridReserveBalanceConstraint},
    devices::Array{V<:PowerSystems.HybridSystem, 1},
    model::DeviceModel{V<:PowerSystems.HybridSystem, W<:AbstractHybridFormulationWithReserves},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Couple the hybrid PCC reserve variables (Out + In) to the sum of per-subcomponent reserve allocations (thermal + renewable + charging + discharging).

add_constraints!(
    container::OptimizationContainer,
    T::Type{PowerOperationsModels.OfflineReserveBandConstraint},
    devices::Union{Array{V<:PowerSystems.HydroGen, 1}, InfrastructureSystems.FlattenIteratorWrapper{V<:PowerSystems.HydroGen}},
    model::DeviceModel{V<:PowerSystems.HydroGen, W<:HydroCommitmentRunOfRiver},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Offline-capability band row for HydroCommitmentRunOfRiver devices contributing to an OfflineReserve. The commitment-gated UB expression excludes the offline awards (offline_reserve_in_range_ub); this row adds them back against the hour's limit in both commitment states:

p + online + offline <= ts_t

where ts_t is the device's ActivePowerTimeSeriesParameter (static pmax without that series). Committed: offline competes with the online products, which the semicontinuous row already caps at pmax * u. Off: that row zeroes p and the online awards, leaving offline <= ts_t.

With "offline_only" = true on the OfflineReserve ServiceModel, an extra OfflineReserveOffStateConstraint row forbids offline awards while committed: offline <= pmax * (1 - u).

With "exclude_shutdown_step" = true, OfflineReserveShutdownConstraint forbids offline awards in the step the unit goes off: offline <= pmax * (1 - u_{t-1} + u_t), with u_0 from the DeviceStatus initial condition.

add_constraints!(
    container::OptimizationContainer,
    T::Type{PowerOperationsModels.OfflineReserveBandConstraint},
    devices::Array{V<:PowerSystems.ThermalGen, 1},
    model::DeviceModel{V<:PowerSystems.ThermalGen, W<:InfrastructureOptimizationModels.AbstractThermalUnitCommitment},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Offline-capability band row for thermal-UC devices contributing to an OfflineReserve. The commitment-gated UB expression excludes the offline awards (offline_reserve_in_range_ub); this row adds them 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

where ts_t = mult * ActivePowerTimeSeriesParameter when the DeviceModel maps that series and the device has it (q_limit = pmax otherwise), and gated = get_min_max_limits(d, ActivePowerVariableLimitsConstraint, W).max is the same headroom the semicontinuous range row gates on: pmax for standard UC (giving ts_t) and pmax - pmin for compact UC (giving ts_t - pmin * u). A must-run device is always committed, so its band is ts_t - (q_limit - gated) outright.

Committed: offline competes with the online products for the gated band. Off: the semi-continuous UB row zeroes p and the online awards, leaving offline <= ts_t. Devices contributing to no offline service get no row.

With "offline_only" = true on the OfflineReserve ServiceModel, an extra OfflineReserveOffStateConstraint row forbids offline awards while committed (offline <= q_limit * (1 - u); 0 for must-run). Scope: thermal unit commitment and HydroCommitmentRunOfRiver; other formulations book OfflineReserve awards against their headroom and are not restricted. With "exclude_shutdown_step" = true, OfflineReserveShutdownConstraint forbids offline awards in the step the unit goes off (offline <= q_limit * (1 - u_{t-1} + u_t)).

add_constraints!(
    container::OptimizationContainer,
    _::Type{ReservoirHeadToVolumeConstraint},
    devices::Array{V<:PowerSystems.HydroReservoir, 1},
    model::DeviceModel{V<:PowerSystems.HydroReservoir, W<:PowerOperationsModels.AbstractHydroFormulation},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function define the relationship between head and volume for the reservoir.

add_constraints!(
    container::OptimizationContainer,
    _::Type{ReservoirInventoryConstraint},
    _::Type{HydroReservoirVolumeVariable},
    devices::Array{V<:PowerSystems.HydroReservoir, 1},
    model::DeviceModel{V<:PowerSystems.HydroReservoir, W<:PowerOperationsModels.AbstractHydroFormulation},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function define the level (head or volume) limits for the reservoir.

add_constraints!(
    container::OptimizationContainer,
    _::Type{ReservoirLevelLimitConstraint},
    devices::Array{V<:PowerSystems.HydroReservoir, 1},
    model::DeviceModel{V<:PowerSystems.HydroReservoir, W<:PowerOperationsModels.AbstractHydroFormulation},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function define the level (head or volume) limits for the reservoir.

add_constraints!(
    container::OptimizationContainer,
    _::Type{ReservoirLevelTargetConstraint},
    devices::Array{V<:PowerSystems.HydroReservoir, 1},
    model::DeviceModel{V<:PowerSystems.HydroReservoir, W<:HydroWaterFactorModel},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function define the target level constraint for the reservoir.

add_constraints!(
    container::OptimizationContainer,
    _::Type{ReservoirLevelTargetConstraint},
    devices::Array{V<:PowerSystems.HydroReservoir, 1},
    model::DeviceModel{V<:PowerSystems.HydroReservoir, W<:PowerOperationsModels.AbstractHydroFormulation},
    _::NetworkModel{X<:AbstractNetworkModel}
)

This function define the target level constraint for the reservoir.

add_constraints!(
    container::OptimizationContainer,
    _::Type{WaterTargetConstraint},
    devices::Array{V<:PowerSystems.HydroReservoir, 1},
    model::DeviceModel{V<:PowerSystems.HydroReservoir, W<:HydroWaterModelReservoir},
    _::NetworkModel{X<:AbstractNetworkModel}
)

Add water target constraints for PowerSystems.HydroReservoir. Only supported for HEAD type.

add_power_flow_data!(
    _::OptimizationContainer,
    network_model::NetworkModel,
    _::InfrastructureSystems.ComponentContainer
)

Default fallback for add_power_flow_data!: a no-op when no evaluators are present. The PowerFlows extension provides the concrete method that handles real evaluators. If evaluators are registered without the PowerFlows extension loaded, this errors with guidance to load it.

add_reserve_variables!(
    container::OptimizationContainer,
    _::Type{T<:ServiceRequirementVariable},
    services::Array{D<:PowerSystems.AbstractReserve, 1},
    formulation
)

Add variables for ServiceRequirementVariable for StepWiseCostReserve

add_to_objective_function!(
    _::OptimizationContainer,
    _::Array{U<:InfrastructureSystems.InfrastructureSystemsComponent, 1},
    _::DeviceModel{U<:InfrastructureSystems.InfrastructureSystemsComponent, F<:AbstractDeviceFormulation},
    _::Type{S<:AbstractNetworkModel}
)

Add objective function contributions for devices.

advance_countdown(
    previous::Real,
    occurred::Bool,
    duration_steps::Int64
) -> Any

advance_countdown(previous, occurred, duration_steps)

The countdown after one step: a new outage starts the clock at duration_steps, an outage already running loses a step, and an available device stays at zero. An outage that fires while the device is already out does not extend it, matching PSI, where only an available device can transition.

attach_feedforward!(
    model::DeviceModel,
    ff::InfrastructureOptimizationModels.AbstractAffectFeedforward
)

Attach a feedforward to a DeviceModel. Attaching a field-for-field identical feedforward twice is a no-op, so a template can be built up incrementally without duplicating containers. Attaching a second feedforward that shares a source key with an attached one but differs in any other field errors, naming the conflicting fields. Attaching a second, differing SemiContinuousFeedforward for the same component type also errors: only one can supply the OnStatusParameter container. Likewise, only one UpperBoundFeedforward and one LowerBoundFeedforward per device model are supported today (see _check_bound_conflict).

availability_from_countdown(countdown::Real) -> Float64

availability_from_countdown(countdown)

Availability implied by a countdown: 0 while the outage still has steps to run, 1 otherwise. Availability is always derived, never stored independently, so the two can never disagree.

availability_trajectory(
    remaining::Real,
    n_steps::Int64
) -> Vector

availability_trajectory(remaining, n_steps)

availability_from_countdown applied to countdown_trajectory.

build!(
    model::DecisionModel{<:AbstractPowerDecisionProblem};
    output_dir,
    recorders,
    console_level,
    file_level,
    disable_timer_outputs,
    store_system_in_outputs
)

Build the Decision Model based on the specified AbstractPowerDecisionProblem.

Arguments

• model::DecisionModel{<:AbstractPowerDecisionProblem}: DecisionModel object
• output_dir::String: Output directory for outputs
• recorders::Vector{Symbol} = []: recorder names to register
• console_level = Logging.Error:
• file_level = Logging.Info:
• disable_timer_outputs = false : Enable/Disable timing outputs
• store_system_in_outputs::Bool = true: If true, stores the system as JSON in the outputs HDF5 file.

build!(
    model::EmulationModel{<:AbstractPowerEmulationProblem};
    executions,
    output_dir,
    recorders,
    console_level,
    file_level,
    disable_timer_outputs,
    store_system_in_outputs
)

Implementation of build for any AbstractPowerEmulationProblem

• store_system_in_outputs::Bool = true: If true, stores the system as JSON in the outputs HDF5 file.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{T<:PowerSystems.Source, D<:ImportExportSourceModel},
    network_model::NetworkModel{<:AbstractActivePowerModel}
)

This function creates the arguments for the model for an import/export formulation for Source devices

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{T<:PowerSystems.Source, D<:InfrastructureOptimizationModels.FixedOutput},
    network_model::NetworkModel{<:AbstractActivePowerModel}
)

This function creates the arguments for the model for a FixedOutput formulation for Source devices

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ThermalGen, D<:PowerOperationsModels.AbstractStandardUnitCommitment},
    network_model::NetworkModel{<:AbstractActivePowerModel}
)

This function creates the arguments model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{T<:PowerSystems.Source, D<:ImportExportSourceModel},
    network_model::NetworkModel
)

This function creates the arguments for the model for an import/export formulation for Source devices

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ThermalGen, D<:PowerOperationsModels.AbstractStandardUnitCommitment},
    network_model::NetworkModel
)

This function creates the arguments for the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    model::DeviceModel{T<:PowerSystems.Source, D<:ImportExportSourceModel},
    network_model::NetworkModel{<:AbstractActivePowerModel}
)

This function creates the constraints for the model for an import/export formulation for Source devices

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    model::DeviceModel{T<:PowerSystems.Source, D<:InfrastructureOptimizationModels.FixedOutput},
    network_model::NetworkModel{<:AbstractActivePowerModel}
)

This function creates the constraints for the model for a FixedOutput formulation for Source devices (no constraints added for FixedOutput)

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    model::DeviceModel{T<:PowerSystems.Source, D<:ImportExportSourceModel},
    network_model::NetworkModel
)

This function creates the constraints for the model for an import/export formulation for Source devices

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{H<:PowerSystems.HydroGen, D<:HydroCommitmentRunOfRiver},
    network_model::NetworkModel{S<:AbstractActivePowerModel}
)

Construct model for PowerSystems.HydroGen with HydroCommitmentRunOfRiver Formulation with only Active Power.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{H<:PowerSystems.HydroGen, D<:HydroCommitmentRunOfRiver},
    network_model::NetworkModel{S<:AbstractNetworkModel}
)

Construct model for PowerSystems.HydroGen with HydroCommitmentRunOfRiver Formulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{H<:PowerSystems.HydroGen, D<:PowerOperationsModels.AbstractHydroDispatchFormulation},
    network_model::NetworkModel{S<:AbstractActivePowerModel}
)

Construct model for PowerSystems.HydroGen with HydroDispatchRunOfRiver Formulation with only Active Power.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{H<:PowerSystems.HydroGen, D<:PowerOperationsModels.AbstractHydroDispatchFormulation},
    network_model::NetworkModel{S<:AbstractNetworkModel}
)

Construct model for PowerSystems.HydroGen with HydroDispatchRunOfRiver Formulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{H<:PowerSystems.HydroReservoir, D<:HydroEnergyModelReservoir},
    network_model::NetworkModel{S<:AbstractNetworkModel}
)

Construct model for PowerSystems.HydroReservoir with HydroEnergyModelReservoir Formulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{H<:PowerSystems.HydroTurbine, D<:HydroTurbineEnergyCommitment},
    network_model::NetworkModel{S<:AbstractActivePowerModel}
)

Construct model for PowerSystems.HydroTurbine with HydroTurbineEnergyCommitment Formulation with only Active Power.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{H<:PowerSystems.HydroTurbine, D<:HydroTurbineEnergyCommitment},
    network_model::NetworkModel{S<:AbstractNetworkModel}
)

Construct model for PowerSystems.HydroTurbine with HydroTurbineEnergyCommitment Formulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{H<:PowerSystems.HydroTurbine, D<:HydroTurbineEnergyDispatch},
    network_model::NetworkModel{S<:AbstractActivePowerModel}
)

Construct model for PowerSystems.HydroTurbine with HydroTurbineEnergyDispatch Formulation with only Active Power.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{H<:PowerSystems.HydroTurbine, D<:HydroTurbineEnergyDispatch},
    network_model::NetworkModel{S<:AbstractNetworkModel}
)

Construct model for PowerSystems.HydroTurbine with HydroTurbineEnergyDispatch Formulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{H<:PowerSystems.HydroTurbine, D<:HydroWaterFactorModel},
    network_model::NetworkModel{S<:AbstractActivePowerModel}
)

Construct model for PowerSystems.HydroTurbine with HydroWaterFactorModel Formulation with only Active Power.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{H<:PowerSystems.HydroTurbine, D<:HydroWaterFactorModel},
    network_model::NetworkModel{S<:AbstractNetworkModel}
)

Construct model for PowerSystems.HydroTurbine with HydroWaterFactorModel Formulation

construct_device!(
    _::OptimizationContainer,
    _::InfrastructureSystems.ComponentContainer,
    _::InfrastructureSystems.Optimization.ConstructStage,
    model::DeviceModel{D<:InfrastructureSystems.InfrastructureSystemsComponent, F<:AbstractDeviceFormulation},
    network_model::NetworkModel{S}
)

Fallback: construct_device! for ArgumentConstructStage and ModelConstructStage.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{H<:PowerSystems.HydroReservoir, HydroWaterFactorModel},
    network_model::NetworkModel{S<:AbstractNetworkModel}
)

Construct model for PowerSystems.HydroReservoir with HydroWaterFactorModel Formulation with only Active Power

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{H<:PowerSystems.HydroGen, InfrastructureOptimizationModels.FixedOutput},
    network_model::NetworkModel{S<:AbstractNetworkModel}
)

Construct model for PowerSystems.HydroGen` with PowerSimulations.FixedOutput Formulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranchBounds},
    network_model::NetworkModel{DCPLLNetworkModel}
)

ArgumentConstructStage for StaticBranchBounds under DCPLLNetworkModel.

Creates the two directional flow variables and applies the rating as variable bounds. As with StaticBranch, slacks and hard bounds are mutually exclusive enforcement styles.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranchBounds},
    network_model::NetworkModel{DCPNetworkModel}
)

ArgumentConstructStage for StaticBranchBounds under DCPNetworkModel.

Creates the FlowActivePowerVariable (with variable-level bounds set) and registers the branch flow contribution to the per-bus ActivePowerBalance expression.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranchBounds},
    network_model::NetworkModel{IVRNetworkModel}
)

ArgumentConstructStage for StaticBranchBounds under IVRNetworkModel.

Identical to StaticBranch but uses the StaticBranchBounds formulation tag (variable-level bounds on the power flows). With use_slacks, adds the metaed "p"/"q" flow-definition slack pairs that relax the bilinear power-current equalities.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranchBounds},
    network_model::NetworkModel{LPACCNetworkModel}
)

ArgumentConstructStage for StaticBranchBounds under LPACCNetworkModel.

Creates the four directional flow variables and the bus-pair cosine variable, and registers each flow's contribution to the per-bus ActivePowerBalance and ReactivePowerBalance.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranchBounds},
    network_model::NetworkModel{NFANetworkModel}
)

ArgumentConstructStage for StaticBranchBounds under NFANetworkModel.

Creates the FlowActivePowerVariable and registers its contribution to the per-bus ActivePowerBalance expression. The rating is enforced as variable bounds at creation (_branch_variable_bounds), so slacks cannot be priced and are rejected.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranch},
    network_model::NetworkModel{ACPNetworkModel}
)

ArgumentConstructStage for StaticBranch under ACPNetworkModel.

Creates the four directional flow variables (active and reactive, from-to and to-from), optional slack variables, and registers each flow variable's contribution to the per-bus ActivePowerBalance and ReactivePowerBalance expressions.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranch},
    network_model::NetworkModel{ACRNetworkModel}
)

ArgumentConstructStage for StaticBranch under ACRNetworkModel.

Creates the four directional flow variables (active and reactive, from-to and to-from), optional slack variables, and registers each flow variable's contribution to the per-bus ActivePowerBalance and ReactivePowerBalance expressions.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranch},
    network_model::NetworkModel{DCPLLNetworkModel}
)

ArgumentConstructStage for StaticBranch under DCPLLNetworkModel.

Creates two directional flow variables (from-to and to-from), applies rating bounds via _set_dcpll_flow_bounds!, and registers each flow's contribution to ActivePowerBalance. No FlowActivePowerVariable — DCPLL uses the directional pair like ACP (active only).

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranch},
    network_model::NetworkModel{IVRNetworkModel}
)

ArgumentConstructStage for StaticBranch under IVRNetworkModel.

Creates the four directional power flow variables (active and reactive, from-to and to-from) and the six branch current variables (crfr, cifr, crto, cito, csr, csi) bounded ±cratinga. Registers flow contributions to the per-bus ActivePowerBalance and ReactivePowerBalance.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranch},
    network_model::NetworkModel{LPACCNetworkModel}
)

ArgumentConstructStage for StaticBranch under LPACCNetworkModel.

Creates the four directional flow variables, the bus-pair cosine variable (cs), optional slacks, and registers each flow's contribution to the per-bus ActivePowerBalance and ReactivePowerBalance expressions.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranch},
    network_model::NetworkModel{NFANetworkModel}
)

ArgumentConstructStage for StaticBranch under NFANetworkModel.

Creates the FlowActivePowerVariable (unbounded; the rating is enforced by the FlowRateConstraint rows) and optional slacks, and registers its contribution to the per-bus ActivePowerBalance expression. No Ohm's law / angles.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ThermalGen, ThermalBasicUnitCommitment},
    network_model::NetworkModel{<:AbstractActivePowerModel}
)

This function creates the arguments for the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ThermalGen, ThermalBasicUnitCommitment},
    network_model::NetworkModel
)

This function creates the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ThermalGen, ThermalStandardDispatch},
    network_model::NetworkModel{<:AbstractActivePowerModel}
)

This function creates the arguments for the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ThermalGen, ThermalStandardDispatch},
    network_model::NetworkModel
)

This function creates the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ThermalGen, <:PowerOperationsModels.AbstractStandardUnitCommitment},
    network_model::NetworkModel{<:AbstractActivePowerModel}
)

This function creates the constraints for the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranchBounds},
    network_model::NetworkModel{DCPLLNetworkModel}
)

ModelConstructStage for StaticBranchBounds under DCPLLNetworkModel.

Applies the DC Ohm's law on pfr (NetworkFlowConstraint), the quadratic line-loss coupling (NetworkLossConstraint), and angle-difference limits. The rating is a FlowRateConstraint row here rather than a variable bound, so `branchvariablebounds` opts DCPLL out of the StaticBranchBounds rating.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranchBounds},
    network_model::NetworkModel{DCPNetworkModel}
)

ModelConstructStage for StaticBranchBounds under DCPNetworkModel.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranchBounds},
    network_model::NetworkModel{IVRNetworkModel}
)

ModelConstructStage for StaticBranchBounds under IVRNetworkModel.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranchBounds},
    network_model::NetworkModel{LPACCNetworkModel}
)

ModelConstructStage for StaticBranchBounds under LPACCNetworkModel.

Applies the apparent-power rate limits, the LPAC-linearized AC Ohm's law constraints, the convex cosine relaxation, and (when applicable) the branch angle-difference limits.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranch},
    network_model::NetworkModel{ACPNetworkModel}
)

ModelConstructStage for StaticBranch under ACPNetworkModel.

Applies the apparent-power rate limits (from-to and to-from), the π-model AC Ohm's law constraints, and (when applicable) the branch angle-difference limits.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranch},
    network_model::NetworkModel{ACRNetworkModel}
)

ModelConstructStage for StaticBranch under ACRNetworkModel.

Applies the apparent-power rate limits (from-to and to-from), the π-model rectangular AC Ohm's law constraints, and cross-product angle-difference limits for branches with non-default (non-±π) angle bounds.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranch},
    network_model::NetworkModel{DCPLLNetworkModel}
)

ModelConstructStage for StaticBranch under DCPLLNetworkModel.

Applies the DC Ohm's law on pfr (NetworkFlowConstraint), the quadratic line-loss coupling pfr + pto >= r * pfr^2 (NetworkLossConstraint), and angle-difference limits.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranch},
    network_model::NetworkModel{DCPNetworkModel}
)

ModelConstructStage for StaticBranch under DCPNetworkModel.

Applies the branch flow rate limits directly on BThetaBranchFlow (no variable to bound instead) and, when applicable, the branch angle-difference limits. There is no separate Ohm's-law equality to add — the expression already carries the DC power-flow value.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranch},
    network_model::NetworkModel{IVRNetworkModel}
)

ModelConstructStage for StaticBranch under IVRNetworkModel.

Applies apparent-power rate limits (from-to and to-from), the IVR π-model constraints (bilinear power-current linking, KCL at each terminal, Ohm's law across series impedance), the terminal current-magnitude quadratic limits, and cross-product angle-difference limits for branches with non-default (non-±π) angle bounds.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranch},
    network_model::NetworkModel{LPACCNetworkModel}
)

ModelConstructStage for StaticBranch under LPACCNetworkModel.

Applies the apparent-power rate limits, the LPAC-linearized AC Ohm's law constraints, the convex cosine relaxation, and (when applicable) the branch angle-difference limits.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranch},
    network_model::NetworkModel{NFANetworkModel}
)

ModelConstructStage for StaticBranch under NFANetworkModel.

Applies only the branch flow rate limit — the transportation model has no Ohm's law or angle-difference constraint.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ThermalGen, ThermalBasicUnitCommitment},
    network_model::NetworkModel{<:AbstractActivePowerModel}
)

This function creates the constraints for the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ThermalGen, ThermalBasicUnitCommitment},
    network_model::NetworkModel
)

This function creates the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ThermalGen, ThermalStandardDispatch},
    network_model::NetworkModel{<:AbstractActivePowerModel}
)

This function creates the constraints for the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ThermalGen, ThermalStandardDispatch},
    network_model::NetworkModel
)

This function creates the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranchBounds},
    network_model::NetworkModel{U<:Union{ACPNetworkModel, ACRNetworkModel}}
)

ArgumentConstructStage for StaticBranchBounds under ACPNetworkModel and ACRNetworkModel.

Creates the four directional flow variables and registers their contributions to the per-bus balance expressions. Both network models take the same argument-stage variable set; only their NetworkFlowConstraint builders differ.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ACTransmission, StaticBranchBounds},
    network_model::NetworkModel{U<:Union{ACPNetworkModel, ACRNetworkModel}}
)

ModelConstructStage for StaticBranchBounds under ACPNetworkModel and ACRNetworkModel.

Applies the apparent-power rate limits (from-to and to-from), the π-model AC Ohm's law constraints, and (when applicable) the branch angle-difference limits.

construct_device!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:PowerSystems.ThermalGen, U<:PowerOperationsModels.AbstractStandardUnitCommitment},
    network_model::NetworkModel
)

This function creates the constraints for the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation

construct_service!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::ServiceModel{SR<:PowerSystems.GroupReserve, GroupRangeReserve},
    _::Dict{Symbol, DeviceModel},
    _::Set{<:DataType},
    _::NetworkModel
)

Constructs a service for GroupRangeReserve.

construct_service!(
    container::OptimizationContainer,
    sys::PowerSystems.System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::ServiceModel{SR<:PowerSystems.GroupReserve, GroupStepwiseCostReserve},
    _::Dict{Symbol, DeviceModel},
    _::Set{<:DataType},
    _::NetworkModel
)

Constructs a service for GroupStepwiseCostReserve: the group's demand curve is cleared by
the summed awards of its contributing services.

countdown_steps(
    duration::Dates.Period,
    resolution::Dates.Period
) -> Int64

countdown_steps(duration, resolution)

duration expressed as a whole number of steps of length resolution, rounded up with a warning when it does not divide evenly. An outage cannot end partway through a step, so the choice is between ending it early and ending it late; rounding up keeps the device out for at least as long as the data says.

TODO(events): rounding up matches PSI, which has always tolerated durations that do

not divide the state resolution. Erroring instead would surface those fixtures, at the

cost of breaking runs that work today. Revisit once the MTTR units question below is

settled, since the two interact: an MTTR read in the wrong unit is exactly what

produces a duration that does not divide evenly.

countdown_trajectory(
    remaining::Real,
    n_steps::Int64
) -> Vector

countdown_trajectory(remaining, n_steps)

The countdown projected across n_steps steps, starting from remaining now. This is what carries an in-progress outage into the horizon of the next decision model: the model is built once, so the whole trajectory has to be written up front rather than discovered step by step.

event_parameter_keys(
    container::OptimizationContainer,
    _::Type{D}
) -> Vector

event_parameter_keys(container, ::Type{D})

The event parameter keys a runtime must update for device type D, in the order they must be written, restricted to those the built model actually has. Which offsets exist depends on the device family and the network model (a load under an AC network gets both offsets; a thermal unit gets neither), so a runtime should ask rather than assume.

event_step_values(
    event::PowerSystems.Contingency,
    event_model::EventModel,
    current_time::Dates.DateTime,
    previous_countdown::Real;
    resolution,
    rng,
    mttr_units,
    may_start,
    active_power_injection,
    reactive_power_injection
)

event_step_values(event, event_model, current_time, previous_countdown; kwargs...)

Everything one runtime step needs for one device, as a named tuple of occurred, countdown, availability, active_power_offset and reactive_power_offset.

resolution is the runtime's state resolution, which sets what a countdown step means. active_power_injection / reactive_power_injection are the device's own time-series contributions to the balance, needed only for devices that carry offset parameters; they default to zero, which is what a device bounded by an outage constraint wants.

may_start is the event condition's verdict for this step (see is_triggered). It gates only whether a new outage can begin: a running countdown decays either way, so a runtime calls this once per device per step rather than skipping it when the condition does not hold — skipping would freeze the outage instead of letting it recover.

get_attribute_device_map(
    e::EventModel
) -> Dict{Int64, Dict{DataType, Set{String}}}

Return e's outage attribute id → device type → device names map, populated by build-time discovery.

get_event_condition(
    e::EventModel{D<:PowerSystems.Contingency, B<:AbstractEventCondition}
) -> AbstractEventCondition

Return the trigger condition attached to e.

get_event_models(
    template::PowerOperationsProblemTemplate
) -> Vector{InfrastructureOptimizationModels.AbstractEventModel}

Return the outage-event models attached to template via set_event_model!.

get_event_type(
    _::EventModel{D<:PowerSystems.Contingency, B<:AbstractEventCondition}
) -> Type{D} where D<:PowerSystems.Contingency

Return the PSY.Contingency subtype that e models.

get_expression_multiplier(
    _::Type{P<:InfrastructureSystems.Optimization.ParameterType},
    _::Type{T<:InfrastructureSystems.Optimization.ExpressionType},
    _::InfrastructureSystems.InfrastructureSystemsComponent,
    _::Type{F<:AbstractDeviceFormulation}
) -> Float64

Get the multiplier for an expression type based on parameter type.

get_initial_conditions_device_model(
    _::InfrastructureOptimizationModels.AbstractOptimizationModel,
    model::DeviceModel{T<:PowerSystems.Device, InfrastructureOptimizationModels.FixedOutput}
) -> InfrastructureOptimizationModels.DeviceModelForBranches{T, InfrastructureOptimizationModels.FixedOutput} where T<:PowerSystems.RenewableGen

Get the device model to use for initialization.

get_multiplier_value(
    _::Type{P<:InfrastructureSystems.Optimization.ParameterType},
    _::InfrastructureSystems.InfrastructureSystemsComponent,
    _::Type{F<:AbstractDeviceFormulation}
) -> Float64

Get the multiplier value for a parameter type.

get_multiplier_value(
    _::Type{T<:InfrastructureSystems.Optimization.TimeSeriesParameter},
    _::InfrastructureSystems.InfrastructureSystemsComponent,
    _::Type{F<:AbstractDeviceFormulation}
) -> Float64

Get multiplier value for a time series parameter.

get_time_stamps(
    c::PresetTimeCondition
) -> Vector{Dates.DateTime}

Return the time stamps at which c is triggered.

get_variable_multiplier(
    _::Type{<:InfrastructureSystems.Optimization.VariableType},
    _::Type{<:InfrastructureSystems.InfrastructureSystemsComponent},
    _::Type{<:AbstractDeviceFormulation}
) -> Float64

Get the multiplier for a variable type when adding to an expression. Default implementation returns 1.0.

is_triggered(
    ::ContinuousCondition,
    ::Dates.DateTime
) -> Bool
is_triggered(
    ::ContinuousCondition,
    ::Dates.DateTime,
    ::Tuple
) -> Bool

is_triggered(condition, current_time, inputs = ())

Whether an event model's condition fires. inputs are the resolved values of required_inputs, in the same order.

A runtime evaluates this once per event model, before applying any outage values; a condition that does not fire leaves the event parameters alone. It gates whether an outage begins — an outage already running keeps counting down regardless, or a condition that fires once could never recover.

outage_occurred(
    event::PowerSystems.FixedForcedOutage,
    event_model::EventModel,
    current_time::Dates.DateTime;
    rng
) -> Any

outage_occurred(event, event_model, current_time; rng)

Whether an outage begins at current_time.

• PSY.FixedForcedOutage: deterministic, read from the :outage_status series attached to the attribute. The value read is the one following current_time, matching PSI: the runtime decides at the end of a step what the next step looks like. A series with no following value reads as no outage.
• PSY.GeometricDistributionForcedOutage: a Bernoulli draw from rng with the attribute's outage_transition_probability, or the value of the time series named by :outage_transition_probability when the event model maps one.

rng is required for the stochastic types and ignored by the deterministic ones, so a runtime can call this uniformly.

power_flow_evaluations(
    ev
) -> InfrastructureOptimizationModels.EvaluationContainer

Build an EvaluationContainer holding a single evaluator. Convenience for the common single-evaluator case at call sites such as NetworkModel(...; evaluations = power_flow_evaluations(ACPowerFlow())).

The power-flow model is keyed by its own type and wrapped in a PowerFlowEvaluator to satisfy IOM's AbstractEvaluator interface.

required_inputs(
    _::AbstractEventCondition
) -> Tuple{StateValueInput}

required_inputs(condition)

The inputs condition needs from a runtime, as a tuple of AbstractConditionInput. Empty for conditions that depend on nothing but the clock, which is passed to is_triggered directly.

run!(
    model::EmulationModel{<:AbstractPowerEmulationProblem};
    export_problem_outputs,
    console_level,
    file_level,
    disable_timer_outputs,
    export_optimization_problem,
    enable_progress_bar,
    store_system_in_outputs,
    kwargs...
) -> InfrastructureSystems.Simulation.RunStatus.Value

Default run method for problems that conform to the requirements of EmulationModel{<: AbstractPowerEmulationProblem}

This will call build! on the model if it is not already built. It will forward all keyword arguments to that function.

Arguments

• model::EmulationModel = model: Emulation model
• optimizer::MOI.OptimizerWithAttributes: The optimizer that is used to solve the model
• executions::Int: Number of executions for the emulator run
• export_problem_outputs::Bool: If true, export OptimizationProblemOutputs DataFrames to CSV files.
• output_dir::String: Required if the model is not already built, otherwise ignored
• enable_progress_bar::Bool: Enables/Disable progress bar printing
• export_optimization_problem::Bool: If true, serialize the model to a file to allow re-execution later.
• store_system_in_outputs::Bool = true: If true, stores the system as JSON in the outputs HDF5 file.

Examples

status = run!(model; optimizer = HiGHS.Optimizer, executions = 10)
status = run!(model; output_dir = ./model_output, optimizer = HiGHS.Optimizer, executions = 10)

solve!(
    model::DecisionModel{<:AbstractPowerDecisionProblem};
    export_problem_outputs,
    console_level,
    file_level,
    disable_timer_outputs,
    export_optimization_problem,
    store_system_in_outputs,
    kwargs...
) -> InfrastructureSystems.Simulation.RunStatus.Value

Default solve method for models that conform to the requirements of DecisionModel{<: AbstractPowerDecisionProblem}.

This will call build! on the model if it is not already built. It will forward all keyword arguments to that function.

Arguments

• model::IOM.AbstractOptimizationModel = model: operation model
• export_problem_outputs::Bool = false: If true, export OptimizationProblemOutputs DataFrames to CSV files.
• console_level = Logging.Error:
• file_level = Logging.Info:
• disable_timer_outputs = false : Enable/Disable timing outputs
• export_optimization_problem::Bool = true: If true, serialize the model to a file to allow re-execution later.
• store_system_in_outputs::Bool = true: If true, stores the system as JSON in the outputs HDF5 file.

Examples

outputs = solve!(OpModel)
outputs = solve!(OpModel, export_problem_outputs = true)

supports_events(_::Type{T<:PowerSystems.Component}) -> Bool

Whether devices of this type support outage events (EventModel). This is a device-type capability trait for time-series outage events — distinct from supports_outages, the formulation trait for security-constrained (MODF) branch contingencies.

time_to_recover(
    event::PowerSystems.FixedForcedOutage,
    event_model::EventModel,
    current_time::Dates.DateTime;
    mttr_units
) -> Any

time_to_recover(event, event_model, current_time; mttr_units = Dates.Minute)

How long the outage beginning at current_time lasts, as a Dates.Period.

• PSY.FixedForcedOutage: the distance to the next available step in the :outage_status series. A series that never returns to available counts as out for its full remaining length.
• PSY.GeometricDistributionForcedOutage: mean_time_to_recovery from the attribute, or from the series named by :mean_time_to_recovery when the event model maps one.