PowerSimulations.jl

PowerSimulations.jl is a Julia package designed for power system modeling and the simulation of power system operations. It provides a flexible framework for different complexities and time-scales, streamlines the construction of large-scale optimization problems, and leverages Julia's performance for quasi-static simulations.

Supported Simulation Types

• Integrated Resource Planning
• Production Cost Modeling
• Market Simulations

PowerSimulations.jl is a flexible, open-source tool for quasi-static power system operations simulations, including Production Cost Models. It is designed with a modular approach, allowing users to formulate decision models and emulation models that can be solved independently or interconnected.

Key components of the simulation workflow include:

• Operation Models: Optimization models used to solve specific operation problems.
• Simulation Models: Models that define the requirements for solving a sequence of operation problems, mimicking real-world operator procedures (e.g., a sequence of Unit Commitment and Economic Dispatch problems).

A ProblemTemplate is a high-level abstraction used to specify the modeling properties of the devices and network in a power system problem. It serves as a container for various models:

• NetworkModel: Defines the topology and physics of the network.
• DeviceModel: Defines the mathematical formulation for specific device types (e.g., how a PowerLoad or ThermalStandard unit behaves).
• ServiceModel: Defines how specific services (like reserves) are modeled within the system.

By using a template, modelers can decouple the physical system description from the mathematical complexity of the individual components.

Thermal generation formulations in PowerSimulations.jl define the mathematical models for thermal units in different operational settings, such as economic dispatch and unit commitment.

Key characteristics include:

• Cost Structures: Thermal units can include no-load cost, turn-on/off cost, fixed cost, and variable cost. Variable costs can be modeled as linear, quadratic, or piecewise-linear.
• Reactive Power: The inclusion of reactive power variables and constraints depends on whether the network model is active power-based or includes reactive power.
• Reserve Services: While reserve variables for services are not explicitly part of the base formulation, their inclusion modifies the resulting variables, expressions, constraints, and objective functions.

Electric load formulations define the mathematical optimization models for load units (demand) in various operational settings like economic dispatch or unit commitment.

Note on Reactive Power: The inclusion of reactive power variables and constraints depends on your network model. If the network model is purely active power-based, reactive power variables and related constraints will not be created.

PowerSimulations.jl achieves modularity by assigning a DeviceModel to each PowerSystems.jl component type within a system.

Each DeviceModel is a subtype of AbstractDeviceFormulation. When a simulation is run, these formulations dispatch to specific methods to populate the optimization problem's:

1. Variables: The decision variables for the optimization.
2. Objective function: The cost or utility components.
3. Expressions: Mathematical terms used in constraints or objectives.
4. Constraints: The physical or operational limits of the device.

In a typical DecisionModel, the total optimization problem is the sum of the objective functions and the union of all constraints from the network model and the individual device models.

The rating $R$ resolved via branch_rating is applied differently depending on the network model:

Linear Network Models

(e.g., PTDFPowerModel, DCPPowerModel, AbstractPTDFModel) Active-power flow is bounded symmetrically: $$-R \le f_{b,t} \le R$$ Applied via FlowRateConstraint or StaticBranchBounds (as variable bounds).

Exception: A standalone MonitoredLine (not collapsed by reduction) uses its own explicit flow_limits.

Nonlinear Network Models

(e.g., full AC models) Apparent-power limits are enforced per flow direction: $$(P^{ft}{b,t})^2 + (Q^{ft}{b,t})^2 \le R^2$$ $$(P^{tf}{b,t})^2 + (Q^{tf}{b,t})^2 \le R^2$$ Applied via FlowRateConstraintFromTo and FlowRateConstraintToFrom.

In PowerSimulations, chronologies are the mechanisms that define the flow of information across different parts of a simulation. They are categorized into two types based on the scope of the information flow:

1. Inter-stage chronologies: These define how information flows between different stages of a simulation. For example, using the results from a day-ahead scheduling stage to provide input/constraints for a real-time economic dispatch stage.
2. Intra-stage chronologies: These define how information flows between multiple consecutive executions of a single stage. For example, ensuring that the ramping limits of the first period in an economic dispatch problem are constrained by the setpoints from the final period of the previous execution.

To create a FeedForward, you must provide three primary pieces of information:

1. component_type: The type of component (e.g., a thermal generator) on which the FeedForward will be applied.
2. source: The variable from the previously solved problem that will be used as input (e.g., the commitment variable of a thermal unit).
3. affected_values: The variables in the current/next problem that will be modified or constrained based on the source value (e.g., the operating range constraints in an economic dispatch problem).

Chronologies in PowerSimulations.jl define how information flows through a simulation. There are two primary types:

1. Inter-stage chronologies (InterProblemChronology): Define information flow between different stages (e.g., using a Day-Ahead solution to inform an Economic Dispatch problem).
2. Intra-stage chronologies (IntraProblemChronology): Define information flow between multiple executions within a single stage (e.g., using ramping limits from the final period of one problem to constrain the first period of the next).

When building a simulation, you must pair a RenewableGen subtype with a valid formulation. Valid combinations are typically defined using DeviceModel(device_type, formulation).

Important Considerations:

• Reactive Power: The inclusion of reactive power variables and constraints depends on your chosen Network Formulation. If the network model is purely active power-based, reactive power variables will not be created even if the renewable formulation supports them.
• Reserves: Reserve variables for services are not included in these formulations by default, though their inclusion affects the resulting optimization model (variables, constraints, etc.).

A standalone PSY.MonitoredLine (one not collapsed into a reduction group) can have asymmetric flow_limits. Because a single symmetric general rate limit cannot represent asymmetry, the system handles it as follows:

1. General rate limit (FlowRateConstraint): This is a single symmetric bound calculated as min(rating, flow_limits.from_to, flow_limits.to_from). If from_to and to_from differ, a warning is emitted to flag that this constraint is conservative.
2. Directional limits: The asymmetry is preserved and enforced via FlowLimitFromToConstraint and FlowLimitToFromConstraint, which use flow_limits.from_to and flow_limits.to_from respectively.

To ensure asymmetric limits are honored, use the directional constraints rather than relying solely on the symmetric general rate limit.