Introduction
NB: This chapter is a draft, and contains potentially errors and is not exhaustive of Trident’s functionality.
The Trident model is a simulator that repeatedly solves optimization problems in the form of linear programming (LP) problems. The LP problems cover a decision period, of user-defined length, typically a week or a day. We refer to this LP problem as the stage decision problem.
The simulation results are obtained as the solution of the stage decision problems. In this chapter we describe how the these mathematical optimization problems are formulated in terms of objective function, decision variables and constraints.
The Trident models takes a fundamental market modeling approach, with the objective of minimizing costs for system dispatch. It aims at reasonably replicating the inner workings of the market by modeling the physical system in detail. Results, in terms of dispatch solutions and prices are based on the marginal costs/values of flexible system resources such as power generation, demand, storages, etc.
A model of a system may comprise several price areas (or just areas). These are geographical areas typically bounded by transmission bottlenecks or watercourse boundaries. Price areas are connected by transmission lines to allow exchange of power between areas while capturing major grid bottlenecks. The transmission system may include both AC and DC connections.
Production of power within an area can come from many different sources. The Trident model particularly emphasize hydropower, where complex cascades combining reservoirs, power plants, and rivers may be represented in detail. The valuation of water available at the end of the decision period in each LP problem is currently facilitated through pre-computed water values. Other production technologies such as thermal (coal, gas, nuclear, etc.), wind, and solar can also be modeled.
The LP problem is formulated as a deterministic problem for the decision period it covers. That means that all parameters are perfectly known for the decision period. To capture variations of weather (inflow, sun, wind, temperature) and demand, the LP problem is further divided into time steps.
Each area has a power balance per time step, where the local demand is met by local production while allowing import and export through the transmission system. The power balance constraint can therefore be seen as the market clearing for each area and time step, where its dual value (or shadow price) is the simulated power price.
The objective of the stage dispatch problem is to minimize costs of system dispatch for that stage. In the following sections we briefly describe the framework of mathematical optimization and formulate a set of conventions and naming rules used in this chapter. In the following sections
Optimization
Objective Function
Mathematically, the objective function can be expressed as:
where the cost is the sum of the vector of decision variables \( (x) \) multiplied by a vector of cost elements for the variables \( (C) \):
When writing how different functionalities impact the cost function in the following, we use \( (+=) \) to indicate that we add to the cost function:
A positive cost element indicates a preference for keeping the value of the corresponding variable low, and vice versa. Positive cost elements are typically associated with variables expressing resources that has a cost, such as fuel for thermal power, and for penalizing the use of slack variables. Negative cost elements are typically used for variables expressing valuable resources, such as water at the end of the decision period or price-sensitive consumption.
Variables
The decision variables \( x \) are allowed to vary within their upper and lower boundaries. We will introduce decision variables and their boundaries in relation to the functionality they represent. For example, a variable \( x(i,k) \) related to a hydropower module may be introduced with its lower \( \textrm{LowBnd}(i,k) \) and upper \( \textrm{UpBnd}(i,k) \) boundaries:
See ‘Naming and Indices’ section below for more information on naming conventions and the use of indices.
Most variables have a lower bound of zero. The highest upper boundary is denoted \( \textrm{InfUB} \).
Constraints
The stage decision problem is a constrained optimization problem on the form
Where \( s.t. \) means that we are minimizing the objective subject to a set of constraints. The constraint set is represented by the constraint matrix \( A \), the variable vector \( x \) and the vector of right-hand side parameters \( b \).
A constraint combines two or more decision variables in a functional relation. In this documentation we will seek to write constraints as summations of variables which differs from the more compact matrix form above.
As an example, consider a constraint defined as:
The constraint type is named BALANCE. The name indicate the functionality represented by the constraint, in this case to balance some kind of storage. The constraint is indexed \( (i,k) \), where \( i \) is indicates the storage element and \( k \) the time step. \( storage(i,k) \) and \( purchase(i,k) \) are variables, while \( \textrm{Demand}(i,k) \) is a parameter.
A constraint may be of type equality ( \( = \)) or inequality ( \( \leq, \geq \) ). We will present variables on the left-hand side and parameters on the right-hand side.
Constraints are mainly introduced in relation to the functionality they represent. However, some constraints may involve many variables and parameters introduced at different places in the introduction. Examples are the power and reservoir balances. For such constraints we define the basic setup, and describe additions on the following form:
- \[ \textrm{BALANCE}(i,k) [LHS] : += \sum_{i,k} import(i,k)\]
- \[ \textrm{BALANCE}(i,k) [RHS]: += \sum_{i,k} \textrm{ExtraDemand}(i,k)\]
The first case means that variables of type \( import \) are added to the left-hand side (LHS) of the constraint. The second case indicates that parameters of type \( \textrm{ExtraDemand}(i,k) \) are added to the right-hand side (RHS) of the constraint.
Notation
Sets and Iterators
The notation used in this chapter is described below. We use sets to denote collections and iterators to iterate over elements in a set.
For the first three cases \( i \) is the iterator and \( Modules \), \( Reservoirs \) and \( Plants \) are the sets. As will be described later, the building block termed hydropower module comprises one reservoir and one plant.
Note that for some sets it is important that the iterator runs in a sequence, e.g., \( k \) needs to run sequentially from the first to the last time step in \( Timesteps \).
Summations are formulated assuming that the correct set is used. For example, a summation of hydropower production in an area can be formulated as follows, where we assume \( i \) to run over the set of modules within area \( a \).
Naming and indices
When mathematically formulating the model we use the following convention:
\( \textrm{CONSTRAINTS} \) are written with capital letters,
\( \textrm{variables} \) are written with lowercase letters.
\( \textrm{Parameters} \) are written with camel case.
\( \textit{collective} \) terms are written with italic camel case.
Indices are shown in parentheses, e.g. \( \textrm{variables(i)} \)