Internal API

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

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

Abstract type for time-series-driven ratings of AC branches

Parameters to define the cost at the minimum available power

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

Example

import PowerSimulations as PSI struct MyCustomDeviceFormulation <: PSI.AbstractDeviceFormulation

Parameters to define the breakpoints of a piecewise linear function

Parameters to define the slopes of a piecewise linear cost function

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

Example

import PowerSimulations as PSI struct MyServiceFormulation <: PSI.AbstractServiceFormulation

All events subtyped from this need to be recorded under :simulation_status.

Auxiliary Variable for line power flow results from power flow evaluation

Informs the flusher on what data to keep in cache.

ContinuousCondition()

Establishes an event condition that is triggered at all timesteps.

Struct to dispatch the creation of DC Converter Binary for Absolute Value Current Variables for DC formulations Docs abbreviation: \nu_c`

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

Struct to define the creation of HVDC DC Line Current Flow

Docs abbreviation: $\i_{d}$

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

Lossless Line Abstract Model

Stores results data for one DecisionModel

Abstract type for Decision Problems

Example

import PowerSimulations as PSI struct MyCustomProblem <: PSI.DecisionProblem

AbstractCostAtMinParameter for the decremental case (power sink)

AbstractPiecewiseLinearBreakpointParameter for the decremental case (power sink)

AbstractPiecewiseLinearSlopeParameter for the decremental case (power sink)

Abstract type for models than employ PowerSimulations methods. For custom decision problems use DecisionProblem as the super type.

Abstract type for models than employ PowerSimulations methods. For custom emulation problems use EmulationProblem as the super type.

DiscreteEventCondition(condition_function::Function)

Establishes an event condition that is triggered if when a user defined function evaluates to true. The function should take SimulationState as its only arguement and return true when the event should be triggered and false otherwise.

Arguments

• condition_function::Function: user defined function f(::SimulationState)to determine if event is triggered.

Stores results data for one EmulationModel

Abstract type for Emulation Problems

Example

import PowerSimulations as PSI struct MyCustomEmulator <: PSI.EmulationProblem

Default PowerSimulations Emulation Problem Type for unspecified problems

Struct to dispatch the creation of HVDC Received Flow at From Bus Variables for PWL formulations

Docs abbreviation: $x$

Struct to dispatch the creation of HVDC Received Flow at To Bus Variables for PWL formulations

Docs abbreviation: $y$

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

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

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

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

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

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

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

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

Struct to define the creation of HVDC Inverter Extinction Angle Variable

Docs abbreviation: $\gamma^i$

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

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

Struct to define the creation of HVDC Inverter Overlap Angle Variable

Docs abbreviation: $\mu^i$

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

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

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

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

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

Docs abbreviation: $\phi^i$

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

Docs abbreviation: $\t^i$

Struct to dispatch the creation of HVDC Piecewise Binary Loss Variables

Docs abbreviation: $z$

Struct to dispatch the creation of HVDC Piecewise Loss Variables

Docs abbreviation: $h$ or $w$

Struct to dispatch the creation of HVDC Received Reactive Flow From Bus Variables

Docs abbreviation: $x^r$

Struct to dispatch the creation of HVDC Received Reactive Flow To Bus Variables

Docs abbreviation: $y^i$

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

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

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

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

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

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

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

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

Struct to define the creation of HVDC Rectifier Delay Angle Variable

Docs abbreviation: $\alpha^r$

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

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

Struct to define the creation of HVDC Rectifier Overlap Angle Variable

Docs abbreviation: $\mu^r$

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

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

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

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

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

Docs abbreviation: $\phi^r$

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

Docs abbreviation: $\t^r$

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

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

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

Stores simulation data in an HDF file.

Stores simulation data in memory

AbstractCostAtMinParameter for the incremental case (power source)

AbstractPiecewiseLinearBreakpointParameter for the incremental case (power source)

AbstractPiecewiseLinearSlopeParameter for the incremental case (power source)

Supertype for initial condition chronologies

Stores data to populate initial conditions before the build call

Linear Loss InterconnectingConverter Model

Parameter to define Max Flow limit for interface time series

Parameter to define Min Flow limit for interface time series

Multi-start startup variables

Abstract type for Decision Model and Emulation Model. OperationModel structs are parameterized with DecisionProblem or Emulation Problem structs

Format used to export the optimization model to disk on each solve.

Values

• NONE: Do not export the model.
• LP: Export to the LP file format (.lp).
• MOF: Export to MathOptFormat (.json).

Cache for a single parameter/variable/dual. Stores arrays chronologically by simulation timestamp.

Cache for all model results

Struct to dispatch the creation of piecewise linear block decremental offer variables for objective function

Docs abbreviation: $\delta_d$

Struct to dispatch the creation of piecewise linear block incremental offer variables for objective function

Docs abbreviation: $\delta$

Struct to create the PiecewiseLinearUpperBoundConstraint associated with a specified variable.

See Piecewise linear cost functions for more information.

Auxiliary Variables that are calculated using a PowerFlowEvaluationModel

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

Establishes an event condition that is triggered at pre-determined times.

Arguments

• time_stamps::Vector{Dates.DateTime}: times when event is triggered

Parameter to define active power in time series

Parameter to define active power in time series

Parameter to define shutdown cost time series

Holds the results of a simulation problem for plotting or exporting.

Provides storage of simulation data

Parameter to define startup cost time series

StateVariableValueCondition(
    variable_type::Type{<:VariableType}
    device_type::Type{<:PSY.Device}
    device_name::String
    value::Float64
)

Establishes an event condition that is triggered if a variable of type variable_type for a device of type device_type and name device_name is equal to value. and name

Arguments

• variable_type::Type{<:VariableType}: variable to be monitored
• device_type::Type{<:PSY.Device}: device type to be monitored
• device_name::String: name of monitored device
• value::Float64: value to compare to in p.u.

empty!(store::PowerSimulations.EmulationModelStore)

Base.empty!(store::EmulationModelStore)

Empty the EmulationModelStore

empty!(cache::PowerSimulations.OptimizationOutputCaches)

Base.empty!(cache::OptimizationOutputCaches)

Empty the OptimizationOutputCaches

empty!(cache::PowerSimulations.OptimizationOutputCache)

Base.empty!(cache::OptimizationOutputCache)

Empty the OptimizationOutputCache

empty!(res::SimulationResults)

Base.empty!(res::SimulationResults)

Empty the SimulationResults

read_results_with_keys(
    res::PowerSimulations.SimulationProblemResults{PowerSimulations.DecisionModelSimulationResults},
    result_keys::Vector{<:InfrastructureSystems.Optimization.OptimizationContainerKey};
    start_time,
    len,
    cols,
    table_format
) -> Dict{InfrastructureSystems.Optimization.OptimizationContainerKey, DataFrame}

High-level function to read a DataFrame of results.

Arguments

• res: the results to read.
• result_keys::Vector{<:OptimizationContainerKey}: the keys to read. Output will be a Dict{OptimizationContainerKey, DataFrame} with these as the keys
• start_time::Union{Nothing, Dates.DateTime} = nothing: the time at which the resulting time series should begin; nothing indicates the first time in the results
• len::Union{Int, Nothing} = nothing: the number of steps in the resulting time series; nothing indicates up to the end of the results
• cols::Union{Colon, Vector{String}} = (:): which columns to fetch; defaults to :, i.e., all the columns

to_matrix(vec::Vector) -> Matrix

Convert Vectors, DenseAxisArrays, and SparkAxisArrays to a matrix.

• If the input is a 1d array or DenseAxisArray, the returned matrix will have a number of rows equal to the length of the input and one column.
• If the input is a 2d DenseAxisArray, the dimensions are transposed, due to the way we store outputs in JuMP.

_accumulate_headroom!(
    pf_data::PowerFlows.PowerFlowData,
    container::PowerSimulations.OptimizationContainer,
    sys::System,
    key::InfrastructureSystems.Optimization.OptimizationContainerKey{<:InfrastructureSystems.Optimization.OptimizationKeyType, U<:Component},
    component_map::Dict{String, Int64},
    n_time_steps::Int64,
    bus_types::Matrix{ACBusTypes},
    computed_gspf::Vector{Dict{Tuple{DataType, String}, Float64}}
)

Accumulate headroom for a single OptimizationContainerKey into pf_data and computed_gspf. The where {U} parameter makes the component type a compile-time constant, so PSY.get_component(U, ...), has_container_key(..., U), and the (U, device_name) Dict key all dispatch concretely. Note that result and ts_param_values remain abstractly typed because OptimizationContainer.variables and .parameters have abstract value types in their dict signatures — the inner indexing into them still goes through dynamic dispatch.

_accumulate_in_out_headroom!(
    pf_data::PowerFlows.PowerFlowData,
    container::PowerSimulations.OptimizationContainer,
    sys::System,
    in_inputs::Dict{InfrastructureSystems.Optimization.OptimizationContainerKey, Dict{String, Int64}},
    out_inputs::Dict{InfrastructureSystems.Optimization.OptimizationContainerKey, Dict{String, Int64}},
    n_time_steps::Int64,
    bus_types::Matrix{ACBusTypes},
    computed_gspf::Vector{Dict{Tuple{DataType, String}, Float64}}
)

Accumulate headroom for devices that use split ActivePowerInVariable / ActivePowerOutVariable (e.g. Storage BookKeeping, Source ImportExportSourceModel).

net = p_out - p_in is the device's signed contribution at time t. With net > 0 the device is dispatching and its headroom is p_max_out - net; with net <= 0 the device is charging (or idle) and contributes no upward slack.

_add_category_to_map!(
    precedence::Vector{DataType},
    available_keys::Vector{Pair{InfrastructureSystems.Optimization.OptimizationContainerKey, Any}},
    temp_component_map::Dict{DataType, <:Dict},
    pf_data_opt_container_map::Dict{InfrastructureSystems.Optimization.OptimizationContainerKey, <:Dict}
)

_add_category_to_map!(
    precedence::Vector{DataType},
    available_keys::Vector{Pair{OptimizationContainerKey, Any}},
    temp_component_map::Union{
        Dict{DataType, Dict{String, Int}},
        Dict{DataType, Dict{Union{Int64, String}, String}},
    },
    pf_data_opt_container_map::Union{
        Dict{OptimizationContainerKey, Dict{String, Int}},
        Dict{OptimizationContainerKey, Dict{Union{Int64, String}, String}},
    },
)

Helper function that is used in makepfinputmap! and addtwoterminalelementsmap! to configure which variables from the optimization results get written to the PowerFlowData. For every results variable from the optimization, it finds the corresponding mapping between the optimization variable and the PowerFlowData variable. The mappings are added to the `pfdataoptcontainer_map` Dict. This step is executed during the build stage of the optimization. The results are written to the PowerFlowData in the solve stage, before the power flow is solved.

Arguments

• precedence::Vector{DataType}: A vector of DataType objects that defines the order of precedence for the variables that correspond to the category of variables (e.g. :active_power - first look for ActivePowerVariable for the component type, if not available then PowerOutput, and finally ActivePowerTimeSeriesParameter).
• available_keys::Vector{Pair{OptimizationContainerKey, Any}}: A vector of key-value pairs where the key is an OptimizationContainerKey and the value contains data associated with the key.
• temp_component_map::Union{Dict{DataType, Dict{String, Int}}, Dict{DataType, Dict{Union{Int64, String}, String}}}: A mapping for component types to point the component-level results (e.g. as voltage value for bus "A") to the appropriate variable in PowerFlowData (e.g. row 27 in the bus-related matrices).
• pf_data_opt_container_map::Union{Dict{OptimizationContainerKey, Dict{String, Int}}, Dict{OptimizationContainerKey, Dict{Union{Int64, String}, String}}}: The target Dict that contains mappings for all relevant component types.

_add_generic_incremental_interpolation_constraint!(
    container::PowerSimulations.OptimizationContainer,
    ::InfrastructureSystems.Optimization.VariableType,
    ::InfrastructureSystems.Optimization.VariableType,
    ::InfrastructureSystems.Optimization.VariableType,
    ::InfrastructureSystems.Optimization.VariableType,
    ::InfrastructureSystems.Optimization.ConstraintType,
    devices::InfrastructureSystems.FlattenIteratorWrapper{W<:Component},
    dic_var_bkpts::Dict{String, Vector{Float64}},
    dic_function_bkpts::Dict{String, Vector{Float64}};
    meta
)

_add_generic_incremental_interpolation_constraint!(container, ::R, ::S, ::T, ::U, ::V, devices, dic_var_bkpts, dic_function_bkpts; meta)

Add incremental piecewise linear interpolation constraints to an optimization container.

This function implements the incremental method for piecewise linear approximation in optimization models. It creates constraints that relate the original variable (x) to its piecewise linear approximation (y = f(x)) using interpolation variables (δ) and binary variables (z) to ensure proper ordering.

The incremental method represents each segment of the PWL function as:

• x = x₁ + Σᵢ δᵢ(xᵢ₊₁ - xᵢ) where δᵢ ∈ [0,1]
• y = y₁ + Σᵢ δᵢ(yᵢ₊₁ - yᵢ) where yᵢ = f(xᵢ)

Binary variables z ensure the incremental property: δᵢ₊₁ ≤ zᵢ ≤ δᵢ for adjacent segments.

Arguments

• container::OptimizationContainer: The optimization container to add constraints to
• ::R: Type parameter for the original variable (x)
• ::S: Type parameter for the approximated variable (y = f(x))
• ::T: Type parameter for the interpolation variables (δ)
• ::U: Type parameter for the binary interpolation variables (z)
• ::V: Type parameter for the constraint type
• devices::IS.FlattenIteratorWrapper{W}: Collection of devices to apply constraints to
• dic_var_bkpts::Dict{String, Vector{Float64}}: Breakpoints in the domain (x-coordinates) for each device
• dic_function_bkpts::Dict{String, Vector{Float64}}: Function values at breakpoints (y-coordinates) for each device
• meta: Metadata for constraint naming (default: empty)

Type Parameters

• R <: VariableType: Original variable type
• S <: VariableType: Approximated variable type
• T <: VariableType: Interpolation variable type
• U <: VariableType: Binary interpolation variable type
• V <: ConstraintType: Constraint type
• W <: PSY.Component: Component type for devices

Notes

• Creates two types of constraints: variable interpolation and function interpolation
• Adds ordering constraints for binary variables to ensure incremental property
• All constraints are applied for each device and time step

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

Register an empty SparseAxisArray keyed by (outage_id::String, monitored_name::String, t::Int) for the given constraint type and meta tag. Entries are populated by JuMP.@constraint assignments during the build. V here is the outaged component type the DeviceModel owns; the container's name axis spans every monitored type associated with those outages.

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

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

_add_pwl_constraint!(
    container::PowerSimulations.OptimizationContainer,
    component::Component,
    _::InfrastructureSystems.Optimization.VariableType,
    break_points::Vector{Float64},
    sos_status::PowerSimulations.SOSStatusVariableModule.SOSStatusVariable,
    period::Int64
)

Implement the constraints for PWL variables. That is:

\[\sum_{k\in\mathcal{K}} P_k^{max} \delta_{k,t} = p_t \\ \sum_{k\in\mathcal{K}} \delta_{k,t} = on_t\]

_add_pwl_constraint!(
    container::PowerSimulations.OptimizationContainer,
    component::Component,
    _::PowerAboveMinimumVariable,
    break_points::Vector{Float64},
    sos_status::PowerSimulations.SOSStatusVariableModule.SOSStatusVariable,
    period::Int64
)

Implement the constraints for PWL variables for Compact form. That is:

\[\sum_{k\in\mathcal{K}} P_k^{max} \delta_{k,t} = p_t + P_min * u_t \\ \sum_{k\in\mathcal{K}} \delta_{k,t} = on_t\]

_add_pwl_constraint!(
    container::PowerSimulations.OptimizationContainer,
    component::ReserveDemandCurve,
    _::ServiceRequirementVariable,
    break_points::Vector{Float64},
    sos_status::PowerSimulations.SOSStatusVariableModule.SOSStatusVariable,
    period::Int64
)

Implement the constraints for PWL Block Offer variables for ORDC. That is:

\[\sum_{k\in\mathcal{K}} \delta_{k,t} = p_t \\ \sum_{k\in\mathcal{K}} \delta_{k,t} <= P_{k+1,t}^{max} - P_{k,t}^{max}\]

_add_pwl_constraint!(
    container::PowerSimulations.OptimizationContainer,
    component::Component,
    _::InfrastructureSystems.Optimization.VariableType,
    _::PowerSimulations.AbstractDeviceFormulation,
    break_points::Vector{<:Union{Float64, JuMP.AbstractJuMPScalar}},
    period::Int64,
    _::Type{V<:PowerSimulations.AbstractPiecewiseLinearBlockOffer},
    _::Type{W<:PowerSimulations.AbstractPiecewiseLinearBlockOfferConstraint}
)

Implement the constraints for PWL Block Offer variables. That is:

\[\sum_{k\in\mathcal{K}} \delta_{k,t} = p_t \\ \sum_{k\in\mathcal{K}} \delta_{k,t} <= P_{k+1,t}^{max} - P_{k,t}^{max}\]

_add_pwl_sos_constraint!(
    container::PowerSimulations.OptimizationContainer,
    component::Component,
    _::InfrastructureSystems.Optimization.VariableType,
    break_points::Vector{Float64},
    sos_status::PowerSimulations.SOSStatusVariableModule.SOSStatusVariable,
    period::Int64
)

Implement the SOS for PWL variables. That is:

\[\{\delta_{i,t}, ..., \delta_{k,t}\} \in \text{SOS}_2\]

_add_pwl_term!(
    container::PowerSimulations.OptimizationContainer,
    component::Component,
    cost_function::Union{CostCurve{PiecewisePointCurve}, FuelCurve{PiecewisePointCurve}},
    _::InfrastructureSystems.Optimization.VariableType,
    _::PowerSimulations.AbstractDeviceFormulation
) -> Vector{JuMP.AffExpr}

Add PWL cost terms for data coming from a PiecewisePointCurve

_add_pwl_term!(
    container::PowerSimulations.OptimizationContainer,
    component::ThermalGen,
    cost_function::Union{CostCurve{PiecewisePointCurve}, FuelCurve{PiecewisePointCurve}},
    _::InfrastructureSystems.Optimization.VariableType,
    _::ThermalDispatchNoMin
) -> Vector{JuMP.AffExpr}

Add PWL cost terms for data coming from a PiecewisePointCurve for ThermalDispatchNoMin formulation

_add_two_terminal_elements_map!(
    sys::System,
    pf_data::PowerFlows.PowerFlowData,
    available_keys::Vector{Pair{InfrastructureSystems.Optimization.OptimizationContainerKey, Any}},
    input_key_map::Dict{Symbol, <:Dict{InfrastructureSystems.Optimization.OptimizationContainerKey, <:Dict}}
)

_add_two_terminal_elements_map!(
    sys::PSY.System,
    pf_data::PFS.PowerFlowData,
    available_keys::Vector{Pair{OptimizationContainerKey, Any}},
    input_key_map::Dict{Symbol, Dict{OptimizationContainerKey, Dict{String, Int64}}}
)

Adds mappings for two-terminal elements (HVDC components) that connect the power flow results (from -> to, to -> from) to be added to the mappings for all component types. The results for these elements are added as bus injections in the PowerFlowData as a simplified representation of these components.

Arguments

• sys::PSY.System: System instance representing the power system model.
• pf_data::PFS.PowerFlowData: The power flow data used internally for power flow calculations.
• available_keys::Vector{Pair{OptimizationContainerKey, Any}}: A vector of available optimization container keys and their associated values.
• input_key_map::Dict{Symbol, Dict{OptimizationContainerKey, Dict{String, Int64}}}: A dictionary mapping categories to optimization container keys and their associated mappings. To be extended in this function by the mappings for the two-terminal elements to the respective buses in the PowerFlowData instance.

_add_variable_cost_to_objective!(
    container::PowerSimulations.OptimizationContainer,
    _::InfrastructureSystems.Optimization.VariableType,
    component::Component,
    cost_function::CostCurve{LinearCurve},
    _::PowerSimulations.AbstractDeviceFormulation
)

Adds to the cost function cost terms for sum of variables with common factor to be used for cost expression for optimization_container model.

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• var_key::VariableKey: The variable name
• componentname::String: The componentname of the variable container
• cost_component::PSY.CostCurve{PSY.LinearCurve} : container for cost to be associated with variable

_add_variable_cost_to_objective!(
    container::PowerSimulations.OptimizationContainer,
    _::InfrastructureSystems.Optimization.VariableType,
    component::Component,
    cost_function::CostCurve{PiecewisePointCurve},
    _::PowerSimulations.AbstractDeviceFormulation
)

Creates piecewise linear cost function using a sum of variables and expression with sign and time step included.

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• var_key::VariableKey: The variable name
• componentname::String: The componentname of the variable container
• cost_function::PSY.CostCurve{PSY.PiecewisePointCurve}: container for piecewise linear cost

_add_variable_cost_to_objective!(
    container::PowerSimulations.OptimizationContainer,
    _::InfrastructureSystems.Optimization.VariableType,
    component::Component,
    cost_function::CostCurve{QuadraticCurve},
    _::PowerSimulations.AbstractDeviceFormulation
)

Adds to the cost function cost terms for sum of variables with common factor to be used for cost expression for optimization_container model.

Equation

gen_cost = dt*sign*(sum(variable.^2)*cost_data[1] + sum(variable)*cost_data[2])

LaTeX

$cost = dt\times sign (sum_{i\in I} c_1 v_i^2 + sum_{i\in I} c_2 v_i )$

for quadratic factor large enough. If the first term of the quadratic objective is 0.0, adds a linear cost term sum(variable)*cost_data[2]

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• var_key::VariableKey: The variable name
• componentname::String: The componentname of the variable container
• cost_component::PSY.CostCurve{PSY.QuadraticCurve} : container for quadratic factors

_add_variable_cost_to_objective!(
    container::PowerSimulations.OptimizationContainer,
    _::InfrastructureSystems.Optimization.VariableType,
    component::Component,
    cost_function::FuelCurve{LinearCurve},
    _::PowerSimulations.AbstractDeviceFormulation
)

Adds to the cost function cost terms for sum of variables with common factor to be used for cost expression for optimization_container model.

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• var_key::VariableKey: The variable name
• componentname::String: The componentname of the variable container
• cost_component::PSY.FuelCurve{PSY.LinearCurve} : container for cost to be associated with variable

_add_variable_cost_to_objective!(
    container::PowerSimulations.OptimizationContainer,
    _::InfrastructureSystems.Optimization.VariableType,
    component::Component,
    cost_function::FuelCurve{PiecewisePointCurve},
    _::PowerSimulations.AbstractDeviceFormulation
)

Creates piecewise linear cost function using a sum of variables and expression with sign and time step included.

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• var_key::VariableKey: The variable name
• componentname::String: The componentname of the variable container
• cost_function::PSY.CostCurve{PSY.PiecewisePointCurve}: container for piecewise linear cost

_add_variable_cost_to_objective!(
    container::PowerSimulations.OptimizationContainer,
    _::InfrastructureSystems.Optimization.VariableType,
    component::Component,
    cost_function::FuelCurve{QuadraticCurve},
    _::PowerSimulations.AbstractDeviceFormulation
)

Adds to the cost function cost terms for sum of variables with common factor to be used for cost expression for optimization_container model.

Equation

gen_cost = dt*(sum(variable.^2)*cost_data[1]*fuel_cost + sum(variable)*cost_data[2]*fuel_cost)

LaTeX

$cost = dt\times (sum_{i\in I} c_f c_1 v_i^2 + sum_{i\in I} c_f c_2 v_i )$

for quadratic factor large enough. If the first term of the quadratic objective is 0.0, adds a linear cost term sum(variable)*cost_data[2]

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• var_key::VariableKey: The variable name
• componentname::String: The componentname of the variable container
• cost_component::PSY.FuelCurve{PSY.QuadraticCurve} : container for quadratic factors

_add_variable_cost_to_objective!(
    container::PowerSimulations.OptimizationContainer,
    _::InfrastructureSystems.Optimization.VariableType,
    component::Component,
    cost_function::OfferCurveCost,
    _::PowerSimulations.AbstractDeviceFormulation
)

Creates piecewise linear market bid function using a sum of variables and expression for market participants. Decremental offers are not accepted for most components, except Storage systems and loads.

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• var_key::VariableKey: The variable name
• componentname::String: The componentname of the variable container
• cost_function::MarketBidCost : container for market bid cost

_add_variable_cost_to_objective!(
    container::PowerSimulations.OptimizationContainer,
    _::InfrastructureSystems.Optimization.VariableType,
    component::Component,
    cost_function::Union{CostCurve{PiecewiseAverageCurve}, CostCurve{PiecewiseIncrementalCurve}},
    _::PowerSimulations.AbstractDeviceFormulation
)

Creates piecewise linear cost function using a sum of variables and expression with sign and time step included.

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• var_key::VariableKey: The variable name
• componentname::String: The componentname of the variable container
• cost_function::PSY.Union{PSY.CostCurve{PSY.PiecewiseIncrementalCurve}, PSY.CostCurve{PSY.PiecewiseAverageCurve}}: container for piecewise linear cost

_add_variable_cost_to_objective!(
    container::PowerSimulations.OptimizationContainer,
    _::InfrastructureSystems.Optimization.VariableType,
    component::Component,
    cost_function::Union{FuelCurve{PiecewiseAverageCurve}, FuelCurve{PiecewiseIncrementalCurve}},
    _::PowerSimulations.AbstractDeviceFormulation
)

Creates piecewise linear fuel cost function using a sum of variables and expression with sign and time step included.

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• var_key::VariableKey: The variable name
• componentname::String: The componentname of the variable container
• cost_function::PSY.Union{PSY.FuelCurve{PSY.PiecewiseIncrementalCurve}, PSY.FuelCurve{PSY.PiecewiseAverageCurve}}: container for piecewise linear cost

_allocate_execution_order(
    interval_run_counts::Vector{Int64}
) -> Vector{Int64}

Function calculates the total number of problem executions in the simulation and allocates the appropiate vector

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

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

_build_device_model_outages!(
    template::ProblemTemplate,
    sys::System
)

Populate device_model.outages for every security-constrained (SC) branch device model in the template, in a single pass over the system's outage supplemental attributes. DeviceModel{D, SC} claims an outage iff D is among the types of the outaged (attached) components — so the OUTAGED component's type must be covered by an SC DeviceModel for the outage to contribute any constraints. For a multi-component outage tripping components of N>1 types, every matching SC DeviceModel claims it; the post-contingency build (add_post_contingency_*) deduplicates by referencing the first claimer's expressions/constraints.

The inner dict carries the per-modeled-type breakdown of monitored component names. Monitored components do NOT need to be security-constrained themselves: an SC DeviceModel{Line, SecurityConstrainedStaticBranch} may claim an outage whose monitored set includes non-SC Transformer2W components, and the post-contingency build then bounds those Transformer flows under that outage.

Selection semantics:

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

There is no implicit "monitor everything" default. The monitored set is exactly what each outage lists in its monitored_components; an outage with empty monitored_components is treated as "monitor nothing" — a warning is emitted and it contributes no post-contingency constraints. This is intentional: defaulting to monitoring every branch under every outage would silently build an N-1-everything-by-everything problem that is intractable for realistic systems, so monitoring is strictly opt-in per branch.

A monitored component whose type is not a modeled PSY.ACTransmission branch type (either not in the template, or modeled but not a branch) is reported once per type with the offending outage UUIDs and is skipped: no post-contingency variables or constraints are built for that monitored component under any outage.

_build_network_reductions(
    model::NetworkModel
) -> Vector{PowerNetworkMatrices.NetworkReduction}

Build the NetworkReduction specs for one matrix construction. As of PowerNetworkMatrices 0.22 the reduction specs are field-less configuration objects; the set of buses to protect from elimination is supplied separately via the irreducible_buses keyword on the matrix constructor (Ybus / VirtualPTDF / VirtualMODF), which seeds it once into the reduction container and shares it across all reduction stages.

_calculate_interval_inner_counts(
    intervals::OrderedDict{Symbol, Dates.Millisecond}
) -> Vector{Int64}

calculateintervalinnercounts(intervals::OrderedDict{String,<:Dates.TimePeriod})

Calculates how many times a problem is executed for every interval of the previous problem

_consolidate_device_model_outages_with_modf!(
    branch_models::Dict{Symbol, DeviceModel{<:Branch}},
    modf_matrix::VirtualMODF
)

Drop outages from each SC-branch DeviceModel whose UUID isn't registered on modf_matrix; without this they'd KeyError downstream in add_post_contingency_flow_expressions!. PNM's _register_outages! silently skips outages it can't convert to a NetworkModification.

_copy_existing_post_contingency_expressions!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:PowerSimulations.PostContingencyExpressions},
    _::Type{V<:ACTransmission},
    expression_container::JuMP.Containers.SparseAxisArray,
    resolved::Vector{Pair{Base.UUID, Vector{Tuple{DataType, String, Tuple{Int64, Int64}, String}}}},
    time_steps::UnitRange{Int64}
) -> Vector{Pair{Base.UUID, Vector{Tuple{DataType, String, Tuple{Int64, Int64}, String}}}}

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

_copy_template_for_build(
    template::ProblemTemplate
) -> ProblemTemplate

_copy_template_for_build(template::ProblemTemplate)

Return an independently-mutable copy of template for build! to own, sharing the network model's PTDF_matrix/MODF_matrix by reference. Those matrices wrap a libklu/libSparse factorization behind a finalizer-owned raw pointer that is not safe to deepcopy (copying it aliases one handle across two objects). The matrices are only ever reassigned during build, never mutated in place, so sharing is safe.

_ensure_ptdf_modf_consistent!(
    model::NetworkModel{<:PowerSimulations.AbstractPTDFModel},
    sys::System
)

Guarantee the PTDF and MODF share an identical bus_reduction_map so the nodal-balance rows and post-contingency MODF columns are dimensionally aligned. VirtualMODF auto-protects monitored/outaged buses (VirtualPTDF does not), so the MODF's retained set is the maximal one and is taken as the source of truth. When the two disagree, keep the MODF and rebuild only the PTDF pinning the MODF's retained buses, which forces the PTDF to reproduce exactly the MODF reduction. Throw only if the two still diverge, which indicates a PowerNetworkMatrices reduction defect rather than mismatched inputs.

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

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

_get_breakpoints_for_pwl_function(
    min_val::Float64,
    max_val::Float64,
    f;
    num_segments
) -> Tuple{Vector{Float64}, Vector{Float64}}

_get_breakpoints_for_pwl_function(min_val, max_val, f; num_segments = DEFAULT_INTERPOLATION_LENGTH)

Generate breakpoints for piecewise linear (PWL) approximation of a nonlinear function.

This function creates equally-spaced breakpoints over the specified domain [minval, maxval] and evaluates the given function at each breakpoint to construct a piecewise linear approximation. The breakpoints are used in optimization problems to linearize nonlinear constraints or objectives.

Arguments

• min_val::Float64: Minimum value of the domain for the PWL approximation
• max_val::Float64: Maximum value of the domain for the PWL approximation
• f: Function to be approximated (must be callable with Float64 input)
• num_segments::Int: Number of linear segments in the PWL approximation (default: DEFAULTINTERPOLATIONLENGTH)

Returns

• Tuple{Vector{Float64}, Vector{Float64}}: A tuple containing:
  • x_bkpts: Vector of x-coordinates (breakpoints) in the domain
  • y_bkpts: Vector of y-coordinates (function values at breakpoints)

Notes

• The number of breakpoints is num_segments + 1
• Breakpoints are equally spaced across the domain
• The first breakpoint is always at min_val and the last at max_val

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

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

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

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

_get_irreducible_buses_due_to_monitored_components(
    sys::System,
    network_model::NetworkModel,
    branch_models::Dict{Symbol, DeviceModel{<:Branch}}
) -> Vector{Int64}

Buses that must be preserved through PNM reductions because something pinned to them is monitored by the simulation. Sources of pinning:

• Branches carrying a BranchRatingTimeSeriesParameter — both endpoint buses are pinned.
• Outages registered on an SC-formulated branch DeviceModel — their monitored_components and associated_components pin buses (for branch components both endpoints, for non-branch devices the connecting bus). Outages on non-SC devices are not consumed and do not pin anything.

The result is unioned and consumed by _build_network_reductions and the matrix constructors in instantiate_network_model!.

_get_pwl_cost_expression(
    container::PowerSimulations.OptimizationContainer,
    component::ReserveDemandCurve,
    time_period::Int64,
    slopes_normalized::Vector{Float64},
    multiplier::Float64
) -> JuMP.AffExpr

Get cost expression for StepwiseCostReserve

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

Fast-path precheck: returns true iff any container of entry type T exists under a component type other than V. The dedup probe scans container.expressions or container.constraints linearly per call; on the common single-component-outage path no other-V container exists yet and every probe returns nothing — so we short-circuit the entire pre-pass when this returns false.

_lookup_maybe_time_variant_param(
    _::PowerSimulations.OptimizationContainer,
    component::Component,
    _::Int64,
    _::Val{false},
    getter_func::Function,
    _::InfrastructureSystems.Optimization.ParameterType
) -> Any

Either looks up a value in the component using getter_func or fetches the value from the parameter U(), depending on whether we are in the time-variant case or not

_reductions_match(
    a::PowerNetworkMatrices.PowerNetworkMatrix,
    b::VirtualMODF
) -> Bool

True when two network matrices carry the same reduction, compared by full bus_reduction_map equality (keys and values). This is the invariant the post-contingency builder relies on: it resolves monitored arcs from the reduced bus/arc numbering and indexes modf[arc, outage_spec], so the PTDF (which dimensions the nodal balance) and the MODF must agree on the entire map, not just the retained-bus key set.

_resolve_monitored_arcs(
    device_model::DeviceModel,
    net_reduction_data::PowerNetworkMatrices.NetworkReductionData
) -> Vector{Pair{Base.UUID, Vector{Tuple{DataType, String, Tuple{Int64, Int64}, String}}}}

For each outage in device_model.outages, resolve every monitored component (across every monitored type) to its arc in the active reduction graph — using component_to_reduction_name_map as a redirect when the monitored name is an individual component that was reduced into a representative. Duplicate arcs within an outage are collapsed per-type. Outages sorted by UUID for deterministic axes.

Template validation is expected to guarantee that every monitored type has an entry in the reduction maps and every monitored name resolves; missing entries will raise KeyError here.

Returns Vector{Pair{UUID, Vector{Tuple{Type, String, Tuple{Int, Int}, String}}}} where each inner tuple is (monitored_type, container_name, arc, reduction_kind). The monitored_type is needed by callers to fetch the correct post-contingency flow variable for that component.

_resolve_reduced_matrix(
    provided::Union{Nothing, PowerNetworkMatrices.PowerNetworkMatrix},
    label::String,
    irreducible_buses::Vector{Int64},
    build
) -> Any

Keep a provided reduced matrix only when it already retains every bus in irreducible_buses (the buses pinned by monitored components — time-series bounds and/or outage-monitored devices); otherwise rebuild it with build so those buses survive the reduction. Keeping a sufficient matrix avoids discarding valid user input. Shared by the PTDF and MODF paths; label ("PTDF" / "MODF") only names the matrix in the log messages, and build is a zero-arg thunk that recomputes it with the identified irreducible buses pinned.

_retained_buses(
    nrd::PowerNetworkMatrices.NetworkReductionData
) -> Set{Int64}

Buses retained by nrd — the keys of the bus reduction map, which PNM initializes with every available non-isolated bus and prunes as buses are eliminated (Ybus build). This key set is therefore exactly the matrix's bus dimension.

This is not the same as get_irreducible_buses(nrd): that field accumulates (via union!) every bus each reduction stage flagged as protected — including all injection buses added by a DegreeTwoReduction. A protected injection bus that sits on a radial leaf can still be eliminated by a RadialReduction stage, so irreducible_buses is not a subset of the retained keys and must not be treated as one.

_summary_to_dict!(
    optimizer_stats::OptimizerStats,
    jump_model::JuMP.Model
)

Run this function only when getting detailed solver stats

_to_is_interval(
    interval::Dates.Millisecond
) -> Union{Nothing, Dates.Millisecond}

Convert the internal Dates.Millisecond interval (where UNSET_INTERVAL means unset) to the Union{Nothing, Dates.Period} form the IS / PSY time-series API expects. Internal hot paths carry a concrete Dates.Millisecond to stay type-stable; this helper performs the boundary conversion.

_to_is_resolution(
    resolution::Dates.Millisecond
) -> Union{Nothing, Dates.Millisecond}

Convert the internal Dates.Millisecond resolution (where UNSET_RESOLUTION means unset) to the Union{Nothing, Dates.Period} form the IS / PSY time-series API expects.

_update_headroom_participation_factors!(
    pf_data::PowerFlows.PowerFlowData,
    container::PowerSimulations.OptimizationContainer,
    sys::System,
    input_key_map::Dict{Symbol, Dict{InfrastructureSystems.Optimization.OptimizationContainerKey, Dict{String, Int64}}}
)

Recompute per-time-step headroom-proportional generator slack participation factors using optimization results. Only runs if headroom proportional slack was enabled during initialization.

For each generator at a REF or PV bus, headroom is P_max(t) - P_setpoint(t), where P_setpoint(t) comes from the optimization result and P_max(t) is the minimum of the static device limit and any ActivePowerTimeSeriesParameter at time t. Devices that use split In/Out active power variables are handled separately via _accumulate_in_out_headroom!. This overwrites the PF-initialized values (which were computed once from static system data) with time-varying factors.

_validate_eltype(
    ::Type{T},
    component::Component,
    ts_key::TimeSeriesKey
) -> Any
_validate_eltype(
    ::Type{T},
    component::Component,
    ts_key::TimeSeriesKey,
    msg
) -> Any

Validate that the eltype of the time series, or the field itself if it's not a time series, is of the type given

_validate_ptdf_reduction_flags(
    model::NetworkModel{<:PowerSimulations.AbstractPTDFModel}
)

Validate a kept PTDF matrix's embedded reductions against the model's reduce flags. A rebuilt matrix satisfies these by construction; the checks matter when a provided matrix is kept.

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

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

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    cons_type::Type{FlowRateConstraintFromTo},
    devices::InfrastructureSystems.FlattenIteratorWrapper{B<:ACTransmission},
    device_model::DeviceModel{B<:ACTransmission, <:PowerSimulations.AbstractBranchFormulation},
    network_model::NetworkModel{T<:PowerModels.AbstractPowerModel}
)

Add rate limit from to constraints for ACBranch with AbstractPowerModel.

When BranchRatingTimeSeriesParameter is configured on the device_model, the per-timestep rate is parameter_value * multiplier (where the multiplier is the static rating); otherwise the static rating from the reduction entry is used.

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    cons_type::Type{FlowRateConstraintToFrom},
    devices::InfrastructureSystems.FlattenIteratorWrapper{B<:ACTransmission},
    device_model::DeviceModel{B<:ACTransmission, <:PowerSimulations.AbstractBranchFormulation},
    network_model::NetworkModel{T<:PowerModels.AbstractPowerModel}
)

Add rate limit to from constraints for ACBranch with AbstractPowerModel.

When BranchRatingTimeSeriesParameter is configured on the device_model, the per-timestep rate is parameter_value * multiplier (where the multiplier is the static rating); otherwise the static rating from the reduction entry is used.

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{FlowLimitConstraint},
    devices::InfrastructureSystems.FlattenIteratorWrapper{AreaInterchange},
    model::DeviceModel{AreaInterchange, StaticBranch},
    _::NetworkModel{T<:PowerModels.AbstractActivePowerModel}
)

Add flow constraints for area interchanges

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{NetworkFlowConstraint},
    devices::InfrastructureSystems.FlattenIteratorWrapper{T<:PhaseShiftingTransformer},
    model::DeviceModel{T<:PhaseShiftingTransformer, PhaseAngleControl},
    network_model::NetworkModel{<:PowerSimulations.AbstractPTDFModel}
)

Add network flow constraints for PhaseShiftingTransformer and NetworkModel with <: AbstractPTDFModel

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{NetworkFlowConstraint},
    devices::InfrastructureSystems.FlattenIteratorWrapper{T<:PhaseShiftingTransformer},
    model::DeviceModel{T<:PhaseShiftingTransformer, PhaseAngleControl},
    _::NetworkModel{DCPPowerModel}
)

Add network flow constraints for PhaseShiftingTransformer and NetworkModel with PM.DCPPowerModel

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    cons_type::Type{NetworkFlowConstraint},
    devices::InfrastructureSystems.FlattenIteratorWrapper{T<:ACTransmission},
    device_model::DeviceModel{T<:ACTransmission, StaticBranchBounds},
    network_model::NetworkModel{<:PowerSimulations.AbstractPTDFModel}
)

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

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{StartTypeConstraint},
    devices::InfrastructureSystems.FlattenIteratorWrapper{T<:ThermalMultiStart},
    model::DeviceModel{T<: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::PowerSimulations.OptimizationContainer,
    _::Type{StartupInitialConditionConstraint},
    devices::InfrastructureSystems.FlattenIteratorWrapper{T<:ThermalMultiStart},
    model::DeviceModel{T<: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::PowerSimulations.OptimizationContainer,
    _::Type{StartupTimeLimitTemperatureConstraint},
    devices::InfrastructureSystems.FlattenIteratorWrapper{T<:ThermalMultiStart},
    model::DeviceModel{T<: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::PowerSimulations.OptimizationContainer,
    _::Type{PhaseAngleControlLimit},
    devices::InfrastructureSystems.FlattenIteratorWrapper{T<:PhaseShiftingTransformer},
    model::DeviceModel{T<:PhaseShiftingTransformer, PhaseAngleControl},
    _::NetworkModel{U<:PowerModels.AbstractActivePowerModel}
)

Add phase angle limits for phase shifters

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{FlowLimitConstraint},
    devices::InfrastructureSystems.FlattenIteratorWrapper{T<:Union{MonitoredLine, PhaseShiftingTransformer}},
    model::DeviceModel{T<:Union{MonitoredLine, PhaseShiftingTransformer}, U<:PowerSimulations.AbstractBranchFormulation},
    _::NetworkModel{V<:PowerModels.AbstractDCPModel}
)

Add branch flow constraints for monitored lines with DC Power Model

add_constraints!(
    _::PowerSimulations.OptimizationContainer,
    _::Type{FlowLimitToFromConstraint},
    devices::InfrastructureSystems.FlattenIteratorWrapper{T<:MonitoredLine},
    model::DeviceModel{T<:MonitoredLine, U<:StaticBranchUnbounded},
    _::NetworkModel{V<:PowerModels.AbstractActivePowerModel}
)

Don't add branch flow constraints for monitored lines if formulation is StaticBranchUnbounded

add_constraints!(
    _::PowerSimulations.OptimizationContainer,
    _::Type{FlowRateConstraintFromTo},
    devices::InfrastructureSystems.FlattenIteratorWrapper{T<:MonitoredLine},
    model::DeviceModel{T<:MonitoredLine, U<:StaticBranchUnbounded},
    _::NetworkModel{V<:PowerModels.AbstractActivePowerModel}
)

Don't add branch flow constraints for monitored lines if formulation is StaticBranchUnbounded

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    cons_type::Type{FlowRateConstraint},
    devices::InfrastructureSystems.FlattenIteratorWrapper{T<:ACTransmission},
    device_model::DeviceModel{T<:ACTransmission, U<:PowerSimulations.AbstractBranchFormulation},
    network_model::NetworkModel{V<:PowerModels.AbstractActivePowerModel}
)

Add branch rate limit constraints for ACBranch with AbstractActivePowerModel

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    T::Type{RampConstraint},
    devices::InfrastructureSystems.FlattenIteratorWrapper{U<:ThermalGen},
    model::DeviceModel{U<:ThermalGen, V<:PowerSimulations.AbstractThermalUnitCommitment},
    _::NetworkModel{W<:PowerModels.AbstractPowerModel}
)

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

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

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

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    T::Type{<:ActivePowerVariableLimitsConstraint},
    U::Type{<:InfrastructureSystems.Optimization.VariableType},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:ThermalMultiStart},
    _::DeviceModel{V<:ThermalMultiStart, W<:ThermalMultiStartUnitCommitment},
    _::NetworkModel{X<:PowerModels.AbstractPowerModel}
)

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

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    T::Type{<:PowerSimulations.PowerVariableLimitsConstraint},
    U::Type{<:Union{InfrastructureSystems.Optimization.ExpressionType, InfrastructureSystems.Optimization.VariableType}},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:ThermalGen},
    model::DeviceModel{V<:ThermalGen, W<:PowerSimulations.AbstractThermalDispatchFormulation},
    _::NetworkModel{X<:PowerModels.AbstractPowerModel}
)

Semicontinuous range constraints for thermal dispatch formulations

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    T::Type{<:PowerSimulations.PowerVariableLimitsConstraint},
    U::Type{<:Union{InfrastructureSystems.Optimization.ExpressionType, InfrastructureSystems.Optimization.VariableType}},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:ThermalGen},
    model::DeviceModel{V<:ThermalGen, W<:PowerSimulations.AbstractThermalUnitCommitment},
    _::NetworkModel{X<:PowerModels.AbstractPowerModel}
)

Semicontinuous range constraints for unit commitment formulations

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    T::Type{<:PowerSimulations.PowerVariableLimitsConstraint},
    U::Type{<:Union{PowerAboveMinimumVariable, InfrastructureSystems.Optimization.ExpressionType}},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:ThermalGen},
    model::DeviceModel{V<:ThermalGen, W<:ThermalCompactDispatch},
    network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
)

Range constraints for thermal compact dispatch

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    T::Type{<:ReactivePowerVariableLimitsConstraint},
    U::Type{<:ReactivePowerVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:ElectricLoad},
    _::DeviceModel{V<:ElectricLoad, W<:PowerSimulations.AbstractControllablePowerLoadFormulation},
    network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
)

Reactive Power Constraints on Controllable Loads Assume Constant power_factor

add_constraints!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{<:ReactivePowerVariableLimitsConstraint},
    _::Type{<:ReactivePowerVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:RenewableGen},
    _::DeviceModel{V<:RenewableGen, W<:RenewableConstantPowerFactor},
    _::NetworkModel{X<:PowerModels.AbstractPowerModel}
)

Reactive Power Constraints on Renewable Gen Constant power_factor

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

Adds all cost expression containers appropriate for the given device type and formulation in a single pass through the device list.

The default method adds only ProductionCostExpression. The PSY.ThermalGen overload adds its full set of ConstituentCostExpression subtypes (Fuel, StartUp, ShutDown, Fixed, VOM), which automatically propagate into ProductionCostExpression via the ConstituentCostExpression dispatch on add_to_expression!. The PSY.RenewableGen overload adds FixedCostExpression and VOMCostExpression (which propagate the same way) plus CurtailmentCostExpression (a direct CostExpressions subtype, recorded as a per-device reporting expression and not propagated to ProductionCostExpression).

add_feedforward_constraints!(
    container::PowerSimulations.OptimizationContainer,
    _::DeviceModel,
    devices::InfrastructureSystems.FlattenIteratorWrapper{T<:Component},
    ff::UpperBoundFeedforward
)

    ub_ff(container::OptimizationContainer,
          cons_name::Symbol,
          constraint_infos,
          param_reference,
          var_key::VariableKey)

Constructs a parameterized upper bound constraint to implement feedforward from other models. The Parameters are initialized using the uppper boundary values of the provided variables.

variable[var_name, t] <= param_reference[var_name]

LaTeX

$x \leq param^{max}$

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• cons_name::Symbol : name of the constraint
• param_reference : Reference to the JuMP.VariableRef used to determine the upperbound
• var_key::VariableKey : the name of the continuous variable

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

    add_feedforward_constraints(
        container::OptimizationContainer,
        ::DeviceModel,
        devices::IS.FlattenIteratorWrapper{T},
        ff::FixValueFeedforward,
    ) where {T <: PSY.Component}

Constructs a equality constraint to a fix a variable in one model using the variable value from other model results.

variable[var_name, t] == param[var_name, t]

LaTeX

$x == param$

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• model::DeviceModel : the device model
• devices::IS.FlattenIteratorWrapper{T} : list of devices
• ff::FixValueFeedforward : a instance of the FixValue Feedforward

add_feedforward_constraints!(
    container::PowerSimulations.OptimizationContainer,
    _::DeviceModel{T<:Component, U<:PowerSimulations.AbstractDeviceFormulation},
    devices::InfrastructureSystems.FlattenIteratorWrapper{T<:Component},
    ff::LowerBoundFeedforward
)

    lb_ff(container::OptimizationContainer,
          cons_name::Symbol,
          constraint_infos,
          param_reference,
          var_key::VariableKey)

Constructs a parameterized upper bound constraint to implement feedforward from other models. The Parameters are initialized using the uppper boundary values of the provided variables.

variable[var_name, t] <= param_reference[var_name]

LaTeX

$x \leq param^{max}$

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• cons_name::Symbol : name of the constraint
• param_reference : Reference to the JuMP.VariableRef used to determine the upperbound
• var_key::VariableKey : the name of the continuous variable

add_linear_ramp_constraints!(
    container::PowerSimulations.OptimizationContainer,
    T::Type{<:InfrastructureSystems.Optimization.ConstraintType},
    U::Type{S<:Union{ActivePowerVariable, PowerAboveMinimumVariable}},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:Component},
    model::DeviceModel{V<:Component, W<:PowerSimulations.AbstractDeviceFormulation},
    _::Type{<:PowerModels.AbstractPowerModel}
)

Constructs allowed rate-of-change constraints from variables, initial condtions, and rate data.

If t = 1:

variable[name, 1] - initial_conditions[ix].value <= rate_data[1][ix].up

initial_conditions[ix].value - variable[name, 1] <= rate_data[1][ix].down

If t > 1:

variable[name, t] - variable[name, t-1] <= rate_data[1][ix].up

variable[name, t-1] - variable[name, t] <= rate_data[1][ix].down

LaTeX

$r^{down} \leq x_1 - x_{init} \leq r^{up}, \text{ for } t = 1$

$r^{down} \leq x_t - x_{t-1} \leq r^{up}, \forall t \geq 2$

add_pwl_term!(
    is_decremental::Bool,
    container::PowerSimulations.OptimizationContainer,
    component::Component,
    _::OfferCurveCost,
    _::InfrastructureSystems.Optimization.VariableType,
    _::PowerSimulations.AbstractDeviceFormulation
)

Add PWL cost terms for data coming from the MarketBidCost with a fixed incremental offer curve

add_range_constraints!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ConstraintType},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:Component},
    model::DeviceModel{V<:Component, W<:PowerSimulations.AbstractDeviceFormulation},
    _::Type{X<:PowerModels.AbstractPowerModel}
)

Constructs min/max range constraint from device variable.

If min and max within an epsilon width:

variable[name, t] == limits.max

Otherwise:

limits.min <= variable[name, t] <= limits.max

where limits in constraint_infos.

LaTeX

$x = limits^{max}, \text{ for } |limits^{max} - limits^{min}| < \varepsilon$

$limits^{min} \leq x \leq limits^{max}, \text{ otherwise }$

add_reserve_range_constraints!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:InputActivePowerVariableLimitsConstraint},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:Component},
    model::DeviceModel{V<:Component, W<:PowerSimulations.AbstractDeviceFormulation},
    _::Type{X<:PowerModels.AbstractPowerModel}
)

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

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

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

where limits in constraint_infos.

LaTeX

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

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

add_reserve_range_constraints!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:Union{ActivePowerVariableLimitsConstraint, OutputActivePowerVariableLimitsConstraint, ReactivePowerVariableLimitsConstraint}},
    _::Type{U<:InfrastructureSystems.Optimization.ExpressionType},
    devices::InfrastructureSystems.FlattenIteratorWrapper{W<:Component},
    model::DeviceModel{W<:Component, X<:PowerSimulations.AbstractDeviceFormulation},
    _::Type{Y<:PowerModels.AbstractPowerModel}
)

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

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

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

where limits in constraint_infos.

LaTeX

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

add_reserve_range_constraints!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:Union{ActivePowerVariableLimitsConstraint, OutputActivePowerVariableLimitsConstraint, ReactivePowerVariableLimitsConstraint}},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::InfrastructureSystems.FlattenIteratorWrapper{W<:Component},
    model::DeviceModel{W<:Component, X<:PowerSimulations.AbstractDeviceFormulation},
    _::Type{Y<:PowerModels.AbstractPowerModel}
)

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

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

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

where limits in constraint_infos.

LaTeX

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

add_result!(
    cache::PowerSimulations.OptimizationOutputCache,
    timestamp::Dates.DateTime,
    array::Array{Float64},
    system_cache_is_full::Bool
) -> Int64

Add result to the cache.

add_semicontinuous_ramp_constraints!(
    container::PowerSimulations.OptimizationContainer,
    T::Type{<:InfrastructureSystems.Optimization.ConstraintType},
    U::Type{S<:Union{ActivePowerVariable, PowerAboveMinimumVariable}},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:Component},
    model::DeviceModel{V<:Component, W<:PowerSimulations.AbstractDeviceFormulation},
    _::Type{<:PowerModels.AbstractPowerModel}
)

Constructs allowed rate-of-change constraints from variables, initial condtions, start/stop status, and rate data

Equations

If t = 1:

variable[name, 1] - initial_conditions[ix].value <= rate_data[1][ix].up + rate_data[2][ix].max*varstart[name, 1]

initial_conditions[ix].value - variable[name, 1] <= rate_data[1][ix].down + rate_data[2][ix].min*varstop[name, 1]

If t > 1:

variable[name, t] - variable[name, t-1] <= rate_data[1][ix].up + rate_data[2][ix].max*varstart[name, t]

variable[name, t-1] - variable[name, t] <= rate_data[1][ix].down + rate_data[2][ix].min*varstop[name, t]

LaTeX

$r^{down} + r^{min} x^{stop}_1 \leq x_1 - x_{init} \leq r^{up} + r^{max} x^{start}_1, \text{ for } t = 1$

$r^{down} + r^{min} x^{stop}_t \leq x_t - x_{t-1} \leq r^{up} + r^{max} x^{start}_t, \forall t \geq 2$

add_semicontinuous_range_constraints!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.ConstraintType},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:Component},
    model::DeviceModel{V<:Component, W<:PowerSimulations.AbstractDeviceFormulation},
    _::Type{X<:PowerModels.AbstractPowerModel}
)

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

If device min = 0:

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

varcts[name, t] >= 0.0

Otherwise:

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

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

where limits in constraint_infos.

LaTeX

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

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

add_sparse_pwl_interpolation_variables!(
    container::PowerSimulations.OptimizationContainer,
    ::Union{PowerSimulations.BinaryInterpolationVariableType, PowerSimulations.InterpolationVariableType},
    devices,
    model::DeviceModel{U<:Component, V<:PowerSimulations.AbstractDeviceFormulation}
)
add_sparse_pwl_interpolation_variables!(
    container::PowerSimulations.OptimizationContainer,
    ::Union{PowerSimulations.BinaryInterpolationVariableType, PowerSimulations.InterpolationVariableType},
    devices,
    model::DeviceModel{U<:Component, V<:PowerSimulations.AbstractDeviceFormulation},
    num_segments
)

add_sparse_pwl_interpolation_variables!(container, devices, ::T, model, num_segments = DEFAULT_INTERPOLATION_LENGTH)

Add piecewise linear interpolation variables to an optimization container.

This function creates the necessary variables for piecewise linear (PWL) approximation in optimization models. It adds either continuous interpolation variables (δ) or binary interpolation variables (z) depending on the variable type T. These variables are used in the incremental method for PWL approximation where:

• Interpolation variables (δ): Continuous variables ∈ [0,1] that represent weights for each segment
• Binary interpolation variables (z): Binary variables that enforce ordering constraints in incremental method

The function creates a 3-dimensional variable structure indexed by (devicename, segmentindex, time_step). For binary variables, the number of variables is one less than for continuous variables since they control transitions between segments.

Arguments

• container::OptimizationContainer: The optimization container to add variables to
• devices: Collection of devices for which to create PWL variables
• ::T: Type parameter specifying the variable type (InterpolationVariableType or BinaryInterpolationVariableType)
• model::DeviceModel{U, V}: Device model containing formulation information for bounds
• num_segments::Int: Number of linear segments in the PWL approximation (default: DEFAULTINTERPOLATIONLENGTH)

Type Parameters

• T <: Union{InterpolationVariableType, BinaryInterpolationVariableType}: Variable type to create
• U <: PSY.Component: Component type for devices
• V <: AbstractDeviceFormulation: Device formulation type for bounds

Notes

• Binary variables have num_segments - 1 variables (control transitions between segments)
• Continuous variables have num_segments variables (one per segment)
• Variable bounds are set based on the device formulation if available
• Variables are created for all devices and time steps in the optimization horizon

See Also

• _add_generic_incremental_interpolation_constraint!: Function that uses these variables in constraints

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{S<:ConstituentCostExpression},
    cost_expression::Union{Float64, JuMP.AbstractJuMPScalar},
    component::Component,
    time_period::Int64
)

Specialized add_to_expression! for ConstituentCostExpression subtypes. In addition to adding to the constituent expression, this method automatically propagates the cost to ProductionCostExpression, so callers do not need to add to both.

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:PhaseShifterAngle},
    devices::InfrastructureSystems.FlattenIteratorWrapper{PhaseShiftingTransformer},
    _::DeviceModel{PhaseShiftingTransformer, V<:PhaseAngleControl},
    network_model::NetworkModel{<:PowerSimulations.AbstractPTDFModel}
)

Implementation of addtoexpression! for lossless branch/network models

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:ActivePowerTimeSeriesParameter},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:MotorLoad},
    model::DeviceModel{V<:MotorLoad, W<:StaticPowerLoad},
    network_model::NetworkModel{AreaBalancePowerModel}
)

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

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:ActivePowerTimeSeriesParameter},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:MotorLoad},
    device_model::DeviceModel{V<:MotorLoad, W<:StaticPowerLoad},
    network_model::NetworkModel{CopperPlatePowerModel}
)

Motor load implementation to add parameters to SystemBalanceExpressions CopperPlate

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:ACBranch},
    _::DeviceModel{V<:ACBranch, W<:PowerSimulations.AbstractBranchFormulation},
    network_model::NetworkModel{CopperPlatePowerModel}
)

Implementation of addtoexpression! for lossless branch/network models

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

Default implementation to add variables to SystemBalanceExpressions

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

Electric Load implementation to add parameters to Copperplate SystemBalanceExpressions

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

Default implementation to add parameters to Copperplate SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerToFromVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:TwoTerminalHVDC},
    _::DeviceModel{V<:TwoTerminalHVDC, W<:PowerSimulations.AbstractTwoTerminalDCLineFormulation},
    network_model::NetworkModel{PTDFPowerModel}
)

Default implementation to add branch variables to SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:ActivePowerTimeSeriesParameter},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:MotorLoad},
    model::DeviceModel{V<:MotorLoad, W<:StaticPowerLoad},
    network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
)

Motor load implementation to add constant power to ActivePowerBalance expression

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:ActivePowerTimeSeriesParameter},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:MotorLoad},
    device_model::DeviceModel{V<:MotorLoad, W<:StaticPowerLoad},
    network_model::NetworkModel{X<:PowerSimulations.AbstractPTDFModel}
)

Motor Load implementation to add constant motor power to PTDF SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerFromToVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:Branch},
    _::DeviceModel{V<:Branch, W<:PowerSimulations.AbstractDeviceFormulation},
    network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
)

Default implementation to add branch variables to SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerFromToVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:TwoTerminalHVDC},
    _::DeviceModel{V<:TwoTerminalHVDC, W<:PowerSimulations.AbstractTwoTerminalDCLineFormulation},
    network_model::NetworkModel{X<:CopperPlatePowerModel}
)

Default implementation to add branch variables to SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerFromToVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:TwoTerminalHVDC},
    _::DeviceModel{V<:TwoTerminalHVDC, W<:PowerSimulations.AbstractTwoTerminalDCLineFormulation},
    network_model::NetworkModel{X<:PowerSimulations.AbstractPTDFModel}
)

Default implementation to add branch variables to SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerToFromVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:ACBranch},
    _::DeviceModel{V<:ACBranch, W<:PowerSimulations.AbstractDeviceFormulation},
    network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
)

Default implementation to add branch variables to SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerToFromVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:TwoTerminalHVDC},
    _::DeviceModel{V<:TwoTerminalHVDC, W<:PowerSimulations.AbstractTwoTerminalDCLineFormulation},
    network_model::NetworkModel{X<:CopperPlatePowerModel}
)

Default implementation to add branch variables to SystemBalanceExpressions

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

Implementation of addtoexpression! for lossless branch/network models

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:FlowActivePowerVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:TwoTerminalHVDC},
    _::DeviceModel{V<:TwoTerminalHVDC, W<:PowerSimulations.AbstractBranchFormulation},
    network_model::NetworkModel{X<:PTDFPowerModel}
)

Implementation of addtoexpression! for lossless branch/network models

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:HVDCLosses},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:TwoTerminalHVDC},
    _::DeviceModel{V<:TwoTerminalHVDC, W<:HVDCTwoTerminalDispatch},
    network_model::NetworkModel{X<:Union{CopperPlatePowerModel, PTDFPowerModel}}
)

Default implementation to add branch variables to SystemBalanceExpressions

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

Default implementation to add variables to SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:PowerSimulations.HVDCActivePowerReceivedFromVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:TwoTerminalHVDC},
    _::DeviceModel{V<:TwoTerminalHVDC, W<:HVDCTwoTerminalLCC},
    network_model::NetworkModel{X<:ACPPowerModel}
)

HVDC LCC implementation to add ActivePowerBalance expression for HVDCActivePowerReceivedFromVariable variable

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:PowerSimulations.HVDCActivePowerReceivedFromVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:TwoTerminalHVDC},
    _::DeviceModel{V<:TwoTerminalHVDC, W<:PowerSimulations.HVDCTwoTerminalPiecewiseLoss},
    network_model::NetworkModel{X<:PowerSimulations.AbstractPTDFModel}
)

PWL implementation to add FromTo branch variables to SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:PowerSimulations.HVDCActivePowerReceivedToVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:TwoTerminalHVDC},
    _::DeviceModel{V<:TwoTerminalHVDC, W<:HVDCTwoTerminalLCC},
    network_model::NetworkModel{X<:ACPPowerModel}
)

HVDC LCC implementation to add ActivePowerBalance expression for HVDCActivePowerReceivedToVariable variable

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:PowerSimulations.HVDCActivePowerReceivedToVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:TwoTerminalHVDC},
    _::DeviceModel{V<:TwoTerminalHVDC, W<:PowerSimulations.HVDCTwoTerminalPiecewiseLoss},
    network_model::NetworkModel{X<:PowerSimulations.AbstractPTDFModel}
)

PWL implementation to add FromTo branch variables to SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ActivePowerBalance},
    _::Type{U<:PowerSimulations.RealizedShiftedLoad},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:ShiftablePowerLoad},
    device_model::DeviceModel{V<:ShiftablePowerLoad, W<:PowerLoadShift},
    network_model::NetworkModel{X<:PowerSimulations.AbstractPTDFModel}
)

Electric Load implementation to add parameters to PTDF ActivePowerBalance expressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ReactivePowerBalance},
    _::Type{U<:PowerSimulations.HVDCReactivePowerReceivedFromVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:TwoTerminalHVDC},
    _::DeviceModel{V<:TwoTerminalHVDC, W<:HVDCTwoTerminalLCC},
    network_model::NetworkModel{X<:ACPPowerModel}
)

HVDC LCC implementation to add ReactivePowerBalance expression for HVDCReactivePowerReceivedFromVariable variable

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ReactivePowerBalance},
    _::Type{U<:PowerSimulations.HVDCReactivePowerReceivedToVariable},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:TwoTerminalHVDC},
    _::DeviceModel{V<:TwoTerminalHVDC, W<:HVDCTwoTerminalLCC},
    network_model::NetworkModel{X<:ACPPowerModel}
)

HVDC LCC implementation to add ReactivePowerBalance expression for HVDCReactivePowerReceivedToVariable variable

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:ReactivePowerBalance},
    _::Type{U<:ReactivePowerTimeSeriesParameter},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:MotorLoad},
    model::DeviceModel{V<:MotorLoad, W<:StaticPowerLoad},
    network_model::NetworkModel{X<:ACPPowerModel}
)

Motor load implementation to add constant power to ActivePowerBalance expression

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:SystemBalanceExpressions},
    _::Type{U<:InfrastructureSystems.Optimization.TimeSeriesParameter},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:Device},
    model::DeviceModel{V<:Device, W<:PowerSimulations.AbstractDeviceFormulation},
    network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
)

Default implementation to add parameters to SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:SystemBalanceExpressions},
    _::Type{U<:InfrastructureSystems.Optimization.TimeSeriesParameter},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:ElectricLoad},
    model::DeviceModel{V<:ElectricLoad, W<:PowerSimulations.AbstractLoadFormulation},
    network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
)

Generic electric load implementation to add parameters to SystemBalanceExpressions

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

Electric Load implementation to add parameters to PTDF SystemBalanceExpressions

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

Default implementation to add parameters to PTDF SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:SystemBalanceExpressions},
    _::Type{U<:InfrastructureSystems.Optimization.VariableType},
    devices::InfrastructureSystems.FlattenIteratorWrapper{V<:StaticInjection},
    _::DeviceModel{V<:StaticInjection, W<:PowerSimulations.AbstractDeviceFormulation},
    network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
)

Default implementation to add device variables to SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:SystemBalanceExpressions},
    _::Type{U<:PowerSimulations.EventParameter},
    devices::Union{Array{V<:Device, 1}, InfrastructureSystems.FlattenIteratorWrapper{V<:Device}},
    model::DeviceModel{V<:Device, W<:PowerSimulations.AbstractDeviceFormulation},
    network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
)

Default implementation to add parameters to SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:SystemBalanceExpressions},
    _::Type{U<:PowerSimulations.EventParameter},
    devices::Union{Array{V<:StaticInjection, 1}, InfrastructureSystems.FlattenIteratorWrapper{V<:StaticInjection}},
    device_model::DeviceModel{V<:StaticInjection, W<:PowerSimulations.AbstractDeviceFormulation},
    network_model::NetworkModel{X<:CopperPlatePowerModel}
)

Default implementation to add parameters to SystemBalanceExpressions

add_to_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:SystemBalanceExpressions},
    _::Type{U<:PowerSimulations.EventParameter},
    devices::Union{Array{V<:StaticInjection, 1}, InfrastructureSystems.FlattenIteratorWrapper{V<:StaticInjection}},
    device_model::DeviceModel{V<:StaticInjection, W<:PowerSimulations.AbstractDeviceFormulation},
    network_model::NetworkModel{X<:PowerSimulations.AbstractPTDFModel}
)

Default implementation to add parameters to SystemBalanceExpressions

add_variable!(
    container::PowerSimulations.OptimizationContainer,
    variable_type::ServiceRequirementVariable,
    service::ReserveDemandCurve,
    formulation
)

Add variables for ServiceRequirementVariable for StepWiseCostReserve

add_variable!(
    container::PowerSimulations.OptimizationContainer,
    var_type::InfrastructureSystems.Optimization.AuxVariableType,
    devices::Union{Array{D<:Component, 1}, InfrastructureSystems.FlattenIteratorWrapper{D<:Component}},
    formulation
)

Default implementation of adding auxiliary variable to the model.

add_variable!(
    container::PowerSimulations.OptimizationContainer,
    variable_type::InfrastructureSystems.Optimization.VariableType,
    devices::Union{Array{D<:Component, 1}, InfrastructureSystems.FlattenIteratorWrapper{D<:Component}},
    formulation
)

Adds a variable to the optimization model and to the affine expressions contained in the optimization_container model according to the specified sign. Based on the inputs, the variable can be specified as binary.

Bounds

lb_value_function <= varstart[name, t] <= ub_value_function

If binary = true:

varstart[name, t] in {0,1}

LaTeX

$lb \ge x^{device}_t \le ub \forall t$

$x^{device}_t \in {0,1} \forall t iff \text{binary = true}$

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• devices : Vector or Iterator with the devices
• var_key::VariableKey : Base Name for the variable
• binary::Bool : Select if the variable is binary
• expressionname::Symbol : Expressionname name stored in container.expressions to add the variable
• sign::Float64 : sign of the addition of the variable to the expression_name. Default Value is 1.0

Accepted Keyword Arguments

• ubvalue : Provides the function over device to obtain the value for a upperbound
• lbvalue : Provides the function over device to obtain the value for a lowerbound. If the variable is meant to be positive define lb = x -> 0.0
• initial_value : Provides the function over device to obtain the warm start value

add_variable!(
    container::PowerSimulations.OptimizationContainer,
    variable_type::Union{OnVariable, StartVariable, StopVariable},
    devices::Union{Array{D<:ThermalGen, 1}, InfrastructureSystems.FlattenIteratorWrapper{D<:ThermalGen}},
    formulation::PowerSimulations.AbstractThermalFormulation
)

Adds a variable to the optimization model for the OnVariable of Thermal Units

add_variables!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.AuxVariableType},
    devices::Union{Array{U<:Component, 1}, InfrastructureSystems.FlattenIteratorWrapper{U<:Component}},
    formulation::Union{PowerSimulations.AbstractDeviceFormulation, PowerSimulations.AbstractServiceFormulation}
)

Add variables to the OptimizationContainer for any component.

add_variables!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.VariableType},
    devices::Union{Array{U<:Component, 1}, InfrastructureSystems.FlattenIteratorWrapper{U<:Component}},
    formulation::Union{PowerSimulations.AbstractDeviceFormulation, PowerSimulations.AbstractServiceFormulation}
)

Add variables to the OptimizationContainer for any component.

add_variables!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{T<:InfrastructureSystems.Optimization.VariableType},
    service::AbstractReserve,
    contributing_devices::Union{Array{V<:Component, 1}, InfrastructureSystems.FlattenIteratorWrapper{V<:Component}},
    formulation::PowerSimulations.AbstractReservesFormulation
)

Add variables to the OptimizationContainer for a service.

apply_maybe_across_time_series(
    fn::Function,
    component::Component,
    ts_key::TimeSeriesKey
) -> Any

Helper function to look up a time series if necessary then apply a function (typically a validation routine in a do block) to every element in it

auto_transform_time_series!(
    sys::System,
    settings::PowerSimulations.Settings
)

Automatically transform SingleTimeSeries into DeterministicSingleTimeSeries for a given (horizon, interval) when a DecisionModel is built with these settings and the system contains only static time series. Uses delete_existing=false so multiple models may share the same system with different transforms.

Does nothing when:

• The model's horizon or interval are unset.
• The system has no SingleTimeSeries to transform.
• The system has existing forecast data AND the requested interval is already present in those forecasts.

branch_rating(
    double_circuit::PowerNetworkMatrices.AbstractBranchesParallel,
    model::DeviceModel
) -> Any

Scalar branch rating for a reduction entry — the single source of truth for branch flow ratings. Parallel groups use the PARALLEL_BRANCH_MAX_RATING_KEY attribute; every other entry uses PNM.get_equivalent_rating. Extend that (not this) for new types. See the "Branch Rating Limits" explanation page.

build_model!(
    model::DecisionModel{<:PowerSimulations.DefaultDecisionProblem}
)

Default implementation of build method for Operational Problems for models conforming with DecisionProblem specification. Overload this function to implement a custom build method

build_model!(model::EmulationModel)

Default implementation of build method for Emulation Problems for models conforming with DecisionProblem specification. Overload this function to implement a custom build method

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

This function checks if the variables for reserves were created

check_file_integrity(path::String)

check_file_integrity(path::String)

Checks the hash value for each file made with the file is written with the new hash_value to verify the file hasn't been tampered with since written

Arguments

• path::String: this is the folder path that contains the results and the check.sha256 file

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

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

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

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

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

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

construct_device!(
    container::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::DeviceModel{T<: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::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:ThermalGen, D<:PowerSimulations.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::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    model::DeviceModel{T<:Source, D<:FixedOutput},
    network_model::NetworkModel{<:PowerModels.AbstractActivePowerModel}
)

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

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

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

construct_device!(
    container::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    model::DeviceModel{T<: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::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:ThermalGen, ThermalBasicUnitCommitment},
    network_model::NetworkModel{<:PowerModels.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::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<: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::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<:ThermalGen, ThermalStandardDispatch},
    network_model::NetworkModel{<:PowerModels.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::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    device_model::DeviceModel{T<: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::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:ThermalGen, <:PowerSimulations.AbstractStandardUnitCommitment},
    network_model::NetworkModel{<:PowerModels.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::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:ThermalGen, ThermalBasicUnitCommitment},
    network_model::NetworkModel{<:PowerModels.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::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<: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::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:ThermalGen, ThermalStandardDispatch},
    network_model::NetworkModel{<:PowerModels.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::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<: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::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ModelConstructStage,
    device_model::DeviceModel{T<:ThermalGen, U<:PowerSimulations.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::PowerSimulations.OptimizationContainer,
    sys::System,
    _::InfrastructureSystems.Optimization.ArgumentConstructStage,
    model::ServiceModel{SR<:ConstantReserveGroup, GroupReserve},
    _::Dict{Symbol, DeviceModel},
    _::Set{<:DataType},
    _::NetworkModel
)

Constructs a service for ConstantReserveGroup.

container_spec(
    _::Type{Float64},
    axs...
) -> JuMP.Containers.DenseAxisArray

Returns the correct container specification for the selected type of JuMP Model

container_spec(
    _::Type{T},
    axs...
) -> JuMP.Containers.DenseAxisArray

Returns the correct container specification for the selected type of JuMP Model

device_duration_compact_retrospective!(
    container::PowerSimulations.OptimizationContainer,
    duration_data::Vector{@NamedTuple{up::Float64, down::Float64}},
    initial_duration::Matrix{InitialCondition},
    cons_type::InfrastructureSystems.Optimization.ConstraintType,
    var_types::Tuple{InfrastructureSystems.Optimization.VariableType, InfrastructureSystems.Optimization.VariableType, InfrastructureSystems.Optimization.VariableType},
    _::Type{T<:Component}
)

This formulation of the duration constraints adds over the start times looking backwards.

LaTeX

• Minimum up-time constraint:

$\sum_{i=t-min(d_{min}^{up}, T)+ 1}^t x_i^{start} - x_t^{on} \leq 0$

for i in the set of time steps.

• Minimum down-time constraint:

$\sum_{i=t-min(d_{min}^{down}, T) + 1}^t x_i^{stop} + x_t^{on} \leq 1$

for i in the set of time steps.

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• duration_data::Vector{UpDown} : gives how many time steps variable needs to be up or down
• initial_duration::Matrix{InitialCondition} : gives initial conditions for up (column 1) and down (column 2)
• cons_name::Symbol : name of the constraint
• var_keys::Tuple{VariableKey, VariableKey, VariableKey}) : names of the variables
• : var_keys[1] : varon
• : var_keys[2] : varstart
• : var_keys[3] : varstop

device_duration_look_ahead!(
    container::PowerSimulations.OptimizationContainer,
    duration_data::Vector{@NamedTuple{up::Float64, down::Float64}},
    initial_duration::Matrix{InitialCondition},
    cons_type_up::InfrastructureSystems.Optimization.ConstraintType,
    cons_type_down::InfrastructureSystems.Optimization.ConstraintType,
    var_types::Tuple{InfrastructureSystems.Optimization.VariableType, InfrastructureSystems.Optimization.VariableType, InfrastructureSystems.Optimization.VariableType},
    _::Type{T<:Component}
)

This formulation of the duration constraints looks ahead in the time frame of the model.

LaTeX

• Minimum up-time constraint:

If $t \leq d_{min}^{up}$

$d_{min}^{down}x_t^{stop} - \sum_{i=t-d_{min}^{up} + 1}^t x_i^{on} - x_{init}^{up} \leq 0$

for i in the set of time steps. Otherwise:

$d_{min}^{down}x_t^{stop} - \sum_{i=t-d_{min}^{up} + 1}^t x_i^{on} \leq 0$

for i in the set of time steps.

• Minimum down-time constraint:

If $t \leq d_{min}^{down}$

$d_{min}^{up}x_t^{start} - \sum_{i=t-d_{min^{down} + 1}^t (1 - x_i^{on}) - x_{init}^{down} \leq 0$

for i in the set of time steps. Otherwise:

$d_{min}^{up}x_t^{start} - \sum_{i=t-d_{min^{down} + 1}^t (1 - x_i^{on}) \leq 0$

for i in the set of time steps.

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• duration_data::Vector{UpDown} : gives how many time steps variable needs to be up or down
• initial_duration::Matrix{InitialCondition} : gives initial conditions for up (column 1) and down (column 2)
• cons_name::Symbol : name of the constraint
• var_keys::Tuple{VariableKey, VariableKey, VariableKey}) : names of the variables
• : var_keys[1] : varon
• : var_keys[2] : varstart
• : var_keys[3] : varstop

device_duration_parameters!(
    container::PowerSimulations.OptimizationContainer,
    duration_data::Vector{@NamedTuple{up::Float64, down::Float64}},
    initial_duration::Matrix{InitialCondition},
    cons_type::InfrastructureSystems.Optimization.ConstraintType,
    var_types::Tuple{InfrastructureSystems.Optimization.VariableType, InfrastructureSystems.Optimization.VariableType, InfrastructureSystems.Optimization.VariableType},
    _::Type{T<:Component}
)

This formulation of the duration constraints considers parameters.

LaTeX

• Minimum up-time constraint:

If $t \leq d_{min}^{up}$

$d_{min}^{down}x_t^{stop} - \sum_{i=t-d_{min}^{up} + 1}^t x_i^{on} - x_{init}^{up} \leq 0$

for i in the set of time steps. Otherwise:

$\sum_{i=t-d_{min}^{up} + 1}^t x_i^{start} - x_t^{on} \leq 0$

for i in the set of time steps.

• Minimum down-time constraint:

If $t \leq d_{min}^{down}$

$d_{min}^{up}x_t^{start} - \sum_{i=t-d_{min^{down} + 1}^t (1 - x_i^{on}) - x_{init}^{down} \leq 0$

for i in the set of time steps. Otherwise:

$\sum_{i=t-d_{min}^{down} + 1}^t x_i^{stop} + x_t^{on} \leq 1$

for i in the set of time steps.

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• duration_data::Vector{UpDown} : gives how many time steps variable needs to be up or down
• initialdurationon::Vector{InitialCondition} : gives initial number of time steps variable is up
• initialdurationoff::Vector{InitialCondition} : gives initial number of time steps variable is down
• cons_name::Symbol : name of the constraint
• var_keys::Tuple{VariableKey, VariableKey, VariableKey}) : names of the variables
• : var_keys[1] : varon
• : var_keys[2] : varstart
• : var_keys[3] : varstop

device_duration_retrospective!(
    container::PowerSimulations.OptimizationContainer,
    duration_data::Vector{@NamedTuple{up::Float64, down::Float64}},
    initial_duration::Matrix{InitialCondition},
    cons_type::InfrastructureSystems.Optimization.ConstraintType,
    var_types::Tuple{InfrastructureSystems.Optimization.VariableType, InfrastructureSystems.Optimization.VariableType, InfrastructureSystems.Optimization.VariableType},
    _::Type{T<:Component}
)

This formulation of the duration constraints adds over the start times looking backwards.

LaTeX

• Minimum up-time constraint:

If $t \leq d_{min}^{up} - d_{init}^{up}$ and $d_{init}^{up} > 0$

$1 + \sum_{i=t-d_{min}^{up} + 1}^t x_i^{start} - x_t^{on} \leq 0$

for i in the set of time steps. Otherwise:

$\sum_{i=t-d_{min}^{up} + 1}^t x_i^{start} - x_t^{on} \leq 0$

for i in the set of time steps.

• Minimum down-time constraint:

If $t \leq d_{min}^{down} - d_{init}^{down}$ and $d_{init}^{down} > 0$

$1 + \sum_{i=t-d_{min}^{down} + 1}^t x_i^{stop} + x_t^{on} \leq 1$

for i in the set of time steps. Otherwise:

$\sum_{i=t-d_{min}^{down} + 1}^t x_i^{stop} + x_t^{on} \leq 1$

for i in the set of time steps.

Arguments

• container::OptimizationContainer : the optimization_container model built in PowerSimulations
• duration_data::Vector{UpDown} : gives how many time steps variable needs to be up or down
• initial_duration::Matrix{InitialCondition} : gives initial conditions for up (column 1) and down (column 2)
• cons_name::Symbol : name of the constraint
• var_keys::Tuple{VariableKey, VariableKey, VariableKey}) : names of the variables
• : var_keys[1] : varon
• : var_keys[2] : varstart
• : var_keys[3] : varstop

find_key_with_value(d, value) -> Any

Return the key for the given value

find_timestamp_index(
    dates::Union{StepRange{Dates.DateTime, Dates.Millisecond}, Vector{Dates.DateTime}},
    date::Dates.DateTime
) -> Int64

calculates the index in the time series corresponding to the data. Assumes that the dates vector is sorted.

generate_formulation_combinations(

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

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

Arguments

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

get_absolute_step_range(
    partitions::SimulationPartitions,
    index::Int64
) -> UnitRange{Int64}

Return a UnitRange for the steps in the partition with the given index. Includes overlap.

get_column_names(
    _::PowerSimulations.OptimizationContainer,
    field::Symbol,
    subcontainer,
    key::InfrastructureSystems.Optimization.OptimizationContainerKey
) -> Any

Get the column names for the specified container in the OptimizationContainer.

Arguments

• container::OptimizationContainer: The optimization container.
• field::Symbol: The field for which to retrieve the column names.
• key::OptimizationContainerKey: The key for which to retrieve the column names.

Returns

• Tuple: Tuple of Vector{String}.

get_column_names_from_key(
    key::InfrastructureSystems.Optimization.OptimizationContainerKey
) -> Tuple{Vector}

Return the column names from a key as a tuple of vector of strings. Only useful for 1d DenseAxisArrays.

get_dirty_data_to_flush!(
    cache::PowerSimulations.OptimizationOutputCache
) -> Tuple{Vector{Dates.DateTime}, Any}

Return all dirty data from the cache. Mark the timestamps as clean.

get_emergency_min_max_limits(
    device::ACTransmission,
    _::Type{<:PowerSimulations.PostContingencyConstraintType},
    _::Type{<:PowerSimulations.AbstractBranchFormulation}
) -> NamedTuple{(:min, :max), <:Tuple{Any, Any}}

Min and max limits for Abstract Branch Formulation and Post-Contingency conditions

get_emergency_min_max_limits(
    entry::PhaseShiftingTransformer,
    _::Type{PhaseAngleControlLimit},
    _::Type{PhaseAngleControl}
) -> @NamedTuple{min::Float64, max::Float64}

Min and max limits for Abstract Branch Formulation and Post-Contingency conditions

get_emergency_min_max_limits(
    double_circuit::PowerNetworkMatrices.AbstractBranchesParallel,
    constraint_type::Type{<:PowerSimulations.PostContingencyConstraintType},
    branch_formulation::Type{<:PowerSimulations.AbstractBranchFormulation}
) -> NamedTuple{(:min, :max), <:Tuple{Any, Any}}

Emergency Min and max limits for Abstract Branch Formulation and Post-Contingency conditions. Covers both PNM.BranchesParallel (homogeneous) and PNM.MixedBranchesParallel groups; PNM's get_equivalent_emergency_rating aggregates the per-circuit emergency ratings as a sum-of-max, matching the max-flow capacity of the group.

get_emergency_min_max_limits(
    series_chain::PowerNetworkMatrices.BranchesSeries,
    constraint_type::Type{<:PowerSimulations.PostContingencyConstraintType},
    branch_formulation::Type{<:PowerSimulations.AbstractBranchFormulation}
) -> NamedTuple{(:min, :max), <:Tuple{Any, Any}}

Min and max limits for Abstract Branch Formulation and Post-Contingency conditions

get_emergency_min_max_limits(
    transformer_entry::PowerNetworkMatrices.ThreeWindingTransformerWinding,
    constraint_type::Type{<:PowerSimulations.PostContingencyConstraintType},
    branch_formulation::Type{<:PowerSimulations.AbstractBranchFormulation}
) -> NamedTuple{(:min, :max), <:Tuple{Float64, Union{Nothing, Float64}}}

Min and max limits for Abstract Branch Formulation and Post-Contingency conditions

get_enum_value(enum, value::String) -> Any

Get the enum value for the string. Case insensitive.

get_forecast_intervals(sys::System) -> Set

Return the set of distinct forecast intervals present in the system.

get_last_updated_timestamp(
    container::PowerSimulations.DatasetContainer,
    key::InfrastructureSystems.Optimization.OptimizationContainerKey
) -> Dates.DateTime

Return the timestamp from most recent data row updated in the dataset. This value may not be the same as the result from get_update_timestamp

get_last_updated_timestamp(
    s::PowerSimulations.HDF5Dataset
) -> Dates.DateTime

Return the timestamp from most recent data row updated in the dataset. This value may not be the same as the result from get_update_timestamp

get_last_updated_timestamp(
    s::PowerSimulations.InMemoryDataset
) -> Dates.DateTime

Return the timestamp from most recent data row updated in the dataset. This value may not be the same as the result from get_update_timestamp

get_min_max_limits(
    device,
    _::Type{ActivePowerVariableLimitsConstraint},
    _::Type{<:PowerSimulations.AbstractCompactUnitCommitment}
) -> NamedTuple{(:min, :max), <:Tuple{Float64, Any}}

Min and Max active power limits for Compact Unit Commitment

get_min_max_limits(
    device,
    _::Type{ActivePowerVariableLimitsConstraint},
    _::Type{<:PowerSimulations.AbstractThermalDispatchFormulation}
) -> NamedTuple{(:min, :max), <:Tuple{Float64, Any}}

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

get_min_max_limits(
    device,
    _::Type{ActivePowerVariableLimitsConstraint},
    _::Type{<:PowerSimulations.AbstractThermalUnitCommitment}
) -> NamedTuple{(:min, :max), <:Tuple{Float64, Any}}

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

get_min_max_limits(
    device,
    _::Type{ActivePowerVariableLimitsConstraint},
    _::Type{ThermalCompactDispatch}
) -> NamedTuple{(:min, :max), <:Tuple{Float64, Any}}

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

get_min_max_limits(
    device,
    _::Type{ActivePowerVariableLimitsConstraint},
    _::Type{ThermalDispatchNoMin}
) -> NamedTuple{(:min, :max), <:Tuple{Float64, Any}}

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

get_min_max_limits(
    device,
    _::Type{ActivePowerVariableLimitsConstraint},
    _::Type{ThermalMultiStartUnitCommitment}
) -> NamedTuple{(:min, :max), <:Tuple{Float64, Any}}

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

get_min_max_limits(
    device,
    _::Type{ReactivePowerVariableLimitsConstraint},
    _::Type{<:PowerSimulations.AbstractThermalDispatchFormulation}
) -> Any

Reactive power limits of generators for all dispatch formulations

get_min_max_limits(
    device,
    _::Type{ReactivePowerVariableLimitsConstraint},
    _::Type{<:PowerSimulations.AbstractThermalUnitCommitment}
) -> Any

Reactive power limits of generators when there CommitmentVariables

get_min_max_limits(
    device::MonitoredLine,
    _::Type{<:InfrastructureSystems.Optimization.ConstraintType},
    _::Type{<:PowerSimulations.AbstractBranchFormulation}
) -> @NamedTuple{min::Float64, max::Float64}

Min and max limits for monitored line

get_min_max_limits(
    device::MonitoredLine,
    _::Type{FlowLimitFromToConstraint},
    _::Type{<:PowerSimulations.AbstractBranchFormulation}
) -> @NamedTuple{min::Float64, max::Float64}

Min and max limits for flow limit from-to constraint

get_min_max_limits(
    device::MonitoredLine,
    _::Type{FlowLimitToFromConstraint},
    _::Type{<:PowerSimulations.AbstractBranchFormulation}
) -> @NamedTuple{min::Float64, max::Float64}

Min and max limits for flow limit to-from constraint

get_min_max_limits(
    _::PhaseShiftingTransformer,
    _::Type{PhaseAngleControlLimit},
    _::Type{PhaseAngleControl}
) -> @NamedTuple{min::Float64, max::Float64}

Min and max limits for Abstract Branch Formulation

get_piecewise_curve_per_system_unit(
    cost_component::PiecewiseStepData,
    unit_system::UnitSystem,
    system_base_power::Float64,
    device_base_power::Float64
) -> PiecewiseStepData

Obtain the normalized PiecewiseStepData in system base per unit depending on the specified power units.

Note that the costs (y-axis) are in /MWh, /(sys pu h) or /(device pu h), so they also require transformation.

get_piecewise_pointcurve_per_system_unit(
    cost_component::PiecewiseLinearData,
    unit_system::UnitSystem,
    system_base_power::Float64,
    device_base_power::Float64
) -> PiecewiseLinearData

Obtain the normalized PiecewiseLinear cost data in system base per unit depending on the specified power units.

Note that the costs (y-axis) are always in /h so they do not require transformation

get_proportional_cost_per_system_unit(
    cost_term::Float64,
    unit_system::UnitSystem,
    system_base_power::Float64,
    device_base_power::Float64
) -> Float64

Obtain proportional (marginal or slope) cost data in system base per unit depending on the specified power units

get_ptdf_orientation_sign(
    net_reduction_data::PowerNetworkMatrices.NetworkReductionData,
    _::Type{T<:ACTransmission},
    name::AbstractString
) -> Float64

Sign relating a branch's native from→to flow to the PTDF column used for its PTDFBranchFlow. Returns -1.0 only for a series-reduction member whose native orientation is :ToFrom relative to the merged path; +1.0 otherwise. Errors on an unknown reduction kind rather than returning a silently wrong sign.

get_quadratic_cost_per_system_unit(
    cost_term::Float64,
    unit_system::UnitSystem,
    system_base_power::Float64,
    device_base_power::Float64
) -> Float64

Obtain quadratic cost data in system base per unit depending on the specified power units

get_single_time_series_consistency(
    sys::System,
    resolution::Dates.Period
) -> Tuple{Any, Any}

Return (initial_timestamp, length) for the SingleTimeSeries in sys whose resolution matches resolution. Throws IS.InvalidValue when no match exists or when matching series disagree on either field. Used to validate emulation model inputs when a system carries SingleTimeSeries at multiple resolutions.

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

Startup shutdown limits for Compact Unit Commitment

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

Startup and shutdown active power limits for Compact Unit Commitment

get_update_timestamp(
    s::PowerSimulations.AbstractDataset
) -> Any

Return the timestamp from the data used in the last update

get_update_timestamp(
    container::PowerSimulations.DatasetContainer,
    key::InfrastructureSystems.Optimization.OptimizationContainerKey
) -> Any

Return the timestamp from the data used in the last update

get_valid_step_length(
    partitions::SimulationPartitions,
    index::Int64
) -> Int64

Return the length of valid data at the given index.

get_valid_step_offset(
    partitions::SimulationPartitions,
    index::Int64
) -> Int64

Return the step offset for valid data at the given index.

has_dirty(
    cache::PowerSimulations.OptimizationOutputCaches
) -> Bool

Return true if the cache has data that has not been flushed to storage.

is_cached(
    cache::PowerSimulations.OptimizationOutputCaches,
    model_name,
    key,
    index
) -> Bool

Return true if the data for timestamp is stored in cache.

is_from_power_flow(
    _::Type{<:InfrastructureSystems.Optimization.AuxVariableType}
) -> Bool

Whether the auxiliary variable is calculated using a PowerFlowEvaluationModel

join_simulation(path::AbstractString)

Combine all partition simulation files.

latest_solved_power_flow_evaluation_data(
    container::PowerSimulations.OptimizationContainer
) -> PowerSimulations.PowerFlowEvaluationData

Fetch the most recently solved PowerFlowEvaluationData

list_decision_model_keys(
    store::PowerSimulations.HdfSimulationStore,
    model::Symbol,
    container_type::Symbol
) -> Vector

Return the fields stored for the problem and container_type (duals/parameters/variables).

list_decision_models(
    store::PowerSimulations.HdfSimulationStore
) -> Base.KeySet{Symbol, OrderedDict{Symbol, PowerSimulations.DatasetContainer{PowerSimulations.HDF5Dataset}}}

Return the problem names in order of execution.

log_cache_hit_percentages(
    cache::PowerSimulations.OptimizationOutputCaches
)

Log the cache hit percentages for all caches.

lookup_additional_axes(parameter_array) -> Any

Given a parameter array, get any additional axes, i.e., those that aren't the first (component) or the last (time)

min_max_flow_limits(
    entry,
    model::DeviceModel
) -> @NamedTuple{min::Float64, max::Float64}

Symmetric (min, max) flow limits from branch_rating. Prefer this over the formulation-only get_min_max_limits when the DeviceModel is in scope.

onvar_cost(
    container::PowerSimulations.OptimizationContainer,
    cost::ThermalGenerationCost,
    _::OnVariable,
    d::ThermalGen,
    _::PowerSimulations.AbstractThermalFormulation,
    t::Int64
) -> Any

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

open_store(
    ::Type{PowerSimulations.HdfSimulationStore},
    directory::AbstractString;
    ...
) -> PowerSimulations.HdfSimulationStore
open_store(
    ::Type{PowerSimulations.HdfSimulationStore},
    directory::AbstractString,
    mode;
    filename
) -> PowerSimulations.HdfSimulationStore

Construct and open an HdfSimulationStore.

When reading or writing results in a program you should use the method that accepts a function in order to guarantee that the file handle gets closed.

Arguments

• directory::AbstractString: Directory containing the store file
• mode::AbstractString: Mode to use to open the store file
• filename::AbstractString: Base name of the store file

Examples

# Assumes a simulation has been executed in the './rts' directory with these parameters.
path = "./rts"
problem = :ED
var_name = :P__ThermalStandard
timestamp = DateTime("2020-01-01T05:00:00")
store = open_store(HdfSimulationStore, path)
df = PowerSimulations.read_result(DataFrame, store, model, :variables, var_name, timestamp)

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

Validate MarketBidCosts and add the appropriate parameters

read_dataframe(filename::AbstractString) -> DataFrame

Return a DataFrame from a CSV file.

read_json(
    filename::AbstractString
) -> Union{Nothing, Bool, Float64, Int64, String, JSON3.Array, JSON3.Object}

Return a decoded JSON file.

read_result(
    cache::PowerSimulations.OptimizationOutputCaches,
    model_name,
    key,
    timestamp
) -> Array

Read the result from cache. Callers must first call is_cached to check if the timestamp is present.

read_result(
    _::Type{DataFrame},
    store::PowerSimulations.HdfSimulationStore,
    model_name::Symbol,
    key::InfrastructureSystems.Optimization.OptimizationContainerKey,
    index::Union{Int64, Dates.DateTime}
) -> DataFrame

Return DataFrame, DenseAxisArray, or Array for a model result at a timestamp.

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

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

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

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

serialize_formulation_combinations(

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

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

Arguments

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

serialize_jump_optimization_model(
    jump_model::JuMP.Model,
    save_path::String
)

Exports the JuMP object in MathOptFormat

set_expression!(
    container::PowerSimulations.OptimizationContainer,
    _::Type{S<:CostExpressions},
    cost_expression::JuMP.AbstractJuMPScalar,
    component::Component,
    time_period::Int64
)

Replaces an expression value in the expression container if the key exists

set_ic_quantity!(
    ic::InitialCondition{T<:InfrastructureSystems.Optimization.InitialConditionType, Float64},
    var_value::Float64
)

Default implementation of setinitialcondition_value

set_ic_quantity!(
    ic::InitialCondition{T<:InfrastructureSystems.Optimization.InitialConditionType, JuMP.VariableRef},
    var_value::Float64
)

Default implementation of setinitialcondition_value

solve_impl!(
    container::PowerSimulations.OptimizationContainer,
    system::System
) -> Any

Default solve method for OptimizationContainer

sparse_container_spec(
    _::Type{T<:JuMP.AbstractJuMPScalar},
    axs...
) -> JuMP.Containers.SparseAxisArray

Returns the correct container specification for the selected type of JuMP Model

to_dataframe(
    array::JuMP.Containers.DenseAxisArray{T<:Union{Number, Tuple{Vararg{Number}}, Vector{<:Tuple{Number, Number}}}, 2, Ax, L} where {Ax, L<:Tuple{JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup}},
    key::InfrastructureSystems.Optimization.OptimizationContainerKey
) -> DataFrame

Create a DataFrame from a JuMP DenseAxisArray or SparseAxisArray.

Arguments

• array: JuMP DenseAxisArray or SparseAxisArray to convert
• key::OptimizationContainerKey:

to_results_dataframe(
    array::JuMP.Containers.DenseAxisArray,
    timestamps
) -> Any

Convert a DenseAxisArray containing components to a results DataFrame consumable by users.

Arguments

• array: DenseAxisArray: JuMP DenseAxisArray to convert
• timestamps: Iterable of timestamps for each component or nothing if time is not known. The resulting DataFrame will have the column "DateTime" if timestamps is not nothing. Otherwise, it will have the column "time_index", representing the index of the time dimension.
• ::Val{TableFormat}: Format of the table to create. If it is TableFormat.LONG, the DataFrame will have the column "name", and, if the data has three dimensions, "name2." If it is TableFormat.WIDE, the DataFrame will have columns for each component. Wide format does not support arrays with more than two dimensions.

update_container_parameter_values!(
    optimization_container::PowerSimulations.OptimizationContainer,
    model::PowerSimulations.OperationModel,
    key::InfrastructureSystems.Optimization.ParameterKey{T<:InfrastructureSystems.Optimization.ParameterType, U<:Component},
    input::PowerSimulations.DatasetContainer{PowerSimulations.InMemoryDataset}
)

Update parameter function an OperationModel

update_model!(
    model::PowerSimulations.OperationModel,
    sim::Simulation
)

Default problem update function for most problems with no customization

update_parameter_values!(
    model::EmulationModel,
    key::InfrastructureSystems.Optimization.ParameterKey{T<:InfrastructureSystems.Optimization.ParameterType, U<:Component},
    input::PowerSimulations.DatasetContainer{PowerSimulations.InMemoryDataset}
)

Update parameter function an OperationModel

update_parameter_values!(
    model::PowerSimulations.OperationModel,
    key::InfrastructureSystems.Optimization.ParameterKey{T<:InfrastructureSystems.Optimization.ParameterType, U<:Component},
    simulation_state::PowerSimulations.SimulationState
)

Update parameter function an OperationModel

update_pf_data!(
    pf_e_data::PowerSimulations.PowerFlowEvaluationData{PowerFlows.PSSEExporter},
    container::PowerSimulations.OptimizationContainer,
    time_step::Int64
)

Update a PowerFlowEvaluationData containing a PowerFlowContainer that does not supports_multi_period using a single time_step of the OptimizationContainer. To properly keep track of outer step number, time steps must be passed in sequentially, starting with 1.

variable_reactive_net_injection(
    pm::PowerModels.AbstractActivePowerModel;
    kwargs...
)

active power only models ignore reactive power variables

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

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

Arguments

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

write_result!(
    store::PowerSimulations.HdfSimulationStore,
    model_name::Symbol,
    key::InfrastructureSystems.Optimization.OptimizationContainerKey,
    index::Dates.DateTime,
    _::Dates.DateTime,
    data::JuMP.Containers.DenseAxisArray{Float64, 3, var"#s252", L} where {var"#s252"<:Tuple{Any, Any, Any}, L<:Tuple{JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup}}
)

Write a decision model result for a timestamp to the store.

write_result!(
    store::PowerSimulations.HdfSimulationStore,
    model_name::Symbol,
    key::InfrastructureSystems.Optimization.OptimizationContainerKey,
    index::Dates.DateTime,
    _::Dates.DateTime,
    data::JuMP.Containers.SparseAxisArray{Float64, N} where N
)

Write a decision-model result whose container is a SparseAxisArray. The sparse container is flattened to a (horizon × n_cols) Matrix{Float64} via to_matrix, where columns are the unique non-time tuple keys (e.g. for post-contingency flows: (outage_id, branch_name)). Cache and HDF5 dataset shapes match the 3D dense path: (horizon, n_cols, num_results).

write_result!(
    store::PowerSimulations.HdfSimulationStore,
    _::Symbol,
    key::InfrastructureSystems.Optimization.OptimizationContainerKey,
    index::Int64,
    simulation_time::Dates.DateTime,
    array::JuMP.Containers.DenseAxisArray{Float64, 2, Ax, L} where {Ax, L<:Tuple{JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup}}
)

Write an emulation model result for an execution index value and the timestamp of the update

write_result!(
    store::PowerSimulations.HdfSimulationStore,
    model_name::Symbol,
    key::InfrastructureSystems.Optimization.OptimizationContainerKey,
    index::Dates.DateTime,
    _::Dates.DateTime,
    data::JuMP.Containers.DenseAxisArray{Float64, N, var"#s252", L} where {var"#s252"<:NTuple{N, Any}, L<:NTuple{N, JuMP.Containers._AxisLookup}}
)

Write a decision model result for a timestamp to the store.

get_component(
    res::InfrastructureSystems.Results,
    uuid::Base.UUID
) -> Union{Nothing, InfrastructureSystems.InfrastructureSystemsComponent}

Calling get_component on a Results is the same as calling [get_available_component] on the system attached to the results.

get_components(
    ::Type{T<:InfrastructureSystems.InfrastructureSystemsComponent},
    res::InfrastructureSystems.Results;
    subsystem_name
) -> InfrastructureSystems.FlattenIteratorWrapper{T, I} where {T<:InfrastructureSystems.InfrastructureSystemsComponent, I<:(Vector)}

Calling get_components on a Results is the same as calling [get_available_components] on the system attached to the results.

get_groups(
    scope_limiter::Union{Nothing, Function},
    selector::ComponentSelector,
    res::InfrastructureSystems.Results
) -> Any

Calling get_groups on a Results is the same as calling [get_available_groups] on the system attached to the results.