Backbone—An Adaptable Energy Systems Modelling Framework

Abstract

Backbone represents a highly adaptable energy systems modelling framework, which can be utilised to create models for studying the design and operation of energy systems, both from investment planning and scheduling perspectives. It includes a wide range of features and constraints, such as stochastic parameters, multiple reserve products, energy storage units, controlled and uncontrolled energy transfers, and, most significantly, multiple energy sectors. The formulation is based on mixed-integer programming and takes into account unit commitment decisions for power plants and other energy conversion facilities. Both high-level large-scale systems and fully detailed smaller-scale systems can be appropriately modelled. The framework has been implemented as the open-source Backbone modelling tool using General Algebraic Modeling System (GAMS). An application of the framework is demonstrated using a power system example, and Backbone is shown to produce results comparable to a commercial tool. However, the adaptability of Backbone further enables the creation and solution of energy systems models relatively easily for many different purposes and thus it improves on the available methodologies.

1. Introduction Energy systems are becoming increasingly integrated, especially through the growing use of electricity in the transport sector, as well as for heating and cooling. At the same time, the share of variable renewable energy (VRE) in the power sector is rapidly increasing. The former calls for models with multiple energy sectors to be represented, while the latter requires models with a high temporal and spatial resolution, as well as the ability to take into account short-term and long-term uncertainties related to large volumes of VRE. Many modelling approaches are available for both approaches but only a few have attempted (and succeeded) in achieving both at the same time. The reason for this is at least twofold: (1) the need for considering both aspects concurrently has not been sufficiently urgent until recently for many systems and (2) doing so for larger systems has been computationally prohibitive. However, while computational power has continued to increase, it is never going to be possible to include everything. Consequently, any model that attempts to model multiple energy systems in detail needs to make appropriate compromises. We argue that those compromises will depend on the task at hand and the best compromises will usually not be known beforehand. Accordingly, it would be useful to have a methodology that has a highly adaptable structure that suitably accommodates such needs. This paper lays out such a modelling framework called Backbone. Backbone is adaptable in multiple dimensions. Adaptability is achieved through a framework structure that defines the actual model based on parameter settings and input data, instead of hard-coded structures. As an example, the duration of a time period in a model can be changed with a single parameter, as long as the underlying data has sufficient resolution. This also means that the same framework can be used to define multiple different models from the same data, for example, an investment model and a scheduling model. Adaptability could lead to a complex formulation of all possibilities and exceptions. Backbone tries to avoid this by defining sets and equations in a way that allows them to be multi-purpose. Consequently, the modelling framework remains relatively compact and the detail lies in the input data. The literature includes a multitude of various energy systems model descriptions. In the following we review energy systems models or modelling frameworks that can consider multiple energy sectors. However, none of the reviewed methodologies possess the full range of capabilities outlined in this paper. The methodologies of interest should be capable of representing large systems instead of focusing on local phenomena only. They should also be able to include high temporal or spatial resolutions or stochastic phenomena. It is important that investment planning solutions can be tested by running operational optimization for the optimized portfolios.

MARKAL/TIMES [1] family models are some of the most widely-used in energy systems modelling. They are typically run as deterministic models and at a coarse temporal resolution. So, for example, when considering only 12 time slices per year, it is not possible to properly represent all the important operational situations, nor take into account the start-ups and shutdowns of units. However, documentation does exist of a stochastic version of TIMES [2], as well as unit commitment features [3]. While the literature does not show wide usage of these unit commitment features, the stochastic programming feature was applied, for example, in Reference [4] and the adaptability of the temporal resolution can be seen in the work by Kannan and Turton [5], Blanco et al. [6] and Pina et al. [7], where a TIMES model was run with as many as 288 time slices per year. However, MARKAL/TIMES still remains as a methodology for planning models and it is not suitable for detailed operational optimization.

Other modelling approaches for long-term energy system planning include MESSAGE and OSeMOSYS. The documentation of MESSAGE dates back to 1981 [8], while a stochastic version was introduced in 1996 [9] and later an open-source implementation in 2019 [10]. The flexibility of the framework enables the analysis of entire systems but also applications focusing on one energy sector. However, although modelling of annual, seasonal, daily and hourly variations is allowed, it is not able to properly understand the demand dynamics and the variability of renewable energy sources, as described in a study focused on the power sector development in Iran [11]. OSeMOSYS [12] is an open source modelling system which has been used, for example, to examine the impact of incorporating flexibility requirements into long-term energy systems models [13]. However, the study lacked a unit commitment representation.

Energy systems models with an adaptive representation of different energy sectors also include PRIMES [14] and PERSEUS [15] but no evidence was found of their usage at high temporal or spatial resolution or with stochastic inputs. Instead, they have been soft-linked with operational models to take into account short-term variability [15,16,17].

By contrast, uncertainty and stochastic behaviour play an important role in SMART [18]. Its methodology is based on the framework of approximate dynamic programming (ADP) which can model energy resource allocation—including dispatch, storage and long-term investments in new technologies—at hourly time increments over an entire year or several decades. The methodology captures different sources of uncertainty, such as energy from wind, demand, prices and rainfall. It is based on a deterministic energy planning modelling system META*Net [19], which captures approximately 13 different sources of energy to satisfy 9 types of load. However, SMART does not represent individual energy generators and is not suitable for operational problems, such as unit commitment.

Calliope [20] is an open-source energy systems modelling framework which is explicitly designed to utilise VRE resource data with high spatial and temporal resolutions. In the literature, the Calliope framework has been used to model the power system of Great Britain, neglecting other energy carriers and focusing on electrical power. While, according to the documentation, Calliope is capable of modelling the online status of certain types of units using integer variables, no mention of the use of such variables has been found in the literature, and the methodology is described as being based on linear programming. The Python package FINE (Framework for Integrated Energy System Assessment) represents another framework for modelling, optimizing and assessing energy systems [21].

There are also energy systems model descriptions such as Balmorel [22,23], REMix [24] and SCOPE [25], which focus on the power system but take into account the heat sector as well. The deterministic optimization model Regional Energy Deployment System (ReEDS) [26] is also designed to analyse the electricity sector but it creates links to heat and transport sectors by considering thermal energy storage in buildings, as well as plug-in electric and hybrid vehicles. However, based on the available documentation, the adaptability of these models to fully consider new sectors is rather limited and requires changes to the model code.

Backbone improves on the available methodologies through its adaptability and offers the capability of both investment planning and operational optimization. So long as the base data permits, Backbone users can, with relatively low effort, build different levels of abstraction that allow the solution of planning and operational problems at appropriate scales and speeds. Given the importance of open models and software in energy research [27], one of the advantages of Backbone is that an implementation in GAMS (General Algebraic Modeling System) language is freely available [28].

This paper has three high-level goals. Firstly, to introduce and describe the model structure (Section 2), including specification of the detailed equations (Section 3). Secondly, to present a case study which demonstrates the behaviour of the model against a literature example (Section 4). Validation is of great importance for any new modelling framework, and ideally, Backbone would be benchmarked against a multi-energy systems model. However, since such test systems are not readily available, a power system model has been selected for the case study. The final goal is to briefly outline a forthcoming workplan, which is intended to demonstrate the full capabilities of the Backbone model (Section 5).

2. Model Structure Description 2.1. Network Structure

In Backbone, energy networks and their components are presented by grids, nodes, lines and units. Nodes and lines correspond with the basic structures of graph theory: vertices and arcs. On top of them, grids are used to separate different energy networks, while units are used to categorize functionalities within the nodes. A network structure with nodes and lines allows bottlenecks and losses to be implemented within the grids. Figure 1 presents an example of the network structure.

2.1.1. Grids

Grids are groups of nodes with a common form of energy or another quantity, for example, electricity, heat or water. Grids bring structure to the model and enable the grouping of results. Furthermore, the diffusion and transfer of energy between nodes located in different grids is not permitted directly because the quantities exchanged in different grids are generally not compatible. Instead, a controlled transfer of energy between grids is referred to as a “conversion”, being handled by units capable of conversion, as explained later in Section 2.1.4. Diffusion (meaning uncontrolled leakage) of energy between grids is not currently possible, although it could be relevant in some applications.

2.1.2. Nodes

Nodes are what constitute the “network” part of Backbone and they are arguably the most important aspect of the model structure. Energy balance is enforced at each defined node. Nodes have properties in addition to their (unique) name, with the most important properties listed below:

• State: for example, the energy content, the temperature or similar quantity of the node. Each node can either have a single state, for example, used for storing energy or no state at all.

  – Various boundary conditions can be imposed on the state of a node, ranging from simple absolute upper and lower bounds to “softer” bounds that can be exceeded, at the cost of a separately defined penalty. These bounds can be set to be invariant or to follow some pre-determined time series. It is also possible to constrain a state of a node relative to the state of another node.

• Reserve requirements: Just as the energy balance is enforced on the nodal level, so are the possible requirements for operating reserves, explained in more detail in Section 2.4. Reserve requirements are specific to power systems and are unlikely to be directly relevant for other grid types.

• Spill capability: Nodes can be permitted to spill energy, transferring it outside the model boundaries.
• Contain units: Even though units represent a separate entity altogether, each unit must be connected to at least one node.

2.1.3. Lines

Lines are defined as connections between two nodes. They have the following properties:

• Transfer: Nodes can be connected to other nodes in the same grid via a controlled transfer, which can be defined either as uni- or bi-directional. Naturally, boundaries on the transfer capabilities of nodes can be imposed using various parameters.
• Diffusion: Nodes can be connected to other nodes in the same grid via diffusion coefficients, causing energy to uncontrollably leak from one node to another, depending on the states of said nodes. While diffusion coefficients can technically be defined even for nodes without states, they will have no effect (non-existent states contain zero energy).

  – Diffusion can be defined to be asymmetric, resulting in a unidirectional uncontrolled flow of energy from one node to another.

  – Self-discharge of energy from individual nodes to outside the model scope is also possible using a separate parameter.

2.1.4. Units

While nodes handle the flow of energy within the different grids, they lack the capability to create, consume and convert energy between grids. Similar to nodes, there are many ways that units can be made to function, depending on the parameters given in the input data. The most important properties of units are briefly explained below.

• Production and consumption of energy: A unit can produce energy at a node or consume it.

  – While units could be defined to produce energy out of thin air, more often it is the case that the produced energy is defined to increase the consumption of defined fuels (which should have a cost attributed to them) or have limited production capabilities based on time series data (e.g., solar, wind, hydro).

  – Consumption of energy in units is treated as “negative production”. Unless some form of energy conversion is defined for the unit in question, the consumed energy is transferred out of the model.

  – While nodes could be used to emulate some of the functionality of the units, units provide parameters capable of defining the way in which energy production and consumption function in much more detail.

• Conversion of energy between grids: While energy can diffuse and be transferred between nodes within each grid, units are the only way of transferring (referred to as conversion) energy between nodes in different grids.

  – This functionality essentially means that a unit can be connected to multiple nodes and the energy production and consumption variables in each node are linked to each other according to desired conversion rules and constraints.

2.1.5. Resulting Spatial Structure

The case-specific spatial structure can be defined freely by specifying an appropriate number of nodes and lines. It is also possible to have a different level of detail for different grids and different nodes associated with each grid. Spatial aggregation is not currently automated but it can be achieved by defining multiple parallel data sets for the same geographic footprint and then establishing scenarios that utilise those separate data sets. 2.2. Temporal Structure

Time is divided into sequential blocks that can have different temporal resolutions, as Figure 2 depicts. First, the user needs to define the resolution of the underlying data by stating the duration of a single time step. Then, each block requires an interval duration, measured in time steps and the last time step of the block. Before solving, the model calculates averages for time series parameters when an interval aggregates multiple time steps. The variable temporal resolution can be creatively utilised to reduce the computational requirements, similar to Reference [29].

Backbone has two methods to represent stochastic behaviour. The first method applies a forecast tree that can branch out from a selected time step. A central forecast can be used to continue the horizon after the stochastic tree ends. In this case, the forecast branches are tied back to the central forecast after the final time step in the stochastic tree. The model implements the first n time steps and schedules the future time steps. All decisions that must be made m time steps before the realization are fixed as required (typically reserve allocation—discussed further in Section 2.4—and consequently also unit commitment decisions). In practice, m should be at least twice n. The variables corresponding to the fixed decisions need to be equal between branches in the forecast tree. Next, the model horizon moves forward n time steps and the forecast tree is built for the new situation. The model again realizes the next n time steps and the procedure continues.

The second method to represent stochastic quantities is to select representative periods from the time series. These samples can then be combined, either as parallel alternatives (e.g., different inflow years for water value calculation) or as sequential or circular time lines (e.g., for investment decisions using representative periods). The operational decisions are, in general, independent for each sample but for node states it is possible to create inter-sample constraints, such as storage state continuity.

It is not recommended to use forecasts and samples simultaneously without careful consideration. Forecasts are intended for short-term (typically hours ... days) unit commitment and economic dispatch modelling, while samples are useful when the model is used to optimize investment decisions or long-term storage scheduling (typically months ... years), including the possibility of divesting old, or non-operational, units. Figure 3 illustrates the multi-forecast and multi-sample structures.

2.3. Technological Structure Energy conversion technologies are represented in Backbone by units. Units can consist of several sub-units and several units can be combined to form an aggregate unit. It is possible to represent the energy conversion efficiency using different methods with different levels of accuracy and to model start-up and shutdown trajectories for the conversion technologies. Units are defined to consist of identical sub-units. The number of sub-units can be one but aggregating several conversion plants with similar characteristics into one unit reduces the number of variables and equations in the model and yields computational savings, while it still allows tracking of the number of start-ups and shutdowns of individual units, for instance. The number of operational sub-units is measured using an integer or linear online variable. Investment variables are also based on the number of sub-units and can be both integer or linear. Technological aggregation can be achieved by defining an aggregate that combines multiple distinct units. The aggregation can be switched on at any point in the optimization horizon. For example, hydro power units connected to a certain node can be optimized individually for the first 12 h, after which they can be treated as an aggregated unit for the remainder of the optimization horizon. The model can also employ a changing level of detail in the representation of operational constraints for the units, namely in the representation of conversion efficiency as well as start-up and shutdown behaviour. The different representations can be applied at different points in the optimization horizon so that appropriate detail is presented for the immediate time intervals and less detail for the longer time horizons. The adaptability of the model allows a trade-off to be found that suits different grids, modelling tasks and computational resources. 2.4. Ancillary Services and Policy Constraints The main ancillary service category considered in the model is frequency related reserves. It is possible to define any number of reserve types in the input data and each reserve type can include up and down directions. Reserve requirements can be defined through several alternatives: a constant requirement, a time series, a dependency on the forecasted production of specific units (typically VRE) or on a unit (or combination) providing the largest output. Each unit includes parameters describing its reserve provision capabilities for each reserve category. If the unit has a variable expressing its online status, the unit needs to be online in order to provide reserve. Units that do not incorporate an online status variable can also be defined to provide reserve. It is also possible to define a reserve transfer capability for individual lines so that a unit connected to one node can provide reserve to another node. Each reserve category has a gate closure time, which expresses how many time steps ahead the reserve allocation decisions must be made. How often different reserves are allocated, the duration of the reserve allocation period and the ability to release particular reserve categories for the realized time intervals can also be defined. In addition, other limitations and requirements can be included: a capacity margin, the maximum instantaneous share of certain types of energy production, the minimum number of online units, the maximum permitted volume of emissions (over a given period), the annual energy produced by certain types of units and so forth. 3. Model Formulation The model formulation consists of the objective function and constraints related to energy balance, unit operation, transfers, system operation and portfolio design. The formulation borrows a lot from power system production cost models but it has been generalized to allow modelling of other energy vectors. 3.1. Objective

The objective function to be minimized combines all the eligible costs, including possible investment costs and penalties for violating certain constraints, as follows:

^vobj=∑{f,t}∈FT_{pf,tprobability}×_vf,tvomCost+_vf,tfuelCost+_{vf,tstartupCost}+_{vf,tshutdownCost}+_vf,trampCost+_{vf,tpenalties}+^vstateValue+^vfomCost+^{vunitInvestCost}+^{vlineInvestCost}

Variable operational and maintenance costs_vf,tvomCostand fuel and emissions costs_vf,tfuelCostare defined below:

_vf,tvomCost=_Δf,t×∑n∈N∑u∈_{UnoutputpuvomCost}×_vn,u,f,tgen

_vf,tfuelCost=_Δf,t×∑u∈U∑h∈_{Humainph,u,tfuelCost}×_{vh,u,f,tfuelUse}

_{ph,u,tfuelCost}=_{ph,tfuelPrice}+∑e∈_{Ehph,efuelEmission}×_{∑n∈N pe,nemissionTax}×_{pn,usize∑n∈N pn,usize}

Start-up costs_{vf,tstartupCost}depend on the start-up type a (hot, warm, cold), while shutdown costs_{vf,tshutdownCost}are always the same:

_{vf,tstartupCost}=∑u∈^Uonline∑a∈A(_{pa,ustartupCost}+∑h∈_{Hustartupph,ustartupFuelFraction}×_{pa,ustartupFuelUse}×_{ph,u,tfuelCost})×_{va,u,f,tstartup}

_{vf,tshutdownCost}=∑u∈^Uonline_{pushutdownCost}×_{vu,f,tshutdown}

Dividing upward and downward ramps into constrained tiers,γ, allows modelling of ramping costs_vf,trampCostthat do not depend only on the total change of output over time intervals but also on the ramping speed (rate of change of output):

_vf,trampCost=_Δf,t×∑γ∈Γ∑n∈N∑u∈_{UnrampCostpγ,n,urampUpCost}×_{vγ,n,u,f,trampUp}+_{pγ,n,urampDownCost}×_{vγ,n,u,f,trampDown}

Penalties_{vf,tpenalties}result from the slack variables within the model, which allow violations of energy balance, reserve requirement, state boundary and capacity margin equations:

_{vf,tpenalties}=_Δf,t×∑n∈N(_{pnbalanceSlackPenalty}×_{vn,f,tslackUp}+_{vn,f,tslackDown}+∑r∈R_{prreserveSlackPenalty}×_{vr,n,^fr,treserveSlack}+∑q∈Q_{pq,nstateSlackPenalty}×_{vq,n,f,tstateSlack}+_{pncapacitySlackPenalty}×_{vn,f,tcapacitySlack})

Changes in state value^vstateValueare calculated as follows:

^vstateValue=∑n∈N_{p^freal,^tstartprobability}×_{pn,^tstartstateValue}×_{vn,^freal,^tstartstate}−∑f∈F_{pf,^tendprobability}×_{pn,^tendstateValue}×_{vn,^fc,^tendstate}

Fixed operational and maintenance costs^vfomCost, unit investment costs^{vunitInvestCost}and network investments costs^{vlineInvestCost}are needed in investment optimization and they are calculated as follows:

^vfomCost=∑n∈N∑u∈_{Unpn,ufomCost}×_pn,usize×_vuinvest

^{vunitInvestCost}=∑n∈N∑u∈_{Unpn,uinvestCost}×_pn,uannuity×_pn,usize×_vuinvest

^{vlineInvestCost}=∑{n,^n′}∈NN_{pn,^n′investCost}×_{pn,^n′annuity}×_{vn,^n′invest}

3.2. Energy Balance

An energy balance must be maintained at all nodes according to (13), which involves typical terminology for production, consumption and transfer, but as the nodes can also have a dynamic state variable, terms for energy diffusion and leakage are also represented. The balance equation is constructed such that the left hand side of the equation is equal to the change in state from one time period to the next. For nodes without a state, the left hand side would be zero. The right hand side of the equation contains all terms which affect the state (conversion input/output, transfer, diffusion, external inflow/outflow, self-discharge, spill and slacks), multiplied by the time period duration. The state variable allows the balance equation to represent a simple energy storage unit, an RC circuit for heat transfers and a power grid with DC load flow phase angle differences, as examples.

∀n∈N,{f,t}∈FT:

_{pnspecificStorage}×_{vn,^fc,tstate}−_{vn,^fd,t−dt−state}=_Δf,t×(∑u∈_{Unvn,u,f,tgen}+∑^n′∈_Nn(_{p^n′,ntransferEff}×_{v^n′,n,f,ttransfer}−_{vn,^n′,f,ttransfer}+_{p^n′,ndiffusionCoeff}×_{v^n′,^fc,tstate}−_{pn,^n′diffusionCoeff}×_{vn,^fc,tstate})+_vn,f,tinflux−_{pnselfDischargeLoss}×_{vn,^fc,tstate}−_vn,f,tspill+_{vn,f,tslackUp}−_{vn,f,tslackDown})

3.3. Unit Operation Energy conversion technologies are represented in Backbone by units. While it is possible to represent various characteristics of the technologies using the operational constraints available in Backbone, some of the constraints are needed only for certain type of technologies. The constraints are divided into start-up and shutdown related constraints, ramping constraints, efficiency constraints and other constraints. The fundamental minimum and maximum input/output constraints are included in the start-up and shutdown related constraints, while the category of other constraints includes, for example, reserve provision capabilities of units, which are specific to power plants.

3.3.1. Start-Up and Shutdown

Figure 4 presents a general illustration of the commitment logic of units. Backbone considers start-up and shutdown trajectories of units by assuming a linear increase in the output during the start-up phase and a linear decrease in the shutdown phase. If the unit reaches its minimum operational level during the last interval of the start-up phase, it can stay at that level for the remaining interval, or it can continue its upward ramping according to its normal operational ramping capabilities. The production of the unit for that interval represents the average output. Similar behaviour is assumed in the shutdown phase.

Minimum and maximum output/input constraints are applied to all units, as given by (14) and (15). The output variable_vn,u,f,tgencan be negative, which means that the unit is consuming energy at the given node. Minimum and maximum operational level parameters_{pu,f,tminimum}and_{pu,f,tmaximum}can vary in time—a typical example would be VRE, which is limited in the scheduling time frame by the predicted energy flow.

∀{n,u}∈NU,{f,t}∈FT:

_vn,u,f,tgen−∑r∈^Rdown_{vr,n,u,f,treserve}≥_pn,usizeGen×_{pu,f,tminimum}×_{vu,^fc,tonline}+_{vn,u,f,tgenStartMin}+_{vn,u,f,tgenShutMin}−_pn,usizeCons×_{pu,f,tmaximum}×_{vu,^fc,tonline}

_vn,u,f,tgen+∑r∈^Rup_{vr,n,u,f,treserve}≤_pn,usizeGen×_{pu,f,tmaximum}×_{vu,^fc,tonline}+_{vn,u,f,tgenStartMax}+_{vn,u,f,tgenShutMax}−_pn,usizeCons×_{pu,f,tminimum}×_{vu,^fc,tonline}

Conversion output during the start-up phase and shutdown phase needs to follow the respective trajectory:

∀{n,u}∈NU,{f,t}∈FT:

_{vn,u,f,tgenStartMin}=_pn,usizeGen×∑a∈A∑τ=1⌈_{pustartupSteps}⌉_{pu,τstartupMin}×_{va,u,^fd,t+dτtrstartup}

_{vn,u,f,tgenStartMax}=_pn,usizeGen×∑a∈A∑τ=1⌈_{pustartupSteps}⌉_{pu,τstartupMax}×_{va,u,^fd,t+dτtrstartup}

_{vn,u,f,tgenShutMin}=_pn,usizeGen×∑τ=1⌈_{pushutdownSteps}⌉_{pu,τshutdownMin}×_{vu,^fd,t+dτtrshutdown}

_{vn,u,f,tgenShutMax}=_pn,usizeGen×∑τ=1⌈_{pushutdownSteps}⌉_{pu,τshutdownMax}×_{vu,^fd,t+dτtrshutdown}

Parameters_{pustartupSteps},_{pu,τstartupMin},_{pu,τstartupMax},_{pushutdownSteps},_{pu,τshutdownMin}and_{pu,τshutdownMax} are calculated based on the start-up and shutdown duration and the minimum load of the unit. For the calculation of the parameters, see Reference [28]. In order to align time frames correctly, a displacement operator_dτtris used in the above equations. It is calculated as_dτtr=−τ+1. Start-up and shutdown trajectories are recommended to be used only for an interval duration equal to the original step size.

The online state follows from the start-up and shutdown decisions, as described by (20). Online variables are unified between the forecasts for the final interval of the stochastic phase. It is also possible to define units that do not involve start-up and shutdown decisions, see (21).

∀u∈^Uonline,{f,t}∈FT:

_{vu,^fc,tonline}=_{vu,^fd,t−dt−online}+∑a∈A_{va,u,^fd,t−du,tstartstartup}−_{vu,^fd,tshutdown}

∀u∉^Uonline,{f,t}∈FT:

_{vu,^fc,tonline}=_{pusubunitCount}+_vuinvest

The number of online sub-units is limited by the total number of sub-units and the shutdowns of the sub-units during the minimum downtime period, as described by (22). The downtime displacement parameter_du,tdowntime in (22) includes those steps required for shutdown and start-up. The number of online sub-units is also limited by the number of start-ups during the minimum uptime period, as represented by (23). The uptime displacement parameter_du,tuptime in (23) does not include those steps required for shutdown and start-up.

∀u∈^Uonline,{f,t}∈FT:

_{vu,^fc,tonline}≤_{pusubunitCount}+_vuinvest−∑^t′=t−_du,tdowntimet_{vu,^fd,^t′shutdown}

_{vu,^fc,tonline}≥∑^t′=t−_du,tstart−_du,tuptimet−_du,tstart∑a∈A_{va,u,^fd,^t′startup}

The start-up type (hot, warm, cold) is determined based on the temporal boundaries between start-up types, as described by (24). The equation can be used when the number of sub-units is one but is currently not supported for a larger number of sub-units.

∀a∈^Aconstrained,u∈^Uonline,{f,t}∈FT:

_{va,u,f,tstartup}≤∑^t′=t−_{pa,ustartTypeMax}t−_{pa,ustartTypeMinvu,^fd,^t′shutdown}

3.3.2. Ramping

The operation of units is also restricted by the ramp up and ramp down limits during startup, normal operation and shutdown phases:

∀{n,u}∈NU,{f,t}∈FT:

_Δf,t×_{vn,u,f,tgenRamp}=_vn,u,f,tgen−_{vn,u,^fd,t−dt−gen}

_{vn,u,f,tgenRamp}+∑r∈^Rup_{vr,n,u,f,treserve}/_Δf,t≤_{pn,umaxRampUp}×_pn,usize×_{vu,^fc,tonline}+_{vn,u,f,trampStartup}+_{pn,umaxRampUp}×_pn,usizeCons×_{vu,f,tshutdown}

_{vn,u,f,tgenRamp}−∑r∈^Rdown_{vr,n,u,f,treserve}/_Δf,t≥−_{pn,umaxRampDown}×_pn,usize×_{vu,^fc,tonline}−_{vn,u,f,trampShutdown}

where

_{vn,u,f,trampStartup}=_pn,usizeGen×∑a∈A∑τ=1⌈_{pustartupSteps}⌉_{pu,τstartupRampMax}×_{va,u,^fd,t+dτtrstartup}

_{vn,u,f,trampShutdown}=_pn,usizeGen×∑τ=1⌈_{pushutdownSteps}⌉+1_{pu,τshutdownRampMax}×_{vu,^fd,t+dτtrshutdown}

Ramps are defined as the change in the conversion level from the previous time interval to the current time interval. The model permits an exception to the above constraints (25)–(29) which allows all units without start-up and/or shutdown trajectories to ramp from zero to minimum load and vice versa (that is, to start up and shut down) within one time interval even if their operational ramp limits would not permit such behaviour, see Reference [28]. If a unit does not specify a shutdown trajectory,_{pushutdownSteps}=0and_{pn,umaxRampDown}replaces_{pu,τshutdownRampMax} in (29). Parameters_{pu,τstartupRampMax}and_{pu,τshutdownRampMax} are calculated based on the start-up and shutdown duration and adjusted using the normal ramp rate limit when required. For the calculation of the parameters, see Reference [28].

Separate ramp up and ramp down variables are required for calculating ramping costs resulting from different ramp tiersγ (see also (7)). The variables should match the general ramp variable_{vn,u,f,tgenRamp} according to (30) in the case of units without start-up and shutdown trajectories, and according to (31) in the case of units with start-up and shutdown trajectories. The equations include adjustments ensuring that ramping from zero to minimum load and from minimum load to zero causes only start-up and shutdown costs and not ramping costs. Equations (32)–(33) ensure that the ramp up and ramp down variables remain below their maximum limits in each tierγ.

∀u∉^Utrajectory,{n,u}∈NU,{f,t}∈FT:

_{vn,u,f,tgenRamp}=∑γ∈Γ_{vγ,n,u,f,trampUp}−_{vγ,n,u,f,trampDown}+_puminimum×(∑a∈A_{va,u,f,tstartup}×_pn,usizeGen+_{vu,f,tshutdown}×_pn,usizeCons−_{vu,f,tshutdown}×_pn,usizeGen−∑a∈A_{va,u,f,tstartup}×_pn,usizeCons)/_Δf,t

∀u∈^Utrajectory,{n,u}∈NU,{f,t}∈FT:

_{vn,u,f,tgenRamp}=∑γ∈Γ_{vγ,n,u,f,trampUp}−_{vγ,n,u,f,trampDown}+_pn,usizeGen×∑a∈A∑τ=1⌈_{pustartupSteps}⌉_{pu,τstartupRampMin}×_{va,u,^fd,t+dτtrstartup}−_pn,usizeGen×∑τ=2⌈_{pushutdownSteps}⌉+1_{pu,τshutdownRampMin}×_{vu,^fd,t+dτtrshutdown}

∀γ∈Γ,{n,u}∈NU,{f,t}∈FT:

_{vγ,n,u,f,trampUp}≤_pn,usize×_{pγ,n,umaxRampUp}×_{vu,^fc,tonline}+_pn,usizeCons×_{pγ,n,umaxRampUp}×_{vu,f,tshutdown}+_{vγ,n,u,f,trampStartup}

_{vγ,n,u,f,trampDown}≤_pn,usize×_{pγ,n,umaxRampDown}×_{vu,^fc,tonline}+_pn,usizeGen×_{pγ,n,umaxRampDown}×_{vu,f,tshutdown}+_{vγ,n,u,f,trampShutdown}

where

_{vγ,n,u,f,trampStartup}=_pn,usizeGen×∑a∈A∑τ=⌈_{pustartupSteps}⌉⌈_{pustartupSteps}⌉_{pγ,n,u,τstartupRampAdjust}×_{va,u,^fd,t+dτtrstartup}

_{vγ,n,u,f,trampShutdown}=_pn,usizeGen×∑τ=22_{pγ,n,u,τshutdownRampAdjust}×_{vu,^fd,t+dτtrshutdown}

Variables_{vu,f,tshutdown},_{vγ,n,u,f,trampStartup}and_{vγ,n,u,f,trampShutdown} are needed in (32)–(33) to allow units to start up and shut down above minimum load as fast as they can, when this type of operation is applicable. Variables_{vγ,n,u,f,trampStartup}and_{vγ,n,u,f,trampShutdown}are used only when the units have start-up and shutdown trajectories. For the calculation of parameters_{pu,τstartupRampMin},_{pu,τshutdownRampMin},_{pγ,n,u,τstartupRampAdjust}and_{pγ,n,u,τshutdownRampAdjust} , see Reference [28]. The parameters ensure that ramping from zero to minimum load and from minimum load to zero does not cause ramping costs and that the portion of the start-up or shutdown that goes beyond minimum load is included in the calculation of ramping costs. Ramping to levels above minimum load in the start-up trajectory is possible if the start-up duration_{pustartupSteps}<⌈_{pustartupSteps}⌉and similarly, ramping from above minimum load in the shutdown trajectory is possible if the shutdown duration_{pushutdownSteps}<⌈_{pushutdownSteps}⌉.

3.3.3. Efficiency

Backbone can approximate efficiency curves of energy conversion technologies using different methods: a so-calledλ -approximation with n segments (i.e., piecewise linear input/output), stepwise incremental heat rates (i.e., also piecewise linear input/output), integer online variables with no-load fuel use and linear input/output, linear online variables with no-load fuel use and linear input/output and without online variables (constant efficiency). Figure 5 shows the efficiency of an example unit following different efficiency approximations.

It is assumed that the main fuels (i.e., normal operation fuels) are used for all production above zero, including the start-up and shutdown phases. In the latter situations, the main fuel consumption is based on the efficiency at minimum load. Additional start-up fuel consumption can also be defined and is calculated according to (5). The efficiency representations utilise an approximated online variable which takes into account the fraction of capacity that is producing during the start-up and shutdown phases:

∀u∈^Uonline,{f,t}∈FT:

_{vu,f,tonlineApprox}=_{vu,^fc,tonline}+∑a∈A∑τ=1⌈_{pustartupSteps}⌉_{pu,τstartupMin}/_puminimum×_{va,u,^fd,t+dτtrstartup}+∑τ=1⌈_{pushutdownSteps}⌉_{pu,τshutdownMin}/_puminimum×_{vu,^fd,t+dτtrshutdown}

The simplest method to represent unit efficiency is to apply a direct conversion, as follows:

∀u∈^Udirect,{f,t}∈FT:

−∑n∈_{Nuinputvn,u,f,tgen}+∑h∈_{Humainvh,u,f,tfuelUse}=_{pu,f,teffSlope}×∑n∈_{Nuoutputvn,u,f,tgen}+_{pu,f,teffSection}×∑n∈_{Nuoutputpn,usizeGen}×_{vu,f,tonlineApprox}

In (37),_{pu,f,teffSection}=0ifu∉^Uonline. The direct conversion equation is used in the efficiency representations based on an integer or linear online variable with no-load fuel use and linear input/output, as well as in the efficiency representation without an online variable.

Using incremental heat rates (i.e., piecewise linear fuel use) results in a more detailed representation, with the unit output divided into segments. For each unit, a no-load heat rate is defined in addition to an incremental heat rate for each segment. The implementation of incremental heat rates is described in the following equations:

∀u∈^UincHR,{n,u}∈NU,{f,t}∈FT:

_vn,u,f,tgen=∑hr∈_{HRuvhr,n,u,f,tgen,inc}

∀u∈^UincHR,{n,u}∈NU,hr∈_HRu,{f,t}∈FT:

_{vhr,n,u,f,tgen,inc}≤(_{phr,u,f,teffOp}−_{phr−1,u,f,teffOp})×_pn,usizeGen×_{vu,f,tonlineApprox}

∀u∈^UincHR,{f,t}∈FT:

−∑n∈_{Nuinputvn,u,f,tgen}+∑h∈_{Humainvh,u,f,tfuelUse}=∑hr∈_HRu∑n∈_{Nuoutputphr,u,f,teffHR}×_{vhr,n,u,f,tgen,inc}+_{pu,f,teffSection}×∑n∈_{Nuoutputpn,usizeGen}×_{vu,f,tonlineApprox}

In (38), the output segments must sum to the actual production of the unit, whereH_Ru represents the group of heat rates for one particular unit. Equation (39) ensures that the output segments are bounded by the relevant neighbouring operational points. In (40), energy output is converted into energy usage. The outlined formulation relies upon increasing incremental heat rates, which is typical for most electric generators (although the average heat rate will reduce when the no-load heat rate is included). However, a decreasing heat rate sequence can also be handled by the inclusion of two additional equations, see Reference [28].

Piecewise linear fuel consumption can also be represented usingλ -variables, which belong to a special ordered set of type 2 [30]:

∀u∈^Uλ,{f,t}∈FT:

−∑n∈_{Nuinputvn,u,f,tgen}+∑h∈_{Humainvh,u,f,tfuelUse}=∑n∈_{Nuoutputpn,usizeGen}×∑k∈K_{pu,f,t,keffOp}×_{pu,f,t,keffSlope}×_λu,f,t,k

∑k∈K_λu,f,t,k=_{vu,f,tonlineApprox}

∑n∈_{Nuoutputpn,usizeGen}×∑k∈K_{pu,f,t,keffOp}×_λu,f,t,k=∑n∈_{Nuoutputvn,u,f,tgen}

3.3.4. Other Constraints

Units can employ multiple fuels as their main fuel, with their usage constrained by applying maximum fuel fractions, as described in (44), and maximum fuel consumption, which can be achieved simply by bounding the upper limit of_{vh,u,f,tfuelUse}.

∀u∈U,h∈_Humain,{f,t}∈FT:

_{vh,u,f,tfuelUse}≤_{ph,umainFuelFraction}×∑^h′∈_{Humainv^h′,u,f,tfuelUse}

If a unit has multiple outputs or multiple inputs of different types, such as in the case of a combined heat and power plant, the ratio of the outputs or inputs can be variable or fixed, as described by (45):

∀{n,^n′,u}∈^NNUfix,{f,t}∈FT:

_vn,u,f,tgen/_{pn,uconversionFactor}=_{v^n′,u,f,tgen}/_{p^n′,uconversionFactor}

The reserve provision of units is limited by their capability for each reserve category:

∀r∈R,n∈^Nreserve,u∈U,{f,t}∈FT:

_{vr,n,u,^fr,treserve}≤_{pr,n,ucapability}×_pn,usize×_{pu,f,tmaximum}×(_{pusubunitCount}+_vuinvest)

Reserve requirements from the system perspective are presented in Section 3.5.

3.4. Transfers

Transfer of energy (or another quantity) between nodes is limited by the initial and invested transfer capacity (at the time of the anticipated transfer):

∀{n,^n′}∈NN,{f,t}∈FT:

_{vn,^n′,f,ttransfer}+∑r∈^Rup_{vr,n,^n′,^fr,treserveTransfer}+∑r∈^Rdown_{vr,^n′,n,^fr,treserveTransfer}≤_{pn,^n′transferCap}+_{vn,^n′invest}

The model assumes that_{vn,^n′invest}=_{v^n′,ninvest}.

Separately, the reserve transfer is also limited:

∀r∈R,{n,^n′}∈NN,{f,t}∈FT:

_{vr,n,^n′,^fr,treserveTransfer}≤_{pr,n,^n′capability}×(_{pn,^n′transferCap}+_{vn,^n′invest})

3.5. System Operation System operational constraints can be included in the model in order to procure a sufficient volume of particular system services, limit the simultaneous operation of a group of units, ensure acceptable behaviour of node states and other actions. Some of the constraints, such as reserve requirements and an inertial constraint, are written specifically for power grids, while many of the constraints are more generic and applicable to many grids.

The model can include reserve requirements, which are typically required in power grids to ensure that the system can withstand faults and fast or unforeseen variations in load and generation:

∀r∈R,n∈^Nreserve,{f,t}∈FT:

∑u∈_{Unvr,n,u,^fr,treserve}+∑^n′∈_{Nnp^n′,ntransferEff}×_{vr,^n′,n,^fr,treserveTransfer}≥_{pr,n,f,treserveDemand}+∑u∈_{Unpr,n,ureserveIncrease}×_vn,u,f,tgen+∑^n′∈_{Nnvr,n,^n′,^fr,treserveTransfer}−_{vr,n,^fr,treserveSlack}

where^fris a forecast index that ensures that the correct forecast is also used during the horizon when reserves are locked. Reserve locking mimics real reserve markets with gate closures. TheN−1reserve constraint ensures that there is sufficient reserve to cover the output of each individual unit with a possibility to trip:

∀r∈^Rup,n∈^Nreserve,u∈^Ufail,{f,t}∈FT:

∑^u′∈_Un^u′≠u_{vr,n,^u′,^fr,treserve}+∑^n′∈_{Nnp^n′,ntransferEff}×_{vr,^n′,n,^fr,treserveTransfer}≥_{pr,n,uinfeedToReserve}×_vn,u,f,tgen+∑^n′∈_{Nnvr,n,^n′,^fr,treserveTransfer}−_{vr,n,^fr,treserveSlack}

An inertial constraint, given by (51), ensures a minimum volume of on-line rotational energy from a group of nodes for every interval. The constraint represents one option which captures particular power system stability concerns as growing volumes of VRE replace conventional synchronous generation. Similar simple constraints can be easily added for further system services, as the user requires.

∀ω∈^{ΩrotationalEnergy},{f,t}∈FT:

∑n∈_Nω∑u∈_{Unoutputpn,uinertia}×_pn,usizeMVA×_{vu,^fc,tonline}≥_{pωrotationalEnergy}

It is also possible to limit the instantaneous share of generation from a group of units and the import of, for example, high-voltage direct current (HVDC) lines, as described in (52). This share is defined in relation to the (electrical) consumption of a group of nodes. This constraint can be used, for example, to limit the share of non-synchronous generation in a power system, in which case this constraint approximates power system stability requirements similar to (51). However, this constraint has also potential for other applications.

∀ω∈^{ΩinstantShare},{f,t}∈FT:

∑n∈_Nω∑u∈_{Un,ωoutputvn,u,f,tgen}+∑{^n′,n}∈_NNωn∈_Nω^n′∉_{Nωp^n′,ntransferEff}×_{v^n′,n,f,ttransfer}≤_{pωinstantShare}×∑n∈_Nω−_pn,f,tinflux−∑u∈_{Uninputvn,u,f,tgen}+∑{n,^n′}∈NNn∈_Nω^n′∉_{Nωvn,^n′,f,ttransfer}

In some cases, in order to ensure the feasibility of (52), the model may find it beneficial to utilise the line between nodes n and^n′for 2-way transfers,_{vn,^n′,f,ttransfer}and_{v^n′,n,f,ttransfer} , at the same time. This is prevented, however, in the model by an approximation that aims to ensure that only one transfer flow variable can be non-zero for each time interval. The approximation complicates the equations and is not shown here for clarity. The approximation can be found in Reference [28].

Storage plants with charging and discharging capabilities are modelled in Backbone using two units (one for charging and one for discharging), which can lead to the unwanted behaviour of both units being operational at the same time. However, by grouping the units together and using the online group constraint (53) it is possible to ensure that the charging and discharging units of a storage plant are not concurrently operational. The same constraint can be used to ensure, for example, that at least a certain number of units need to be always operational.

∀ω∈^{ΩonlineGroup},{f,t}∈FT:

∑u∈_{Uωpω,uonlineGroupMultiplier}×_{vu,^fc,tonline}≤_{pωonlineGroupTotal}

The model also includes several equations in order to constrain the behaviour of node states. These equations ensure, for example, that the minimum and maximum levels of storage are not exceeded, that room temperatures are within comfortable ranges and also that power flows in the DC power flow representation do not exceed the line capacities. A state slack constraint permits costs to be imposed for exceeding acceptable states:

∀n∈^Nstate,q∈Q,{f,t}∈FT:

_{vq,n,f,tstateSlack}≥_pqdirection×(_vn,f,tstate−_{pq,n,f,tboundary})

Correctly modelling the reserve provision capability of storage units requires a connection to be made between the state variables of the storage and the reserve provision variables of the units handling the charging and discharging of the storage. The following equations ensure that conversion units connected to a node with a state variable cannot provide reserve that would violate the upper or lower boundaries of the said state variable. Naturally, the invested state capacity has an impact on the upward boundary of the storage nodes in question. While the previous equation, (54), allowed for “softer” bounds that can be exceeded at the cost of a separately defined penalty, Equations (55) and (56) provide absolute upper and lower boundaries for the state variables.

∀n∈^Nstate,{f,t}∈FT:

_{pn,f,tupLimit}+∑u∈_{Unpn,ustateLimitIncrease}×_pn,usize×_vuinvest−_{vn,^fc,tstate}×_{pnspecificStorage}+_Δf,t×_{pnselfDischargeLoss}+∑^n′∈_{Nnpn,^n′diffusionCoeff}≥_Δf,t×_{vn,f,treserveDownInput}+_{vn,f,treserveDownOutput}

_{vn,^fc,tstate}−_{pn,f,tdownLimit}×_{pnspecificStorage}+_Δf,t×_{pnselfDischargeLoss}+∑^n′∈_{Nnpn,^n′diffusionCoeff}≥_Δf,t×_{vn,f,treserveUpInput}+_{vn,f,treserveUpOutput}

where

_{vn,f,treserveDownInput}=∑r∈^Rdown∑^n′∈N∑u∈_{U^n′,nvr,^n′,u,^fr,treserve pu,f,teffSlope}

_{vn,f,treserveDownOutput}=∑r∈^Rdown∑^n′∈N∑u∈_{Un,^n′pu,f,teffSlope}×_{vr,^n′,u,^fr,treserve}

_{vn,f,treserveUpInput}=∑r∈^Rup∑^n′∈N∑u∈_{U^n′,nvr,^n′,u,^fr,treserve pu,f,teffSlope}

_{vn,f,treserveUpOutput}=∑r∈^Rup∑^n′∈N∑u∈_{Un,^n′pu,f,teffSlope}×_{vr,^n′,u,^fr,treserve}

It is worth noting that the efficiency approximations of the conversion units are not rigorously considered in the above equations but instead the maximum efficiency of the unit is assumed, in order to keep the model linear. Typically, plants operate at or close to their maximum efficiency, hence the error arising from this approximation can be assumed to be small. Moreover, it is assumed that if a node has a state variable, then it should not have reserve requirements, which is why reserve transfers between nodes are not included in the previous equations. Finally, it may seem counterintuitive that in (56), self discharge and diffusion coefficients from node n increase the possibility of the node providing upward reserve to other nodes. This can be explained by the model discretization (see also the balance equation (13)): with upward reserve provision, the losses from self discharge and diffusion are smaller than they would have been if energy had not been removed through upward reserve provision and hence node n can provide more upward reserve to other nodes than the energy available in the storage.

The difference between the states of two nodes can be constrained, as described by (61). This constraint can be used, for example, to ensure that power flows do not exceed line capacities in the DC power flow representation. If the amount of energy stored per unit of state, that is,_{pnspecificStorage}or_{p^n′specificStorage} , is zero, as is the case with the DC power flow representation, the terms including them in (61) are ignored.

∀{n,^n′}∈^NNbound,{f,t}∈FT:

_{vn,^fc,tstate}+_Δf,t/_{pnspecificStorage}×_{vn,f,treserveDownInput}+_{vn,f,treserveDownOutput}≤(_{v^n′,^fc,tstate}+_{pn,^n′maxDiff})−_Δf,t/_{p^n′specificStorage}×_{v^n′,f,treserveUpInput}+_{v^n′,f,treserveUpOutput}

It is possible to create cyclic boundaries for node states, according to (62). The equation enables modelling of the seasonal evolution of storage levels when optimizing investments using representative periods, as an example. By applying (62) it is possible to require that the node state at the beginning of one sample must equal the state at the end of another sample (or, indeed, the same sample). A similar equation is applied to nodes where the state must be the same at the beginning and the end of the optimization horizon (63).

∀{n,s,^s′}∈^NSSbound,{f,t}∈FT,t=_psend,^t′=_p^s′start:

_vn,f,tstate=_{vn,f,^t′state}

∀n∈^{NboundStartEnd}:

_{vn,^fcentral,^tendstate}=_{vn,^freal,^tstartstate}

3.6. Portfolio Design

Some of Backbone’s equations are designed specifically for portfolio planning. The equations constrain portfolio planning based on capacity requirements, annual emission volumes and annual energy outputs of different production types. In order to take into account security of supply, a capacity margin constraint (64) can be applied at each node and for each interval. This ensures that sufficient new production capacity is built on time, while also recognizing, perhaps, existing plant retirements.

∀n∈N,{f,t}∈FT:

∑u∈_{Unoutputvn,u,f,tavailableCapacity}+∑^n′∈_Nn(_{p^n′,ntransferEff}×_{v^n′,n,f,ttransfer}−_{vn,^n′,f,ttransfer}+_{p^n′,ndiffusionCoeff}×_{v^n′,^fc,tstate}−_{pn,^n′diffusionCoeff}×_{vn,^fc,tstate})+∑u∈_{Uninputvn,u,f,tgen}+_pn,f,tinflux+_{vn,f,tcapacitySlack}≥_{pncapacityMargin}

where

_{vn,u,f,tavailableCapacity}=_{pu,f,tmaximum}×_pn,usize×(_{pusubunitCount}+_vuinvest)

In Backbone, the investment variable of energy conversion technologies (i.e., units) is the number of sub-units. The ratios of sub-unit investments of multiple energy conversion technologies can be constrained or fixed by using a capacity group constraint (66). For example, it is possible to require that unit type A receives the same number of sub-unit investments as unit type B. This can be useful when a storage plant must have the same number of charging and discharging sub-units. Similarly, the total number of sub-unit investments of multiple energy conversion technologies can be constrained using the same equation. In this way it is possible to require, for example, that investments cannot be made both in unit type C and unit type D. Such a constraint can be used to consider replacement and decommissioning decisions.

∀ω∈^{ΩcapacityGroup}:

∑u∈_{Uωpω,ucapacityGroupMultiplier}×_vuinvest≤_{pωcapacityGroupTotal}

The model also includes equations for limiting emissions and the annual energy output based on production type, see Reference [28].

4. Case Study In the following we present an application of the Backbone framework as a short-term production cost model to a publicly available test system data set, and compare the results to a commercial model. The purpose of the comparison is to demonstrate that the framework, and its implementation in GAMS, function as intended. The test system involves only the power system.

Barrows et al. [31] have previously performed test runs on the same test system data set with PLEXOS, Backbone and Prescient production cost models. The purpose of these short test runs was to demonstrate the suitability of the data set for different tools. A more rigorous comparison is needed for a new modelling framework.

4.1. Backbone Modelling Tool

The Backbone modelling framework was implemented in GAMS as the Backbone modelling tool. This GAMS program formulates a large mixed-integer programming (MIP) problem based on given input data and any open-source or commercial optimization solvers linked to GAMS can be used to solve the problem. The native input and output data format is GAMS GDX but conversion tools from major formats are available. All parameters defining the model structure can be set via input files or command line arguments. The GAMS source code for the program is published under the GNU Lesser General Public License version 3 at https://gitlab.vtt.fi/backbone/backbone/. Version 1.1 of the modelling tool [28] was used in the case study but the software is still under active development.

4.2. The RTS-GMLC Test System

The IEEE Reliability Test System (RTS) is an imaginary power system with a defined transmission grid, generators and consumption patterns. It was developed in the United States in 1979 in order to conduct analyses on the impact of generation and transmission outages [32]. The purpose was to allow the comparison of different reliability evaluation tools. Since its introduction, the RTS has grown in size and features. The update implemented by The Grid Modernization Laboratory Consortium to the RTS was used as a platform to study model performance. The resulting RTS-GMLC test system [31], which includes a substantial capacity of VRE generation, is well documented and freely available [33]. The RTS-GMLC allows the testing of many of the capabilities which have been built into Backbone, such as varying efficiencies and storage modelling. A drawback is that the system contains only the electrical grid and other types of grids (e.g., gas) have not been defined.

The RTS-GMLC covers a geographical region of roughly 450 km × 400 km (Figure 6). While it does not represent any real system, it was projected onto south-western United States in order to obtain spatially and temporally coincident weather data. Both hourly and 5-minute resolution load, run-of-river hydropower, wind power and solar photovoltaic (PV) profiles are included. The hourly profiles represent day-ahead forecasts while the 5-minute profiles represent actual load or generation. The same types of profiles are given for the required supply of several reserve products.

RTS-GMLC includes 73 nodes, 106 transmission lines and 158 generators. Spatially the system is divided into three regions which are all connected. For combustion plants, minimum load and incremental heat rates for three tranches have been defined. Similarly, minimum up and down times as well as fuel price, start-up and shutdown costs have been defined. 4.3. PLEXOS Implementation

The National Renewable Energy Laboratory (NREL) has prepared a PLEXOS implementation of the RTS-GMLC test system [31]. PLEXOS is a commercially available energy systems optimization software developed by Energy Exemplar [34]. For this implementation, only the day-ahead simulation steps are performed, which means that one simulation step is 24 h long and the day-ahead load, PV and wind power profiles are used. The time resolution of the simulation is one hour. End-of-horizon effects (e.g., start-up and shutdown decisions for slow units) are avoided by including a 24 h look ahead period at each simulation step. The temporal structure is illustrated in Figure 7.

Certain other simplifications have also been taken by NREL [31]. For example, reserve provision was not considered; the concentrated solar power plant and the battery storage unit were not included; the start-up lead time for power plants was not considered; plant start-ups were modelled using binary variables, that is, a MIP model was employed; different start-up types (e.g., cold or warm) were not modelled; the start-up costs were taken as the cold start fuel cost; plant shutdown costs, contrary to the RTS-GMLC, were assumed equal to the start-up costs; emission costs were neglected. As the objective is to compare the results of Backbone to another modelling tool, the validity of these modelling choices, as such, is not important in this case study, apart from the ability of the test system to fully exploit the capabilities of Backbone. The generation capacity of this implementation of the RTS-GMLC has been shown in Figure 8.

The DC power flow calculation method was used in the calculation of transmission flows. The assumption implies that line resistances are small compared to reactances and losses can be neglected. 4.4. Backbone Implementation

The same assumptions concerning generator plants and transmission grid, as were made in the PLEXOS implementation, were made in the Backbone model. Conventional units were modelled with piecewise linear fuel consumption, as in Equations (38)–(40). Adding multiple VRE units of the same type to a single node is of negligible value in Backbone and they were thus aggregated into a single unit. Only the central forecast in Figure 3, which represents the 24 h look-ahead period, was used. The DC power flow calculation was implemented by using the node state variables^vstateas phase angles.

In addition to direct implementation of the RTS-GMLC, a verification scenario was also run. In this scenario, the production schedule, created by PLEXOS, was given to Backbone exogenously. The purpose of this was to check the resulting total cost and feasibility of this solution in Backbone. In both models the stopping tolerance of the MIP solver was set to 0.1%. Backbone employed the CPLEX solver while PLEXOS relied on Xpress-MP. 4.5. Comparison of Results

Using the above assumptions, both Backbone and PLEXOS models were applied to create a two-week schedule of the RTS-GMLC day-ahead simulation, requiring approximately 35 min on a laptop PC with Core i7-6600U processor to run the Backbone simulation. The results were compared in terms of total production cost, generation output by generator type, renewables curtailment and the marginal cost of production. For example, Stoll et al. [35] have used the first three metrics for comparison of different implementations of a production cost model in PLEXOS. The total production cost can be considered a meaningful metric when demonstrating model behaviour, given that the objective of the models is to obtain the least cost production schedule. The computational requirements of Backbone and PLEXOS cannot be directly compared as they were run on different computer environments.

Figure 9 illustrates electricity production during the first week, categorized by the generator type, while Table 1 shows a comparison of the total production over the complete two-week period. The largest production differences over the two week period, 8.3 and 7.2 GWh (1.5% and 1.6%) respectively, occur in coal- and gas-fired generation. While Backbone substituted some expensive gas with coal, PLEXOS utilised somewhat more wind and solar power (0.4 and 1.0 GWh or 0.2% and 0.4%, respectively). The solution obtained by Backbone is slightly cheaper, as can be seen from Table 2, which shows the total operational cost for each model for the 2 week period. The difference in total cost is 0.15% which is comparable to the 0.1% solver tolerance (relative gap between the objective values of the solution and linear relaxation of the problem).

Similarly, comparing the marginal cost of electricity in each model we find that for 53% of the time the difference was smaller than $0.01 per MWh. Occasionally, different decisions in unit commitment lead to greater differences in the marginal cost. Figure 10 shows the duration curves of marginal cost in the three different regions of the RTS-GMLC. Some differences can also be seen in the VRE curtailment as a function of time (Figure 11), as curtailment is greatly dependent on unit commitment.

Running the verification scenario in Backbone confirmed that the PLEXOS solution is a feasible solution in Backbone. It resulted in the same total cost as obtained by PLEXOS (Table 2), which is only slightly higher than the total cost of the direct solution by Backbone. This increases our confidence in the correctness of constraints and the objective function of the Backbone model.

We define the_ℓ2distance between solutions as the square root of sum of squares of differences in generation values of generator plants in different solutions. The_ℓ2distance between the PLEXOS solution and the Backbone solution was 4370 MWh, which turns into 13.0 MWh/h when divided by the length of the schedule in hours. The_ℓ2distance was reduced to zero in the verification scenario. We thus find that the problem can have several sub-optimal solutions which can lie relatively far from each other but be close in terms of total cost.

The differences are most likely caused by the MIP solution tolerance and the simulation process, where differences in one step are carried over to the initial conditions of the next simulation step. The differences obtained by Barrows et al. [31] in total generation by generator type lie in the same range as obtained here, or were larger. We may note that as the optimization problem formulation and simulation process used by PLEXOS is proprietary, it is impossible to exactly diagnose the exact differences between PLEXOS and Backbone [31].

This is the first test of Backbone against another production cost model framework. The performed test runs give us welcome confidence that the model works as intended for this type of problem. The confidence level could be increased by performing longer test runs and lowering the solver tolerance in both Backbone and PLEXOS. 5. Discussion and Conclusions

A novel energy systems modelling framework which is easy to re-configure for different purposes has been presented. An application of the modelling framework implementation in GAMS, called Backbone modelling tool, to a power system test case has been demonstrated. New energy sectors, energy vectors, other processes and material flows can be added through the input data and future applications will demonstrate the wider capabilities of the modelling framework. It allows detailed modelling of specific systems, as demonstrated in the case study of this paper, as well as high-level modelling of large-scale systems [36]. The presented equations make it possible to perform both investment and operational optimization. These features permit versatile approaches to model future energy systems with increasing connections between electricity and other energy sectors. The adaptability of the framework and its implementation allows for exploratory modelling to find reasonable trade-offs between accuracy and speed during the modelling task.

The article has demonstrated that Backbone gives results comparable to a commercial modelling tool. However, only a portion of Backbone’s capabilities were exploited in the comparison. The paper has presented structures and equations for reserve products, start-up and shutdown trajectories, unit efficiency approximations, investment optimization, sector interactions, different temporal representations and stochastic features. Future applications will demonstrate the use of these additional capabilities. Backbone can now be used to answer research questions related to energy system co-ordination, scheduling and planning. As the presented equations enable a high level of operational detail in investment planning, such as start-up and ramping costs, one of the early questions will be to address the relative importance of presenting different aspects of technological and temporal detail in energy systems with high levels of VRE. Another direction to explore is the potential flexibility in the industrial sector, since Backbone can include relatively detailed representations of (linearized) industrial processes. We are also interested in investigating if electrification of energy (transport, industries, heating, cooling, etc.) can reveal cost-effective solutions to fully de-carbonize power and energy systems. Many more research questions are possible, especially through further model development.

In order to increase the effectiveness of model development efforts in the energy systems community, we have shared the Backbone modelling tool with an open-source license and we hope to have an increasing number of users and developers to assist with building new capabilities and to widen the cross-institutional collaboration that we have already established. There are several directions to be taken. For example, investment planning should be able to encapsulate several decades with ease. That would propose a methodology that can simultaneously model consistent energy system transitions, as well as operational flexibility requirements and stability concerns. An early version of Backbone included ramp dispatch capability, which could be re-introduced, as it shows promise as part of a fast and accurate optimization strategy [37]. The modelling framework should also permit the use of different forecast trees in different geographic areas (e.g., a single forecast in one region and three forecasts in a neighbouring region). When new industrial or chemical processes are modelled, there can be a need to build process specific constraints—a library of such features would be a valuable addition. Multiple alternative directions are also possible and will depend on the needs and desires of the evolving community.

Plant Type	PLEXOS	Backbone
Coal	570.3	578.6
Gas	445.5	438.2
Solar	255.3	254.3
Hydro	219.1	219.1
Wind	169.3	168.9
Nuclear	134.2	134.2
Oil	0.4	0.7

Cost Type	PLEXOS	Backbone
Fuel cost	26.49	26.49
Start-up and shutdown cost	0.52	0.48
Total	27.01	26.97

Author Contributions

Conceptualization, J.K.; methodology, N.H., J.K., T.R., E.R., C.O. and R.L.; software, N.H., J.K., J.I., T.R., E.R., C.O. and R.L.; validation, J.I.; formal analysis, J.I.; investigation, J.I.; data curation, J.I.; writing-original draft preparation, N.H., J.K. and J.I.; writing-review and editing, T.R., E.R., C.O., R.L. and D.F.; visualization, N.H. and J.I.; supervision, J.K. and D.F.; project administration, J.K. and D.F.; funding acquisition, N.H., J.K. and D.F.

Funding

N. Helistö, J. Kiviluoma, J. Ikäheimo, T. Rasku, and E. Rinne acknowledge funding from the Academy of Finland project "Improving the value of variable and uncertain power generation in energy systems (VaGe)" (grant number 284973), which is part of the New Energy programme; as well as from the Strategic Research Council at the Academy of Finland, project "Transition to a resource efficient and climate neutral electricity system (EL-TRAN)" (grant number 314319). N. Helistö also acknowledges funding from the Jenny and Antti Wihuri Foundation. Ciara O'Dwyer has received funding from the European Union Horizon 2020 research and innovation programme under grant agreement No 773505. Ran Li and J. Kiviluoma are supported by Science Foundation Ireland under the Strategic Partnership Programme Grant SFI/15/SPP/E3125.

Conflicts of Interest

The authors declare no conflict of interest. The funders had no role in the design of the study; in the collection, analyses, or interpretation of data; in the writing of the manuscript, or in the decision to publish the results.

Nomenclature

Indices and Sets
a∈A	Start-up typesA={cold,warm,hot}
a∈Aconstrained	Start-up types which can only take place if the unit has not been offline for too longAconstrained={warm,hot}
e∈Eh	Emissions of fuel h
f∈F	Forecasts (freal,fcentralfor realized and central forecasts)
fc	Forecast index; normally the same forecast as the current f except in the last interval of the stochastic horizon, in which casefcrefers to the central forecast
fd	Forecast index; normally the same forecast as the current f except during the realized horizon, in which casefdrefers to the realized forecast
fr	Forecast index; normally the same forecast as the current f except during the horizon when reserves have been locked / are to be locked, in which casefrrefers to the realized forecast
h∈Humain	Main fuels of unit u
h∈Hustartup	Start-up fuels of unit u
hr∈HRu	Incremental heat rate segments
k∈K	Indices for representing piecewise linear efficiency curves usingλ-variables
n∈N	Nodes
n∈Nn'	Nodes with a line to noden'
n∈Nω	Nodes that are in groupω
n∈NboundStartEnd	Nodes where state needs to be the same in the first and last interval of a horizon
n∈Nuinput	Nodes where unit u has consumption capacity
n∈Nuoutput	Nodes where unit u has production capacity
n∈Nreserve	Nodes with reserve demand
n∈Nstate	Nodes with state variable
q∈Q	Indices for state slacks (soft bounds)
r∈R	Reserve categories
r∈Rdown	Downward reserves
r∈Rup	Upward reserves
s∈S	Samples
t∈T	Time intervals (tstart,tendfor the first and last time intervals)
u∈U	Units
u∈Un	Units that have capacity in node n
u∈Un,n'	Conversion units taking input from node n and outputting to noden'
u∈Uω	Units that are in groupω
u∈Udirect	Units using direct input to output conversion
u∈Ufail	Units that have a possibility to trip
u∈UincHR	Units using incremental heat rates for part-load efficiency representation
u∈Uninput	Units that have consumption capacity in node n
u∈Uonline	Units that have online variable
u∈Unoutput	Units that have production capacity in node n
u∈Un,ωoutput	Units that have production capacity in node n and are in groupω
u∈UnrampCost	Units that have ramping costs in node n
u∈Utrajectory	Units that have start-up and shutdown trajectories
u∈Uλ	Units using piecewise linear efficiency representation for part-load efficiencies (λ-variables)
{f,t}∈FT	Forecast-interval combinations
{n,n'}∈NN	Lines
{n,n'}∈NNω	Lines that are in groupω
{n,n'}∈NNbound	Node pairs with constrained state difference
{n,n',u}∈NNUfix	A bond between two inputs or outputs in a single unit (fixed ratio between the outputs/inputs)
{n,s,s'}∈NSSbound	Nodes where state needs to be the same at the end of sample s and at the beginning of samples'
{n,u}∈NU	Node-unit combinations
γ∈Γ	Indices for ramp tiers
τ	Time step index (an alternative for t, which is mainly used for intervals)
ω∈Ω	Groups (for defining equations over a number of nodes, units, etc.),ΩrotationalEnergy,ΩinstantShare,ΩonlineGroup,ΩcapacityGroup
Parameters
dt-	Displacement to the previous interval, in time steps (≥0)
du,tdowntime	Displacement to the shutdown decision if t is the last interval when unit u still needs to be offline, in time steps (≥0)
du,tstart	Displacement to the start-up decision if unit u becomes online at interval t, in time steps (≥0)
dτtr	Displacement operator for aligning time frames (used with start-up and shutdown trajectories)dτtr=-τ+1
du,tuptime	Displacement to the interval when unit u became online if t is the last interval when the unit still needs to be online, in time steps (≥0)
pn,n'annuity	Line annuity factor based on number of periods n and rate per period r:r1-(1+r)-n, in (1/a)
pn,uannuity	Unit annuity factor based on number of periods n and rate per period r:r1-(1+r)-n, in (1/a)
pnbalanceSlackPenalty	Penalty of not meeting the balance equation, in CUR/MWh
pq,n,f,tboundary	Soft upper or lower bound for the state of node n, in[vn,f,tstate]
pr,n,n'capability	Reserve provision capability of line{n,n'}, in p.u.
pr,n,ucapability	Reserve provision capability of unit u, in p.u.
pω,ucapacityGroupMultiplier	Multiplier of a unit investment variable when constraining the number of invested units for a group of units
pωcapacityGroupTotal	Maximum value for the sum of multiplied investment variables when constraining the number of invested units for a group of units
pncapacityMargin	Capacity margin, in MW
pncapacitySlackPenalty	Penalty of not meeting the capacity requirement, in CUR/MWh
pn,uconversionFactor	The ratio of one output or input to another output or input if the ratio of them is fixed
pn,n'diffusionCoeff	Coefficient for energy diffusion between nodes, in MW/[vn,f,tstate]
pqdirection	Sign for the state slack direction,+1for upward boundaries and-1for downward boundaries
pn,f,tdownLimit	Absolute lower limit of the state variable, in[vn,f,tstate]
phr,u,f,teffHR	Incremental heat rate of segmenthr
phr,u,f,teffOp	Operating point related to segmenthr, in p.u.
pu,f,t,keffOp	Operating point of theλ-variable k, in p.u.
pu,f,teffSection	Heat rate parameter representing no-load fuel consumption, calculated differently for direct conversion and incremental heat rate representation
pu,f,teffSlope	The slope of the linearized input/output curve
pu,f,t,keffSlope	The slope related to theλ-variable k
pe,nemissionTax	Emission price or tax, in CUR/kg
psend	The last time step of sample s
pn,ufomCost	Fixed operational and maintenance costs, in CUR/MW(/a)
ph,u,tfuelCost	Fuel and emission costs, in CUR/MWh
ph,efuelEmission	Emission content in a fuel, in kg/MWh
ph,tfuelPrice	Fuel price, in CUR/MWh
pn,uinertia	Inertia constant, in MJ/MVA
pr,n,uinfeedToReserve	Proportion of unit output that needs to be covered by reserves (preparing for a trip of the largest unit in node n), in p.u.
pn,f,tinflux	External energy inflow/outflow, in MWh/h (<0for consumption)
pωinstantShare	Maximum instantaneous share of output
pn,n'investCost	Line investment costs, in CUR/MW
pn,uinvestCost	Unit investment costs, in CUR/MW
pn,n'maxDiff	Maximum difference between the state of two nodes, in[vn,f,tstate]
pu,f,tmaximum	Maximum production/consumption capacity, in p.u.
pn,umaxRampDown	Maximum ramp down speed, in p.u./h
pγ,n,umaxRampDown	Maximum ramp down speed of tierγ, in p.u./h
pn,umaxRampUp	Maximum ramp up speed, in p.u./h
pγ,n,umaxRampUp	Maximum ramp up speed of tierγ, in p.u./h
ph,umainFuelFraction	Maximum proportion of fuel h in normal operation
puminimum	Minimum production/consumption capacity, in p.u.
pu,f,tminimum	Minimum production/consumption capacity, in p.u.
pωonlineGroupTotal	Maximum value for the sum of multiplied online variables when constraining the number of online units for a group of units
pω,uonlineGroupMultiplier	Multiplier of a unit online variable when constraining the number of online units for a group of units
pf,tprobability	The probability or weight of intervalf,t
pγ,n,urampDownCost	Cost of ramping down, in CUR/MW
pγ,n,urampUpCost	Cost of ramping up, in CUR/MW
pr,n,f,treserveDemand	Reserve demand, in MW
pr,n,ureserveIncrease	Reserve demand increase caused by the output of unit u (typically preparing for variability and uncertainty), in p.u.
prreserveSlackPenalty	Penalty of not meeting the reserve demand, in CUR/MWh
pωrotationalEnergy	Minimum rotational energy, in MJ
pnselfDischargeLoss	Self-discharge rate of the node, in MW/[vn,f,tstate]
pushutdownCost	Cost of shutting down a unit, in CUR/unit
pu,τshutdownMax	Maximum production during the shutdown phase, in p.u.
pu,τshutdownMin	Minimum production during the shutdown phase, in p.u.
pγ,n,u,τshutdownRampAdjust	The difference between the maximum and minimum ramping during the shutdown phase, in p.u./h
pu,τshutdownRampMax	Maximum ramping during the shutdown phase, in p.u./h
pu,τshutdownRampMin	Minimum ramping during the shutdown phase, in p.u./h
pushutdownSteps	Number of time steps needed for shutdown phase
pn,usize	Capacity of a sub-unit, in MW.pn,usize=pn,usizeGen+pn,usizeCons
pn,usizeCons	Consumption capacity of a sub-unit, in MW
pn,usizeGen	Production capacity of a sub-unit, in MW
pn,usizeMVA	Capacity of a sub-unit, in MVA
pnspecificStorage	Unit conversion if state variable uses something else than MWh, in MWh/[vn,f,tstate]
psstart	The first time step of sample s
pa,ustartTypeMax	Maximum time after shutdown when a start-up decision can be made, in time steps
pa,ustartTypeMin	Minimum time after shutdown when a start-up decision can be made, in time steps
pa,ustartupCost	Cost of starting up a unit, in CUR/unit
ph,ustartupFuelFraction	Proportion of fuel h in start-up
pa,ustartupFuelUse	Start-up fuel use during the start-up phase, in MWh/unit
pu,τstartupMax	Maximum production during the start-up phase, in p.u.
pu,τstartupMin	Minimum production during the start-up phase, in p.u.
pγ,n,u,τstartupRampAdjust	The difference between the maximum and minimum ramping during the start-up phase, in p.u./h
pu,τstartupRampMax	Maximum ramping during the start-up phase, in p.u./h
pu,τstartupRampMin	Minimum ramping during the start-up phase, in p.u./h
pustartupSteps	Number of time steps needed for start-up phase
pn,ustateLimitIncrease	Increase in the upper limit of the state variable when investing in units, in[vn,f,tstate]/MW
pq,nstateSlackPenalty	Penalty of exceeding the soft bounds of node states, in CUR/[vn,f,tstate]/h
pn,tstateValue	Value of the node state, in CUR/[vn,f,tstate]
pusubunitCount	Number of sub-units
pn,n'transferCap	Transfer capacity limit, in MW
pn,n'transferEff	Transfer efficiency
pn,f,tupLimit	Absolute upper limit of the state variable, in[vn,f,tstate]
puvomCost	Variable operational and maintenance costs, in CUR/MWh
Δf,t	Length of interval{f,t}, in h
Variables
vn,u,f,tavailableCapacity	Available capacity, in MW
vn,f,tcapacitySlack	Dummy capacity to ensure capacity margin feasibility, in MW (≥0)
vfomCost	Fixed operational and maintenance costs, in CUR(/a)
vf,tfuelCost	Fuel and emission costs, in CUR
vh,u,f,tfuelUse	Fuel use, in MWh/h (≥0)
vn,u,f,tgen	Conversion input (<0) or output (>0), in MWh/h
vhr,n,u,f,tgen,inc	Production for each heat rate segment, in MWh/h
vn,u,f,tgenRamp	Ramp from the previous interval to interval t, in MW/h
vn,u,f,tgenShutMax	Maximum production during the shutdown phase, in MWh/h
vn,u,f,tgenShutMin	Minimum production during the shutdown phase, in MWh/h
vn,u,f,tgenStartMax	Maximum production during the start-up phase, in MWh/h
vn,u,f,tgenStartMin	Minimum production during the start-up phase, in MWh/h
vn,n'invest	Invested transfer capacity, in MW (≥0)
vuinvest	Number of invested sub-units, in p.u. (≥0, continuous or integer)
vlineInvestCost	Line investment costs, in CUR(/a)
vobj	Objective function value, in CUR
vu,f,tonline	Number of sub-units online, in p.u. (≥0, continuous or integer)
vu,f,tonlineApprox	Approximated online variable that takes into account start-up and shutdown trajectories, in p.u.
vf,tpenalties	Penalties, in CUR
vf,trampCosts	Ramping costs, in CUR
vγ,n,u,f,trampDown	Ramping down, in MW/h (≥0)
vn,u,f,trampShutdown	Helper variable to relax ramp down constraint during the shutdown phase, in MW/h
vγ,n,u,f,trampShutdown	Helper variable to calculate ramp down variable and ramping costs during the shutdown phase, in MW/h
vn,u,f,trampStartup	Helper variable to relax ramp up constraint during the start-up phase, in MW/h
vγ,n,u,f,trampStartup	Helper variable to calculate ramp up variable and ramping costs during the start-up phase, in MW/h
vγ,n,u,f,trampUp	Ramping up, in MW/h (≥0)
vr,n,u,f,treserve	Capacity reserved for providing reserves, in MW (≥0)
vn,f,treserveDownInput	Downward reserve provision impact to node n, summed over those units that have output capacity at node n and provide reserves to their input node, in MW
vn,f,treserveDownOutput	Downward reserve provision impact to node n, summed over those units that have input capacity at node n and provide reserves to their output node, in MW
vr,n,f,treserveSlack	Dummy to decrease reserve demand, in MW (≥0)
vr,n,n',f,treserveTransfer	Transfer capacity reserved for providing reserves, in MW (≥0)
vn,f,treserveUpInput	Upward reserve provision impact to node n, summed over those units that have output capacity at node n and provide reserves to their input node, in MW
vn,f,treserveUpOutput	Upward reserve provision impact to node n, summed over those units that have input capacity at node n and provide reserves to their output node, in MW
vu,f,tshutdown	Number of sub-units shut down, in p.u. (≥0, continuous or integer)
vf,tshutdownCost	Shutdown costs, in CUR
vn,f,tslackDown	Dummy consumption to ensure balance equation feasibility, in MWh/h (≥0)
vn,f,tslackUp	Dummy production to ensure balance equation feasibility, in MWh/h (≥0)
vn,f,tspill	Spill of energy from storage node, in MWh/h (≥0)
va,u,f,tstartup	Number of sub-units started up, in p.u. (≥0, continuous or integer)
vf,tstartupCost	Start-up costs, in CUR
vn,f,tstate	State variable (unit of measure depends on the application)
vq,n,f,tstateSlack	Slack variable for state slack categories, in[vn,f,tstate](≥0)
vstateValue	Value of state change, in CUR
vn,n',f,ttransfer	Energy transfer from node n to noden', in MWh/h
vunitInvestCost	Unit investment costs, in CUR(/a)
vf,tvomCost	Variable operational and maintenance costs, in CUR
λu,f,t,k	Ordered set of non-negative variables for piece-wise linear efficiency curve. At most two variables can be non-zero∀u,f,t. If two variables are non-zero, they must be adjacent in the set.
Abbreviations
CC	Combined Cycle
CT	Combustion Turbine
CUR	Currency
GAMS	General Algebraic Modeling System
MIP	Mixed-integer Programming
PV	Photovoltaic
RTPV	Roof-top Photovoltaic
RTS-GMLC	Reliability Test System-Grid Modernization Lab Consortium
ST	Steam Turbine
VRE	Variable Renewable Energy