Учебники / 0841558_16EA1_federico_milano_power_system_modelling_and_scripting

For example, in voltage stability analysis, load power consumptions are independent variables. In most applications considered in this book, only a scalar independent variable is considered. For example, the loading level μ for continuation power flow analysis (see Chapter 5) and the time t for time domain integration (see Chapter 8).

It is worth noting the di erence between controllable parameters η and device parameters such as transmission line series resistances or synchronous generator sub-transient short-circuit time constants. The latter cannot vary unless the device itself is changed. On the contrary, η are constant because their dynamic is slow with respect to the considered time scale. However, η can vary according to a given strategy or control. For example, η may represent the vector of dispatched generator active powers in optimal power flow analysis (see Chapter 6).

Analogously to (1.7), equations (1.11) can be split into a collection of subsystems if discrete variables u are substituted for if-then rules. Thus, (1.11) can be conveniently rewritten as a collection of continuous DAEs, one per each discrete variable change. Such a system is also known as hybrid automaton or hybrid dynamical system. An in-depth description and formalization of hybrid systems for power system analysis can be found in [131] and other works by the same author.

The DAE system (1.11) can be defined for any time scale. The terms slow and fast do not mean anything unless the reference time scale is defined. In this book, the time scale of interest concerns transient stability analysis, i.e., from 0.01 s to 10 s or, which is the same, from 0.1 Hz to 100 Hz. Subsynchronous resonance and some long term dynamics (such as under load tap changer controls) overlap transient stability dynamics and are thus also taken into account in this book (see Figure 1.6). In some specific cases, also faster dynamics, such as synchronous machine magnetic fluxes are considered, mostly to perform comparisons with transient models.

Example 1.4 Transient Behavior of State and Algebraic Variables

Figure 1.7 illustrates the di erence between state and algebraic variable transient behavior. The figure shows the time evolution of two variables of the IEEE 14-bus system, namely the phase angle θ of the voltage at bus 5, and the rotor angle δ of synchronous machines at bus 3. The simulation shows the transient following line 2-4 outage occurring at t = 1.0 s. As explained above, the line disconnection can be modelled as a switch of a discrete variable. After the occurrence of the line outage, the bus voltage phase angle trajectory shows a discontinuity, while the synchronous machine rotor angle, as expected, is always continuous. Discontinuities only appear if a discrete variable changes its value. Hence, algebraic variable trajectories before and after discrete variable switches are continuous.

In Figure 1.7, the transition of the bus phase angle θ from t− to t+ is indicated by a dotted line vertical line. However, for simplicity, it is common

Fig. 1.7 Time evolution of state and algebraic variables

practice (also used in this book hereinafter) to plot preand post-disturbance values of algebraic variables as they were connected by a continuous trajectory. Thus, the reader has to be aware that straight vertical lines in the trajectories of as algebraic variables indicate a discontinuity or, in other words, a jump from t− to t+.

Example 1.5 Reactor Transient Stability Model

Let us consider again the inductor model discussed in Example 1.3 and define a model suitable for transient stability studies. Neglecting the ideal model (1.3) which is of no engineering interest and assuming lumped parameters, the most adequate starting point is the model (1.4).

Reactors (or chokes) used in industrial applications for short circuit protections or filters have an iron core and copper windings. Given that the copper and iron specific heat are cp,Cu = 0.385 and cp,Fe = 0.450 kJ/kgK, respectively, we can assume a mean specific heat of about cˆp = 0.4 kJ/KgK. The density of the copper and the iron are ρCu = 8 920 and ρFe = 7 870 kg/m3, respectively, we can assume a mean reactor density of about ρˆ = 8 500 kg/m3. If the reactor volume is Vol = 0.5 m3, an active area of A = 4.0 m2 and a convective heat transfer coe cient of about kc = 1.0 kW/m2K, then the thermal time constant can estimated as:

The thermal time constant is thus well beyond the transient stability time scale (e.g., 10 s) and we can consider that the reactor temperature Θ is frozen at a given value during transient stability simulations. Therefore, the reactor resistance value R is constant.

On the other hand, the parasitic capacity C and conductance G are very small. If the capacity is about 0.1 nF and the conductance is about 1.0 μS, then the time constant associated to parasitic e ects is:

Tp = C ≈ 10−10 = 10−4 s

G 10−6

that is much smaller than the limit of transient stability time scale (e.g., 0.01 s). Hence, the voltage at the reactor terminal can be considered an algebraic variable. Moreover, since both the conductance G and the capacity C are comparatively small, the total current can be approximated as i ≈ iL.

Neglecting magnetic flux saturation and assuming that the reactance of the reactor at the fundamental frequency of f = 50 Hz is, say, XL = ωL = 5.0 Ω and its series resistance is R = 2.0 Ω, then the time constant associated with the inductive coil is:

where ω = 2πf is the fundamental angular frequency of the system. Hence, the time constant Ti is su ciently small to allow considering also iL an algebraic variable. In conclusion, the reactor model for transient stability studies, at 50 Hz, is as follows:

where V and I are the phasor voltage and phasor current, respectively.

In case the reactor coil is made of a superconductor as in superconducting magnetic energy storage (SMES) devices, then the resistance R is some orders of magnitude lower than for standard copper coils. Hence, the time constant Ti can fall into the range of transient stability time scale. This justifies considering the SMES current as a state variable. Further insights on the SMES model are given in Example 18.3 of Chapters 18.

Fig. 2.1 Cantorian triadic bar with horizontal section dimension D = ln 2/ ln 3 = 0.6309

Clearly, some applications are more complicated than the average. For example the kernel of the operating system is a monolithic application. A current Linux kernel 2.6 with common modules has a size more than 8.5 millions of lines of code. However, the kernel is an exceptional application. And even the kernel is internally divided into several modules, each one taking care of a specific issue.

The fact that a complex and general purpose operating system such as Unix, can be reduced into a set of generally small programs and scripts, is common to any software project. The key point is to find an e cient, yet simple, mechanism to make all programs interact smoothly together. Ants have solved the issue basing their complex communication system on ferormons. The Unix solution is the assumption that everything is a file or a file-like object. Thus, applications communicate writing and reading files. Folders, Internet sockets, process forks and other fancy stu commonly used in informatics are treated as files.

An objective of this book is to formalize fundamental concepts for creating an application oriented to power system analysis. The conceptual issues that have to be solved are two: (i) to divide the project into a series of small functions, and (ii) to find a convenient glue that allows a good integration among all functions yet leaving each function as independent and stand-alone as possible. These issues are addressed in the remainder of this chapter.

Example 2.1 Unix Shell Script

To clarify the idea presented in the previous section, consider the following example. In the Unix (and Linux) environment, it is a common practice to create small shell scripts to execute a given series of commands. For the sake of example, the script used for generating the portable document format (pdf) file of this manuscript from source LATEX files is as follows:

latex book.tex

makeindex -s index book.idx bibtex book.aux

latex book.tex latex book.tex

dvips -tletter -Ppdf -G0 -o book.ps book.dvi ps2pdf book.ps book.pdf

The script above calls five executable programs that are supposed to be available in the system, namely latex, makeindex, bibtex, dvips, and ps2pdf. The first command compiles the book.tex source file (which is divided into a variety of files). The latex command, by itself, is not a monolithic application, but is based on the TEX compiler and on a myriad of specialized packages. Then the makeindex command create the analytical index, while bibtex parses the entries of the reference database for populating the book bibliography section. The following two latex commands consolidates the references and make a consistent document. The result of the latex commands is a dvi file which has to be transformed into a postscript (dvips) and finally into a pdf file (ps2pdf).

This lengthy description is aimed to show the fractal nature of Unix systems. A complex document such as this typeset manuscript is the results of a high fragmentation of the operations needed to obtain it. The pdf document is created using a variety of “macroscopic” applications (e.g., latex and ps2pdf). Then, each application internally calls a variety of other applications, packages, libraries, etc. (see Figure 2.2). If the function solved by each applications is “small” or “simple” enough, the function is executed, otherwise it is divided into simpler functions, and so on. The branching process ends up if a function is so simple that it cannot be conveniently further divided into other functions. Simplicity means that a specific function can be implemented and maintained by a single person or by a very reduced group of people. Moreover, simplicity generally also implies robustness. For example, the execution of the script provided in this example rarely fails despite the huge number of applications, functions and libraries that are directly or indirectly called.1

A failure occurs only if the source code (e.g., the book.tex file) contains errors, but this does not depend on the script nor on the application called by the script. Unfortunately, being able to recognize the errors due to the input data and those due to application bugs is not always straightforward as in this case.

2.2Classes and Procedures

The discussion and the simple provided in the previous section suggests that any software project can be assessed and mastered if adequately divided into a tree of single-goal possibly simple tasks. This is the strategy that allowed Romans to govern their huge empire, namely divide et impera (e.g., “divide and conquer”).

There are mainly two kinds of elementary pieces into which a software project can be divided: (i) classes which accomplishes a specific functionality (e.g., computing the current value of a function) and (ii) procedures that

1Actually, the TEX version 3.141592 program which is the kernel of the latex command, is said to be one of very few programs that are virtually bug free.

Fig. 2.2 Tree of applications called by a simple shell script

coordinate the activities of classes (e.g., the Newton’s method for determining the solution of a set of nonlinear equations). Procedures typically provide algorithms, while classes typically provide specific functions or, as they are known in the slang of object oriented programming, methods.

Using a modern concept of computer science, a class can be assimilated to an agent. A rigorous definition of an agent is as follows: “A software routine that waits in the background and performs an action when a specified event occurs. For example, agents could transmit a summary file on the first day of the month or monitor incoming data and alert the user when a certain transaction has arrived.” In this context, the details of agent theory are not relevant (e.g., the four key notions that distinguish agents from arbitrary programs: reaction to the environment, autonomy, goal-orientation and persistence) and agent-based programming techniques is not a concern.2 However, the agent definition fits well with the structures proposed in the next sections of this chapter.

According to the analogy with computer agents, procedures can be identified with agencies or authorities that decide which (and if) agents have to be called and which action or method is appropriate. After being initialized, each class waits for an event, i.e., a call from a procedure. For example, the power flow analysis calls device algebraic equations and power flow Jacobians. In case one is interested in solving a time domain simulations, the numerical integration routine calls di erential equations of all dynamic devices. Note that if a class does not take part to a certain kind of analysis, the procedure simply does not call it.

2The popularity of agent-based analysis is increasing in power system analysis, even though mostly oriented to the study and the modelling of electricity markets. The interested reader can find a comprehensive introduction to this topic in [347].

Even though class details have not been introduced yet, it should be easy to understand that classes have to be able to properly interact with procedures. This issue is discussed in the following section.

2.3Modularity

An important aspect that is worth further discussion is how classes and procedures communicate. Each arrow in Figure 2.2 (see also following Figures 2.3 and 2.5) represents a call to a function or to a method of some class. Following each call, the method has to perform some action and, optionally, return some object/data in a given format.

It is not hard to see that if each class has its own custom methods and each method requires custom calls, the procedures have to take care of each class in a di erent way. Furthermore, any change in a class method would require a change in the procedures that call that class. Even for a reduced number of classes, the whole project would quickly become intractable and di cult to maintain.

The critical issue is how to define the way classes communicate with the rest of the world. The set of rules that define the communication grammar and syntax is often called protocol in computer data communication and telecommunication. For example, the server message block (SNB) or the systems network architecture (SNA) provide a shared access to files, printers, serial ports and other resources between nodes (e.g., computers) of a network. More sophisticated examples of communications protocols are human languages, like English or Italian. In the same vein, computer languages are the communication protocol between human beings and computers.

A protocol should be as flexible and as complete as possible to avoid raising exceptions. An example of completeness and flexibility are human languages: a modern language such as English allows expressing any concept. However, computer applications never require such level of completeness and flexibility. Furthermore, too much flexibility may lead to ambiguity, which has to be carefully avoided in any computer application. Fortunately, simplicity (and, thereby, consistency) and flexibility are not necessarily in opposition. Example 2.2 attempts to clarify this point.

The definition of a common communication protocol for classes of the same kind should be accompanied by a systematic programming approach, i.e., modularity. Generally speaking, modularity is the property of a software package to be organized in fixed though flexible sections whose structure recurs with little of no changes in several parts of the package itself. Modularity is strictly linked to object-oriented programming and helps one implement, reuse and maintain a robust code. Chapter 3 provides further discussion and examples of class-based (i.e., modular) scripting for power system analysis.

Properly understanding the concept of modularity is fundamental for mastering the architecture of power systems. In fact, although the number of

devices that compose a real-world power system is huge, these devices can be divided into a few basic classes. Thus, even huge power systems such the one shown in Figure 1.1 of Chapter 1 can be assessed by defining a very reduced number of basic devices. In particular, the classes of devices that are of interest in this book are generators, transmission systems, transformers, loads, motors, regulators, power electronic converters and protections. Example 2.3 discusses the device taxonomy of the IEEE 14-bus system. This well-known benchmark system is extensively used throughout the book as main test board.

Example 2.2 Zero of a Scalar Function

To clarify the concepts introduced above, this example provides a qualitative description of a simple mathematical application containing modular classes and procedures.

The objective is to write a software application that finds the solution f (x) = 0 of a scalar function f that is defined by the user. Although f is not known, its general structure is fixed. Say that f is of the form:

=1,...,n

There is no particular reason for imposing such structure, it is just for the sake of example. The important point is that the user can instantiate any number n of functions fi. Such functions fi are collected in a library of classes, each of which defining a specific function kind. In this example two classes are considered: the quadratic polynomial and the sine function. The class that defines polynomial calculates the following function:

while the sine class computes:

Any other function fi(x) can be defined just by adding a new class. The user has to define in a file a triplet (ai, bi, ci) for each polynomial and a triplet (Aj , ωj , φj ) for each sine function. This can be conveniently accomplished using a text file with a given format.

Clearly, the polynomials and the sine functions could be merged together in a unique function. However, in this example we are not interested in e ciency or in reducing as much as possible the lines of code, but rather in providing an example of a modular application.

The user can also pass to the application some settings, such as the initial guess x0, which algorithm has to be used for finding the solution f (x) = 0, the tolerance that has to be used for defining the convergence of the algorithm,