Optimization

The market simulation core calculates short-term economic equilibria to derive market volumes and prices. It is based on multiple optimizations with specialized problem classes, assumptions, formulations, and solving techniques.

Optimization problem class

The optimization finds the cost-minimal dispatch needed to satisfy the electricity demand across multiple time intervals and bidding zones. It applies mathematical optimization problem classes such as linear programming (LP), involving continuous variables, and mixed-integer programming (MIP), which incorporates discrete variables, or a combination of both (MILP). The process resolves unit commitment problems, focusing on scheduling components efficiently.

Model assumptions

The optimization-based dispatch model simulates by default unit-by-unit and hour-by-hour generation, consumption and exchange. This approach is a representation of the European electricity market and, as are all models, it is built based on a set of assumptions. The main assumptions are listed below:

• Level playing field: In addition to operation cost like fuel cost and emission certificate cost of thermal power plants, there are no other additional costs such as levies and taxes.
• Perfect competition: The unit commitment is modeled for each hour of the year while considering available generation, demand and exchange. Market bids that partially define the dispatch are considered to be equal to the generation cost of each unit without strategic bidding or offering.
• Perfect foresight: Renewable feed-in forecast errors are not considered and market players see occurring power plant outages or market limitations with certainty.

After taking these assumptions, the problem of electricity market modelling is to determine the least cost dispatch of generating and consuming resources to meet a given price-taking electricity demand. These assumptions are necessary to model the market through solving one integrated optimization problem.

Remove model assumptions

The first two key assumptions, level playing field and perfect competition, can be relaxed using time-specific and unit-specific adjustments to bid prices, such as markups or markdowns, applied to thermal, storage, or demand units via input datasets. Perfect foresight can be addressed by incorporating stochastic uncertainties, like outages or weather variations, into Monte Carlo simulations.

Model day-ahead and intraday

To simulate day-ahead, intraday, platform-based, or over-the-counter markets, the single run procedure is repeated with updated inputs that reflect outcomes from previous market places and remaining degrees of dreedom in dispatch. Solving a single optimization problem corresponds to modeling one spot marketplace. When executed only once, the model most closely replicates the market with the largest volume of physically delivered traded products, such as the day-ahead market in Europe.

Optimization formulation

The full mixed-integer linear optimization problem is described in the following research publications.

• Ketov, M.: Marktsimulationen unter Berücksichtigung der Strom-Wärme-Sektorenkopplung, ABEV 189, 2019 (ISBN-13: 9783941704848)
• Drees, T.: Simulation des europäischen Binnenmarktes für Strom und Regelleistung bei hohem Anteil erneuerbarer Energien, ABEV 168, 2016 (ISBN-13: 9783941704558)
• Mirbach, T.: Marktsimulationsverfahren zur Untersuchung der Preisentwicklung im europäischen Strommarkt, ABEV 128, 2009 (ISBN-13: 9783934318977)

Transparency about the performed model calculations can be obtained by reporting all equations and variables. Please use therefor the optional human readable model export (lp file). This optional output can be enabled via the project configuration output_procedure_lp_files. Decision variables are labeled therein individually so every problem formulation can be retraced. For advanced model analysis please use the optional binary export to load the problem in any compatible solver (sav file) via the project configuration output_procedure_sav_files.

Constraints within the model can be classified as hard or soft constraints. Hard constraints cannot be violated at any costs. Soft constraints can be violated for penalty costs in the objective function. The violation amount is quantified by a slack variable. The user has the possibility to parametrize the slack costs individually in the project configuration. To see all slack costs, please set the filter in the project configuration to slack. In case of infeasibilities the user gets the exact error position to quickly detect and solve errors during the data check.

Residual load

The market demand and feed-in by renewable energy sources can response to the market price only through demand-side response and reducing the feed-in. The remaining residual load and dispatch flexibility need to be covered by other generators, storages, and interconnectors.

Flexible renewables

The demand-side response model can also be applied to flexible generation units, such as dump energy and reserve provision from renewable energy sources. To adapt the demand model for supply-side applications, invert the parametrization signs: an increase in consumption corresponds to a decrease in generation, while a decrease in consumption equates to an increase in generation.

Solving

A successful data check ensures that the solution space is not empty (solvability). The applied solution algorithms have the ability to find a suitable solution (convergence) with the target optimality gap (optimality). This ensures that any increase in degrees of freedom, such as expanded NTC, consistently results in equal or reduced total system operation costs, maintaining logical and reliable outcomes.

For linear problems (LP), methods like interior-point algorithms are used to derive solutions by default. For mixed-integer problems (MIP), combinatorial approaches such as branch and cut are employed. The project configuration solver_optimizer_linear_problem and solver_optimizer_mixed_integer_problem allows to specify the used method. For lengthy MIP calculations, optimality gaps can be adjusted using solver_mixed_integer_problem_gap_absolute and solver_mixed_integer_problem_gap_relative to tradeoff precision and runtime.