PowerPlots.jl: Power Grid Visualization

• PowerPlots.jl is an open‐source Julia framework for power grid visualization and analysis, transforming PowerModels dictionaries into layered VegaLite plots.
• It converts nested power-system data into graph models and DataFrames, enabling topology-aware and statistical analysis with standard Julia tools.
• The framework supports both exploratory inspection and figure refinement, adapting seamlessly to evolving data schemas in complex power-system research.

Searching arXiv for the cited papers to ground the article in current records. arXiv search query: PowerPlots Julia power grid visualization PowerModels MathProgComplex optimal power flow complex variables PowerPlots.jl is an open-source Julia framework for power-grid visualization and data analysis designed for academic research. It operates within the InfrastructureModels/PowerModels ecosystem, directly consumes the standard nested-dictionary data format used by PowerModels.jl and PowerModelsDistribution.jl, and is intended to support both exploratory analysis and publication-ready figure generation from the same workflow. Its defining characteristics are a layered VegaLite-based plotting model, supporting transformations into graph-topological and DataFrame representations, and a data model that remains compatible with transmission, distribution, multi-network, and user-extended power-system datasets (Rhodes, 6 Oct 2025).

1. Research role, scope, and problem setting

PowerPlots.jl is positioned as a visualization and analysis layer for power-system research rather than as a solver or a fixed-function GUI. Its stated goals are twofold. First, it supports exploration: drawing a network diagram from a raw case file, mapping arbitrary solution fields such as voltages, flows, locational marginal prices (LMPs), or custom metrics onto the network, and interactively inspecting values by hovering, filtering, and stepping through time or scenarios. Second, it supports communication: refining exploratory graphics into clear figures with customized legends, fonts, colors, and layouts suitable for publication (Rhodes, 6 Oct 2025).

The package is explicitly described as ecosystem-agnostic within Julia’s PowerModels family. Any tool that outputs a PowerModels-style dictionary can use it without code changes. It is also described as data-agnostic in the sense that new components or attributes can be added to the underlying data structure and visualized directly. This is significant for research settings in which data schemas evolve during method development, for example when introducing new asset classes, scenario annotations, or custom reliability or market metrics.

The supported application space includes transmission systems and distribution systems. For distribution systems, PowerPlots.jl works with PowerModelsDistribution.jl in both the engineering model, which reflects physical equipment such as three-winding transformers and lines, and the mathematical model, which reflects the equivalent circuit used in optimization. It also supports multi-network data through the nw index used in PowerModels multinetwork format, enabling visualization of time series, scenario sets, restoration stages, and related sequence-structured studies.

A central theme is that the framework is designed for researchers who need to inspect nonstandard outputs. Existing tools are characterized in the source material as often being tied to a particular solver stack, focused on standard problems and fixed data models, or offering limited flexibility for arbitrary user-defined fields. PowerPlots.jl is presented as an alternative in which the plotting layer adapts to the research data model rather than the reverse.

2. Internal architecture and data representations

The core workflow follows a fixed sequence. The input is a nested dictionary in PowerModels format. If coordinates are absent, PowerPlots.jl constructs a graph and computes component coordinates with a layout algorithm, writing those coordinates back into the input data. The nested dictionaries are then transformed into DataFrames, typically one per component type plus a metadata DataFrame. Finally, a layered VegaLite plot is generated, with separate layers for component classes such as buses, branches, and generators. A single call to powerplot(grid_data) performs the coordinate-generation and plotting stages automatically with defaults, while each stage can also be invoked and customized independently (Rhodes, 6 Oct 2025).

Two auxiliary data models formalize these transformations.

The first is PowerModelsGraph, which stores a graph view of the network. Its fields are:

• graph::Graphs.SimpleDiGraph
• node_comp_map::Dict{Int,Tuple{String,String}
• edge_comp_map::Dict{Graphs.AbstractEdge,Tuple{String,String}
• edge_connector_map::Dict{Graphs.AbstractEdge,Tuple{String,String}

In this representation, the plotted network is effectively undirected even though it is implemented as a SimpleDiGraph. Graph nodes can include buses and connected components such as generators, loads, and shunts. Physical network edges correspond to branches, transformers, DC lines, and switches, while connector edges link non-bus components to their associated buses. The resulting graph representation is directly compatible with Graphs.jl analytics such as node degrees, shortest paths, bridges, articulation points, and connected-component analysis.

The second is PowerModelsDataFrame, which stores a tabular view:

• metadata::DataFrames.DataFrame
• components::Dict{Symbol,DataFrames.DataFrame}

This transformation is important because the original PowerModels nested dictionary is convenient for per-component access but awkward for aggregate analysis. Converting to DataFrames enables sorting, grouping, filtering, joins, and aggregation over fields such as pmax, base_kv, or voltage magnitudes. In practical terms, this shifts the analysis interface from recursive dictionary access to a column-oriented research workflow.

The architecture therefore implements a three-view model of the same dataset: nested dictionaries for interoperability with PowerModels-based tools, graph structure for topology-aware analysis and layout, and DataFrames for statistical and comparative analysis. This division is one of the package’s distinguishing design choices.

3. Visualization model, layouts, and interaction

PowerPlots.jl’s primary output is a layered network plot built with VegaLite.jl. Each component class is plotted as a separate layer, and user arguments determine which data fields are mapped to encodings such as color, size, line style, opacity, or shape. Because the package uses VegaLite’s layered grammar of graphics, the plot specification remains programmatically editable after construction, including legend titles, color domains, scale independence, and font choices (Rhodes, 6 Oct 2025).

If network coordinates are unavailable, PowerPlots.jl computes them with NetworkLayout.jl algorithms or with its own Kamada–Kawai implementation. The default Kamada–Kawai layout minimizes the stress functional

$$E = \frac{1}{2} \sum_{i \neq j} k_{ij} (d_{ij} - \| \mathbf{x}_i - \mathbf{x}_j \|)^2$$

where $d_{ij}$ is the graph-theoretic distance between nodes $i$ and $j$ and $k_{ij}$ is a spring constant, often $1/d_{ij}^2$. The intent is to align Euclidean distance in the drawing with graph distance, which reduces crossings and usually yields visually interpretable layouts. Alternative layouts include Spring (Fruchterman–Reingold), SFDP, Spectral, Shell, and Grid.

The paper reports the following timing data in seconds for three cases:

Layout	Case39	Case1354	Case1888
Kamada–Kawai	0.0096	31	35
Spring	0.0039	5	4.8
SFDP	0.00094	3.1	2.8
Spectral	0.0012	2.5	2.2
Shell	0.00062	0.068	0.065
Grid	0.00055	0.25	0.065

These timings make explicit the trade-off between visual quality and scalability: Kamada–Kawai is described as the highest-quality default but also as the slowest on larger systems, whereas SFDP and Spectral are the scalable alternatives. When known coordinates are present in the data, they can be treated as fixed. Partial-layout workflows are also supported, for example fixing geographic bus positions while using SFDP to place generators around them.

Visual encoding is field-driven. Buses can be colored by LMP or voltage magnitude, branches can be colored by loading or contingency status, and component sizes can encode quantities such as load or flow magnitude. Multi-network data introduce an extra nw dimension; PowerPlots.jl interprets this as a family of networks and exposes filtering so that different time periods, scenarios, or restoration stages can be displayed with a common layout. Interactivity is browser-based and includes hover tooltips over components and simple filtering over nw.

4. Analytical workflows beyond plotting

Although introduced as a plotting framework, PowerPlots.jl is also a data-analysis system because its graph and DataFrame layers expose the same power-grid data to established Julia analytics packages. This enables research workflows in which visualization and quantitative analysis are tightly coupled rather than separated into different software environments (Rhodes, 6 Oct 2025).

Graph-based analysis proceeds from PowerModelsGraph. Standard Graphs.jl functionality can then be used to compute node degree distributions, incidence or adjacency matrices, shortest paths, connectivity properties, bridges, and articulation points. One example reported in the paper is topological analysis across PGLib cases, where bus node degrees were computed for small, medium, and large synthetic transmission networks. The reported result is that small networks with fewer than 1000 buses and medium networks with 1000–10,000 buses have more degree-1 and degree-2 nodes but fewer degree-3 and degree-4 nodes than large networks with more than 10,000 buses, and that the maximum node degree is 15 in small networks versus 41 in medium and large networks.

Tabular analysis proceeds from PowerModelsDataFrame. Because each component type is materialized as a DataFrame, standard DataFrames.jl operations become available immediately. The paper gives examples including sorting generators by pmax and computing voltage-magnitude statistics by base_kv after solving AC OPF with PowerModels and Ipopt and then writing the solution back into the data structure. In the cited example, grouping buses by base_kv and aggregating mean, standard deviation, minimum, and maximum of vm reveals that 69 kV buses have an average voltage of approximately 1.07 p.u., which is interpreted in the source material as suggesting significant injections at that level.

The paper frames these capabilities as directly useful for algorithm development and debugging. A researcher can solve a power flow, state estimation, restoration optimization, or related model, visualize anomalies or congestion patterns, inspect suspicious components via hover, and then move seamlessly into graph-theoretic or statistical post-analysis. The same framework is also applied to scenario comparison, model checking for distribution-system engineering versus mathematical models, and final figure production.

Several case studies illustrate the range of use. These include basic visualization of the 39-bus EPRI system, comparison of PEGASE 89-bus and IEEE 118-bus synthetic structures, wildfire risk and Public Safety Power Shutoff planning on RTS-GMLC, LMP and congestion visualization, multi-stage restoration planning in a 24-bus system, engineering-versus-math-model views of a 3-phase center-tap transformer, topological analysis across PGLib, and voltage statistics on pglib_opf_case2000. The cumulative effect is to locate PowerPlots.jl at the interface between qualitative interpretation and quantitative inspection.

5. Extensibility, customization, and ecosystem position

PowerPlots.jl is implemented in Julia and leverages PowerModels.jl or PowerModelsDistribution.jl for data formats and parsing, Graphs.jl for graph representation and analysis, NetworkLayout.jl for layout algorithms, DataFrames.jl for tabular handling, VegaLite.jl for interactive plotting, and ColorSchemes.jl for colormaps (Rhodes, 6 Oct 2025). The package therefore inherits a broad set of Julia ecosystem capabilities while remaining anchored to the PowerModels data model.

Its extensibility model is intentionally simple. New components can be introduced by extending the PowerModels-style dictionary with a new key such as "hydro" and including that component type among connected components in the plot. New numerical or categorical fields can be attached to existing components and then mapped directly onto visual encodings without modifying the library itself. Because the plot output is a VegaLite specification, the user can also add layers or mutate the generated JSON-like structure to alter legends, color domains, font settings, or scale behavior. The source material characterizes this as effectively a small domain-specific language over VegaLite specifications.

In relation to other tools, the package is contrasted with PyPSA, pandapower, PowerGridModel and its data-analysis extension, OpenDSS and OpenDSS-G, and commercial tools such as PowerWorld, PSS/E, ETAP, and TARA. The distinction drawn is not that these systems lack plotting, but that they tend to be more tightly bound to fixed workflows or to the data produced by the tool itself. PowerPlots.jl, by contrast, is presented as an open-source, code-centric visualization and analysis front-end for Julia-based power-system research with arbitrary user-defined fields and component types.

This positioning also explains the package’s emphasis on publication-ready graphics. Since the same object produced for exploratory plotting can be post-processed programmatically, the transition from preliminary inspection to figure finalization does not require re-implementing the plot in another environment. The paper treats this continuity as part of the research workflow rather than as a cosmetic afterthought.

6. Limitations, future directions, and relation to adjacent optimization tooling

The documented limitations are primarily methodological rather than functional. Kamada–Kawai layouts become slow on very large networks, with runtimes of tens of seconds for systems of roughly 1800 buses. Interactivity is currently centered on hover tooltips and simple multi-network filtering rather than more elaborate dashboard-style controls. Advanced customization is often possible only by directly editing the VegaLite specification, and the authors indicate an intention to expose more of this control through higher-level user arguments. The package’s current domain focus is electric power grids, with extension to other infrastructure networks such as gas, water, and telecommunications identified as future work (Rhodes, 6 Oct 2025).

A relevant adjacent development is MathProgComplex.jl, a Julia module for representing mixed-integer polynomial optimization problems with complex variables in their original complex form and applying them to ACOPF and PSCOPF (Sliwak et al., 2019). That module does not provide built-in plotting or visualization features. However, it explicitly identifies outputs such as complex bus voltages, line flows, generator outputs, contingency cases, and relaxation and bound data as natural inputs for a plotting or visualization tool. It also argues for possible integration into PowerModels.jl to provide a complex formulation of ACOPF. This suggests a complementary layering in the Julia power-systems ecosystem: complex-first optimization and relaxation tools can provide mathematically faithful solution objects, while PowerPlots.jl can provide the graph, tabular, and visual front end through which those results are inspected.

The same relation holds more generally for research workflows involving novel formulations. When optimization tools produce PowerModels-style dictionaries, PowerPlots.jl can consume them directly. When they do not, the graph and DataFrame abstractions indicate a plausible pathway for adaptation. In this sense, the package occupies a methodological niche between model output and scientific interpretation: it does not solve power-system problems, but it supplies a flexible representation and rendering layer through which topology, operating state, scenario variation, and model transformation can be examined with the same software artifact.