From 6091cab75945debef13b288e0fc86185e470ca5e Mon Sep 17 00:00:00 2001 From: "Documenter.jl" Date: Thu, 3 Oct 2024 00:06:12 +0000 Subject: [PATCH] build based on 806a148 --- .../PR1132/api/PowerSimulations/index.html | 64 ++++++------- .../developer/index.html | 2 +- .../extending_powersimulations/index.html | 2 +- .../troubleshooting/index.html | 2 +- .../formulation_library/Branch/index.html | 14 +-- .../Feedforward/index.html | 10 +- .../formulation_library/General/index.html | 4 +- .../Introduction/index.html | 2 +- .../formulation_library/Load/index.html | 6 +- .../formulation_library/Network/index.html | 8 +- .../formulation_library/Piecewise/index.html | 2 +- .../formulation_library/README/index.html | 2 +- .../RenewableGen/index.html | 6 +- .../formulation_library/Service/index.html | 10 +- .../formulation_library/ThermalGen/index.html | 20 ++-- previews/PR1132/index.html | 2 +- .../structure_of_operation_problem/index.html | 2 +- .../troubleshooting/index.html | 2 +- .../debugging_infeasible_models/index.html | 2 +- .../modeler_guide/definitions/index.html | 2 +- .../PR1132/modeler_guide/logging/index.html | 2 +- .../modeler_guide/modeling_faq/index.html | 2 +- .../parallel_simulations/index.html | 2 +- .../problem_templates/index.html | 6 +- .../modeler_guide/psi_structure/index.html | 2 +- .../modeler_guide/read_results/index.html | 2 +- .../running_a_simulation/index.html | 2 +- .../simulation_recorder/index.html | 2 +- .../modeler_guide/tips_and_tricks/index.html | 2 +- previews/PR1132/quick_start_guide/index.html | 2 +- previews/PR1132/search/index.html | 2 +- .../adding_new_device_formulation/index.html | 2 +- .../adding_new_problem_model/index.html | 2 +- .../basics_of_developing_models/index.html | 2 +- .../tutorials/decision_problem/index.html | 56 +++++------ .../tutorials/pcm_simulation/index.html | 92 ++++++++++--------- 36 files changed, 173 insertions(+), 171 deletions(-) diff --git a/previews/PR1132/api/PowerSimulations/index.html b/previews/PR1132/api/PowerSimulations/index.html index 644c94c10..a31f38a53 100644 --- a/previews/PR1132/api/PowerSimulations/index.html +++ b/previews/PR1132/api/PowerSimulations/index.html @@ -8,13 +8,13 @@ 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

Refer to the Problem Templates Page for available ProblemTemplates.

  +)

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

Refer to the Problem Templates Page for available ProblemTemplates.

   

Decision Models

PowerSimulations.DecisionModel — Type
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
DecisionModel(
+OpModel = DecisionModel(MockOperationProblem, template, system)
source
DecisionModel(
     ::Type{M<:PowerSimulations.DecisionProblem},
     template::PowerSimulations.AbstractProblemTemplate,
     sys::System;
@@ -28,13 +28,13 @@
     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

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
DecisionModel(
+problem = DecisionModel(MyOpProblemType, template, system, optimizer)
source

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
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(
+

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(
     ::Type{M<:PowerSimulations.DecisionProblem},
     template::PowerSimulations.AbstractProblemTemplate,
     sys::System;
@@ -48,13 +48,13 @@
     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
DecisionModel(
+problem = DecisionModel(MyOpProblemType, template, system, optimizer)
source
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.build! — Method
build!(
+

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.build! — Method
build!(
     model::DecisionModel;
     output_dir,
     recorders,
@@ -62,7 +62,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,
@@ -72,13 +72,13 @@
     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
  +results = solve!(OpModel, export_problem_results = true)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;
@@ -92,14 +92,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,
@@ -108,7 +108,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,
@@ -118,8 +118,8 @@
     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
  - 

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
  +status = run!(model; output_dir = ./model_output, optimizer = GLPK.Optimizer, executions = 10)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.SimulationModels — Type
SimulationModels(
     decision_models::Vector{<:DecisionModel},
     emulation_models::Union{Nothing, EmulationModel}
@@ -132,7 +132,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
@@ -158,7 +158,7 @@
             ),
         ],
     ),
-)
source
PowerSimulations.Simulation — Type
Simulation(
+)
source
PowerSimulations.Simulation — Type
Simulation(
     sequence::SimulationSequence,
     name::String,
     steps::Int
@@ -195,8 +195,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,
@@ -205,32 +205,32 @@
     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
  - 

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

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

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} \\ +execute!(sim::Simulation; kwargs...)

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

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

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
Missing docstring.

Missing docstring for HVDCLossesAbsoluteValue. Check Documenter's build log for details.

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
Missing docstring.

Missing docstring for HVDCLossesAbsoluteValue. Check Documenter's build log for details.

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
+\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
diff --git a/previews/PR1132/code_base_developer_guide/developer/index.html b/previews/PR1132/code_base_developer_guide/developer/index.html index 786d915a5..8c7c9dde7 100644 --- a/previews/PR1132/code_base_developer_guide/developer/index.html +++ b/previews/PR1132/code_base_developer_guide/developer/index.html @@ -1,2 +1,2 @@ -Developer Guide · PowerSimulations.jl
Edit on GitHub
+Developer Guide · PowerSimulations.jl
Edit on GitHub
diff --git a/previews/PR1132/code_base_developer_guide/extending_powersimulations/index.html b/previews/PR1132/code_base_developer_guide/extending_powersimulations/index.html index 0d75ffa26..ffa929002 100644 --- a/previews/PR1132/code_base_developer_guide/extending_powersimulations/index.html +++ b/previews/PR1132/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/previews/PR1132/code_base_developer_guide/troubleshooting/index.html b/previews/PR1132/code_base_developer_guide/troubleshooting/index.html index 29cdfdf51..81f485fbb 100644 --- a/previews/PR1132/code_base_developer_guide/troubleshooting/index.html +++ b/previews/PR1132/code_base_developer_guide/troubleshooting/index.html @@ -1,2 +1,2 @@ -Troubleshooting · PowerSimulations.jl
Edit on GitHub
+Troubleshooting · PowerSimulations.jl
Edit on GitHub
diff --git a/previews/PR1132/formulation_library/Branch/index.html b/previews/PR1132/formulation_library/Branch/index.html index dd877f84e..de99dd728 100644 --- a/previews/PR1132/formulation_library/Branch/index.html +++ b/previews/PR1132/formulation_library/Branch/index.html @@ -1,13 +1,13 @@ -Branch · PowerSimulations.jl
Edit on 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:

If Slack variables are enabled:

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

Edit on 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:

If Slack variables are enabled:

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/previews/PR1132/formulation_library/Feedforward/index.html b/previews/PR1132/formulation_library/Feedforward/index.html index 3f073c794..31ed4ee88 100644 --- a/previews/PR1132/formulation_library/Feedforward/index.html +++ b/previews/PR1132/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/previews/PR1132/formulation_library/General/index.html b/previews/PR1132/formulation_library/General/index.html index 91f91267c..0e5ff1c4a 100644 --- a/previews/PR1132/formulation_library/General/index.html +++ b/previews/PR1132/formulation_library/General/index.html @@ -1,5 +1,5 @@ -General · PowerSimulations.jl
Edit on 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

Edit on 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} & \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/previews/PR1132/formulation_library/Introduction/index.html b/previews/PR1132/formulation_library/Introduction/index.html index 0a78fbd2c..03ec67a4f 100644 --- a/previews/PR1132/formulation_library/Introduction/index.html +++ b/previews/PR1132/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/previews/PR1132/formulation_library/Load/index.html b/previews/PR1132/formulation_library/Load/index.html index 8dc92c94d..18be5eb8d 100644 --- a/previews/PR1132/formulation_library/Load/index.html +++ b/previews/PR1132/formulation_library/Load/index.html @@ -1,8 +1,8 @@ -Load · PowerSimulations.jl
Edit on 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

Edit on 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} & 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
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} & 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/previews/PR1132/formulation_library/Network/index.html b/previews/PR1132/formulation_library/Network/index.html index 2823272da..d46b32cdc 100644 --- a/previews/PR1132/formulation_library/Network/index.html +++ b/previews/PR1132/formulation_library/Network/index.html @@ -1,8 +1,8 @@ -Network · PowerSimulations.jl
Edit on 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. 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

Edit on 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. 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.

+\end{align}\]

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

diff --git a/previews/PR1132/formulation_library/Piecewise/index.html b/previews/PR1132/formulation_library/Piecewise/index.html index 4ae4ea5c9..dbbb72e02 100644 --- a/previews/PR1132/formulation_library/Piecewise/index.html +++ b/previews/PR1132/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/previews/PR1132/formulation_library/README/index.html b/previews/PR1132/formulation_library/README/index.html index 183f180fa..e95504489 100644 --- a/previews/PR1132/formulation_library/README/index.html +++ b/previews/PR1132/formulation_library/README/index.html @@ -1,2 +1,2 @@ -Formulation documentation guide · PowerSimulations.jl
Edit on 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
Edit on 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/previews/PR1132/formulation_library/RenewableGen/index.html b/previews/PR1132/formulation_library/RenewableGen/index.html index 055c556da..a9e2beb87 100644 --- a/previews/PR1132/formulation_library/RenewableGen/index.html +++ b/previews/PR1132/formulation_library/RenewableGen/index.html @@ -1,8 +1,8 @@ -Renewable Generation · PowerSimulations.jl
Edit on 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

Edit on 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} & 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
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} & 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/previews/PR1132/formulation_library/Service/index.html b/previews/PR1132/formulation_library/Service/index.html index bbbb0b49f..c38a57802 100644 --- a/previews/PR1132/formulation_library/Service/index.html +++ b/previews/PR1132/formulation_library/Service/index.html @@ -1,11 +1,11 @@ -Services · PowerSimulations.jl
Edit on 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. 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:

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

Edit on 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. 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:

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:

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:

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:

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:

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\}\]

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\}\]

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/previews/PR1132/formulation_library/ThermalGen/index.html b/previews/PR1132/formulation_library/ThermalGen/index.html index d683dcad2..41fd9598c 100644 --- a/previews/PR1132/formulation_library/ThermalGen/index.html +++ b/previews/PR1132/formulation_library/ThermalGen/index.html @@ -1,33 +1,33 @@ -Thermal Generation · PowerSimulations.jl
Edit on 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

Edit on 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/previews/PR1132/index.html b/previews/PR1132/index.html index 5b5d8194c..cdcef9323 100644 --- a/previews/PR1132/index.html +++ b/previews/PR1132/index.html @@ -1,2 +1,2 @@ -Welcome Page · PowerSimulations.jl
Edit on 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
Edit on 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/previews/PR1132/model_developer_guide/structure_of_operation_problem/index.html b/previews/PR1132/model_developer_guide/structure_of_operation_problem/index.html index 68c766b85..5f196a1db 100644 --- a/previews/PR1132/model_developer_guide/structure_of_operation_problem/index.html +++ b/previews/PR1132/model_developer_guide/structure_of_operation_problem/index.html @@ -23,4 +23,4 @@ end return - end + end diff --git a/previews/PR1132/model_developer_guide/troubleshooting/index.html b/previews/PR1132/model_developer_guide/troubleshooting/index.html index 1f9ba1144..9ece043be 100644 --- a/previews/PR1132/model_developer_guide/troubleshooting/index.html +++ b/previews/PR1132/model_developer_guide/troubleshooting/index.html @@ -1,2 +1,2 @@ -Troubleshooting · PowerSimulations.jl
Edit on GitHub
+Troubleshooting · PowerSimulations.jl
Edit on GitHub
diff --git a/previews/PR1132/modeler_guide/debugging_infeasible_models/index.html b/previews/PR1132/modeler_guide/debugging_infeasible_models/index.html index 7c339b348..0564bd92a 100644 --- a/previews/PR1132/modeler_guide/debugging_infeasible_models/index.html +++ b/previews/PR1132/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/previews/PR1132/modeler_guide/definitions/index.html b/previews/PR1132/modeler_guide/definitions/index.html index 0b81346cb..e79d34bb3 100644 --- a/previews/PR1132/modeler_guide/definitions/index.html +++ b/previews/PR1132/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/previews/PR1132/modeler_guide/logging/index.html b/previews/PR1132/modeler_guide/logging/index.html index ff02493f9..eac8b8a4a 100644 --- a/previews/PR1132/modeler_guide/logging/index.html +++ b/previews/PR1132/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/previews/PR1132/modeler_guide/modeling_faq/index.html b/previews/PR1132/modeler_guide/modeling_faq/index.html index 34be5f056..b12059661 100644 --- a/previews/PR1132/modeler_guide/modeling_faq/index.html +++ b/previews/PR1132/modeler_guide/modeling_faq/index.html @@ -1,2 +1,2 @@ -Modeling FAQ · PowerSimulations.jl
Edit on 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
Edit on 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/previews/PR1132/modeler_guide/parallel_simulations/index.html b/previews/PR1132/modeler_guide/parallel_simulations/index.html index 6311c1249..554195f43 100644 --- a/previews/PR1132/modeler_guide/parallel_simulations/index.html +++ b/previews/PR1132/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/previews/PR1132/modeler_guide/problem_templates/index.html b/previews/PR1132/modeler_guide/problem_templates/index.html index ac6e91ad2..a8484adea 100644 --- a/previews/PR1132/modeler_guide/problem_templates/index.html +++ b/previews/PR1132/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/previews/PR1132/modeler_guide/psi_structure/index.html b/previews/PR1132/modeler_guide/psi_structure/index.html index d2ee88fe1..4b606a1e8 100644 --- a/previews/PR1132/modeler_guide/psi_structure/index.html +++ b/previews/PR1132/modeler_guide/psi_structure/index.html @@ -1,2 +1,2 @@ -PowerSimulations.jl Modeling Structure · PowerSimulations.jl
Edit on 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
Edit on 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/previews/PR1132/modeler_guide/read_results/index.html b/previews/PR1132/modeler_guide/read_results/index.html index fbde56fe0..754389f47 100644 --- a/previews/PR1132/modeler_guide/read_results/index.html +++ b/previews/PR1132/modeler_guide/read_results/index.html @@ -124,4 +124,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/previews/PR1132/modeler_guide/running_a_simulation/index.html b/previews/PR1132/modeler_guide/running_a_simulation/index.html index f9ec67627..a89b9a3e3 100644 --- a/previews/PR1132/modeler_guide/running_a_simulation/index.html +++ b/previews/PR1132/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/previews/PR1132/modeler_guide/simulation_recorder/index.html b/previews/PR1132/modeler_guide/simulation_recorder/index.html index ac92a0316..533272546 100644 --- a/previews/PR1132/modeler_guide/simulation_recorder/index.html +++ b/previews/PR1132/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/previews/PR1132/modeler_guide/tips_and_tricks/index.html b/previews/PR1132/modeler_guide/tips_and_tricks/index.html index db70148f1..547584fec 100644 --- a/previews/PR1132/modeler_guide/tips_and_tricks/index.html +++ b/previews/PR1132/modeler_guide/tips_and_tricks/index.html @@ -1,2 +1,2 @@ -Tips and tricks · PowerSimulations.jl
Edit on GitHub
+Tips and tricks · PowerSimulations.jl
Edit on GitHub
diff --git a/previews/PR1132/quick_start_guide/index.html b/previews/PR1132/quick_start_guide/index.html index 6f25d15d7..b116ededf 100644 --- a/previews/PR1132/quick_start_guide/index.html +++ b/previews/PR1132/quick_start_guide/index.html @@ -1,2 +1,2 @@ -Quick Start Guide · PowerSimulations.jl
Edit on 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
Edit on 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/previews/PR1132/search/index.html b/previews/PR1132/search/index.html index 7dda84269..fb9adaeae 100644 --- a/previews/PR1132/search/index.html +++ b/previews/PR1132/search/index.html @@ -1,2 +1,2 @@ -Search · PowerSimulations.jl

Loading search...

    +Search · PowerSimulations.jl

    Loading search...

      diff --git a/previews/PR1132/tutorials/adding_new_device_formulation/index.html b/previews/PR1132/tutorials/adding_new_device_formulation/index.html index f0baaf6c3..0d5a93c68 100644 --- a/previews/PR1132/tutorials/adding_new_device_formulation/index.html +++ b/previews/PR1132/tutorials/adding_new_device_formulation/index.html @@ -1,2 +1,2 @@ -Adding Device Formulations · PowerSimulations.jl
      Edit on GitHub
      +Adding Device Formulations · PowerSimulations.jl
      Edit on GitHub
      diff --git a/previews/PR1132/tutorials/adding_new_problem_model/index.html b/previews/PR1132/tutorials/adding_new_problem_model/index.html index a966fd705..4c353228b 100644 --- a/previews/PR1132/tutorials/adding_new_problem_model/index.html +++ b/previews/PR1132/tutorials/adding_new_problem_model/index.html @@ -73,4 +73,4 @@ end return - end + end diff --git a/previews/PR1132/tutorials/basics_of_developing_models/index.html b/previews/PR1132/tutorials/basics_of_developing_models/index.html index 823863e39..d9a052ef1 100644 --- a/previews/PR1132/tutorials/basics_of_developing_models/index.html +++ b/previews/PR1132/tutorials/basics_of_developing_models/index.html @@ -1,2 +1,2 @@ -Basics of Developing Operation Models · PowerSimulations.jl
      Edit on GitHub
      +Basics of Developing Operation Models · PowerSimulations.jl
      Edit on GitHub
      diff --git a/previews/PR1132/tutorials/decision_problem/index.html b/previews/PR1132/tutorials/decision_problem/index.html index 7712997f2..7eed20206 100644 --- a/previews/PR1132/tutorials/decision_problem/index.html +++ b/previews/PR1132/tutorials/decision_problem/index.html @@ -313,13 +313,13 @@

      PowerSimulations Problem Auxiliary variables Results - TimeDurationOn__ThermalStandard + HydroEnergyOutput__HydroDispatch TimeDurationOff__ThermalStandard - HydroEnergyOutput__HydroDispatch + TimeDurationOn__ThermalStandard @@ -328,16 +328,16 @@

      PowerSimulations Problem Expressions Results - ProductionCostExpression__ThermalStandard + ProductionCostExpression__HydroDispatch - ActivePowerBalance__System + ProductionCostExpression__RenewableDispatch - ProductionCostExpression__HydroDispatch + ProductionCostExpression__ThermalStandard - ProductionCostExpression__RenewableDispatch + ActivePowerBalance__System @@ -345,32 +345,32 @@

      PowerSimulations Problem Parameters Results - - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R3 - ActivePowerTimeSeriesParameter__HydroDispatch RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R1 - - RequirementTimeSeriesParameter__VariableReserve__ReserveDown__Reg_Down - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R2 - ActivePowerTimeSeriesParameter__RenewableNonDispatch + RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R3 - ActivePowerTimeSeriesParameter__PowerLoad + RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Reg_Up ActivePowerTimeSeriesParameter__RenewableDispatch - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Reg_Up + RequirementTimeSeriesParameter__VariableReserve__ReserveDown__Reg_Down + + + ActivePowerTimeSeriesParameter__PowerLoad + + + ActivePowerTimeSeriesParameter__RenewableNonDispatch @@ -378,14 +378,11 @@

      PowerSimulations Problem Variables Results - - ActivePowerReserveVariable__VariableReserve__ReserveUp__Reg_Up - StopVariable__ThermalStandard - OnVariable__ThermalStandard + ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R2 StartVariable__ThermalStandard @@ -394,29 +391,32 @@

      ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R1 - ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R2 - - - ActivePowerVariable__ThermalStandard + ActivePowerReserveVariable__VariableReserve__ReserveUp__Reg_Up ActivePowerReserveVariable__VariableReserve__ReserveDown__Reg_Down - ActivePowerVariable__RenewableDispatch + ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R3 - ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R3 + ActivePowerVariable__ThermalStandard ActivePowerVariable__HydroDispatch + + OnVariable__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.630742missingmissingmissing0.7329330.3447430.0004345212.94527e70.0210614

      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…
+
      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.647214missingmissingmissing0.7309990.3508290.0004322262.94527e70.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…
   "OnVariable__ThermalStan… => 24×55 DataFrame…
   "ActivePowerVariable__Hy… => 24×2 DataFrame…
   "ActivePowerReserveVaria… => 24×19 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/previews/PR1132/tutorials/pcm_simulation/index.html b/previews/PR1132/tutorials/pcm_simulation/index.html index f546f1508..1302abd77 100644 --- a/previews/PR1132/tutorials/pcm_simulation/index.html +++ b/previews/PR1132/tutorials/pcm_simulation/index.html @@ -873,16 +873,16 @@

      ED Problem Expressions Results - ProductionCostExpression__ThermalStandard + ActivePowerBalance__ACBus - ActivePowerBalance__ACBus + ProductionCostExpression__RenewableDispatch - ActivePowerBalance__System + ProductionCostExpression__ThermalStandard - ProductionCostExpression__RenewableDispatch + ActivePowerBalance__System @@ -891,31 +891,31 @@

      ED Problem Parameters Results - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R3 + RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R1 - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R1 + RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R2 - OnStatusParameter__ThermalStandard + RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R3 - RequirementTimeSeriesParameter__VariableReserve__ReserveDown__Reg_Down + OnStatusParameter__ThermalStandard - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R2 + RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Reg_Up - ActivePowerTimeSeriesParameter__RenewableNonDispatch + ActivePowerTimeSeriesParameter__RenewableDispatch ActivePowerTimeSeriesParameter__PowerLoad - ActivePowerTimeSeriesParameter__RenewableDispatch + RequirementTimeSeriesParameter__VariableReserve__ReserveDown__Reg_Down - RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Reg_Up + ActivePowerTimeSeriesParameter__RenewableNonDispatch @@ -924,67 +924,68 @@

      ED Problem Variables Results - SystemBalanceSlackDown__System + HVDCFlowDirectionVariable__TwoTerminalHVDCLine FlowActivePowerVariable__TapTransformer - ActivePowerReserveVariable__VariableReserve__ReserveUp__Reg_Up + FlowActivePowerFromToVariable__TwoTerminalHVDCLine - ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R1 + ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R2 - FlowActivePowerToFromVariable__TwoTerminalHVDCLine + ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R1 - ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R2 + HVDCLosses__TwoTerminalHVDCLine - ActivePowerVariable__ThermalStandard + FlowActivePowerVariable__Line - ActivePowerReserveVariable__VariableReserve__ReserveDown__Reg_Down + SystemBalanceSlackDown__System - ActivePowerVariable__RenewableDispatch + ActivePowerReserveVariable__VariableReserve__ReserveUp__Reg_Up - ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R3 + FlowActivePowerToFromVariable__TwoTerminalHVDCLine - SystemBalanceSlackUp__System + ActivePowerReserveVariable__VariableReserve__ReserveDown__Reg_Down - HVDCLosses__TwoTerminalHVDCLine + ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R3 - FlowActivePowerVariable__Line + SystemBalanceSlackUp__System - FlowActivePowerFromToVariable__TwoTerminalHVDCLine + ActivePowerVariable__ThermalStandard - HVDCFlowDirectionVariable__TwoTerminalHVDCLine + ActivePowerVariable__RenewableDispatch -

      We can read all the result variables

      read_variables(uc_results)
      Dict{String, SortedDict{Any, Any, Base.Order.ForwardOrdering}} with 14 entries:
+
      We can read all the result variables
      read_variables(uc_results)
      Dict{String, SortedDict{Any, Any, Base.Order.ForwardOrdering}} with 15 entries:
   "ActivePowerReserveVaria… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×5…
   "FlowActivePowerToFromVa… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×2…
-  "ActivePowerReserveVaria… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×5…
   "StopVariable__ThermalSt… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×5…
+  "ActivePowerReserveVaria… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×5…
   "OnVariable__ThermalStan… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×5…
   "ActivePowerVariable__Hy… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×2…
   "ActivePowerReserveVaria… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×1…
   "StartVariable__ThermalS… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×5…
   "ActivePowerVariable__Th… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×5…
-  "ActivePowerVariable__Re… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×3…
-  "ActivePowerReserveVaria… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×1…
   "FlowActivePowerFromToVa… => 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:
+  "ActivePowerVariable__Re… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×3…
+  "HVDCLosses__TwoTerminal… => SortedDict(DateTime("2020-01-01T00:00:00")=>48×2…
+  "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…
@@ -993,30 +994,31 @@ 
      list_variable_names(uc_results)
      14-element Vector{String}:
- "ActivePowerReserveVariable__VariableReserve__ReserveUp__Reg_Up"
+  "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}:
+ "HVDCFlowDirectionVariable__TwoTerminalHVDCLine"
+ "FlowActivePowerFromToVariable__TwoTerminalHVDCLine"
  "StopVariable__ThermalStandard"
- "OnVariable__ThermalStandard"
+ "ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R2"
  "StartVariable__ThermalStandard"
  "ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R1"
+ "HVDCLosses__TwoTerminalHVDCLine"
+ "ActivePowerReserveVariable__VariableReserve__ReserveUp__Reg_Up"
  "FlowActivePowerToFromVariable__TwoTerminalHVDCLine"
- "ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R2"
- "ActivePowerVariable__ThermalStandard"
  "ActivePowerReserveVariable__VariableReserve__ReserveDown__Reg_Down"
- "ActivePowerVariable__RenewableDispatch"
  "ActivePowerReserveVariable__VariableReserve__ReserveUp__Spin_Up_R3"
+ "ActivePowerVariable__ThermalStandard"
  "ActivePowerVariable__HydroDispatch"
- "FlowActivePowerFromToVariable__TwoTerminalHVDCLine"
- "HVDCFlowDirectionVariable__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}:
- "RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R3"
+ "OnVariable__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__HydroDispatch"
  "RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R1"
- "RequirementTimeSeriesParameter__VariableReserve__ReserveDown__Reg_Down"
  "RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R2"
- "ActivePowerTimeSeriesParameter__RenewableNonDispatch"
- "ActivePowerTimeSeriesParameter__PowerLoad"
+ "RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Spin_Up_R3"
+ "RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Reg_Up"
  "ActivePowerTimeSeriesParameter__RenewableDispatch"
- "RequirementTimeSeriesParameter__VariableReserve__ReserveUp__Reg_Up"
      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([
+ "RequirementTimeSeriesParameter__VariableReserve__ReserveDown__Reg_Down"
+ "ActivePowerTimeSeriesParameter__PowerLoad"
+ "ActivePowerTimeSeriesParameter__RenewableNonDispatch"
      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",
         "ActivePowerVariable__HydroDispatch",
@@ -1038,4 +1040,4 @@ 
      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