Учебники / 0841558_16EA1_federico_milano_power_system_modelling_and_scripting
.pdf
2.3 Modularity |
25 |
Input data file
Data parser
|
|
|
Settings |
|
Solver procedure |
|
||
|
|
|
|
|
|
Plot f (x)
Interface
Solution
Function
Classes
add
fi(x) polynomial
dfi (x)
dx
add
fi(x) sine
dfi (x)
dx
Fig. 2.3 Structure of a simple application that finds the zero of a general scalar function f (x)
the maximum number of iterations before stopping the algorithm in case of no convergence, etc.
After parsing the input data file, the application calls the main procedure for solving f (x) = 0. At the each iteration k, the procedure calls the classes to compute each fi(xk ), and the derivatives dfi(x)/dx|k . If the method converges, the application returns to the user the solution x and, optionally, the final tolerance, the number of iterations, the plot of f (x) in the neighborhood of the initial guess x0, etc. Otherwise, the application displays an error message stating that the solver has not converged. The structure of this simple application is depicted in Figure 2.3.
The most important point that has to be retained is that any number of classes implementing a particular function can be added without changing the structure of the program or of the procedures outside the fi(x) classes.3 However, in order to accomplish this modularity, each fi(x) class has to communicate using a standard protocol. In this simple example, the communication protocol simply consists in passing to the fi(x) classes the current value of the variable xk and expecting that the classes return the values fi(xk ) and dfi(x)/dx|xk . It can also be helpful to use a common interface for simplifying the operations of handling several fi(x) classes. The interface can be a class itself or simply a collection of methods that organize the
3The only exception to this rule are data parsers that strictly depend on the functionality and features of the whole application. Adding a new fi (x) class likely a ects also the parser, since the input data format changes.
26 |
2 Power System Architecture |
initialization and the calls to the fi(x) classes. A possible implementation of this application is given in Script 3.1 of Chapter 3.
The example provided in this section is quite simple and has a limited practical use, however it is useful to understand the behavior of more complex tools, such as a power system software package. As a matter of fact, a power system package works in a very similar way as the tool described above. For example, classes that define dynamic power system devices may contain a method that evaluates di erential equations. This method requires the current simulation time and the state variable vector as input and return first time derivatives of those state variables of its competence. The duty of the procedures that calls dynamic devices (e.g., the time integration algorithm) is to collect the time derivatives in an ordered vector. However, there is no need for the time integration algorithm to know the details of the implementation of each device as long as the device returns the first time derivatives. Thus, adding a new device does not require to modify existing code. Furthermore, except for the multi-dimensional variable vector, the analysis techniques described in Part II consists, at the very end, in finding the solution of a set of nonlinear equations in the form:
0 = ϕˆ |
ˆ |
(2.4) |
(ξ) |
ˆ ˆ
where ϕ and ξ changes depending on the application. For example, in case of standard power flow analysis, ϕˆ describes the power injections at network
ˆ
buses and ξ are the voltage magnitudes and phases at load buses. In case of time domain analysis, (2.4) is solved for a sequence of given times and
ˆ ˆ
ϕ is a set of equations that depends on the integration algorithm while ξ are the state and algebraic variables of the DAE system. The same can be said for continuation and optimization methods. Thus the main issue that is addressed in Part II is the proper definition of the set of nonlinear equations
ˆ ˆ
ϕ(ξ).
Example 2.3 Structure of the IEEE 14-Bus System
In order to clarify the structure of a power system, Figure 2.4 depicts the IEEE 14-bus benchmark system that consists of two generators, three synchronous compensators, two two-winding and one three-winding transformers, fifteen transmission lines, eleven loads and one shunt capacitor. Not depicted in Figure 2.4, but implicitly included, are generator controllers, such as the primary voltage and frequency regulators, transmission line and transformer protections and breakers, etc. This simple network (as well as most benchmark systems) can be used to illustrate virtually all power system phenomena and, if properly modified, to show the behavior of any device model. This is a byproduct of the modularity of the power system structure.
2.4 Architecture of a Power System Software Tool |
27 |
|||
|
G |
Generators |
13 |
|
|
|
|
|
|
|
|
|
12 |
14 |
|
C |
Synchronous |
11 |
|
|
|
|
||
|
|
Compensators |
10 |
|
|
|
|
||
|
|
|
|
9 |
|
|
|
|
C |
|
|
G |
|
7 |
|
|
|
6 |
|
|
|
|
8 |
|
|
|
|
|
|
|
|
1 |
C |
|
|
|
|
4 |
|
|
|
|
|
|
|
|
|
5 |
|
Three Winding |
|
|
||
Transformer Equivalent |
2 |
|
||
|
|
|
|
|
|
9 |
|
|
|
|
|
|
G |
|
7 |
|
C |
|
3 |
|
|
|
||
|
4 |
8 |
|
|
|
|
|
C |
|
|
|
|
|
|
Fig. 2.4 IEEE 14-bus test system
2.4Architecture of a Power System Software Tool
This section attempts to define a basic and as general as possible architecture for a power system analysis software package. The proposed structure is shown in Figure 2.5. The main parts that are shown in the figure are as follows.
1.Parsing input data. Input data can be defined as plain text files or through graphical tools, such as one-line network diagrams or graphical information systems (GIS). There is no particular need for using only one graphical library or GIS tool. The fact that proprietary software applications do not allow using graphical systems but the one embedded in the application itself is an example of traditional programming that, in this book, is deprecated. In the same vein, there is no reason for adopting a particular data format as long as suitable parsers for the input data are provided. A detailed discussion on data format issues is provided in Chapter 21.
2.Initialization of power flow devices. Given the input data, the initialization of power flow devices consists in creating an instance of all devices that are used in the power flow analysis and populating these instances with the data provided by the parser. In power flow analysis one has to define at least buses, transmission lines, static generators and loads. But, in principle, any device can be included in the power flow analysis. This point is further discussed in Chapter 4.
28 |
2 Power System Architecture |
Network Diagram |
Input Data |
|
|
|
|
|
Data Format 1 |
Graphic Library 1 |
|
|
|
|
|
Parser |
Data Format 2 |
|
|
|
|
Graphic Library 2 |
|
|
|
|
|
|
Data Format n |
|
|
Initialization of |
|
Graphic Library n |
Power Flow Devices |
|
|
|
|
||
|
Power Flow Method 1 |
|
|
Settings |
Power Flow Method 2 |
|
|
|
|
||
|
Power Flow Method n |
|
|
|
|
Initialization of |
|
|
Remaining Devices |
|
|
Static |
Static |
Dynamic |
Dynamic |
Analysis 1 |
Analysis n |
Analysis 1 |
Analysis n |
Output Format 1 |
|
|
|
Output Format 2 |
Report Files |
|
Plots |
|
|
||
GIS 1
GIS 2
GIS n
Device 1
Device 2
Device 3
Device n − 1
Device n
Graphic Tool 1
Graphic Tool 2
Output Format n |
|
Graphic Tool n |
|
|
|
Fig. 2.5 Structure of a general purpose software suite for power system analysis
3.Power flow analysis. Since the focus of the book is on balanced systems at the fundamental frequency, the very kernel of the application is the power flow analysis. Of course, a similar structure can be extended or moved to other analysis, such as electro-magnetic transient (EMT) analysis. In this case, the core algorithm would be the EMT integration. However, the basic concepts that are beneath the proposed structure are independent of the specific analysis that is carried on.
The power flow analysis is a general solver that looks for the zeros of a set of nonlinear equations but does not contain any information about the network or the devices included in the network. The solver is not necessarily unique. As a matter of fact, several algorithms have been proposed in the literature and are discussed in Chapter 4 (e.g., Newton’s method, Seidel’s method and fast decoupled).
2.4 Architecture of a Power System Software Tool |
29 |
4.Initialization of remaining devices. After completing the power flow analysis, it is common practice to initialize dynamic devices such as synchronous machines, primary voltage and frequency regulators, etc. The initialization consists in creating an instance of all required devices, assigning the data to the instances and computing the initial value of state and algebraic variables (see Subsection 9.1.1 of Chapter 7). At the end of the initializations, the power system model is at a steady-state equilibrium point that serves as initial condition for further analysis.
5.Static or dynamic analyses. Given a steady-state equilibrium point, several analysis can be performed. This book focuses on two static ones (namely, continuation power flow and optimal power flow) and two dynamical ones (namely, eigenvalue analysis and time domain simulation). Other relevant topics are harmonic analysis, fault analysis, state estimation, etc. However, the relevant point is that any algorithm can be included in the scheme of Figure 2.5 provided that the algorithm properly interacts with all available devices.
6.Output storage and display. The last step is to display the results in a convenient format. Report files, tables, plots and other visualization techniques help understand and interpret results. As for the input data and one-line diagram editors, the choice should not be limited to only one tool or output format. Further discussions on these topics are provided in Chapters 21 and 22.
From the observation of the scheme depicted in Figure 2.5, one can identify procedures and classes. It is easy to distinguish classes from procedures based on a pictorial di erence: while classes are like terminals from which depart arrows, procedures are like hubs from and at which several arrows depart and arrive.
The procedures are: the input data parser; the initialization of power flow devices; the power flow analysis; the initialization of devices used after the power flow analysis; static and dynamic analyses; and output storage and display. The classes are: graphic libraries for defining network diagrams; graphical information systems; data format parser definitions; devices; and text and graphic output formatters. A special kind of class is the set of settings of the software package. Settings allow a fine tuning of the behavior of the application and of each procedure.
There are two kinds of procedures: the ones that implement mathematical analyses and algorithms (e.g., power flow analysis) and those that are mainly needed for organizing and putting in order the devices (e.g., input data parser). In the same vein, there are two kinds of classes: the ones that implements di erential and algebraic equations of power system devices and those that are for non-engineering operations (e.g., data grammars and graphic libraries). In this book, the focus is only on algorithms (Part II) and algebraic di erential equations (Part III). Part IV provides an overview of non-strictly- technical topics.
30 |
2 Power System Architecture |
While procedures are totally application dependent and have thus to be written for the specific problem that has to be solved, classes can be in some cases imported from existing public-domain libraries. For example, GIS and graphical functions can be imported from external libraries. On the other hand, power system device classes or data parsers have to be implemented as they are highly application dependent. However, the key point of a fragmented (or fractal) structure, is the fact that device and parser classes can be collected in a library and, if one needs a new device or a new parser, only that specific device or parser has to be implemented.
Figure 2.5 also helps understand one of the main reasons why undergraduate and Ph.D. students are afraid of writing their own power system software package. Thinking, organizing, planning and implementing the whole project is, at a first glance, overwhelming. Furthermore, a great portion of the code is out of the scope of power system analysis and modelling. However, had the student only to implement a few device classes or an algorithm (procedure), the amount of code to implement would be relatively easy to master. Of course, the underlying assumption is that the main project to which the student adds his contributions has to be open in the sense discussed in Section 3.1. More details on educational aspects of power system software tools are given in Chapter 23.
Chapter 3
Power System Scripting
The topics of this chapter are threefold. The first topic is to find the most adequate scenario for a didactic and research-oriented programming environment (Section 3.1). With this aim, the concepts of open and closed software as well as the di erences between traditional programming and scripting are introduced and discussed (Sections 3.2 and 3.3, respectively). The second topic is to describe the minimal features that a computer language should have to be suitable for power system analysis and simulation (Section 3.4). Comparisons among various modern programming languages commonly used in computational science is given. Finally, the chapter introduces the Python programming language and provides a complete simple example of modular application implemented in this language (Section 3.5).
The main thread of this chapter is that a computer language is not only a mean for translating mathematical formulæ into a computer-readable format. Rather, each computer language provides a particular “way of thinking”. The choice of the computer language is thus more a philosophical issue than a technical one.
3.1Open and Closed Programming
In a theoretical scenario, the steps to follow for studying the behavior of a power system are (i) to establish the model, (ii) to set up equations and (iii) to implement on a computer the resulting system using a suitable solution algorithm (see also Figure 1.3 of Chapter 1). This process is actually quite rare in practice, at least in what concerns standard analyses such as the solution of the power flow problem or time domain integrations. Students and, sad to say, even some researchers, often use a closed software package for solving the assigned problem. This scenario is illustrated in Figure 3.1.
In this context, the term closed refers to the lack of freedom to modify the source code of a certain software package. In this sense, commercial products
F. Milano: Power System Modelling and Scripting, Power Systems, pp. 31–58. springerlink.com c Springer-Verlag Berlin Heidelberg 2010
32 |
3 Power System Scripting |
Physical system
Data |
Adjustments |
|
Closed |
|
software package |
Fig. 3.1 Approach for studying a physical system based on a closed software package
are generally closed. However, also freely-distributed projects1 can be closed at practical e ects if the source code is not provided or, if provided, is too complicated to be mastered in a reasonable time. As it can be promptly observed, closed software packages embed and mask the most interesting parts, i.e., the modelling and computer implementation phases.
There are at least two important drawbacks in this approach. The first one is that the user has to accept the hypotheses and simplifications used by the authors of the software package. The other one is that the user often ignores the hypotheses and simplifications used by the authors of the software package. A byproduct drawback is also the absent or reduced possibility of modifying the equations and of replacing the algorithms used by the software package.
Clearly, the main advantage of using a closed software packages is to save time. For well-assessed and repetitive operations, such as most industry applications, it is also the correct approach. On the other hand, the educational weakness of closed software is evident. The user gives up the possibility of thinking in exchange for setting up input data and adjustments (e.g., software parameter settings). It has to be noted that setting up a set of data without having the control or the full knowledge of the model can lead to unpredictable results.
In any case, the approach illustrated in Figure 3.1 should be avoided as much as possible at least in the academic environment, since it promotes two dangerous habits: (i) to consider the implementation phase a non-relevant step of the study, and (ii) to accept acritically the model provided by the closed software application. The latter habit is in antithesis with the correct academic approach.
1The expression open source is widely used for defining a software application or library whose code is available to the final user. If the user is also free to copy, modify and re-utilize the code, provided that the resulting application remains open and free, the project pertain to the family of free and open source software (FOSS). Further details on this topic can be found in Chapter 23.
3.2 Scripting |
33 |
It has to be said that in most branches of engineering the approach depicted in Figure 3.1 is not so common as it is in power system analysis. This likely happens because, in power systems analysis, setting up the power flow problem and the transient analysis for a general system composed of an arbitrary number of buses, connections and devices implies the implementation of a considerable amount of code that accomplishes ancillary tasks (e.g., data parsing) and is not strictly related to power system analysis (see Section 2.4 of Chapter 2). Thus, using a closed software package is an easy shortcut that allows the students focusing on theoretical concepts more than on programming issues.
This book attempts to demonstrate that programming issues are not insuperable and actually help assimilate theoretical aspects. The proposed approach for studying a physical system is shown in Figure 3.2. In this figure, the open software package stands either for a self-made application or an available open source project that can be easily mastered and modified by the user. Of course, implementing the whole software package could result an overwhelming task for the average student. But, according to this approach, it is not necessary that the user implements the whole architecture, just a limited set of modifications, extensions, add-ons or plug-ins. If the extensions are worth, these can be used by others and the project grows up.
Actually, this approach is not new. It is the philosophical basis of the free and open source software community [292] and has proved to work well, at least for projects like Linux, Apache, LATEX, Python, etc. Chapter 23 discusses these concepts and attempts to explain why the open source philosophy catches on with great di culty in the power system community.
3.2Scripting
In the previous section, the word programming is used for indicating the activity of writing computer code. The primary purpose of this section is to clarify the di erences between two available approaches for computer programming, namely traditional programming and scripting. The second purpose of this section is to explain why the scripting approach is adopted in this book.
Traditional programming or system programming consists in the construction of a self-contained, stand-alone, typically complex and monolithic computer application.
Scripting or simply programming consists in the production of typically small fractal applications that get advantage of other existing packages to provide new functionalities.
The following remarks are useful to better explain the conceptual di erences between traditional programming and scripting.
1.Languages that are suitable for traditional programming projects are typically C, C++, Java, C# and Scala. For engineering applications,
34 |
3 Power System Scripting |
Physical system
Hypotheses
Model 
&
Simplifications
|
Equations |
|
|
Available |
|
Data |
algorithms |
|
|
|
|
|
|
Adjustments |
|
Numerical |
Open |
|
|
|
|
solution |
software package |
|
|
Fig. 3.2 Proposed approach for studying a physical system based on an open software package
FORTRAN (in any available versions, namely, 77, 90/95 and 2003) is also quite popular.
2.Languages commonly used for scripting are, for example, Perl, Python, Php, Tcl and Ruby. In the engineering world, high abstraction level languages such as R, Matlab, Mathematica and Octave are popular choices. The learning process of these languages is much faster than that of C, C++, Java and FORTRAN.
3.Traditional programming is oriented almost exclusively to the application and not to the re-usability of the code. However, one could do scripting also using C or FORTRAN. In the same vein, one could use Perl for a large project, although this would not likely be a good choice. The key point is that the di erence between scripting and traditional programming does not concerns necessarily the computer language.