An Open-Source Julia Package for RMS Time-Domain Simulations of Power Systems

Abstract

This paper presents RMSPowerSims.jl, an open-source Julia package for the time-domain simulation of power systems. The package is designed to be used in conjunction with PowerModels.jl, a widely used Julia package for power system optimization. RMSPowerSims.jl provides a framework for the simulation of power systems in the time domain, allowing for the study of transient stability, frequency stability, and other dynamic phenomena. The package is designed to be intuitive and flexible, allowing users to easily define custom models for network components and disturbances, while also providing a range of pre-constructed models for common power system components. RMSPowerSims.jl simplifies the process of performing RMS simulations on power system models developed using the PowerModels.jl ecosystem, and provides an easy-to-use modeling that reduces the barrier to entry for new users wishing to perform RMS simulations. The accuracy of the package is verified against DIgSILENT PowerFactory for short-circuit and load-increase disturbances, using the New England 39-bus system. The active power generation delivered by several generators in the network, and the voltage magnitudes of selected busbars are analyzed and noted to be in close agreement with those obtained using PowerFactory. The computational performance of the package is compared to that of PowerFactory and is found to be comparable for load-step simulations; however, PowerFactory is found to be considerably faster for short-circuit simulations. As computational performance is not a priority at this stage of development, this is expected, and speed optimization is planned for future work. RMSPowerSims.jl is available under an open-source license and can be downloaded from GitHub.

1. Introduction

Power grids across the globe are presently undergoing a transition away from fossil-fueled electricity generation towards renewable energy generation (REG). The variable nature of REG, the decentralization of generation, and the introduction of large numbers of inverter-based generators (IBGs) in the form of solar photovoltaic and wind generation mark significant differences from the traditional synchronous generator-dominated power systems [1]. As a result, the development of new tools for power system analysis, operation, and planning is critical to maintain reliable and stable operation in modern power systems. For example, electromechanical root mean square (RMS) simulations, which have historically been used to analyze the dynamic behavior of the power grid, are unable to capture some of the fast dynamics of IBGs. As a result, the need for electromagnetic transient (EMT) simulations, which operate with much smaller time steps, and associated grid models has become more prevalent [1]. This being said, RMS simulations remain applicable in some areas of power system stability analysis due to the computational expense of EMT simulations [2]. This is most prevalent in studies relating to frequency and angular stability, where the reduction in grid inertia resulting from an absence of synchronism is significant. Regarding scheduling and the dispatching of generation, new optimal power flow (OPF) formulations are needed that can account for the stochastic nature of renewable generation, and the growing impact of distributed energy resources [3,4].

Commercial software packages, such as DIgSILENT PowerFactory [5] and PSS/E [6], are commonly used throughout industry for the steady-state and dynamic analysis of power systems, and PSCAD/EMTDC [7] is commonly used for EMT simulation [8]. Open-source software tools are, however, becoming increasingly popular amongst academics and researchers due to their ability to be modified and extended to suit the needs of the user, and the lack of prohibitively expensive licensing fees. In recent years, the Julia programming language has seen a range of power system-related tools developed [9,10,11,12,13]. The reasoning for the selection of Julia for these developments is due to its high performance, comparable to that of low-level programming languages such as C and C++, while maintaining a high-level syntax that is easy for a user to understand. As a result, a suite of state-of-the-art solvers for differential equations, optimization, and linear algebra are available in Julia, making it an ideal language for developing power system analysis tools.

The collection of packages developed by the National Renewable Energy Laboratory (NREL) provides a modeling architecture for modern power grids [9], including a quasi-static simulation package as in [10] and dynamic simulation package suitable for both electromechanical and electromagnetic transient simulation as in [11]. The complexity of this ecosystem does, however, result in a steep learning curve for new users, especially those with little prior programming experience. PowerDynamics.jl provides an alternative option for users who wish to perform dynamic simulations of power systems; however, the implementation of the package models the generators, loads, and inverters as nodes in a graph rather than as components connected to a node. This is a departure from the traditional power system modeling approach as is used in DIgSILENT PowerFactory [5] and PSS/E [6]. The approach is suitable for some research applications and has been shown to be highly performative [12] but is restrictive, in that it requires bespoke models if multiple components are connected to a single node. Additionally, for initialization purposes, it is practical to define a node as a slack bus; however, doing so requires that the dynamics of the generator at that slack bus must be omitted from a given model, which is unrealistic and not always acceptable.

The PowerModels.jl package provides a power system modeling framework, with the aim of facilitating the easy comparison of OPF formulations and is the only Julia package known to the authors capable of solving AC OPF problems. Substantial work has been performed in implementing large, synthetic models of Australia’s National Electricity Market in the PowerModels.jl format, and it would be beneficial to be able to build on these models for dynamic simulation; however, this functionality is not supported by PowerModels.jl [14,15]. It is possible to convert from the PowerModels.jl network data dictionary (NDD) format to a format which can be used with software, either commercial or open-source, that is capable of dynamic simulation. In particular, the ability to import and export steady-state network models in the MATPOWER case file format [16] is commonly supported by open-source power system simulation packages. However, in the experience of the authors, the process of implementing a power system in multiple software programs is time consuming, requires verification to ensure that the models are equivalent, requires maintaining two separate representations of the same system, and often requires an in-depth knowledge of both the source and destination program/format. It is, therefore, preferable to build on an existing model rather than reconstructing it in a different format. For this reason, this paper presents the development of a Julia-based simulation package, known as RMSPowerSims.jl, that is capable of performing dynamic simulations using the existing PowerModels.jl model package from Julia.

In consideration during the development of RMSPowerSims.jl is the fact that the scope of the energy transition requires a new generation of power system engineers to be trained in the use of power system analysis tools, and to be capable of addressing the research gaps. Currently, there is a gap in the freely available open-source tools for power system education when it comes to dynamic simulation. MATPOWER is commonly utilized in tertiary education programs for steady-state analysis and power flow studies but does not provide a toolbox with dynamic simulation capabilities. PowerSimulationsDynamics [11] provides a flexible and performative dynamic simulation package; however, the level of programming experience required to use the package is high and, as a result, is not ideal for less experienced users. For this reason, RMSPowerSims.jl aims to provide an easy-to-use interface, intuitive for power system simulation, without making compromises to performance or accuracy.

The advantages of RMSPowerSims.jl are as follows:

• Simplification of the process of performing RMS simulations on power system models developed using the PowerModels.jl ecosystem;
• A flexible modeling framework that allows for the inclusion of a wide range of power system components and disturbances;
• Pre-constructed models of common power system components, such as synchronous generators, loads, and common generator control systems, that can be used to build models of power systems;
• A simple, easy-to-understand programming interface that is suitable for power system education.

The remainder of this paper is organized as follows: Section 2 discusses the overall structure of the new RMSPowerSims.jl package, Section 3 examines the process of running a simulation and provides a detailed overview implementation of the package, Section 4 presents a verification process of the package using the 39 Bus New England System and examines the computational performance of the package [17] and DIgSILENTs PowerFactory, and Section 5 provides conclusions and outlines future work.

2. RMSPowerSims.jl

This section provides details relating to the modeling structures of RMSPowerSims. The high-level control flow, and the data structures used to define the network model are discussed in Section 2.1. The hierarchical software object type structure used to define individual power system components is discussed in Section 2.2. Details of some specific component models that have been implemented are provided in Section 2.3, and the disturbance simulation is discussed in Section 2.4. An overview of the package functionality is provided in Section 2.5. The package documentation [18] provides specific details relating to the data model; the parameter definitions and underlying equations for the component models; disturbance implementation; function definitions; and the simulation process.

It is important to note that RMSPowerSims.jl is built on top of a number of other Julia packages. The most significant dependencies, within the context of this paper, are PowerModels.jl [13], which provides the basis for the data structure used to model the system and is used for steady-state analysis, and DifferentialEquations.jl [19], which is used to solve the differential equations that characterize the system dynamics. Additionally, the default solver used by the package is the IDA solver [20] from the Sundials suite [21]; however, users are free to choose a different, suitable solver if desired. The full list of dependencies and their functions within the package is shown in Appendix B.

2.1. High-Level Package Structure

To provide an overview of the intended use of the package, the procedure of preparing a model and running a simulation is shown in Figure 1.

The primary data structure used for storing network data is an extension of the PowerModels.jl NDD format [13]. The NDD is an augmented version of the MATPOWER case file format [16], with the significant difference being the addition of dedicated fields for loads and shunt components. Any existing, valid, Julia-based PowerModels.jl model must contain all the necessary information for steady-state analysis. For time-domain simulation, additional parameters and modeling details are required that specify the dynamical behavior of the components of the network. RMSPowerSims.jl is configured in such a way that RMSPowerSims.jl NDD is an extension of the PowerModels.jl NDD.

The Julia package DifferentialEquations.jl [19] is used to formulate the differential-algebraic equation (DAE) problem that characterizes the power-system dynamics. Passing the entire PowerModels.jl NDD to the differential equation solver would be inefficient, as only a subset of the data contained in the dictionary is required to define the dynamic model of the system. Accordingly, a bespoke data structure is defined that contains only the data required for the time-domain simulation, referred to as a PowerSystemSimulation object. At this point, it is worth briefly outlining how a differential-algebraic equation problem is formulated in DifferentialEquations.jl, as a cursory understanding is necessary to explain the structure of the PowerSystemSimulation object and its components. A general DAE problem passed to the DifferentialEquations.jl package can be expressed as a function in the form

$$out=DAE\_function(u,du,p,t)$$

(1)

where u is a state vector containing the state and algebraic variables of the system, $du$ is a vector containing the derivatives of the state variables, p is an object containing the non-time-varying parameters of the system, t is the time, and $out$ is a vector containing the residuals of the differential and algebraic equations. The body of code in the $DAE\_function$ is where the equations that define an arbitrary dynamical system are implemented. Since a power system is an example of a DAE-type system, it is possible to directly implement the equations that define the system in this form. However, due to the size and complexity of modern power systems, it is more practical to define the equations in a modular form, with each component of the system representing a functional module that has its own parameters and equations. These function modules can then all be called from a single main function that assembles the equations of the entire system. Algorithm 1 shows a pseudo-code representation of how this process is implemented in RMSPowerSims.jl, where $u^{\prime }$, $d{u}^{\prime }$, and $ou{t}^{\prime }$ are the subsets of the u, $du$, and $out$ vectors that are necessary for the implementation of the component model, and $model$ is a custom typed object that contains the parameters of the component model. This custom typing is important, as it allows for the use of Julia’s type-based multiple dispatch capabilities. Multiple dispatch in Julia allows for the definition of multiple methods for a given function, with the method that is called being determined by the types of the arguments passed to the function [22]. In the context of RMSPowerSims.jl, this allows the solver to identify which moduar $DAE\_function$ should be applied, depending on the type of the $model$ parameter. This type is defined within a hierarchical typing structure, with the supertype defined as ComponentModel. The type hierarchy and the existing sub-types defined are discussed further in Section 2.2.

Algorithm 1 Power system equations.

function power_system_equations!($out$, $du$, u, p, t) for each $component\_model$ in $power\_system\_model$ do    $ou{t}^{\prime }$ = DAE_Function($d{u}^{\prime }$, $u^{\prime }$, $model$, t) end for end function

With an understanding of how the equations of the system are implemented in the RMSPowerSims.jl package, it is now possible to discuss the structure of the PowerSystemSimulation object passed to the solver, and its components. A dictionary tree representation of the PowerSystemSimulation object is shown in Listing 1. For brevity, the diagram does not show the full structure, only those parts which are necessary for the explanation of the structure. The actual implementation can be found in the package documentation [18].

As can be seen in Listing 1, the PowerSystemSimulation object has a tiered structure and contains several other custom data objects. The top level of the structure contains a PowerSystemModel object, the initial conditions of the simulation, and a list of any disturbances that occur during the simulation. Disturbance handling and calculation of the initial conditions are discussed in Section 2.4 and Section 3, respectively. The design philosophy is that the PowerSystemModel object is intended to contain all of the data required to define the dynamic model of the system, independent of any state of the system. In contrast, the PowerSystemSimulation object contains only those details related to a given simulation and corresponds to a specific state and trajectory of the system. The PowerSystemModel object is defined with two distinct lists. The variable list contains the uniquely defined names of all state and algebraic variables used to define the model, including the names of any derivative quantities required to implement the component models. The component list contains the ComponentModel objects and the pointers to the variables required for the simulation of each component. There is a one-to-many relation between the component list and the variable list.

Listing 1. Simulated dirtree within listing.
1	PowerSystemSimulation
2	|--	PowerSystemModel
3	|	|--	Component List
4	|	|	|--	ComponentModel 1 & Pointers
5	|	|	|--	ComponentModel 2 & Pointers
6	|	|	|--	...
7	|	|	‘--	ComponentModel n & Pointers
8	|	‘--	List of State & Algebraic Variables
9	|--	Initial Conditions
10	‘--	Disturbances
11	|--	Disturbance 1
12	|--	Disturbance 2
13	|--	...
14	‘--	Disturbance n

2.2. Component Models and Typing

A hierarchical typing system is used to classify, and differentiate among, the various components of the model. The models for each component sit at the bottom of this hierarchy, and are implemented as what is referred to in the Julia programming language as a concrete type, i.e., a type that can be instantiated. It is this lowest level of the hierarchy that is used to identify the correct method of a given RMSPowerSims.jl function to apply to a given component, using Julia’s multiple dispatch.

During the process of solving the differential equations, a system is fully defined by instances of concrete-typed component models and their corresponding DAE_functions. That is to say that all components in the system are treated in the same manner by the solver, and the hierarchical type structure of the PowerSystemModel is irrelevant. The need for supertypes arises when configuring the ystemSimulation object and calculating the initial conditions. The hierarchy of supertypes defined in the package is shown in Figure 2. As can be seen in Figure 2, all component models are sub-typed from the ComponentModel type. The next level of sub-types classifies components as either a generator, controller, node, or load model. Conveniently, this classification aligns with the definitions already used in the PowerModels.jl NDD, with the exception of controller models, which are not included in PowerModels.jl. The reasoning for this classification, however, arises from the structure of the network equations. The power balance form of the network equations for bus i are expressed as

$$0=\sum _{j\in G_i}{P}_{gj}-\sum _{l\in L_i}{P}_{dl}-\sum _{k\in B_i}\left|V_i\right|\left|V_k\right|\left|Y_{ik}\right|cos({\theta }_i-{\theta }_k-{\alpha }_{ik})$$

(2)

$$0=\sum _{j\in G_i}{Q}_{gj}-\sum _{l\in L_i}{Q}_{dl}-\sum _{k\in B_i}\left|V_i\right|\left|V_k\right|\left|Y_{ik}\right|sin({\theta }_i-{\theta }_k-{\alpha }_{ik})$$

(3)

where we have the following:

• i is the index of the bus for which the power balance is being calculated;
• j is the index for generators connected to bus i;
• l is the index for loads connected to bus i;
• k is the index for summation over all buses in the network;
• $G_i$ is the set of generators connected to bus i;
• $L_i$ is the set of loads connected to bus i;
• $B_i$ is the set of buses in the network with branches connecting to bus i;
• $V_i,V_k$ are the voltage magnitudes at buses i and k, respectively;
• ${\theta }_i,{\theta }_k$ are the voltage phase angles at buses i and k, respectively;
• $P_{gj},Q_{gj}$ are the real and reactive power injections of generator j;
• $P_{dl},Q_{dl}$ are the real and reactive power demands of load l;
• $Y_{ik}$ is the magnitude of the admittance between buses i and k;
• ${\alpha }_{ik}$ is the phase angle of the admittance between buses i and k.

The interpretation of these equations is that the dynamics of the generators and loads in the system are coupled through the power injection terms in the network equations. The definition of the generator and load supertypes is motivated by the need to ensure that the power injection terms $P_{gj}$, $Q_{gj}$, $P_{dl}$, and $Q_{dl}$ are defined; otherwise, this coupling would not be possible. As such, it is enforced by the RMSPowerSims.jl package that all generators must include variables $P_{gj}$ and $Q_{gj}$, all loads must include variables $P_{dl}$ and $Q_{dl}$, and that all power injection variables must be expressed on a common per-unit base. $P_{dl}$ and $Q_{dl}$ are defined as having positive values for positive demand to be consistent with the conventions used in PowerModels.jl. The definition of separate supertypes for generators and loads allows for this difference in polarity, and also provides an intuitive distinction between the two types of components.

It is worth noting that it is also possible to couple the generators and loads through current injections, where the nodal algebraic equations represent a real and reactive current, rather than real and reactive power [23]. This formulation is mathematically equivalent, and often viewed to be programmatically simpler; however, the power-balance form has been chosen, as it is more intuitive and removes the need for additional equations to account for power injections. Extension of the package to include current injections, to allow alternative definitions of generators and loads, is in the scope of future work for the package.

The ControllerModel supertype is defined to allow for the inclusion of external generator controllers, such as automatic voltage regulators (AVRs) and governors for synchronous machines. A given instance of a ControllerModel object is implemented as a functional module that is distinct from the functional module of the generator it is connected to. It is during the process of configuring the ystemSimulation object that the pointers are configured so that both the controller and the generator module point to the coupling variables. In the formulation of RMSPowerSims.jl presented in this paper, a ControllerModel can only be connected to a GeneratorModel and not to a LoadModel. This is a logical restriction for a traditional power system, where generators are typically controllable, while loads are not. However, considering the increasing prevalence of demand-side management, the authors note the utility of extending the package to allow for the modeling of controllable loads, and as such is in the scope of future work.

The lower-level supertype SynchrounousGeneratorModel is defined as a sub-type of the GeneratorModel, and the lower-level supertypes AVRModel and GovernorModel are defined as sub-types of the ControllerModel. This is to allow synchronous generators to be modeled either with or without AVR and turbine-governor models. The parameters that are controlled by the AVR and governor, the excitation voltage and mechanical torque, respectively, are necessary for the modeling of a synchronous generator; however, it is common to model them as constant in a simplified model. To allow for this, during the process of configuring the ystemSimulation object, the package checks whether a controller of type AVRModel or GovernorModel is defined, and if not, a ConstantExcitation or ConstantMechanicalPower model is automatically added.

2.3. Implemented Component Models

Component models implemented for the IEEET1 type excitation system [24] the TGOV1 thermal governor [25] remain largely unchanged from their source material. The only differences are the omission of the over/underexcitation limiter inputs from the IEEET1, as those systems have yet not been implemented in the developed package, and the omission of the turbine damping branch in the TGOV1, as this is commonly neglected. Component models for constant excitation and constant mechanical power inputs to a synchronous machine model are also available; however, these are not discussed here, as their implementation is trivial.

A static ZIP load model is included, with the governing equations shown below:

$$P_d=P_{d0}\left(K_{pz}{\left({\displaystyle \frac{V}{V_0}}\right)}^2+K_{pi}\left({\displaystyle \frac{V}{V_0}}\right)+K_{qc}\right)$$

(4)

$$Q_d=Q_{d0}\left(K_{qz}{\left({\displaystyle \frac{V}{V_0}}\right)}^2+K_{qi}\left({\displaystyle \frac{V}{V_0}}\right)+K_{qc}\right)$$

(5)

where V is the voltage magnitude of the connected bus, and $P_{d0}$, $Q_{d0}$, and $V_0$ are the initial values of the active power injection, reactive power injection, and voltage magnitude of the connected bus, respectively. The initial values are parsed from the load flow solution. The parameters $K_{pz}$, $K_{pi}$, $K_{pc}$, $K_{qi}$, $K_{qz}$, and $K_{qc}$ are the ZIP load parameters, and must satisfy the conditions

$$K_{pz}+K_{pi}+K_{pc}=1,\mathrm{and}{K}_{qz}+K_{qi}+K_{qc}=1.$$

A sixth-order synchronous machine model based on the model presented in [23] is implemented. Some modifications are made to account for the dependence of the electrical torque on the rotor speed as can be seen in the speed ratio terms in (11)–(13). This dependence is necessary for simulations of small systems, where the rotor speed deviates significantly from the synchronous speed during a disturbance [26]. If it is required that the effects of the rotor speed variation be neglected, these ratios are simply replaced by one. The differential equations of the model, as it is implemented in the package, are given in (6) through (11); the stator voltage equations are given in (12) and (13); and the generator power injections to the network are given in (14) and (15):

$$\begin{array}{c}\hfill \dot{E_q}{T}_{do}^{\prime }=-E_q-(X_d-X_d^{\prime })\left(I_d-\left({\displaystyle \frac{X_d^{\prime }-X_d^{\prime \prime }}{{(X_d^{\prime }-X_l)}^2}}\right)({\psi }_{1d}+(X_d^{\prime }-X_l)I_d-Eq)\right)+E_{fd}\end{array}$$

(6)

$$\begin{array}{c}\hfill \dot{E_d}{T}_{qo}^{\prime }=-E_d+(X_q-X_q^{\prime })\left(I_q-\left({\displaystyle \frac{X_q^{\prime }-X_q^{\prime \prime }}{{(X_q^{\prime }-X_l)}^2}}\right)({\psi }_{2q}+(X_q^{\prime }-X_l)I_q+E_d)\right)\end{array}$$

(7)

$$\begin{array}{cc}\hfill {\dot{\psi }}_{1d}{T}_{do}^{\prime \prime }& =-{\psi }_{1d}+E_q-(X_d^{\prime }-X_l)I_d\hfill \end{array}$$

(8)

$$\begin{array}{cc}\hfill {\dot{\psi }}_{2q}{T}_{qo}^{\prime \prime }& =-{\psi }_{2q}-E_d-(X_q^{\prime }-X_l)I_q\hfill \end{array}$$

(9)

$$\begin{array}{cc}\hfill \dot{\delta }& =2\pi f_{\mathrm{nom}}(\omega -{\omega }_{\mathrm{ref}})\hfill \end{array}$$

(10)

$$\begin{array}{cc}\hfill \dot{\omega }\left({\displaystyle \frac{2H}{{\omega }_s}}\right)& =T_m-\left({\displaystyle \frac{{\omega }_s}{\omega }}\right)\left(V_d{I}_d+V_q{I}_q+R_s\left(I_d^2+I_q^2\right)\right)\hfill \end{array}$$

(11)

$$\begin{array}{c}\hfill 0=Vsin(\delta -\theta )+R_s{I}_d+\left({\displaystyle \frac{\omega }{{\omega }_s}}\right)\left(-X_q^{\prime \prime }{I}_q-\left({\displaystyle \frac{X_q^{\prime \prime }-X_l}{X_q^{\prime }-X_l}}\right)E_d+\left({\displaystyle \frac{X_q^{\prime }-X_q^{\prime \prime }}{X_q^{\prime }-X_l}}\right){\psi }_{2q}\right)\end{array}$$

(12)

$$\begin{array}{c}\hfill 0=Vcos(\delta -\theta )+R_s{I}_q+\left({\displaystyle \frac{\omega }{{\omega }_s}}\right)\left(X_d^{\prime \prime }{I}_d-\left({\displaystyle \frac{X_d^{\prime \prime }-X_l}{X_d^{\prime }-X_l}}\right)E_q-\left({\displaystyle \frac{X_d^{\prime }-X_d^{\prime \prime }}{X_d^{\prime }-X_l}}\right){\psi }_{1d}\right)\end{array}$$

(13)

$$\begin{array}{cc}\hfill P_g& =I_{d}Vsin(\delta -\theta )+I_{q}Vcos(\delta -\theta )\hfill \end{array}$$

(14)

$$\begin{array}{cc}\hfill Q_g& =I_{d}Vcos(\delta -\theta )-I_{q}Vsin(\delta -\theta )\hfill \end{array}$$

(15)

The state variables of the synchronous machine model are $E_q$, $E_d$, ${\psi }_{1d}$, ${\psi }_{2q}$, $\delta$, and $\omega$, which represent the flux in the excitation, the flux in the three damper windings, the rotor angle, and the rotor speed, respectively. $I_d$, $I_q$, $V_d$, and $V_q$ are the direct and quadrature components of the stator current and voltage, respectively. $E_{fd}$ and $T_m$ are the excitation voltage and mechanical torque, respectively, and depend on the connected control system models. ${\omega }_{ref}$ is the reference speed of the system, which is typically the speed of the reference machine, although a center-of-inertia reference is also possible. $R_s$ and $X_l$ are the stator resistance and leakage reactance, respectively. $X_d$, $X_d^{\prime }$, and $X_d^{\prime \prime }$ represent the direct-axis synchronous, transient, and sub-transient reactances, respectively. $X_q$, $X_q^{\prime }$, and $X_q^{\prime \prime }$ represent the quadrature-axis synchronous, transient, and sub-transient reactances, respectively. $T_{do}^{\prime }$ and $T_{qo}^{\prime }$ represent the open-circuit transient and sub-transient direct and quadrature-axis transient times, respectively. $T_{do}^{\prime \prime }$ and $T_{qo}^{\prime \prime }$ represent the open-circuit sub-transient direct and quadrature-axis transient times, respectively. H is the inertia constant of the machine, expressed in seconds, and ${\omega }_s$ is the nominal speed of the system in rad/s.

2.4. Disturbances

As with the modeling of power system components, the modeling of disturbances utilizes custom typing to leverage Julia’s multiple dispatch capabilities. Only a single supertype is defined in this instance, named Disturbance. The implementation of a disturbance in RMSPowerSims.jl consists of two parts: a uniquely typed disturbance object containing the parameters required to implement the disturbance, and a perturb_model! function that modifies the PowerSystemModel object.

For disturbances that do not cause significant discontinuities in the system variables, such as a small step change in load, the perturb_model! function can be implemented directly on the PowerSystemModel object used by the solver. Attempting this for disturbances that result in larger discontinuities, such as short-circuit faults, often results in the solver failing to converge. In these instances, the solver must be restarted from the time of the disturbance. The initial conditions for the new simulation are calculated from the state of the system prior to the disturbance using the following assumptions:

• The values of state variables do not change from the time of the disturbance to the time immediately following the disturbance.
• The values of algebraic variables are allowed to change instantaneously.
• The values of the derivatives of the state variables are allowed to change instantaneously.

In the current implementation of the developed package, this recalculation is performed as a two-step process. Firstly, the values of the algebraic variables are recalculated using the updated PowerSystemModel object. This calculation is handled by one of Julia’s non-linear equation solver packages [27], with the definition of equations once again being performed using type-based function overloading. A key difference between the algebraic_equations! functions called during this process and the DAE_functions used during the simulation is that the number of equations is reduced to only those required to define the algebraic variables. The second step is to recalculate the derivatives of the state variables. It is not necessary to use a non-linear solver for this process, as enough variables are defined at this stage for the direct calculation of the derivatives for each component.

It is worth noting that the two-step process for recalculating the system state is not the most programmatically succinct method. An alternative that was considered is to re-use the equations defined in the DAE_functions and simply fix the values of the state variables, treating both the algebraic variables and the derivatives of the state variables as variable quantities passed to the solver. This allows for simultaneous calculation of the algebraic variables and the derivatives of the state variables, and reduces the number of function definitions required for each component model. The reason for not selecting this approach is that it requires the solver to know which variables are state variables and which are algebraic variables. In most cases, this is simple, and can be parsed from the component models data file; however, it becomes more complex for variables that can be treated as either, depending on the simulation context. The sole example of this that has arisen in development so far is the excitation voltage of a synchronous machine, which can change depending on the presence of an excitation system. This alternative method also increases the order of the system that must be passed to the non-linear solver, which in turn increases the time taken to solve. In any case, the solution of the alternative method is identical; however, the implementation of the alternative method is an open question that may be revisited in future development.

2.5. Package Functionality

This section details the functionality of the developed package. A complete list of function implementations, their documentation, and usage examples can be found in the package documentation [18].

• The package provides a modeling framework that extends the PowerModels.jl NDD format to incorporate additional parameters required for dynamic simulation.
• Hierarchical typing allows for the definition of custom models of power system components and their incorporation into the simulation.
• The package provides functionality to calculate the initial conditions for dynamic simulations.
• The package provides functionality to execute RMS time-domain simulations.
• The package provides the ability to recalculate the system state following a disturbance that causes a significant discontinuity in the system state variables. This is necessary for some disturbances which result in significant non-linearity in the system equations.
• The package provides functionality to visualize the results of simulations using the Plots.jl package.

3. Simulation Process

This section will present a short example of how to run a simulation using RMSPowerSims.jl, in order to give an overview of what occurs during each function call. Listing 2 shows a code snippet that demonstrates how to run a simulation using RMSPowerSims.jl. The $load\_model$ function called in line 2 loads a PowerModels.jl NDD, which will be assumed in this example to already have been configured with the details needed for time-domain simulation.

The $prepare\_simulation$ function call builds the ystemSimulation object from the PowerModels.jl NDD. It is at this point that the initial conditions for the simulation are calculated. PowerModels.jl is used to solve the load flow problem required as a starting point for the initialization process; however, in principle, other alternative solvers for the static power flow solvers would be suitable. Following this, the initial values of all state and algebraic variables are calculated by the functions defined for each ComponentModel. It is worth noting that the RMSPowerSims.jl function defined for the calculation of the initial conditions assumes a steady-state operating point, and as such is not suitable for starting simulations from a transient state. The PowerSystemModel is then generated by iterating over each power system component in the NDD.

Any disturbances that are to be applied during the simulation are added directly to the ystemSimulation object as is shown in lines 7–13 of Listing 2. The specific disturbances shown in the listing are a short-circuit fault at bus 3 of the network, and the clearance of the fault at the same bus. Note that the $restart\_simulation$ flag is set to true for the $ClearBusFault$ disturbance. This is often necessary for the clearance of faults, as the solver has trouble converging to a solution from a state of near zero voltages.

Listing 2. Example of running a simulation using RMSPowerSims.jl.
1	# Load network model
2	load_model("example_network")
3
4	# Build PowerSystemSimulation object
5	power_system_simulation = prepare_simulation(net)
6
7	# Set disturbances
8	faulted_bus_index = 3
9	(t_fault, t_clear) = (0.5, 0.55)
10	power_system_simulation.disturbances = Disturbance[
11	BusFault(faulted_bus_index, t_fault),
12	ClearBusFault(faulted_bus_index, t_clear, restart_simulation=true),
13	]
14
15	# Run simulation
16	tspan = (0.0, 10.0)
17	soln = run_RMS_simulation(
18	power_system_simulation,
19	tspan;
20	solver_settings=Dict(
21	"reltol" => 1e-9,
22	"abstol" => 1e-8,
23	"maxiters" => 10000,
24	"dtmax" => 0.01,
25	)
26	)
27
28	# Add simulation results to network model
29	add_simulation_results!(net, soln)
30
31	# Plot results
32	plot_res(net, "gen", 1, "Pg")

The call of the $run\_RMS\_simulation$ function executes the time-domain simulation. If any of the disturbances require a restart of the simulation, the simulation will be run in multiple stages, with the initial condition of each stage being calculated from the final state of the previous stage. To avoid duplicate time values, subsequent stages are started after a small time interval, $t_{gap}$, from the previous stage. For simulations in which multiple disturbances occur, this results in the simulated time interval between disturbances being smaller than the difference between the times they are set to occur by an amount of $t_{gap}$. It is important to minimize $t_{gap}$, as significant variations in the simulation results are observed if it is too large. An interval in the order of ${10}^{-5}$ is found to provide acceptable results.

Finally, lines 28–32 of Listing 2 show some simple data processing. The function $add\_simulation\_results!$ parses the solution objects returned by the differential equation solver and adds them to the PowerModels.jl NDD. This simplifies the process of accessing the simulation results. The $plot\_res$ function is a simple plotting function that uses the Plots.jl [28] package to plot the results of the simulation.

4. Verification

In this section, the time-domain simulation results produced by RMSPowerSims.jl are compared to those produced by the DIgSILENT PowerFactory. A version of the PowerFactory model of the 39 Bus New England System [17,29], with modified AVR models and salient-pole generators replaced by round-rotor generators, is used for the simulation. The network diagram of the system is shown in Figure 3. The system contains ten synchronous generators, nine of which are equipped with a TGOV1 thermal governor and IEEET1 type AVR model. All generators are modeled as round rotor machines using PowerFactory’s Standard Model [30]. The complete list of parameters used to model the system is provided in Appendix A.

Figure 4 shows comparisons of the time series results produced by RMSPowerSims.jl and PowerFactory. The simulation used for comparison includes a bolted short-circuit fault, clearance of the fault, and a load increase. The fault occurs at Bus 31 at $t=0.1$ s, and is cleared at $t=0.2$ s. The load increase occurs at $t=1.5$ s for the load at Bus 16, and is set to 20% of the load at Bus 16 before the fault, that being 322 MW. RMSPowerSims.jl is set to recalculate the state of the system at the time of fault clearance but not at the time of the fault, or  the time of the load increase. The Sundials IDA solver [20,21] is used in RMSPowerSims.jl with both absolute tolerance and relative tolerance set to ${10}^{-4}$.

As can be seen in Figure 4a,b, both the voltage at the faulted bus and the active power response of the generator connected to faulted bus, G 02, match the results produced by PowerFactory quite closely. Figure 4c,d show the voltage of Bus 9 and the active power response of the generator connected to Bus 38, G 09, which is distant from the fault. The results here are also shown to be in close agreement with those produced by PowerFactory. Figure 4e shows that the active power drawn by the load at Bus 16 closely matches the PowerFactory results through both the short-circuit disturbance, and the load increase.

It is worth noting that while the verification processes of other software packages commonly use metrics such as the root mean square error of the compared signals, we simply opt for visual inspection in this case. The reasoning for this is that the synchronous generator models used in RMSPowerSims.jl and PowerFactory are not strictly identical [31], and as such, the results produced by the two packages are not expected to match identically. Any metric-based comparison would, therefore, be misleading, as it is not possible to identify which differences are due to the generator model and which are the implementation of the simulation package.

To evaluate the computational performance, both load-step and short-circuit simulations are conducted comparing RMSPowerSims.jl and PowerFactory. The performance analysis consists of 100 simulations executed on an Intel Core i9-11900H CPU, with computation times recorded for each run. The initial condition calculations are excluded from the timing measurements. Due to Julia’s just-in-time compilation characteristics, a warm-up simulation is performed prior to recording the computation times, as the first execution of a simulation run in RMSPowerSims.jl is slower than subsequent runs.

The analysis employs both fixed-step and adaptive-step solvers. The fixed-step solver utilizes a 0.01 s step size, while the adaptive-step solver’s maximum step size is configured at 0.1 s. RMSPowerSims.jl again implements the Sundials IDA solver, whereas PowerFactory employs a trapezoidal integration method. A direct solver comparison is not feasible due to two constraints: (1) limited access to PowerFactory’s internal solver implementation, and (2) the restricted availability of DAE-compatible solvers within the Julia ecosystem.

The computational performance comparison for load-step studies is presented in Figure 5 using violin plots. The results demonstrate that PowerFactory exhibits superior performance, with both mean and median computation times approximately three times faster than RMSPowerSims.jl for fixed-step simulations and approximately four times faster for the adaptive-step simulations. This performance differential is anticipated, given that the primary development focus of RMSPowerSims.jl has prioritized accuracy, flexibility, and usability over computational optimization. For the load-step studies examined here, the absolute difference in computation times is in the order of hundreds of milliseconds, making the performance gap negligible for these specific cases. Further investigation is warranted to evaluate the scalability of RMSPowerSims.jl’s computational performance with increasing system size.

The computational performance comparison for short-circuit studies is presented in Figure 6. While similar performance trends are observed as in the load-step studies, the performance differential between PowerFactory and RMSPowerSims.jl is more pronounced for short-circuit simulations. PowerFactory demonstrates significantly faster execution times, with mean and median computation times approximately twelve times faster for fixed-step studies and twenty times faster for adaptive-step studies.

A substantial portion of this performance gap can be attributed to RMSPowerSims.jl’s requirement to recalculate the initial system conditions at fault clearance time, a process that requires approximately 1.5 s for the New England 39 Bus System. This recalculation, while necessary for ensuring result accuracy, introduces considerable computational overhead, which does not scale well with the size of the system. Given the magnitude of these performance differences, RMSPowerSims.jl in its current implementation may not be suitable for short-circuit applications, where computational efficiency is a primary consideration.

5. Conclusions

This paper has presented an RMS simulation capable Julia package that is intended to be compatible with the PowerModels.jl ecosystem. The overall structure of the package has been discussed, as well as a brief overview of the simulation process. A verification process has been performed using the 39 Bus New England System to compare the responses acquired using the developed RMSPowerSims.jl package and DIgSILENT PowerFactory. The results clearly indicate that RMSPowerSims.jl is capable of producing accurate time-domain simulation results. The computational performance of the package has also been discussed, and while the package is not yet at the level of performance of commercial packages such as DIgSILENT PowerFactory, the simulation times are not prohibitively long as long as the computational performance is not the primary concern. Performance optimizations are planned for future development to improve the computational performance of the package.

The immediate future work for the package includes the implementation of additional synchronous generator control models and renewable energy generation models. This will increase the range of systems that can be simulated and facilitate studies of modern power systems for all researchers.