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 fieldid
is 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 useFixedProfile
orStrategicProfile
for the capacity, but notRepresentativeProfile
orOperationalProfile
. 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 specifiedinput
andoutput
ratios. The variable operating expenses can be provided asOperationalProfile
as 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 useFixedProfile
orStrategicProfile
for the fixed OPEX, but notRepresentativeProfile
orOperationalProfile
. In addition, all values have to be non-negative.input::Dict{<:Resource,<:Real}
andoutput::Dict{<:Resource,<:Real}
:
Both fields describe theinput
andoutput
Resource
s 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
data
is not required as we include a constructor when the value is excluded.Using `CaptureData` If you plan to use
CaptureData
for aMinUpDownTimeNode
node, it is crucial that you specify your CO₂ resource in theoutput
dictionary. 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 theoutput
dictionary. Hence, not specifying CO₂ asoutput
resource 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 NetworkNode
s.
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
EmissionsData
is 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_installed
is also used inEnergyModelsInvestments
to 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)\]