Учебники / 0841558_16EA1_federico_milano_power_system_modelling_and_scripting

Integration Method: There is huge variety of numerical integration methods. Explicit methods such as Runge-Kutta’s formulæ are well suited for nonsti ODE systems. However, transient stability analysis concerns the integration of a nonlinear and generally sti DAE systems. In this case, the most adequate methods are A-stable implicit and semi-implicit methods such as the implicit trapezoidal method or Rosenbrock’s formulæ.

Step Length: The step length Δt can be fixed or variable. Implicit A-stable numerical methods allow relatively large step length without loosing accuracy. The step length has to take into account the time constants of the system. With this aim, an eigenvalue analysis for the initial value can provide information about the time scales of the system.

Disturbance: Typical disturbances for transient stability analysis are shortcircuit and device outages. However a general routine for time domain analysis has to be able to support any user-defined disturbance. The latter can be easily obtained if using an open-source tool based on a scripting language.

Stop Criterion: When dealing with contingency analysis, it is important to save time by stopping the numerical integration routine if the trajectories are surely stable or unstable. Monitoring the maximum synchronous machine rotor angle di erence provides such information. The SIME method provides su cient instability conditions and necessary stability ones based on the computation of an equivalent OMIB system at each time step.

Part III

Device Models

Chapter 9

Device Generalities

This chapter is about modelling and scripting of general purpose devices. Section 9.1 defines the mathematical model of an as general as possible device, while Section 9.2 provides the conceptual basis for implementing a device as a class. Subsection 9.2.1 presents a Python example of a base device class, while Subsection 9.2.3 provides an example of specific device methods, namely the two-axis model of the synchronous machine.

9.1General Device Model

Chapter 8 defines a general power injection model, as follows:

Each device is a subset of equations (9.1)-(9.3). In particular, for each device, one can define a certain set of di erential equations f i f and algebraic equations gˆi gˆ. Moreover, if the device is connected to a network bus, say bus h, the element h of the vector s¯ contains the power injection of the considered device. In general, there can be more than one device connected to the same bus. Thus, the element h of the vector s¯ is obtained as the sum of the contributions of each device connected to the bus h. Similarly,

all powers injected to branches (e.g., transmission lines and transformers) connected to bus h.

According to the discussion above, equation (9.3) can be rewritten as:

connected to bus h, and B is the set of buses. Further generalizing (9.4),

F. Milano: Power System Modelling and Scripting, Power Systems, pp. 221–246. springerlink.com c Springer-Verlag Berlin Heidelberg 2010

i.e., considering also transmission lines and transformers as devices that inject powers at buses, leads to:

i Ωh

where Ωh ˆh Ch = Ω .

A similar equation holds for node current balance equations of dc devices:

where ih,i is the current injected at node h by device i, Ωdc,h is the set of all dc devices connected to node h, and N is the set of nodes of the dc network.

In conclusion, the most general model of an ac device is as follows:

where the sub-index i indicates internal device variables and equations and

the sub-index e indicates external variables shared with other devices. Hence, x = [xTi , xTe ]T and yˆ = [yˆTi , yˆTe ]T . In (9.7), complex voltage phasors v¯ are split into magnitudes v and phase angles θ. A similar general model can be

defined for dc devices.

Typical device models satisfy the following conditions:

1.The vector of state variables x can be divided into internal device variables, say xi, and external ones, say xe. If xi Rnxi , then f i has to map to Rnxi .

2.The vector of algebraic variables yˆ can be divided into internal device

variables, say yˆi, and external ones, say yˆe. If yˆi Rnyi , then gˆi has to map to Rnyi .

3.If the device is connected to ni buses, then both gp,hi and gq,hi have to map to Rni .

If all devices satisfy these rules, then the complete system (9.1)-(9.3) is well defined, i.e., the number of state variables is equal to the number of di erential equations and the number of algebraic variables is equal to the number of algebraic equations. However, the rules above are only su cient conditions for obtaining a consistent DAE system. As long as f : Rnx ×Rny ×Rnη → Rnx and g : Rnx × Rny × Rnη → Rny , it is not necessary that each device strictly follows these rules.

Finally, in (9.7), it is implicitly assumed that the device depends on a set of parameters, say a, which characterize the behavior of the device itself. By default, parameters a are constant.

Example 9.1 Two-Axis Synchronous Machine Model

Consider the two-axis synchronous machine model that is formally deduced in Chapter 15. According to the notation introduced in (9.7), the machine DAE can be subdivided as follows:

where:

1. The state variables are x = xi = [ed, eq , δ, ω]T and xe = [].

2.The algebraic variables are yˆ = yˆi = [id, iq , vd, vf , vq , τe, τm]T and yˆe = [].

3.The bus voltage is v¯h = vh θh.

4.The controllable variables are η = [vf 0, τm0]T .

5.The constant parameters are a = [D, H, ra, Td0, Tq0, xd, xd, xq , xq , Ωb, ωs]T .

Observe the use of the trivial equations for assigning the mechanical torque τm and the field voltage vf . Using such dummy algebraic equations is a common practice that allows easily interfacing devices. For example, the mechanical torque τm0 can be set as the output of a turbine governor and the field voltage vf 0 can be set as the output of an automatic voltage regulator (see also Chapter 16).

9.1.1Initialization of Device Internal Variables

As discussed in Chapter 4, the solution of the power flow problem provides an operating point, i.e., voltage phasors and complex power injections at each node of the network. Since the standard power flow analysis does not contain dynamic models, the calculation of the equilibrium point (x0, y0) requires a specific routine for dynamic devices.

Example 9.2 Initialization of the Synchronous Machine

Two-Axis Model

To clarify the procedure for initializing state variables, consider the synchronous machine two-axis model of the previous Example 9.1. The set of equations for initializing the two-axis model of the synchronous machine are (see also Section 15.1):

0= (τm − τe − D(ω − ωs))/2H

0= (vq + raiq )iq + (vd + raid)id − τe

0= vdid + vq iq − p0

0= vq id − vdiq − q0

0= −eq − (xd − xd)id + vf

0= −ed + (xq − xq )iq )

0= (vd + raid)id + (vq + raiq )iq − τe

0= vq + raiq − eq + xdid

0= vd + raid − ed − xq iq

0= v0 sin(δ − θ0) − vd

0= v0 cos(δ − θ0) − vq

where v0, θ0, p0 and q0 are the input variables as obtained from the power flow solution and ed, eq , δ, ω, id, iq , vd, vf , vq , τe, τm, τm0, vf 0 are the quantities to be initialized. In this case, (9.10) have an explicit solution, as

follows. The rotor angle δ can be obtained as:

pe0 = (vq0 + raiq0)iq0 + (vd0 + raid0)id0 eq0 = vq0 + raiq0 + xdid0

ed0 = vd0 + raid0 − xq iq0 vf 0 = eq0 + (xd − xd)id0

˙

Finally, in order to impose δ = 0, it must be:

i.e., the machine speed is synchronous at the initial equilibrium point. This

˙

is a consequence of using a fictitious synchronous reference for δ. The latter condition leads to

that completes the initialization of the synchronous machine two-axis model.

9.2Devices as Classes

In computer programming, a class is a complex type that contains a variety of properties, namely attributes (e.g., data and settings) and methods (e.g., functions and procedures). Class attributes are, in some aspects, similar to Leibniz’s monads, since attributes are entities of irreducible simplicity.1 Class methods operates on attributes and allows devices interacting with the rest of the program. Thus, unlike monads, class methods do communicate with the rest of the world.

When designing a project based on classes one has to have clear that there is a distinction between the code that implements a certain class and the instances of that class. The code that implements the class is an abstract structure that only defines a new type and states how that new type behaves. On the other hand, an instance of a class is a specific variable whose behavior is defined by the class definition. While the class is unique, there can be any number of class instances. Using a human language analogy, a class is similar to a grammatical object, such as the noun, the verb, the adjective, etc. Words are similar to instances of some grammatical object. For example, script is an instance of the class noun.

Given this premise, we are interested in defining power system devices as classes. Before proceeding with the definition of classes, there is an important decision that has to be taken. There are two possibilities for implementing such device classes (see Figure 9.3).

1.To create an instance for each device defined in the system. In this case, the interface class that coordinates the functioning of all devices2 will handle series (or arrays) of class instances.

2.To create an unique instance for each group of devices of the same kind. In this case, the interface class that coordinates the functioning of all devices will handle series of class methods of each device. Each method will internally work on an array of elements of the same device.

At a first glance, these two approaches above may seem equivalent, although, probably, the most intuitive is the first one. In fact, considering again the analogy with human languages, the nouns that are contained in a dictionary

1Actually, class attributes may be instances of other classes, but this possibility is not used in this chapter.

2For a definition of this class see Script 3.2 of Chapter 3.

Fig. 9.3 Instancing approaches for device classes: (a) one instance per each physical device, and (b) unique instance per device type

are each one an instance of the grammatical object noun. This corresponds to the creation of an instance for each device of the class, say, PQ load. According to this approach, whenever the bus power balance (9.5) is computed, one has to look for each instance of the PQ load class and the method that computes the bus power balance has to be called for each one of these instances. The second approach declares only one instance of the PQ load class. Thus, it su ces to call the method for computing the bus power balance only once if PQ loads are defined in the system. The PQ load method internally iterates over each element and computes (9.5).

There is an important di erence between iterating over class instances or over elements of a class. In the latter case, operation can be made vectorially since the elements can be grouped into matrices or vectors. When using scripting languages, avoiding explicit for-loops always allows saving CPU time. Thus, for scripting languages, the second approach has to be preferred. For example, in Python, built-in vectorial operations of NumPy arrays or of CVXOPT matrices are by far more e cient than operating over lists or tuples using for loops [164]. On the other hand, system programming languages are not a ected by explicit for-loops. Thus, the first approach is also a valid alternative [287]. However, the risk of the first approach is to create a high fragmentation of the information. In fact, for a system with several thousands of devices, there are several thousand of class instances on which operate. In the second approach, since the number of device types is never really high, the program has to handle only a reduced number of class instances. Thus, the second approach should be preferred independently from the programming language adopted.

Assuming that each class has only one instance, the second question that might arise is whether it is really necessary to define a class for each device or if it is better to use some other programming technique (e.g., modules or simple functions). At this regard, it su ces to observe that some properties are