From 45e9cce87817079b3cf86e110ce50e63c13758c8 Mon Sep 17 00:00:00 2001 From: rodrigomha Date: Sat, 11 May 2024 12:22:03 -0700 Subject: [PATCH] update typos --- docs/src/formulation_library/General.md | 6 ++-- docs/src/formulation_library/Piecewise.md | 32 +++++++++++++++++-- .../devices/common/objective_functions.jl | 8 ++--- src/feedforward/feedforwards.jl | 28 ++++++++-------- 4 files changed, 50 insertions(+), 24 deletions(-) diff --git a/docs/src/formulation_library/General.md b/docs/src/formulation_library/General.md index 11b5c2ab9f..b603df29bf 100644 --- a/docs/src/formulation_library/General.md +++ b/docs/src/formulation_library/General.md @@ -104,9 +104,9 @@ 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. -___ +--- -## `StorageManagementCost` +## `StorageCost` Adds an objective function cost term according to: @@ -118,7 +118,7 @@ Adds an objective function cost term according to: **Impact of different cost configurations:** -The following table describes all possible configuration of the `StorageManagementCost` with the target constraint in hydro or storage device models. Cases 1(a) & 2(a) will have no impact of the models 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 or the model not storing any energy in the device. This is caused by the fact that when 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. +The following table describes all possible configuration of the `StorageCost` with the target constraint in hydro or storage device models. Cases 1(a) & 2(a) will have no impact of the models 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 or the model not storing any energy in the device. This is caused by the fact that when 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. | Case | Energy Target | Energy Shortage Cost | Energy Value / Energy Surplus cost | Effect | diff --git a/docs/src/formulation_library/Piecewise.md b/docs/src/formulation_library/Piecewise.md index d175ed7270..2167769162 100644 --- a/docs/src/formulation_library/Piecewise.md +++ b/docs/src/formulation_library/Piecewise.md @@ -13,8 +13,8 @@ A special ordered set (SOS) is an ordered set of variables used as an additional Piecewise-linear costs are defined by a sequence of points representing the line segments for each generator: ``(P_k^\text{max}, C_k)`` on which we assume ``C_k`` is the cost of generating ``P_k^\text{max}`` power, and ``k \in \{1,\dots, K\}`` are the number of segments each generator cost function has. -!!!note - `PowerSystems` has more options to specify cost functions for each thermal unit. Independent of which form of the cost data is provided, `PowerSimulations.jl` will internally transform the data to use the λ-model formulation. See TODO: ADD PSY COST DOCS for more information. +!!! note + `PowerSystems` has more options to specify cost functions for each thermal unit. Independent of which form of the cost data is provided, `PowerSimulations.jl` will internally transform the data to use the λ-model formulation. See **TODO: ADD PSY COST DOCS** for more information. ### Commitment formulation @@ -48,4 +48,30 @@ on which ``\delta_{k,t} \in [0,1]`` is the interpolation variable, ``p`` is the ## Compact representation of PWL costs -TODO \ No newline at end of file +### Commitment Formulation + +```math +\begin{align*} + \min_{\substack{p_{t}, \delta_{k,t}}} + & \sum_{t \in \mathcal{T}} \left(\sum_{k \in \mathcal{K}} C_{k,t} \delta_{k,t} \right) \Delta t\\ + & \sum_{k \in \mathcal{K}} P_{k}^{\text{max}} \delta_{k,t} = P^{\text{min}} u_{t} + \Delta p_{t} & \forall t \in \mathcal{T}\\ + & \sum_{k \in \mathcal{K}} \delta_{k,t} = u_{t} & \forall t \in \mathcal{T}\\ + & 0 \leq \Delta p_{t} \leq \left( P^{\text{max}} - P^{\text{min}} \right)u_{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. + +### Dispatch formulation + +```math +\begin{align*} + \min_{\substack{p_{t}, \delta_{k,t}}} + & \sum_{t \in \mathcal{T}} \left(\sum_{k \in \mathcal{K}} C_{k,t} \delta_{k,t} \right) \Delta t\\ + & \sum_{k \in \mathcal{K}} P_{k}^{\text{max}} \delta_{k,t} = P^{\text{min}} \text{on}_{t} + \Delta p_{t} & \forall t \in \mathcal{T}\\ + & \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. \ No newline at end of file diff --git a/src/devices_models/devices/common/objective_functions.jl b/src/devices_models/devices/common/objective_functions.jl index f64c3da743..2199bdf3ee 100644 --- a/src/devices_models/devices/common/objective_functions.jl +++ b/src/devices_models/devices/common/objective_functions.jl @@ -453,11 +453,11 @@ end Obtain the normalized PiecewiseLinear cost data in system base per unit depending on the specified power units. -Note that the costs (y-axis) are always in $/h so +Note that the costs (y-axis) are always in \$/h so they do not require transformation """ function get_piecewise_pointcurve_per_system_unit( - cost_component::PiecewiseLinearData, + cost_component::PSY.PiecewiseLinearData, ::Val{0}, # SystemBase Units system_base_power::Float64, device_base_power::Float64, @@ -466,7 +466,7 @@ function get_piecewise_pointcurve_per_system_unit( end function get_piecewise_pointcurve_per_system_unit( - cost_component::PiecewiseLinearData, + cost_component::PSY.PiecewiseLinearData, ::Val{1}, # DeviceBase Units system_base_power::Float64, device_base_power::Float64, @@ -481,7 +481,7 @@ function get_piecewise_pointcurve_per_system_unit( end function get_piecewise_pointcurve_per_system_unit( - cost_component::PiecewiseLinearData, + cost_component::PSY.PiecewiseLinearData, ::Val{2}, # Natural Units system_base_power::Float64, device_base_power::Float64, diff --git a/src/feedforward/feedforwards.jl b/src/feedforward/feedforwards.jl index 1089d86422..a69b00a2ef 100644 --- a/src/feedforward/feedforwards.jl +++ b/src/feedforward/feedforwards.jl @@ -61,10 +61,10 @@ end 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. +* `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. """ struct UpperBoundFeedforward <: AbstractAffectFeedforward @@ -113,10 +113,10 @@ get_slacks(ff::UpperBoundFeedforward) = ff.add_slacks 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. +* `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. """ struct LowerBoundFeedforward <: AbstractAffectFeedforward @@ -191,9 +191,9 @@ It allows to enable/disable bounds to 0.0 for a specified variable. Commonly use an another problem (typically a Unit Commitment problem). # 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 semicontinuous limit will be applied using the source values +* `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 semicontinuous limit will be applied using the source values """ struct SemiContinuousFeedforward <: AbstractAffectFeedforward optimization_container_key::OptimizationContainerKey @@ -258,9 +258,9 @@ Fixes a Variable or Parameter Value in the model from another problem. Is the on 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 +* `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 """ struct FixValueFeedforward <: AbstractAffectFeedforward optimization_container_key::OptimizationContainerKey