Understanding Sienna - Part I

Why understand Sienna?

This post was born out of my desire to have a deeper understanding and appreciation for the Sienna modeling framework as it stands today. A significant part of my research is currently being carried out using Sienna. These notes are an attempt to reinforce my learning of the inner workings of Sienna code and to host it in a place that is easy for me to find and share. Sharing these notes is also one of the reasons why I am making this blog post. Throughout my academic career, I have benefited tremendously from content like this — either by people sharing their class notes or insights while exploring a topic. With that said, I should add that I am the primary audience of this post, and the language here will, at times, reflect that.

The content of this post is not entirely original. It draws heavily from the PowerSystems.jl webpage and the Sienna Tutorial videos on YouTube. The brilliant creators at the helm of these tutorials know much more about Sienna than I do, and I trust their video structure to organize my bite-sized posts. Other sources, such as papers, reports, and presentations, are referenced in the References section when necessary.

An introduction to Sienna

Sienna is an open-source modeling framework and ecosystem for simulation and optimization, and is divided into three main applications: \Data, \Ops, and \Dyn.

Sienna\Data concerns the efficient intake and use of data. Siennaperforms all simulation (and emulation) of system scheduling problems, such as UC, ED, OPF, etc. Finally, Siennais concerned with the simulation of systems dynamics, which is more related to power systems control. Given my research, it’s in my best interest to acquire a firmer grasp of and , before going into .

Sienna\Data is where everything starts with all Sienna projects. Data are king, after all. And if that is so, PowerSystem.jl is the knight leading the infantry. The package is part of all three Sienna applications, underscoring its prestige within the modeling framework.

In the following sections, I detail what I have gathered from these sources.

Siena\Data

In Episode 2: Sienna\Data – How it Works, we see the Sienna approach to modeling data.

To explain how Siena\Data manages information, it is wise first to mention two different types of models that rely on data: the data model and the operational model. The data model, called Types, can be generators, loads, service, network topology, and time series data. There is information about these models that stays the same within the scope of a study, such as the capacity or location of a generator. The operational model, called Formulations, refers to a series of real-world problems that Sienna can model and simulate, such as the UC, the ED, and the OPF problems. These models rely on equations that change according to the problem being tackled, and the Formulations apply to different Components in a System.

For this reason, Sienna\Data keeps data and equations separated. This modeling choice is based on the different ways data can be used. The data on any given generator or load is innate to them. Yet, how a generator or load is modeled will change according to the type of problem at hand. The example from the tutorial video is the behavior of a wind generator as part of a UC problem or as part of a stability analysis. The data for that generator does not change regardless of the problem; however, the generator’s role in these two distinct problems differs significantly.

In Sinna\Data, the fundamental¹ data is stored in all sorts of files, e.g., files .csv, .m, .raw, .txt. These data will be fed into a Data Model, whereas Equations are fed into the Operational Models.

This is when I am reminded I am no Electrical Engineer. Stability analysis is something I know little of because it is far outside the scope of my research interests.

Data and equations can be combined to describe a particular problem. Once the Data Models have been declared, all the information in these models is stored in memory. Likewise, once the operation models are defined, they, too, are stored in memory and, along with the information contained in memory, are passed to the solver.

There are five packages within Sienna: PowerSystems.jl (PSY), PowerGraphics.jl, PowerNetworkMatrices.jl, PowerSystemsCaseBuilder.jl, and PowerFlows.jl. One quickly learns that PowerSystems.jl is the powerhouse of the Sienna application trifecta. PSY is part of all three major applications and is used to parse and format all input data for consistent representation. Consistency is one of the ethos of the Sienna modeling framework.

PowerGraphics.jl is concerned with ways to visualize data inputs and results. PowerNetworkMatrices.jl is used to build common power systems matrices, such as the Y matrix in OPF and the PTDF matrix. PowerSystemsCaseBuilder loads test system and custom system data. A strong suit of PowerSystemsCaseBuilder is the data it stores; it allows Sienna novices to get a taste of how Sienna works before defining their own systems. Lastly, PowerFlows calculates simple power flows outside the sequential production cost modeling problem.

Type hierarchy

At this point, it bears explaining the type hierarchy within Sienna.

In Julia, a (parametric) Type is a struct that can take as many parameters as the user declares. For each distinct combination of parameter values, there is a new family of types. There are many types, e.g.,Abstract, Union, Float64. To know more, see here.

This part relies heavily on the System and Type Structure subsections of the Explanation section of PowerSystems.jl. The website states there are several subtypes of InfrastructureSystemsType, but the most important are System, Component, InfrastructureSystems.DeviceParameters, and TimeSeriesData.

A System is the main container of Components and Time Series data. A schematic of a System is seen in Figure 1. In Julia lingo, System is a struct that collects all of the Components.

Figure 1: System structure within Sienna.

Data describing an infrastructure component is always held in a struct with a specific set of parameters distinctively defining a Component. A Component includes all elements of power system data, namely:

• Topology: includes non-physical elements describing network connectivity
• Service: includes descriptions of system requirements (other than energy balance)
• Device:includes descriptions of all the physical devices in a power system

An InfrastructureSystems.DeviceParameter includes the struct that holds data describing the dynamics, or economic capabilities of a Device. Lastly, the TimeSeriesData includes the two types of time series types: Forecast and StaticTimeSeries. A visualization of the relationship between different Types can be seen in Figure 2.

Figure 2: Types relationship and hierarchy

Note

The image for this post is Madonna and Child by Sano di Pietro (or Ansano di Pietro di Mencio), an italian painter born in Siena, Italy, and part of the Sienese school of paiting.

Footnotes

1. Fundamental is my choice of words. In no document or video did I read or see data being described with fundamental. Data were described as basic. The point to get across is that these are essential data, without which we can’t do anything