The Dispa-SET model¶

Using Dispa-SET with GAMS:¶

Dispa-SET is primarily designed to run with GAMS and therefore requires GAMS to be installed with a valid user licence. Currently, only the 64-bit version of GAMS is supported in Dispa-SET!

The GAMS api for python has been pre-compiled in the “Externals” folder and is usable with most operating systems. If the pre-compiled binaries are not available or could not be loaded, the system exits with an error message. In that case, the gams python api should be compiled from the source provided in the GAMS installation folder (e.g. “C:\GAMS\win64\24.3\apifiles\Python\api”):

python gdxsetup.py install
python gamssetup.py install

The api requires the path to the gams installation folder. The “get_gams_path()” function of dispa-set performs a system search to automatically detect this path. It case it is not successful, the user is prompted for the proper installation path.

Using Dispa-SET with PYOMO:¶

• Install pyomo

  pip install pyomo
  

• Install a solver and add it to the PATH environment variable (e.g. if cplex is installed, the “cplex” command should be callable from any command prompt).

1. Using the command line interface¶

Dispa-SET can be run from the command line. To that aim, open a terminal window and change de directory to the Dispa-SET root folder.

python dispacli.py -c ./ConfigFiles/ConfigTest.xlsx build

python dispacli.py -g -c ./ConfigFiles/ConfigTest.xlsx simulate

python dispacli.py -g -c ./ConfigFiles/ConfigTest.xlsx build simulate

python dispacli.py -p -c ./ConfigFiles/ConfigTest.xlsx build simulate

2. Using the Dispa-SET API.¶

The steps to run a model can be also performed directly in python, by importing the Dispa-SET library. An example file (“build_and_run.py”) is available in the “scripts/” folder. After checking the configuration file “ConfigTest.xlsx” (in the “ConfigFiles” folder). Run the following python commands:

2.1 Import Dispa-SET:

import DispaSET as ds

2.2 Load the configuration file:

config = ds.load_config_excel('ConfigFiles/ConfigTest.xlsx')

2.3 Build the simulation environment (Folder that contains the input data and the simulation files required for the solver):

SimData = ds.build_simulation(config)

2.4a Solve using PYOMO:

r = ds.solve_pyomo(config['SimulationDirectory'])

2.4b Solve using GAMS:

r = ds.solve_GAMS(config['SimulationDirectory'], config['GAMS_folder'])

A more detailed description of the Dispa-SET functions in available in the API section.

3. Using GAMS¶

It is sometimes useful to run the dispa-SET directly in GAMS (e.g. for debugging purposes). In that case, the pre-processing must be run first (steps 1.2 or 2.1, 2.2 and 2.3) and the gams file generated in the simulation folder can be used to run the optimization.

Sets¶

Parameters¶

Optimization Variables¶

Objective function¶

The goal of the unit commitment problem is to minimize the total power system costs (expressed in EUR in equation ), which are defined as the sum of different cost items, namely: start-up and shut-down, fixed, variable, ramping, transmission-related and load shedding (voluntary and involuntary) costs.

The costs can be broken down as:

• Fixed costs: depending on whether the unit is on or off.
• Variable costs: stemming from the power output of the units.
• Start-up costs: due to the start-up of a unit.
• Shut-down costs: due to the shut-down of a unit.
• Ramp-up: emerging from the ramping up of a unit.
• Ramp-down: emerging from the ramping down of a unit.
• Load shed: due to necessary load shedding.
• Transmission: depending of the flow transmitted through the lines.
• Loss of load: power exceeding the demand or not matching it, ramping and reserve.

The variable production costs (in EUR/MWh), are determined by fuel and emission prices corrected by the efficiency (which is considered to be constant for all levels of output in this version of the model) and the emission rate of the unit (equation ):

The variable cost includes an additional mark-up parameter that can be used for calibration and validation purposes.

The start-up and shut-down costs are positive variables, active when the commitment status between two consecutive time periods is modified:

In the previous equation, as in some of the following, a distinction is made between the equation for the first and subsequent periods. The equation for the first period takes into account the commitment status of the unit before the beginning of the simulation, which is part of the information fed into the model.

Ramping costs are computed in the same manner:

It should be noted that in case of start-up and shut-down, the ramping costs are added to the objective function. Using start-up, shut-down and ramping costs at the same time should therefore be performed with care.

In the current formulation all other costs (fixed and variable costs, transmission costs, load shedding costs) are considered as exogenous parameters.

As regards load shedding, the model considers the possibility of voluntary load shedding resulting from contractual arrangements between generators and consumers. Additionally, in order to facilitate tracking and debugging of errors, the model also considers some variables representing the capacity the system is not able to provide when the minimum/maximum power, reserve, or ramping constraints are reached. These lost loads are a very expensive last resort of the system used when there is no other choice available. The different lost loads are assigned very high values (with respect to any other costs). This allows running the simulation without infeasibilities, thus helping to detect the origin of the loss of load. In a normal run of the model, without errors, all these variables are expected to be equal to zero.

Demand-related constraints¶

The main constraint to be met is the supply-demand balance, for each period and each zone, in the day-ahead market (equation ). According to this restriction, the sum of all the power produced by all the units present in the node (including the power generated by the storage units), the power injected from neighbouring nodes, and the curtailed power from intermittent sources is equal to the load in that node, plus the power consumed for energy storage, minus the load interrupted and the load shed.

Besides that balance, the reserve requirements (upwards and downwards) in each node must be met as well. In Dispa-SET, the reserve requirements are defined as an aggregation of secondary and tertiary reserves, which are typically brought online in periods shorter than an hour, the time step of this model. Therefore, additional equations and constraints are defined to account for the up/down ramping requirements, by computing the ability of each unit to adapt its power output within a period of 15 min.

For each power plant, the ability to increase its power (in MW/h) is the ramp-up capability if it is already committed or the nominal power if it is stopped and its starting time is lower than 15 minutes. This is to take into account that fast starting units could provide reserve (hydro units for secondary reserve, gas turbine for tertiary reserve).

where FlexibilityUp is the maximum flexibility (in MW/h) that can be provided by the unit in 15 min in case of cold start:

where the factor 4 is used to convert the ramping rate from MW/15min to MW/h.

The maximum ramping rate is also limited by the available capacity margin between current and maximum power output:

The same applies to the 15 min ramping down capabilities:

The parameter FlexibilityDown is defined as the maximum ramp down rate at which the unit can shut down in 15 minutes. In case the unit cannot be shut-down in 15 minutes (and only in this case) the maximum ramping down capability is limited by the capacity margin between actual and minimum power:

The reserve requirements are defined by the users. In case no input is provided a default formula is used to evaluate the needs for secondary reserves as a function of the maximum expected load for each day. The default formula is described by:

Downward reserves are defined as 50% of the upward margin:

The reserve demand should be fulfilled at all times by all the plants allowed to participate in the reserve market:

The same equation applies to downward reserve requirements (2D).

Power output bounds¶

The minimum power output is determined by the must-run or stable generation level of the unit if it is committed:

On the other hand, the output is limited by the available capacity, if the unit is committed:

The availability factor is used for renewable technologies to set the maximum time-dependent generation level. It is set to one for the traditional power plants. The outage factor accounts for the share of unavailable power due to planned or unplanned outages.

The power output in a given period also depends on the output levels in the previous and the following periods and on the ramping capabilities of the unit. If the unit was down, the ramping capability is given by the maximum start up ramp, while if the unit was online the limit is defined by the maximum ramp up rate. Those bounds are given with respect to the previous time step by the equation :

Where the LoadMaximum parameter is calculated taking into account the availability factor and the outage factor:

Similarly, the ramp down capability is limited by the maximum ramp down or the maximum shut down ramp rate:

Minimum up and down times¶

The operation of the generation units is also limited as well by the amount of time the unit has been running or stopped. In order to avoid excessive ageing of the generators, or because of their physical characteristics, once a unit is started up, it cannot be shut down immediately. Reciprocally, if the unit is shut down it may not be started immediately.

That is, the value of the time counter with respect to the minimum up time and down times determines the commitment status of the unit. In order to model theses constraints linearly, it is necessary to keep track of the number of hours the unit must be online at the beginning of the simulation:

where N is the number of time steps in the current optimisation horizon.

If the unit is initially started up, it has to remain committed until reaching the minimum up time:

If the unit is started during the considered horizon, the time it has to remain online is TimeUpMinimum, but cannot exceed the time remaining in the simulated period. This is expressed in equation and is pre-calculated for each time step of the period.

The equation imposing the unit to remain committed is written:

The same method can be applied to the minimum down time constraint:

Related to the initial status of the unit:

The TimeDownLeftJustStopped parameter is computed by:

Finally, the equation imposing the time the unit has to remain de-committed is defined as:

This formulation avoids the use of additional binary variables to describe the start-up and shut-down of each unit.

Storage-related constraints¶

Generation units with energy storage capabilities (mostly large hydro reservoirs and pumped hydro storage units) must meet additional restrictions related to the amount of energy stored. Storage units are considered to be subject to the same constraints as non-storage power plants. In addition to those constraints, storage-specific restrictions are added for the set of storage units (i.e. a subset of all units). These restrictions include the storage capacity, inflow, outflow, charging, charging capacity, charge/discharge efficiencies, etc. Discharging is considered as the standard operation mode and is therefore linked to the Power variable, common to all units.

The first constrain imposes that the energy stored by a given unit is bounded by a minimum value:

In the case of a storage unit, the availability factor applies to the charging/discharging power, but also to the storage capacity. The storage level is thus limited by:

The energy added to the storage unit is limited by the charging capacity. Charging is allowed only if the unit is not producing (discharging) at the same time (i.e. if Committed, corresponding to the {textquotedbl}normal{textquotedbl} mode, is equal to 0).

Discharge is limited by the level of charge of the storage unit:

Charge is limited by the level of charge of the storage unit:

Besides, the energy stored in a given period is given by the energy stored in the previous period, net of charges and discharges:

Some storage units are equiped with large reservoirs, whose capacity at full load might be longer than the optimisation horizon. Therefore, a minimum level constraint is required for the last hour of the optimisation, which otherwise wouls systematically tend to empty the reservoir as much a possible. An exogenous minimum profile is thus provided and the following constraint is applied:

where StorageProfile is a non-dimensional minimum storage level provided as an exogenous input. The minimum is taken to avoid unfeasibilities in case the provided inflows are not sufficient to comply with the imposed storage level at the end of the horizon.

Heat production constraints (CHP plants only)¶

In DispaSET Power plants can be indicated as CHP satisfying one heat demand. Heat Demand can be covered either by a CHP plant or by alternative heat supply options (Heat Slack).

The following two heat balance constraints are used for any CHP plant type.

The constraints between heat and power production differ for each plant design and explained within the following subsections.

Steam plants with Backpressure turbine¶

This options includes steam-turbine based power plants with a backpressure turbine. The feasible operating region is between AB. The slope of the line is the heat to power ratio.

\[Power_{chp,i} = StorageInput_{chp,i} \cdot CHPPowerToHeat_{chp}\]

Steam plants with Extraction/condensing turbine¶

This options includes steam-turbine based power plants with an extraction/condensing turbine. The feasible operating region is within ABCDE. The vertical dotted line BC corresponds to the minimum condensation line (as defined by CHPMaxHeat). The slope of the DC line is the heat to power ratio and the slope of the AB line is the inverse of the power penalty ratio.

\[Power_{chp,i} \geq StorageInput_{chp,i} \cdot CHPPowerToHeat_{chp}\]

\[Power_{chp,i} \leq PowerCapacity_{chp} -\]\[StorageInput_{chp,i} \cdot CHPPowerLossFactor_{chp}\]

Power plant coupled with any power to heat option¶

This option includes power plants coupled with resistance heater or heat pumps. The feasible operating line is between AB. The slope of the line is the inverse of the COP or efficiency. The vertical dotted line corresponds to the heat pump (or resistance heater) thermal capacity (as defined by CHPMaxHeat)

\[Power_{chp,i} = PowerCapacity_{chp} - StorageInput_{chp,i} \cdot CHPPowerLossFactor_{chp}\]

Emission limits¶

The operating schedule also needs to take into account any cap on the emissions (not only CO2) from the generation units existing in each node:

It is important to note that the emission cap is applied to each optimisation horizon: if a rolling horizon of one day is adopted for the simulation, the cap will be applied to all days instead of the whole year.

Network-related constraints¶

The flow of power between nodes is limited by the capacities of the transmission lines:

In this model a simple Net Transfer Capacity (NTC) between countries approach is followed. No DC power flow or Locational Marginal Pricing (LMP) model is implemented.

Curtailment¶

If curtailment of intermittent generation sources is allowed in one node, the amount of curtailed power is bounded by the output of the renewable (tr) units present in that node:

Load shedding¶

If load shedding is allowed in a node, the amount of shed load is limited by the shedding capacity contracted on that particular node (e.g. through interruptible industrial contracts)

MILP clustering¶

In this formulation, the units that are either very small or very flexible are aggregated into larger units. Some of these units (e.g. the turbojets) indeed present a low capacity or a high flexibility: their output power does not exceed a few MW and/or they can reach full power in less than 15 minutes (i.e. less than the simulation time step). For these units, a unit commitment model with a time step of 1 hour is unnecessary and computationally inefficient. They are therefore merged into one single, highly flexible unit with averaged characteristics.

The condition for the clustering of two units is a combination of subconditions regarding their type, maximum power, flexiblity and technical similarities. They are summarized in the figure below (NB: the thresholds are for indicative purpose only, they can be user-defined).

When two units are clustered, the minimum and maximum capacities of new aggregated units (indicated by the star) are given by:

The last equation is also applied for the storage capacity or for the storage charging power.

The unit marginal (or variable cost) is given by:

The start-up/shut-down costs are transformed into ramping costs (example with ramp-up):

Other characteristics, such as the plant efficiency, the minimum up/down times or the CO2 emissions are computed as a weighted averaged:

It should be noted that only very similar units are aggregated (i.e. their quantitative characteristics should be similar), which avoids errors due to excessive aggregation.

LP clustering¶

Dispa-SET provides the possibility to generate the optimisation model as an LP problem (i.e. withtout the binary variables). In that case, the following constraints are removed since they can only be expressed in an MILP formulation:

• Minimum up and down times
• Start-up costs
• Minimum stable load

Since the start-up of individual units is not considered anymore, it is not useful to disaggrate them in the optimisation. All units of a similar technology, fuel and zone can be aggregated into a single unit using the equations proposed in the previous section.

UCM_h.gms and UCM.gpr¶

UCM_h.gms is the main GAMS model described in Chapter 1. A copy of this file is included in each simulation environment, allowing keeping track of the exact version of the model used for the simulation. The model must be run in GAMS and requires a proper input file (Inputs.gdx).

UCM.gpr is the GAMS project file which should be opened before UCM_h.gms.

make_gdx.gms¶

GAMS file that reads the different template excel files and generates the Inputs.gdx file. This file should be opened in GAMS.

makeGDX.bat¶

Batch script that generates the input file from the template without requiring opening GAMS. The first time it is executed, the path of the GAMS folder must be provided.

writeresults.gms¶

GAMS file to generate the excel Results.xlsx file from the Results.gdx generated by GAMS (in case the write_excel function was deactivated in GAMS.

Inputs.gdx¶

All the inputs of the model must be stored in the Inputs.gdx file since it is the only file read by the main GAMS model. This file is generated from the DispaSET template.

InputDispa-SET - [ParameterName].xlsx¶

Series of 42 excel files, each corresponding to a parameter of the DispaSET model (see Chapter 1). The files must be formatted according to section 2.2.

InputDispa-SET - Sets.xlsx¶

Single excel file that contains all the sets used in the model in a column format.

InputDispa-SET - Config.xlsx¶

Single excel file that contains simulation metadata in the form of a Table. This metadata allows setting the rolling horizon parameter and slicing the input data to simulate a subset only.

Structure of the Excel template¶

The name of the input files are “Input Dispa-SET – [Parameter name].xlsx”. These files contain the data to be read by the model, after conversion into a GDX file.

The structure of all input files follows the following rules:

1. There is one file per model parameter

2. Each file contains only one sheet

3. The first row is left blank for non-time series data (i.e. data starts at A2)

4. For time series data, the rows are organized as follows:

   1. The first row is left blank
   2. Rows 2 to 5 contains the year, month, day and hour of each data
   3. Row 6 contains the time index of the data, which will be used in DispaSET
   4. The data therefore starts at A6

5. If one of the input sets of the data is u (the unit name), it is always defined as the first column of the data (column A)

6. If one of the input sets of the data is h (the time index), it is always defined as the only horizontal input in row 6

In the case of the file “Input Dispa-SET – Sets.xlsx”, all the required sets are written in columns with the set name in row 2.

Common fields¶

The following fields must be defined for all units:

NB: the fields indicated with % as unit must be entered in a non-dimensional way (i.e. 90% should be written 0.9).

Storage units¶

Some parameters must only be defined for the units equipped with storage. They can be left blank for all other units.

In the case of a storage unit, the discharge efficiency should be assigned to the common field “Efficiency”. Similarly, the common field “PowerCapacity” is the nominal power in discharge mode.

CHP units¶

Some parameters must only be defined for the units equipped with CHP. They can be left blank for all other units.

In the current version of DispaSet three type of combined heat and power units are supported:

• Extraction/condensing units
• Backpressure units
• Power to heat

For each of the above configurations the following fields must be filled:

There are numerous data checking routines to ensure that all data provided is consistent.

Inflows¶

The Inflows are defined as the contribution of exogenous sources to the level (or state of charge) or the reservoir. They are expressed in MWh of potential energy. If the inflows are provided as m³/h, they must be converted.

The input to dispaset is defined as “ScaledInflows”. It is the normalized values of the inflow with respect to the nominal power of the storage unit (in discharge mode). As an example, if the inflow value at a certain time is 100MWh/h and if the turbining capacity of the hydro plant is 200 MW, the scaled inflow value must be defined as 0.5.

Scaled inflows should be provided in the form of time series with the unit name or the technology as columns header.

Storage level¶

Because emptying the storage has a zero marginal cost, a non-constrained optimization tends to leave the storage completely empty at the end of the optimisation horizon. For that reason, a minimum storage level is imposed at the last hour of each horizon. In Dispa-SET, a typical optimisation horizon is a few days. The model is therefore not capable of optimising the storage level e.g. for seasonal variations. The minimum storage level at the last hour is therefore an exogenous input. It can be selected from a historical level or obtained from a long-term hydro scheduling optimization.

The level input in the Dispa-SET database is normalized with respect to the storage capacity: its minimum value is zero and its maximum is one.

Variable capacity storage¶

In special cases, it might be necessary to simulate a storage unit whose capacity varies in time. A typical example is the simulation of the storage capacity provided by electric vehicles: depending on the time of the day, the connected battery capacity varies.

This special case can be simulated using the “AvailabilityFactor” input. In the case of a storage unit, reduces the avaiable capacity by a factor varying from 0 to 1.

Net transfer capacities¶

Dispa-SET indogenously models the internal exchanges between countries (or zones) using a commercial net transfer caapcity (NTC). It does not consider (yet) DC power flows or more complex grid simulations.

Since the NTC values might vary in time, they must be supplied as time series, whose header include the origin country, the string ‘ -> ‘ and the destination country. As an example, the NTC from belgium to france must be provided with the header ‘BE -> FR’.

Because NTCs are not necessarily symetrical, they must be provided in both directions (i.e. ‘BE -> FR’ and ‘FR -> BE’. Non-provided NTCs are considered to be zero (i.e. no interconnection).

Historical physical flows¶

In Dispa-SET, the flows between internal zones and the rest of the world cannot be modeled endogenously. They must be provided as exogenous inputs. These inputs are referred to as “Historical physical flows”, although they can also be user-defined.

In the input table of historical flows, the headers are similar to those of the NTCs (ie. ‘XX -> YY’). All flows occuring an internal zone of the simulation and outside zones are considered as external flows and summed up. As an example, the historical flows ‘FR -> XX’, ‘FR -> YY’ and ‘FR -> ZZ’ will be aggregated in to a single interconnection flow ‘FR -> RoW’ if XX, YY and ZZ are not simulated zones.

These aggregated historical flows are then imposed to the solver as exogenous inputs.

In Dispa-SET, the flows are defined as positive variables. For each zone, there will thus be a maximum of two vectors defining its exchanges with the rest of the world (e.g. ‘FR -> RoW’ and ‘RoW -> FR’).

As for the NTCs, undefined historical flows are considered to be zero, i.e. not provided any historical flows is equivalent to consider the system as islanded.

Version 2.2¶

• Inclusion of CHP, power2heat and thermal storage (these new features can be tested by running the config file for Cyprus: ‘ConfigFiles/ConfigCY.xlsx’)
• Bug fixes
• Improved user interface

Version 2.1¶

• Major refactoring of the folder structure
• New data included in the database
• Inclusion of the LP formulation (in addition to the MILP)

Version 2.0¶

First public version of the Dispa-SET model.