From 44bc466a4b1a12fe1d87f78bd92d037aa06747e9 Mon Sep 17 00:00:00 2001 From: "Documenter.jl" Date: Mon, 28 Oct 2024 14:59:43 +0000 Subject: [PATCH] build based on 59ee821 --- dev/.documenter-siteinfo.json | 2 +- dev/api/PowerSimulations/index.html | 164 ++++----- .../developer/index.html | 2 +- .../extending_powersimulations/index.html | 2 +- .../internal/index.html | 346 +++++++++--------- .../troubleshooting/index.html | 2 +- dev/formulation_library/Branch/index.html | 14 +- dev/formulation_library/DCModels/index.html | 2 +- .../Feedforward/index.html | 10 +- dev/formulation_library/General/index.html | 4 +- .../Introduction/index.html | 2 +- dev/formulation_library/Load/index.html | 6 +- dev/formulation_library/Network/index.html | 10 +- dev/formulation_library/Piecewise/index.html | 2 +- dev/formulation_library/README/index.html | 2 +- .../RenewableGen/index.html | 6 +- dev/formulation_library/Service/index.html | 10 +- dev/formulation_library/ThermalGen/index.html | 20 +- dev/index.html | 2 +- .../structure_of_operation_problem/index.html | 2 +- .../troubleshooting/index.html | 2 +- .../debugging_infeasible_models/index.html | 2 +- dev/modeler_guide/definitions/index.html | 2 +- dev/modeler_guide/logging/index.html | 2 +- dev/modeler_guide/modeling_faq/index.html | 2 +- .../parallel_simulations/index.html | 2 +- .../problem_templates/index.html | 6 +- dev/modeler_guide/psi_structure/index.html | 2 +- dev/modeler_guide/read_results/index.html | 2 +- .../running_a_simulation/index.html | 2 +- .../simulation_recorder/index.html | 2 +- dev/modeler_guide/tips_and_tricks/index.html | 2 +- dev/quick_start_guide/index.html | 2 +- .../adding_new_device_formulation/index.html | 2 +- .../adding_new_problem_model/index.html | 2 +- .../basics_of_developing_models/index.html | 2 +- dev/tutorials/decision_problem/index.html | 52 +-- dev/tutorials/pcm_simulation/index.html | 90 ++--- 38 files changed, 394 insertions(+), 394 deletions(-) diff --git a/dev/.documenter-siteinfo.json b/dev/.documenter-siteinfo.json index 2349c4ec3..872ca9af2 100644 --- a/dev/.documenter-siteinfo.json +++ b/dev/.documenter-siteinfo.json @@ -1 +1 @@ -{"documenter":{"julia_version":"1.11.0","generation_timestamp":"2024-10-11T21:15:40","documenter_version":"1.7.0"}} \ No newline at end of file +{"documenter":{"julia_version":"1.11.1","generation_timestamp":"2024-10-28T14:59:03","documenter_version":"1.7.0"}} \ No newline at end of file diff --git a/dev/api/PowerSimulations/index.html b/dev/api/PowerSimulations/index.html index 33a3e63db..b38b7df17 100644 --- a/dev/api/PowerSimulations/index.html +++ b/dev/api/PowerSimulations/index.html @@ -8,53 +8,53 @@ duals::Vector{DataType}, services::Vector{ServiceModel} attributes::Dict{String, Any} -)

Establishes the model for a particular device specified by type. Uses the keyword argument feedforward to enable passing values between operation model at simulation time

Arguments

Example

thermal_gens = DeviceModel(ThermalStandard, ThermalBasicUnitCommitment)
source

Formulations

Refer to the Formulations Page for each Abstract Device Formulation.

Problem Templates

PowerSimulations.ProblemTemplate — Type
ProblemTemplate(::Type{T}) where {T<:PM.AbstractPowerFormulation}

Creates a model reference of the PowerSimulations Optimization Problem.

Arguments

  • model::Type{T<:PM.AbstractPowerFormulation}:

Example

template = ProblemTemplate(CopperPlatePowerModel)

source
PowerSimulations.set_device_model! — Method
set_device_model!(
+)

Establishes the model for a particular device specified by type. Uses the keyword argument feedforward to enable passing values between operation model at simulation time

Arguments

  • ::Type{D} where D<:PSY.Device: Power System Device Type
  • ::Type{B} where B<:AbstractDeviceFormulation: Abstract Device Formulation
  • feedforward::Array{<:AbstractAffectFeedforward} = Vector{AbstractAffectFeedforward}() : use to pass parameters between models
  • use_slacks::Bool = false : Add slacks to the device model. Implementation is model dependent and not all models feature slacks
  • duals::Vector{DataType} = Vector{DataType}(): use to pass constraint type to calculate the duals. The DataType needs to be a valid ConstraintType
  • time_series_names::Dict{Type{<:TimeSeriesParameter}, String} = get_default_time_series_names(D, B) : use to specify time series names associated to the device`
  • attributes::Dict{String, Any} = get_default_attributes(D, B) : use to specify attributes to the device

Example

thermal_gens = DeviceModel(ThermalStandard, ThermalBasicUnitCommitment)
source

Formulations

Refer to the Formulations Page for each Abstract Device Formulation.

Problem Templates

PowerSimulations.ProblemTemplate — Type
ProblemTemplate(::Type{T}) where {T<:PM.AbstractPowerFormulation}

Creates a model reference of the PowerSimulations Optimization Problem.

Arguments

  • model::Type{T<:PM.AbstractPowerFormulation}:

Example

template = ProblemTemplate(CopperPlatePowerModel)

source
PowerSimulations.set_device_model! — Method
set_device_model!(
     template::ProblemTemplate,
     model::DeviceModel
 )
-

Sets the device model in a template using a DeviceModel instance

source
PowerSimulations.set_device_model! — Method
set_device_model!(
+

Sets the device model in a template using a DeviceModel instance

source
PowerSimulations.set_device_model! — Method
set_device_model!(
     template::ProblemTemplate,
     component_type::Type{<:Device},
     formulation::Type{<:PowerSimulations.AbstractDeviceFormulation}
 )
-

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

source
PowerSimulations.set_network_model! — Method
set_network_model!(
+

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

source
PowerSimulations.set_network_model! — Method
set_network_model!(
     template::ProblemTemplate,
     model::NetworkModel
 )
-

Sets the network model in a template.

source
PowerSimulations.set_service_model! — Method
set_service_model!(
+

Sets the network model in a template.

source
PowerSimulations.set_service_model! — Method
set_service_model!(
     template::ProblemTemplate,
     service_name::String,
     service_type::Type{<:Service},
     formulation::Type{<:PowerSimulations.AbstractServiceFormulation}
 )
-

Sets the service model in a template using a name and the service type and formulation. Builds a default ServiceModel with useservicename set to true.

source
PowerSimulations.set_service_model! — Method
set_service_model!(
+

Sets the service model in a template using a name and the service type and formulation. Builds a default ServiceModel with useservicename set to true.

source
PowerSimulations.set_service_model! — Method
set_service_model!(
     template::ProblemTemplate,
     service_type::Type{<:Service},
     formulation::Type{<:PowerSimulations.AbstractServiceFormulation}
 )
-

Sets the service model in a template using a ServiceModel instance.

source
PowerSimulations.template_economic_dispatch — Method
template_economic_dispatch(; kwargs...) -> ProblemTemplate
+

Sets the service model in a template using a ServiceModel instance.

source
PowerSimulations.template_economic_dispatch — Method
template_economic_dispatch(; kwargs...) -> ProblemTemplate
 
template_economic_dispatch(; kwargs...)

Creates a ProblemTemplate with default DeviceModels for an Economic Dispatch problem.

Example

template = templateeconomicdispatch()


 # Accepted Key Words
 - `network::Type{<:PM.AbstractPowerModel}` : override default network model settings
 - `devices::Vector{DeviceModel}` : override default `DeviceModel` settings
-- `services::Vector{ServiceModel}` : override default `ServiceModel` settings
source
PowerSimulations.template_unit_commitment — Method
template_unit_commitment(; kwargs...) -> ProblemTemplate
+- `services::Vector{ServiceModel}` : override default `ServiceModel` settings
source
PowerSimulations.template_unit_commitment — Method
template_unit_commitment(; kwargs...) -> ProblemTemplate
 
template_unit_commitment(; kwargs...)

Creates a ProblemTemplate with default DeviceModels for a Unit Commitment problem.

Example

template = templateunitcommitment()


 # Accepted Key Words
 - `network::Type{<:PM.AbstractPowerModel}` : override default network model settings
 - `devices::Vector{DeviceModel}` : override default `DeviceModel` settings
-- `services::Vector{ServiceModel}` : override default `ServiceModel` settings
source
  +- `services::Vector{ServiceModel}` : override default `ServiceModel` settingssource   

Decision Models

PowerSimulations.DecisionModel — Method
DecisionModel(
     directory::AbstractString,
     optimizer::MathOptInterface.OptimizerWithAttributes;
     jump_model,
     system
 ) -> Any
-

Construct an DecisionProblem from a serialized file.

Arguments

  • directory::AbstractString: Directory containing a serialized model
  • jump_model::Union{Nothing, JuMP.Model} = nothing: The JuMP model does not get serialized. Callers should pass whatever they passed to the original problem.
  • optimizer::Union{Nothing,MOI.OptimizerWithAttributes} = nothing: The optimizer does not get serialized. Callers should pass whatever they passed to the original problem.
  • system::Union{Nothing, PSY.System}: Optionally, the system used for the model. If nothing and systofile was set to true when the model was created, the system will be deserialized from a file.
source
PowerSimulations.DecisionModel — Method
DecisionModel{M}(
+

Construct an DecisionProblem from a serialized file.

Arguments

  • directory::AbstractString: Directory containing a serialized model
  • jump_model::Union{Nothing, JuMP.Model} = nothing: The JuMP model does not get serialized. Callers should pass whatever they passed to the original problem.
  • optimizer::Union{Nothing,MOI.OptimizerWithAttributes} = nothing: The optimizer does not get serialized. Callers should pass whatever they passed to the original problem.
  • system::Union{Nothing, PSY.System}: Optionally, the system used for the model. If nothing and systofile was set to true when the model was created, the system will be deserialized from a file.
source
PowerSimulations.DecisionModel — Method
DecisionModel{M}(
     template::AbstractProblemTemplate,
     sys::PSY.System,
     jump_model::Union{Nothing, JuMP.Model}=nothing;
     kwargs...) where {M<:DecisionProblem}

Build the optimization problem of type M with the specific system and template.

Arguments

  • ::Type{M} where M<:DecisionProblem: The abstract operation model type
  • template::AbstractProblemTemplate: The model reference made up of transmission, devices, branches, and services.
  • sys::PSY.System: the system created using Power Systems
  • jump_model::Union{Nothing, JuMP.Model}: Enables passing a custom JuMP model. Use with care
  • name = nothing: name of model, string or symbol; defaults to the type of template converted to a symbol.
  • optimizer::Union{Nothing,MOI.OptimizerWithAttributes} = nothing : The optimizer does not get serialized. Callers should pass whatever they passed to the original problem.
  • horizon::Dates.Period = UNSET_HORIZON: Manually specify the length of the forecast Horizon
  • resolution::Dates.Period = UNSET_RESOLUTION: Manually specify the model's resolution
  • warm_start::Bool = true: True will use the current operation point in the system to initialize variable values. False initializes all variables to zero. Default is true
  • system_to_file::Bool = true:: True to create a copy of the system used in the model.
  • initialize_model::Bool = true: Option to decide to initialize the model or not.
  • initialization_file::String = "": This allows to pass pre-existing initialization values to avoid the solution of an optimization problem to find feasible initial conditions.
  • deserialize_initial_conditions::Bool = false: Option to deserialize conditions
  • export_pwl_vars::Bool = false: True to export all the pwl intermediate variables. It can slow down significantly the build and solve time.
  • allow_fails::Bool = false: True to allow the simulation to continue even if the optimization step fails. Use with care.
  • optimizer_solve_log_print::Bool = false: Uses JuMP.unset_silent() to print the optimizer's log. By default all solvers are set to MOI.Silent()
  • detailed_optimizer_stats::Bool = false: True to save detailed optimizer stats log.
  • calculate_conflict::Bool = false: True to use solver to calculate conflicts for infeasible problems. Only specific solvers are able to calculate conflicts.
  • direct_mode_optimizer::Bool = false: True to use the solver in direct mode. Creates a JuMP.direct_model.
  • store_variable_names::Bool = false: to store variable names in optimization model. Decreases the build times.
  • rebuild_model::Bool = false: It will force the rebuild of the underlying JuMP model with each call to update the model. It increases solution times, use only if the model can't be updated in memory.
  • initial_time::Dates.DateTime = UNSET_INI_TIME: Initial Time for the model solve.
  • time_series_cache_size::Int = IS.TIME_SERIES_CACHE_SIZE_BYTES: Size in bytes to cache for each time array. Default is 1 MiB. Set to 0 to disable.

Example

template = ProblemTemplate(CopperPlatePowerModel, devices, branches, services)
-OpModel = DecisionModel(MockOperationProblem, template, system)
source
PowerSimulations.DecisionModel — Method
DecisionModel(
+OpModel = DecisionModel(MockOperationProblem, template, system)
source
PowerSimulations.DecisionModel — Method
DecisionModel(
     ::Type{M<:PowerSimulations.DecisionProblem},
     template::PowerSimulations.AbstractProblemTemplate,
     sys::System;
@@ -68,7 +68,7 @@
     kwargs...
 ) -> DecisionModel

Build the optimization problem of type M with the specific system and template

Arguments

  • ::Type{M} where M<:DecisionProblem: The abstract operation model type
  • template::AbstractProblemTemplate: The model reference made up of transmission, devices, branches, and services.
  • sys::PSY.System: the system created using Power Systems
  • jump_model::Union{Nothing, JuMP.Model} = nothing: Enables passing a custom JuMP model. Use with care.

Example

template = ProblemTemplate(CopperPlatePowerModel, devices, branches, services)
-problem = DecisionModel(MyOpProblemType, template, system, optimizer)
source
PowerSimulations.DecisionModel — Method

Builds an empty decision model. This constructor is used for the implementation of custom decision models that do not require a template.

Arguments

  • ::Type{M} where M<:DecisionProblem: The abstract operation model type
  • sys::PSY.System: the system created using Power Systems
  • jump_model::Union{Nothing, JuMP.Model} = nothing: Enables passing a custom JuMP model. Use with care.

Example

problem = DecisionModel(system, optimizer)
source
PowerSimulations.GenericOpProblem — Type

Generic PowerSimulations Operation Problem Type for unspecified models

source
PowerSimulations.build! — Method
build!(
+problem = DecisionModel(MyOpProblemType, template, system, optimizer)
source
PowerSimulations.DecisionModel — Method

Builds an empty decision model. This constructor is used for the implementation of custom decision models that do not require a template.

Arguments

  • ::Type{M} where M<:DecisionProblem: The abstract operation model type
  • sys::PSY.System: the system created using Power Systems
  • jump_model::Union{Nothing, JuMP.Model} = nothing: Enables passing a custom JuMP model. Use with care.

Example

problem = DecisionModel(system, optimizer)
source
PowerSimulations.GenericOpProblem — Type

Generic PowerSimulations Operation Problem Type for unspecified models

source
PowerSimulations.build! — Method
build!(
     model::DecisionModel;
     output_dir,
     recorders,
@@ -76,7 +76,7 @@
     file_level,
     disable_timer_outputs
 )
-

Build the Decision Model based on the specified DecisionProblem.

Arguments

  • model::DecisionModel{<:DecisionProblem}: DecisionModel object
  • output_dir::String: Output directory for results
  • recorders::Vector{Symbol} = []: recorder names to register
  • console_level = Logging.Error:
  • file_level = Logging.Info:
  • disable_timer_outputs = false : Enable/Disable timing outputs
source
PowerSimulations.solve! — Method
solve!(
+

Build the Decision Model based on the specified DecisionProblem.

Arguments

  • model::DecisionModel{<:DecisionProblem}: DecisionModel object
  • output_dir::String: Output directory for results
  • recorders::Vector{Symbol} = []: recorder names to register
  • console_level = Logging.Error:
  • file_level = Logging.Info:
  • disable_timer_outputs = false : Enable/Disable timing outputs
source
PowerSimulations.solve! — Method
solve!(
     model::DecisionModel;
     export_problem_results,
     console_level,
@@ -86,20 +86,20 @@
     kwargs...
 ) -> InfrastructureSystems.Simulation.RunStatusModule.RunStatus

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

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

Arguments

  • model::OperationModel = model: operation model
  • export_problem_results::Bool = false: If true, export OptimizationProblemResults DataFrames to CSV files. Reduces solution times during simulation.
  • console_level = Logging.Error:
  • file_level = Logging.Info:
  • disable_timer_outputs = false : Enable/Disable timing outputs
  • export_optimization_problem::Bool = true: If true, serialize the model to a file to allow re-execution later.

Examples

results = solve!(OpModel)
-results = solve!(OpModel, export_problem_results = true)
source
PowerSimulations.solve! — Method
solve!(
+results = solve!(OpModel, export_problem_results = true)
source
PowerSimulations.solve! — Method
solve!(
     step::Int64,
     model::DecisionModel,
     start_time::Dates.DateTime,
     store::PowerSimulations.SimulationStore;
     exports
 ) -> InfrastructureSystems.Simulation.RunStatusModule.RunStatus
-

Default solve method for a DecisionModel used inside of a Simulation. Solves problems that conform to the requirements of DecisionModel{<: DecisionProblem}

Arguments

  • step::Int: Simulation Step
  • model::OperationModel: operation model
  • start_time::Dates.DateTime: Initial Time of the simulation step in Simulation time.
  • store::SimulationStore: Simulation output store

Accepted Key Words

  • exports: realtime export of output. Use wisely, it can have negative impacts in the simulation times
source
  +

Default solve method for a DecisionModel used inside of a Simulation. Solves problems that conform to the requirements of DecisionModel{<: DecisionProblem}

Arguments

Accepted Key Words

source   

Emulation Models

PowerSimulations.EmulationModel — Type
EmulationModel{M}(
     template::AbstractProblemTemplate,
     sys::PSY.System,
     jump_model::Union{Nothing, JuMP.Model}=nothing;
     kwargs...) where {M<:EmulationProblem}

Build the optimization problem of type M with the specific system and template.

Arguments

  • ::Type{M} where M<:EmulationProblem: The abstract Emulation model type
  • template::AbstractProblemTemplate: The model reference made up of transmission, devices, branches, and services.
  • sys::PSY.System: the system created using Power Systems
  • jump_model::Union{Nothing, JuMP.Model}: Enables passing a custom JuMP model. Use with care
  • name = nothing: name of model, string or symbol; defaults to the type of template converted to a symbol.
  • optimizer::Union{Nothing,MOI.OptimizerWithAttributes} = nothing : The optimizer does not get serialized. Callers should pass whatever they passed to the original problem.
  • warm_start::Bool = true: True will use the current operation point in the system to initialize variable values. False initializes all variables to zero. Default is true
  • system_to_file::Bool = true:: True to create a copy of the system used in the model.
  • initialize_model::Bool = true: Option to decide to initialize the model or not.
  • initialization_file::String = "": This allows to pass pre-existing initialization values to avoid the solution of an optimization problem to find feasible initial conditions.
  • deserialize_initial_conditions::Bool = false: Option to deserialize conditions
  • export_pwl_vars::Bool = false: True to export all the pwl intermediate variables. It can slow down significantly the build and solve time.
  • allow_fails::Bool = false: True to allow the simulation to continue even if the optimization step fails. Use with care.
  • calculate_conflict::Bool = false: True to use solver to calculate conflicts for infeasible problems. Only specific solvers are able to calculate conflicts.
  • optimizer_solve_log_print::Bool = false: Uses JuMP.unset_silent() to print the optimizer's log. By default all solvers are set to MOI.Silent()
  • detailed_optimizer_stats::Bool = false: True to save detailed optimizer stats log.
  • direct_mode_optimizer::Bool = false: True to use the solver in direct mode. Creates a JuMP.direct_model.
  • store_variable_names::Bool = false: True to store variable names in optimization model.
  • rebuild_model::Bool = false: It will force the rebuild of the underlying JuMP model with each call to update the model. It increases solution times, use only if the model can't be updated in memory.
  • initial_time::Dates.DateTime = UNSET_INI_TIME: Initial Time for the model solve.
  • time_series_cache_size::Int = IS.TIME_SERIES_CACHE_SIZE_BYTES: Size in bytes to cache for each time array. Default is 1 MiB. Set to 0 to disable.

Example

template = ProblemTemplate(CopperPlatePowerModel, devices, branches, services)
-OpModel = EmulationModel(MockEmulationProblem, template, system)
source
PowerSimulations.EmulationModel — Method
EmulationModel(
+OpModel = EmulationModel(MockEmulationProblem, template, system)
source
PowerSimulations.EmulationModel — Method
EmulationModel(
     ::Type{M<:PowerSimulations.EmulationProblem},
     template::PowerSimulations.AbstractProblemTemplate,
     sys::System;
@@ -113,14 +113,14 @@
     kwargs...
 ) -> EmulationModel

Build the optimization problem of type M with the specific system and template

Arguments

  • ::Type{M} where M<:EmulationProblem: The abstract Emulation model type
  • template::AbstractProblemTemplate: The model reference made up of transmission, devices, branches, and services.
  • sys::PSY.System: the system created using Power Systems
  • jump_model::Union{Nothing, JuMP.Model}: Enables passing a custom JuMP model. Use with care

Example

template = ProblemTemplate(CopperPlatePowerModel, devices, branches, services)
-problem = EmulationModel(MyEmProblemType, template, system, optimizer)
source
PowerSimulations.EmulationModel — Method
EmulationModel(
+problem = EmulationModel(MyEmProblemType, template, system, optimizer)
source
PowerSimulations.EmulationModel — Method
EmulationModel(
     directory::AbstractString,
     optimizer::MathOptInterface.OptimizerWithAttributes;
     jump_model,
     system,
     kwargs...
 ) -> Any
-

Construct an EmulationProblem from a serialized file.

Arguments

  • directory::AbstractString: Directory containing a serialized model.
  • optimizer::MOI.OptimizerWithAttributes: The optimizer does not get serialized. Callers should pass whatever they passed to the original problem.
  • jump_model::Union{Nothing, JuMP.Model} = nothing: The JuMP model does not get serialized. Callers should pass whatever they passed to the original problem.
  • system::Union{Nothing, PSY.System}: Optionally, the system used for the model. If nothing and systofile was set to true when the model was created, the system will be deserialized from a file.
source
PowerSimulations.build! — Method
build!(
+

Construct an EmulationProblem from a serialized file.

Arguments

  • directory::AbstractString: Directory containing a serialized model.
  • optimizer::MOI.OptimizerWithAttributes: The optimizer does not get serialized. Callers should pass whatever they passed to the original problem.
  • jump_model::Union{Nothing, JuMP.Model} = nothing: The JuMP model does not get serialized. Callers should pass whatever they passed to the original problem.
  • system::Union{Nothing, PSY.System}: Optionally, the system used for the model. If nothing and systofile was set to true when the model was created, the system will be deserialized from a file.
source
PowerSimulations.build! — Method
build!(
     model::EmulationModel;
     executions,
     output_dir,
@@ -129,7 +129,7 @@
     file_level,
     disable_timer_outputs
 )
-

Implementation of build for any EmulationProblem

source
PowerSimulations.run! — Method
run!(
+

Implementation of build for any EmulationProblem

source
PowerSimulations.run! — Method
run!(
     model::EmulationModel;
     export_problem_results,
     console_level,
@@ -139,16 +139,16 @@
     kwargs...
 ) -> InfrastructureSystems.Simulation.RunStatusModule.RunStatus

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

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

Arguments

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

Examples

status = run!(model; optimizer = GLPK.Optimizer, executions = 10)
-status = run!(model; output_dir = ./model_output, optimizer = GLPK.Optimizer, executions = 10)
source
PowerSimulations.solve! — Method
solve!(
+status = run!(model; output_dir = ./model_output, optimizer = GLPK.Optimizer, executions = 10)
source
PowerSimulations.solve! — Method
solve!(
     step::Int64,
     model::EmulationModel,
     start_time::Dates.DateTime,
     store::PowerSimulations.SimulationStore;
     exports
 ) -> InfrastructureSystems.Simulation.RunStatusModule.RunStatus
-

Default solve method for an EmulationModel used inside of a Simulation. Solves problems that conform to the requirements of DecisionModel{<: DecisionProblem}

Arguments

  • step::Int: Simulation Step
  • model::OperationModel: operation model
  • start_time::Dates.DateTime: Initial Time of the simulation step in Simulation time.
  • store::SimulationStore: Simulation output store
  • exports = nothing: realtime export of output. Use wisely, it can have negative impacts in the simulation times
source
  - 

Service Models

List of structures and methods for Service models

PowerSimulations.ServiceModel — Type

Establishes the model for a particular services specified by type. Uses the keyword argument use_service_name to assign the model to a service with the same name as the name in the template. Uses the keyword argument feedforward to enable passing values between operation model at simulation time

Arguments

-::Type{D}: Power System Service Type -::Type{B}: Abstract Service Formulation

Accepted Key Words

  • feedforward::Array{<:AbstractAffectFeedforward} : use to pass parameters between models
  • use_service_name::Bool : use the name as the name for the service

Example

reserves = ServiceModel(PSY.VariableReserve{PSY.ReserveUp}, RangeReserve)

source
  - 

Simulation Models

Refer to the Simulations Page to explanations on how to setup a Simulation, with Sequencing and Feedforwards.

PowerSimulations.InitialCondition — Type

Container for the initial condition data

source
PowerSimulations.SimulationModels — Type
SimulationModels(
+

Default solve method for an EmulationModel used inside of a Simulation. Solves problems that conform to the requirements of DecisionModel{<: DecisionProblem}

Arguments

  • step::Int: Simulation Step
  • model::OperationModel: operation model
  • start_time::Dates.DateTime: Initial Time of the simulation step in Simulation time.
  • store::SimulationStore: Simulation output store
  • exports = nothing: realtime export of output. Use wisely, it can have negative impacts in the simulation times
source
  + 

Service Models

List of structures and methods for Service models

PowerSimulations.ServiceModel — Type

Establishes the model for a particular services specified by type. Uses the keyword argument use_service_name to assign the model to a service with the same name as the name in the template. Uses the keyword argument feedforward to enable passing values between operation model at simulation time

Arguments

-::Type{D}: Power System Service Type -::Type{B}: Abstract Service Formulation

Accepted Key Words

  • feedforward::Array{<:AbstractAffectFeedforward} : use to pass parameters between models
  • use_service_name::Bool : use the name as the name for the service

Example

reserves = ServiceModel(PSY.VariableReserve{PSY.ReserveUp}, RangeReserve)

source
  + 

Simulation Models

Refer to the Simulations Page to explanations on how to setup a Simulation, with Sequencing and Feedforwards.

PowerSimulations.InitialCondition — Type

Container for the initial condition data

source
PowerSimulations.SimulationModels — Type
SimulationModels(
     decision_models::Vector{<:DecisionModel},
     emulation_models::Union{Nothing, EmulationModel}
 )

Stores the OperationProblem definitions to be used in the simulation. When creating the SimulationModels, the order in which the models are created determines the order on which the simulation is executed.

Arguments

  • decision_models::Vector{<:DecisionModel}: Vector of decision models.
  • emulation_models::Union{Nothing, EmulationModel}: Optional argument to include

an EmulationModel in the Simulation

Example

template_uc = template_unit_commitment()
@@ -160,7 +160,7 @@
         my_decision_model_uc,
         my_decision_model_ed
     ]
-)
source
PowerSimulations.SimulationSequence — Type
SimulationSequence(
+)
source
PowerSimulations.SimulationSequence — Type
SimulationSequence(
     models::SimulationModels,
     feedforward::Dict{String, Vector{<:AbstractAffectFeedforward}}
     ini_cond_chronology::InitialConditionChronology
@@ -186,7 +186,7 @@
             ),
         ],
     ),
-)
source
PowerSimulations.Simulation — Type
Simulation(
+)
source
PowerSimulations.Simulation — Type
Simulation(
     sequence::SimulationSequence,
     name::String,
     steps::Int
@@ -223,8 +223,8 @@
     steps = 5,
     models = models,
     simulation_folder = mktempdir(cleanup=true),
-)
source
PowerSimulations.Simulation — Method
Simulation(directory::AbstractString, model_info::Dict)
-

Constructs Simulation from a serialized directory. Callers should pass any kwargs here that they passed to the original Simulation.

Arguments

  • directory::AbstractString: the directory returned from the call to serialize
  • model_info::Dict: Two-level dictionary containing model parameters that cannot be serialized. The outer dict should be keyed by the problem name. The inner dict must contain 'optimizer' and may contain 'jump_model'. These should be the same values used for the original simulation.
source
PowerSimulations.build! — Method
build!(
+)
source
PowerSimulations.Simulation — Method
Simulation(directory::AbstractString, model_info::Dict)
+

Constructs Simulation from a serialized directory. Callers should pass any kwargs here that they passed to the original Simulation.

Arguments

  • directory::AbstractString: the directory returned from the call to serialize
  • model_info::Dict: Two-level dictionary containing model parameters that cannot be serialized. The outer dict should be keyed by the problem name. The inner dict must contain 'optimizer' and may contain 'jump_model'. These should be the same values used for the original simulation.
source
PowerSimulations.build! — Method
build!(
     sim::Simulation;
     recorders,
     console_level,
@@ -233,13 +233,13 @@
     partitions,
     index
 ) -> InfrastructureSystems.Simulation.SimulationBuildStatusModule.SimulationBuildStatus
-

Build the Simulation, problems and the related folder structure.

Arguments

  • sim::Simulation: simulation object
  • recorders::Vector{Symbol} = []: recorder names to register
  • serialize::Bool = true: serializes the simulation objects in the simulation
  • console_level = Logging.Error:
  • file_level = Logging.Info:
source
PowerSimulations.execute! — Method
execute!(
+

Build the Simulation, problems and the related folder structure.

Arguments

  • sim::Simulation: simulation object
  • recorders::Vector{Symbol} = []: recorder names to register
  • serialize::Bool = true: serializes the simulation objects in the simulation
  • console_level = Logging.Error:
  • file_level = Logging.Info:
source
PowerSimulations.execute! — Method
execute!(
     sim::Simulation;
     kwargs...
 ) -> InfrastructureSystems.Simulation.RunStatusModule.RunStatus

Solves the simulation model for sequential Simulations.

Arguments

  • sim::Simulation=sim: simulation object created by Simulation()

The optional keyword argument exports controls exporting of results to CSV files as the simulation runs.

Example

sim = Simulation("Test", 7, problems, "/Users/folder")
-execute!(sim::Simulation; kwargs...)
source
PowerSimulations.SimulationPartitions — Type

Defines how a simulation can be partition into partitions and run in parallel.

source
PowerSimulations.get_num_partitions — Method
get_num_partitions(x::SimulationPartitions) -> Int64
-

Return the number of partitions in the simulation.

source
PowerSimulations.run_parallel_simulation — Method
run_parallel_simulation(
+execute!(sim::Simulation; kwargs...)
source
PowerSimulations.SimulationPartitions — Type

Defines how a simulation can be partition into partitions and run in parallel.

source
PowerSimulations.get_num_partitions — Method
get_num_partitions(x::SimulationPartitions) -> Int64
+

Return the number of partitions in the simulation.

source
PowerSimulations.run_parallel_simulation — Method
run_parallel_simulation(
     build_function,
     execute_function;
     script,
@@ -252,46 +252,46 @@
     exeflags,
     force
 )
-

Run a partitioned simulation in parallel on a local computer.

Arguments

  • build_function: Function reference that returns a built Simulation.
  • execute_function: Function reference that executes a Simulation.
  • script::AbstractString: Path to script that includes $build_function$ and $execute_function$.
  • output_dir::AbstractString: Path for simulation outputs
  • name::AbstractString: Simulation name
  • num_steps::Integer: Total number of steps in the simulation
  • period::Integer: Number of steps in each simulation partition
  • num_overlap_steps::Integer: Number of steps that each partition overlaps with the previous partition
  • num_parallel_processes: Number of partitions to run in parallel. If nothing, use the number of cores.
  • exeflags: Path to Julia project. Forwarded to Distributed.addprocs.
  • force: Overwrite the output directory if it already exists.
source
  - 

Chronology Models

PowerSimulations.InterProblemChronology — Type
InterProblemChronology()

Type struct to select an information sharing model between stages that uses results from the most recent stage executed to calculate the initial conditions. This model takes into account solutions from stages defined with finer temporal resolutions

See also: IntraProblemChronology

source
PowerSimulations.IntraProblemChronology — Type
IntraProblemChronology()

Type struct to select an information sharing model between stages that uses results from the same recent stage to calculate the initial conditions. This model ignores solutions from stages defined with finer temporal resolutions.

See also: InterProblemChronology

source

Variables

For a list of variables for each device refer to its Formulations page.

Common Variables

PowerSimulations.ActivePowerVariable — Type

Struct to dispatch the creation of Active Power Variables

Docs abbreviation: $p$

source
PowerSimulations.ReactivePowerVariable — Type

Struct to dispatch the creation of Reactive Power Variables

Docs abbreviation: $q$

source
PowerSimulations.PieceWiseLinearCostVariable — Type

Struct to dispatch the creation of piecewise linear cost variables for objective function

Docs abbreviation: $\delta$

source

Thermal Unit Variables

PowerSimulations.OnVariable — Type

Struct to dispatch the creation of a binary commitment status variable

Docs abbreviation: $u$

source
PowerSimulations.StartVariable — Type

Struct to dispatch the creation of Binary Start Variables

Docs abbreviation: $v$

source
PowerSimulations.StopVariable — Type

Struct to dispatch the creation of Binary Stop Variables

Docs abbreviation: $w$

source
PowerSimulations.TimeDurationOn — Type

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

source
PowerSimulations.TimeDurationOff — Type

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

source
PowerSimulations.HotStartVariable — Type

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

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

source
PowerSimulations.WarmStartVariable — Type

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

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

source
PowerSimulations.ColdStartVariable — Type

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

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

source
PowerSimulations.PowerAboveMinimumVariable — Type

Struct to dispatch the creation of Active Power Variables above minimum power for Thermal Compact formulations

Docs abbreviation: $\Delta p$

source
PowerSimulations.PowerOutput — Type

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

source

Storage Unit Variables

PowerSimulations.ReservationVariable — Type

Struct to dispatch the creation of binary storage charge reservation variable

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

source
PowerSimulations.EnergyVariable — Type

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

Docs abbreviation: $e$

source
PowerSimulations.ActivePowerOutVariable — Type

Struct to dispatch the creation of Active Power Output Variables for 2-directional devices. For instance storage or pump-hydro

Docs abbreviation: $p^\text{out}$

source
PowerSimulations.ActivePowerInVariable — Type

Struct to dispatch the creation of Active Power Input Variables for 2-directional devices. For instance storage or pump-hydro

Docs abbreviation: $p^\text{in}$

source

Branches and Network Variables

PowerSimulations.FlowActivePowerVariable — Type

Struct to dispatch the creation of bidirectional Active Power Flow Variables

Docs abbreviation: $f$

source
PowerSimulations.FlowActivePowerSlackUpperBound — Type

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

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

source
PowerSimulations.FlowActivePowerSlackLowerBound — Type

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

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

source
PowerSimulations.FlowActivePowerFromToVariable — Type

Struct to dispatch the creation of unidirectional Active Power Flow Variables

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

source
PowerSimulations.FlowActivePowerToFromVariable — Type

Struct to dispatch the creation of unidirectional Active Power Flow Variables

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

source
PowerSimulations.FlowReactivePowerFromToVariable — Type

Struct to dispatch the creation of unidirectional Reactive Power Flow Variables

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

source
PowerSimulations.FlowReactivePowerToFromVariable — Type

Struct to dispatch the creation of unidirectional Reactive Power Flow Variables

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

source
PowerSimulations.PhaseShifterAngle — Type

Struct to dispatch the creation of Phase Shifters Variables

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

source
PowerSimulations.HVDCLosses — Type

Struct to dispatch the creation of HVDC Losses Auxiliary Variables

Docs abbreviation: $\ell$

source
PowerSimulations.HVDCFlowDirectionVariable — Type

Struct to dispatch the creation of HVDC Flow Direction Auxiliary Variables

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

source
PowerSimulations.VoltageMagnitude — Type

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

Docs abbreviation: $v$

source
PowerSimulations.VoltageAngle — Type

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

Docs abbreviation: $\theta$

source

Services Variables

PowerSimulations.ActivePowerReserveVariable — Type

Struct to dispatch the creation of Active Power Reserve Variables

Docs abbreviation: $r$

source
PowerSimulations.ServiceRequirementVariable — Type

Struct to dispatch the creation of Service Requirement Variables

Docs abbreviation: $\text{req}$

source
PowerSimulations.SystemBalanceSlackUp — Type

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

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

source
PowerSimulations.SystemBalanceSlackDown — Type

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

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

source
PowerSimulations.ReserveRequirementSlack — Type

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

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

source
PowerSimulations.InterfaceFlowSlackUp — Type

Struct to dispatch the creation of Interface Flow Slack Up variables

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

source
PowerSimulations.InterfaceFlowSlackDown — Type

Struct to dispatch the creation of Interface Flow Slack Down variables

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

source

Feedforward Variables

PowerSimulations.UpperBoundFeedForwardSlack — Type

Struct to dispatch the creation of Slack variables for UpperBoundFeedforward

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

source
PowerSimulations.LowerBoundFeedForwardSlack — Type

Struct to dispatch the creation of Slack variables for LowerBoundFeedforward

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

source
  - 

Constraints

Common Constraints

PowerSimulations.PieceWiseLinearCostConstraint — Type

Struct to create the PieceWiseLinearCostConstraint associated with a specified variable.

See Piecewise linear cost functions for more information.

source

Network Constraints

PowerSimulations.CopperPlateBalanceConstraint — Type

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

The specified constraint is generally formulated as:

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

source
PowerSimulations.NodalBalanceActiveConstraint — Type

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

The specified constraint depends on the network model chosen.

source
PowerSimulations.NodalBalanceReactiveConstraint — Type

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

The specified constraint depends on the network model chosen.

source
PowerSimulations.AreaParticipationAssignmentConstraint — Type

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

The specified constraint is generally formulated as:

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

source

Power Variable Limit Constraints

PowerSimulations.ActivePowerVariableLimitsConstraint — Type

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

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

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

source
PowerSimulations.ReactivePowerVariableLimitsConstraint — Type

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

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

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

source
PowerSimulations.ActivePowerVariableTimeSeriesLimitsConstraint — Type

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

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

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

source
PowerSimulations.InputActivePowerVariableLimitsConstraint — Type

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

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

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

source
PowerSimulations.OutputActivePowerVariableLimitsConstraint — Type

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

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

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

source

Services Constraints

PowerSimulations.RequirementConstraint — Type

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

The constraint is as follows:

\[\sum_{d\in\mathcal{D}_s} r_{d,t} + r_t^\text{sl} \ge \text{Req},\quad \forall t\in \{1,\dots, T\} \quad \text{(for a ConstantReserve)} \\ -\sum_{d\in\mathcal{D}_s} r_{d,t} + r_t^\text{sl} \ge \text{RequirementTimeSeriesParameter}_{t},\quad \forall t\in \{1,\dots, T\} \quad \text{(for a VariableReserve)}\]

source
PowerSimulations.ParticipationFractionConstraint — Type

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

The constraint is as follows:

\[r_{d,t} \le \text{Req} \cdot \text{PF} ,\quad \forall d\in \mathcal{D}_s, \forall t\in \{1,\dots, T\} \quad \text{(for a ConstantReserve)} \\ -r_{d,t} \le \text{RequirementTimeSeriesParameter}_{t} \cdot \text{PF}\quad \forall d\in \mathcal{D}_s, \forall t\in \{1,\dots, T\}, \quad \text{(for a VariableReserve)}\]

source
PowerSimulations.ReservePowerConstraint — Type

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

For more information check Service Formulations for NonSpinningReserve.

The constraint is as follows:

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

source

Thermal Unit Constraints

PowerSimulations.ActiveRangeICConstraint — Type

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

The specified constraint is formulated as:

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

source
PowerSimulations.CommitmentConstraint — Type

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

The specified constraints are formulated as:

\[u_1^\text{th} = u^\text{th,init} + v_1^\text{th} - w_1^\text{th} \\ +

Run a partitioned simulation in parallel on a local computer.

Arguments

  • build_function: Function reference that returns a built Simulation.
  • execute_function: Function reference that executes a Simulation.
  • script::AbstractString: Path to script that includes $build_function$ and $execute_function$.
  • output_dir::AbstractString: Path for simulation outputs
  • name::AbstractString: Simulation name
  • num_steps::Integer: Total number of steps in the simulation
  • period::Integer: Number of steps in each simulation partition
  • num_overlap_steps::Integer: Number of steps that each partition overlaps with the previous partition
  • num_parallel_processes: Number of partitions to run in parallel. If nothing, use the number of cores.
  • exeflags: Path to Julia project. Forwarded to Distributed.addprocs.
  • force: Overwrite the output directory if it already exists.
source
  + 

Chronology Models

PowerSimulations.InterProblemChronology — Type
InterProblemChronology()

Type struct to select an information sharing model between stages that uses results from the most recent stage executed to calculate the initial conditions. This model takes into account solutions from stages defined with finer temporal resolutions

See also: IntraProblemChronology

source
PowerSimulations.IntraProblemChronology — Type
IntraProblemChronology()

Type struct to select an information sharing model between stages that uses results from the same recent stage to calculate the initial conditions. This model ignores solutions from stages defined with finer temporal resolutions.

See also: InterProblemChronology

source

Variables

For a list of variables for each device refer to its Formulations page.

Common Variables

PowerSimulations.ActivePowerVariable — Type

Struct to dispatch the creation of Active Power Variables

Docs abbreviation: $p$

source
PowerSimulations.ReactivePowerVariable — Type

Struct to dispatch the creation of Reactive Power Variables

Docs abbreviation: $q$

source
PowerSimulations.PieceWiseLinearCostVariable — Type

Struct to dispatch the creation of piecewise linear cost variables for objective function

Docs abbreviation: $\delta$

source

Thermal Unit Variables

PowerSimulations.OnVariable — Type

Struct to dispatch the creation of a binary commitment status variable

Docs abbreviation: $u$

source
PowerSimulations.StartVariable — Type

Struct to dispatch the creation of Binary Start Variables

Docs abbreviation: $v$

source
PowerSimulations.StopVariable — Type

Struct to dispatch the creation of Binary Stop Variables

Docs abbreviation: $w$

source
PowerSimulations.TimeDurationOn — Type

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

source
PowerSimulations.TimeDurationOff — Type

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

source
PowerSimulations.HotStartVariable — Type

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

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

source
PowerSimulations.WarmStartVariable — Type

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

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

source
PowerSimulations.ColdStartVariable — Type

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

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

source
PowerSimulations.PowerAboveMinimumVariable — Type

Struct to dispatch the creation of Active Power Variables above minimum power for Thermal Compact formulations

Docs abbreviation: $\Delta p$

source
PowerSimulations.PowerOutput — Type

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

source

Storage Unit Variables

PowerSimulations.ReservationVariable — Type

Struct to dispatch the creation of binary storage charge reservation variable

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

source
PowerSimulations.EnergyVariable — Type

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

Docs abbreviation: $e$

source
PowerSimulations.ActivePowerOutVariable — Type

Struct to dispatch the creation of Active Power Output Variables for 2-directional devices. For instance storage or pump-hydro

Docs abbreviation: $p^\text{out}$

source
PowerSimulations.ActivePowerInVariable — Type

Struct to dispatch the creation of Active Power Input Variables for 2-directional devices. For instance storage or pump-hydro

Docs abbreviation: $p^\text{in}$

source

Branches and Network Variables

PowerSimulations.FlowActivePowerVariable — Type

Struct to dispatch the creation of bidirectional Active Power Flow Variables

Docs abbreviation: $f$

source
PowerSimulations.FlowActivePowerSlackUpperBound — Type

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

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

source
PowerSimulations.FlowActivePowerSlackLowerBound — Type

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

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

source
PowerSimulations.FlowActivePowerFromToVariable — Type

Struct to dispatch the creation of unidirectional Active Power Flow Variables

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

source
PowerSimulations.FlowActivePowerToFromVariable — Type

Struct to dispatch the creation of unidirectional Active Power Flow Variables

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

source
PowerSimulations.FlowReactivePowerFromToVariable — Type

Struct to dispatch the creation of unidirectional Reactive Power Flow Variables

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

source
PowerSimulations.FlowReactivePowerToFromVariable — Type

Struct to dispatch the creation of unidirectional Reactive Power Flow Variables

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

source
PowerSimulations.PhaseShifterAngle — Type

Struct to dispatch the creation of Phase Shifters Variables

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

source
PowerSimulations.HVDCLosses — Type

Struct to dispatch the creation of HVDC Losses Auxiliary Variables

Docs abbreviation: $\ell$

source
PowerSimulations.HVDCFlowDirectionVariable — Type

Struct to dispatch the creation of HVDC Flow Direction Auxiliary Variables

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

source
PowerSimulations.VoltageMagnitude — Type

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

Docs abbreviation: $v$

source
PowerSimulations.VoltageAngle — Type

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

Docs abbreviation: $\theta$

source

Services Variables

PowerSimulations.ActivePowerReserveVariable — Type

Struct to dispatch the creation of Active Power Reserve Variables

Docs abbreviation: $r$

source
PowerSimulations.ServiceRequirementVariable — Type

Struct to dispatch the creation of Service Requirement Variables

Docs abbreviation: $\text{req}$

source
PowerSimulations.SystemBalanceSlackUp — Type

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

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

source
PowerSimulations.SystemBalanceSlackDown — Type

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

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

source
PowerSimulations.ReserveRequirementSlack — Type

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

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

source
PowerSimulations.InterfaceFlowSlackUp — Type

Struct to dispatch the creation of Interface Flow Slack Up variables

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

source
PowerSimulations.InterfaceFlowSlackDown — Type

Struct to dispatch the creation of Interface Flow Slack Down variables

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

source

Feedforward Variables

PowerSimulations.UpperBoundFeedForwardSlack — Type

Struct to dispatch the creation of Slack variables for UpperBoundFeedforward

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

source
PowerSimulations.LowerBoundFeedForwardSlack — Type

Struct to dispatch the creation of Slack variables for LowerBoundFeedforward

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

source
  + 

Constraints

Common Constraints

PowerSimulations.PieceWiseLinearCostConstraint — Type

Struct to create the PieceWiseLinearCostConstraint associated with a specified variable.

See Piecewise linear cost functions for more information.

source

Network Constraints

PowerSimulations.CopperPlateBalanceConstraint — Type

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

The specified constraint is generally formulated as:

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

source
PowerSimulations.NodalBalanceActiveConstraint — Type

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

The specified constraint depends on the network model chosen.

source
PowerSimulations.NodalBalanceReactiveConstraint — Type

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

The specified constraint depends on the network model chosen.

source
PowerSimulations.AreaParticipationAssignmentConstraint — Type

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

The specified constraint is generally formulated as:

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

source

Power Variable Limit Constraints

PowerSimulations.ActivePowerVariableLimitsConstraint — Type

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

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

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

source
PowerSimulations.ReactivePowerVariableLimitsConstraint — Type

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

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

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

source
PowerSimulations.ActivePowerVariableTimeSeriesLimitsConstraint — Type

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

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

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

source
PowerSimulations.InputActivePowerVariableLimitsConstraint — Type

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

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

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

source
PowerSimulations.OutputActivePowerVariableLimitsConstraint — Type

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

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

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

source

Services Constraints

PowerSimulations.RequirementConstraint — Type

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

The constraint is as follows:

\[\sum_{d\in\mathcal{D}_s} r_{d,t} + r_t^\text{sl} \ge \text{Req},\quad \forall t\in \{1,\dots, T\} \quad \text{(for a ConstantReserve)} \\ +\sum_{d\in\mathcal{D}_s} r_{d,t} + r_t^\text{sl} \ge \text{RequirementTimeSeriesParameter}_{t},\quad \forall t\in \{1,\dots, T\} \quad \text{(for a VariableReserve)}\]

source
PowerSimulations.ParticipationFractionConstraint — Type

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

The constraint is as follows:

\[r_{d,t} \le \text{Req} \cdot \text{PF} ,\quad \forall d\in \mathcal{D}_s, \forall t\in \{1,\dots, T\} \quad \text{(for a ConstantReserve)} \\ +r_{d,t} \le \text{RequirementTimeSeriesParameter}_{t} \cdot \text{PF}\quad \forall d\in \mathcal{D}_s, \forall t\in \{1,\dots, T\}, \quad \text{(for a VariableReserve)}\]

source
PowerSimulations.ReservePowerConstraint — Type

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

For more information check Service Formulations for NonSpinningReserve.

The constraint is as follows:

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

source

Thermal Unit Constraints

PowerSimulations.ActiveRangeICConstraint — Type

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

The specified constraint is formulated as:

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

source
PowerSimulations.CommitmentConstraint — Type

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

The specified constraints are formulated as:

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

source
PowerSimulations.DurationConstraint — Type

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

For more information check ThermalGen Formulations.

source
PowerSimulations.RampConstraint — Type

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

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

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

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

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

source
PowerSimulations.StartupInitialConditionConstraint — Type

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

For more information check ThermalGen Formulations for ThermalMultiStartUnitCommitment.

source
PowerSimulations.StartupTimeLimitTemperatureConstraint — Type

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

For more information check ThermalGen Formulations for ThermalMultiStartUnitCommitment.

source

Renewable Unit Constraints

PowerSimulations.EqualityConstraint — Type

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

For more information check RenewableGen Formulations.

The specified constraint is formulated as:

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

source

Branches Constraints

PowerSimulations.FlowLimitConstraint — Type

Struct to create the constraint that set the flow limits through a PhaseShiftingTransformer.

For more information check Branch Formulations.

The specified constraint is formulated as:

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

source
PowerSimulations.FlowRateConstraint — Type

Struct to create the constraint that set the flow limits through an HVDC two-terminal branch.

For more information check Branch Formulations.

The specified constraint is formulated as:

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

source
PowerSimulations.FlowRateConstraintFromTo — Type

Struct to create the constraint that set the flow from-to limits through an HVDC two-terminal branch.

For more information check Branch Formulations.

The specified constraint is formulated as:

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

source
PowerSimulations.FlowRateConstraintToFrom — Type

Struct to create the constraint that set the flow to-from limits through an HVDC two-terminal branch.

For more information check Branch Formulations.

The specified constraint is formulated as:

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

source
PowerSimulations.HVDCPowerBalance — Type

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

For more information check Branch Formulations.

The specified constraints are formulated as:

\[\begin{align*} +v_t^\text{th} + w_t^\text{th} \le 1, \quad \forall t \in \{1,\dots,T\}\]

source
PowerSimulations.DurationConstraint — Type

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

For more information check ThermalGen Formulations.

source
PowerSimulations.RampConstraint — Type

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

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

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

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

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

source
PowerSimulations.StartupInitialConditionConstraint — Type

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

For more information check ThermalGen Formulations for ThermalMultiStartUnitCommitment.

source
PowerSimulations.StartupTimeLimitTemperatureConstraint — Type

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

For more information check ThermalGen Formulations for ThermalMultiStartUnitCommitment.

source

Renewable Unit Constraints

PowerSimulations.EqualityConstraint — Type

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

For more information check RenewableGen Formulations.

The specified constraint is formulated as:

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

source

Branches Constraints

PowerSimulations.FlowLimitConstraint — Type

Struct to create the constraint that set the flow limits through a PhaseShiftingTransformer.

For more information check Branch Formulations.

The specified constraint is formulated as:

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

source
PowerSimulations.FlowRateConstraint — Type

Struct to create the constraint that set the flow limits through an HVDC two-terminal branch.

For more information check Branch Formulations.

The specified constraint is formulated as:

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

source
PowerSimulations.FlowRateConstraintFromTo — Type

Struct to create the constraint that set the flow from-to limits through an HVDC two-terminal branch.

For more information check Branch Formulations.

The specified constraint is formulated as:

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

source
PowerSimulations.FlowRateConstraintToFrom — Type

Struct to create the constraint that set the flow to-from limits through an HVDC two-terminal branch.

For more information check Branch Formulations.

The specified constraint is formulated as:

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

source
PowerSimulations.HVDCPowerBalance — Type

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

For more information check Branch Formulations.

The specified constraints are formulated as:

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

source
PowerSimulations.NetworkFlowConstraint — Type

Struct to create the constraint the AC branch flows depending on the network model. For more information check Branch Formulations.

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

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

source
PowerSimulations.RateLimitConstraint — Type

Struct to create the constraint that set the AC flow limits through branches.

For more information check Branch Formulations.

The specified constraint is formulated as:

\[\begin{align*} +\end{align*}\]

source
PowerSimulations.NetworkFlowConstraint — Type

Struct to create the constraint the AC branch flows depending on the network model. For more information check Branch Formulations.

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

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

source
PowerSimulations.RateLimitConstraint — Type

Struct to create the constraint that set the AC flow limits through branches.

For more information check Branch Formulations.

The specified constraint is formulated as:

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

source
PowerSimulations.PhaseAngleControlLimit — Type

Struct to create the constraint that set the angle limits through a PhaseShiftingTransformer.

For more information check Branch Formulations.

The specified constraint is formulated as:

\[\Theta^\text{min} \le \theta^\text{shift}_t \le \Theta^\text{max}, \quad \forall t \in \{1,\dots,T\}\]

source

Feedforward Constraints

PowerSimulations.FeedforwardSemiContinuousConstraint — Type

Struct to create the constraint for semicontinuous feedforward limits.

For more information check Feedforward Formulations.

The specified constraint is formulated as:

\[\begin{align*} +\end{align*}\]

source
PowerSimulations.PhaseAngleControlLimit — Type

Struct to create the constraint that set the angle limits through a PhaseShiftingTransformer.

For more information check Branch Formulations.

The specified constraint is formulated as:

\[\Theta^\text{min} \le \theta^\text{shift}_t \le \Theta^\text{max}, \quad \forall t \in \{1,\dots,T\}\]

source

Feedforward Constraints

PowerSimulations.FeedforwardSemiContinuousConstraint — Type

Struct to create the constraint for semicontinuous feedforward limits.

For more information check Feedforward Formulations.

The specified constraint is formulated as:

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

source
PowerSimulations.FeedforwardUpperBoundConstraint — Type

Struct to create the constraint for upper bound feedforward limits.

For more information check Feedforward Formulations.

The specified constraint is formulated as:

\[\begin{align*} +\end{align*}\]

source
PowerSimulations.FeedforwardUpperBoundConstraint — Type

Struct to create the constraint for upper bound feedforward limits.

For more information check Feedforward Formulations.

The specified constraint is formulated as:

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

source
PowerSimulations.FeedforwardLowerBoundConstraint — Type

Struct to create the constraint for lower bound feedforward limits.

For more information check Feedforward Formulations.

The specified constraint is formulated as:

\[\begin{align*} +\end{align*}\]

source
PowerSimulations.FeedforwardLowerBoundConstraint — Type

Struct to create the constraint for lower bound feedforward limits.

For more information check Feedforward Formulations.

The specified constraint is formulated as:

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

source
  - 

Parameters

Time Series Parameters

PowerSimulations.ActivePowerTimeSeriesParameter — Type

Parameter to define active power time series

source
PowerSimulations.ReactivePowerTimeSeriesParameter — Type

Parameter to define reactive power time series

source
PowerSimulations.RequirementTimeSeriesParameter — Type

Parameter to define requirement time series

source

Variable Value Parameters

PowerSimulations.UpperBoundValueParameter — Type

Parameter to define variable upper bound

source
PowerSimulations.LowerBoundValueParameter — Type

Parameter to define variable lower bound

source
PowerSimulations.OnStatusParameter — Type

Parameter to define unit commitment status

source
PowerSimulations.FixValueParameter — Type

Parameter to FixValueParameter

source

Objective Function Parameters

PowerSimulations.CostFunctionParameter — Type

Parameter to define cost function coefficient

source

Results

Acessing Optimization Model

PowerSimulations.serialize_optimization_model — Method
serialize_optimization_model(
+\end{align*}\]
source
  + 

Parameters

Time Series Parameters

Variable Value Parameters

Objective Function Parameters

Results

Acessing Optimization Model

PowerSimulations.get_all_constraint_index — Method
get_all_constraint_index(
     model::PowerSimulations.OperationModel
 ) -> Vector{Tuple{InfrastructureSystems.Optimization.ConstraintKey, Int64, Int64}}
-

Each Tuple corresponds to (conname, internalindex, moi_index)

source

Accessing Problem Results

Accessing Problem Results

Accessing Simulation Results

Accessing Simulation Results

PowerSimulations.SimulationResults — Type
SimulationResults(
     path::AbstractString,
     name::AbstractString;
     ...
@@ -302,12 +302,12 @@
     execution;
     ignore_status
 ) -> SimulationResults
-

Construct SimulationResults from a simulation output directory.

Arguments

  • path::AbstractString: Simulation output directory
  • name::AbstractString: Simulation name
  • execution::AbstractString: Execution number. Default is the most recent.
  • ignore_status::Bool: If true, return results even if the simulation failed.
source
PowerSimulations.SimulationResults — Method
SimulationResults(
+

Construct SimulationResults from a simulation output directory.

Arguments

  • path::AbstractString: Simulation output directory
  • name::AbstractString: Simulation name
  • execution::AbstractString: Execution number. Default is the most recent.
  • ignore_status::Bool: If true, return results even if the simulation failed.
source
InfrastructureSystems.Optimization.export_results — Method
export_results(results::SimulationResults, exports)

Export results to files in the results directory.

Arguments

  • results::SimulationResults: simulation results
  • exports: SimulationResultsExport or anything that can be passed to its constructor. (such as Dict or path to JSON file)

An example JSON file demonstrating possible options is below. Note that start_time, end_time, path, and format are optional.

{
   "decision_models": [
     {
@@ -337,35 +337,35 @@
   "path": null,
   "format": "csv"
 }
-
source
InfrastructureSystems.Optimization.read_aux_variable — Method
read_aux_variable(
     res::PowerSimulations.SimulationProblemResults{PowerSimulations.DecisionModelSimulationResults},
     args...;
     initial_time,
     count,
     store
 ) -> SortedDict{Any, Any, Base.Order.ForwardOrdering}
-

Return the values for the requested auxillary variables. It keeps requests when performing multiple retrievals.

Arguments

  • args: Can be a string returned from list_aux_variable_names or args that can be splatted into a AuxVarKey.
  • initial_time::Dates.DateTime : initial of the requested results
  • count::Int: Number of results
source
InfrastructureSystems.Optimization.read_dual — Method
read_dual(
+

Return the values for the requested auxillary variables. It keeps requests when performing multiple retrievals.

Arguments

  • args: Can be a string returned from list_aux_variable_names or args that can be splatted into a AuxVarKey.
  • initial_time::Dates.DateTime : initial of the requested results
  • count::Int: Number of results
source
InfrastructureSystems.Optimization.read_dual — Method
read_dual(
     res::PowerSimulations.SimulationProblemResults{PowerSimulations.DecisionModelSimulationResults},
     args...;
     initial_time,
     count,
     store
 ) -> SortedDict{Any, Any, Base.Order.ForwardOrdering}
-

Return the values for the requested dual. It keeps requests when performing multiple retrievals.

Arguments

  • args: Can be a string returned from list_dual_names or args that can be splatted into a ConstraintKey.
  • initial_time::Dates.DateTime : initial of the requested results
  • count::Int: Number of results
  • store::SimulationStore: a store that has been opened for reading
source
InfrastructureSystems.Optimization.read_expression — Method
read_expression(
+

Return the values for the requested dual. It keeps requests when performing multiple retrievals.

Arguments

  • args: Can be a string returned from list_dual_names or args that can be splatted into a ConstraintKey.
  • initial_time::Dates.DateTime : initial of the requested results
  • count::Int: Number of results
  • store::SimulationStore: a store that has been opened for reading
source
InfrastructureSystems.Optimization.read_expression — Method
read_expression(
     res::PowerSimulations.SimulationProblemResults{PowerSimulations.DecisionModelSimulationResults},
     args...;
     initial_time,
     count,
     store
 ) -> SortedDict{Any, Any, Base.Order.ForwardOrdering}
-

Return the values for the requested auxillary variables. It keeps requests when performing multiple retrievals.

Arguments

  • args: Can be a string returned from list_expression_names or args that can be splatted into a ExpressionKey.
  • initial_time::Dates.DateTime : initial of the requested results
  • count::Int: Number of results
source
InfrastructureSystems.Optimization.read_parameter — Method
read_parameter(
+

Return the values for the requested auxillary variables. It keeps requests when performing multiple retrievals.

Arguments

  • args: Can be a string returned from list_expression_names or args that can be splatted into a ExpressionKey.
  • initial_time::Dates.DateTime : initial of the requested results
  • count::Int: Number of results
source
InfrastructureSystems.Optimization.read_parameter — Method
read_parameter(
     res::PowerSimulations.SimulationProblemResults{PowerSimulations.DecisionModelSimulationResults},
     args...;
     initial_time,
     count,
     store
 ) -> SortedDict{Any, Any, Base.Order.ForwardOrdering}
-

Return the values for the requested parameter. It keeps requests when performing multiple retrievals.

Arguments

  • args: Can be a string returned from list_parameter_names or args that can be splatted into a ParameterKey.
  • initial_time::Dates.DateTime : initial of the requested results
  • count::Int: Number of results
source
InfrastructureSystems.Optimization.read_variable — Method
read_variable(
+

Return the values for the requested parameter. It keeps requests when performing multiple retrievals.

Arguments

  • args: Can be a string returned from list_parameter_names or args that can be splatted into a ParameterKey.
  • initial_time::Dates.DateTime : initial of the requested results
  • count::Int: Number of results
source
InfrastructureSystems.Optimization.read_variable — Method
read_variable(
     res::PowerSimulations.SimulationProblemResults{PowerSimulations.DecisionModelSimulationResults},
     args...;
     initial_time,
@@ -373,10 +373,10 @@
     store
 ) -> SortedDict{Any, Any, Base.Order.ForwardOrdering}

Return the values for the requested variable. It keeps requests when performing multiple retrievals.

Arguments

  • args: Can be a string returned from list_variable_names or args that can be splatted into a VariableKey.
  • initial_time::Dates.DateTime : initial of the requested results
  • count::Int: Number of results
  • store::SimulationStore: a store that has been opened for reading

Examples

read_variable(results, ActivePowerVariable, ThermalStandard)
-read_variable(results, "ActivePowerVariable__ThermalStandard")
source
PowerSimulations.load_results! — Method
load_results!(
     res::PowerSimulations.SimulationProblemResults{PowerSimulations.DecisionModelSimulationResults},
     count::Int64;
     initial_time,
@@ -387,7 +387,7 @@
     expressions,
     store
 )
-

Load the simulation results into memory for repeated reads. This is useful when loading results from remote locations over network connections, when reading the same data very many times, etc. Multiple calls augment the cache according to these rules, where "variable" means "variable, expression, etc.":

  • Requests for an already cached variable at a lesser count than already cached do not decrease the count of the cached variable
  • Requests for an already cached variable at a greater count than already cached do increase the count of the cached variable
  • Requests for new variables are fulfilled without evicting existing variables

Note that count is global across all variables, so increasing the count re-reads already cached variables. For each variable, each element must be the name encoded as a string, like "ActivePowerVariable__ThermalStandard" or a Tuple with its constituent types, like (ActivePowerVariable, ThermalStandard). To clear the cache, use Base.empty!.

Arguments

  • count::Int: Number of windows to load.
  • initial_time::Dates.DateTime : Initial time of first window to load. Defaults to first.
  • aux_variables::Vector{Union{String, Tuple}}: Optional list of aux variables to load.
  • duals::Vector{Union{String, Tuple}}: Optional list of duals to load.
  • expressions::Vector{Union{String, Tuple}}: Optional list of expressions to load.
  • parameters::Vector{Union{String, Tuple}}: Optional list of parameters to load.
  • variables::Vector{Union{String, Tuple}}: Optional list of variables to load.
source
PowerSimulations.load_results! — Method
load_results!(
+

Load the simulation results into memory for repeated reads. This is useful when loading results from remote locations over network connections, when reading the same data very many times, etc. Multiple calls augment the cache according to these rules, where "variable" means "variable, expression, etc.":

  • Requests for an already cached variable at a lesser count than already cached do not decrease the count of the cached variable
  • Requests for an already cached variable at a greater count than already cached do increase the count of the cached variable
  • Requests for new variables are fulfilled without evicting existing variables

Note that count is global across all variables, so increasing the count re-reads already cached variables. For each variable, each element must be the name encoded as a string, like "ActivePowerVariable__ThermalStandard" or a Tuple with its constituent types, like (ActivePowerVariable, ThermalStandard). To clear the cache, use Base.empty!.

Arguments

  • count::Int: Number of windows to load.
  • initial_time::Dates.DateTime : Initial time of first window to load. Defaults to first.
  • aux_variables::Vector{Union{String, Tuple}}: Optional list of aux variables to load.
  • duals::Vector{Union{String, Tuple}}: Optional list of duals to load.
  • expressions::Vector{Union{String, Tuple}}: Optional list of expressions to load.
  • parameters::Vector{Union{String, Tuple}}: Optional list of parameters to load.
  • variables::Vector{Union{String, Tuple}}: Optional list of variables to load.
source
PowerSimulations.load_results! — Method
load_results!(
     res::PowerSimulations.SimulationProblemResults{PowerSimulations.EmulationModelSimulationResults};
     aux_variables,
     duals,
@@ -395,75 +395,75 @@
     parameters,
     variables
 )
-

Load the simulation results into memory for repeated reads. This is useful when loading results from remote locations over network connections.

For each variable/parameter/dual, etc., each element must be the name encoded as a string, like "ActivePowerVariable__ThermalStandard"or a Tuple with its constituent types, like(ActivePowerVariable, ThermalStandard)`.

Arguments

  • aux_variables::Vector{Union{String, Tuple}}: Optional list of aux variables to load.
  • duals::Vector{Union{String, Tuple}}: Optional list of duals to load.
  • expressions::Vector{Union{String, Tuple}}: Optional list of expressions to load.
  • parameters::Vector{Union{String, Tuple}}: Optional list of parameters to load.
  • variables::Vector{Union{String, Tuple}}: Optional list of variables to load.
source
InfrastructureSystems.Optimization.get_timestamps — Method
get_timestamps(
+

Load the simulation results into memory for repeated reads. This is useful when loading results from remote locations over network connections.

For each variable/parameter/dual, etc., each element must be the name encoded as a string, like "ActivePowerVariable__ThermalStandard"or a Tuple with its constituent types, like(ActivePowerVariable, ThermalStandard)`.

Arguments

  • aux_variables::Vector{Union{String, Tuple}}: Optional list of aux variables to load.
  • duals::Vector{Union{String, Tuple}}: Optional list of duals to load.
  • expressions::Vector{Union{String, Tuple}}: Optional list of expressions to load.
  • parameters::Vector{Union{String, Tuple}}: Optional list of parameters to load.
  • variables::Vector{Union{String, Tuple}}: Optional list of variables to load.
source
PowerSimulations.get_system! — Method
get_system!(
+

Return the optimizer stats for the problem as a DataFrame.

Accepted keywords

  • store::SimulationStore: a store that has been opened for reading
source
PowerSimulations.get_system! — Method
get_system!(
     results::Union{OptimizationProblemResults, PowerSimulations.SimulationProblemResults};
     kwargs...
 ) -> Union{Nothing, InfrastructureSystems.InfrastructureSystemsType}
-

Return the system used for the problem. If the system hasn't already been deserialized or set with set_system! then deserialize and store it.

If the simulation was configured to serialize all systems to file then the returned system will include all data. If that was not configured then the returned system will include all data except time series data.

source
PowerSimulations.read_realized_aux_variable — Method
read_realized_aux_variable(
+

Return the system used for the problem. If the system hasn't already been deserialized or set with set_system! then deserialize and store it.

If the simulation was configured to serialize all systems to file then the returned system will include all data. If that was not configured then the returned system will include all data except time series data.

source
PowerSimulations.read_realized_variable — Method
read_realized_variable(
     res::PowerSimulations.SimulationProblemResults,
     variable::AbstractString;
     kwargs...
 ) -> Any

Return the final values for the requested variable for each time step for a problem.

Decision problem results are returned in a Dict{DateTime, DataFrame}.

Emulation problem results are returned in a DataFrame.

Limit the data sizes returned by specifying initial_time and count for decision problems or start_time and len for emulation problems.

See also load_results! to preload data into memory.

Arguments

  • variable::Union{String, Tuple}: Variable name as a string or a Tuple with variable type and device type.
  • initial_time::Dates.DateTime: Initial time of the requested results. Decision problems only.
  • count::Int: Number of results. Decision problems only.
  • start_time::Dates.DateTime: Start time of the requested results. Emulation problems only.
  • len::Int: Number of rows in each DataFrame. Emulation problems only.

Examples

julia > read_realized_variable(results, "ActivePowerVariable__ThermalStandard")
-julia > read_realized_variable(results, (ActivePowerVariable, ThermalStandard))
source
PowerSimulations.read_realized_variables — Method
read_realized_variables(
     res::PowerSimulations.SimulationProblemResults;
     kwargs...
 ) -> Dict
@@ -472,21 +472,21 @@
 julia > variables_as_types =
     [(ActivePowerVariable, ThermalStandard), (ActivePowerVariable, RenewableDispatch)]
 julia > read_realized_variables(results, variables_as_strings)
-julia > read_realized_variables(results, variables_as_types)
source
PowerSimulations.set_system! — Method
set_system!(
     results::PowerSimulations.SimulationProblemResults,
     system::AbstractString
 )
-

Set the system in the results instance.

Throws InvalidValue if the system UUID is incorrect.

Arguments

  • results::SimulationProblemResults: Results object
  • system::AbstractString: Path to the system json file

Examples

julia > set_system!(res, "my_path/system_data.json")
source
InfrastructureSystems.Optimization.read_optimizer_stats — Method
read_optimizer_stats(
+

Set the system in the results instance.

Throws InvalidValue if the system UUID is incorrect.

Arguments

  • results::SimulationProblemResults: Results object
  • system::AbstractString: Path to the system json file

Examples

julia > set_system!(res, "my_path/system_data.json")
source

Simulation Recorder

Simulation Recorder

PowerSimulations.list_simulation_events — Method
list_simulation_events(
     ::Type{T<:InfrastructureSystems.AbstractRecorderEvent},
     output_dir::AbstractString;
     ...
@@ -504,7 +504,7 @@
     filter_func::Union{Nothing, Function} = nothing;
     step = nothing,
     model = nothing,
-) where {T <: IS.AbstractRecorderEvent}

List simulation events of type T in a simulation output directory.

Arguments

  • output_dir::AbstractString: Simulation output directory
  • filter_func::Union{Nothing, Function} = nothing: Refer to show_simulation_events.
  • step::Int = nothing: Filter events by step. Required if model is passed.
  • model::Int = nothing: Filter events by model.
source
PowerSimulations.show_recorder_events — Method
show_recorder_events(
+) where {T <: IS.AbstractRecorderEvent}

List simulation events of type T in a simulation output directory.

Arguments

  • output_dir::AbstractString: Simulation output directory
  • filter_func::Union{Nothing, Function} = nothing: Refer to show_simulation_events.
  • step::Int = nothing: Filter events by step. Required if model is passed.
  • model::Int = nothing: Filter events by model.
source
PowerSimulations.show_recorder_events — Method
show_recorder_events(
     ::Type{T<:InfrastructureSystems.AbstractRecorderEvent},
     filename::AbstractString;
     ...
@@ -522,7 +522,7 @@
     filter_func::Union{Nothing, Function} = nothing;
     wall_time = false,
     kwargs...,
-) where {T <: IS.AbstractRecorderEvent}

Show the events of type T in a recorder file.

Arguments

  • ::Type{T}: Recorder event type
  • filename::AbstractString: recorder filename
  • filter_func::Union{Nothing, Function} = nothing: Optional function that accepts an event of type T and returns a Bool. Apply this function to each event and only return events where the result is true.
  • wall_time = false: If true, show the wall_time timestamp.
source
PowerSimulations.show_simulation_events — Method
show_simulation_events(
+) where {T <: IS.AbstractRecorderEvent}

Show the events of type T in a recorder file.

Arguments

  • ::Type{T}: Recorder event type
  • filename::AbstractString: recorder filename
  • filter_func::Union{Nothing, Function} = nothing: Optional function that accepts an event of type T and returns a Bool. Apply this function to each event and only return events where the result is true.
  • wall_time = false: If true, show the wall_time timestamp.
source
PowerSimulations.show_simulation_events — Method
show_simulation_events(
     ::Type{T<:InfrastructureSystems.AbstractRecorderEvent},
     output_dir::AbstractString;
     ...
@@ -544,4 +544,4 @@
     model = nothing,
     wall_time = false,
     kwargs...,
-) where { T <: IS.AbstractRecorderEvent}

Show all simulation events of type T in a simulation output directory.

Arguments

  • ::Type{T}: Recorder event type
  • output_dir::AbstractString: Simulation output directory
  • filter_func::Union{Nothing, Function} = nothing: Refer to show_recorder_events.
  • step::Int = nothing: Filter events by step. Required if model is passed.
  • model::Int = nothing: Filter events by model.
  • wall_time = false: If true, show the wall_time timestamp.
source
+) where { T <: IS.AbstractRecorderEvent}

Show all simulation events of type T in a simulation output directory.

Arguments

source diff --git a/dev/code_base_developer_guide/developer/index.html b/dev/code_base_developer_guide/developer/index.html index 0ad62c84c..8f18970dc 100644 --- a/dev/code_base_developer_guide/developer/index.html +++ b/dev/code_base_developer_guide/developer/index.html @@ -1,2 +1,2 @@ -Developer Guide · PowerSimulations.jl
GitHub
+Developer Guide · PowerSimulations.jl
GitHub
diff --git a/dev/code_base_developer_guide/extending_powersimulations/index.html b/dev/code_base_developer_guide/extending_powersimulations/index.html index 154ce8c0c..1a3d15316 100644 --- a/dev/code_base_developer_guide/extending_powersimulations/index.html +++ b/dev/code_base_developer_guide/extending_powersimulations/index.html @@ -33,4 +33,4 @@ │ 2020-04-07T15:08:32.711 │ InitialConditionUpdateEvent │ 2024-01-02T00:00:00 │ DeviceStatus │ ThermalStandard │ Alta │ 1.0 │ 1 │ │ 2020-04-07T15:08:32.711 │ InitialConditionUpdateEvent │ 2024-01-02T00:00:00 │ DeviceStatus │ ThermalStandard │ Brighton │ 1.0 │ 1 │ │ 2020-04-07T15:08:32.711 │ InitialConditionUpdateEvent │ 2024-01-02T00:00:00 │ DeviceStatus │ ThermalStandard │ Sundance │ 0.0 │ 1 │ -└─────────────────────────┴─────────────────────────────┴─────────────────────┴────────────────────────┴─────────────────┴─────────────┴─────┴──────────────┘ +└─────────────────────────┴─────────────────────────────┴─────────────────────┴────────────────────────┴─────────────────┴─────────────┴─────┴──────────────┘ diff --git a/dev/code_base_developer_guide/internal/index.html b/dev/code_base_developer_guide/internal/index.html index 17d1be529..71ffea1b1 100644 --- a/dev/code_base_developer_guide/internal/index.html +++ b/dev/code_base_developer_guide/internal/index.html @@ -1,16 +1,16 @@ -Internals · PowerSimulations.jl
GitHub

Internal API

PowerSimulations.OperationModel — Type

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

source
InfrastructureSystems.Optimization.read_results_with_keys — Method
read_results_with_keys(
+Internals · PowerSimulations.jl
GitHub
Internal API
PowerSimulations.OperationModel — Type
Abstract type for Decision Model and Emulation Model. OperationModel structs are parameterized with DecisionProblem or Emulation Problem structs
source
InfrastructureSystems.Optimization.read_results_with_keys — Method
read_results_with_keys(
     res::PowerSimulations.SimulationProblemResults{PowerSimulations.DecisionModelSimulationResults},
     result_keys::Vector{<:InfrastructureSystems.Optimization.OptimizationContainerKey};
     start_time,
     len,
     cols
 ) -> Dict{InfrastructureSystems.Optimization.OptimizationContainerKey, DataFrames.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
source
PowerSimulations._add_pwl_constraint! — Method
_add_pwl_constraint!(
+
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
source
PowerSimulations._add_pwl_constraint! — Method
_add_pwl_constraint!(
     container::PowerSimulations.OptimizationContainer,
     component::Component,
     _::InfrastructureSystems.Optimization.VariableType,
@@ -18,7 +18,7 @@
     period::Int64
 )
 
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}\]
source
PowerSimulations._add_pwl_constraint! — Method
_add_pwl_constraint!(
     container::PowerSimulations.OptimizationContainer,
     component::Component,
     _::InfrastructureSystems.Optimization.VariableType,
@@ -27,7 +27,7 @@
     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\]
source
PowerSimulations._add_pwl_constraint! — Method
_add_pwl_constraint!(
     container::PowerSimulations.OptimizationContainer,
     component::Component,
     _::PowerAboveMinimumVariable,
@@ -36,7 +36,7 @@
     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\]
source
PowerSimulations._add_pwl_constraint! — Method
_add_pwl_constraint!(
     container::PowerSimulations.OptimizationContainer,
     component::ReserveDemandCurve,
     _::ServiceRequirementVariable,
@@ -45,7 +45,7 @@
     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}\]
source
PowerSimulations._add_pwl_sos_constraint! — Method
_add_pwl_sos_constraint!(
     container::PowerSimulations.OptimizationContainer,
     component::Component,
     _::InfrastructureSystems.Optimization.VariableType,
@@ -53,7 +53,7 @@
     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\]
source
PowerSimulations._add_pwl_term! — Method
_add_pwl_term!(
     container::PowerSimulations.OptimizationContainer,
     component::Component,
     cost_function::MarketBidCost,
@@ -61,220 +61,220 @@
     _::InfrastructureSystems.Optimization.VariableType,
     _::PowerSimulations.AbstractDeviceFormulation
 ) -> Vector{JuMP.AffExpr}
-
Add PWL cost terms for data coming from the MarketBidCost with a fixed incremental offer curve
source
PowerSimulations._add_pwl_term! — Method
_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
source
PowerSimulations._add_pwl_term! — Method
_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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_add_variable_cost_to_objective!(
+
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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_add_variable_cost_to_objective!(
+
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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_add_variable_cost_to_objective!(
+
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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_add_variable_cost_to_objective!(
+
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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_add_variable_cost_to_objective!(
     container::PowerSimulations.OptimizationContainer,
     _::InfrastructureSystems.Optimization.VariableType,
     component::Component,
     cost_function::MarketBidCost,
     _::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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_add_variable_cost_to_objective!(
+
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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_add_variable_cost_to_objective!(
     container::PowerSimulations.OptimizationContainer,
     _::InfrastructureSystems.Optimization.VariableType,
     component::Component,
     cost_function::Union{CostCurve{PiecewisePointCurve}, 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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_add_variable_cost_to_objective!(
+
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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_add_variable_cost_to_objective!(
+
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
source
PowerSimulations._add_variable_cost_to_objective! — Method
_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
source
PowerSimulations._allocate_execution_order — Method
_allocate_execution_order(
+
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
source
PowerSimulations._allocate_execution_order — Method
_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
source
PowerSimulations._calculate_interval_inner_counts — Method
_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
source
PowerSimulations._create_time_series_multiplier_index — Method
_create_time_series_multiplier_index(
     model,
     _::Type{T<:InfrastructureSystems.Optimization.TimeSeriesParameter}
 ) -> Union{Nothing, Int64}
-
Function to create a unique index of time series names for each device model. For example, if two parameters each reference the same time series name, this function will return a different value for each parameter entry
source
PowerSimulations._get_data_for_tdc — Method
_get_data_for_tdc(
+
Function to create a unique index of time series names for each device model. For example, if two parameters each reference the same time series name, this function will return a different value for each parameter entry
source
PowerSimulations._get_data_for_tdc — Method
_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.
source
PowerSimulations._get_initial_condition_type — Method
_get_initial_condition_type(
+
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.
source
PowerSimulations._get_initial_condition_type — Method
_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
source
PowerSimulations._get_pwl_cost_expression — Method
_get_pwl_cost_expression(
     container::PowerSimulations.OptimizationContainer,
     component::ReserveDemandCurve,
     time_period::Int64,
     cost_data::PiecewiseStepData,
     multiplier::Float64
 ) -> JuMP.AffExpr
-
Get cost expression for StepwiseCostReserve
source
PowerSimulations.add_constraints! — Method
add_constraints!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{NetworkFlowConstraint},
     devices::InfrastructureSystems.FlattenIteratorWrapper{B<:ACBranch},
     model::DeviceModel{B<:ACBranch, <:PowerSimulations.AbstractBranchFormulation},
     network_model::NetworkModel{<:PowerSimulations.AbstractPTDFModel}
 )
-
Add network flow constraints for ACBranch and NetworkModel with <: AbstractPTDFModel
source
PowerSimulations.add_constraints! — Method
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
source
PowerSimulations.add_constraints! — Method
add_constraints!(
     container::PowerSimulations.OptimizationContainer,
     cons_type::Type{RateLimitConstraintFromTo},
     devices::InfrastructureSystems.FlattenIteratorWrapper{B<:ACBranch},
     device_model::DeviceModel{B<:ACBranch, <:PowerSimulations.AbstractBranchFormulation},
     network_model::NetworkModel{T<:PowerModels.AbstractPowerModel}
 )
-
Add rate limit from to constraints for ACBranch with AbstractPowerModel
source
PowerSimulations.add_constraints! — Method
add_constraints!(
     container::PowerSimulations.OptimizationContainer,
     cons_type::Type{RateLimitConstraintToFrom},
     devices::InfrastructureSystems.FlattenIteratorWrapper{B<:ACBranch},
     _::DeviceModel{B<:ACBranch, <:PowerSimulations.AbstractBranchFormulation},
     network_model::NetworkModel{T<:PowerModels.AbstractPowerModel}
 )
-
Add rate limit to from constraints for ACBranch with AbstractPowerModel
source
PowerSimulations.add_constraints! — Method
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
source
PowerSimulations.add_constraints! — Method
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
source
PowerSimulations.add_constraints! — Method
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
source
PowerSimulations.add_constraints! — Method
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)$
source
PowerSimulations.add_constraints! — Method
add_constraints!(
+
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)$
source
PowerSimulations.add_constraints! — Method
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}$
source
PowerSimulations.add_constraints! — Method
add_constraints!(
+
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}$
source
PowerSimulations.add_constraints! — Method
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)$
source
PowerSimulations.add_constraints! — Method
add_constraints!(
+
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)$
source
PowerSimulations.add_constraints! — Method
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
source
PowerSimulations.add_constraints! — Method
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
source
PowerSimulations.add_constraints! — Method
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
source
PowerSimulations.add_constraints! — Method
add_constraints!(
     _::PowerSimulations.OptimizationContainer,
     _::Type{RateLimitConstraintFromTo},
     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
source
PowerSimulations.add_constraints! — Method
add_constraints!(
     container::PowerSimulations.OptimizationContainer,
     cons_type::Type{RateLimitConstraint},
     devices::InfrastructureSystems.FlattenIteratorWrapper{T<:ACBranch},
     device_model::DeviceModel{T<:ACBranch, U<:PowerSimulations.AbstractBranchFormulation},
     network_model::NetworkModel{V<:PowerModels.AbstractActivePowerModel}
 )
-
Add branch rate limit constraints for ACBranch with AbstractActivePowerModel
source
PowerSimulations.add_constraints! — Method
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
source
PowerSimulations.add_constraints! — Method
add_constraints!(
     container::PowerSimulations.OptimizationContainer,
     T::Type{<:ActivePowerVariableLimitsConstraint},
     U::Type{<:InfrastructureSystems.Optimization.VariableType},
@@ -282,7 +282,7 @@
     _::DeviceModel{V<:ThermalMultiStart, W<:ThermalMultiStartUnitCommitment},
     _::NetworkModel{X<:PowerModels.AbstractPowerModel}
 )
-
This function adds range constraint for the first time period. Constraint (10) from PGLIB formulation
source
PowerSimulations.add_constraints! — Method
add_constraints!(
     container::PowerSimulations.OptimizationContainer,
     T::Type{<:PowerSimulations.PowerVariableLimitsConstraint},
     U::Type{<:Union{InfrastructureSystems.Optimization.ExpressionType, InfrastructureSystems.Optimization.VariableType}},
@@ -290,7 +290,7 @@
     model::DeviceModel{V<:ThermalGen, W<:PowerSimulations.AbstractThermalDispatchFormulation},
     _::NetworkModel{X<:PowerModels.AbstractPowerModel}
 )
-
Semicontinuous range constraints for thermal dispatch formulations
source
PowerSimulations.add_constraints! — Method
add_constraints!(
     container::PowerSimulations.OptimizationContainer,
     T::Type{<:PowerSimulations.PowerVariableLimitsConstraint},
     U::Type{<:Union{InfrastructureSystems.Optimization.ExpressionType, InfrastructureSystems.Optimization.VariableType}},
@@ -298,7 +298,7 @@
     model::DeviceModel{V<:ThermalGen, W<:PowerSimulations.AbstractThermalUnitCommitment},
     _::NetworkModel{X<:PowerModels.AbstractPowerModel}
 )
-
Semicontinuous range constraints for unit commitment formulations
source
PowerSimulations.add_constraints! — Method
add_constraints!(
     container::PowerSimulations.OptimizationContainer,
     T::Type{<:PowerSimulations.PowerVariableLimitsConstraint},
     U::Type{<:Union{PowerAboveMinimumVariable, InfrastructureSystems.Optimization.ExpressionType}},
@@ -306,7 +306,7 @@
     model::DeviceModel{V<:ThermalGen, W<:ThermalCompactDispatch},
     network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
 )
-
Range constraints for thermal compact dispatch
source
PowerSimulations.add_constraints! — Method
add_constraints!(
     container::PowerSimulations.OptimizationContainer,
     T::Type{<:ReactivePowerVariableLimitsConstraint},
     U::Type{<:ReactivePowerVariable},
@@ -314,7 +314,7 @@
     _::DeviceModel{V<:ElectricLoad, W<:PowerSimulations.AbstractControllablePowerLoadFormulation},
     network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
 )
-
Reactive Power Constraints on Controllable Loads Assume Constant power_factor
source
PowerSimulations.add_constraints! — Method
add_constraints!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{<:ReactivePowerVariableLimitsConstraint},
     _::Type{<:ReactivePowerVariable},
@@ -322,7 +322,7 @@
     _::DeviceModel{V<:RenewableGen, W<:RenewableConstantPowerFactor},
     _::NetworkModel{X<:PowerModels.AbstractPowerModel}
 )
-
Reactive Power Constraints on Renewable Gen Constant power_factor
source
PowerSimulations.add_feedforward_constraints! — Method
add_feedforward_constraints!(
     container::PowerSimulations.OptimizationContainer,
     _::DeviceModel,
     devices::InfrastructureSystems.FlattenIteratorWrapper{T<:Component},
@@ -332,7 +332,7 @@
           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
source
PowerSimulations.add_feedforward_constraints! — Method
add_feedforward_constraints!(
+          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
source
PowerSimulations.add_feedforward_constraints! — Method
add_feedforward_constraints!(
     container::PowerSimulations.OptimizationContainer,
     _::DeviceModel,
     devices::Union{Array{T<:Component, 1}, InfrastructureSystems.FlattenIteratorWrapper{T<:Component}},
@@ -343,7 +343,7 @@
         ::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
source
PowerSimulations.add_feedforward_constraints! — Method
add_feedforward_constraints!(
+    ) 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
source
PowerSimulations.add_feedforward_constraints! — Method
add_feedforward_constraints!(
     container::PowerSimulations.OptimizationContainer,
     _::DeviceModel{T<:Component, U<:PowerSimulations.AbstractDeviceFormulation},
     devices::InfrastructureSystems.FlattenIteratorWrapper{T<:Component},
@@ -353,7 +353,7 @@
           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
source
PowerSimulations.add_linear_ramp_constraints! — Method
add_linear_ramp_constraints!(
+          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
source
PowerSimulations.add_linear_ramp_constraints! — Method
add_linear_ramp_constraints!(
     container::PowerSimulations.OptimizationContainer,
     T::Type{<:InfrastructureSystems.Optimization.ConstraintType},
     U::Type{S<:Union{ActivePowerVariable, PowerAboveMinimumVariable}},
@@ -361,7 +361,7 @@
     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$
source
PowerSimulations.add_range_constraints! — Method
add_range_constraints!(
+
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$
source
PowerSimulations.add_range_constraints! — Method
add_range_constraints!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:InfrastructureSystems.Optimization.ConstraintType},
     _::Type{U<:InfrastructureSystems.Optimization.VariableType},
@@ -369,7 +369,7 @@
     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 }$
source
PowerSimulations.add_reserve_range_constraints! — Method
add_reserve_range_constraints!(
+
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 }$
source
PowerSimulations.add_reserve_range_constraints! — Method
add_reserve_range_constraints!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:InputActivePowerVariableLimitsConstraint},
     _::Type{U<:InfrastructureSystems.Optimization.VariableType},
@@ -377,7 +377,7 @@
     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 }$
source
PowerSimulations.add_reserve_range_constraints! — Method
add_reserve_range_constraints!(
+
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 }$
source
PowerSimulations.add_reserve_range_constraints! — Method
add_reserve_range_constraints!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:Union{OutputActivePowerVariableLimitsConstraint, ReactivePowerVariableLimitsConstraint}},
     _::Type{U<:InfrastructureSystems.Optimization.ExpressionType},
@@ -385,7 +385,7 @@
     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},$
source
PowerSimulations.add_reserve_range_constraints! — Method
add_reserve_range_constraints!(
+
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},$
source
PowerSimulations.add_reserve_range_constraints! — Method
add_reserve_range_constraints!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:Union{OutputActivePowerVariableLimitsConstraint, ReactivePowerVariableLimitsConstraint}},
     _::Type{U<:InfrastructureSystems.Optimization.VariableType},
@@ -393,13 +393,13 @@
     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},$
source
PowerSimulations.add_result! — Method
add_result!(
+
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},$
source
PowerSimulations.add_result! — Method
add_result!(
     cache::PowerSimulations.OptimizationOutputCache,
     timestamp::Dates.DateTime,
     array::Array{Float64},
     system_cache_is_full::Bool
 ) -> Int64
-
Add result to the cache.
source
PowerSimulations.add_semicontinuous_ramp_constraints! — Method
add_semicontinuous_ramp_constraints!(
     container::PowerSimulations.OptimizationContainer,
     T::Type{<:InfrastructureSystems.Optimization.ConstraintType},
     U::Type{S<:Union{ActivePowerVariable, PowerAboveMinimumVariable}},
@@ -407,7 +407,7 @@
     _::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$
source
PowerSimulations.add_semicontinuous_range_constraints! — Method
add_semicontinuous_range_constraints!(
+
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$
source
PowerSimulations.add_semicontinuous_range_constraints! — Method
add_semicontinuous_range_constraints!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:InfrastructureSystems.Optimization.ConstraintType},
     _::Type{U<:InfrastructureSystems.Optimization.VariableType},
@@ -415,7 +415,7 @@
     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 }$
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
+
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 }$
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:PhaseShifterAngle},
@@ -423,7 +423,7 @@
     _::DeviceModel{PhaseShiftingTransformer, V<:PhaseAngleControl},
     network_model::NetworkModel{<:PowerSimulations.AbstractPTDFModel}
 )
-
Implementation of addtoexpression! for lossless branch/network models
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:FlowActivePowerVariable},
@@ -431,7 +431,7 @@
     _::DeviceModel{V<:ACBranch, W<:PowerSimulations.AbstractBranchFormulation},
     network_model::NetworkModel{CopperPlatePowerModel}
 )
-
Implementation of addtoexpression! for lossless branch/network models
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:InfrastructureSystems.Optimization.VariableType},
@@ -439,7 +439,7 @@
     device_model::DeviceModel{V<:StaticInjection, W<:PowerSimulations.AbstractDeviceFormulation},
     network_model::NetworkModel{CopperPlatePowerModel}
 )
-
Default implementation to add variables to SystemBalanceExpressions
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:FlowActivePowerToFromVariable},
@@ -447,7 +447,7 @@
     _::DeviceModel{V<:Union{TwoTerminalHVDCLine, TwoTerminalVSCDCLine}, W<:PowerSimulations.AbstractTwoTerminalDCLineFormulation},
     network_model::NetworkModel{PTDFPowerModel}
 )
-
Default implementation to add branch variables to SystemBalanceExpressions
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:FlowActivePowerVariable},
@@ -455,7 +455,7 @@
     _::DeviceModel{V<:ACBranch, W<:PowerSimulations.AbstractBranchFormulation},
     network_model::NetworkModel{PTDFPowerModel}
 )
-
Implementation of addtoexpression! for lossless branch/network models
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:InfrastructureSystems.Optimization.VariableType},
@@ -463,7 +463,7 @@
     device_model::DeviceModel{V<:StaticInjection, W<:PowerSimulations.AbstractDeviceFormulation},
     network_model::NetworkModel{PTDFPowerModel}
 )
-
Default implementation to add variables to SystemBalanceExpressions
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:FlowActivePowerFromToVariable},
@@ -471,7 +471,7 @@
     _::DeviceModel{V<:Branch, W<:PowerSimulations.AbstractDeviceFormulation},
     network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
 )
-
Default implementation to add branch variables to SystemBalanceExpressions
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:FlowActivePowerFromToVariable},
@@ -479,7 +479,7 @@
     _::DeviceModel{V<:Union{TwoTerminalHVDCLine, TwoTerminalVSCDCLine}, W<:PowerSimulations.AbstractTwoTerminalDCLineFormulation},
     network_model::NetworkModel{X<:CopperPlatePowerModel}
 )
-
Default implementation to add branch variables to SystemBalanceExpressions
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:FlowActivePowerFromToVariable},
@@ -487,7 +487,7 @@
     _::DeviceModel{V<:Union{TwoTerminalHVDCLine, TwoTerminalVSCDCLine}, W<:PowerSimulations.AbstractTwoTerminalDCLineFormulation},
     network_model::NetworkModel{X<:PowerSimulations.AbstractPTDFModel}
 )
-
Default implementation to add branch variables to SystemBalanceExpressions
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:FlowActivePowerToFromVariable},
@@ -495,7 +495,7 @@
     _::DeviceModel{V<:ACBranch, W<:PowerSimulations.AbstractDeviceFormulation},
     network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
 )
-
Default implementation to add branch variables to SystemBalanceExpressions
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:FlowActivePowerToFromVariable},
@@ -503,7 +503,7 @@
     _::DeviceModel{V<:Union{TwoTerminalHVDCLine, TwoTerminalVSCDCLine}, W<:PowerSimulations.AbstractTwoTerminalDCLineFormulation},
     network_model::NetworkModel{X<:CopperPlatePowerModel}
 )
-
Default implementation to add branch variables to SystemBalanceExpressions
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:FlowActivePowerVariable},
@@ -511,7 +511,7 @@
     _::DeviceModel{V<:ACBranch, W<:PowerSimulations.AbstractBranchFormulation},
     network_model::NetworkModel{X<:PowerModels.AbstractActivePowerModel}
 )
-
Implementation of addtoexpression! for lossless branch/network models
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:HVDCLosses},
@@ -519,7 +519,7 @@
     _::DeviceModel{V<:Union{TwoTerminalHVDCLine, TwoTerminalVSCDCLine}, W<:HVDCTwoTerminalDispatch},
     network_model::NetworkModel{X<:Union{CopperPlatePowerModel, PTDFPowerModel}}
 )
-
Default implementation to add branch variables to SystemBalanceExpressions
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:PowerSimulations.HVDCActivePowerReceivedFromVariable},
@@ -527,7 +527,7 @@
     _::DeviceModel{V<:Union{TwoTerminalHVDCLine, TwoTerminalVSCDCLine}, W<:PowerSimulations.HVDCTwoTerminalPiecewiseLoss},
     network_model::NetworkModel{X<:PowerSimulations.AbstractPTDFModel}
 )
-
PWL implementation to add FromTo branch variables to SystemBalanceExpressions
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:ActivePowerBalance},
     _::Type{U<:PowerSimulations.HVDCActivePowerReceivedToVariable},
@@ -535,7 +535,7 @@
     _::DeviceModel{V<:Union{TwoTerminalHVDCLine, TwoTerminalVSCDCLine}, W<:PowerSimulations.HVDCTwoTerminalPiecewiseLoss},
     network_model::NetworkModel{X<:PowerSimulations.AbstractPTDFModel}
 )
-
PWL implementation to add FromTo branch variables to SystemBalanceExpressions
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:SystemBalanceExpressions},
     _::Type{U<:InfrastructureSystems.Optimization.TimeSeriesParameter},
@@ -543,7 +543,7 @@
     model::DeviceModel{V<:Device, W<:PowerSimulations.AbstractDeviceFormulation},
     network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
 )
-
Default implementation to add parameters to SystemBalanceExpressions
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:SystemBalanceExpressions},
     _::Type{U<:InfrastructureSystems.Optimization.TimeSeriesParameter},
@@ -551,7 +551,7 @@
     device_model::DeviceModel{V<:StaticInjection, W<:PowerSimulations.AbstractDeviceFormulation},
     network_model::NetworkModel{X<:CopperPlatePowerModel}
 )
-
Default implementation to add parameters to SystemBalanceExpressions
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:SystemBalanceExpressions},
     _::Type{U<:InfrastructureSystems.Optimization.TimeSeriesParameter},
@@ -559,7 +559,7 @@
     device_model::DeviceModel{V<:StaticInjection, W<:PowerSimulations.AbstractDeviceFormulation},
     network_model::NetworkModel{X<:PowerSimulations.AbstractPTDFModel}
 )
-
Default implementation to add parameters to SystemBalanceExpressions
source
PowerSimulations.add_to_expression! — Method
add_to_expression!(
     container::PowerSimulations.OptimizationContainer,
     _::Type{T<:SystemBalanceExpressions},
     _::Type{U<:InfrastructureSystems.Optimization.VariableType},
@@ -567,143 +567,143 @@
     _::DeviceModel{V<:StaticInjection, W<:PowerSimulations.AbstractDeviceFormulation},
     network_model::NetworkModel{X<:PowerModels.AbstractPowerModel}
 )
-
Default implementation to add device variables to SystemBalanceExpressions
source
PowerSimulations.add_variable! — Method
add_variable!(
     container::PowerSimulations.OptimizationContainer,
     variable_type::ServiceRequirementVariable,
     service::ReserveDemandCurve,
     formulation
 )
-
Add variables for ServiceRequirementVariable for StepWiseCostReserve
source
PowerSimulations.add_variable! — Method
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.
source
PowerSimulations.add_variable! — Method
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
source
PowerSimulations.add_variable! — Method
add_variable!(
+
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
source
PowerSimulations.add_variable! — Method
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
source
PowerSimulations.add_variables! — Method
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.
source
PowerSimulations.add_variables! — Method
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.
source
PowerSimulations.add_variables! — Method
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.
source
PowerSimulations.build_model! — Method
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
source
PowerSimulations.build_model! — 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
source
PowerSimulations.check_activeservice_variables — Method
check_activeservice_variables(
+
Default implementation of build method for Operational Problems for models conforming with DecisionProblem specification. Overload this function to implement a custom build method
source
PowerSimulations.build_model! — 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
source
PowerSimulations.check_file_integrity — Method
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
source
PowerSimulations.check_file_integrity — Method
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
source
PowerSimulations.construct_device! — Method
construct_device!(
     container::PowerSimulations.OptimizationContainer,
     sys::System,
     _::InfrastructureSystems.Optimization.ArgumentConstructStage,
     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
source
PowerSimulations.construct_device! — Method
construct_device!(
+
This function creates the arguments model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation
source
PowerSimulations.construct_device! — Method
construct_device!(
     container::PowerSimulations.OptimizationContainer,
     sys::System,
     _::InfrastructureSystems.Optimization.ArgumentConstructStage,
     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
source
PowerSimulations.construct_device! — Method
construct_device!(
+
This function creates the arguments for the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation
source
PowerSimulations.construct_device! — Method
construct_device!(
     container::PowerSimulations.OptimizationContainer,
     sys::System,
     _::InfrastructureSystems.Optimization.ArgumentConstructStage,
     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
source
PowerSimulations.construct_device! — Method
construct_device!(
+
This function creates the arguments for the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation
source
PowerSimulations.construct_device! — Method
construct_device!(
     container::PowerSimulations.OptimizationContainer,
     sys::System,
     _::InfrastructureSystems.Optimization.ArgumentConstructStage,
     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
source
PowerSimulations.construct_device! — Method
construct_device!(
+
This function creates the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation
source
PowerSimulations.construct_device! — Method
construct_device!(
     container::PowerSimulations.OptimizationContainer,
     sys::System,
     _::InfrastructureSystems.Optimization.ArgumentConstructStage,
     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
source
PowerSimulations.construct_device! — Method
construct_device!(
+
This function creates the arguments for the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation
source
PowerSimulations.construct_device! — Method
construct_device!(
     container::PowerSimulations.OptimizationContainer,
     sys::System,
     _::InfrastructureSystems.Optimization.ArgumentConstructStage,
     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
source
PowerSimulations.construct_device! — Method
construct_device!(
+
This function creates the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation
source
PowerSimulations.construct_device! — Method
construct_device!(
     container::PowerSimulations.OptimizationContainer,
     sys::System,
     _::InfrastructureSystems.Optimization.ModelConstructStage,
     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
source
PowerSimulations.construct_device! — Method
construct_device!(
+
This function creates the constraints for the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation
source
PowerSimulations.construct_device! — Method
construct_device!(
     container::PowerSimulations.OptimizationContainer,
     sys::System,
     _::InfrastructureSystems.Optimization.ModelConstructStage,
     model::DeviceModel{T<:ThermalGen, <: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
source
PowerSimulations.construct_device! — Method
construct_device!(
+
This function creates the constraints for the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation
source
PowerSimulations.construct_device! — Method
construct_device!(
     container::PowerSimulations.OptimizationContainer,
     sys::System,
     _::InfrastructureSystems.Optimization.ModelConstructStage,
     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
source
PowerSimulations.construct_device! — Method
construct_device!(
+
This function creates the constraints for the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation
source
PowerSimulations.construct_device! — Method
construct_device!(
     container::PowerSimulations.OptimizationContainer,
     sys::System,
     _::InfrastructureSystems.Optimization.ModelConstructStage,
     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
source
PowerSimulations.construct_device! — Method
construct_device!(
+
This function creates the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation
source
PowerSimulations.construct_device! — Method
construct_device!(
     container::PowerSimulations.OptimizationContainer,
     sys::System,
     _::InfrastructureSystems.Optimization.ModelConstructStage,
     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
source
PowerSimulations.construct_device! — Method
construct_device!(
+
This function creates the constraints for the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation
source
PowerSimulations.construct_device! — Method
construct_device!(
     container::PowerSimulations.OptimizationContainer,
     sys::System,
     _::InfrastructureSystems.Optimization.ModelConstructStage,
     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
source
PowerSimulations.construct_service! — Method
construct_service!(
+
This function creates the model for a full thermal dispatch formulation depending on combination of devices, deviceformulation and systemformulation
source
PowerSimulations.construct_service! — Method
construct_service!(
     container::PowerSimulations.OptimizationContainer,
     sys::System,
     _::InfrastructureSystems.Optimization.ArgumentConstructStage,
@@ -712,15 +712,15 @@
     _::Set{<:DataType},
     _::NetworkModel
 )
-
Constructs a service for ConstantReserveGroup.
source
PowerSimulations.container_spec — Method
container_spec(
     _::Type{Float64},
     axs...
 ) -> JuMP.Containers.DenseAxisArray
-
Returns the correct container specification for the selected type of JuMP Model
source
PowerSimulations.container_spec — Method
container_spec(
     _::Type{T},
     axs...
 ) -> JuMP.Containers.DenseAxisArray
-
Returns the correct container specification for the selected type of JuMP Model
source
PowerSimulations.device_duration_compact_retrospective! — Method
device_duration_compact_retrospective!(
     container::PowerSimulations.OptimizationContainer,
     duration_data::Vector{@NamedTuple{up::Float64, down::Float64}},
     initial_duration::Matrix{InitialCondition},
@@ -728,7 +728,7 @@
     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
source
PowerSimulations.device_duration_look_ahead! — Method
device_duration_look_ahead!(
+
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
source
PowerSimulations.device_duration_look_ahead! — Method
device_duration_look_ahead!(
     container::PowerSimulations.OptimizationContainer,
     duration_data::Vector{@NamedTuple{up::Float64, down::Float64}},
     initial_duration::Matrix{InitialCondition},
@@ -737,7 +737,7 @@
     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
source
PowerSimulations.device_duration_parameters! — Method
device_duration_parameters!(
+
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
source
PowerSimulations.device_duration_parameters! — Method
device_duration_parameters!(
     container::PowerSimulations.OptimizationContainer,
     duration_data::Vector{@NamedTuple{up::Float64, down::Float64}},
     initial_duration::Matrix{InitialCondition},
@@ -745,7 +745,7 @@
     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
source
PowerSimulations.device_duration_retrospective! — Method
device_duration_retrospective!(
+
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
source
PowerSimulations.device_duration_retrospective! — Method
device_duration_retrospective!(
     container::PowerSimulations.OptimizationContainer,
     duration_data::Vector{@NamedTuple{up::Float64, down::Float64}},
     initial_duration::Matrix{InitialCondition},
@@ -753,177 +753,177 @@
     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
source
PowerSimulations.find_timestamp_index — Method
find_timestamp_index(
+
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
source
PowerSimulations.find_timestamp_index — Method
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.
source
PowerSimulations.generate_formulation_combinations — Function
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.
source
PowerSimulations.get_absolute_step_range — Method
get_absolute_step_range(
+
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.
source
PowerSimulations.get_absolute_step_range — Method
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.
source
PowerSimulations.get_dirty_data_to_flush! — Method
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.
source
PowerSimulations.get_last_updated_timestamp — Method
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
source
PowerSimulations.get_last_updated_timestamp — Method
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
source
PowerSimulations.get_last_updated_timestamp — Method
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
source
PowerSimulations.get_min_max_limits — Method
get_min_max_limits(
+
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
source
PowerSimulations.get_min_max_limits — Method
get_min_max_limits(
     device::ACBranch,
     _::Type{<:InfrastructureSystems.Optimization.ConstraintType},
     _::Type{<:PowerSimulations.AbstractBranchFormulation}
 ) -> @NamedTuple{min::Float64, max::Float64}
-
Min and max limits for Abstract Branch Formulation
source
PowerSimulations.get_min_max_limits — Method
get_min_max_limits(
     device,
     _::Type{ActivePowerVariableLimitsConstraint},
     _::Type{<:PowerSimulations.AbstractCompactUnitCommitment}
 ) -> Any
-
Min and Max active power limits for Compact Unit Commitment
source
PowerSimulations.get_min_max_limits — Method
get_min_max_limits(
     device,
     _::Type{ActivePowerVariableLimitsConstraint},
     _::Type{<:PowerSimulations.AbstractThermalDispatchFormulation}
 ) -> Any
-
Min and max active power limits of generators for thermal dispatch formulations
source
PowerSimulations.get_min_max_limits — Method
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
source
PowerSimulations.get_min_max_limits — Method
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
source
PowerSimulations.get_min_max_limits — Method
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
source
PowerSimulations.get_min_max_limits — Method
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
source
PowerSimulations.get_min_max_limits — Method
get_min_max_limits(
     device,
     _::Type{ReactivePowerVariableLimitsConstraint},
     _::Type{<:PowerSimulations.AbstractThermalDispatchFormulation}
 ) -> Any
-
Reactive power limits of generators for all dispatch formulations
source
PowerSimulations.get_min_max_limits — Method
get_min_max_limits(
     device,
     _::Type{ReactivePowerVariableLimitsConstraint},
     _::Type{<:PowerSimulations.AbstractThermalUnitCommitment}
 ) -> Any
-
Reactive power limits of generators when there CommitmentVariables
source
PowerSimulations.get_min_max_limits — Method
get_min_max_limits(
     device::MonitoredLine,
     _::Type{<:InfrastructureSystems.Optimization.ConstraintType},
     _::Type{<:PowerSimulations.AbstractBranchFormulation}
 ) -> NamedTuple{(:min, :max), <:Tuple{Any, Any}}
-
Min and max limits for monitored line
source
PowerSimulations.get_min_max_limits — Method
get_min_max_limits(
     device::MonitoredLine,
     _::Type{FlowLimitFromToConstraint},
     _::Type{<:PowerSimulations.AbstractBranchFormulation}
 ) -> NamedTuple{(:min, :max), <:Tuple{Any, Any}}
-
Min and max limits for flow limit from-to constraint
source
PowerSimulations.get_min_max_limits — Method
get_min_max_limits(
     device::MonitoredLine,
     _::Type{FlowLimitToFromConstraint},
     _::Type{<:PowerSimulations.AbstractBranchFormulation}
 ) -> NamedTuple{(:min, :max), <:Tuple{Any, Any}}
-
Min and max limits for flow limit to-from constraint
source
PowerSimulations.get_min_max_limits — Method
get_min_max_limits(
     _::PhaseShiftingTransformer,
     _::Type{PhaseAngleControlLimit},
     _::Type{PhaseAngleControl}
 ) -> @NamedTuple{min::Float64, max::Float64}
-
Min and max limits for Abstract Branch Formulation
source
PowerSimulations.get_piecewise_incrementalcurve_per_system_unit — Method
get_piecewise_incrementalcurve_per_system_unit(
     cost_component::PiecewiseStepData,
     unit_system::UnitSystem,
     system_base_power::Float64,
     device_base_power::Float64
 ) -> PiecewiseStepData
-
Obtain the normalized PiecewiseStep cost data 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.
source
PowerSimulations.get_piecewise_pointcurve_per_system_unit — Method
get_piecewise_pointcurve_per_system_unit(
+
Obtain the normalized PiecewiseStep cost data 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.
source
PowerSimulations.get_piecewise_pointcurve_per_system_unit — Method
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
source
PowerSimulations.get_proportional_cost_per_system_unit — Method
get_proportional_cost_per_system_unit(
+
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
source
PowerSimulations.get_proportional_cost_per_system_unit — Method
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
source
PowerSimulations.get_quadratic_cost_per_system_unit — Method
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
source
PowerSimulations.get_startup_shutdown_limits — Method
get_startup_shutdown_limits(
     device,
     _::Type{ActivePowerVariableLimitsConstraint},
     _::Type{<:PowerSimulations.AbstractCompactUnitCommitment}
 ) -> NamedTuple{(:startup, :shutdown), <:Tuple{Any, Any}}
-
Startup shutdown limits for Compact Unit Commitment
source
PowerSimulations.get_startup_shutdown_limits — Method
get_startup_shutdown_limits(
     device::ThermalMultiStart,
     _::Type{ActivePowerVariableLimitsConstraint},
     _::Type{ThermalMultiStartUnitCommitment}
 ) -> NamedTuple{(:startup, :shutdown), <:Tuple{Any, Any}}
-
Startup and shutdown active power limits for Compact Unit Commitment
source
PowerSimulations.get_update_timestamp — Method
get_update_timestamp(
     container::PowerSimulations.DatasetContainer,
     key::InfrastructureSystems.Optimization.OptimizationContainerKey
 ) -> Any
-
Return the timestamp from the data used in the last update
source
PowerSimulations.has_dirty — Method
has_dirty(
     cache::PowerSimulations.OptimizationOutputCaches
 ) -> Bool
-
Return true if the cache has data that has not been flushed to storage.
source
PowerSimulations.is_cached — Method
is_cached(
     cache::PowerSimulations.OptimizationOutputCaches,
     model_name,
     key,
     index
 ) -> Bool
-
Return true if the data for timestamp is stored in cache.
source
PowerSimulations.list_decision_model_keys — Method
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).
source
PowerSimulations.list_decision_models — Method
list_decision_models(
     store::PowerSimulations.HdfSimulationStore
 ) -> Base.KeySet{Symbol, OrderedDict{Symbol, PowerSimulations.DatasetContainer{PowerSimulations.HDF5Dataset}}}
-
Return the problem names in order of execution.
source
PowerSimulations.onvar_cost — Method
onvar_cost(
     cost::ThermalGenerationCost,
     S::OnVariable,
     d::ThermalGen,
     U::PowerSimulations.AbstractThermalFormulation
 ) -> Any
-
Theoretical Cost at power output zero. Mathematically is the intercept with the y-axis
source
PowerSimulations.open_store — Function
open_store(
     ::Type{PowerSimulations.HdfSimulationStore},
     directory::AbstractString;
     ...
@@ -940,93 +940,93 @@
 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)
source
PowerSimulations.read_json — Method
read_json(
     filename::AbstractString
 ) -> Union{Nothing, Bool, Float64, Int64, String, JSON3.Array, JSON3.Object}
-
Return a decoded JSON file.
source
PowerSimulations.read_result — Method
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.
source
PowerSimulations.read_result — Method
read_result(
     _::Type{DataFrames.DataFrame},
     store::PowerSimulations.HdfSimulationStore,
     model_name::Symbol,
     key::InfrastructureSystems.Optimization.OptimizationContainerKey,
     index::Union{Int64, Dates.DateTime}
 ) -> DataFrames.DataFrame
-
Return DataFrame, DenseAxisArray, or Array for a model result at a timestamp.
source
PowerSimulations.serialize_formulation_combinations — Function
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.
source
PowerSimulations.serialize_jump_optimization_model — Method
serialize_jump_optimization_model(
+
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.
source
PowerSimulations.serialize_simulation — Method
serialize_simulation(sim::Simulation; path, force) -> String
-
serialize_simulation(sim::Simulation, path = ".")
Serialize the simulation to a directory in path.
Return the serialized simulation directory name that is created.
Arguments
  • sim::Simulation: simulation to serialize
  • path = ".": path in which to create the serialzed directory
  • force = false: If true, delete the directory if it already exists. Otherwise, it will throw an exception.
source
PowerSimulations.serialize_simulation — Method
serialize_simulation(sim::Simulation; path, force) -> String
+
serialize_simulation(sim::Simulation, path = ".")
Serialize the simulation to a directory in path.
Return the serialized simulation directory name that is created.
Arguments
  • sim::Simulation: simulation to serialize
  • path = ".": path in which to create the serialzed directory
  • force = false: If true, delete the directory if it already exists. Otherwise, it will throw an exception.
source
PowerSimulations.set_expression! — Method
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
source
PowerSimulations.set_ic_quantity! — Method
set_ic_quantity!(
     ic::InitialCondition{T<:InfrastructureSystems.Optimization.InitialConditionType, Float64},
     var_value::Float64
 )
-
Default implementation of setinitialcondition_value
source
PowerSimulations.set_ic_quantity! — Method
set_ic_quantity!(
     ic::InitialCondition{T<:InfrastructureSystems.Optimization.InitialConditionType, JuMP.VariableRef},
     var_value::Float64
 )
-
Default implementation of setinitialcondition_value
source
PowerSimulations.solve_impl! — Method
solve_impl!(
     container::PowerSimulations.OptimizationContainer,
     system::System
 ) -> Any
-
Default solve method for OptimizationContainer
source
PowerSimulations.sparse_container_spec — Method
sparse_container_spec(
     _::Type{T<:JuMP.AbstractJuMPScalar},
     axs...
 ) -> JuMP.Containers.SparseAxisArray
-
Returns the correct container specification for the selected type of JuMP Model
source
PowerSimulations.to_dataframe — Method
to_dataframe(
     array::JuMP.Containers.DenseAxisArray{T<:Number, 2, Ax, L} where {Ax, L<:Tuple{JuMP.Containers._AxisLookup, JuMP.Containers._AxisLookup}},
     key::InfrastructureSystems.Optimization.OptimizationContainerKey
 ) -> DataFrames.DataFrame
-
Creates a DataFrame from a JuMP DenseAxisArray or SparseAxisArray.
Arguments
  • array: JuMP DenseAxisArray or SparseAxisArray to convert
  • key::OptimizationContainerKey:
source
PowerSimulations.update_container_parameter_values! — Method
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
source
PowerSimulations.update_model! — Method
update_model!(
     model::PowerSimulations.OperationModel,
     sim::Simulation
 )
-
Default problem update function for most problems with no customization
source
PowerSimulations.update_parameter_values! — Method
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
source
PowerSimulations.update_parameter_values! — Method
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
source
PowerSimulations.write_formulation_combinations — Function
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.
source
PowerSimulations.write_result! — Method
write_result!(
+
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.
source
PowerSimulations.write_result! — Method
write_result!(
     store::PowerSimulations.HdfSimulationStore,
     model_name::Symbol,
     key::InfrastructureSystems.Optimization.OptimizationContainerKey,
@@ -1034,7 +1034,7 @@
     _::Dates.DateTime,
     data::JuMP.Containers.DenseAxisArray{Float64, 3, var"#s547", L} where {var"#s547"<: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.
source
PowerSimulations.write_result! — Method
write_result!(
     store::PowerSimulations.HdfSimulationStore,
     _::Symbol,
     key::InfrastructureSystems.Optimization.OptimizationContainerKey,
@@ -1042,7 +1042,7 @@
     simulation_time::Dates.DateTime,
     data::JuMP.Containers.DenseAxisArray
 )
-
Write an emulation model result for an execution index value and the timestamp of the update
source
PowerSimulations.write_result! — Method
write_result!(
     store::PowerSimulations.HdfSimulationStore,
     model_name::Symbol,
     key::InfrastructureSystems.Optimization.OptimizationContainerKey,
@@ -1050,4 +1050,4 @@
     _::Dates.DateTime,
     data::JuMP.Containers.DenseAxisArray{Float64, N, var"#s547", L} where {var"#s547"<:NTuple{N, Any}, L<:NTuple{N, JuMP.Containers._AxisLookup}}
 )
-
Write a decision model result for a timestamp to the store.
source

+

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

source
diff --git a/dev/code_base_developer_guide/troubleshooting/index.html b/dev/code_base_developer_guide/troubleshooting/index.html index ec319460e..7cf0782c0 100644 --- a/dev/code_base_developer_guide/troubleshooting/index.html +++ b/dev/code_base_developer_guide/troubleshooting/index.html @@ -1,2 +1,2 @@ -Troubleshooting · PowerSimulations.jl +Troubleshooting · PowerSimulations.jl diff --git a/dev/formulation_library/Branch/index.html b/dev/formulation_library/Branch/index.html index 513bf8ea4..66098b01d 100644 --- a/dev/formulation_library/Branch/index.html +++ b/dev/formulation_library/Branch/index.html @@ -1,13 +1,13 @@ -Branch · PowerSimulations.jl
GitHub

PowerSystems.Branch Formulations

Note

The use of reactive power variables and constraints will depend on the network model used, i.e., whether it uses (or does not use) reactive power. If the network model is purely active power-based, reactive power variables and related constraints are not created.

Table of contents

  1. StaticBranch
  2. StaticBranchBounds
  3. StaticBranchUnbounded
  4. HVDCTwoTerminalUnbounded
  5. HVDCTwoTerminalLossless
  6. HVDCTwoTerminalDispatch
  7. PhaseAngleControl
  8. Valid configurations

StaticBranch

Formulation valid for PTDFPowerModel Network model

Variables:

Static Parameters

  • $R^\text{max}$ = PowerSystems.get_rating(branch)

Objective:

Add a large proportional cost to the objective function if rate constraint slack variables are used $+ (f^\text{sl,up} + f^\text{sl,lo}) \cdot 2 \cdot 10^5$

Expressions:

No expressions are used.

Constraints:

For each branch $b \in \{1,\dots, B\}$ (in a system with $N$ buses) the constraints are given by:

\[\begin{aligned} +Branch · PowerSimulations.jl

GitHub

PowerSystems.Branch Formulations

Note

The use of reactive power variables and constraints will depend on the network model used, i.e., whether it uses (or does not use) reactive power. If the network model is purely active power-based, reactive power variables and related constraints are not created.

Table of contents

  1. StaticBranch
  2. StaticBranchBounds
  3. StaticBranchUnbounded
  4. HVDCTwoTerminalUnbounded
  5. HVDCTwoTerminalLossless
  6. HVDCTwoTerminalDispatch
  7. PhaseAngleControl
  8. Valid configurations

StaticBranch

Formulation valid for PTDFPowerModel Network model

Variables:

Static Parameters

  • $R^\text{max}$ = PowerSystems.get_rating(branch)

Objective:

Add a large proportional cost to the objective function if rate constraint slack variables are used $+ (f^\text{sl,up} + f^\text{sl,lo}) \cdot 2 \cdot 10^5$

Expressions:

No expressions are used.

Constraints:

For each branch $b \in \{1,\dots, B\}$ (in a system with $N$ buses) the constraints are given by:

\[\begin{aligned} & f_t = \sum_{i=1}^N \text{PTDF}_{i,b} \cdot \text{Bal}_{i,t}, \quad \forall t \in \{1,\dots, T\}\\ & f_t - f_t^\text{sl,up} \le R^\text{max},\quad \forall t \in \{1,\dots, T\} \\ & f_t + f_t^\text{sl,lo} \ge -R^\text{max},\quad \forall t \in \{1,\dots, T\} -\end{aligned}\]

on which $\text{PTDF}$ is the $N \times B$ system Power Transfer Distribution Factors (PTDF) matrix, and $\text{Bal}_{i,t}$ is the active power bus balance expression (i.e. $\text{Generation}_{i,t} - \text{Demand}_{i,t}$) at bus $i$ at time-step $t$.

StaticBranchBounds

Formulation valid for PTDFPowerModel Network model

Variables:

Static Parameters

  • $R^\text{max}$ = PowerSystems.get_rating(branch)

Objective:

No cost is added to the objective function.

Expressions:

No expressions are used.

Constraints:

For each branch $b \in \{1,\dots, B\}$ (in a system with $N$ buses) the constraints are given by:

\[\begin{aligned} +\end{aligned}\]

on which $\text{PTDF}$ is the $N \times B$ system Power Transfer Distribution Factors (PTDF) matrix, and $\text{Bal}_{i,t}$ is the active power bus balance expression (i.e. $\text{Generation}_{i,t} - \text{Demand}_{i,t}$) at bus $i$ at time-step $t$.

StaticBranchBounds

Formulation valid for PTDFPowerModel Network model

Variables:

Static Parameters

  • $R^\text{max}$ = PowerSystems.get_rating(branch)

Objective:

No cost is added to the objective function.

Expressions:

No expressions are used.

Constraints:

For each branch $b \in \{1,\dots, B\}$ (in a system with $N$ buses) the constraints are given by:

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

on which $\text{PTDF}$ is the $N \times B$ system Power Transfer Distribution Factors (PTDF) matrix, and $\text{Bal}_{i,t}$ is the active power bus balance expression (i.e. $\text{Generation}_{i,t} - \text{Demand}_{i,t}$) at bus $i$ at time-step $t$.

StaticBranchUnbounded

Formulation valid for PTDFPowerModel Network model

Objective:

No cost is added to the objective function.

Expressions:

No expressions are used.

Constraints:

For each branch $b \in \{1,\dots, B\}$ (in a system with $N$ buses) the constraints are given by:

\[\begin{aligned} +\end{aligned}\]

on which $\text{PTDF}$ is the $N \times B$ system Power Transfer Distribution Factors (PTDF) matrix, and $\text{Bal}_{i,t}$ is the active power bus balance expression (i.e. $\text{Generation}_{i,t} - \text{Demand}_{i,t}$) at bus $i$ at time-step $t$.

StaticBranchUnbounded

Formulation valid for PTDFPowerModel Network model

Objective:

No cost is added to the objective function.

Expressions:

No expressions are used.

Constraints:

For each branch $b \in \{1,\dots, B\}$ (in a system with $N$ buses) the constraints are given by:

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

on which $\text{PTDF}$ is the $N \times B$ system Power Transfer Distribution Factors (PTDF) matrix, and $\text{Bal}_{i,t}$ is the active power bus balance expression (i.e. $\text{Generation}_{i,t} - \text{Demand}_{i,t}$) at bus $i$ at time-step $t$.

HVDCTwoTerminalUnbounded

Formulation valid for PTDFPowerModel Network model

This model assumes that it can transfer power from two AC buses without losses and no limits.

Variables:

Objective:

No cost is added to the objective function.

Expressions:

The variable FlowActivePowerVariable $f$ is added to the nodal balance expression ActivePowerBalance, by adding the flow $f$ in the receiving bus and subtracting it from the sending bus. This is used then to compute the AC flows using the PTDF equation.

Constraints:

No constraints are added.

HVDCTwoTerminalLossless

Formulation valid for PTDFPowerModel Network model

This model assumes that it can transfer power from two AC buses without losses.

Variables:

Static Parameters

  • $R^\text{from,min}$ = PowerSystems.get_active_power_limits_from(branch).min
  • $R^\text{from,max}$ = PowerSystems.get_active_power_limits_from(branch).max
  • $R^\text{to,min}$ = PowerSystems.get_active_power_limits_to(branch).min
  • $R^\text{to,max}$ = PowerSystems.get_active_power_limits_to(branch).max

Objective:

No cost is added to the objective function.

Expressions:

The variable FlowActivePowerVariable $f$ is added to the nodal balance expression ActivePowerBalance, by adding the flow $f$ in the receiving bus and subtracting it from the sending bus. This is used then to compute the AC flows using the PTDF equation.

Constraints:

\[\begin{align*} +\end{aligned}\]

on which $\text{PTDF}$ is the $N \times B$ system Power Transfer Distribution Factors (PTDF) matrix, and $\text{Bal}_{i,t}$ is the active power bus balance expression (i.e. $\text{Generation}_{i,t} - \text{Demand}_{i,t}$) at bus $i$ at time-step $t$.

HVDCTwoTerminalUnbounded

Formulation valid for PTDFPowerModel Network model

This model assumes that it can transfer power from two AC buses without losses and no limits.

Variables:

Objective:

No cost is added to the objective function.

Expressions:

The variable FlowActivePowerVariable $f$ is added to the nodal balance expression ActivePowerBalance, by adding the flow $f$ in the receiving bus and subtracting it from the sending bus. This is used then to compute the AC flows using the PTDF equation.

Constraints:

No constraints are added.

HVDCTwoTerminalLossless

Formulation valid for PTDFPowerModel Network model

This model assumes that it can transfer power from two AC buses without losses.

Variables:

Static Parameters

  • $R^\text{from,min}$ = PowerSystems.get_active_power_limits_from(branch).min
  • $R^\text{from,max}$ = PowerSystems.get_active_power_limits_from(branch).max
  • $R^\text{to,min}$ = PowerSystems.get_active_power_limits_to(branch).min
  • $R^\text{to,max}$ = PowerSystems.get_active_power_limits_to(branch).max

Objective:

No cost is added to the objective function.

Expressions:

The variable FlowActivePowerVariable $f$ is added to the nodal balance expression ActivePowerBalance, by adding the flow $f$ in the receiving bus and subtracting it from the sending bus. This is used then to compute the AC flows using the PTDF equation.

Constraints:

\[\begin{align*} & R^\text{min} \le f_t \le R^\text{max},\quad \forall t \in \{1,\dots, T\} \\ \end{align*}\]

where:

\[\begin{align*} & R^\text{min} = \begin{cases} @@ -23,7 +23,7 @@ R^\text{from,max},& \text{if } R^\text{from,max} \le 0 \text{ and } R^\text{to,max} \ge 0 \\ R^\text{to,max},& \text{if } R^\text{from,max} \ge 0 \text{ and } R^\text{to,max} \le 0 \end{cases} -\end{align*}\]

HVDCTwoTerminalDispatch

Formulation valid for PTDFPowerModel Network model

Variables

Static Parameters

  • $R^\text{from,min}$ = PowerSystems.get_active_power_limits_from(branch).min
  • $R^\text{from,max}$ = PowerSystems.get_active_power_limits_from(branch).max
  • $R^\text{to,min}$ = PowerSystems.get_active_power_limits_to(branch).min
  • $R^\text{to,max}$ = PowerSystems.get_active_power_limits_to(branch).max
  • $L_0$ = PowerSystems.get_loss(branch).l0
  • $L_1$ = PowerSystems.get_loss(branch).l1

Objective:

No cost is added to the objective function.

Expressions:

Each FlowActivePowerToFromVariable $f^\text{to-from}$ and FlowActivePowerFromToVariable $f^\text{from-to}$ is added to the nodal balance expression ActivePowerBalance, by adding the respective flow in the receiving bus and subtracting it from the sending bus. That is, $f^\text{to-from}$ adds the flow to the from bus, and subtracts the flow from the to bus, while $f^\text{from-to}$ adds the flow to the to bus, and subtracts the flow from the from bus This is used then to compute the AC flows using the PTDF equation.

In addition, the HVDCLosses are subtracted to the from bus in the ActivePowerBalance expression.

Constraints:

\[\begin{align*} +\end{align*}\]

HVDCTwoTerminalDispatch

Formulation valid for PTDFPowerModel Network model

Variables

Static Parameters

  • $R^\text{from,min}$ = PowerSystems.get_active_power_limits_from(branch).min
  • $R^\text{from,max}$ = PowerSystems.get_active_power_limits_from(branch).max
  • $R^\text{to,min}$ = PowerSystems.get_active_power_limits_to(branch).min
  • $R^\text{to,max}$ = PowerSystems.get_active_power_limits_to(branch).max
  • $L_0$ = PowerSystems.get_loss(branch).l0
  • $L_1$ = PowerSystems.get_loss(branch).l1

Objective:

No cost is added to the objective function.

Expressions:

Each FlowActivePowerToFromVariable $f^\text{to-from}$ and FlowActivePowerFromToVariable $f^\text{from-to}$ is added to the nodal balance expression ActivePowerBalance, by adding the respective flow in the receiving bus and subtracting it from the sending bus. That is, $f^\text{to-from}$ adds the flow to the from bus, and subtracts the flow from the to bus, while $f^\text{from-to}$ adds the flow to the to bus, and subtracts the flow from the from bus This is used then to compute the AC flows using the PTDF equation.

In addition, the HVDCLosses are subtracted to the from bus in the ActivePowerBalance expression.

Constraints:

\[\begin{align*} & R^\text{from,min} \le f_t^\text{from-to} \le R^\text{from,max}, \forall t \in \{1,\dots, T\} \\ & R^\text{to,min} \le f_t^\text{to-from} \le R^\text{to,max},\quad \forall t \in \{1,\dots, T\} \\ & f_t^\text{to-from} - f_t^\text{from-to} \le L_1 \cdot f_t^\text{to-from} - L_0,\quad \forall t \in \{1,\dots, T\} \\ @@ -32,7 +32,7 @@ & f_t^\text{to-from} - f_t^\text{from-to} \ge - M^\text{big} u^\text{dir}_t,\quad \forall t \in \{1,\dots, T\} \\ & f_t^\text{to-from} - f_t^\text{from-to} \le \ell_t,\quad \forall t \in \{1,\dots, T\} \\ & f_t^\text{from-to} - f_t^\text{to-from} \le \ell_t,\quad \forall t \in \{1,\dots, T\} -\end{align*}\]

PhaseAngleControl

Formulation valid for PTDFPowerModel Network model

Variables:

Static Parameters

  • $R^\text{max}$ = PowerSystems.get_rating(branch)
  • $\Theta^\text{min}$ = PowerSystems.get_phase_angle_limits(branch).min
  • $\Theta^\text{max}$ = PowerSystems.get_phase_angle_limits(branch).max
  • $X$ = PowerSystems.get_x(branch) (series reactance)

Objective:

No changes to objective function

Expressions:

Adds to the ActivePowerBalance expression the term $-\theta^\text{shift} /X$ to the from bus and $+\theta^\text{shift} /X$ to the to bus, that the PhaseShiftingTransformer is connected.

Constraints:

For each branch $b \in \{1,\dots, B\}$ (in a system with $N$ buses) the constraints are given by:

\[\begin{aligned} +\end{align*}\]

PhaseAngleControl

Formulation valid for PTDFPowerModel Network model

Variables:

Static Parameters

  • $R^\text{max}$ = PowerSystems.get_rating(branch)
  • $\Theta^\text{min}$ = PowerSystems.get_phase_angle_limits(branch).min
  • $\Theta^\text{max}$ = PowerSystems.get_phase_angle_limits(branch).max
  • $X$ = PowerSystems.get_x(branch) (series reactance)

Objective:

No changes to objective function

Expressions:

Adds to the ActivePowerBalance expression the term $-\theta^\text{shift} /X$ to the from bus and $+\theta^\text{shift} /X$ to the to bus, that the PhaseShiftingTransformer is connected.

Constraints:

For each branch $b \in \{1,\dots, B\}$ (in a system with $N$ buses) the constraints are given by:

\[\begin{aligned} & f_t = \sum_{i=1}^N \text{PTDF}_{i,b} \cdot \text{Bal}_{i,t} + \frac{\theta^\text{shift}_t}{X}, \quad \forall t \in \{1,\dots, T\}\\ & -R^\text{max} \le f_t \le R^\text{max},\quad \forall t \in \{1,\dots, T\} -\end{aligned}\]

on which $\text{PTDF}$ is the $N \times B$ system Power Transfer Distribution Factors (PTDF) matrix, and $\text{Bal}_{i,t}$ is the active power bus balance expression (i.e. $\text{Generation}_{i,t} - \text{Demand}_{i,t}$) at bus $i$ at time-step $t$.

Valid configurations

Valid DeviceModels for subtypes of Branch include the following:

Valid DeviceModelDevice TypeFormulation
DeviceModel(PhaseShiftingTransformer, PhaseAngleControl)PhaseShiftingTransformerPhaseAngleControl
DeviceModel(TwoTerminalHVDCLine, HVDCTwoTerminalDispatch)TwoTerminalHVDCLineHVDCTwoTerminalDispatch
DeviceModel(TwoTerminalVSCDCLine, HVDCTwoTerminalDispatch)TwoTerminalVSCDCLineHVDCTwoTerminalDispatch
DeviceModel(TwoTerminalHVDCLine, HVDCTwoTerminalLossless)TwoTerminalHVDCLineHVDCTwoTerminalLossless
DeviceModel(TwoTerminalVSCDCLine, HVDCTwoTerminalLossless)TwoTerminalVSCDCLineHVDCTwoTerminalLossless
DeviceModel(TwoTerminalHVDCLine, HVDCTwoTerminalUnbounded)TwoTerminalHVDCLineHVDCTwoTerminalUnbounded
DeviceModel(TwoTerminalVSCDCLine, HVDCTwoTerminalUnbounded)TwoTerminalVSCDCLineHVDCTwoTerminalUnbounded
DeviceModel(TwoTerminalHVDCLine, PowerSimulations.HVDCTwoTerminalPiecewiseLoss)TwoTerminalHVDCLinePowerSimulations.HVDCTwoTerminalPiecewiseLoss
DeviceModel(TwoTerminalVSCDCLine, PowerSimulations.HVDCTwoTerminalPiecewiseLoss)TwoTerminalVSCDCLinePowerSimulations.HVDCTwoTerminalPiecewiseLoss
DeviceModel(Line, StaticBranch)LineStaticBranch
DeviceModel(MonitoredLine, StaticBranch)MonitoredLineStaticBranch
DeviceModel(PhaseShiftingTransformer, StaticBranch)PhaseShiftingTransformerStaticBranch
DeviceModel(TapTransformer, StaticBranch)TapTransformerStaticBranch
DeviceModel(Transformer2W, StaticBranch)Transformer2WStaticBranch
DeviceModel(TwoTerminalHVDCLine, StaticBranch)TwoTerminalHVDCLineStaticBranch
DeviceModel(TwoTerminalVSCDCLine, StaticBranch)TwoTerminalVSCDCLineStaticBranch
DeviceModel(AreaInterchange, StaticBranch)AreaInterchangeStaticBranch
DeviceModel(Line, StaticBranchBounds)LineStaticBranchBounds
DeviceModel(MonitoredLine, StaticBranchBounds)MonitoredLineStaticBranchBounds
DeviceModel(PhaseShiftingTransformer, StaticBranchBounds)PhaseShiftingTransformerStaticBranchBounds
DeviceModel(TapTransformer, StaticBranchBounds)TapTransformerStaticBranchBounds
DeviceModel(Transformer2W, StaticBranchBounds)Transformer2WStaticBranchBounds
DeviceModel(TwoTerminalHVDCLine, StaticBranchBounds)TwoTerminalHVDCLineStaticBranchBounds
DeviceModel(TwoTerminalVSCDCLine, StaticBranchBounds)TwoTerminalVSCDCLineStaticBranchBounds
DeviceModel(Line, StaticBranchUnbounded)LineStaticBranchUnbounded
DeviceModel(MonitoredLine, StaticBranchUnbounded)MonitoredLineStaticBranchUnbounded
DeviceModel(PhaseShiftingTransformer, StaticBranchUnbounded)PhaseShiftingTransformerStaticBranchUnbounded
DeviceModel(TapTransformer, StaticBranchUnbounded)TapTransformerStaticBranchUnbounded
DeviceModel(Transformer2W, StaticBranchUnbounded)Transformer2WStaticBranchUnbounded
DeviceModel(TwoTerminalHVDCLine, StaticBranchUnbounded)TwoTerminalHVDCLineStaticBranchUnbounded
DeviceModel(TwoTerminalVSCDCLine, StaticBranchUnbounded)TwoTerminalVSCDCLineStaticBranchUnbounded
DeviceModel(AreaInterchange, StaticBranchUnbounded)AreaInterchangeStaticBranchUnbounded
+\end{aligned}\]

on which $\text{PTDF}$ is the $N \times B$ system Power Transfer Distribution Factors (PTDF) matrix, and $\text{Bal}_{i,t}$ is the active power bus balance expression (i.e. $\text{Generation}_{i,t} - \text{Demand}_{i,t}$) at bus $i$ at time-step $t$.

Valid configurations

Valid DeviceModels for subtypes of Branch include the following:

Valid DeviceModelDevice TypeFormulation
DeviceModel(PhaseShiftingTransformer, PhaseAngleControl)PhaseShiftingTransformerPhaseAngleControl
DeviceModel(TwoTerminalHVDCLine, HVDCTwoTerminalDispatch)TwoTerminalHVDCLineHVDCTwoTerminalDispatch
DeviceModel(TwoTerminalVSCDCLine, HVDCTwoTerminalDispatch)TwoTerminalVSCDCLineHVDCTwoTerminalDispatch
DeviceModel(TwoTerminalHVDCLine, HVDCTwoTerminalLossless)TwoTerminalHVDCLineHVDCTwoTerminalLossless
DeviceModel(TwoTerminalVSCDCLine, HVDCTwoTerminalLossless)TwoTerminalVSCDCLineHVDCTwoTerminalLossless
DeviceModel(TwoTerminalHVDCLine, HVDCTwoTerminalUnbounded)TwoTerminalHVDCLineHVDCTwoTerminalUnbounded
DeviceModel(TwoTerminalVSCDCLine, HVDCTwoTerminalUnbounded)TwoTerminalVSCDCLineHVDCTwoTerminalUnbounded
DeviceModel(TwoTerminalHVDCLine, PowerSimulations.HVDCTwoTerminalPiecewiseLoss)TwoTerminalHVDCLinePowerSimulations.HVDCTwoTerminalPiecewiseLoss
DeviceModel(TwoTerminalVSCDCLine, PowerSimulations.HVDCTwoTerminalPiecewiseLoss)TwoTerminalVSCDCLinePowerSimulations.HVDCTwoTerminalPiecewiseLoss
DeviceModel(Line, StaticBranch)LineStaticBranch
DeviceModel(MonitoredLine, StaticBranch)MonitoredLineStaticBranch
DeviceModel(PhaseShiftingTransformer, StaticBranch)PhaseShiftingTransformerStaticBranch
DeviceModel(TapTransformer, StaticBranch)TapTransformerStaticBranch
DeviceModel(Transformer2W, StaticBranch)Transformer2WStaticBranch
DeviceModel(TwoTerminalHVDCLine, StaticBranch)TwoTerminalHVDCLineStaticBranch
DeviceModel(TwoTerminalVSCDCLine, StaticBranch)TwoTerminalVSCDCLineStaticBranch
DeviceModel(AreaInterchange, StaticBranch)AreaInterchangeStaticBranch
DeviceModel(Line, StaticBranchBounds)LineStaticBranchBounds
DeviceModel(MonitoredLine, StaticBranchBounds)MonitoredLineStaticBranchBounds
DeviceModel(PhaseShiftingTransformer, StaticBranchBounds)PhaseShiftingTransformerStaticBranchBounds
DeviceModel(TapTransformer, StaticBranchBounds)TapTransformerStaticBranchBounds
DeviceModel(Transformer2W, StaticBranchBounds)Transformer2WStaticBranchBounds
DeviceModel(TwoTerminalHVDCLine, StaticBranchBounds)TwoTerminalHVDCLineStaticBranchBounds
DeviceModel(TwoTerminalVSCDCLine, StaticBranchBounds)TwoTerminalVSCDCLineStaticBranchBounds
DeviceModel(Line, StaticBranchUnbounded)LineStaticBranchUnbounded
DeviceModel(MonitoredLine, StaticBranchUnbounded)MonitoredLineStaticBranchUnbounded
DeviceModel(PhaseShiftingTransformer, StaticBranchUnbounded)PhaseShiftingTransformerStaticBranchUnbounded
DeviceModel(TapTransformer, StaticBranchUnbounded)TapTransformerStaticBranchUnbounded
DeviceModel(Transformer2W, StaticBranchUnbounded)Transformer2WStaticBranchUnbounded
DeviceModel(TwoTerminalHVDCLine, StaticBranchUnbounded)TwoTerminalHVDCLineStaticBranchUnbounded
DeviceModel(TwoTerminalVSCDCLine, StaticBranchUnbounded)TwoTerminalVSCDCLineStaticBranchUnbounded
DeviceModel(AreaInterchange, StaticBranchUnbounded)AreaInterchangeStaticBranchUnbounded
diff --git a/dev/formulation_library/DCModels/index.html b/dev/formulation_library/DCModels/index.html index 72d816629..6268e2b2b 100644 --- a/dev/formulation_library/DCModels/index.html +++ b/dev/formulation_library/DCModels/index.html @@ -1,2 +1,2 @@ -DC Models formulations · PowerSimulations.jl
GitHub

DC Models formulations

Note

Multi-terminal DC models are still in early stages of development and future versions will add a more comprehensive list of formulations

LossLessLine

LossLessLine models are used with PSY.DCBranch models.

Variables:

Static Parameters

  • $R^\text{from,min}$ = PowerSystems.get_active_power_limits_from(branch).min
  • $R^\text{from,max}$ = PowerSystems.get_active_power_limits_from(branch).max
  • $R^\text{to,min}$ = PowerSystems.get_active_power_limits_to(branch).min
  • $R^\text{to,max}$ = PowerSystems.get_active_power_limits_to(branch).max

Then, the minimum and maximum are computed as R^\text{min} = \min(R^\text{from,min}, R^\text{to,min}) and R^\text{max} = \min(R^\text{from,max}, R^\text{to,max})

Objective:

No cost is added to the objective function.

Expressions:

The variable FlowActivePowerVariable $f$ is added to the nodal balance expression ActivePowerBalance for DC Buses, by adding the flow $f$ in the receiving DC bus and subtracting it from the sending DC bus.

Constraints:

No constraints are added to the function.

LossLessConverter

Converters are used to interface the AC Buses with DC Buses.

Variables:

Static Parameters:

  • $P^\text{min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{max}$ = PowerSystems.get_active_power_limits(device).max

Objective:

No cost is added to the objective function.

Expressions:

The variable ActivePowerVariable $p$ is added positive to the AC balance expression ActivePowerBalance for AC Buses, and added negative to ActivePowerBalance for DC Buses, balancing both sides.

Constraints:

No constraints are added to the function.

+DC Models formulations · PowerSimulations.jl
GitHub

DC Models formulations

Note

Multi-terminal DC models are still in early stages of development and future versions will add a more comprehensive list of formulations

LossLessLine

LossLessLine models are used with PSY.DCBranch models.

Variables:

Static Parameters

  • $R^\text{from,min}$ = PowerSystems.get_active_power_limits_from(branch).min
  • $R^\text{from,max}$ = PowerSystems.get_active_power_limits_from(branch).max
  • $R^\text{to,min}$ = PowerSystems.get_active_power_limits_to(branch).min
  • $R^\text{to,max}$ = PowerSystems.get_active_power_limits_to(branch).max

Then, the minimum and maximum are computed as R^\text{min} = \min(R^\text{from,min}, R^\text{to,min}) and R^\text{max} = \min(R^\text{from,max}, R^\text{to,max})

Objective:

No cost is added to the objective function.

Expressions:

The variable FlowActivePowerVariable $f$ is added to the nodal balance expression ActivePowerBalance for DC Buses, by adding the flow $f$ in the receiving DC bus and subtracting it from the sending DC bus.

Constraints:

No constraints are added to the function.

LossLessConverter

Converters are used to interface the AC Buses with DC Buses.

Variables:

Static Parameters:

  • $P^\text{min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{max}$ = PowerSystems.get_active_power_limits(device).max

Objective:

No cost is added to the objective function.

Expressions:

The variable ActivePowerVariable $p$ is added positive to the AC balance expression ActivePowerBalance for AC Buses, and added negative to ActivePowerBalance for DC Buses, balancing both sides.

Constraints:

No constraints are added to the function.

diff --git a/dev/formulation_library/Feedforward/index.html b/dev/formulation_library/Feedforward/index.html index ae4a626a6..637b8d28a 100644 --- a/dev/formulation_library/Feedforward/index.html +++ b/dev/formulation_library/Feedforward/index.html @@ -4,7 +4,7 @@ source::Type{T}, affected_values::Vector{DataType}, meta = CONTAINER_KEY_EMPTY_META -) where {T}

It allows to enable/disable bounds to 0.0 for a specified variable. Commonly used to limit the ActivePowerVariable in an Economic Dispatch problem by the commitment decision taken in an another problem (typically a Unit Commitment problem).

Arguments:

source

Variables:

No variables are created

Parameters:

Objective:

No changes to the objective function.

Expressions:

Adds $-\text{on}^\text{th}P^\text{th,max}$ to the ActivePowerRangeExpressionUB expression and $-\text{on}^\text{th}P^\text{th,min}$ to the ActivePowerRangeExpressionLB expression.

Constraints:

Limits the ActivePowerRangeExpressionUB and ActivePowerRangeExpressionLB by zero as:

\[\begin{align*} +) where {T}

It allows to enable/disable bounds to 0.0 for a specified variable. Commonly used to limit the ActivePowerVariable in an Economic Dispatch problem by the commitment decision taken in an another problem (typically a Unit Commitment problem).

Arguments:

source

Variables:

No variables are created

Parameters:

Objective:

No changes to the objective function.

Expressions:

Adds $-\text{on}^\text{th}P^\text{th,max}$ to the ActivePowerRangeExpressionUB expression and $-\text{on}^\text{th}P^\text{th,min}$ to the ActivePowerRangeExpressionLB expression.

Constraints:

Limits the ActivePowerRangeExpressionUB and ActivePowerRangeExpressionLB by zero as:

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

Thus, if the commitment parameter is zero, the dispatch is limited to zero, forcing to turn off the generator without introducing binary variables in the economic dispatch problem.

FixValueFeedforward

PowerSimulations.FixValueFeedforward — Type
FixValueFeedforward(
@@ -12,7 +12,7 @@
     source::Type{T},
     affected_values::Vector{DataType},
     meta = CONTAINER_KEY_EMPTY_META
-) where {T}

Fixes a Variable or Parameter Value in the model from another problem. Is the only Feed Forward that can be used with a Parameter or a Variable as the affected value.

Arguments:

  • component_type::Type{<:PSY.Component} : Specify the type of component on which the Feedforward will be applied
  • source::Type{T} : Specify the VariableType, ParameterType or AuxVariableType as the source of values for the Feedforward
  • affected_values::Vector{DataType} : Specify the variable on which the fix value will be applied using the source values
source

Variables:

No variables are created

Parameters:

The parameter FixValueParameter is used to match the result obtained from the source variable (from the simulation state).

Objective:

No changes to the objective function.

Expressions:

No changes on expressions.

Constraints:

Set the VariableType from the affected_values to be equal to the source parameter store in FixValueParameter

\[\begin{align*} +) where {T}

Fixes a Variable or Parameter Value in the model from another problem. Is the only Feed Forward that can be used with a Parameter or a Variable as the affected value.

Arguments:

source

Variables:

No variables are created

Parameters:

The parameter FixValueParameter is used to match the result obtained from the source variable (from the simulation state).

Objective:

No changes to the objective function.

Expressions:

No changes on expressions.

Constraints:

Set the VariableType from the affected_values to be equal to the source parameter store in FixValueParameter

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

UpperBoundFeedforward

PowerSimulations.UpperBoundFeedforward — Type
UpperBoundFeedforward(
     component_type::Type{<:PSY.Component},
@@ -20,7 +20,7 @@
     affected_values::Vector{DataType},
     add_slacks::Bool = false,
     meta = CONTAINER_KEY_EMPTY_META
-) where {T}

Constructs a parameterized upper bound constraint to implement feedforward from other models.

Arguments:

  • component_type::Type{<:PSY.Component} : Specify the type of component on which the Feedforward will be applied
  • source::Type{T} : Specify the VariableType, ParameterType or AuxVariableType as the source of values for the Feedforward
  • affected_values::Vector{DataType} : Specify the variable on which the upper bound will be applied using the source values
  • add_slacks::Bool = false : Add slacks variables to relax the upper bound constraint.
source

Variables:

If slack variables are enabled:

Parameters:

The parameter UpperBoundValueParameter stores the result obtained from the source variable (from the simulation state) that will be used as an upper bound to the affected variable.

Objective:

The slack variable is added to the objective function using its large default cost $+ p^\text{ff,ubsl} \cdot 10^6$

Expressions:

No changes on expressions.

Constraints:

Set the VariableType from the affected_values to be lower than the source parameter store in UpperBoundValueParameter.

\[\begin{align*} +) where {T}

Constructs a parameterized upper bound constraint to implement feedforward from other models.

Arguments:

source

Variables:

If slack variables are enabled:

Parameters:

The parameter UpperBoundValueParameter stores the result obtained from the source variable (from the simulation state) that will be used as an upper bound to the affected variable.

Objective:

The slack variable is added to the objective function using its large default cost $+ p^\text{ff,ubsl} \cdot 10^6$

Expressions:

No changes on expressions.

Constraints:

Set the VariableType from the affected_values to be lower than the source parameter store in UpperBoundValueParameter.

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

LowerBoundFeedforward

PowerSimulations.LowerBoundFeedforward — Type
LowerBoundFeedforward(
     component_type::Type{<:PSY.Component},
@@ -28,6 +28,6 @@
     affected_values::Vector{DataType},
     add_slacks::Bool = false,
     meta = CONTAINER_KEY_EMPTY_META
-) where {T}

Constructs a parameterized lower bound constraint to implement feedforward from other models.

Arguments:

  • component_type::Type{<:PSY.Component} : Specify the type of component on which the Feedforward will be applied
  • source::Type{T} : Specify the VariableType, ParameterType or AuxVariableType as the source of values for the Feedforward
  • affected_values::Vector{DataType} : Specify the variable on which the lower bound will be applied using the source values
  • add_slacks::Bool = false : Add slacks variables to relax the lower bound constraint.
source

Variables:

If slack variables are enabled:

Parameters:

The parameter LowerBoundValueParameter stores the result obtained from the source variable (from the simulation state) that will be used as a lower bound to the affected variable.

Objective:

The slack variable is added to the objective function using its large default cost $+ p^\text{ff,lbsl} \cdot 10^6$

Expressions:

No changes on expressions.

Constraints:

Set the VariableType from the affected_values to be greater than the source parameter store in LowerBoundValueParameter.

\[\begin{align*} +) where {T}

Constructs a parameterized lower bound constraint to implement feedforward from other models.

Arguments:

source

Variables:

If slack variables are enabled:

Parameters:

The parameter LowerBoundValueParameter stores the result obtained from the source variable (from the simulation state) that will be used as a lower bound to the affected variable.

Objective:

The slack variable is added to the objective function using its large default cost $+ p^\text{ff,lbsl} \cdot 10^6$

Expressions:

No changes on expressions.

Constraints:

Set the VariableType from the affected_values to be greater than the source parameter store in LowerBoundValueParameter.

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

+\end{align*}\]

diff --git a/dev/formulation_library/General/index.html b/dev/formulation_library/General/index.html index 0909cb370..e397770ad 100644 --- a/dev/formulation_library/General/index.html +++ b/dev/formulation_library/General/index.html @@ -1,5 +1,5 @@ -General · PowerSimulations.jl
GitHub

Formulations

Modeling formulations are created by dispatching on abstract subtypes of PowerSimulations.AbstractDeviceFormulation

FixedOutput

Variables:

No variables are created for DeviceModel(<:DeviceType, FixedOutput)

Static Parameters:

  • ThermalGen:

    • $P^\text{th,max}$ = PowerSystems.get_max_active_power(device)
    • $Q^\text{th,max}$ = PowerSystems.get_max_reactive_power(device)

  • Storage:

    • $P^\text{st,max}$ = PowerSystems.get_max_active_power(device)
    • $Q^\text{st,max}$ = PowerSystems.get_max_reactive_power(device)

Time Series Parameters:

Device TypeParameterDefault Time Series Name
RenewableGenReactivePowerTimeSeriesParametermax_active_power
RenewableGenActivePowerTimeSeriesParametermax_active_power
HydroGenReactivePowerTimeSeriesParametermax_active_power
HydroGenActivePowerTimeSeriesParametermax_active_power
ElectricLoadReactivePowerTimeSeriesParametermax_active_power
ElectricLoadActivePowerTimeSeriesParametermax_active_power

Objective:

No objective terms are created for DeviceModel(<:DeviceType, FixedOutput)

Expressions:

Adds the active and reactive parameters listed for specific device types above to the respective active and reactive power balance expressions created by the selected Network Formulations.

Constraints:

No constraints are created for DeviceModel(<:DeviceType, FixedOutput)

FunctionData Options

PowerSimulations can represent variable costs using a variety of different methods depending on the data available in each device. The following describes the objective function terms that are populated for each variable cost option.

LinearFunctionData

variable_cost = LinearFunctionData(c): creates a fixed marginal cost term in the objective function

\[\begin{aligned} +General · PowerSimulations.jl

GitHub

Formulations

Modeling formulations are created by dispatching on abstract subtypes of PowerSimulations.AbstractDeviceFormulation

FixedOutput

Variables:

No variables are created for DeviceModel(<:DeviceType, FixedOutput)

Static Parameters:

  • ThermalGen:

    • $P^\text{th,max}$ = PowerSystems.get_max_active_power(device)
    • $Q^\text{th,max}$ = PowerSystems.get_max_reactive_power(device)

  • Storage:

    • $P^\text{st,max}$ = PowerSystems.get_max_active_power(device)
    • $Q^\text{st,max}$ = PowerSystems.get_max_reactive_power(device)

Time Series Parameters:

Device TypeParameterDefault Time Series Name
RenewableGenActivePowerTimeSeriesParametermax_active_power
RenewableGenReactivePowerTimeSeriesParametermax_active_power
HydroGenActivePowerTimeSeriesParametermax_active_power
HydroGenReactivePowerTimeSeriesParametermax_active_power
ElectricLoadActivePowerTimeSeriesParametermax_active_power
ElectricLoadReactivePowerTimeSeriesParametermax_active_power

Objective:

No objective terms are created for DeviceModel(<:DeviceType, FixedOutput)

Expressions:

Adds the active and reactive parameters listed for specific device types above to the respective active and reactive power balance expressions created by the selected Network Formulations.

Constraints:

No constraints are created for DeviceModel(<:DeviceType, FixedOutput)

FunctionData Options

PowerSimulations can represent variable costs using a variety of different methods depending on the data available in each device. The following describes the objective function terms that are populated for each variable cost option.

LinearFunctionData

variable_cost = LinearFunctionData(c): creates a fixed marginal cost term in the objective function

\[\begin{aligned} & \text{min} \sum_{t} c * G_t \end{aligned}\]

QuadraticFunctionData and PolynomialFunctionData

variable_cost::QuadraticFunctionData and variable_cost::PolynomialFunctionData: create a polynomial cost term in the objective function

\[\begin{aligned} & \text{min} \sum_{t} \sum_{n} C_n * G_t^n @@ -7,4 +7,4 @@ & \text{min} \sum_{t} f(G_t) \end{aligned}\]

where

  • For variable_cost::PiecewiseLinearData, $f(x)$ is the piecewise linear function obtained by connecting the (x, y) points get_points(variable_cost) in order.

  • For variable_cost = PiecewiseLinearSlopeData([x0, x1, x2, ...], y0, [s0, s1, s2, ...]), $f(x)$ is the piecewise linear function obtained by starting at (x0, y0), drawing a segment at slope s0 to x=x1, drawing a segment at slope s1 to x=x2, etc.

StorageCost

Adds an objective function cost term according to:

\[\begin{aligned} & \text{min} \sum_{t} \quad [E^{surplus}_t * C^{penalty} - E^{shortage}_t * C^{value}] -\end{aligned}\]

Impact of different cost configurations:

The following table describes all possible configurations of the StorageCost with the target constraint in hydro or storage device models. Cases 1(a) & 2(a) will not impact the model's operations, and the target constraint will be rendered useless. In most cases that have no energy target and a non-zero value for $C^{value}$, if this cost is too high ($C^{value} >> 0$) or too low ($C^{value} <<0$) can result in either the model holding on to stored energy till the end of the model not storing any energy in the device. This is caused by the fact that when the energy target is zero, we have $E_t = - E^{shortage}_t$, and $- E^{shortage}_t * C^{value}$ in the objective function is replaced by $E_t * C^{value}$, thus resulting in $C^{value}$ to be seen as the cost of stored energy.

CaseEnergy TargetEnergy Shortage CostEnergy Value / Energy Surplus costEffect
Case 1(a)$\hat{E}=0$$C^{penalty}=0$$C^{value}=0$no change
Case 1(b)$\hat{E}=0$$C^{penalty}=0$$C^{value}<0$penalty for storing energy
Case 1(c)$\hat{E}=0$$C^{penalty}>0$$C^{value}=0$no penalties or incentives applied
Case 1(d)$\hat{E}=0$$C^{penalty}=0$$C^{value}>0$incentive for storing energy
Case 1(e)$\hat{E}=0$$C^{penalty}>0$$C^{value}<0$penalty for storing energy
Case 1(f)$\hat{E}=0$$C^{penalty}>0$$C^{value}>0$incentive for storing energy
Case 2(a)$\hat{E}>0$$C^{penalty}=0$$C^{value}=0$no change
Case 2(b)$\hat{E}>0$$C^{penalty}=0$$C^{value}<0$penalty on energy storage in excess of target
Case 2(c)$\hat{E}>0$$C^{penalty}>0$$C^{value}=0$penalty on energy storage short of target
Case 2(d)$\hat{E}>0$$C^{penalty}=0$$C^{value}>0$incentive on excess energy
Case 2(e)$\hat{E}>0$$C^{penalty}>0$$C^{value}<0$penalty on both excess/shortage of energy
Case 2(f)$\hat{E}>0$$C^{penalty}>0$$C^{value}>0$penalty for shortage, incentive for excess energy
+\end{aligned}\]

Impact of different cost configurations:

The following table describes all possible configurations of the StorageCost with the target constraint in hydro or storage device models. Cases 1(a) & 2(a) will not impact the model's operations, and the target constraint will be rendered useless. In most cases that have no energy target and a non-zero value for $C^{value}$, if this cost is too high ($C^{value} >> 0$) or too low ($C^{value} <<0$) can result in either the model holding on to stored energy till the end of the model not storing any energy in the device. This is caused by the fact that when the energy target is zero, we have $E_t = - E^{shortage}_t$, and $- E^{shortage}_t * C^{value}$ in the objective function is replaced by $E_t * C^{value}$, thus resulting in $C^{value}$ to be seen as the cost of stored energy.

CaseEnergy TargetEnergy Shortage CostEnergy Value / Energy Surplus costEffect
Case 1(a)$\hat{E}=0$$C^{penalty}=0$$C^{value}=0$no change
Case 1(b)$\hat{E}=0$$C^{penalty}=0$$C^{value}<0$penalty for storing energy
Case 1(c)$\hat{E}=0$$C^{penalty}>0$$C^{value}=0$no penalties or incentives applied
Case 1(d)$\hat{E}=0$$C^{penalty}=0$$C^{value}>0$incentive for storing energy
Case 1(e)$\hat{E}=0$$C^{penalty}>0$$C^{value}<0$penalty for storing energy
Case 1(f)$\hat{E}=0$$C^{penalty}>0$$C^{value}>0$incentive for storing energy
Case 2(a)$\hat{E}>0$$C^{penalty}=0$$C^{value}=0$no change
Case 2(b)$\hat{E}>0$$C^{penalty}=0$$C^{value}<0$penalty on energy storage in excess of target
Case 2(c)$\hat{E}>0$$C^{penalty}>0$$C^{value}=0$penalty on energy storage short of target
Case 2(d)$\hat{E}>0$$C^{penalty}=0$$C^{value}>0$incentive on excess energy
Case 2(e)$\hat{E}>0$$C^{penalty}>0$$C^{value}<0$penalty on both excess/shortage of energy
Case 2(f)$\hat{E}>0$$C^{penalty}>0$$C^{value}>0$penalty for shortage, incentive for excess energy
diff --git a/dev/formulation_library/Introduction/index.html b/dev/formulation_library/Introduction/index.html index 4d587821d..d15e0653a 100644 --- a/dev/formulation_library/Introduction/index.html +++ b/dev/formulation_library/Introduction/index.html @@ -12,4 +12,4 @@ & \hspace{0.9cm} p_t^\text{th} + p_t^\text{re} = P_t^\text{load}, \quad \forall t \in {1,\dots, 48} \\ & \hspace{0.9cm} 0 \le p_t^\text{th} \le P^\text{th,max} \\ & \hspace{0.9cm} 0 \le p_t^\text{re} \le \text{ActivePowerTimeSeriesParameter}_t -\end{align*}\]

Note that the StaticPowerLoad does not impose any cost to the objective function or constraint but adds its power demand to the supply-balance demand of the CopperPlatePowerModel used. Since we are using the ThermalDispatchNoMin formulation for the thermal generation, the lower bound for the power is 0, instead of $P^\text{th,min}$. In addition, we are assuming a linear cost $C^\text{th}$. Finally, the RenewableFullDispatch formulation allows the dispatch of the renewable unit between 0 and its maximum injection time series $p_t^\text{re,param}$.

Nomenclature

In the formulations described in the other pages, the nomenclature is as follows:

+\end{align*}\]

Note that the StaticPowerLoad does not impose any cost to the objective function or constraint but adds its power demand to the supply-balance demand of the CopperPlatePowerModel used. Since we are using the ThermalDispatchNoMin formulation for the thermal generation, the lower bound for the power is 0, instead of $P^\text{th,min}$. In addition, we are assuming a linear cost $C^\text{th}$. Finally, the RenewableFullDispatch formulation allows the dispatch of the renewable unit between 0 and its maximum injection time series $p_t^\text{re,param}$.

Nomenclature

In the formulations described in the other pages, the nomenclature is as follows:

diff --git a/dev/formulation_library/Load/index.html b/dev/formulation_library/Load/index.html index 80ba9d943..0d45ccff8 100644 --- a/dev/formulation_library/Load/index.html +++ b/dev/formulation_library/Load/index.html @@ -1,8 +1,8 @@ -Load · PowerSimulations.jl
GitHub

PowerSystems.ElectricLoad Formulations

Electric load formulations define the optimization models that describe load units (demand) mathematical model in different operational settings, such as economic dispatch and unit commitment.

Note

The use of reactive power variables and constraints will depend on the network model used, i.e., whether it uses (or does not use) reactive power. If the network model is purely active power-based, reactive power variables and related constraints are not created.

Table of contents

  1. StaticPowerLoad
  2. PowerLoadInterruption
  3. PowerLoadDispatch
  4. Valid configurations

StaticPowerLoad

Variables:

No variables are created

Time Series Parameters:

Uses the max_active_power timeseries parameter to determine the demand value at each time-step

ParameterDefault Time Series Name
ReactivePowerTimeSeriesParametermax_active_power
ActivePowerTimeSeriesParametermax_active_power

Expressions:

Subtracts the parameters listed above from the respective active and reactive power balance expressions created by the selected Network Formulations.

Constraints:

No constraints are created

PowerLoadInterruption

Variables:

Static Parameters:

  • $P^\text{ld,max}$ = PowerSystems.get_max_active_power(device)
  • $Q^\text{ld,max}$ = PowerSystems.get_max_reactive_power(device)

Time Series Parameters:

ParameterDefault Time Series Name
ReactivePowerTimeSeriesParametermax_active_power
ActivePowerTimeSeriesParametermax_active_power

Objective:

Creates an objective function term based on the FunctionData Options where the quantity term is defined as $p^\text{ld}$.

Expressions:

  • Subtract$p^\text{ld}$ and $q^\text{ld}$ terms and to the respective active and reactive power balance expressions created by the selected Network Formulations

Constraints:

\[\begin{aligned} +Load · PowerSimulations.jl

GitHub

PowerSystems.ElectricLoad Formulations

Electric load formulations define the optimization models that describe load units (demand) mathematical model in different operational settings, such as economic dispatch and unit commitment.

Note

The use of reactive power variables and constraints will depend on the network model used, i.e., whether it uses (or does not use) reactive power. If the network model is purely active power-based, reactive power variables and related constraints are not created.

Table of contents

  1. StaticPowerLoad
  2. PowerLoadInterruption
  3. PowerLoadDispatch
  4. Valid configurations

StaticPowerLoad

Variables:

No variables are created

Time Series Parameters:

Uses the max_active_power timeseries parameter to determine the demand value at each time-step

ParameterDefault Time Series Name
ActivePowerTimeSeriesParametermax_active_power
ReactivePowerTimeSeriesParametermax_active_power

Expressions:

Subtracts the parameters listed above from the respective active and reactive power balance expressions created by the selected Network Formulations.

Constraints:

No constraints are created

PowerLoadInterruption

Variables:

Static Parameters:

  • $P^\text{ld,max}$ = PowerSystems.get_max_active_power(device)
  • $Q^\text{ld,max}$ = PowerSystems.get_max_reactive_power(device)

Time Series Parameters:

ParameterDefault Time Series Name
ActivePowerTimeSeriesParametermax_active_power
ReactivePowerTimeSeriesParametermax_active_power

Objective:

Creates an objective function term based on the FunctionData Options where the quantity term is defined as $p^\text{ld}$.

Expressions:

  • Subtract$p^\text{ld}$ and $q^\text{ld}$ terms and to the respective active and reactive power balance expressions created by the selected Network Formulations

Constraints:

\[\begin{aligned} & p_t^\text{ld} \le u_t^\text{ld} \cdot \text{ActivePowerTimeSeriesParameter}_t, \quad \forall t \in \{1,\dots, T\} \\ & q_t^\text{re} = \text{pf} \cdot p_t^\text{re}, \quad \forall t \in \{1,\dots, T\} -\end{aligned}\]

on which $\text{pf} = \sin(\arctan(Q^\text{ld,max}/P^\text{ld,max}))$.

PowerLoadDispatch

Variables:

  • ActivePowerVariable:

    • Bounds: [0.0, ]
    • Default initial value: PowerSystems.get_active_power(device)
    • Symbol: $p^\text{ld}$

  • ReactivePowerVariable:

    • Bounds: [0.0, ]
    • Default initial value: PowerSystems.get_reactive_power(device)
    • Symbol: $q^\text{ld}$

Static Parameters:

  • $P^\text{ld,max}$ = PowerSystems.get_max_active_power(device)
  • $Q^\text{ld,max}$ = PowerSystems.get_max_reactive_power(device)

Time Series Parameters:

ParameterDefault Time Series Name
ReactivePowerTimeSeriesParametermax_active_power
ActivePowerTimeSeriesParametermax_active_power

Objective:

Creates an objective function term based on the FunctionData Options where the quantity term is defined as $p^\text{ld}$.

Expressions:

  • Subtract$p^\text{ld}$ and $q^\text{ld}$ terms and to the respective active and reactive power balance expressions created by the selected Network Formulations

Constraints:

\[\begin{aligned} +\end{aligned}\]

on which $\text{pf} = \sin(\arctan(Q^\text{ld,max}/P^\text{ld,max}))$.

PowerLoadDispatch

Variables:

  • ActivePowerVariable:

    • Bounds: [0.0, ]
    • Default initial value: PowerSystems.get_active_power(device)
    • Symbol: $p^\text{ld}$

  • ReactivePowerVariable:

    • Bounds: [0.0, ]
    • Default initial value: PowerSystems.get_reactive_power(device)
    • Symbol: $q^\text{ld}$

Static Parameters:

  • $P^\text{ld,max}$ = PowerSystems.get_max_active_power(device)
  • $Q^\text{ld,max}$ = PowerSystems.get_max_reactive_power(device)

Time Series Parameters:

ParameterDefault Time Series Name
ActivePowerTimeSeriesParametermax_active_power
ReactivePowerTimeSeriesParametermax_active_power

Objective:

Creates an objective function term based on the FunctionData Options where the quantity term is defined as $p^\text{ld}$.

Expressions:

  • Subtract$p^\text{ld}$ and $q^\text{ld}$ terms and to the respective active and reactive power balance expressions created by the selected Network Formulations

Constraints:

\[\begin{aligned} & p_t^\text{ld} \le \text{ActivePowerTimeSeriesParameter}_t, \quad \forall t \in \{1,\dots, T\}\\ & q_t^\text{ld} = \text{pf} \cdot p_t^\text{ld}, \quad \forall t \in \{1,\dots, T\}\\ -\end{aligned}\]

on which $\text{pf} = \sin(\arctan(Q^\text{ld,max}/P^\text{ld,max}))$.

Valid configurations

Valid DeviceModels for subtypes of ElectricLoad include the following:

Valid DeviceModelDevice TypeFormulation
DeviceModel(InterruptiblePowerLoad, PowerLoadDispatch)InterruptiblePowerLoadPowerLoadDispatch
DeviceModel(ExponentialLoad, PowerLoadDispatch)ExponentialLoadPowerLoadDispatch
DeviceModel(PowerLoad, PowerLoadDispatch)PowerLoadPowerLoadDispatch
DeviceModel(StandardLoad, PowerLoadDispatch)StandardLoadPowerLoadDispatch
DeviceModel(InterruptiblePowerLoad, PowerLoadInterruption)InterruptiblePowerLoadPowerLoadInterruption
DeviceModel(ExponentialLoad, PowerLoadInterruption)ExponentialLoadPowerLoadInterruption
DeviceModel(PowerLoad, PowerLoadInterruption)PowerLoadPowerLoadInterruption
DeviceModel(StandardLoad, PowerLoadInterruption)StandardLoadPowerLoadInterruption
DeviceModel(FixedAdmittance, StaticPowerLoad)FixedAdmittanceStaticPowerLoad
DeviceModel(InterruptiblePowerLoad, StaticPowerLoad)InterruptiblePowerLoadStaticPowerLoad
DeviceModel(ExponentialLoad, StaticPowerLoad)ExponentialLoadStaticPowerLoad
DeviceModel(PowerLoad, StaticPowerLoad)PowerLoadStaticPowerLoad
DeviceModel(StandardLoad, StaticPowerLoad)StandardLoadStaticPowerLoad
DeviceModel(SwitchedAdmittance, StaticPowerLoad)SwitchedAdmittanceStaticPowerLoad
+\end{aligned}\]

on which $\text{pf} = \sin(\arctan(Q^\text{ld,max}/P^\text{ld,max}))$.

Valid configurations

Valid DeviceModels for subtypes of ElectricLoad include the following:

Valid DeviceModelDevice TypeFormulation
DeviceModel(InterruptiblePowerLoad, PowerLoadDispatch)InterruptiblePowerLoadPowerLoadDispatch
DeviceModel(ExponentialLoad, PowerLoadDispatch)ExponentialLoadPowerLoadDispatch
DeviceModel(PowerLoad, PowerLoadDispatch)PowerLoadPowerLoadDispatch
DeviceModel(StandardLoad, PowerLoadDispatch)StandardLoadPowerLoadDispatch
DeviceModel(InterruptiblePowerLoad, PowerLoadInterruption)InterruptiblePowerLoadPowerLoadInterruption
DeviceModel(ExponentialLoad, PowerLoadInterruption)ExponentialLoadPowerLoadInterruption
DeviceModel(PowerLoad, PowerLoadInterruption)PowerLoadPowerLoadInterruption
DeviceModel(StandardLoad, PowerLoadInterruption)StandardLoadPowerLoadInterruption
DeviceModel(FixedAdmittance, StaticPowerLoad)FixedAdmittanceStaticPowerLoad
DeviceModel(InterruptiblePowerLoad, StaticPowerLoad)InterruptiblePowerLoadStaticPowerLoad
DeviceModel(ExponentialLoad, StaticPowerLoad)ExponentialLoadStaticPowerLoad
DeviceModel(PowerLoad, StaticPowerLoad)PowerLoadStaticPowerLoad
DeviceModel(StandardLoad, StaticPowerLoad)StandardLoadStaticPowerLoad
DeviceModel(SwitchedAdmittance, StaticPowerLoad)SwitchedAdmittanceStaticPowerLoad
diff --git a/dev/formulation_library/Network/index.html b/dev/formulation_library/Network/index.html index 36ab91cb5..988f90c7d 100644 --- a/dev/formulation_library/Network/index.html +++ b/dev/formulation_library/Network/index.html @@ -1,10 +1,10 @@ -Network · PowerSimulations.jl
GitHub

Network Formulations

Network formulations are used to describe how the network and buses are handled when constructing constraints. The most common constraint decided by the network formulation is the supply-demand balance constraint.

PowerSimulations.NetworkModel — Type

Establishes the model for the network specified by type.

Arguments

-::Type{T}: PowerModels AbstractPowerModel

Accepted Key Words

  • use_slacks::Bool: Adds slacks to the network modeling
  • PTDF::PTDF: PTDF Array calculated using PowerNetworkMatrices
  • duals::Vector{DataType}: Constraint types to calculate the duals
  • reduce_radial_branches::Bool: Skips modeling radial branches in the system to reduce problem size

Example

ptdfarray = PTDF(system) nw = NetworkModel(PTDFPowerModel, ptdf = ptdfarray),

source

Available Network Models are:

FormulationDescription
CopperPlatePowerModelCopper plate connection between all components, i.e. infinite transmission capacity
AreaBalancePowerModelNetwork model approximation to represent inter-area flow with each area represented as a single node
PTDFPowerModelUses the PTDF factor matrix to compute the fraction of power transferred in the network across the branches
AreaPTDFPowerModelUses the PTDF factor matrix to compute the fraction of power transferred in the network across the branches and balances power by Area instead of system-wide

PowerModels.jl available formulations:

  • Exact non-convex models: ACPPowerModel, ACRPowerModel, ACTPowerModel.
  • Linear approximations: DCPPowerModel, NFAPowerModel.
  • Quadratic approximations: DCPLLPowerModel, LPACCPowerModel
  • Quadratic relaxations: SOCWRPowerModel, SOCWRConicPowerModel, SOCBFPowerModel, SOCBFConicPowerModel, QCRMPowerModel, QCLSPowerModel.
  • SDP relaxations: SDPWRMPowerModel, SparseSDPWRMPowerModel.

All of these formulations are described in the PowerModels.jl documentation and will not be described here.

CopperPlatePowerModel

Variables:

If Slack variables are enabled:

  • SystemBalanceSlackUp:

    • Bounds: [0.0, ]
    • Default initial value: 0.0
    • Default proportional cost: 1e6
    • Symbol: $p^\text{sl,up}$

  • SystemBalanceSlackDown:

    • Bounds: [0.0, ]
    • Default initial value: 0.0
    • Default proportional cost: 1e6
    • Symbol: $p^\text{sl,dn}$

Objective:

Add a large proportional cost to the objective function if slack variables are used $+ (p^\text{sl,up} + p^\text{sl,dn}) \cdot 10^6$

Expressions:

Adds $p^\text{sl,up}$ and $p^\text{sl,dn}$ terms to the respective active power balance expressions ActivePowerBalance created by this CopperPlatePowerModel network formulation.

Constraints:

Adds the CopperPlateBalanceConstraint to balance the active power of all components available in the system

\[\begin{align} +Network · PowerSimulations.jl

GitHub

Network Formulations

Network formulations are used to describe how the network and buses are handled when constructing constraints. The most common constraint decided by the network formulation is the supply-demand balance constraint.

PowerSimulations.NetworkModel — Type

Establishes the model for the network specified by type.

Arguments

-::Type{T}: PowerModels AbstractPowerModel

Accepted Key Words

  • use_slacks::Bool: Adds slacks to the network modeling
  • PTDF::PTDF: PTDF Array calculated using PowerNetworkMatrices
  • duals::Vector{DataType}: Constraint types to calculate the duals
  • reduce_radial_branches::Bool: Skips modeling radial branches in the system to reduce problem size

Example

ptdfarray = PTDF(system) nw = NetworkModel(PTDFPowerModel, ptdf = ptdfarray),

source

Available Network Models are:

FormulationDescription
CopperPlatePowerModelCopper plate connection between all components, i.e. infinite transmission capacity
AreaBalancePowerModelNetwork model approximation to represent inter-area flow with each area represented as a single node
PTDFPowerModelUses the PTDF factor matrix to compute the fraction of power transferred in the network across the branches
AreaPTDFPowerModelUses the PTDF factor matrix to compute the fraction of power transferred in the network across the branches and balances power by Area instead of system-wide

PowerModels.jl available formulations:

  • Exact non-convex models: ACPPowerModel, ACRPowerModel, ACTPowerModel.
  • Linear approximations: DCPPowerModel, NFAPowerModel.
  • Quadratic approximations: DCPLLPowerModel, LPACCPowerModel
  • Quadratic relaxations: SOCWRPowerModel, SOCWRConicPowerModel, SOCBFPowerModel, SOCBFConicPowerModel, QCRMPowerModel, QCLSPowerModel.
  • SDP relaxations: SDPWRMPowerModel, SparseSDPWRMPowerModel.

All of these formulations are described in the PowerModels.jl documentation and will not be described here.

CopperPlatePowerModel

Variables:

If Slack variables are enabled:

  • SystemBalanceSlackUp:

    • Bounds: [0.0, ]
    • Default initial value: 0.0
    • Default proportional cost: 1e6
    • Symbol: $p^\text{sl,up}$

  • SystemBalanceSlackDown:

    • Bounds: [0.0, ]
    • Default initial value: 0.0
    • Default proportional cost: 1e6
    • Symbol: $p^\text{sl,dn}$

Objective:

Add a large proportional cost to the objective function if slack variables are used $+ (p^\text{sl,up} + p^\text{sl,dn}) \cdot 10^6$

Expressions:

Adds $p^\text{sl,up}$ and $p^\text{sl,dn}$ terms to the respective active power balance expressions ActivePowerBalance created by this CopperPlatePowerModel network formulation.

Constraints:

Adds the CopperPlateBalanceConstraint to balance the active power of all components available in the system

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

AreaBalancePowerModel

Variables: If Slack variables are enabled:

  • SystemBalanceSlackUp by area:

    • Bounds: [0.0, ]
    • Default initial value: 0.0
    • Default proportional cost: 1e6
    • Symbol: $p^\text{sl,up}$

  • SystemBalanceSlackDown by area:

    • Bounds: [0.0, ]
    • Default initial value: 0.0
    • Default proportional cost: 1e6
    • Symbol: $p^\text{sl,dn}$

Objective:

Adds $p^\text{sl,up}$ and $p^\text{sl,dn}$ terms to the respective active power balance expressions ActivePowerBalance per area.

Expressions:

Creates ActivePowerBalance expressions for each area that then are used to balance active power for all buses within a single area.

Constraints:

Adds the CopperPlateBalanceConstraint to balance the active power of all components available in an area.

\[\begin{align} +\end{align}\]

AreaBalancePowerModel

Variables: If Slack variables are enabled:

  • SystemBalanceSlackUp by area:

    • Bounds: [0.0, ]
    • Default initial value: 0.0
    • Default proportional cost: 1e6
    • Symbol: $p^\text{sl,up}$

  • SystemBalanceSlackDown by area:

    • Bounds: [0.0, ]
    • Default initial value: 0.0
    • Default proportional cost: 1e6
    • Symbol: $p^\text{sl,dn}$

Objective:

Adds $p^\text{sl,up}$ and $p^\text{sl,dn}$ terms to the respective active power balance expressions ActivePowerBalance per area.

Expressions:

Creates ActivePowerBalance expressions for each area that then are used to balance active power for all buses within a single area.

Constraints:

Adds the CopperPlateBalanceConstraint to balance the active power of all components available in an area.

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

PTDFPowerModel

Variables:

If Slack variables are enabled:

  • SystemBalanceSlackUp:

    • Bounds: [0.0, ]
    • Default initial value: 0.0
    • Default proportional cost: 1e6
    • Symbol: $p^\text{sl,up}$

  • SystemBalanceSlackDown:

    • Bounds: [0.0, ]
    • Default initial value: 0.0
    • Default proportional cost: 1e6
    • Symbol: $p^\text{sl,dn}$

Objective:

Add a large proportional cost to the objective function if slack variables are used $+ (p^\text{sl,up} + p^\text{sl,dn}) \cdot 10^6$

Expressions:

Adds $p^\text{sl,up}$ and $p^\text{sl,dn}$ terms to the respective system-wide active power balance expressions ActivePowerBalance created by this CopperPlatePowerModel network formulation. In addition, it creates ActivePowerBalance expressions for each bus to be used in the calculation of branch flows.

Constraints:

Adds the CopperPlateBalanceConstraint to balance the active power of all components available in the system

\[\begin{align} +\end{align}\]

PTDFPowerModel

Variables:

If Slack variables are enabled:

  • SystemBalanceSlackUp:

    • Bounds: [0.0, ]
    • Default initial value: 0.0
    • Default proportional cost: 1e6
    • Symbol: $p^\text{sl,up}$

  • SystemBalanceSlackDown:

    • Bounds: [0.0, ]
    • Default initial value: 0.0
    • Default proportional cost: 1e6
    • Symbol: $p^\text{sl,dn}$

Objective:

Add a large proportional cost to the objective function if slack variables are used $+ (p^\text{sl,up} + p^\text{sl,dn}) \cdot 10^6$

Expressions:

Adds $p^\text{sl,up}$ and $p^\text{sl,dn}$ terms to the respective system-wide active power balance expressions ActivePowerBalance created by this CopperPlatePowerModel network formulation. In addition, it creates ActivePowerBalance expressions for each bus to be used in the calculation of branch flows.

Constraints:

Adds the CopperPlateBalanceConstraint to balance the active power of all components available in the system

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

In addition creates NodalBalanceActiveConstraint for HVDC buses balance, if DC components are connected to an HVDC network.

AreaPTDFPowerModel

Variables

Slack variables are not supported.

Objective Function

No changes to the objective function.

Expressions

Creates the area-wide and nodal-wide active power balance expressions ActivePowerBalance to balance power based on each area independently. The flows across areas are computed based on the PTDF factors of lines connecting areas.

Constraints:

Adds the ActivePowerBalance constraint to balance the active power of all components available for each area.

\[\begin{align} +\end{align}\]

In addition creates NodalBalanceActiveConstraint for HVDC buses balance, if DC components are connected to an HVDC network.

AreaPTDFPowerModel

Variables

Slack variables are not supported.

Objective Function

No changes to the objective function.

Expressions

Creates the area-wide and nodal-wide active power balance expressions ActivePowerBalance to balance power based on each area independently. The flows across areas are computed based on the PTDF factors of lines connecting areas.

Constraints:

Adds the ActivePowerBalance constraint to balance the active power of all components available for each area.

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

This includes the flows of lines based on the PTDF factors.

+\end{align}\]

This includes the flows of lines based on the PTDF factors.

diff --git a/dev/formulation_library/Piecewise/index.html b/dev/formulation_library/Piecewise/index.html index 661bae2ba..c30bed420 100644 --- a/dev/formulation_library/Piecewise/index.html +++ b/dev/formulation_library/Piecewise/index.html @@ -27,4 +27,4 @@ & \sum_{k \in \mathcal{K}} \delta_{k,t} = \text{on}_{t} & \forall t \in \mathcal{T}\\ & 0 \leq \Delta p_{t} \leq \left( P^{\text{max}} - P^{\text{min}} \right)\text{on}_{t} & \forall t \in \mathcal{T}\\ &\left \{\delta_{i,t} \dots \delta_{k,t} \right \} \in \text{SOS}_{2} & \forall t \in \mathcal{T} -\end{align*}\]

on which $\delta_{k,t} \in [0,1]$ is the interpolation variable, $\Delta p$ is the active power of the generator above the minimum power and $u \in \{0,1\}$ is the commitment variable of the generator. In the case of a PWL convex costs, i.e. increasing slopes, the SOS constraint is omitted.

+\end{align*}\]

on which $\delta_{k,t} \in [0,1]$ is the interpolation variable, $\Delta p$ is the active power of the generator above the minimum power and $u \in \{0,1\}$ is the commitment variable of the generator. In the case of a PWL convex costs, i.e. increasing slopes, the SOS constraint is omitted.

diff --git a/dev/formulation_library/README/index.html b/dev/formulation_library/README/index.html index 8664e5199..75e89312c 100644 --- a/dev/formulation_library/README/index.html +++ b/dev/formulation_library/README/index.html @@ -1,2 +1,2 @@ -Formulation documentation guide · PowerSimulations.jl
GitHub

Formulation documentation guide

Formulation documentation should roughly follow the template established by RenewableGen.md

Auto generated items

  • Valid DeviceModel table: just change the device category in the filter function
  • Time Series Parameters: just change the device category and formulation in the get_default_time_series_names method call

Linked items

  • Formulations in the Valid DeviceModel table must have a docstring in src/core/formulations.jl
  • The Formulation in the @docs block must have a docstring in src/core/formulations.jl
  • The Variables must have docstrings in src/core/variables.jl
  • The Time Series Parameters must have docstrings in src/core/parameters.jl
+Formulation documentation guide · PowerSimulations.jl
GitHub

Formulation documentation guide

Formulation documentation should roughly follow the template established by RenewableGen.md

Auto generated items

  • Valid DeviceModel table: just change the device category in the filter function
  • Time Series Parameters: just change the device category and formulation in the get_default_time_series_names method call

Linked items

  • Formulations in the Valid DeviceModel table must have a docstring in src/core/formulations.jl
  • The Formulation in the @docs block must have a docstring in src/core/formulations.jl
  • The Variables must have docstrings in src/core/variables.jl
  • The Time Series Parameters must have docstrings in src/core/parameters.jl
diff --git a/dev/formulation_library/RenewableGen/index.html b/dev/formulation_library/RenewableGen/index.html index edbd46077..da820eb2d 100644 --- a/dev/formulation_library/RenewableGen/index.html +++ b/dev/formulation_library/RenewableGen/index.html @@ -1,8 +1,8 @@ -Renewable Generation · PowerSimulations.jl
GitHub

PowerSystems.RenewableGen Formulations

Renewable generation formulations define the optimization models that describe renewable units mathematical model in different operational settings, such as economic dispatch and unit commitment.

Note

The use of reactive power variables and constraints will depend on the network model used, i.e., whether it uses (or does not use) reactive power. If the network model is purely active power-based, reactive power variables and related constraints are not created.

Note

Reserve variables for services are not included in the formulation, albeit their inclusion change the variables, expressions, constraints and objective functions created. A detailed description of the implications in the optimization models is described in the Service formulation section.

Table of contents

  1. RenewableFullDispatch
  2. RenewableConstantPowerFactor
  3. Valid configurations

RenewableFullDispatch

Variables:

Static Parameters:

  • $P^\text{re,min}$ = PowerSystems.get_active_power_limits(device).min
  • $Q^\text{re,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{re,max}$ = PowerSystems.get_reactive_power_limits(device).max

Time Series Parameters:

Uses the max_active_power timeseries parameter to limit the available active power at each time-step.

ParameterDefault Time Series Name
ReactivePowerTimeSeriesParametermax_active_power
ActivePowerTimeSeriesParametermax_active_power

Objective:

Creates an objective function term based on the FunctionData Options where the quantity term is defined as $- p^\text{re}$ to incentivize generation from RenewableGen devices.

Expressions:

Adds $p^\text{re}$ and $q^\text{re}$ terms to the respective active and reactive power balance expressions created by the selected Network Formulations.

Constraints:

\[\begin{aligned} +Renewable Generation · PowerSimulations.jl

GitHub

PowerSystems.RenewableGen Formulations

Renewable generation formulations define the optimization models that describe renewable units mathematical model in different operational settings, such as economic dispatch and unit commitment.

Note

The use of reactive power variables and constraints will depend on the network model used, i.e., whether it uses (or does not use) reactive power. If the network model is purely active power-based, reactive power variables and related constraints are not created.

Note

Reserve variables for services are not included in the formulation, albeit their inclusion change the variables, expressions, constraints and objective functions created. A detailed description of the implications in the optimization models is described in the Service formulation section.

Table of contents

  1. RenewableFullDispatch
  2. RenewableConstantPowerFactor
  3. Valid configurations

RenewableFullDispatch

Variables:

Static Parameters:

  • $P^\text{re,min}$ = PowerSystems.get_active_power_limits(device).min
  • $Q^\text{re,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{re,max}$ = PowerSystems.get_reactive_power_limits(device).max

Time Series Parameters:

Uses the max_active_power timeseries parameter to limit the available active power at each time-step.

ParameterDefault Time Series Name
ActivePowerTimeSeriesParametermax_active_power
ReactivePowerTimeSeriesParametermax_active_power

Objective:

Creates an objective function term based on the FunctionData Options where the quantity term is defined as $- p^\text{re}$ to incentivize generation from RenewableGen devices.

Expressions:

Adds $p^\text{re}$ and $q^\text{re}$ terms to the respective active and reactive power balance expressions created by the selected Network Formulations.

Constraints:

\[\begin{aligned} & P^\text{re,min} \le p_t^\text{re} \le \text{ActivePowerTimeSeriesParameter}_t, \quad \forall t \in \{1,\dots, T\} \\ & Q^\text{re,min} \le q_t^\text{re} \le Q^\text{re,max}, \quad \forall t \in \{1,\dots, T\} -\end{aligned}\]

RenewableConstantPowerFactor

Variables:

  • ActivePowerVariable:

    • Bounds: [0.0, ]
    • Default initial value: PowerSystems.get_active_power(device)
    • Symbol: $p^\text{re}$

  • ReactivePowerVariable:

    • Bounds: [0.0, ]
    • Default initial value: PowerSystems.get_reactive_power(device)
    • Symbol: $q^\text{re}$

Static Parameters:

  • $P^\text{re,min}$ = PowerSystems.get_active_power_limits(device).min
  • $Q^\text{re,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{re,max}$ = PowerSystems.get_reactive_power_limits(device).max
  • $\text{pf}$ = PowerSystems.get_power_factor(device)

Time Series Parameters:

ParameterDefault Time Series Name
ReactivePowerTimeSeriesParametermax_active_power
ActivePowerTimeSeriesParametermax_active_power

Objective:

Creates an objective function term based on the FunctionData Options where the quantity term is defined as $- p_t^\text{re}$ to incentivize generation from RenewableGen devices.

Expressions:

Adds $p^\text{re}$ and $q^\text{re}$ terms to the respective active and reactive power balance expressions created by the selected Network Formulations

Constraints:

\[\begin{aligned} +\end{aligned}\]

RenewableConstantPowerFactor

Variables:

  • ActivePowerVariable:

    • Bounds: [0.0, ]
    • Default initial value: PowerSystems.get_active_power(device)
    • Symbol: $p^\text{re}$

  • ReactivePowerVariable:

    • Bounds: [0.0, ]
    • Default initial value: PowerSystems.get_reactive_power(device)
    • Symbol: $q^\text{re}$

Static Parameters:

  • $P^\text{re,min}$ = PowerSystems.get_active_power_limits(device).min
  • $Q^\text{re,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{re,max}$ = PowerSystems.get_reactive_power_limits(device).max
  • $\text{pf}$ = PowerSystems.get_power_factor(device)

Time Series Parameters:

ParameterDefault Time Series Name
ActivePowerTimeSeriesParametermax_active_power
ReactivePowerTimeSeriesParametermax_active_power

Objective:

Creates an objective function term based on the FunctionData Options where the quantity term is defined as $- p_t^\text{re}$ to incentivize generation from RenewableGen devices.

Expressions:

Adds $p^\text{re}$ and $q^\text{re}$ terms to the respective active and reactive power balance expressions created by the selected Network Formulations

Constraints:

\[\begin{aligned} & P^\text{re,min} \le p_t^\text{re} \le \text{ActivePowerTimeSeriesParameter}_t, \quad \forall t \in \{1,\dots, T\} \\ & q_t^\text{re} = \text{pf} \cdot p_t^\text{re}, \quad \forall t \in \{1,\dots, T\} -\end{aligned}\]

Valid configurations

Valid DeviceModels for subtypes of RenewableGen include the following:

Valid DeviceModelDevice TypeFormulation
DeviceModel(RenewableDispatch, FixedOutput)RenewableDispatchFixedOutput
DeviceModel(RenewableNonDispatch, FixedOutput)RenewableNonDispatchFixedOutput
DeviceModel(RenewableDispatch, RenewableConstantPowerFactor)RenewableDispatchRenewableConstantPowerFactor
DeviceModel(RenewableNonDispatch, RenewableConstantPowerFactor)RenewableNonDispatchRenewableConstantPowerFactor
DeviceModel(RenewableDispatch, RenewableFullDispatch)RenewableDispatchRenewableFullDispatch
DeviceModel(RenewableNonDispatch, RenewableFullDispatch)RenewableNonDispatchRenewableFullDispatch
+\end{aligned}\]

Valid configurations

Valid DeviceModels for subtypes of RenewableGen include the following:

Valid DeviceModelDevice TypeFormulation
DeviceModel(RenewableDispatch, FixedOutput)RenewableDispatchFixedOutput
DeviceModel(RenewableNonDispatch, FixedOutput)RenewableNonDispatchFixedOutput
DeviceModel(RenewableDispatch, RenewableConstantPowerFactor)RenewableDispatchRenewableConstantPowerFactor
DeviceModel(RenewableNonDispatch, RenewableConstantPowerFactor)RenewableNonDispatchRenewableConstantPowerFactor
DeviceModel(RenewableDispatch, RenewableFullDispatch)RenewableDispatchRenewableFullDispatch
DeviceModel(RenewableNonDispatch, RenewableFullDispatch)RenewableNonDispatchRenewableFullDispatch
diff --git a/dev/formulation_library/Service/index.html b/dev/formulation_library/Service/index.html index 569c43f38..aaf8b463c 100644 --- a/dev/formulation_library/Service/index.html +++ b/dev/formulation_library/Service/index.html @@ -1,11 +1,11 @@ -Services · PowerSimulations.jl
GitHub

PowerSystems.Service Formulations

Services (or ancillary services) are models used to ensure that there is necessary support to the power grid from generators to consumers, in order to ensure reliable operation of the system.

The most common application for ancillary services are reserves, i.e., generation (or load) that is not currently being used, but can be quickly made available in case of unexpected changes of grid conditions, for example a sudden loss of load or generation.

A key challenge of adding services to a system, from a mathematical perspective, is specifying which units contribute to the specified requirement of a service, that implies the creation of new variables (such as reserve variables) and modification of constraints.

In this documentation, we first specify the available Services in the grid, and what requirements impose in the system, and later we discuss the implication on device formulations for specific units.

Table of contents

  1. RangeReserve
  2. StepwiseCostReserve
  3. GroupReserve
  4. RampReserve
  5. NonSpinningReserve
  6. ConstantMaxInterfaceFlow
  7. VariableMaxInterfaceFlow
  8. Changes on Expressions

RangeReserve

For each service $s$ of the model type RangeReserve the following variables are created:

Variables:

  • ActivePowerReserveVariable:

    • Bounds: [0.0, ]
    • Default proportional cost: $1.0 / \text{SystemBasePower}$
    • Symbol: $r_{d}$ for $d$ in contributing devices to the service $s$ If slacks are enabled:

  • ReserveRequirementSlack:

    • Bounds: [0.0, ]
    • Default proportional cost: 1e5
    • Symbol: $r^\text{sl}$

Depending on the PowerSystems.jl type associated to the RangeReserve formulation model, the parameters are:

Static Parameters

  • $\text{PF}$ = PowerSystems.get_max_participation_factor(service)

For a ConstantReserve PowerSystems type:

  • $\text{Req}$ = PowerSystems.get_requirement(service)

Time Series Parameters

For a VariableReserve PowerSystems type:

ParameterDefault Time Series Name
RequirementTimeSeriesParameterrequirement

Relevant Methods:

  • $\mathcal{D}_s$ = PowerSystems.get_contributing_devices(system, service): Set (vector) of all contributing devices to the service $s$ in the system.

Objective:

Add a large proportional cost to the objective function if slack variables are used $+ r^\text{sl} \cdot 10^5$. In addition adds the default cost for ActivePowerReserveVariables as a proportional cost.

Expressions:

Adds the ActivePowerReserveVariable for upper/lower bound expressions of contributing devices.

For ReserveUp types, the variable is added to ActivePowerRangeExpressionUB, such that this expression considers both the ActivePowerVariable and its reserve variable. Similarly, For ReserveDown types, the variable is added to ActivePowerRangeExpressionLB, such that this expression considers both the ActivePowerVariable and its reserve variable

Example: for a thermal unit $d$ contributing to two different ReserveUp $s_1, s_2$ services (e.g. Reg-Up and Spin):

\[\text{ActivePowerRangeExpressionUB}_{t} = p_t^\text{th} + r_{s_1,t} + r_{s_2, t} \le P^\text{th,max}\]

similarly if $s_3$ is a ReserveDown service (e.g. Reg-Down):

\[\text{ActivePowerRangeExpressionLB}_{t} = p_t^\text{th} - r_{s_3,t} \ge P^\text{th,min}\]

Constraints:

A RangeReserve implements two fundamental constraints. The first is that the sum of all reserves of contributing devices must be larger than the RangeReserve requirement. Thus, for a service $s$:

\[\sum_{d\in\mathcal{D}_s} r_{d,t} + r_t^\text{sl} \ge \text{Req},\quad \forall t\in \{1,\dots, T\} \quad \text{(for a ConstantReserve)} \\ +Services · PowerSimulations.jl

GitHub

PowerSystems.Service Formulations

Services (or ancillary services) are models used to ensure that there is necessary support to the power grid from generators to consumers, in order to ensure reliable operation of the system.

The most common application for ancillary services are reserves, i.e., generation (or load) that is not currently being used, but can be quickly made available in case of unexpected changes of grid conditions, for example a sudden loss of load or generation.

A key challenge of adding services to a system, from a mathematical perspective, is specifying which units contribute to the specified requirement of a service, that implies the creation of new variables (such as reserve variables) and modification of constraints.

In this documentation, we first specify the available Services in the grid, and what requirements impose in the system, and later we discuss the implication on device formulations for specific units.

Table of contents

  1. RangeReserve
  2. StepwiseCostReserve
  3. GroupReserve
  4. RampReserve
  5. NonSpinningReserve
  6. ConstantMaxInterfaceFlow
  7. VariableMaxInterfaceFlow
  8. Changes on Expressions

RangeReserve

For each service $s$ of the model type RangeReserve the following variables are created:

Variables:

  • ActivePowerReserveVariable:

    • Bounds: [0.0, ]
    • Default proportional cost: $1.0 / \text{SystemBasePower}$
    • Symbol: $r_{d}$ for $d$ in contributing devices to the service $s$ If slacks are enabled:

  • ReserveRequirementSlack:

    • Bounds: [0.0, ]
    • Default proportional cost: 1e5
    • Symbol: $r^\text{sl}$

Depending on the PowerSystems.jl type associated to the RangeReserve formulation model, the parameters are:

Static Parameters

  • $\text{PF}$ = PowerSystems.get_max_participation_factor(service)

For a ConstantReserve PowerSystems type:

  • $\text{Req}$ = PowerSystems.get_requirement(service)

Time Series Parameters

For a VariableReserve PowerSystems type:

ParameterDefault Time Series Name
RequirementTimeSeriesParameterrequirement

Relevant Methods:

  • $\mathcal{D}_s$ = PowerSystems.get_contributing_devices(system, service): Set (vector) of all contributing devices to the service $s$ in the system.

Objective:

Add a large proportional cost to the objective function if slack variables are used $+ r^\text{sl} \cdot 10^5$. In addition adds the default cost for ActivePowerReserveVariables as a proportional cost.

Expressions:

Adds the ActivePowerReserveVariable for upper/lower bound expressions of contributing devices.

For ReserveUp types, the variable is added to ActivePowerRangeExpressionUB, such that this expression considers both the ActivePowerVariable and its reserve variable. Similarly, For ReserveDown types, the variable is added to ActivePowerRangeExpressionLB, such that this expression considers both the ActivePowerVariable and its reserve variable

Example: for a thermal unit $d$ contributing to two different ReserveUp $s_1, s_2$ services (e.g. Reg-Up and Spin):

\[\text{ActivePowerRangeExpressionUB}_{t} = p_t^\text{th} + r_{s_1,t} + r_{s_2, t} \le P^\text{th,max}\]

similarly if $s_3$ is a ReserveDown service (e.g. Reg-Down):

\[\text{ActivePowerRangeExpressionLB}_{t} = p_t^\text{th} - r_{s_3,t} \ge P^\text{th,min}\]

Constraints:

A RangeReserve implements two fundamental constraints. The first is that the sum of all reserves of contributing devices must be larger than the RangeReserve requirement. Thus, for a service $s$:

\[\sum_{d\in\mathcal{D}_s} r_{d,t} + r_t^\text{sl} \ge \text{Req},\quad \forall t\in \{1,\dots, T\} \quad \text{(for a ConstantReserve)} \\ \sum_{d\in\mathcal{D}_s} r_{d,t} + r_t^\text{sl} \ge \text{RequirementTimeSeriesParameter}_{t},\quad \forall t\in \{1,\dots, T\} \quad \text{(for a VariableReserve)}\]

In addition, there is a restriction on how much each contributing device $d$ can contribute to the requirement, based on the max participation factor allowed.

\[r_{d,t} \le \text{Req} \cdot \text{PF} ,\quad \forall d\in \mathcal{D}_s, \forall t\in \{1,\dots, T\} \quad \text{(for a ConstantReserve)} \\ -r_{d,t} \le \text{RequirementTimeSeriesParameter}_{t} \cdot \text{PF}\quad \forall d\in \mathcal{D}_s, \forall t\in \{1,\dots, T\}, \quad \text{(for a VariableReserve)}\]

StepwiseCostReserve

Service must be used with ReserveDemandCurve PowerSystems.jl type. This service model is used to model ORDC (Operating Reserve Demand Curve) in ERCOT.

For each service $s$ of the model type ReserveDemandCurve the following variables are created:

Variables:

Time Series Parameters

For a ReserveDemandCurve PowerSystems type:

| Parameter | Default Time Series Name |

Relevant Methods:

  • $\mathcal{D}_s$ = PowerSystems.get_contributing_devices(system, service): Set (vector) of all contributing devices to the service $s$ in the system.

Objective:

The ServiceRequirementVariable is added as a piecewise linear cost based on the decreasing offers listed in the variable_cost time series. These decreasing cost represent the scarcity prices of not having sufficient reserves. For example, if the variable $\text{req} = 0$, then a really high cost is paid for not having enough reserves, and if $\text{req}$ is larger, then a lower cost (or even zero) is paid.

Expressions:

Adds the ActivePowerReserveVariable for upper/lower bound expressions of contributing devices.

For ReserveUp types, the variable is added to ActivePowerRangeExpressionUB, such that this expression considers both the ActivePowerVariable and its reserve variable. Similarly, For ReserveDown types, the variable is added to ActivePowerRangeExpressionLB, such that this expression considers both the ActivePowerVariable and its reserve variable

Example: for a thermal unit $d$ contributing to two different ReserveUp $s_1, s_2$ services (e.g. Reg-Up and Spin):

\[\text{ActivePowerRangeExpressionUB}_{t} = p_t^\text{th} + r_{s_1,t} + r_{s_2, t} \le P^\text{th,max}\]

similarly if $s_3$ is a ReserveDown service (e.g. Reg-Down):

\[\text{ActivePowerRangeExpressionLB}_{t} = p_t^\text{th} - r_{s_3,t} \ge P^\text{th,min}\]

Constraints:

A StepwiseCostReserve implements a single constraint, such that the sum of all reserves of contributing devices must be larger than the ServiceRequirementVariable variable. Thus, for a service $s$:

\[\sum_{d\in\mathcal{D}_s} r_{d,t} \ge \text{req}_t,\quad \forall t\in \{1,\dots, T\} \]

GroupReserve

Service must be used with ConstantReserveGroup PowerSystems.jl type. This service model is used to model an aggregation of services.

For each service $s$ of the model type GroupReserve the following variables are created:

Variables:

No variables are created, but the services associated with the GroupReserve must have created variables.

Static Parameters

  • $\text{Req}$ = PowerSystems.get_requirement(service)

Relevant Methods:

  • $\mathcal{S}_s$ = PowerSystems.get_contributing_services(system, service): Set (vector) of all contributing services to the group service $s$ in the system.
  • $\mathcal{D}_{s_i}$ = PowerSystems.get_contributing_devices(system, service_aux): Set (vector) of all contributing devices to the service $s_i$ in the system.

Objective:

Does not modify the objective function, besides the changes to the objective function due to the other services associated to the group service.

Expressions:

No changes, besides the changes to the expressions due to the other services associated to the group service.

Constraints:

A GroupReserve implements that the sum of all reserves of contributing devices, of all contributing services, must be larger than the GroupReserve requirement. Thus, for a GroupReserve service $s$:

\[\sum_{d\in\mathcal{D}_{s_i}} \sum_{i \in \mathcal{S}_s} r_{d,t} \ge \text{Req},\quad \forall t\in \{1,\dots, T\} \]

RampReserve

For each service $s$ of the model type RampReserve the following variables are created:

Variables:

  • ActivePowerReserveVariable:

    • Bounds: [0.0, ]
    • Default proportional cost: $1.0 / \text{SystemBasePower}$
    • Symbol: $r_{d}$ for $d$ in contributing devices to the service $s$ If slacks are enabled:

  • ReserveRequirementSlack:

    • Bounds: [0.0, ]
    • Default proportional cost: 1e5
    • Symbol: $r^\text{sl}$

RampReserve only accepts VariableReserve PowerSystems.jl type. With that, the parameters are:

Static Parameters

  • $\text{TF}$ = PowerSystems.get_time_frame(service)
  • $R^\text{th,up}$ = PowerSystems.get_ramp_limits(device).up for thermal contributing devices
  • $R^\text{th,dn}$ = PowerSystems.get_ramp_limits(device).down for thermal contributing devices

Time Series Parameters

For a VariableReserve PowerSystems type:

ParameterDefault Time Series Name
RequirementTimeSeriesParameterrequirement

Relevant Methods:

  • $\mathcal{D}_s$ = PowerSystems.get_contributing_devices(system, service): Set (vector) of all contributing devices to the service $s$ in the system.

Objective:

Add a large proportional cost to the objective function if slack variables are used $+ r^\text{sl} \cdot 10^5$. In addition adds the default cost for ActivePowerReserveVariables as a proportional cost.

Expressions:

Adds the ActivePowerReserveVariable for upper/lower bound expressions of contributing devices.

For ReserveUp types, the variable is added to ActivePowerRangeExpressionUB, such that this expression considers both the ActivePowerVariable and its reserve variable. Similarly, For ReserveDown types, the variable is added to ActivePowerRangeExpressionLB, such that this expression considers both the ActivePowerVariable and its reserve variable

Example: for a thermal unit $d$ contributing to two different ReserveUp $s_1, s_2$ services (e.g. Reg-Up and Spin):

\[\text{ActivePowerRangeExpressionUB}_{t} = p_t^\text{th} + r_{s_1,t} + r_{s_2, t} \le P^\text{th,max}\]

similarly if $s_3$ is a ReserveDown service (e.g. Reg-Down):

\[\text{ActivePowerRangeExpressionLB}_{t} = p_t^\text{th} - r_{s_3,t} \ge P^\text{th,min}\]

Constraints:

A RampReserve implements three fundamental constraints. The first is that the sum of all reserves of contributing devices must be larger than the RampReserve requirement. Thus, for a service $s$:

\[\sum_{d\in\mathcal{D}_s} r_{d,t} + r_t^\text{sl} \ge \text{RequirementTimeSeriesParameter}_{t},\quad \forall t\in \{1,\dots, T\}\]

Finally, there is a restriction based on the ramp limits of the contributing devices:

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

NonSpinningReserve

For each service $s$ of the model type NonSpinningReserve, the following variables are created:

Variables:

  • ActivePowerReserveVariable:

    • Bounds: [0.0, ]
    • Default proportional cost: $1.0 / \text{SystemBasePower}$
    • Symbol: $r_{d}$ for $d$ in contributing devices to the service $s$ If slacks are enabled:

  • ReserveRequirementSlack:

    • Bounds: [0.0, ]
    • Default proportional cost: 1e5
    • Symbol: $r^\text{sl}$

NonSpinningReserve only accepts VariableReserve PowerSystems.jl type. With that, the parameters are:

Static Parameters

  • $\text{PF}$ = PowerSystems.get_max_participation_factor(service)
  • $\text{TF}$ = PowerSystems.get_time_frame(service)
  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min for thermal contributing devices
  • $T^\text{st,up}$ = PowerSystems.get_time_limits(d).up for thermal contributing devices
  • $R^\text{th,up}$ = PowerSystems.get_ramp_limits(device).down for thermal contributing devices

Other parameters:

  • $\Delta T$: Resolution of the problem in minutes.

Time Series Parameters

For a VariableReserve PowerSystems type:

| Parameter | Default Time Series Name |

Relevant Methods:

  • $\mathcal{D}_s$ = PowerSystems.get_contributing_devices(system, service): Set (vector) of all contributing devices to the service $s$ in the system.

Objective:

Add a large proportional cost to the objective function if slack variables are used $+ r^\text{sl} \cdot 10^5$. In addition adds the default cost for ActivePowerReserveVariables as a proportional cost.

Expressions:

Adds the ActivePowerReserveVariable for upper/lower bound expressions of contributing devices.

For ReserveUp types, the variable is added to ActivePowerRangeExpressionUB, such that this expression considers both the ActivePowerVariable and its reserve variable. Similarly, For ReserveDown types, the variable is added to ActivePowerRangeExpressionLB, such that this expression considers both the ActivePowerVariable and its reserve variable

Example: for a thermal unit $d$ contributing to two different ReserveUp $s_1, s_2$ services (e.g. Reg-Up and Spin):

\[\text{ActivePowerRangeExpressionUB}_{t} = p_t^\text{th} + r_{s_1,t} + r_{s_2, t} \le P^\text{th,max}\]

similarly if $s_3$ is a ReserveDown service (e.g. Reg-Down):

\[\text{ActivePowerRangeExpressionLB}_{t} = p_t^\text{th} - r_{s_3,t} \ge P^\text{th,min}\]

Constraints:

A NonSpinningReserve implements three fundamental constraints. The first is that the sum of all reserves of contributing devices must be larger than the NonSpinningReserve requirement. Thus, for a service $s$:

\[\sum_{d\in\mathcal{D}_s} r_{d,t} + r_t^\text{sl} \ge \text{RequirementTimeSeriesParameter}_{t},\quad \forall t\in \{1,\dots, T\}\]

In addition, there is a restriction on how much each contributing device $d$ can contribute to the requirement, based on the max participation factor allowed.

\[r_{d,t} \le \text{RequirementTimeSeriesParameter}_{t} \cdot \text{PF}\quad \forall d\in \mathcal{D}_s, \forall t\in \{1,\dots, T\},\]

Finally, there is a restriction based on the reserve response time for the non-spinning reserve if the unit is off. To do so, compute $R^\text{limit}_d$ as the reserve response limit as:

\[R^\text{limit}_d = \begin{cases} +r_{d,t} \le \text{RequirementTimeSeriesParameter}_{t} \cdot \text{PF}\quad \forall d\in \mathcal{D}_s, \forall t\in \{1,\dots, T\}, \quad \text{(for a VariableReserve)}\]

StepwiseCostReserve

Service must be used with ReserveDemandCurve PowerSystems.jl type. This service model is used to model ORDC (Operating Reserve Demand Curve) in ERCOT.

For each service $s$ of the model type ReserveDemandCurve the following variables are created:

Variables:

Time Series Parameters

For a ReserveDemandCurve PowerSystems type:

| Parameter | Default Time Series Name |

Relevant Methods:

  • $\mathcal{D}_s$ = PowerSystems.get_contributing_devices(system, service): Set (vector) of all contributing devices to the service $s$ in the system.

Objective:

The ServiceRequirementVariable is added as a piecewise linear cost based on the decreasing offers listed in the variable_cost time series. These decreasing cost represent the scarcity prices of not having sufficient reserves. For example, if the variable $\text{req} = 0$, then a really high cost is paid for not having enough reserves, and if $\text{req}$ is larger, then a lower cost (or even zero) is paid.

Expressions:

Adds the ActivePowerReserveVariable for upper/lower bound expressions of contributing devices.

For ReserveUp types, the variable is added to ActivePowerRangeExpressionUB, such that this expression considers both the ActivePowerVariable and its reserve variable. Similarly, For ReserveDown types, the variable is added to ActivePowerRangeExpressionLB, such that this expression considers both the ActivePowerVariable and its reserve variable

Example: for a thermal unit $d$ contributing to two different ReserveUp $s_1, s_2$ services (e.g. Reg-Up and Spin):

\[\text{ActivePowerRangeExpressionUB}_{t} = p_t^\text{th} + r_{s_1,t} + r_{s_2, t} \le P^\text{th,max}\]

similarly if $s_3$ is a ReserveDown service (e.g. Reg-Down):

\[\text{ActivePowerRangeExpressionLB}_{t} = p_t^\text{th} - r_{s_3,t} \ge P^\text{th,min}\]

Constraints:

A StepwiseCostReserve implements a single constraint, such that the sum of all reserves of contributing devices must be larger than the ServiceRequirementVariable variable. Thus, for a service $s$:

\[\sum_{d\in\mathcal{D}_s} r_{d,t} \ge \text{req}_t,\quad \forall t\in \{1,\dots, T\} \]

GroupReserve

Service must be used with ConstantReserveGroup PowerSystems.jl type. This service model is used to model an aggregation of services.

For each service $s$ of the model type GroupReserve the following variables are created:

Variables:

No variables are created, but the services associated with the GroupReserve must have created variables.

Static Parameters

  • $\text{Req}$ = PowerSystems.get_requirement(service)

Relevant Methods:

  • $\mathcal{S}_s$ = PowerSystems.get_contributing_services(system, service): Set (vector) of all contributing services to the group service $s$ in the system.
  • $\mathcal{D}_{s_i}$ = PowerSystems.get_contributing_devices(system, service_aux): Set (vector) of all contributing devices to the service $s_i$ in the system.

Objective:

Does not modify the objective function, besides the changes to the objective function due to the other services associated to the group service.

Expressions:

No changes, besides the changes to the expressions due to the other services associated to the group service.

Constraints:

A GroupReserve implements that the sum of all reserves of contributing devices, of all contributing services, must be larger than the GroupReserve requirement. Thus, for a GroupReserve service $s$:

\[\sum_{d\in\mathcal{D}_{s_i}} \sum_{i \in \mathcal{S}_s} r_{d,t} \ge \text{Req},\quad \forall t\in \{1,\dots, T\} \]

RampReserve

For each service $s$ of the model type RampReserve the following variables are created:

Variables:

  • ActivePowerReserveVariable:

    • Bounds: [0.0, ]
    • Default proportional cost: $1.0 / \text{SystemBasePower}$
    • Symbol: $r_{d}$ for $d$ in contributing devices to the service $s$ If slacks are enabled:

  • ReserveRequirementSlack:

    • Bounds: [0.0, ]
    • Default proportional cost: 1e5
    • Symbol: $r^\text{sl}$

RampReserve only accepts VariableReserve PowerSystems.jl type. With that, the parameters are:

Static Parameters

  • $\text{TF}$ = PowerSystems.get_time_frame(service)
  • $R^\text{th,up}$ = PowerSystems.get_ramp_limits(device).up for thermal contributing devices
  • $R^\text{th,dn}$ = PowerSystems.get_ramp_limits(device).down for thermal contributing devices

Time Series Parameters

For a VariableReserve PowerSystems type:

ParameterDefault Time Series Name
RequirementTimeSeriesParameterrequirement

Relevant Methods:

  • $\mathcal{D}_s$ = PowerSystems.get_contributing_devices(system, service): Set (vector) of all contributing devices to the service $s$ in the system.

Objective:

Add a large proportional cost to the objective function if slack variables are used $+ r^\text{sl} \cdot 10^5$. In addition adds the default cost for ActivePowerReserveVariables as a proportional cost.

Expressions:

Adds the ActivePowerReserveVariable for upper/lower bound expressions of contributing devices.

For ReserveUp types, the variable is added to ActivePowerRangeExpressionUB, such that this expression considers both the ActivePowerVariable and its reserve variable. Similarly, For ReserveDown types, the variable is added to ActivePowerRangeExpressionLB, such that this expression considers both the ActivePowerVariable and its reserve variable

Example: for a thermal unit $d$ contributing to two different ReserveUp $s_1, s_2$ services (e.g. Reg-Up and Spin):

\[\text{ActivePowerRangeExpressionUB}_{t} = p_t^\text{th} + r_{s_1,t} + r_{s_2, t} \le P^\text{th,max}\]

similarly if $s_3$ is a ReserveDown service (e.g. Reg-Down):

\[\text{ActivePowerRangeExpressionLB}_{t} = p_t^\text{th} - r_{s_3,t} \ge P^\text{th,min}\]

Constraints:

A RampReserve implements three fundamental constraints. The first is that the sum of all reserves of contributing devices must be larger than the RampReserve requirement. Thus, for a service $s$:

\[\sum_{d\in\mathcal{D}_s} r_{d,t} + r_t^\text{sl} \ge \text{RequirementTimeSeriesParameter}_{t},\quad \forall t\in \{1,\dots, T\}\]

Finally, there is a restriction based on the ramp limits of the contributing devices:

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

NonSpinningReserve

For each service $s$ of the model type NonSpinningReserve, the following variables are created:

Variables:

  • ActivePowerReserveVariable:

    • Bounds: [0.0, ]
    • Default proportional cost: $1.0 / \text{SystemBasePower}$
    • Symbol: $r_{d}$ for $d$ in contributing devices to the service $s$ If slacks are enabled:

  • ReserveRequirementSlack:

    • Bounds: [0.0, ]
    • Default proportional cost: 1e5
    • Symbol: $r^\text{sl}$

NonSpinningReserve only accepts VariableReserve PowerSystems.jl type. With that, the parameters are:

Static Parameters

  • $\text{PF}$ = PowerSystems.get_max_participation_factor(service)
  • $\text{TF}$ = PowerSystems.get_time_frame(service)
  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min for thermal contributing devices
  • $T^\text{st,up}$ = PowerSystems.get_time_limits(d).up for thermal contributing devices
  • $R^\text{th,up}$ = PowerSystems.get_ramp_limits(device).down for thermal contributing devices

Other parameters:

  • $\Delta T$: Resolution of the problem in minutes.

Time Series Parameters

For a VariableReserve PowerSystems type:

| Parameter | Default Time Series Name |

Relevant Methods:

  • $\mathcal{D}_s$ = PowerSystems.get_contributing_devices(system, service): Set (vector) of all contributing devices to the service $s$ in the system.

Objective:

Add a large proportional cost to the objective function if slack variables are used $+ r^\text{sl} \cdot 10^5$. In addition adds the default cost for ActivePowerReserveVariables as a proportional cost.

Expressions:

Adds the ActivePowerReserveVariable for upper/lower bound expressions of contributing devices.

For ReserveUp types, the variable is added to ActivePowerRangeExpressionUB, such that this expression considers both the ActivePowerVariable and its reserve variable. Similarly, For ReserveDown types, the variable is added to ActivePowerRangeExpressionLB, such that this expression considers both the ActivePowerVariable and its reserve variable

Example: for a thermal unit $d$ contributing to two different ReserveUp $s_1, s_2$ services (e.g. Reg-Up and Spin):

\[\text{ActivePowerRangeExpressionUB}_{t} = p_t^\text{th} + r_{s_1,t} + r_{s_2, t} \le P^\text{th,max}\]

similarly if $s_3$ is a ReserveDown service (e.g. Reg-Down):

\[\text{ActivePowerRangeExpressionLB}_{t} = p_t^\text{th} - r_{s_3,t} \ge P^\text{th,min}\]

Constraints:

A NonSpinningReserve implements three fundamental constraints. The first is that the sum of all reserves of contributing devices must be larger than the NonSpinningReserve requirement. Thus, for a service $s$:

\[\sum_{d\in\mathcal{D}_s} r_{d,t} + r_t^\text{sl} \ge \text{RequirementTimeSeriesParameter}_{t},\quad \forall t\in \{1,\dots, T\}\]

In addition, there is a restriction on how much each contributing device $d$ can contribute to the requirement, based on the max participation factor allowed.

\[r_{d,t} \le \text{RequirementTimeSeriesParameter}_{t} \cdot \text{PF}\quad \forall d\in \mathcal{D}_s, \forall t\in \{1,\dots, T\},\]

Finally, there is a restriction based on the reserve response time for the non-spinning reserve if the unit is off. To do so, compute $R^\text{limit}_d$ as the reserve response limit as:

\[R^\text{limit}_d = \begin{cases} 0 & \text{ if TF } \le T^\text{st,up}_d \\ P^\text{th,min}_d + (\text{TF}_s - T^\text{st,up}_d) \cdot R^\text{th,up}_d \Delta T \cdot R^\text{th,up}_d & \text{ if TF } > T^\text{st,up}_d -\end{cases}, \quad \forall d\in \mathcal{D}_s\]

Then, the constraint depends on the commitment variable $u_t^\text{th}$ as:

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

ConstantMaxInterfaceFlow

This Service model only accepts the PowerSystems.jl TransmissionInterface type to properly function. It is used to model a collection of branches that make up an interface or corridor with a maximum transfer of power.

Variables

If slacks are used:

Static Parameters

  • $F^\text{max}$ = PowerSystems.get_active_power_flow_limits(service).max
  • $F^\text{min}$ = PowerSystems.get_active_power_flow_limits(service).min
  • $C^\text{flow}$ = PowerSystems.get_violation_penalty(service)
  • $\mathcal{M}_s$ = PowerSystems.get_direction_mapping(service). Dictionary of contributing branches with its specified direction ($\text{Dir}_d = 1$ or $\text{Dir}_d = -1$) with respect to the interface.

Relevant Methods

  • $\mathcal{D}_s$ = PowerSystems.get_contributing_devices(system, service): Set (vector) of all contributing branches to the service $s$ in the system.

Objective:

Add the violation penalty proportional cost to the objective function if slack variables are used $+ (f^\text{sl,up} + f^\text{sl,dn}) \cdot C^\text{flow}$.

Expressions:

Creates the expression InterfaceTotalFlow to keep track of all FlowActivePowerVariable of contributing branches to the transmission interface.

Constraints:

It adds the constraint to limit the InterfaceTotalFlow by the specified bounds of the service $s$:

\[F^\text{min} \le f^\text{sl,up}_t - f^\text{sl,dn}_t + \sum_{d\in\mathcal{D}_s} \text{Dir}_d f_{d,t} \le F^\text{max}, \quad \forall t \in \{1,\dots,T\}\]

VariableMaxInterfaceFlow

This Service model only accepts the PowerSystems.jl TransmissionInterface type to properly function. It is used to model a collection of branches that make up an interface or corridor with a maximum transfer of power.

Variables

If slacks are used:

Static Parameters

  • $F^\text{max}$ = PowerSystems.get_active_power_flow_limits(service).max
  • $F^\text{min}$ = PowerSystems.get_active_power_flow_limits(service).min
  • $C^\text{flow}$ = PowerSystems.get_violation_penalty(service)
  • $\mathcal{M}_s$ = PowerSystems.get_direction_mapping(service). Dictionary of contributing branches with its specified direction ($\text{Dir}_d = 1$ or $\text{Dir}_d = -1$) with respect to the interface.

Time Series Parameters

For a TransmissionInterface PowerSystems type:

ParameterDefault Time Series Name
PowerSimulations.MinInterfaceFlowLimitParametermin_active_power_flow_limit
PowerSimulations.MaxInterfaceFlowLimitParametermax_active_power_flow_limit

Relevant Methods

  • $\mathcal{D}_s$ = PowerSystems.get_contributing_devices(system, service): Set (vector) of all contributing branches to the service $s$ in the system.

Objective:

Add the violation penalty proportional cost to the objective function if slack variables are used $+ (f^\text{sl,up} + f^\text{sl,dn}) \cdot C^\text{flow}$.

Expressions:

Creates the expression InterfaceTotalFlow to keep track of all FlowActivePowerVariable of contributing branches to the transmission interface.

Constraints:

It adds the constraint to limit the InterfaceTotalFlow by the specified bounds of the service $s$:

\[F^\text{min} \cdot \text{MinInterfaceFlowLimitParameter}_t \le f^\text{sl,up}_t - f^\text{sl,dn}_t + \sum_{d\in\mathcal{D}_s} \text{Dir}_d f_{d,t} \le F^\text{max}\cdot \text{MaxInterfaceFlowLimitParameter}_t, \quad \forall t \in \{1,\dots,T\}\]

Changes on Expressions due to Service models

It is important to note that by adding a service to a Optimization Problem, variables for each contributing device must be created. For example, for every contributing generator $d \in \mathcal{D}$ that is participating in services $s_1,s_2,s_3$, it is required to create three set of ActivePowerReserveVariable variables:

\[r_{s_1,d,t},~ r_{s_2,d,t},~ r_{s_3,d,t},\quad \forall d \in \mathcal{D}, \forall t \in \{1,\dots, T\}\]

Changes on UpperBound (UB) and LowerBound (LB) limits

Each contributing generator $d$ has active power limits that the reserve variables affect. In simple terms, the limits are implemented using expressions ActivePowerRangeExpressionUB and ActivePowerRangeExpressionLB as:

\[\text{ActivePowerRangeExpressionUB}_t \le P^\text{max} \\ +\end{cases}, \quad \forall d\in \mathcal{D}_s\]

Then, the constraint depends on the commitment variable $u_t^\text{th}$ as:

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

ConstantMaxInterfaceFlow

This Service model only accepts the PowerSystems.jl TransmissionInterface type to properly function. It is used to model a collection of branches that make up an interface or corridor with a maximum transfer of power.

Variables

If slacks are used:

Static Parameters

  • $F^\text{max}$ = PowerSystems.get_active_power_flow_limits(service).max
  • $F^\text{min}$ = PowerSystems.get_active_power_flow_limits(service).min
  • $C^\text{flow}$ = PowerSystems.get_violation_penalty(service)
  • $\mathcal{M}_s$ = PowerSystems.get_direction_mapping(service). Dictionary of contributing branches with its specified direction ($\text{Dir}_d = 1$ or $\text{Dir}_d = -1$) with respect to the interface.

Relevant Methods

  • $\mathcal{D}_s$ = PowerSystems.get_contributing_devices(system, service): Set (vector) of all contributing branches to the service $s$ in the system.

Objective:

Add the violation penalty proportional cost to the objective function if slack variables are used $+ (f^\text{sl,up} + f^\text{sl,dn}) \cdot C^\text{flow}$.

Expressions:

Creates the expression InterfaceTotalFlow to keep track of all FlowActivePowerVariable of contributing branches to the transmission interface.

Constraints:

It adds the constraint to limit the InterfaceTotalFlow by the specified bounds of the service $s$:

\[F^\text{min} \le f^\text{sl,up}_t - f^\text{sl,dn}_t + \sum_{d\in\mathcal{D}_s} \text{Dir}_d f_{d,t} \le F^\text{max}, \quad \forall t \in \{1,\dots,T\}\]

VariableMaxInterfaceFlow

This Service model only accepts the PowerSystems.jl TransmissionInterface type to properly function. It is used to model a collection of branches that make up an interface or corridor with a maximum transfer of power.

Variables

If slacks are used:

Static Parameters

  • $F^\text{max}$ = PowerSystems.get_active_power_flow_limits(service).max
  • $F^\text{min}$ = PowerSystems.get_active_power_flow_limits(service).min
  • $C^\text{flow}$ = PowerSystems.get_violation_penalty(service)
  • $\mathcal{M}_s$ = PowerSystems.get_direction_mapping(service). Dictionary of contributing branches with its specified direction ($\text{Dir}_d = 1$ or $\text{Dir}_d = -1$) with respect to the interface.

Time Series Parameters

For a TransmissionInterface PowerSystems type:

ParameterDefault Time Series Name
PowerSimulations.MinInterfaceFlowLimitParametermin_active_power_flow_limit
PowerSimulations.MaxInterfaceFlowLimitParametermax_active_power_flow_limit

Relevant Methods

  • $\mathcal{D}_s$ = PowerSystems.get_contributing_devices(system, service): Set (vector) of all contributing branches to the service $s$ in the system.

Objective:

Add the violation penalty proportional cost to the objective function if slack variables are used $+ (f^\text{sl,up} + f^\text{sl,dn}) \cdot C^\text{flow}$.

Expressions:

Creates the expression InterfaceTotalFlow to keep track of all FlowActivePowerVariable of contributing branches to the transmission interface.

Constraints:

It adds the constraint to limit the InterfaceTotalFlow by the specified bounds of the service $s$:

\[F^\text{min} \cdot \text{MinInterfaceFlowLimitParameter}_t \le f^\text{sl,up}_t - f^\text{sl,dn}_t + \sum_{d\in\mathcal{D}_s} \text{Dir}_d f_{d,t} \le F^\text{max}\cdot \text{MaxInterfaceFlowLimitParameter}_t, \quad \forall t \in \{1,\dots,T\}\]

Changes on Expressions due to Service models

It is important to note that by adding a service to a Optimization Problem, variables for each contributing device must be created. For example, for every contributing generator $d \in \mathcal{D}$ that is participating in services $s_1,s_2,s_3$, it is required to create three set of ActivePowerReserveVariable variables:

\[r_{s_1,d,t},~ r_{s_2,d,t},~ r_{s_3,d,t},\quad \forall d \in \mathcal{D}, \forall t \in \{1,\dots, T\}\]

Changes on UpperBound (UB) and LowerBound (LB) limits

Each contributing generator $d$ has active power limits that the reserve variables affect. In simple terms, the limits are implemented using expressions ActivePowerRangeExpressionUB and ActivePowerRangeExpressionLB as:

\[\text{ActivePowerRangeExpressionUB}_t \le P^\text{max} \\ \text{ActivePowerRangeExpressionLB}_t \ge P^\text{min}\]

ReserveUp type variables contribute to the upper bound expression, while ReserveDown variables contribute to the lower bound expressions. So if $s_1,s_2$ are ReserveUp services, and $s_3$ is a ReserveDown service, then for a thermal generator $d$ using a ThermalStandardDispatch:

\[\begin{align*} & p_{d,t}^\text{th} + r_{s_1,d,t} + r_{s_2,d,t} \le P^\text{th,max},\quad \forall d\in \mathcal{D}^\text{th}, \forall t \in \{1,\dots,T\} \\ & p_{d,t}^\text{th} - r_{s_3,d,t} \ge P^\text{th,min},\quad \forall d\in \mathcal{D}^\text{th}, \forall t \in \{1,\dots,T\} @@ -15,4 +15,4 @@ \end{align*}\]

Changes in Ramp limits

For the case of Ramp Limits (of formulation that model these limits), the reserve variables only affect the current time, and not the previous time. Then, for the same example as before:

\[\begin{align*} & p_{d,t}^\text{th} + r_{s_1,d,t} + r_{s_2,d,t} - p_{d,t-1}^\text{th}\le R^\text{th,up},\quad \forall d\in \mathcal{D}^\text{th}, \forall t \in \{1,\dots,T\}\\ & p_{d,t}^\text{th} - r_{s_3,d,t} - p_{d,t-1}^\text{th} \ge -R^\text{th,dn},\quad \forall d\in \mathcal{D}^\text{th}, \forall t \in \{1,\dots,T\} -\end{align*}\]

+\end{align*}\]

diff --git a/dev/formulation_library/ThermalGen/index.html b/dev/formulation_library/ThermalGen/index.html index bae00803f..d1458d7ae 100644 --- a/dev/formulation_library/ThermalGen/index.html +++ b/dev/formulation_library/ThermalGen/index.html @@ -1,33 +1,33 @@ -Thermal Generation · PowerSimulations.jl
GitHub

ThermalGen Formulations

Thermal generation formulations define the optimization models that describe thermal units mathematical model in different operational settings, such as economic dispatch and unit commitment.

Note

Thermal units can include multiple terms added to the objective function, such as no-load cost, turn-on/off cost, fixed cost and variable cost. In addition, variable costs can be linear, quadratic or piecewise-linear formulations. These methods are properly described in the cost function page.

Note

The use of reactive power variables and constraints will depend on the network model used, i.e., whether it uses (or does not use) reactive power. If the network model is purely active power-based, reactive power variables and related constraints are not created.

Note

Reserve variables for services are not included in the formulation, albeit their inclusion change the variables, expressions, constraints and objective functions created. A detailed description of the implications in the optimization models is described in the Service formulation section.

Table of Contents

  1. ThermalBasicDispatch
  2. ThermalDispatchNoMin
  3. ThermalCompactDispatch
  4. ThermalStandardDispatch
  5. ThermalBasicUnitCommitment
  6. ThermalBasicCompactUnitCommitment
  7. ThermalStandardUnitCommitment
  8. ThermalMultiStartUnitCommitment
  9. Valid configurations

ThermalBasicDispatch

Variables:

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters.

\[\begin{align*} +Thermal Generation · PowerSimulations.jl

GitHub

ThermalGen Formulations

Thermal generation formulations define the optimization models that describe thermal units mathematical model in different operational settings, such as economic dispatch and unit commitment.

Note

Thermal units can include multiple terms added to the objective function, such as no-load cost, turn-on/off cost, fixed cost and variable cost. In addition, variable costs can be linear, quadratic or piecewise-linear formulations. These methods are properly described in the cost function page.

Note

The use of reactive power variables and constraints will depend on the network model used, i.e., whether it uses (or does not use) reactive power. If the network model is purely active power-based, reactive power variables and related constraints are not created.

Note

Reserve variables for services are not included in the formulation, albeit their inclusion change the variables, expressions, constraints and objective functions created. A detailed description of the implications in the optimization models is described in the Service formulation section.

Table of Contents

  1. ThermalBasicDispatch
  2. ThermalDispatchNoMin
  3. ThermalCompactDispatch
  4. ThermalStandardDispatch
  5. ThermalBasicUnitCommitment
  6. ThermalBasicCompactUnitCommitment
  7. ThermalStandardUnitCommitment
  8. ThermalMultiStartUnitCommitment
  9. Valid configurations

ThermalBasicDispatch

Variables:

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters.

\[\begin{align*} & P^\text{th,min} \le p^\text{th}_t \le P^\text{th,max}, \quad \forall t\in \{1, \dots, T\} \\ & Q^\text{th,min} \le q^\text{th}_t \le Q^\text{th,max}, \quad \forall t\in \{1, \dots, T\} -\end{align*}\]

ThermalDispatchNoMin

Variables:

Static Parameters:

  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters.

\[\begin{align} +\end{align*}\]

ThermalDispatchNoMin

Variables:

Static Parameters:

  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters.

\[\begin{align} & 0 \le p^\text{th}_t \le P^\text{th,max}, \quad \forall t\in \{1, \dots, T\} \\ & Q^\text{th,min} \le q^\text{th}_t \le Q^\text{th,max}, \quad \forall t\in \{1, \dots, T\} -\end{align}\]

ThermalCompactDispatch

Variables:

Auxiliary Variables:

  • PowerOutput:
    • Symbol: $P^\text{th}$
    • Definition: $P^\text{th} = \text{on}^\text{th}P^\text{min} + \Delta p^\text{th}$

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max
  • $R^\text{th,up}$ = PowerSystems.get_ramp_limits(device).up
  • $R^\text{th,dn}$ = PowerSystems.get_ramp_limits(device).down

Variable Value Parameters:

  • $\text{on}^\text{th}$: Used in feedforwards to define if the unit is on/off at each time-step from another problem. If no feedforward is used, the parameter takes a {0,1} value if the unit is available or not.

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $\text{on}^\text{th}P^\text{th,min} + \Delta p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters. It also implements ramp constraints for the active power variable.

\[\begin{align*} +\end{align}\]

ThermalCompactDispatch

Variables:

Auxiliary Variables:

  • PowerOutput:
    • Symbol: $P^\text{th}$
    • Definition: $P^\text{th} = \text{on}^\text{th}P^\text{min} + \Delta p^\text{th}$

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max
  • $R^\text{th,up}$ = PowerSystems.get_ramp_limits(device).up
  • $R^\text{th,dn}$ = PowerSystems.get_ramp_limits(device).down

Variable Value Parameters:

  • $\text{on}^\text{th}$: Used in feedforwards to define if the unit is on/off at each time-step from another problem. If no feedforward is used, the parameter takes a {0,1} value if the unit is available or not.

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $\text{on}^\text{th}P^\text{th,min} + \Delta p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters. It also implements ramp constraints for the active power variable.

\[\begin{align*} & 0 \le \Delta p^\text{th}_t \le \text{on}^\text{th}_t\left(P^\text{th,max} - P^\text{th,min}\right), \quad \forall t\in \{1, \dots, T\} \\ & \text{on}^\text{th}_t Q^\text{th,min} \le q^\text{th}_t \le \text{on}^\text{th}_t Q^\text{th,max}, \quad \forall t\in \{1, \dots, T\} \\ & -R^\text{th,dn} \le \Delta p_1^\text{th} - \Delta p^\text{th, init} \le R^\text{th,up} \\ & -R^\text{th,dn} \le \Delta p_t^\text{th} - \Delta p_{t-1}^\text{th} \le R^\text{th,up}, \quad \forall t\in \{2, \dots, T\} -\end{align*}\]

ThermalStandardDispatch

Variables:

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max
  • $R^\text{th,up}$ = PowerSystems.get_ramp_limits(device).up
  • $R^\text{th,dn}$ = PowerSystems.get_ramp_limits(device).down

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters.

\[\begin{align*} +\end{align*}\]

ThermalStandardDispatch

Variables:

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max
  • $R^\text{th,up}$ = PowerSystems.get_ramp_limits(device).up
  • $R^\text{th,dn}$ = PowerSystems.get_ramp_limits(device).down

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters.

\[\begin{align*} & P^\text{th,min} \le p^\text{th}_t \le P^\text{th,max}, \quad \forall t\in \{1, \dots, T\} \\ & Q^\text{th,min} \le q^\text{th}_t \le Q^\text{th,max}, \quad \forall t\in \{1, \dots, T\} \\ & -R^\text{th,dn} \le p_1^\text{th} - p^\text{th, init} \le R^\text{th,up} \\ & -R^\text{th,dn} \le p_t^\text{th} - p_{t-1}^\text{th} \le R^\text{th,up}, \quad \forall t\in \{2, \dots, T\} -\end{align*}\]

ThermalBasicUnitCommitment

Variables:

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters. In addition, it creates the commitment constraint to turn on/off the device.

\[\begin{align*} +\end{align*}\]

ThermalBasicUnitCommitment

Variables:

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters. In addition, it creates the commitment constraint to turn on/off the device.

\[\begin{align*} & u_t^\text{th} P^\text{th,min} \le p^\text{th}_t \le u_t^\text{th} P^\text{th,max}, \quad \forall t\in \{1, \dots, T\} \\ & u_t^\text{th} Q^\text{th,min} \le q^\text{th}_t \le u_t^\text{th} Q^\text{th,max}, \quad \forall t\in \{1, \dots, T\} \\ & u_1^\text{th} = u^\text{th,init} + v_1^\text{th} - w_1^\text{th} \\ & u_t^\text{th} = u_{t-1}^\text{th} + v_t^\text{th} - w_t^\text{th}, \quad \forall t \in \{2,\dots,T\} \\ & v_t^\text{th} + w_t^\text{th} \le 1, \quad \forall t \in \{1,\dots,T\} -\end{align*}\]

ThermalBasicCompactUnitCommitment

Variables:

Auxiliary Variables:

  • PowerOutput:
    • Symbol: $P^\text{th}$
    • Definition: $P^\text{th} = u^\text{th}P^\text{min} + \Delta p^\text{th}$

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $u^\text{th}P^\text{th,min} + \Delta p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters. In addition, it creates the commitment constraint to turn on/off the device.

\[\begin{align*} +\end{align*}\]

ThermalBasicCompactUnitCommitment

Variables:

Auxiliary Variables:

  • PowerOutput:
    • Symbol: $P^\text{th}$
    • Definition: $P^\text{th} = u^\text{th}P^\text{min} + \Delta p^\text{th}$

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $u^\text{th}P^\text{th,min} + \Delta p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters. In addition, it creates the commitment constraint to turn on/off the device.

\[\begin{align*} & 0 \le \Delta p^\text{th}_t \le u^\text{th}_t\left(P^\text{th,max} - P^\text{th,min}\right), \quad \forall t\in \{1, \dots, T\} \\ & u_t^\text{th} Q^\text{th,min} \le q^\text{th}_t \le u_t^\text{th} Q^\text{th,max}, \quad \forall t\in \{1, \dots, T\} \\ & u_1^\text{th} = u^\text{th,init} + v_1^\text{th} - w_1^\text{th} \\ & u_t^\text{th} = u_{t-1}^\text{th} + v_t^\text{th} - w_t^\text{th}, \quad \forall t \in \{2,\dots,T\} \\ & v_t^\text{th} + w_t^\text{th} \le 1, \quad \forall t \in \{1,\dots,T\} -\end{align*}\]

ThermalCompactUnitCommitment

Variables:

Auxiliary Variables:

  • PowerOutput:

    • Symbol: $P^\text{th}$
    • Definition: $P^\text{th} = u^\text{th}P^\text{min} + \Delta p^\text{th}$

  • TimeDurationOn:

    • Symbol: $V_t^\text{th}$
    • Definition: Computed post optimization by adding consecutive turned on variable $u_t^\text{th}$

  • TimeDurationOff:

    • Symbol: $W_t^\text{th}$
    • Definition: Computed post optimization by adding consecutive turned off variable $1 - u_t^\text{th}$

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max
  • $R^\text{th,up}$ = PowerSystems.get_ramp_limits(device).up
  • $R^\text{th,dn}$ = PowerSystems.get_ramp_limits(device).down
  • $D^\text{min,up}$ = PowerSystems.get_time_limits(device).up
  • $D^\text{min,dn}$ = PowerSystems.get_time_limits(device).down

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $u^\text{th}P^\text{th,min} + \Delta p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters. It also creates the commitment constraint to turn on/off the device.

\[\begin{align*} +\end{align*}\]

ThermalCompactUnitCommitment

Variables:

Auxiliary Variables:

  • PowerOutput:

    • Symbol: $P^\text{th}$
    • Definition: $P^\text{th} = u^\text{th}P^\text{min} + \Delta p^\text{th}$

  • TimeDurationOn:

    • Symbol: $V_t^\text{th}$
    • Definition: Computed post optimization by adding consecutive turned on variable $u_t^\text{th}$

  • TimeDurationOff:

    • Symbol: $W_t^\text{th}$
    • Definition: Computed post optimization by adding consecutive turned off variable $1 - u_t^\text{th}$

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max
  • $R^\text{th,up}$ = PowerSystems.get_ramp_limits(device).up
  • $R^\text{th,dn}$ = PowerSystems.get_ramp_limits(device).down
  • $D^\text{min,up}$ = PowerSystems.get_time_limits(device).up
  • $D^\text{min,dn}$ = PowerSystems.get_time_limits(device).down

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $u^\text{th}P^\text{th,min} + \Delta p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters. It also creates the commitment constraint to turn on/off the device.

\[\begin{align*} & 0 \le \Delta p^\text{th}_t \le u^\text{th}_t\left(P^\text{th,max} - P^\text{th,min}\right), \quad \forall t\in \{1, \dots, T\} \\ & u_t^\text{th} Q^\text{th,min} \le q^\text{th}_t \le u_t^\text{th} Q^\text{th,max}, \quad \forall t\in \{1, \dots, T\} \\ & -R^\text{th,dn} \le \Delta p_1^\text{th} - \Delta p^\text{th, init} \le R^\text{th,up} \\ @@ -45,7 +45,7 @@ & 1 + \sum_{i=t-D^\text{min,dn} + 1}^t w_i^\text{th} \leq 1 - u_t^\text{th} \quad \text{(for } i \text{ in the set of time steps).} \\ & \text{Otherwise:} \\ & \sum_{i=t-D^\text{min,dn} + 1}^t w_i^\text{th} \leq 1 - u_t^\text{th} -\end{align*}\]

ThermalStandardUnitCommitment

Variables:

Auxiliary Variables:

  • TimeDurationOn:

    • Symbol: $V_t^\text{th}$
    • Definition: Computed post optimization by adding consecutive turned on variable $u_t^\text{th}$

  • TimeDurationOff:

    • Symbol: $W_t^\text{th}$
    • Definition: Computed post optimization by adding consecutive turned off variable $1 - u_t^\text{th}$

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max
  • $R^\text{th,up}$ = PowerSystems.get_ramp_limits(device).up
  • $R^\text{th,dn}$ = PowerSystems.get_ramp_limits(device).down
  • $D^\text{min,up}$ = PowerSystems.get_time_limits(device).up
  • $D^\text{min,dn}$ = PowerSystems.get_time_limits(device).down

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters. It also creates the commitment constraint to turn on/off the device.

\[\begin{align*} +\end{align*}\]

ThermalStandardUnitCommitment

Variables:

Auxiliary Variables:

  • TimeDurationOn:

    • Symbol: $V_t^\text{th}$
    • Definition: Computed post optimization by adding consecutive turned on variable $u_t^\text{th}$

  • TimeDurationOff:

    • Symbol: $W_t^\text{th}$
    • Definition: Computed post optimization by adding consecutive turned off variable $1 - u_t^\text{th}$

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max
  • $R^\text{th,up}$ = PowerSystems.get_ramp_limits(device).up
  • $R^\text{th,dn}$ = PowerSystems.get_ramp_limits(device).down
  • $D^\text{min,up}$ = PowerSystems.get_time_limits(device).up
  • $D^\text{min,dn}$ = PowerSystems.get_time_limits(device).down

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters. It also creates the commitment constraint to turn on/off the device.

\[\begin{align*} & u^\text{th}_t P^\text{th,min} \le p^\text{th}_t \le u^\text{th}_t P^\text{th,max}, \quad \forall t\in \{1, \dots, T\} \\ & u_t^\text{th} Q^\text{th,min} \le q^\text{th}_t \le u_t^\text{th} Q^\text{th,max}, \quad \forall t\in \{1, \dots, T\} \\ & -R^\text{th,dn} \le p_1^\text{th} - p^\text{th, init} \le R^\text{th,up} \\ @@ -63,7 +63,7 @@ & 1 + \sum_{i=t-D^\text{min,dn} + 1}^t w_i^\text{th} \leq 1 - u_t^\text{th} \quad \text{(for } i \text{ in the set of time steps).} \\ & \text{Otherwise:} \\ & \sum_{i=t-D^\text{min,dn} + 1}^t w_i^\text{th} \leq 1 - u_t^\text{th} -\end{align*}\]

ThermalMultiStartUnitCommitment

Variables:

Auxiliary Variables:

  • PowerOutput:

    • Symbol: $P^\text{th}$
    • Definition: $P^\text{th} = u^\text{th}P^\text{min} + \Delta p^\text{th}$

  • TimeDurationOn:

    • Symbol: $V_t^\text{th}$
    • Definition: Computed post optimization by adding consecutive turned on variable $u_t^\text{th}$

  • TimeDurationOff:

    • Symbol: $W_t^\text{th}$
    • Definition: Computed post optimization by adding consecutive turned off variable $1 - u_t^\text{th}$

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max
  • $R^\text{th,up}$ = PowerSystems.get_ramp_limits(device).up
  • $R^\text{th,dn}$ = PowerSystems.get_ramp_limits(device).down
  • $D^\text{min,up}$ = PowerSystems.get_time_limits(device).up
  • $D^\text{min,dn}$ = PowerSystems.get_time_limits(device).down
  • $D^\text{cold}$ = PowerSystems.get_start_time_limits(device).cold
  • $D^\text{warm}$ = PowerSystems.get_start_time_limits(device).warm
  • $D^\text{hot}$ = PowerSystems.get_start_time_limits(device).hot
  • $P^\text{th,startup}$ = PowerSystems.get_power_trajectory(device).startup
  • $P^\text{th, shdown}$ = PowerSystems.get_power_trajectory(device).shutdown

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $u^\text{th}P^\text{th,min} + \Delta p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters. It also creates the commitment constraint to turn on/off the device.

\[\begin{align*} +\end{align*}\]

ThermalMultiStartUnitCommitment

Variables:

Auxiliary Variables:

  • PowerOutput:

    • Symbol: $P^\text{th}$
    • Definition: $P^\text{th} = u^\text{th}P^\text{min} + \Delta p^\text{th}$

  • TimeDurationOn:

    • Symbol: $V_t^\text{th}$
    • Definition: Computed post optimization by adding consecutive turned on variable $u_t^\text{th}$

  • TimeDurationOff:

    • Symbol: $W_t^\text{th}$
    • Definition: Computed post optimization by adding consecutive turned off variable $1 - u_t^\text{th}$

Static Parameters:

  • $P^\text{th,min}$ = PowerSystems.get_active_power_limits(device).min
  • $P^\text{th,max}$ = PowerSystems.get_active_power_limits(device).max
  • $Q^\text{th,min}$ = PowerSystems.get_reactive_power_limits(device).min
  • $Q^\text{th,max}$ = PowerSystems.get_reactive_power_limits(device).max
  • $R^\text{th,up}$ = PowerSystems.get_ramp_limits(device).up
  • $R^\text{th,dn}$ = PowerSystems.get_ramp_limits(device).down
  • $D^\text{min,up}$ = PowerSystems.get_time_limits(device).up
  • $D^\text{min,dn}$ = PowerSystems.get_time_limits(device).down
  • $D^\text{cold}$ = PowerSystems.get_start_time_limits(device).cold
  • $D^\text{warm}$ = PowerSystems.get_start_time_limits(device).warm
  • $D^\text{hot}$ = PowerSystems.get_start_time_limits(device).hot
  • $P^\text{th,startup}$ = PowerSystems.get_power_trajectory(device).startup
  • $P^\text{th, shdown}$ = PowerSystems.get_power_trajectory(device).shutdown

Objective:

Add a cost to the objective function depending on the defined cost structure of the thermal unit by adding it to its ProductionCostExpression.

Expressions:

Adds $u^\text{th}P^\text{th,min} + \Delta p^\text{th}$ to the ActivePowerBalance expression and $q^\text{th}$ to the ReactivePowerBalance, to be used in the supply-balance constraint depending on the network model used.

Constraints:

For each thermal unit creates the range constraints for its active and reactive power depending on its static parameters. It also creates the commitment constraint to turn on/off the device.

\[\begin{align*} & 0 \le \Delta p^\text{th}_t \le u^\text{th}_t\left(P^\text{th,max} - P^\text{th,min}\right), \quad \forall t\in \{1, \dots, T\} \\ & u_t^\text{th} Q^\text{th,min} \le q^\text{th}_t \le u_t^\text{th} Q^\text{th,max}, \quad \forall t\in \{1, \dots, T\} \\ & -R^\text{th,dn} \le \Delta p_1^\text{th} - \Delta p^\text{th, init} \le R^\text{th,up} \\ @@ -90,4 +90,4 @@ & D^\text{hot} z_t^\text{th} \le \sum_{i=1}^t (1 - u_i^\text{th}) + D^\text{init,hot}, \quad \forall t \in \{1, \dots, T\} \\ & (D^\text{cold} - 1) y_t^\text{th} + (1 - y_t^\text{th}) M^\text{big} \ge \sum_{i=1}^t (1 - u_i^\text{th}) + D^\text{init,warm}, \quad \forall t \in \{1, \dots, T\} \\ & D^\text{warm} y_t^\text{th} \le \sum_{i=1}^t (1 - u_i^\text{th}) + D^\text{init,warm}, \quad \forall t \in \{1, \dots, T\} \\ -\end{align*}\]

Valid configurations

Valid DeviceModels for subtypes of ThermalGen include the following:

Valid DeviceModelDevice TypeFormulation
DeviceModel(ThermalMultiStart, FixedOutput)ThermalMultiStartFixedOutput
DeviceModel(ThermalStandard, FixedOutput)ThermalStandardFixedOutput
DeviceModel(ThermalMultiStart, ThermalBasicDispatch)ThermalMultiStartThermalBasicDispatch
DeviceModel(ThermalStandard, ThermalBasicDispatch)ThermalStandardThermalBasicDispatch
DeviceModel(ThermalMultiStart, ThermalCompactDispatch)ThermalMultiStartThermalCompactDispatch
DeviceModel(ThermalStandard, ThermalCompactDispatch)ThermalStandardThermalCompactDispatch
DeviceModel(ThermalMultiStart, ThermalDispatchNoMin)ThermalMultiStartThermalDispatchNoMin
DeviceModel(ThermalStandard, ThermalDispatchNoMin)ThermalStandardThermalDispatchNoMin
DeviceModel(ThermalMultiStart, ThermalStandardDispatch)ThermalMultiStartThermalStandardDispatch
DeviceModel(ThermalStandard, ThermalStandardDispatch)ThermalStandardThermalStandardDispatch
DeviceModel(ThermalMultiStart, ThermalBasicCompactUnitCommitment)ThermalMultiStartThermalBasicCompactUnitCommitment
DeviceModel(ThermalStandard, ThermalBasicCompactUnitCommitment)ThermalStandardThermalBasicCompactUnitCommitment
DeviceModel(ThermalMultiStart, ThermalCompactUnitCommitment)ThermalMultiStartThermalCompactUnitCommitment
DeviceModel(ThermalStandard, ThermalCompactUnitCommitment)ThermalStandardThermalCompactUnitCommitment
DeviceModel(ThermalMultiStart, ThermalMultiStartUnitCommitment)ThermalMultiStartThermalMultiStartUnitCommitment
DeviceModel(ThermalMultiStart, ThermalBasicUnitCommitment)ThermalMultiStartThermalBasicUnitCommitment
DeviceModel(ThermalStandard, ThermalBasicUnitCommitment)ThermalStandardThermalBasicUnitCommitment
DeviceModel(ThermalMultiStart, ThermalStandardUnitCommitment)ThermalMultiStartThermalStandardUnitCommitment
DeviceModel(ThermalStandard, ThermalStandardUnitCommitment)ThermalStandardThermalStandardUnitCommitment
+\end{align*}\]

Valid configurations

Valid DeviceModels for subtypes of ThermalGen include the following:

Valid DeviceModelDevice TypeFormulation
DeviceModel(ThermalMultiStart, FixedOutput)ThermalMultiStartFixedOutput
DeviceModel(ThermalStandard, FixedOutput)ThermalStandardFixedOutput
DeviceModel(ThermalMultiStart, ThermalBasicDispatch)ThermalMultiStartThermalBasicDispatch
DeviceModel(ThermalStandard, ThermalBasicDispatch)ThermalStandardThermalBasicDispatch
DeviceModel(ThermalMultiStart, ThermalCompactDispatch)ThermalMultiStartThermalCompactDispatch
DeviceModel(ThermalStandard, ThermalCompactDispatch)ThermalStandardThermalCompactDispatch
DeviceModel(ThermalMultiStart, ThermalDispatchNoMin)ThermalMultiStartThermalDispatchNoMin
DeviceModel(ThermalStandard, ThermalDispatchNoMin)ThermalStandardThermalDispatchNoMin
DeviceModel(ThermalMultiStart, ThermalStandardDispatch)ThermalMultiStartThermalStandardDispatch
DeviceModel(ThermalStandard, ThermalStandardDispatch)ThermalStandardThermalStandardDispatch
DeviceModel(ThermalMultiStart, ThermalBasicCompactUnitCommitment)ThermalMultiStartThermalBasicCompactUnitCommitment
DeviceModel(ThermalStandard, ThermalBasicCompactUnitCommitment)ThermalStandardThermalBasicCompactUnitCommitment
DeviceModel(ThermalMultiStart, ThermalCompactUnitCommitment)ThermalMultiStartThermalCompactUnitCommitment
DeviceModel(ThermalStandard, ThermalCompactUnitCommitment)ThermalStandardThermalCompactUnitCommitment
DeviceModel(ThermalMultiStart, ThermalMultiStartUnitCommitment)ThermalMultiStartThermalMultiStartUnitCommitment
DeviceModel(ThermalMultiStart, ThermalBasicUnitCommitment)ThermalMultiStartThermalBasicUnitCommitment
DeviceModel(ThermalStandard, ThermalBasicUnitCommitment)ThermalStandardThermalBasicUnitCommitment
DeviceModel(ThermalMultiStart, ThermalStandardUnitCommitment)ThermalMultiStartThermalStandardUnitCommitment
DeviceModel(ThermalStandard, ThermalStandardUnitCommitment)ThermalStandardThermalStandardUnitCommitment
diff --git a/dev/index.html b/dev/index.html index 26b176f39..40f1a2000 100644 --- a/dev/index.html +++ b/dev/index.html @@ -1,2 +1,2 @@ -Welcome Page · PowerSimulations.jl
GitHub

PowerSimulations.jl

Overview

PowerSimulations.jl is a power system operations simulation tool developed as a flexible and open source software for quasi-static power systems simulations including Production Cost Models. PowerSimulations.jl tackles the issues of developing a simulation model in a modular way providing tools for the formulation of decision models and emulation models that can be solved independently or in an interconnected fashion.

PowerSimulations.jl supports the workflows to develop simulations by separating the development of operations models and simulation models.

  • Operation Models: Optimization model used to find the solution of an operation problem.
  • Simulations Models: Defined the requirements to find solutions to a sequence of operation problems in a way that resembles the procedures followed by operators.

The most common Simulation Model is the solution of a Unit Commitment and Economic Dispatch sequence of problems. This model is used in commercial Production Cost Modeling tools, but it has a limited scope of analysis.

How the documentation is structured

PowerSimulations.jl documentation and code are organized according to the needs of different users depending on their skillset and requirements. In broad terms there are three categories:

  • Modeler: Users that want to solve an operations problem or run a simulation using the existing models in PowerSimulations.jl. For instance, answer questions about the change in operation costs in future fuel mixes. Check the formulations library page to choose a modeling strategy that fits your needs.

  • Model Developer: Users that want to develop custom models and workflows for the simulation of a power system operation. For instance, study the impacts of an stochastic optimization problem over a deterministic.

  • Code Base Developers: Users that want to add new core functionalities or fix bugs in the core capabilities of PowerSimulations.jl.

PowerSimulations.jl is an active project under development, and we welcome your feedback, suggestions, and bug reports.

Note: PowerSimulations.jl uses the data model implemented in PowerSystems.jl to construct optimization models. In most cases, you need to add PowerSystems.jl to your scripts.

Installation

The latest stable release of PowerSimulations can be installed using the Julia package manager with

] add PowerSimulations

For the current development version, "checkout" this package with

] add PowerSimulations#main

An appropriate optimization solver is required for running PowerSimulations models. Refer to JuMP.jl solver's page to select the most appropriate for the application of interest.

PowerSystems has been developed as part of the Scalable Integrated Infrastructure Planning (SIIP) initiative at the U.S. Department of Energy's National Renewable Energy Laboratory (NREL).

+Welcome Page · PowerSimulations.jl
GitHub

PowerSimulations.jl

Overview

PowerSimulations.jl is a power system operations simulation tool developed as a flexible and open source software for quasi-static power systems simulations including Production Cost Models. PowerSimulations.jl tackles the issues of developing a simulation model in a modular way providing tools for the formulation of decision models and emulation models that can be solved independently or in an interconnected fashion.

PowerSimulations.jl supports the workflows to develop simulations by separating the development of operations models and simulation models.

  • Operation Models: Optimization model used to find the solution of an operation problem.
  • Simulations Models: Defined the requirements to find solutions to a sequence of operation problems in a way that resembles the procedures followed by operators.

The most common Simulation Model is the solution of a Unit Commitment and Economic Dispatch sequence of problems. This model is used in commercial Production Cost Modeling tools, but it has a limited scope of analysis.

How the documentation is structured

PowerSimulations.jl documentation and code are organized according to the needs of different users depending on their skillset and requirements. In broad terms there are three categories:

  • Modeler: Users that want to solve an operations problem or run a simulation using the existing models in PowerSimulations.jl. For instance, answer questions about the change in operation costs in future fuel mixes. Check the formulations library page to choose a modeling strategy that fits your needs.

  • Model Developer: Users that want to develop custom models and workflows for the simulation of a power system operation. For instance, study the impacts of an stochastic optimization problem over a deterministic.

  • Code Base Developers: Users that want to add new core functionalities or fix bugs in the core capabilities of PowerSimulations.jl.

PowerSimulations.jl is an active project under development, and we welcome your feedback, suggestions, and bug reports.

Note: PowerSimulations.jl uses the data model implemented in PowerSystems.jl to construct optimization models. In most cases, you need to add PowerSystems.jl to your scripts.

Installation

The latest stable release of PowerSimulations can be installed using the Julia package manager with

] add PowerSimulations

For the current development version, "checkout" this package with

] add PowerSimulations#main

An appropriate optimization solver is required for running PowerSimulations models. Refer to JuMP.jl solver's page to select the most appropriate for the application of interest.

PowerSystems has been developed as part of the Scalable Integrated Infrastructure Planning (SIIP) initiative at the U.S. Department of Energy's National Renewable Energy Laboratory (NREL).

diff --git a/dev/model_developer_guide/structure_of_operation_problem/index.html b/dev/model_developer_guide/structure_of_operation_problem/index.html index 61d0a4777..3d0d11bb6 100644 --- a/dev/model_developer_guide/structure_of_operation_problem/index.html +++ b/dev/model_developer_guide/structure_of_operation_problem/index.html @@ -23,4 +23,4 @@ end return -end +end diff --git a/dev/model_developer_guide/troubleshooting/index.html b/dev/model_developer_guide/troubleshooting/index.html index c4bc35024..e4b102ac2 100644 --- a/dev/model_developer_guide/troubleshooting/index.html +++ b/dev/model_developer_guide/troubleshooting/index.html @@ -1,2 +1,2 @@ -Troubleshooting · PowerSimulations.jl
GitHub
+Troubleshooting · PowerSimulations.jl
GitHub
diff --git a/dev/modeler_guide/debugging_infeasible_models/index.html b/dev/modeler_guide/debugging_infeasible_models/index.html index d68105f6c..82f18f251 100644 --- a/dev/modeler_guide/debugging_infeasible_models/index.html +++ b/dev/modeler_guide/debugging_infeasible_models/index.html @@ -124,4 +124,4 @@ │ │ ("317_Hybrid", 26) │ │ └───────────────────────────────────────┘ - Error: Serializing Infeasible Problem at /var/folders/1v/t69qyl0n5059n6c1nn7sp8zm7g8s6z/T/jl_jNSREb/compact_sim/problems/ED/infeasible_ED_2020-10-06T15:00:00.json

Note that the IIS clearly identify that the issue is happening at time step 26, and constraints are related with the CopperPlateBalanceConstraint__System, with multiple upper bound constraints, for the hybrid system, renewable units and thermal units. This highlights that there may not be enough generation in the system. Indeed, by enabling system slacks, the problem become feasible.

Finally, the infeasible model is exported in a json file that can be loaded directly in JuMP to be explored. More information about this is available here.

+ Error: Serializing Infeasible Problem at /var/folders/1v/t69qyl0n5059n6c1nn7sp8zm7g8s6z/T/jl_jNSREb/compact_sim/problems/ED/infeasible_ED_2020-10-06T15:00:00.json

Note that the IIS clearly identify that the issue is happening at time step 26, and constraints are related with the CopperPlateBalanceConstraint__System, with multiple upper bound constraints, for the hybrid system, renewable units and thermal units. This highlights that there may not be enough generation in the system. Indeed, by enabling system slacks, the problem become feasible.

Finally, the infeasible model is exported in a json file that can be loaded directly in JuMP to be explored. More information about this is available here.

diff --git a/dev/modeler_guide/definitions/index.html b/dev/modeler_guide/definitions/index.html index 4ff4f0cd1..34d8cc820 100644 --- a/dev/modeler_guide/definitions/index.html +++ b/dev/modeler_guide/definitions/index.html @@ -12,4 +12,4 @@ "regularization" => false, ), ), -)

Changing the attributes between true or false can enable/disable multiple aspects of the formulation.

C

D

E

F

H

I

R

S

T

+)

Changing the attributes between true or false can enable/disable multiple aspects of the formulation.

C

D

E

F

H

I

R

S

T

diff --git a/dev/modeler_guide/logging/index.html b/dev/modeler_guide/logging/index.html index 5113275e1..dd2dd74ee 100644 --- a/dev/modeler_guide/logging/index.html +++ b/dev/modeler_guide/logging/index.html @@ -8,4 +8,4 @@ )

Configuring the simulation logger

You can configure the logging level used by the simulation logger when you call build!(simulation). Here is an example that increases logging verbosity:

import Logging
 using PowerSimulations
 simulation = Simulation(...)
-build!(simulation; console_level = Logging.Info, file_level = Logging.Debug)

The log file will be located at <your-output-path>/<simulation-name>/<run-output-dir>/logs/simulation.log.

Solver logs

You can configure logging for the solver you use. Refer to the solver documentation. PowerSimulations does not redirect or intercept prints to stdout or stderr from other libraries.

Recorder events

PowerSimulations uses the InfrastructureSystems.Recorder to store simulation events in a log file. Refer to this link for more information.

+build!(simulation; console_level = Logging.Info, file_level = Logging.Debug)

The log file will be located at <your-output-path>/<simulation-name>/<run-output-dir>/logs/simulation.log.

Solver logs

You can configure logging for the solver you use. Refer to the solver documentation. PowerSimulations does not redirect or intercept prints to stdout or stderr from other libraries.

Recorder events

PowerSimulations uses the InfrastructureSystems.Recorder to store simulation events in a log file. Refer to this link for more information.

diff --git a/dev/modeler_guide/modeling_faq/index.html b/dev/modeler_guide/modeling_faq/index.html index 809cf756a..a89d43ec3 100644 --- a/dev/modeler_guide/modeling_faq/index.html +++ b/dev/modeler_guide/modeling_faq/index.html @@ -1,2 +1,2 @@ -Modeling FAQ · PowerSimulations.jl
GitHub

Modeling FAQ

How do I reduce the amount of print on my REPL?

The print to the REPL is controlled with the logging. Check the Logging documentation page to see how to reduce the print out

How do I print the optimizer logs to see the solution process?

When specifying the DecisionModel or EmulationModel pass the keyword print_optimizer_log = true

+Modeling FAQ · PowerSimulations.jl
GitHub

Modeling FAQ

How do I reduce the amount of print on my REPL?

The print to the REPL is controlled with the logging. Check the Logging documentation page to see how to reduce the print out

How do I print the optimizer logs to see the solution process?

When specifying the DecisionModel or EmulationModel pass the keyword print_optimizer_log = true

diff --git a/dev/modeler_guide/parallel_simulations/index.html b/dev/modeler_guide/parallel_simulations/index.html index 0d5210531..81221bb3b 100644 --- a/dev/modeler_guide/parallel_simulations/index.html +++ b/dev/modeler_guide/parallel_simulations/index.html @@ -102,4 +102,4 @@ project_path=".", # This optionally specifies the Julia project environment to load. ) Created Jade configuration in config.json. Run 'jade submit-jobs [options] config.json' to execute them.

Exit Julia.

  1. View the configuration for accuracy.
$ jade config show config.json
  1. Start an interactive session on a debug node. Do not submit the jobs on a login node! The submission step will run a full build of the simulation and that may consume too many CPU and memory resources for the login node.
$ salloc -t 01:00:00 -N1 --account=<your-account> --partition=debug
  1. Follow the instructions at https://nrel.github.io/jade/tutorial.html to submit the jobs. The example below will configure Jade to run each partition on its own compute node. Depending on the compute and memory constraints of your simulation, you may be able to pack more jobs on each node.Adjust the walltime as necessary.
$ jade config hpc -c hpc_config.toml -t slurm  --walltime=04:00:00 -a <your-account>
-$ jade submit-jobs config.json --per-node-batch-size=1 -o output

If you are unsure about how much memory and CPU resources your simulation consumes, add these options:

$ jade submit-jobs config.json --per-node-batch-size=1 -o output --resource-monitor-type periodic --resource-monitor-interval 3

Jade will create HTML plots of the resource utilization in output/stats. You may be able to customize --per-node-batch-size and --num-processes to finish the simulations more quickly.

  1. Jade will run a final command to join the simulation partitions into one unified file. You can load the results as you normally would.
julia> results = SimulationResults("<output-dir>/job-outputs/<simulation-name>")

Note the log files and results for each partition are located in <output-dir>/job-outputs/<simulation-name>/simulation_partitions

+$ jade submit-jobs config.json --per-node-batch-size=1 -o output

If you are unsure about how much memory and CPU resources your simulation consumes, add these options:

$ jade submit-jobs config.json --per-node-batch-size=1 -o output --resource-monitor-type periodic --resource-monitor-interval 3

Jade will create HTML plots of the resource utilization in output/stats. You may be able to customize --per-node-batch-size and --num-processes to finish the simulations more quickly.

  1. Jade will run a final command to join the simulation partitions into one unified file. You can load the results as you normally would.
julia> results = SimulationResults("<output-dir>/job-outputs/<simulation-name>")

Note the log files and results for each partition are located in <output-dir>/job-outputs/<simulation-name>/simulation_partitions

diff --git a/dev/modeler_guide/problem_templates/index.html b/dev/modeler_guide/problem_templates/index.html index aa206eb5e..5cf3707e7 100644 --- a/dev/modeler_guide/problem_templates/index.html +++ b/dev/modeler_guide/problem_templates/index.html @@ -8,7 +8,7 @@ # Accepted Key Words - `network::Type{<:PM.AbstractPowerModel}` : override default network model settings - `devices::Vector{DeviceModel}` : override default `DeviceModel` settings -- `services::Vector{ServiceModel}` : override default `ServiceModel` settingssource
template_economic_dispatch()
+- `services::Vector{ServiceModel}` : override default `ServiceModel` settingssource
template_economic_dispatch()
@@ -131,7 +131,7 @@ # Accepted Key Words - `network::Type{<:PM.AbstractPowerModel}` : override default network model settings - `devices::Vector{DeviceModel}` : override default `DeviceModel` settings -- `services::Vector{ServiceModel}` : override default `ServiceModel` settingssource
template_unit_commitment()
Network Model
+- `services::Vector{ServiceModel}` : override default `ServiceModel` settingssource
template_unit_commitment()
@@ -249,4 +249,4 @@
Network Model
- + diff --git a/dev/modeler_guide/psi_structure/index.html b/dev/modeler_guide/psi_structure/index.html index 584406bc0..5af73c67c 100644 --- a/dev/modeler_guide/psi_structure/index.html +++ b/dev/modeler_guide/psi_structure/index.html @@ -1,2 +1,2 @@ -PowerSimulations.jl Modeling Structure · PowerSimulations.jl
GitHub

PowerSimulations.jl Modeling Structure

PowerSimulations enables the simulation of a sequence of power systems optimization problems and provides user control over each aspect of the simulation configuration. Specifically:

What is the difference between a Model and a Problem?

A "Problem" is an abstract mathematical description of how to represent power system behavior, whereas a "Model" is a concrete representation of a "Problem" applied to a dataset. I.e. once a Problem is populated with data describing all the loads, generators, lines, etc., it becomes a Model.

+PowerSimulations.jl Modeling Structure · PowerSimulations.jl
GitHub

PowerSimulations.jl Modeling Structure

PowerSimulations enables the simulation of a sequence of power systems optimization problems and provides user control over each aspect of the simulation configuration. Specifically:

What is the difference between a Model and a Problem?

A "Problem" is an abstract mathematical description of how to represent power system behavior, whereas a "Model" is a concrete representation of a "Problem" applied to a dataset. I.e. once a Problem is populated with data describing all the loads, generators, lines, etc., it becomes a Model.

diff --git a/dev/modeler_guide/read_results/index.html b/dev/modeler_guide/read_results/index.html index 63f64114a..597dd90dd 100644 --- a/dev/modeler_guide/read_results/index.html +++ b/dev/modeler_guide/read_results/index.html @@ -126,4 +126,4 @@ 190 │ 2020-10-09T21:00:00 -7.65965e-12 293.333 60.6667 0.0 124.0 0.0 0.0 0.0 76.0 0.0 191 │ 2020-10-09T22:00:00 0.0 0.0 60.6667 0.0 124.0 0.0 0.0 0.0 76.0 7.156 192 │ 2020-10-09T23:00:00 0.0 0.0 60.6667 0.0 117.81 0.0 0.0 0.0 76.0 0.0 - 44 columns and 180 rows omitted

In this case, the 8 simulation steps of 24 hours (192 hours), in a single DataFrame, to enable easy exploration of the realized results for the user.

+ 44 columns and 180 rows omitted

In this case, the 8 simulation steps of 24 hours (192 hours), in a single DataFrame, to enable easy exploration of the realized results for the user.

diff --git a/dev/modeler_guide/running_a_simulation/index.html b/dev/modeler_guide/running_a_simulation/index.html index 322ee470c..c2b281735 100644 --- a/dev/modeler_guide/running_a_simulation/index.html +++ b/dev/modeler_guide/running_a_simulation/index.html @@ -72,4 +72,4 @@ build!(sim) # Execute the simulation using the Optimizer specified in each DecisionModel -execute!(sim; enable_progress_bar = true)

Check the PCM tutorial for a more detailed tutorial on executing a simulation in a production cost modeling (PCM) environment.

+execute!(sim; enable_progress_bar = true)

Check the PCM tutorial for a more detailed tutorial on executing a simulation in a production cost modeling (PCM) environment.

diff --git a/dev/modeler_guide/simulation_recorder/index.html b/dev/modeler_guide/simulation_recorder/index.html index 76ad5adb0..796802c30 100644 --- a/dev/modeler_guide/simulation_recorder/index.html +++ b/dev/modeler_guide/simulation_recorder/index.html @@ -40,4 +40,4 @@ │ ProblemExecutionEvent │ 2024-01-01T20:00:00 │ 1 │ 2 │ start │ │ ProblemExecutionEvent │ 2024-01-01T21:00:00 │ 1 │ 2 │ start │ │ ProblemExecutionEvent │ 2024-01-01T22:00:00 │ 1 │ 2 │ start │ -└──────────────────────┴─────────────────────┴──────┴───────┴────────┘ +└──────────────────────┴─────────────────────┴──────┴───────┴────────┘ diff --git a/dev/modeler_guide/tips_and_tricks/index.html b/dev/modeler_guide/tips_and_tricks/index.html index a3d49e33b..9d52ba21c 100644 --- a/dev/modeler_guide/tips_and_tricks/index.html +++ b/dev/modeler_guide/tips_and_tricks/index.html @@ -1,2 +1,2 @@ -Tips and tricks · PowerSimulations.jl
GitHub
+Tips and tricks · PowerSimulations.jl
GitHub
diff --git a/dev/quick_start_guide/index.html b/dev/quick_start_guide/index.html index 94d3bcf63..819c7bd41 100644 --- a/dev/quick_start_guide/index.html +++ b/dev/quick_start_guide/index.html @@ -1,2 +1,2 @@ -Quick Start Guide · PowerSimulations.jl
GitHub

Quick Start Guide

Tip

If you need to develop a dataset for a simulation check the PowerSystems.jl Tutorials on how to parse data and attach time series

  • Tutorial: If you are eager to run your first simulation visit the Solve a Day Ahead Market Scheduling Problem using PowerSimulations.jl tutorial
+Quick Start Guide · PowerSimulations.jl
GitHub

Quick Start Guide

Tip

If you need to develop a dataset for a simulation check the PowerSystems.jl Tutorials on how to parse data and attach time series

  • Tutorial: If you are eager to run your first simulation visit the Solve a Day Ahead Market Scheduling Problem using PowerSimulations.jl tutorial
diff --git a/dev/tutorials/adding_new_device_formulation/index.html b/dev/tutorials/adding_new_device_formulation/index.html index 3eb53ef42..2e0a8a6e3 100644 --- a/dev/tutorials/adding_new_device_formulation/index.html +++ b/dev/tutorials/adding_new_device_formulation/index.html @@ -1,2 +1,2 @@ -Adding Device Formulations · PowerSimulations.jl
GitHub
+Adding Device Formulations · PowerSimulations.jl
GitHub
diff --git a/dev/tutorials/adding_new_problem_model/index.html b/dev/tutorials/adding_new_problem_model/index.html index 237b1f693..95ea7fb93 100644 --- a/dev/tutorials/adding_new_problem_model/index.html +++ b/dev/tutorials/adding_new_problem_model/index.html @@ -73,4 +73,4 @@ end return -end +end diff --git a/dev/tutorials/basics_of_developing_models/index.html b/dev/tutorials/basics_of_developing_models/index.html index 6af8781bb..09088a7f3 100644 --- a/dev/tutorials/basics_of_developing_models/index.html +++ b/dev/tutorials/basics_of_developing_models/index.html @@ -1,2 +1,2 @@ -Basics of Developing Operation Models · PowerSimulations.jl
GitHub
+Basics of Developing Operation Models · PowerSimulations.jl
GitHub
diff --git a/dev/tutorials/decision_problem/index.html b/dev/tutorials/decision_problem/index.html index d2606c8df..beba0a437 100644 --- a/dev/tutorials/decision_problem/index.html +++ b/dev/tutorials/decision_problem/index.html @@ -312,15 +312,15 @@

PowerSimulations Problem Auxiliary variables Results - - TimeDurationOff__ThermalStandard - TimeDurationOn__ThermalStandard HydroEnergyOutput__HydroDispatch + + TimeDurationOff__ThermalStandard + @@ -328,13 +328,13 @@

PowerSimulations Problem Expressions Results - ProductionCostExpression__HydroDispatch + ProductionCostExpression__ThermalStandard ActivePowerBalance__System - ProductionCostExpression__ThermalStandard + ProductionCostExpression__HydroDispatch ProductionCostExpression__RenewableDispatch @@ -346,28 +346,28 @@

PowerSimulations Problem Parameters Results - ActivePowerTimeSeriesParameter__RenewableNonDispatch + ActivePowerTimeSeriesParameter__RenewableDispatch - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Reg_Up + ActivePowerTimeSeriesParameter__PowerLoad - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R1 + RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Reg_Up - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R3 + RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R2 - ActivePowerTimeSeriesParameter__RenewableDispatch + RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R1 - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R2 + RequirementTimeSeriesParameter__VariableReserve__ReserveDown__Reg_Down - ActivePowerTimeSeriesParameter__PowerLoad + ActivePowerTimeSeriesParameter__RenewableNonDispatch - RequirementTimeSeriesParameter__VariableReserve__ReserveDown__Reg_Down + RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R3 ActivePowerTimeSeriesParameter__HydroDispatch @@ -379,41 +379,41 @@

PowerSimulations Problem Variables Results - StopVariable__ThermalStandard - - - ActivePowerReserveVariable__VariableReserve__ReserveDown__Reg_Down + ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R2 - ActivePowerVariable__RenewableDispatch + StartVariable__ThermalStandard - StartVariable__ThermalStandard + ActivePowerVariable__HydroDispatch ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R1 - ActivePowerVariable__ThermalStandard + StopVariable__ThermalStandard - ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R3 + ActivePowerReserveVariable__VariableReserve__ReserveDown__Reg_Down - ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R2 + ActivePowerReserveVariable__VariableReserve__ReserveUp__Reg_Up - ActivePowerReserveVariable__VariableReserve__ReserveUp__Reg_Up + ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R3 OnVariable__ThermalStandard - ActivePowerVariable__HydroDispatch + ActivePowerVariable__ThermalStandard + + + ActivePowerVariable__RenewableDispatch -

Optimizer Stats

The optimizer summary is included

get_optimizer_stats(res)
1×21 DataFrame
Rowdetailed_statsobjective_valuetermination_statusprimal_statusdual_statussolver_solve_timeresult_counthas_valueshas_dualsobjective_boundrelative_gapdual_objective_valuesolve_timebarrier_iterationssimplex_iterationsnode_counttimed_solve_timetimed_calculate_aux_variablestimed_calculate_dual_variablessolve_bytes_allocsec_in_gc
BoolFloat64Int64Int64Int64Float64Int64BoolBoolMissingMissingMissingFloat64MissingMissingMissingFloat64Float64Float64Float64Float64
1false2.3571e6110NaN1falsefalsemissingmissingmissing0.614038missingmissingmissing0.6853040.4363570.0007165042.605e70.0

Objective Function Value

get_objective_value(res)
2.357099085649291e6

Variable, Parameter, Auxillary Variable, Dual, and Expression Values

The solution value data frames for variables, parameters, auxillary variables, duals and expressions can be accessed using the read_ methods:

read_variables(res)
Dict{String, DataFrames.DataFrame} with 11 entries:
+
Optimizer Stats
The optimizer summary is included
get_optimizer_stats(res)
1×21 DataFrame
Rowdetailed_statsobjective_valuetermination_statusprimal_statusdual_statussolver_solve_timeresult_counthas_valueshas_dualsobjective_boundrelative_gapdual_objective_valuesolve_timebarrier_iterationssimplex_iterationsnode_counttimed_solve_timetimed_calculate_aux_variablestimed_calculate_dual_variablessolve_bytes_allocsec_in_gc
BoolFloat64Int64Int64Int64Float64Int64BoolBoolMissingMissingMissingFloat64MissingMissingMissingFloat64Float64Float64Float64Float64
1false2.3571e6110NaN1falsefalsemissingmissingmissing0.61338missingmissingmissing0.6865180.4391540.0004138012.37147e70.0
Objective Function Value
get_objective_value(res)
2.357099085649291e6
Variable, Parameter, Auxillary Variable, Dual, and Expression Values
The solution value data frames for variables, parameters, auxillary variables, duals and expressions can be accessed using the read_ methods:
read_variables(res)
Dict{String, DataFrames.DataFrame} with 11 entries:
   "ActivePowerReserveVaria… => 24×52 DataFrame…
   "StopVariable__ThermalSt… => 24×55 DataFrame…
   "ActivePowerReserveVaria… => 24×52 DataFrame…
@@ -425,4 +425,4 @@ 

   "ActivePowerVariable__Re… => 24×30 DataFrame…
   "ActivePowerReserveVaria… => 24×18 DataFrame…
   "ActivePowerReserveVaria… => 24×17 DataFrame…
Or, you can read a single parameter values for parameters that exist in the results.
list_parameter_names(res)
-read_parameter(res, "ActivePowerTimeSeriesParameter__RenewableDispatch")
RowDateTime122_WIND_1324_PV_3312_PV_1102_PV_1101_PV_1324_PV_2313_PV_2104_PV_1101_PV_2309_WIND_1310_PV_2113_PV_1317_WIND_1314_PV_1324_PV_1103_PV_1303_WIND_1314_PV_2102_PV_2314_PV_3320_PV_1101_PV_3319_PV_1314_PV_4310_PV_1215_PV_1313_PV_1101_PV_4119_PV_1
DateTimeFloat64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64
12020-01-01T00:00:00713.20.00.00.00.00.00.00.00.0142.80.00.0795.10.00.00.0480.80.00.00.00.00.00.00.00.00.00.00.00.0
22020-01-01T01:00:00712.80.00.00.00.00.00.00.00.0139.10.00.0794.40.00.00.0634.90.00.00.00.00.00.00.00.00.00.00.00.0
32020-01-01T02:00:00708.40.00.00.00.00.00.00.00.0145.30.00.0773.60.00.00.0487.30.00.00.00.00.00.00.00.00.00.00.00.0
42020-01-01T03:00:00710.70.00.00.00.00.00.00.00.0144.80.00.0767.30.00.00.0432.70.00.00.00.00.00.00.00.00.00.00.00.0
52020-01-01T04:00:00701.40.00.00.00.00.00.00.00.0137.10.00.0752.20.00.00.0407.90.00.00.00.00.00.00.00.00.00.00.00.0
62020-01-01T05:00:00682.50.00.00.00.00.00.00.00.098.60.00.0719.40.00.00.0440.20.00.00.00.00.00.00.00.00.00.00.00.0
72020-01-01T06:00:00614.70.00.00.00.00.00.00.00.062.20.00.0655.30.00.00.0377.30.00.00.00.00.00.00.00.00.00.00.00.0
82020-01-01T07:00:00517.736.452.230.629.636.462.229.830.447.338.299.4594.647.444.829.8199.346.630.063.847.830.6179.246.438.2127.662.228.827.2
92020-01-01T08:00:00426.663.497.436.834.863.496.035.037.048.961.4126.2579.161.265.258.4110.667.036.4100.061.437.4248.067.061.4164.695.635.456.6
102020-01-01T09:00:00274.271.2118.038.036.471.4117.636.638.230.766.8133.2466.869.068.076.63.669.837.6121.869.838.8273.469.866.8172.2116.835.874.8
112020-01-01T10:00:0093.072.2132.037.836.472.2130.836.638.027.470.2134.2301.470.270.289.82.472.237.4129.070.438.6277.872.270.4173.2128.437.488.2
122020-01-01T11:00:006.370.6135.237.035.070.6134.235.437.260.969.8135.2110.767.070.298.056.272.436.6128.667.237.6263.272.469.6170.0133.238.691.6
132020-01-01T12:00:003.867.4131.036.235.467.4129.635.636.420.467.8133.078.967.268.294.091.570.235.8128.267.437.0267.470.267.6169.0128.837.890.6
142020-01-01T13:00:001.165.2125.435.235.065.2123.635.435.41.667.2126.6107.967.065.881.4103.067.634.8119.667.035.8258.867.667.0161.8122.835.879.2
152020-01-01T14:00:000.060.2109.631.031.060.4108.031.431.20.063.2110.222.359.462.659.439.764.230.8107.059.431.6227.864.262.8143.2106.831.459.0
162020-01-01T15:00:000.042.069.020.219.242.065.620.620.22.645.062.824.642.444.825.487.746.220.065.843.420.6151.646.243.882.262.820.427.8
172020-01-01T16:00:000.90.00.00.00.00.00.00.00.037.90.00.010.80.00.00.092.30.00.00.00.00.00.00.00.00.00.00.00.0
182020-01-01T17:00:00276.30.00.00.00.00.00.00.00.046.90.00.0243.20.00.00.089.40.00.00.00.00.00.00.00.00.00.00.00.0
192020-01-01T18:00:00272.90.00.00.00.00.00.00.00.024.00.00.0375.20.00.00.090.40.00.00.00.00.00.00.00.00.00.00.00.0
202020-01-01T19:00:00345.60.00.00.00.00.00.00.00.024.00.00.0568.40.00.00.081.10.00.00.00.00.00.00.00.00.00.00.00.0
212020-01-01T20:00:00411.70.00.00.00.00.00.00.00.027.40.00.0636.10.00.00.0172.90.00.00.00.00.00.00.00.00.00.00.00.0
222020-01-01T21:00:00376.60.00.00.00.00.00.00.00.06.50.00.0719.20.00.00.0326.90.00.00.00.00.00.00.00.00.00.00.00.0
232020-01-01T22:00:00561.30.00.00.00.00.00.00.00.01.30.00.0734.90.00.00.0256.70.00.00.00.00.00.00.00.00.00.00.00.0
242020-01-01T23:00:00568.40.00.00.00.00.00.00.00.00.10.00.0729.10.00.00.0141.10.00.00.00.00.00.00.00.00.00.00.00.0
Plotting
Take a look at the plotting capabilities in PowerGraphics.jl

+read_parameter(res, "ActivePowerTimeSeriesParameter__RenewableDispatch")
24×30 DataFrame
RowDateTime122_WIND_1324_PV_3312_PV_1102_PV_1101_PV_1324_PV_2313_PV_2104_PV_1101_PV_2309_WIND_1310_PV_2113_PV_1317_WIND_1314_PV_1324_PV_1103_PV_1303_WIND_1314_PV_2102_PV_2314_PV_3320_PV_1101_PV_3319_PV_1314_PV_4310_PV_1215_PV_1313_PV_1101_PV_4119_PV_1
DateTimeFloat64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64Float64
12020-01-01T00:00:00713.20.00.00.00.00.00.00.00.0142.80.00.0795.10.00.00.0480.80.00.00.00.00.00.00.00.00.00.00.00.0
22020-01-01T01:00:00712.80.00.00.00.00.00.00.00.0139.10.00.0794.40.00.00.0634.90.00.00.00.00.00.00.00.00.00.00.00.0
32020-01-01T02:00:00708.40.00.00.00.00.00.00.00.0145.30.00.0773.60.00.00.0487.30.00.00.00.00.00.00.00.00.00.00.00.0
42020-01-01T03:00:00710.70.00.00.00.00.00.00.00.0144.80.00.0767.30.00.00.0432.70.00.00.00.00.00.00.00.00.00.00.00.0
52020-01-01T04:00:00701.40.00.00.00.00.00.00.00.0137.10.00.0752.20.00.00.0407.90.00.00.00.00.00.00.00.00.00.00.00.0
62020-01-01T05:00:00682.50.00.00.00.00.00.00.00.098.60.00.0719.40.00.00.0440.20.00.00.00.00.00.00.00.00.00.00.00.0
72020-01-01T06:00:00614.70.00.00.00.00.00.00.00.062.20.00.0655.30.00.00.0377.30.00.00.00.00.00.00.00.00.00.00.00.0
82020-01-01T07:00:00517.736.452.230.629.636.462.229.830.447.338.299.4594.647.444.829.8199.346.630.063.847.830.6179.246.438.2127.662.228.827.2
92020-01-01T08:00:00426.663.497.436.834.863.496.035.037.048.961.4126.2579.161.265.258.4110.667.036.4100.061.437.4248.067.061.4164.695.635.456.6
102020-01-01T09:00:00274.271.2118.038.036.471.4117.636.638.230.766.8133.2466.869.068.076.63.669.837.6121.869.838.8273.469.866.8172.2116.835.874.8
112020-01-01T10:00:0093.072.2132.037.836.472.2130.836.638.027.470.2134.2301.470.270.289.82.472.237.4129.070.438.6277.872.270.4173.2128.437.488.2
122020-01-01T11:00:006.370.6135.237.035.070.6134.235.437.260.969.8135.2110.767.070.298.056.272.436.6128.667.237.6263.272.469.6170.0133.238.691.6
132020-01-01T12:00:003.867.4131.036.235.467.4129.635.636.420.467.8133.078.967.268.294.091.570.235.8128.267.437.0267.470.267.6169.0128.837.890.6
142020-01-01T13:00:001.165.2125.435.235.065.2123.635.435.41.667.2126.6107.967.065.881.4103.067.634.8119.667.035.8258.867.667.0161.8122.835.879.2
152020-01-01T14:00:000.060.2109.631.031.060.4108.031.431.20.063.2110.222.359.462.659.439.764.230.8107.059.431.6227.864.262.8143.2106.831.459.0
162020-01-01T15:00:000.042.069.020.219.242.065.620.620.22.645.062.824.642.444.825.487.746.220.065.843.420.6151.646.243.882.262.820.427.8
172020-01-01T16:00:000.90.00.00.00.00.00.00.00.037.90.00.010.80.00.00.092.30.00.00.00.00.00.00.00.00.00.00.00.0
182020-01-01T17:00:00276.30.00.00.00.00.00.00.00.046.90.00.0243.20.00.00.089.40.00.00.00.00.00.00.00.00.00.00.00.0
192020-01-01T18:00:00272.90.00.00.00.00.00.00.00.024.00.00.0375.20.00.00.090.40.00.00.00.00.00.00.00.00.00.00.00.0
202020-01-01T19:00:00345.60.00.00.00.00.00.00.00.024.00.00.0568.40.00.00.081.10.00.00.00.00.00.00.00.00.00.00.00.0
212020-01-01T20:00:00411.70.00.00.00.00.00.00.00.027.40.00.0636.10.00.00.0172.90.00.00.00.00.00.00.00.00.00.00.00.0
222020-01-01T21:00:00376.60.00.00.00.00.00.00.00.06.50.00.0719.20.00.00.0326.90.00.00.00.00.00.00.00.00.00.00.00.0
232020-01-01T22:00:00561.30.00.00.00.00.00.00.00.01.30.00.0734.90.00.00.0256.70.00.00.00.00.00.00.00.00.00.00.00.0
242020-01-01T23:00:00568.40.00.00.00.00.00.00.00.00.10.00.0729.10.00.00.0141.10.00.00.00.00.00.00.00.00.00.00.00.0

Plotting

Take a look at the plotting capabilities in PowerGraphics.jl

diff --git a/dev/tutorials/pcm_simulation/index.html b/dev/tutorials/pcm_simulation/index.html index 39252d6d3..bdf711b44 100644 --- a/dev/tutorials/pcm_simulation/index.html +++ b/dev/tutorials/pcm_simulation/index.html @@ -872,18 +872,18 @@

ED Problem Expressions Results - - ActivePowerBalance__System - ProductionCostExpression__ThermalStandard - ActivePowerBalance__ACBus + ActivePowerBalance__System ProductionCostExpression__RenewableDispatch + + ActivePowerBalance__ACBus + @@ -891,31 +891,31 @@

ED Problem Parameters Results - ActivePowerTimeSeriesParameter__RenewableNonDispatch + ActivePowerTimeSeriesParameter__RenewableDispatch - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Reg_Up + ActivePowerTimeSeriesParameter__PowerLoad - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R1 + RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Reg_Up - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R3 + RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R2 - ActivePowerTimeSeriesParameter__RenewableDispatch + RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R1 - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R2 + OnStatusParameter__ThermalStandard - ActivePowerTimeSeriesParameter__PowerLoad + RequirementTimeSeriesParameter__VariableReserve__ReserveDown__Reg_Down - RequirementTimeSeriesParameter__VariableReserve__ReserveDown__Reg_Down + ActivePowerTimeSeriesParameter__RenewableNonDispatch - OnStatusParameter__ThermalStandard + RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R3 @@ -924,49 +924,49 @@

ED Problem Variables Results - ActivePowerReserveVariable__VariableReserve__ReserveDown__Reg_Down + ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R2 - FlowActivePowerVariable__Line + SystemBalanceSlackUp__System - FlowActivePowerFromToVariable__TwoTerminalHVDCLine + FlowActivePowerVariable__TapTransformer - ActivePowerVariable__RenewableDispatch + ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R1 HVDCFlowDirectionVariable__TwoTerminalHVDCLine - ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R1 + ActivePowerReserveVariable__VariableReserve__ReserveDown__Reg_Down - ActivePowerVariable__ThermalStandard + ActivePowerReserveVariable__VariableReserve__ReserveUp__Reg_Up - ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R3 + SystemBalanceSlackDown__System - ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R2 + FlowActivePowerFromToVariable__TwoTerminalHVDCLine - FlowActivePowerVariable__TapTransformer + ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R3 - SystemBalanceSlackUp__System + HVDCLosses__TwoTerminalHVDCLine - HVDCLosses__TwoTerminalHVDCLine + FlowActivePowerToFromVariable__TwoTerminalHVDCLine - ActivePowerReserveVariable__VariableReserve__ReserveUp__Reg_Up + FlowActivePowerVariable__Line - SystemBalanceSlackDown__System + ActivePowerVariable__ThermalStandard - FlowActivePowerToFromVariable__TwoTerminalHVDCLine + ActivePowerVariable__RenewableDispatch @@ -981,11 +981,11 @@

48×5… "ActivePowerVariable__Th… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×5… "FlowActivePowerFromToVa… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×2… - "ActivePowerVariable__Re… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×3… "ActivePowerReserveVaria… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×1… + "ActivePowerVariable__Re… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×3… "HVDCLosses__TwoTerminal… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×2… - "ActivePowerReserveVaria… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×1… - "HVDCFlowDirectionVariab… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×2…

or all the parameters

read_parameters(uc_results)
Dict{String, SortedDict{Any, Any, Base.Order.ForwardOrdering}} with 9 entries:
+  "HVDCFlowDirectionVariab… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×2…
+  "ActivePowerReserveVaria… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×1…

or all the parameters

read_parameters(uc_results)
Dict{String, SortedDict{Any, Any, Base.Order.ForwardOrdering}} with 9 entries:
   "RequirementTimeSeriesPa… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×2…
   "ActivePowerTimeSeriesPa… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×5…
   "ActivePowerTimeSeriesPa… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×3…
@@ -995,29 +995,29 @@ 
48×2…
   "RequirementTimeSeriesPa… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×2…
   "RequirementTimeSeriesPa… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×2…

We can just list the variable names contained in uc_results:

list_variable_names(uc_results)
15-element Vector{String}:
+ "ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R2"
+ "StartVariable__ThermalStandard"
+ "ActivePowerVariable__HydroDispatch"
+ "HVDCFlowDirectionVariable__TwoTerminalHVDCLine"
  "StopVariable__ThermalStandard"
+ "ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R1"
  "ActivePowerReserveVariable__VariableReserve__ReserveDown__Reg_Down"
+ "ActivePowerReserveVariable__VariableReserve__ReserveUp__Reg_Up"
  "FlowActivePowerFromToVariable__TwoTerminalHVDCLine"
- "ActivePowerVariable__RenewableDispatch"
- "StartVariable__ThermalStandard"
- "ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R1"
- "ActivePowerVariable__ThermalStandard"
  "ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R3"
- "HVDCFlowDirectionVariable__TwoTerminalHVDCLine"
- "ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R2"
  "HVDCLosses__TwoTerminalHVDCLine"
- "ActivePowerReserveVariable__VariableReserve__ReserveUp__Reg_Up"
  "OnVariable__ThermalStandard"
- "ActivePowerVariable__HydroDispatch"
- "FlowActivePowerToFromVariable__TwoTerminalHVDCLine"

and a number of parameters (this pattern also works for aux_variables, expressions, and duals)

list_parameter_names(uc_results)
9-element Vector{String}:
- "ActivePowerTimeSeriesParameter__RenewableNonDispatch"
- "RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Reg_Up"
- "RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R1"
- "RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R3"
+ "FlowActivePowerToFromVariable__TwoTerminalHVDCLine"
+ "ActivePowerVariable__ThermalStandard"
+ "ActivePowerVariable__RenewableDispatch"

and a number of parameters (this pattern also works for aux_variables, expressions, and duals)

list_parameter_names(uc_results)
9-element Vector{String}:
  "ActivePowerTimeSeriesParameter__RenewableDispatch"
- "RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R2"
  "ActivePowerTimeSeriesParameter__PowerLoad"
+ "RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Reg_Up"
+ "RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R2"
+ "RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R1"
  "RequirementTimeSeriesParameter__VariableReserve__ReserveDown__Reg_Down"
+ "ActivePowerTimeSeriesParameter__RenewableNonDispatch"
+ "RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R3"
  "ActivePowerTimeSeriesParameter__HydroDispatch"

Now we can read the specific results of interest for a specific problem, time window (optional), and set of variables, duals, or parameters (optional)

Dict([
     v => read_variable(uc_results, v) for v in [
         "ActivePowerVariable__RenewableDispatch",
@@ -1040,4 +1040,4 @@ 
12×32 DataFrame…
Info

note that this returns the results of each execution step in a separate dataframe If you want the realized results (without lookahead periods), you can call read_realized_*:

read_realized_variables(
     uc_results,
     ["ActivePowerVariable__ThermalStandard", "ActivePowerVariable__RenewableDispatch"],
-)

Plotting

Take a look at the plotting capabilities in PowerGraphics.jl

+)

Plotting

Take a look at the plotting capabilities in PowerGraphics.jl