SIIP Power Systems Julia Packages¶
The core design of the Scalable Integrated Infrastructure Planning (SIIP) simulation platform is that models are comprised of two major parts:
PowerSystems.jl Takes advantage of Julia's dynamic types and functional dispatch to define data schemas for Power System's data in a structured yet extensible way.
PowerSimulations.jl We leverage the types/structs defined in
PowerSystems.jlto utilize multiple dispatch in the construction of device models within operational models for power systems analysis.
Framework¶
- In this approach, mathematical programming serves as the unifying framework for operational models in power systems.
- The underlying meta model for
PowerSimulations.jlcan be described as follows:
The contributions are:
- Develop a framework that enables developers and researchers to create and integrate new formulations to system-wide models to study renewable energy integration.
- Allow analysts to describe the functional assumptions used in their models in a language that is simple yet clearly states the assumptions.
In [1]:
] activate nb-environs/SMD_env
In [2]:
] instantiate
In [3]:
] up
In [4]:
using Logging
# Testing Topological components of the schema
gl = global_logger()
global_logger(ConsoleLogger(gl.stream, Logging.Error));
In [5]:
tsteps = 2
include("SIIP-Design-Demo/demo-preload.jl");
5-Bus System Data¶
For this presentation, we will use the 5-bus test system for examples.
- It is possible to store the data for the system in a formal type structure.
- The structure organizes the generators, branches, and topological data.
- Using structs/types to handle system data enables the use of multiple dispatch to perform specific operations depending on the device.
In [6]:
sys5b_th
Out[6]:
In [7]:
sys5b_th.generators
Out[7]:
In [8]:
sys5b_th.buses[1]
Out[8]:
In [9]:
sys5b_th.branches[1]
Out[9]:
Design Principle 1: Flexibility¶
Specification of Device Models (Formulations)¶
Optimization problems are created by applying model formulations to the device data structure.
PowerSimulations.jlbuilds a device formulation by calling functions with common constraint structures, enabling code re-usability and consistency across device formulations.The equations that comprise each device formulation are dispatched based on the specification of the device type, device formulation and transmission formulation.
In [33]:
display(TypeTree(PSI.AbstractRenewableFormulation,init_expand = 2,scopesep="\n"))
Example Thermal Generators¶
- The most generic model for a thermal generator in a power system operations model includes the commitment decisions.
- The descriptor of the devices can be directly mapped into the optimization mathematical program.
- An Abstract Type higher up in the tree will generate a more general model of the device.
function activepower_constraints(ps_m::CanonicalModel,
devices::Array{T,1},
device_formulation::Type{D},
system_formulation::Type{S},
time_range::UnitRange{Int64})
where {T <: PSY.ThermalGen,
D <: AbstractThermalFormulation,
S <: PM.AbstractPowerFormulation}
range_data = [(g.name, g.tech.activepowerlimits) for g in devices]
device_semicontinuousrange(ps_m, range_data, time_range,
:thermal_active_range, :Pth, :on_th)
return
end
- When a more specific formulation such as
ThermalDispatchis used, the active power variables constraints are created as a range without the binary component.
function activepower_constraints(ps_m::CanonicalModel,
devices::Array{T,1},
device_formulation::Type{D},
system_formulation::Type{S},
time_range::UnitRange{Int64})
where {T <: PSY.ThermalGen,
D <: AbstractThermalDispatchForm,
S <: PM.AbstractPowerFormulation}
range_data = [(g.name, g.tech.activepowerlimits) for g in devices]
device_range(ps_m, range_data, time_range,
:thermal_active_range, :Pth)
return
end
function device_range(ps_m::CanonicalModel,
range_data::Array{Tuple{String,NamedTuple{(:min, :max),Tuple{Float64,Float64}}},1},
time_range::UnitRange{Int64},
cons_name::Symbol,
var_name::Symbol)
ps_m.constraints[cons_name] =
JuMP.Containers.DenseAxisArray{JuMP.ConstraintRef}
(undef, [r[1] for r in range_data], time_range)
for t in time_range, r in range_data
ps_m.constraints[cons_name][r[1], t] =
JuMP.@constraint(ps_m.JuMPmodel, r[2].min <= ps_m.variables[var_name][r[1], t] <= r[2].max)
end
return
end
In [11]:
ED = PSI.EconomicDispatch(sys5b_th, PSI.CopperPlatePowerModel; optimizer = GLPK_optimizer);
UC = PSI.UnitCommitment(sys5b_th, PSI.CopperPlatePowerModel; optimizer = GLPK_optimizer);
In [12]:
ED.devices[:ThermalGenerators]
Out[12]:
In [13]:
ED.canonical_model.constraints[:thermal_active_range]["Alta",1]
Out[13]:
In [14]:
keys(ED.canonical_model.constraints)
Out[14]:
In a Unit Commitment (UC) model the thermal generators output limits are described as a semi-continuous range.
In [15]:
UC.devices[:ThermalGenerators]
Out[15]:
In [16]:
display(UC.canonical_model.constraints[:thermal_active_range_ub]["Alta",1])
display(UC.canonical_model.constraints[:thermal_active_range_lb]["Alta",1])
In [17]:
keys(UC.canonical_model.constraints)
Out[17]:
Mixing and Changing Device Formulations¶
A common requirement is the capability to define different device models for a particular problem in order to answer questions about the system's operation under different conditions.
For instance, how does the system dispatch change when the units have little flexibility?
In [31]:
ED.devices[:ThermalGenerators] = PSI.DeviceModel(PSY.ThermalGen, PSI.ThermalRampLimited)
PSI.build_op_model!(ED);
ED.canonical_model.constraints[:ramp_thermal_up][:,2]
Out[31]:
Network Representation¶
- For a combination of devices in the system,
PowerSimulations.jlcan specify the network formulation independently in the model. - By collaborating with researchers from LANL, we have integrated
PowerSystems.jl(NREL) andPowerSimulations.jl(NREL) withPowerModels.jl(LANL) to enable nonlinear AC power flow representations and relaxations. - This feature expands the modeling capabilities to perform research with a broader scope, including the use convex optimization models for AC power flow.
In [19]:
EDPF = PSI.EconomicDispatch(sys5b_th, PSI.StandardPTDFForm ; optimizer = GLPK_optimizer, PTDF = PTDF);
In [20]:
display(ED.transmission)
ED.canonical_model.constraints[:CopperPlateBalance][1]
Out[20]:
In [21]:
display(EDPF.transmission)
display(EDPF.canonical_model.constraints[:network_flow]["1",1])
display(EDPF.canonical_model.constraints[:nodal_balance]["nodeA",1])
In [22]:
ED_AC= PSI.EconomicDispatch(sys5b_th, PM.StandardACPForm ; optimizer = ipopt_optimizer);
This capability is supported by the use of JuMP.DenseAxisArrays to keep track of the affine expressions (AffnExpr) that make up for the total injections at the nodes at each time-step.
In [23]:
ED_AC.canonical_model.expressions[:var_active]
Out[23]:
In [24]:
ED_AC.canonical_model.expressions[:var_reactive]
Out[24]:
Services Representation - WIP¶
- Most available open source models have limited representation for services required by the system to integrate large amounts of renewable energy.
- A major line of research is developing new services or market products that operators need to add in order to integrate more renewable energy.
PowerSimulations.jlincludes a specification for services based on the formulation and the collection of devices that participate in the provision of the service.
Design Principle 2: Modularity¶
The design of PowerSimulations.jl separates all the modeling by device, network, and service, and wraps it all into single struct.
In [25]:
display(ED.devices)
In [26]:
display(ED.branches)
display(ED.transmission)
In [27]:
display(ED.services)
In [40]:
EDPF.canonical_model.expressions[:var_active]
Out[40]:
In [29]:
ED.canonical_model.constraints
Out[29]:
In [42]:
res = solve_op_model!(UC, optimizer = GLPK_optimizer);
res.optimizer_log
Out[42]:
Design Principle 3: Scalability¶
- Power system operational models need to be run at large scales: 50,000+ buses, 5000+ generators at 5 minute resolution.
- The third layer defines the mechanics of executing many operational models depending on the type of analysis required.
- This feature is under development right now.
Use of StructJuMP.jl + PowerSimulations.jl for Expansion Problem Definition¶
- Simplify the problem specification phases to develop algorithms and decomposition methods for large scale problems of this nature.
- Incorporate operational models with the appropriate level of detail and resolution into expansion decision-making models.
Next Steps¶
- Develop type structures for more devices and branches.
- Explore mechanisms to update Affine Expression constants in nodal power balance equations when updating time-series data and avoid model rebuilding.
- Use
ParameterJuMPor useMOIconstraint modification?
- Use
- Develop compiling operational model that can be deployed in a self-contained form.
- Use the experience gained and developed structure to build
SystemsandSimulationspackages for water and gas.