Formulation of the power flow problem in human readable form for translation into an efficient solver

(1)

IN

DEGREE PROJECT ELECTRICAL ENGINEERING, SECOND CYCLE, 30 CREDITS

STOCKHOLM SWEDEN 2016,

Formulation of the power flow problem in human readable form for translation into an efficient solver

MUHAMMAD TALAL KHAN

(2)

TRITA TRITA-EE 2016:190

(3)

Formulation of the power flow problem in human readable form for translation into an efficient solver

by

Muhammad Talal Khan

A thesis submitted to the School of Electrical Engineering

in partial fulfilment of the requirements for the degree of

Master of Science in Systems Controls and Robotics

Department of Electric Power and Energy Systems KTH

November 2016

(4)

Abstract Power systems are complex systems that need supervision and control to operate reliably and safely. Energy Management Systems (EMS)/SCADA provides the necessary aids for monitoring and control of power systems. Since power flow forms the basis of power system analysis, power flow solvers (PFS) are an integral part of EMS/SCADA systems. With the evolving power systems new challenges appear which force new functionalities and requirements on EMS/SCADA, these in turn are translated into requirements on the PFS. Current EMS/SCADA utilize PFS that were developed in the 1970’s and 1980’s. Maintaining and upgrading these PFS to meet current requirements is ever more difficult. The development of an advanced, efficient and easier to maintain PFS is therefore necessary. This thesis focuses on the development of a power flow solver that is easier to maintain, efficient and scalable. To achieve this a programming language that can meet the performance requirements of a PFS and formulate the power flow problem at a higher abstraction level is required. Several programming languages are reviewed while they fulfill some aspects they are deficient on other requirements. Therefore the open EMS programming language (OPL) is developed, which can describe the power flow problem at a higher programming level. OPL is used to model a small power system network, which is solved to obtain the power flow solution. The existing model is extended to include ratio tap changers and switched shunts, to proof the concept that additional equipment is added with relative ease.

(5)

Sammanfattning Elkraftsystem är komplexa system som kräver övervakning och styrning för att fungera p˚alitlighet och säkert. Energy Management Systems (EMS)/SCADA används för

¨

overvakning och styrning av systemet. Eftersom effektflöden utgör basen för analys av elkraftsystem finns beräkningsverktyg (power flow solvers, PFS) integrerat i EMS/SCADA. I och med att elkraftsystemet utvecklas uppst˚ar nya utmaningar, som kräver nya funktionaliteter och krav p˚a EMS/SCADA. Detta resulterar i krav p˚a även PFS. PFS som används i EMS/SCADA idag utveck- lades p˚a 1970- och 80-talet. Att underh˚alla och utveckla dessa för att uppfylla de nya kraven blir allt sv˚arare. Detta examensarbete syftar till att utveckla en PFS som är lättare att underh˚alla och som är effektiv och anpassningsbar. För att uppn˚a detta behövs ett programmeringsspr˚ak som uppfyller prestandan som krävs för PFS, och flödesproblemet behöver formuleras om p˚a en högre niv˚a. I detta examensarbete har flera programmeringsspr˚ak granskats, och samtliga uppfyller vissa av kraven men brister i andra. Därför har ett öppet programmeringsspr˚ak (OPL). Detta beskriver effektflödesproblemet p˚a en högre abstraktionsniv˚a. OPL har utvarderats genom användning för modellering av ett litet elkraftsystem, för att lösa effektflödesproblemet. Modellen inkluderar även lindningskopplare och shuntar, vilket visar att konceptet relativt lätt till˚ater utökning med fler apparater i systemet.

(6)

Acknowledgements

I would first like to thank my thesis supervisor M. Hassan Fidai. He has been very supportive and patient during this entire period. He has always been available when ever I had doubts. He has directed in the best possible way to complete this thesis and that it has a meaningful contribution to the research at the department. Without his supervision and help this thesis would have not been possible to complete.

Secondly, I thank my ABB supervisor Lars-Ola Osterlund. His continuous input through out the thesis has helped me achieve the goal of my work. I have learned a lot from his experience and knowledge, which has helped me to manage my work efficiently and methodically.

I am also thankful to Prof. Lars Nordstrom for the opportunity to work at his department. He has not only contributed as the examiner for this thesis but thorough his input he has directed this thesis to a greater potential and helped me in achieving different goals that make this work valuable.

Lastly I would thank ABB Enterprise software for the thesis opportunity and funding. I offer my warmest gratitude to the department manager Asa Groth for allowing me to work at her department and experience the multinational environment of ABB.

Muhammad Talal Khan Stockholm, Sweden November, 2016.

(7)

Abbreviations

EMS Energy Management System

SCADA Supervisory Control and Data Acquisition PFS Power Flow Solver

PFE Power Flow Equations OEMS OpenEMS

PFP Power Flow Problem

OPL Open EMS Programming Language AC Alternating Current

NR Newton-Raphson DC Direct Current

OPFS OpenEMS Power Flow Solver

(8)

List of Tables

3.1 Bus data matrix format . . . 15

3.2 Line data matrix format . . . 16

3.3 Tap data matrix format . . . 16

3.4 Shunt data matrix format . . . 16

(11)

List of Figures

2.1 Transformer with a tap changer [1]. . . 9

2.2 Ratio tap changer pi-model [1]. . . 10

3.1 Modelica compiler work flow [2]. . . 19

3.2 Work flow for the OPFS. . . 22

3.3 Active power equation as written in OPL. . . 22

3.4 OPL format and mandatory sections. . . 23

3.5 Variable declaration in OPL. . . 23

3.6 Equation declaration in OPL. . . 24

3.7 A two bus system [1]. . . 24

3.8 Flex and bison working diagram [3]. . . 25

3.9 Bison code structure [3] . . . 26

3.10 Code example for parsing . . . 27

3.11 Code generator workflow . . . 28

3.12 Active power equation as written in OPL. . . 29

3.13 Cos function separated from the equation. . . 29

3.14 Sum function separated from the equation. . . 29

(12)

Chapter 1

Introduction

Power systems are complex, extensive and physically dispersed networks. They need supervision and control to operate within set standards of security and reliability. The computer aids needed by the network operator to supervise and control the power systems are provided by Energy Management Systems (EMS) and Supervisory Control and Data Acquisition (SCADA). They are capable of monitoring, controlling and optimizing the operation of power systems. EMS/SCADA comprise of several applications, such as real time SCADA applications, generation and dispatch control, transmission security, energy scheduling, etc. Since power flow forms the basis for power system analysis [1], power flow solvers (PFS) are an integral component of EMS/SCADA. PFS provide vital information about the power systems in many different scenarios, some of these are mentioned as follows:

• PFS are used to identify the cause of a disturbance by studying the system state before and after a disturbance [4].

• When extending power systems, PFS are used to plan and study the extensions in order to study their effect and meet the required goals [5].

• PFS are used in operational planning to verify that the system security stays within limits [6].

• When supervising and operating power systems, PFS are used to validate operational actions [7].

• A PFS is also the basic component in optimizing the power system with regards to power production and voltage profile [4].

The power systems are evolving, the deregulated market, the inclusion of renewable energy, micro-grids and the ever expanding network poses new challenges and difficulties [4]. These challenges lead to increased requirements of safety and reliability on the power systems. These in turn pose greater requirements on the EMS/SCADA which translates to requirements on the PFS. Cur- rent EMS/SCADA use PFS that have been developed in the 1970’s and 1980’s, where the power flow equations (PFE) are hand coded in FORTRAN. The ability to maintain and update these solvers is diminishing. Finding expertise in these programming languages and implementation of

(13)

new concepts and equations in the existing code, is ever more difficult. Also with the advancements in computer technology the possibilities to develop a new, efficient and better PFS are numerous.

New memory management schemes can be applied to get better performance and programming at higher abstraction levels is possible which makes maintenance of code easier.

This thesis is part of the OpenEMS (OEMS) project. OEMS aims at the development of an open source EMS/SCADA system. This will be achieved with the help of off-the-shelf products to deliver an economical and efficient solution. As mentioned above PFS are integral to EMS/SCADA, in this thesis a PFS is developed for the OEMS. The focus is to develop a PFS that is easier to maintain, update and extend while meeting requirements on performance and efficiency. To achieve this, focus is laid on the formulation of the power flow problem (PFP) in a human intuitive form.

Several programming languages are researched with regards to the PFS requirements. While they fulfill some aspects they are deficient on other requirements. Therefore the open EMS programming language (OPL) is developed, which can describe the PFP in a human readable form. The main contribution of this thesis is the development of the OPL and its use in the development of a prototype PFS for the OEMS.

(14)

Chapter 2

Background

2.1 Power Flow

Power flow is the steady state analysis of a power system [8]. It analyses the flow of electric power in an interconnected system. Interconnected systems are represented by nodes and branches. In power systems, the terminologies bus and line are used to refer to nodes and branches respectively.

The alternating current (AC) power has four associated parameters, these are voltage magnitude, phase angle, active power and reactive power. Power flow aims at determining the voltage and phase angle at each bus and the active and reactive power flow in each line. This knowledge is gained by obtaining the solution to the network equations. The network equations can be formulated into several systematic forms but the node-voltage method is the most suitable and commonly used [1].

This formulation leads to complex algebraic equations in terms of line currents. Since in power systems, powers are known instead of line currents, the equations specified in terms of powers are nonlinear and known as the PFE, these are briefly discussed in the next section. These nonlinear equations are then solved using numerical analysis techniques.

2.1.1 Power Flow Problem

As mentioned above the power flow solution aims at determining the voltage magnitude and phase angle at each bus, and the active and reactive power flow in each line. Based on the knowledge of these quantities, system buses are classified as:

• Slack Bus: These buses have specified voltage magnitude and phase angle while the active and reactive power are unknown. They are termed as slack buses. The slack bus acts as the reference bus and makes up for the difference in the active and reactive power in the system due to losses.

• Load Buses: These buses have specified active and reactive power while the voltage magnitude and phase angle are unknown. These are termed as P-Q buses. Generally these are the buses where system loads are situated.

(15)

• Voltage Regulated Buses: These buses have a specified active power and bus voltage magnitude but the reactive power and the phase angle at the bus are unknown. They are termed P-V buses. Generally these are the buses where generators are situated.

2.1.1.1 Power Flow Equations

The PFE as mentioned before are constructed based on the node-voltage method, which leads to a set of non-linear equations. A brief derivation of these are given here, a detailed derivation can be found in [1].

The complex power flow between two buses is given by equation 2.1.

S_i= V_iI_i^∗= V_i(

n

X

j=1

Y_ijV_j)^∗= V_i

n

X

j=1

Y_ij^∗V_j^∗ (2.1)

Where n denotes the total number of buses, i and j denotes the bus subscripts,S_iis the complex power flowing from bus i, V_iis the complex voltage at bus i, I_ithe complex current flowing from bus i. Y_ijis the line admittance between bus i and j and V_jis the voltage at bus j. The line admittance and complex voltage are defined by equation 2.2.

Y_ij, |Yij|∠θij

V_i, |Vi|∠δi

δ_ij, δi− δj

(2.2)

Where δ is the phase angle at that bus and θ the admittance angle. Using the definitions in equation 2.2, the complex power flow can be represented as in equation 2.3.

S_i= P_i+ jQ_i= V_i

n

X

j=1

Y_ij^∗V_j^∗=

n

X

j=1

|V_i||V_j|e^jδ^ij|Y_ij|e^jθ^ij (2.3)

Separating equation 2.3 into real and imaginary parts, the active power and reactive power equations are obtained as in equation 2.4 and 2.5 respectively.

P_i= P_Gi− PDi=

n

X

j=1

|Vi||Vj||Yij|cos(θij− δi+ δ_j) (2.4)

Q_i= Q_Gi− Q_Di= −

n

X

j=1

|V_i||V_j||Y_ij|sin(θ_ij− δ_i+ δ_j) (2.5) The total complex power balance should exist at every bus. This means that the sum of power flowing from the bus, the generated power and the consumed power at the bus should equal to zero.

This gives us the PFE, which are solved to obtain the solution to the power flow problem. They are given by equation 2.6. The PFE are solved using numerical methods, one of these methods is explained in the next section.

(16)

For active power :

n

X

j=1

|Vi||Vj||Yij|cos(θij− δi+ δ_j) − P_Gi+ P_Di= 0

For reactive power :

−

n

X

j=1

|V_i||V_j||Y_ij|sin(θ_ij− δ_i+ δ_j) − Q_Gi+ Q_Di = 0

(2.6)

2.1.2 Power Flow Solution Methods 2.1.2.1 Introduction

The numerical methods applied to solve PFE are part of the numerical analysis techniques. Numeri- cal analysis involves iterative methods to find the solution to a set of equations. They use numerical approximations which are repeated until the roots of the equations are approximated to a specified accuracy. The most common techniques for iterative solutions to nonlinear algebraic equations are Gauss-Seidel, Newton-Raphson (NR), and Quasi-Newton methods [1]. In the next section the NR method and its application to the PFE is discussed. NR is a mathematically superior method and is less prone to divergence, but is computationally taxing due to the number of evaluations in each iteration [1]. The PFE, though being complex and nonlinear, can be simplified using general assumptions. The simplified PFE can then be solved using lesser computationally exhaustive methods.

Two of these methods, fast decoupled and direct current (DC) load flow, are discussed in sections 2.1.2.3 and 2.1.2.4.

2.1.2.2 Newton-Raphson

The NR method is an iterative method that aims at finding the roots of real valued functions. The method starts with an initial approximation, after which the function is approximated by its tangent line. The x-intercept of this tangent line is used as the guess for the next iteration. This process is repeated until a specified accuracy is achieved. The general steps for the algorithm are shown in equation 2.7.

W hile

||f (x^(k))|| > Do

x^(k+1)= x^(k)− [J (x^(k))]⁻¹f (x^(k)) k = k + 1

End

(2.7)

Where x represents the variables which are unknown while f (x) represents the function for which the set of variables x are the roots and k is the number of iteration.

In the case of power flow x and f (x) are formed as shown in equation 2.8. The matrix J , known as the jacobian matrix, represents the differentiation of the function f (x) with respect to the set of variables x. The jacobian matrix representation is as shown in equation 2.9.

(17)

x =





 θ₂

... θ₂







andf (x) =







P₂(x) − P_G2+ P_D2 ...

P_n(x) − P_Gn+ P_Dn ...

Q₂(x) − Q_G2+ Q_D2 ...

Q_n(x) − Q_Gn+ Q_Dn







(2.8)

J (x) = ∂f (x)

∂x =







∂f1(x)

∂x1

∂f1(x)

∂x2 · · · _∂x^∂f¹^(x)

2n−2

∂f2(x)

∂x1

∂f2(x)

∂x2 · · · _∂x^∂f²^(x)

2n−2

... . .. . .. ...

∂f2n−2(x)

∂x1

∂f2n−2(x)

∂x2 · · · ^∂f_∂x²ⁿ⁻²^(x)

2n−2







(2.9)

The vector x which contains the unknown voltage magnitudes and phase angles is initialized and at every iteration of the algorithm, power residuals are calculated using equation 2.10. After this step the jacobian matrix is calculated and with the power residuals the linear simultaneous equation 2.11 is solved for δ and V . The iterations are repeated until a specified accuracy is reached as in equation 2.12.

∆P_i^k= P_i^sch− P_i^k

∆Q^k_i = Q^sch_i − Q^k_i (2.10)

"

∆P

∆Q

#

=h J

i

"

∆δ

∆V

#

(2.11)

|∆P_i^k| <

|∆Q^k_i| < (2.12)

2.1.2.2.1 Jacobian

In the NR method the jacobian matrix represents the dependency of the solving function to its variables. Since in power flow, the solving function represents the active and reactive power, and the variables are voltage magnitude and phase angle, the jacobian matrix represents the dependencies of the active and reactive power to the voltage magnitude and phase angle. Therefore, the jacobian matrix specifically has four sub matrices. The four sub matrices are depicted here by J1, J2, J3 and J4. These can be outlined into:

• Active power to phase angle dependence represented by J1. They are calculated using equation 2.13.

• Active power to voltage magnitude dependence represented by J2. They are calculated using equation 2.14.

(18)

• Reactive power to phase angle dependence represented by J3. They are calculated using equation 2.15.

• Reactive power to voltage magnitude dependence represented by J4. They are calculated using equation 2.16.

J1 diagonal = ∂P_i

∂δ_i =X

j6=i

|V_i||V_j||Y_ij|sin(θ_ij− δ_i+ δ_j)

J1 off-diagonal = −∂P_i

∂δ_j = |V_i||V_j||Y_ij|sin(θ_ij− δ_i+ δ_j)wherej 6= i (2.13) J2 diagonal = ∂P_i

∂|V_i|= 2|V_i||Y_ii|cos(θ_ii) +X

j6=i

|V_j||Y_ij|cos(θ_ij− δ_i+ δ_j)

J2 off-diagonal = ∂P_i

∂|V_j|= |V_i||Y_ij|cos(θ_ij− δ_i+ δ_j)wherej 6= i (2.14) J3 diagonal = ∂Q_i

∂δ_i =X

j6=i

|V_i||V_j||Y_ij|cos(θ_ij− δ_i+ δ_j)

J3 off-diagonal = −∂Q_i

∂δ_j = |V_i||V_j||Y_ij|cos(θ_ij− δ_i+ δ_j)wherej 6= i (2.15) J4 diagonal = ∂Q_i

∂|V_i|= 2|V_i||Y_ii|sin(θ_ii) +X

j6=i

|V_j||Y_ij|cos(θ_ij− δ_i+ δ_j)

J4 off-diagonal = ∂Q_i

∂|V_j|= |V_i||Y_ij|sin(θ_ij− δ_i+ δ_j)wherej 6= i (2.16)

Based on these dependencies the computation time for the power flow can be reduced by neglecting some of the dependencies. Since the computation of the jacobian is relatively taxing, neglecting the dependencies reduces the computation times. Some of the methods that implement on neglecting the dependencies are explained in the following sections.

2.1.2.3 Fast Decoupled

The fast decoupled method has the same principles as NR but is computationally less exhaustive. It achieves this by simplifying the computation of the jacobian. The dependencies, of the active power and reactive power with respect to the voltage magnitude and phase angle, were discussed in section 2.1.2.2.1. For power systems the transmission lines have high X/R ratio. Such systems exhibit a greater dependency of active power to the phase angle rather than to the voltage and the reactive power has a greater dependence on the voltage than the phase angle. Considering this simplification the sub matrices of jacobian corresponding to these dependencies are set to zero. Thus the linear equation 2.11 reduces to equation 2.17.

"

∆P

∆Q

#

=

"

J 1 0 0 J 4

# "

∆δ

∆V

#

(2.17)

(19)

This considerably simplifies the power flow computation and requires less time and effort to find a solution. The solution is provided by the two decoupled sets of equations 2.18 and 2.19.

∆P = J 1∆δ (2.18)

∆Q = J 4∆V (2.19)

2.1.2.4 DC Load Flow

The DC Load flow provides a non-iterative estimation to the power flow for an AC system [8].

It only considers the active power flows and the reactive flows are neglected. It provides a lower accuracy but the method has 100% convergence [9]. It has applications in scenarios where fast and repetitive load flow estimations are needed. The DC power flow has its derivation based in the following assumptions [9] :

• Line resistances are negligible in comparison to line reactance.

• Difference in phase angles is considered small enough to apply small angle theorem, namely sinθ ≈ θ and cosθ ≈ 1 .

• Voltages are considered to be close to 1 p.u .

Taking into account the above assumptions, the PFE is reduced to equation 2.20.

P_i=

N

X

j=1

B_ij(δ_i− δ_j) (2.20)

2.1.3 Industrial Power Flow Requirements

The PFE introduced in section 2.1.1.1 are based on the flow of power in the electric network, considering interconnected buses through transmission lines. In actuality power systems consist of many different types of equipment, which have an effect on the power flow. Therefore, the PFE need to model the different types of equipment and their associated controls. These equipment and control functions may include the following:

• Transformer tap changers.

• Transformer phase tap changers.

• Voltage and reactive power control using transformer tap changers.

• Voltage control using shunts.

• Voltage control using synchronous generators.

• Reactive power limits for production units.

• HVDC injection models.

(20)

2.2 Power System Equipment

As mentioned in section 2.1.3 there are several equipment that need to be modeled in the PFE to make them usable in commercial environments. In this thesis two of these devices have been considered, namely ratio tap changers and switched shunts. To model their complete effect on the power flow, two things need to be considered, the effect of the device’s behavior and the effect of its associated control, on the power flow. The modeling of the behavioral effect of ratio tap changers and switched shunts is explained in section 2.2.1 and 2.2.2, while the effect of their controls in section 2.2.3.

2.2.1 Ratio Tap Changer

Power transformers are an integral equipment for power systems. They are used to step-up and step- down the voltage levels to facilitate cost effective transmission of power. They are equipped with tap changers which allows for a variable transformer winding ratio. Tap changers can be classified into phase tap changers and ratio tap changers. Phase tap changers vary the phase angle of the voltage at both ends of the winding, while ratio tap changers vary the winding ratio. This thesis focuses on ratio tap changers.

Ratio tap changers either control the bus voltage or the reactive power. A single line diagram for a two phase winding transformer with a ratio tap changer is as shown in figure 2.1. Transformers are modeled as a series admittance in power flow. At nominal ratio this admittance is similar from both sides, but at off-nominal tap the admittance as seen from both ends is different and therefore needs to be adjusted. The voltage and current relationships for both ends of the transformer are given by equations 2.21 and 2.22 respectively. From the figure 2.1, it can be seen that the current from the non-tap side of the transformer can also be given by equation 2.23.

Figure 2.1: Transformer with a tap changer [1].

V_x= V_j

a (2.21)

I_i= −aI_j (2.22)

I_i= y_t(V_i− V_x) (2.23)

Substituting equation 2.21 in equation 2.23 we get the equation 2.24 and using equation 2.22 in equation 2.24 we get the equation 2.25. These equations represent the current from both ends of the

(21)

transformer in terms of the voltage, transformer admittance and the tap ratio, which can be written in matrix form as in equation 2.26.

I_i= y_tV_i−y_t

aV_j (2.24)

I_j= −y_t aV_i− y_t

a²V_j (2.25)

"

I_i I_j

#

=

"

y_t −^y_a^t

−^y_a^t ^y_a^t2

# "

V_i V_j

#

(2.26) The detailed derivation of the pi-model for a ratio tap changer is detailed in [1], which is used in this thesis and briefly described above. The pi-model is shown in 2.2.

Figure 2.2: Ratio tap changer pi-model [1].

To model the effect of the ratio tap changer’s behavior, the transformer admittance is included in the bus admittance matrix [1,8]. This is an easy and simple procedure, but when the tap position is changed, the bus admittance matrix needs to be reformed, which is a computationally exhaustive procedure. To avoid this, the effect of tap ratio on the transformer admittance is modeled in the PFE. This is done by introducing the tap ratio as a variable in the PFE. Since the effect of the tap ratio varies for the tap side and non-tap side, two sets of equations are formed. The non-tap side PFE for active and reactive power are outlined in equations 2.27 and 2.28 respectively.

P_ij= V_i²a²g − V_iV_jay_ijcos(θ_ij− δ_i− δ_j) (2.27)

Q_ij= −V_i²a²b − V_iV_jay_ijsin(θ_ij− δ_i− δ_j) (2.28) Where P_ijrepresents the active power flow from bus i to bus j and Q_ijthe reactive power flow.

V_iand V_jrepresent the bus voltage magnitudes at bus i and j respectively while δ_iand δ_jthe phase angles. Y_ij is the line admittance between the two buses and θ_ij the admittance angle. Finally a represents the tap ratio.

For the tap side the PFE are given by equations 2.29 and 2.30.

P_ji= V_i²g − V_iV_jay_ijcos(θ_ij− δi− δj) (2.29)

(22)

Q_ji= −V_j²b − V_jV_iay_ijsin(θ_ij− δ_i− δ_j) (2.30) 2.2.2 Switched Shunts

Shunts are power system elements that provide reactive or capacitive compensation. They are modeled by an admittance connected between the bus and ground. Shunts have a fixed admittance, but they can be connected or disconnected from the bus. These switched shunts can comprise from one to several sections and hence provide a varied compensation. This gives a simple method to regulate the bus voltage. Depending on the voltage required at the bus a number of sections can be connected or disconnected. Since a continuous variation of admittance is not possible they do not provide a voltage control method but rather a regulatory one [8].

To model the effect of the switched shunt’s behavior, the shunt admittance is included in the bus admittance matrix [1, 8]. This is an easy and simple procedure, but when the shunt is switched on or off, the bus admittance matrix needs to be reformed, which is a computationally exhaustive procedure. To avoid this the effect of this switching is modeled in the PFE. This is done by introducing the shunt admittance as a variable in the PFE. The PFE for the switched shunt are given by equation 2.31 for the active power and equation 2.32 for the reactive power.

P_ii=

n

X

j=1

|V_i||V_j||Y_ij|cos(θ_ij− δ_i+ δ_j) + V_i²y_shcos(θ_sh) (2.31)

Q_ii= −

n

X

j=1

|V_i||V_j||Y_ij|sin(θ_ij− δ_i+ δ_j) − V_i²y_shsin(θ_sh) (2.32) Where P_irepresents the active power flow at bus i and Q_ithe reactive power flow. V_irepresents the bus voltages at bus i, y_shis shunt admittance between the two buses and θ_shthe shunt admittance angle.

2.2.3 Control Strategies

Network devices have associated controls and they govern how the device behaves in different condi- tions. Depending on the device control the power flow is effected. To incorporate these effects, the controls of these devices are also modeled in the power flow algorithm. Some examples can include the voltage control using tap changer, reactive power limits for synchronous generators based on their capability curves, active power control through phase tap change transformers and many oth- ers. Since in this thesis ratio tap changers and switched shunts are considered, their corresponding control is also modeled.

Since the devices being considered were ratio tap changers and switched shunts, control strategies pertaining to these devices were explored. For automatic tap adjustment, several possibilities exist which have been researched. These can be primarily divided into two groups:

• The tap ratio is modeled as a variable to control the voltage or reactive power. In the case that the tap changer hits a limit, it is fixed and replaced by the voltage as a variable. This approach is discussed in [10] and [11].

(23)

• In the other approach the controlled voltage is a state variable and in the case that it does not match its regulated value, the corresponding tap ratio is altered to meet the regulated value.

This approach is discussed in [12] and [13].

Conventionally and in practice these devices have discrete controls and many power flow solvers implement them as such. The basic procedure follows that the power flow is solved with initial settings for these devices, if the controlled variable does not match the reference values, the device settings are adjusted by a single step and the power flow is repeated [8]. This procedure though being methodical is time consuming and computationally expensive. This thesis utilizes a sensitivity based approach for the control of tap changers. This allows to calculate the sensitivity of the tap ratio to the control variable in every iteration and therefore an easy and efficient adjustment for the tap ratio. Moreover the sensitivity method can be extended to other devices, for example the same method is also used to control bus voltage using switched shunts. This method does not make the control process continuous as the tap changers and switched shunts are discrete devices, although the sensitivity method provides a continuous control.

2.2.3.1 Sensitivity Analysis

The sensitivity analysis approach is based on [14]. This paper discusses the approach in [10] to [13]

and discusses the advantages of the sensitivity based control. In [14] the solution approach is still to solve for the tap ratio after the NR iterations. In this thesis, the tap control is applied along with the NR iterations.

The equilibrium state of a power system is represented by the non-linear equation 2.33.

g(x, y) = 0 (2.33)

where x are the independent variables (bus voltage and angle) and y the dependent variables (active power and reactive power). Introducing the tap ratio as a control variable this equilibrium is represented by equation 2.34.

g(x, a, y) = 0 (2.34)

where a is the tap ratio. This set of non-linear equations can be linearized at an operating point such as x_o, given by equation 2.35.

(∂g(x, a, p)

∂x )∆x = −(∂g(x, a, p)

∂a )∆a (2.35)

The control variables control some entity which can be represented as a function, f (x, y), of the independent and dependent variables x and y respectively. This function can represent the voltage or the reactive power flow being controlled. The effect of the control variable on this function can be determined by using the differential given by equation 2.36.

∆f = (∂f (x, a, p)

∂x )∆x + (∂f (x, a, p)

∂a )∆a (2.36)

Substituting equation 2.35 into equation 2.36 we get equation 2.37. Equation 2.37 is reorganized into equation 2.38 which gives the rate of change of the control function with respect to change in the control variable.

(24)

∆f = −∂f

∂x[∂g(x, a, p)

∂x ]⁻¹∂g

∂a∆a +∂f

∂a∆a (2.37)

∆f

∆a = −∂f

∂xJ⁻¹∂g

∂a+∂f

∂a (2.38)

J represents the jacobian as explained in section 2.1.2.2.1. Defined here by equation 2.39.

J , [∂g(x, a, p)

∂x ] (2.39)

(25)

Chapter 3

Implementation

3.1 Introduction

The aim of this thesis is to develop the OpenEMS Power Flow Solver (OPFS). The OPFS should be efficient, scalable and easier to maintain. Since it is part of the OEMS project, the idea is to develop OPFS using existing commercially available or free ware software development tools. The OPFS development is divided into two main tasks:

1. Implementation of PFP with various power system equipment and their control strategies.

This implementation is further discussed in section 3.2.

2. Formulation of the PFP at a higher abstraction level to ensure that maintenance and upgrade is easier. This task is the main contribution of this thesis and is further discussed in section 3.3.

3.2 Power Flow implementation

The PFP and modeling of different power system equipment was discussed in section 2.1. The power system equipment modeled in this thesis is the ratio tap changer and switched shunts. The implementation for this PFP was done in Matlab. Matlab is a very powerful tool and is widely used all over the world. The matrix based language provides an easy and efficient way of expressing mathematical problems. With the vast pre-built toolboxes Matlab provides a fast setup for engineering and scientific problems and several methods to analyze and test different scenarios. The implementation in Matlab provided a proof of concept and also a test bed for validation of the power flow and the modeling of associated equipment. The power flow for a 30 bus American power system was implemented. The system data is provided in appendix B. In the following sections the procedure for the implementation is discussed briefly.

3.2.1 Writing Equations

The PFE were derived and discussed in section 2.1.1. These are given here by equations 3.1 and 3.2.

Except for the summation function, Matlab provides with all the functionalities required to solve

(26)

the PFE. To implement the summation, two loops are required that operate in the i and j index.

The summation is performed by looping through all j indices and then incrementing in i.

P_i= P_Gi− P_Di=

n

X

j=1

|V_i||V_j||Y_ij|cos(θ_ij− δ_i+ δ_j) (3.1)

Q_i= Q_Gi− Q_Di= −

n

X

j=1

|V_i||V_j||Y_ij|sin(θ_ij− δ_i+ δ_j) (3.2)

3.2.2 Data Input

Network data for the Matlab implementation is provided as a separate text file. The data is divided into mainly two groups, busdata and linedata. Busdata contains all information about the network buses while linedata contains all information about the lines. The different parameters that the busdata and linedata provide are given in tables 3.1 and 3.2 respectively. As the network system is expanded and other essential equipment is modeled, a data table for each equipment is added.

In this implementation since tap changing transformers and controllable shunts are considered, the data file also includes tap data and shunt data tables. The information these files contain is given in tables 3.3 and 3.4 respectively.

Table 3.1: Bus data matrix format

Bus Denotes the bus number

Type The type of bus (Slack, load or voltage regu-

lated)

Pgen Generated active power at the bus

Qgen Generated reactive power at the bus

Pload Active load at the bus

Qload Reactive load at the bus

Yl Shunt conductance at the bus

Ysh Shunt susceptance at the bus

V Voltage at the bus

Angle Voltage angle at the bus

Vreg Required voltage value at the bus

Vbase Voltage Base for the bus

(27)

Table 3.2: Line data matrix format

Line Denotes the line number

From The from bus for the line

To The to bus for the line

R Resistance of the line

X Reactance of the line

G Conductance of the line

B Susceptance of the line

Tap If a tap changer exists on the transformer

Table 3.3: Tap data matrix format

From The from bus for the transformer

To The to bus for the trasnformer

Neutral step The neutral step position for the tap changer

Normal step The normal step position for the tap changer

Current step The initial step position for the tap changer

High step The highest possible step position for the tap

changer

Low step The lowest possible step position for the tap

changer

Neutral U The voltage for the transformer at neutral step

G Conductance of the transformer

B Susceptance of the transformer

R Resistance of the transformer

X Reactance of the transformer

Table 3.4: Shunt data matrix format

Bus The bus at which shunt is installed

Sections Number of sections of the shunt

Current section Initial section for the shunt

B Susceptance per section

G Conductance per section

(28)

3.3 Power Flow Problem Formulation at Higher Abstraction Level

One of the problems with the present PFS is that it is difficult to maintain and upgrade, since the PFP has been coded in a low programming level. With OPFS, to have easier maintainability, the idea is to formulate the PFP at a higher abstraction level. Hence, it would be human readable and intuitive, and easier to maintain. Since the OPFS also needs to satisfy efficiency and performance criterion, this PFP formulation should be compiled into machine code and linked with an efficient solver. Therefore, the development process for OPFS had three main tasks:

1. Identify a programming language which enables the definition of power flow at a higher programming level.

2. Compilation of code in 1 into lower level machine code.

3. Linking of code in 2 with an efficient solver.

To achieve these tasks several programming languages were surveyed, this is discussed in the following section.

3.3.1 Surveyed Languages

As mentioned above programming languages were surveyed that could fulfill the OPFS requirements.

These included different modeling and mathematical languages. The languages surveyed include Modelica, Matlab, Mathematica, Ptolemy and C++. The survey was conducted with the following key points:

• The language’s ability to define mathematical problems.

• The ability to extend and combine several mathematical problems.

• Scalability to larger problem sets.

• Performance with respect to the requirements of a PFS.

In the next sections, the survey for each language is further discussed.

3.3.1.1 Modelica

Modelica is a modeling language that was developed with the aim to standardize modeling and exchange of dynamical systems [15]. It is an open source, object oriented, equation based language to define models for complex physical systems. For purposes of modeling in Modelica users need a simulation platform that implements Modelica. Several platforms exist that provide an efficient and easy modeling approach in Modelica. These include OpenModelica, JModelica, Dymola, CATIA systems, CyModelica etc. In this thesis OpenModelica, JModelica and Dymola were surveyed.

(29)

3.3.1.1.1 OpenModelica

OpenModelica is an open source simulation environment based in Modelica. It provides the user with both graphical and text based modeling. Although it provides the user with an option for text based modeling, the features are limited and is not as friendly as the graphical interface. Since the thesis focuses towards a textual representation of the PFP, Dymola was preferred over OpenModelica.

Further details and information regarding OpenModelica can be found in [2].

3.3.1.1.2 JModelica

JModelica is an open source simulation environment based in Modelica. It provides a text based modeling in python. Due the ease of usabilty of OpenModelica and Dymola, JModelica wasn’t explored further. Further details and information regarding JModelica can be found in [16].

3.3.1.1.3 Dymola

Dymola is a commercial simulation environment based in Modelica. It provides the user with both graphical and text based modeling. Since the text based interface for Dymola was better than OpenModelcia further investigation into modelica was done using Dymola. Further details and information regarding dymola can be found in [17].

3.3.1.1.4 Modeling in Modelica

Modleica is an equation based object oriented language, and the models are described using equations. This gives the ability for analytic modeling, where variables and known parameters are declared to define models with equations. As Modelica uses equations it provides an excellent choice for describing models in a human readable and intuitive form. Modelica has a vast and expanding resource of libraries that contain multiple power system components and has been the focus of research in power systems. [18, 19] present their work in the power systems field where Modelica is useful. Modelica on an initial analysis seems a good choice for OPFS.

Modelica was invented for simulation studies, which it perfectly fits. But Modelica isn’t the best choice for the PFS application. Since it was designed for simulation studies it has different goals than a PFS. Modelica fulfills the aim of defining models in a human readable and intuitive form but it does not meet other requirements. These include the scalability to large problem sets, performance, and integration to an efficient solver. To understand why these problems exist the work flow of the Modelica compiler is studied. Figure 3.1 shows the Modelica compiler work flow. It can be seen that the graphical or textual representation of the model is converted into a Modelica model, this is then converted into Modelica source code. The Modelica source code is then converted into optimized sorted equations through the steps of translation, analysis and optimization respectively.

The optimized code then is converted into c code for further compilation into an executable. The end executable or the c code is a solution to the complete system, which is deficient in meeting performance requirements of a PFS. Also any change in the system data needs to be made at the modeling level and the whole model needs to be recompiled. For these reasons Modelica was not considered for OPFS development.

(30)

Modelica textual Editor

Modelica

Graphical Editor Modelica Model

Modelica Source Code

Translator

Analyzer

Optimizer

Code Generator

C compiler

Simulation

Modelica Model

Flat Model

C Code Optimized

Sorted Equations

Executable

Figure 3.1: Modelica compiler work flow [2].

3.3.1.2 Ptolemy

Ptolemy is a project conducted by the Department of Electrical Engineering and Computer Sciences of the University of California at Berkeley. It is similar to Modelica and aims at modeling, simulating and designing concurrent systems. Ptolemy was a potential candidate that could be adopted in this project. While it provides a foundation for modeling, the main aim of the Ptolemy is for embedded systems. Also being similar to Modleica, it faced the same limitations. Therefore further research into Ptolemy was not done. Further details and information regarding Ptolemy can be found in [20].

3.3.1.3 Wolfram Mathematica

Mathematica is a computational program based on symbolic mathematics. It has uses in the fields of science, mathematics, engineering and computing. The programming language used is the wolfram.

Mathematica provides an adequate base with multiple functionalities for modeling physical systems.

The limitations in Mathematica were similar to Modelica which hindered further research into the language. Further details and information regarding wolfram mathematica can be found in [21].

3.3.1.4 Matlab

Power flow implementation in Matlab was discussed in section 3.2. The Matlab implementation provided a test bed and proof of concept for the formulation of the PFP. As mentioned before Matlab is a very powerful tool and the matrix based language provides an easy and efficient way of expressing mathematical problems. Therefore, Matlab suits our needs and could be a possible

(31)

platform for the OPFS development. Since the PFP had already been implemented, Matlab was further explored with respect to its code conversion into C++, which is explained next.

3.3.1.4.1 Matlab to C code

The Code Generator is a Matlab tool that converts Matlab code into C++. This tool gave a great opportunity as the PFP could be formulated at a relatively higher programming level and then converted to lower programming level for performance and efficiency. Details on how to use Code Generator and its different applications can be found in [22]. Although, this was a great opportunity and the code output from the Code Generator can be compiled into an executable, there were a few short comings with the Matlab platform and the code generator. These are:

• The number of files and the overall size of the generated code is large in comparison to the power system modeled in Matlab. This would be a limiting factor when modeling power systems in real life scenarios which can be up to thousands of buses.

• The Code Generator can only convert Matlab functions, therefore linking code for these functions needs to be written in C++.

• The loops required to implement equations in existing PFS still could not be avoided.

• The PFP formulation in Matlab is human readable to an extent. Also as mentioned above the loops could not be avoided, which makes the code programmer specific, as different program- mers will implement the equations in a different way.

3.3.1.5 C++

The main objective in the OPFS development was to find a programming language that could allow PFP formulation in a human readable form but also provide a performance efficient solution.

Since, C++ is a highly efficient low level programming language and has library support that allows programming at a higher level, C++ was also researched. The library that facilitated coding at a higher programming level was Armadillo, it is explained next.

3.3.1.5.1 Armadillo

Armadillo is an open source library for C/C++. It aims to strike a balance between ease of use and speed, by providing a high programming level similar to Matlab [23, 24]. Armadillo provides easy handling of vectors and matrices. It has several functions that facilitate the construction of matrices and vectors and the handling of data in an easy and efficient manner. Details regarding the complete functionality of the library can be found at [23]. The Armadillo installation instructions are provided with the Armadillo source code, in this thesis Armadillo was used on a Linux based platform. The installation instructions followed are provided in appendix A.

Recognizing the similarities between Matlab and Armadillo, the PFP implementation in Matlab, discussed in section 3.2, was translated into C++ code using Armadillo. Armadillo provides a syntax translation for Matlab code to Armadillo, which can be found in [25]. The implementation in Armadillo provided a proof of concept that programming at a higher abstraction was possible in

(32)

lower level languages, such as C++. Moreover, it utilized the efficiency and performance benefits of C++ and unlike Matlab did not need any tools for code conversion to a lower programming level.

3.3.1.5.2 C++ Limitations

Armadillo provided a platform with a higher level syntax and speed, but the implementation was very similar to Matlab and had the same concerns and limitations as mentioned in section 3.3.1.4.1.

Therefore further development with armadillo and C++ could not be carried out.

3.3.1.6 Summary for Surveyed Languages

The languages surveyed fulfilled some aspects of our requirements. Modelica and Ptolemy fulfilled the idea to define models in a human readable and intuitive form but since they were designed for simulation purposes they did not meet performance requirements for a PFS and also failed in linking external solvers and conversion to a lower level language.

Matlab and C++ implementations fulfill lower level language constraints but the use of loops to implement the power flow could not be avoided and the programming level is sufficiently low in comparison to Modelica. This leads us to conclude that a language which provides an abstract implementation of models like Modelica while fulfilling performance requirements of a C++ implementation is still needed.

3.4 Open EMS Power Flow Solver

3.4.1 Introduction

As concluded in section 3.3.1.6, existing programming languages could not meet the requirements for OPFS, but it gave the direction to develop a specific language for OPFS. The inspiration was adopted from Modelica, which was developed to facilitate the modeling of physical systems for simulation studies. The idea was to develop a language that would formulate the PFP in a human readable form while meeting performance requirements of a PFS. The development of the OPFS was divided into three main tasks as follows:

• A language definition that could formulate the mathematics.

• A parser for the defined language.

• A code generator that generates low level machine executable code from the parser output.

Figure 3.2 shows the work flow diagram for the OPFS. The language definition, termed here as the OPL, is represented by the “Language” block and explained further in section 3.4.2. The parser block takes the OPL code as input, it represents the compiler-compiler application needed to translate the OPL code. The compiler-compiler is chosen as “Flex and Bison”. The working of Flex and Bison is explained in section 3.4.3. The parsed code from Flex and Bison is passed to the code generator. The code generator translates it into machine code, links the network data and passes it to the solver to obtain the power flow solution. Code generator is further explained in section 3.4.5.

For the transfer of data between the parser and code generator application, serialization is used. It is explained in section 3.4.4.

(33)

Language (OPL)

Parser (Flex and

Bison)

Parsed Data Transfer (Serialization)

Network Data

Code

Generator Solver

Power Flow Solution

Figure 3.2: Work flow for the OPFS.

3.4.2 OpenEMS Programming Language - OPL

OPL was defined with the requirement that the power flow definition should be human readable and intuitive. Since text book equations provide a near perfect example of human readable and intuitive form, OPL was defined in the same manner to consist of equations for defining a system’s model. The active power equation as in textbooks is shown in equation 3.3 while the same equation as written in OPL is shown in figure 3.3.

P_i= P_Gi− P_Di=

n

X

j=1

|V_i||V_j||Y_ij|cos(θ_ij− δ_i+ δ_j) (3.3)

Figure 3.3: Active power equation as written in OPL.

Figure 3.3 shows the structure of the OPL. It is seen that it contains functions like, sum and cos, which are contained within curly brackets. The characters V , Y , thetaY and theta are variables.

The variables have associated indices, i and j, with them. Therefore to define an equation in OPL, the basic things needed are variables, functions and indices. How functions and indices are declared in OPL is discussed in sections 3.4.2.3 and 3.4.2.4. To be able to declare variables, the OPL code has two sections, “Variables” and “Equations”. Each section starts with the section name and is followed by a colon. To end the code an “endf” statement is required. This syntax of the OPL is shown in figure 3.4. The sections, variables and equations, are further explained in sections 3.4.2.1 and 3.4.2.2 respectively.

3.4.2.1 Variables

In the variables section the user defines the names and type for the variables to be used in the equation definitions. In OPL variable names can consist of alphabets and number, but underscore and any other special characters are not allowed. The types of variables can either be “vector” or

“matrix”.

(34)

Figure 3.4: OPL format and mandatory sections.

For the active power equation in figure 3.3, the code for variable declaration is as shown in figure 3.5.

Figure 3.5: Variable declaration in OPL.

3.4.2.2 Equations

The power system equations are written in this section. For power flow two calculations are required, the power at each bus and the jacobian matrix. Therefore the equation section has two subsections,

“jacobian” and “powerflow”. In section 2.2, the different types of power system equipment were discussed and their effect on the power flow was modeled. To distinguish equations for the different types of equipment, the subsection name must have a text qualifier that denotes the type of equipment. The possible text qualifiers are basecase, tapchanger or shunt.

An example of the OPL code for equations is shown in figure 3.6. As mentioned above it has two subsections, these start with keywords “jacobian” and “powerflow” and are ended with a

“end subsectionName” statement. Also notice the text qualifiers adjacent to the subsection names.

The active power equation in figure 3.3 is applicable to the basecase and is therefore written in the

“powerflow basecase ” segment.

(35)

Figure 3.6: Equation declaration in OPL.

3.4.2.3 Indices

In power systems, power flows from one bus to the other. In calculating the power flow and jacobian equations, distinction is needed between the buses, i.e. to determine the bus power is flowing from and the bus it is flowing to. For this distinction to be possible indices are used. Figure 3.7 shows a two bus system, to calculate the active power flow at a bus, equation 3.4 can be used. The indices in the equation denote which bus’s parameter to use. For example, if we want to calculate the power flow from bus 1 to bus 2, and using index “i” to denote the “from” bus and index “j” the “to” bus.

The equation is solved with the values of bus 1 in place of the variables with index i and values of bus 2 in place of variables with index j.

P_i= |V_i||Vj||Yij|cos(θij− δi+ δ_j) (3.4)

Figure 3.7: A two bus system [1].

In OPL indices are denoted by underscore, for example theta1 i, y j, x ij. In OPL index “i”

denotes the “From” bus and index “j” the “To” bus.

3.4.2.4 Functions

In section 2.1.1.1, the PFE were discussed, it can be seen that they contain general mathematical functions such as sine, cosine and summation. To be able to define equations with such functions,

(36)

the OPL has three possible function declarations.

• sin to compute the mathematical sine.

• cos to compute the mathematical cosine

• sum to compute the summation. As seen in equation 3.3, the power at a bus is calculated as the sum of power flowing from the bus to all connected buses. In OPL the sum function is responsible to implement this summation. As discussed in section 3.4.2.3, the i index denotes the from bus, therefore the sum function for a particular i index iterates overall j indices adding the values together before it moves to the next i index.

Function declarations start with the function name followed by the function body written within the curly ”{” ”}” brackets. For example sin{theta1 i + theta2 j} , sum{x i+y j}.

3.4.3 Parser

The language definition for OPL allows programming at higher abstraction level, but to be able to execute this code it needs to be compiled into machine code. The first step in doing so is to parse the OPL code. This is done by the parser application, and the chosen parser is Flex and Bison.

These are UNIX utilities which have applications in writing compiler compilers. They are updated versions of the “Lex” and “Yacc” [26]. Apart from being simple and a good choice to write a parser in limited amount of time, they have other advantages over custom written parsers [26]:

• Parser written with Flex and Bison will be fast and efficient.

• Source code is easy to update and fix bugs.

• Error handling and recovery mechanisms are provided.

Lexer File

Parser File

flex

Bison source file bison

Lex source

file

C

Compiler Program

Figure 3.8: Flex and bison working diagram [3].

The general compilation process for Flex and Bison is shown in figure 3.8. Flex and Bison work in conjunction to provide a complete parser [3]. The role of Flex is to generate tokens based on the code input, these tokens are then used by Bison for parsing. The communication between Flex and

(37)

%{

/* C header section */

%}

/* Bison definitions */

%%

/* grammar rules */

%%

/* C body section */

Figure 3.9: Bison code structure [3]

Bison is achieved by the yylex function, whenever Bison needs a new token it calls the yylex function which returns the next token [3]. The Bison code structure is as shown in figure 3.9. As can be seen it has four main sections. The C header section contains all the header files needed for the user defined code. The Bison def initions contain some default Bison definitions but it also contains the token definitions. This is needed so that Bison can identify the tokens that are generated from Flex and later use them for parsing. The grammar rules contain the syntax rules according to which the code should be parsed. As mentioned in section 3.4.2, the OPL code has two sections and the section names are followed by colon, these rules are written in the grammar rules section. Based on these syntax rules the user can specify what action is taken when a particular syntax rule is justified or broken. These actions are contained in the C body section.

The working of Flex and Bison can be explained considering figure 3.10 as an example. Bison calls the yylex function and it returns the first token from Flex as variables. Bison receives the token and goes to the grammar rule to identify if it needs to take an action on this token. It then calls for the next token, which in this case is : (colon), it then again reads the grammar rules to decide what action to take. Since the OPL syntax requires that the section name should be followed by a colon, if after the variables token the : token was missing, Bison based on the grammar rules would generate an error message. In this way Flex and Bison parse through the complete code taking actions based on the grammar rules.

3.4.3.1 Error Handling

Bison provides error handling and recovery mechanism, these were used to provide syntax error checking. The syntax error checking provides a safe check to avoid common typing and syntactical errors. These include:

Formulation of the power flow problem in human readable form for translation into an efficient solver

Formulation of the power flow problem in human readable form for translation into an efficient solver

MUHAMMAD TALAL KHAN

Formulation of the power flow problem in human readable form for translation into an efficient solver

Contents

List of Tables

List of Figures

Chapter 1

Introduction

Chapter 2

Background

2.1 Power Flow

2.2 Power System Equipment

Chapter 3

Implementation

3.1 Introduction

3.2 Power Flow implementation

3.3 Power Flow Problem Formulation at Higher Abstraction Level

3.4 Open EMS Power Flow Solver