MinUpDownTimeNode
MinUpDownTimeNode is a specialized NetworkNode type that introduces unit commitment logic including minimum up and down time constraints. It is useful for modeling dispatchable power plants or technologies where operation must adhere to minimum runtime constraints.
This node is included in an example to demonstrate flexible demand.
Introduced type and its fields
The MinUpDownTimeNode extends the capabilities of a NetworkNode with binary status tracking and time-dependent logical constraints. It is implemented using integer variables to model on/off behavior and operational transitions.
Standard fields
The standard fields are given as:
id:
The fieldidis only used for providing a name to the node.cap::TimeProfile:
The installed capacity corresponds to the nominal capacity of the node.
If the node should contain investments through the application ofEnergyModelsInvestments, it is important to note that you can only useFixedProfileorStrategicProfilefor the capacity, but notRepresentativeProfileorOperationalProfile. In addition, all values have to be non-negative.opex_var::TimeProfile:
The variable operational expenses are based on the capacity utilization through the variable:cap_use. Hence, it is directly related to the specifiedinputandoutputratios. The variable operating expenses can be provided asOperationalProfileas well.opex_fixed::TimeProfile:
The fixed operating expenses are relative to the installed capacity (through the fieldcap) and the chosen duration of an investment period as outlined on UtilizeTimeStruct.
It is important to note that you can only useFixedProfileorStrategicProfilefor the fixed OPEX, but notRepresentativeProfileorOperationalProfile. In addition, all values have to be non-negative.input::Dict{<:Resource,<:Real}andoutput::Dict{<:Resource,<:Real}:
Both fields describe theinputandoutputResources with their corresponding conversion factors as dictionaries.
CO₂ cannot be directly specified, i.e., you cannot specify a ratio. If you useCaptureData, it is however necessary to specify CO₂ as output, although the ratio is not important.
All values have to be non-negative.data::Vector{<:Data}:
Optional metadata (e.g., emissions or investment data). This is initialized to an empty array by default.Constructor for `MinUpDownTimeNode` The field
datais not required as we include a constructor when the value is excluded.Using `CaptureData` If you plan to use
CaptureDatafor aMinUpDownTimeNodenode, it is crucial that you specify your CO₂ resource in theoutputdictionary. The chosen value is however not important as the CO₂ flow is automatically calculated based on the process utilization and the provided process emission value. The reason for this necessity is that flow variables are declared through the keys of theoutputdictionary. Hence, not specifying CO₂ asoutputresource results in not creating the corresponding flow variable and subsequent problems in the design.We plan to remove this necessity in the future. As it would most likely correspond to breaking changes, we have to be careful to avoid requiring major changes in other packages.
Note that this node cannot be used with OperationalScenarios or RepresentativePeriods.
Additional fields
MinUpDownTimeNode nodes add four additional fields compared to a NetworkNode:
minUpTime::Real:
Minimum number of operational periods the unit must remain on after being started.minDownTime::Real:
Minimum number of operational periods the unit must remain off after being stopped.minCapacity::Real:
Minimum power output when the unit is on. The value must be larger than zero.maxCapacity::Real:
Maximum power output when the unit is on (usually aligned withcap). The value must not be less thanminCapacity.
The fields minUpTime and minDownTime are defined in terms of operational period durations and should be consistent with the time granularity of the model.
Mathematical description
MinUpDownTimeNode introduces integer-based logic and sequencing constraints, in addition to standard flow and capacity formulations of NetworkNodes.
Variables
In addition to variables used in a NetworkNode:
- $\texttt{opex\_var}$
- $\texttt{opex\_fixed}$
- $\texttt{cap\_use}$
- $\texttt{cap\_inst}$
- $\texttt{flow\_in}$
- $\texttt{flow\_out}$
- $\texttt{emissions\_node}$ if
EmissionsDatais added to the fielddata
The following binary variables are introduced for unit commitment behavior:
- $\texttt{on\_off}[n, t] \in \{0,1\}$:
Indicates if the unit is operating during time step $t$. - $\texttt{onswitch}[n, t] \in \{0,1\}$:
Indicates a startup at time step $t$. - $\texttt{offswitch}[n, t] \in \{0,1\}$:
Indicates a shutdown at time step $t$.
Constraints
The following sections omit the direct inclusion of the vector of MinUpDownTimeNode nodes. Instead, it is implicitly assumed that the constraints are valid $\forall n ∈ N$ for all MinUpDownTimeNode types if not stated differently. In addition, all constraints are valid $\forall t \in T$ (that is in all operational periods) or $\forall t_{inv} \in T^{Inv}$ (that is in all investment periods).
Standard constraints
MinUpDownTimeNode utilize in general the standard constraints that are implemented for a NetworkNode node as described in the documentation of EnergyModelsBase. These standard constraints are:
constraints_capacity_installed:\[\texttt{cap\_inst}[n, t] = capacity(n, t)\]
Using investments The function
constraints_capacity_installedis also used inEnergyModelsInvestmentsto incorporate the potential for investment. Nodes with investments are then no longer constrained by the parameter capacity.constraints_flow_in:\[\texttt{flow\_in}[n, t, p] = inputs(n, p) \times \texttt{cap\_use}[n, t] \qquad \forall p \in inputs(n)\]
constraints_flow_out:\[\texttt{flow\_out}[n, t, p] = outputs(n, p) \times \texttt{cap\_use}[n, t] \qquad \forall p \in outputs(n) \setminus \{\text{CO}_2\}\]
constraints_opex_fixed:\[\texttt{opex\_fixed}[n, t_{inv}] = opex\_fixed(n, t_{inv}) \times \texttt{cap\_inst}[n, first(t_{inv})]\]
Why do we use `first()` The variable $\texttt{cap\_inst}$ is declared over all operational periods (see the section on Capacity variables for further explanations). Hence, we use the function $first(t_{inv})$ to retrieve the installed capacity in the first operational period of a given investment period $t_{inv}$ in the function
constraints_opex_fixed.constraints_opex_var:\[\texttt{opex\_var}[n, t_{inv}] = \sum_{t \in t_{inv}} opex\_var(n, t) \times \texttt{cap\_use}[n, t] \times scale\_op\_sp(t_{inv}, t)\]
The function `scale_op_sp` The function $scale\_op\_sp(t_{inv}, t)$ calculates the scaling factor between operational and investment periods. It also takes into account potential operational scenarios and their probability as well as representative periods.
constraints_data:
This function is only called for specified data of the nodes, see above.
The function constraints_capacity receives a new method to handle the minimum up and down time constraints:
On/off transition logic:
\[\texttt{on\_off}[n, t] = \texttt{on\_off}[n, t_{prev}] - \texttt{offswitch}[n, t] + \texttt{onswitch}[n, t]\]
Mutual exclusivity of on/off switching:
\[\texttt{onswitch}[n, t] + \texttt{offswitch}[n, t] \leq 1\]
Minimum up time:
\[\sum_{\tau = t+1}^{t+M-1} \texttt{onswitch}[n, \tau] \leq 1\]
and
\[\texttt{offswitch}[n, t] \leq 1 - \sum_{\tau = t+1}^{t+M-1} \texttt{onswitch}[n, \tau]\]
Minimum down time:
\[\sum_{\tau = t+1}^{t+N-1} \texttt{offswitch}[n, \tau] \leq 1\]
and
\[\texttt{onswitch}[n, t] \leq 1 - \sum_{\tau = t+1}^{t+N-1} \texttt{offswitch}[n, \tau]\]
Capacity conditional on on/off status:
\[\texttt{cap\_use}[n, t] \leq \texttt{on\_off}[n, t] \times n.maxCapacity\]
\[\texttt{cap\_use}[n, t] \geq \texttt{on\_off}[n, t] \times n.minCapacity\]
Upper bound by installed capacity:
\[\texttt{cap\_use}[n, t] \leq \texttt{cap\_inst}[n, t]\]
Installed capacity fixed to defined value:
\[\texttt{cap\_inst}[n, t] = capacity(n, t)\]