Source-linked AI summary

Interactive Power Flow in the Browser

Samuel Talkington, Frederik Geth, Qian Zhang, Le Xie, Skyler Liu

arXiv:2610.01922v1eess.SYcs.HCcs.MScs.SY

TL;DR

Open-source power-system solvers remove license barriers, but delivering an executable study still involves installation, dependencies, and input conventions. tellegen brings interactive PF and OPF studies into the browser, where cases can be parsed and solved locally. Evaluations compare its solvers with established tools and report browser OPF solve times approximately 25–43% longer than native solves.

  • Problem

    Open-source tools remove license barriers, but delivering a focused executable study still requires installation, dependencies, and learning input conventions.

    Source: §1 · p. 1
  • Method

    tellegen combines a browser interface with local WebAssembly power-system calculations, allowing users to load cases, edit parameters, preview sensitivities, and re-solve studies.

    Source: §1 · p. 1
  • Results

    Evaluations report DC OPF objective agreement with PowerModels.jl in 148 cases, distribution PF comparisons with OpenDSS, and browser OPF solves approximately 25–43% longer than native solves.

    Source: §3.1 · p. 5, §3.2 · p. 5, §3.4 · p. 6
  • Takeaways & Limitations

    A study can be shared as a web link while recipients keep sensitive case files local and run the analysis in a compatible browser.

    Source: §5.1 · p. 7, §7 · p. 8

    Educational and organizational impacts remain unmeasured, and large networks that run acceptably in benchmarks may be unsuitable for mobile devices.

    Source: §5.1 · p. 7

Abstract

from arXiv · show

This paper introduces tellegen, an open source framework for interactive power flow (PF) and optimal power flow (OPF) studies that run in the browser. This provides intuitive and democratized access to power system analysis tools compiled to WebAssembly. A user can drag and drop a case file, click and drag to change a nodal demand or line rating, preview the impacts via sensitivity analysis, and obtain an exact re-solve on release. User case files and results stay entirely on the device: tellegen transmits zero Critical Energy/Electric Infrastructure Information (CEII). The framework comprises a core numerical engine for PF and OPF, reusable browser components, saved studies, and structured WebMCP tools for agentic interaction. We evaluate the transmission OPF solver by comparing objectives with PGLib baselines; the distribution PF solver by comparing voltages and currents with OpenDSS; and the WebAssembly execution times by comparing with PowerModels.jl. On realistic synthetic grids, WebAssembly OPF solves take only 25-43% longer than native binary solves. The implementation shows how an engineer can distribute an executable numerical study as a URL, reducing installation and hosting requirements while keeping case data local.

1 Introduction

The introduction identifies a gap between open-source power-system solvers and the effort required to deliver an executable study to someone without the author’s environment. It presents tellegen as an open-source browser framework for interactive power-system analysis and visualization, evaluated against existing tools.

1 Introduction

  • Open-source solvers remove licensing barriers, but delivering a focused executable study still requires addressing installation, dependencies, and input conventions.Static illustrations are straightforward to generate, whereas changing study assumptions usually requires numerical software.Source: §1 · p. 1
  • Recipients can open a study link, edit electrical parameters, inspect sensitivity impacts, and obtain a new solution in the browser.Local case files can also be loaded by drag and drop; parsing and solving happen on the recipient’s device.Source: §1 · p. 1
  • The framework combines a Rust numerical engine compiled to WebAssembly with case parsing, reusable browser components, saved studies, and experimental WebMCP support.The engine supports transmission PF and OPF, multiconductor distribution PF, OPF sensitivity analysis, and retained sessions for repeated PF load changes.Source: §1 · p. 1
  • tellegen integrates browser-based power-system analysis and visualization, with transmission OPF and distribution PF evaluations against existing tools.The introduction names PowerModels.jl and OpenDSS as baselines.Source: §1 · p. 2
  • The demo showcases four synthetic transmission grids and a distribution example, while the source and browser packages are available online.The paper identifies outreach, teaching, and exploration of sensitive network models as potential application areas.Source: §1 · pp. 1–2

2 System Architecture

tellegen combines browser components with compiled power-system solvers so studies can be parsed, edited, and solved locally. Its models span transmission and distribution formulations, while sensitivity previews, reusable case data, and native interfaces support interactive and batch workflows.

2 System Architecture

  • tellegen compiles a shared numerical engine to native and WebAssembly targets, enabling browser studies to run locally without a cloud solver service.Browser components load, edit, and display power-system models.Source: §2 · p. 2

2.1 Models and formulations

  • Transmission models include DC PF and OPF and a convex SOC relaxation; distribution models include multiconductor AC PF and LinDist3Flow, an approximate model rather than an AC feasibility certificate.LinDist3Flow neutral elimination assumes zero voltage drop along the neutral.Source: §2.1 · pp. 2–3
  • Multiconductor PF retains explicit neutrals and line coupling, and reuses its prepared matrix for load edits; topology, tap, or reference-source changes require rebuilding the session.The solver uses one sparse LU factorization for voltage iterations.Source: §2.1 · p. 2

2.2 Sensitivities, preview, and re-solve

  • Implicit differentiation maps supported problem inputs to outputs for sensitivity previews, while committing an edit triggers a solve to numerical tolerance rather than derivative extrapolation.Previews can become invalid near singular points, across active-set boundaries, or outside the feasible region.Source: §2.2 · pp. 3–4

2.3 Case data and browser packages

  • The browser-facing architecture separates parsing and numerical execution from browser rendering, with reusable packages providing the study lifecycle and result displays.Rendering uses JavaScript components, deck.gl, and MapLibre rather than Rust.Source: §2.3 · p. 4
  • Local parsing supports several transmission and distribution file formats, but parsing a format does not guarantee that the solver supports the case; local study data and results remain on-device.Local studies have no server-solving fallback, and tellegen transmits zero CEII from them.Source: §2.3 · p. 4

2.4 Access outside the browser

  • Native Rust and Python interfaces expose the same study lifecycle for scripts and notebooks, while an MCP server supports headless and batch workflows distinct from browser WebMCP.Studies exported from either interface can be imported into the other.Source: §2.4 · p. 4

3 Evaluation

The evaluation compares transmission OPF objectives and solve times with established baselines, and distribution PF results with OpenDSS. It also tests LinDist3Flow approximation error and reports native distribution latency, with numerical failures and validation limits included in the scope.

3.1 Transmission objectives and sensitivities

  • 148 DC OPF objectives agree with PowerModels.jl+Ipopt within 1%, with median relative discrepancy 1.0 × 10−5.The evaluation attempted 198 PGLib case–variant pairs across 66 cases and three operating conditions, ranging from 3 to 78,484 buses.Source: §3.1 · p. 5
  • 189 computed SOC relaxation objectives lie below AC OPF reference objectives within tolerance; 183 reproduce the SOC gap with median absolute gap discrepancy 0.006 percentage points.Certifying these objectives as lower bounds would require a feasible relaxation dual, and local AC OPF solutions need not be globally optimal.Source: §3.1 · p. 5
  • Sensitivity validation uses finite-difference estimates, which approximate actual derivatives and leave active-set changes, small derivatives, and conic degeneracy as concerns.The authors note that solutions may differ when optima are nonunique.Source: §3.1 · p. 5

3.2 Distribution power flow against OpenDSS

  • Distribution PF comparisons with OpenDSS include maximum voltage and current discrepancies of 1.08 × 10−7 V and 6.78 × 10−9 A across 56 reference cases.The evidence covers specified static models, not time-series controls or every OpenDSS device.Source: §3.2 · p. 5, Table 3 · p. 5

3.3 LinDist3Flow validation

  • On one feeder, LinDist3Flow’s receiving voltage is 220.4269 V versus 220.1931 V for nonlinear OpenDSS, a 0.1062% magnitude discrepancy.This measures approximation error, distinct from the smaller discrepancies between implementations of the same nonlinear model.Source: §3.3 · p. 5

3.4 Transmission OPF solve time

  • SOCWR failures remain part of the evaluation: the 10,000-bus GOC case fails across native tellegen, wasm, and PowerModels with Clarabel.Three more PowerModels/Clarabel cases fail, and 15 additional runs have ALMOST_OPTIMAL status.Source: §3.4 · p. 6

3.5 Native distribution PF time

  • Native distribution latency measurements include startup, parsing, preparation, solution, and JSON serialization; the median launch-only baseline is 2.70 ms.These are native end-to-end timings, not browser timings or an OpenDSS runtime comparison.Source: Table 6 · p. 6, §3.5 · p. 6

3.4 Transmission OPF solve time

  • Browser OPF solves take approximately 25–43% longer than native solves on realistic synthetic grids, while 60 PGLib cases extend the comparison through 10,480 buses.The broader comparison reports median wasm/native ratios of 1.43 for DC OPF and 1.25 for SOCWR.Source: Figure 3 · p. 6, §3.4 · p. 6

4 Interactive Studies

Interactive studies combine browser-based network visualization and editing with previews and exact re-solves. Distribution-study features and structured WebMCP tools extend this workflow to equipment inspection, repeated load changes, and agent interaction.

4 Interactive Studies

  • The workflow parses a case into a canonical network, loads the shared Rust engine as WebAssembly, and renders results with a map and solve card.A formulation selector switches transmission solves between DC OPF and the SOCWR relaxation without leaving the page.Source: §4 · p. 6
  • Selecting a bus or binding line displays demand or rating sensitivities; releasing a rating edit commits an exact re-solve after a first-order preview.For a +10 MW rating edit, the panel reports a −15.9 $/h prediction beside a −14.9 $/h exact change.Source: §4 · p. 6

4.1 Distribution studies and agent tools

  • Distribution views include terminal voltages, currents, source powers, and, when declared, voltages relative to neutral; equipment inspection exposes model attributes.Retained multiconductor sessions reuse network factorization for repeated active/reactive load edits, which trigger full nonlinear PF solves rather than sensitivity previews.Source: §4.1 · pp. 6–7
  • Structured WebMCP tools let agents inspect cases, query solved quantities, request PF or supported experiments, and propose capacity changes for human approval.Proposals record trials and re-solved results; applying one checks the case and revision, requires interface approval, and can be recorded in an exportable journal.Source: §4.1 · p. 7

5 Implications for Digital Transformation

The paper frames executable studies as a way to reduce the work of running power-system analyses and describes design choices for responsive, local interaction. It also identifies limits in evidence about user impact, device capacity, and operational validation.

5.1 Access through an executable study

  • An executable study can be shared as a link for recipients to run in a compatible browser, with educators, researchers, and engineers as intended users.The proposed uses include publishing controlled educational networks, attaching executable examples to papers, and sharing interfaces while customers keep sensitive files local.Source: §5.1 · p. 7
  • Numerical evaluations establish feasibility and realism, but educational and organizational impacts remain unmeasured.Browser execution shifts computation and memory to the recipient, so a network suitable for benchmark devices may not suit mobile users.Source: §5.1 · p. 7

5.2 Lessons for numerical software delivery

  • Separating a fast solution preview from a completed solve keeps parameter exploration responsive, while a compiled worker keeps the interface usable during longer solves.The paper presents these design choices as useful for scientific applications involving parametric edits to costly in-process optimization problems.Source: §5.2 · p. 7
  • Local-first delivery distributes the solver so execution costs fall on clients, removing the need for an operator-side solver service for private cases.Large batch, multi-period, or security-constrained studies may still warrant native or remote compute; not every study must fit every device.Source: §5.2 · p. 7

5.3 Agent interaction and implementation experience

  • The WebMCP workflow supports collaborative agent and human inspection, bounded experiments, and planning proposals, with human approval required to apply a proposal.Proposals use sensitivities to select trials and re-solve each candidate; agentic coding experience also motivates retaining reference-grid benchmarks and independent checks.Source: §5.3 · p. 7

5.4 Ethical considerations

  • Keeping parsing and solving on-device is the framework’s stated basis for transmitting zero CEII; validation uses synthetic transmission grids and public distribution datasets.Those datasets may not reflect utility models needed operationally, so operational decisions require validation against applicable equipment models and operating requirements.Source: §5.4 · p. 7

6 Related Work

The related work includes open analysis and optimization tools, distribution-model tools, interactive visualization systems, and GPU-oriented solvers. Tellegen’s stated distinction is a client-side compiled solver integrated with local file ingestion and sensitivity previews.

6 Related Work

  • MATPOWER, pandapower, and PowerModels.jl [5] provide open power-system analysis and optimization implementations, while OpenDSS and PowerModelsDistribution.jl [10] address detailed unbalanced distribution models.Tellegen uses established formulations and these reference implementations to evaluate its delivery and interaction model.Source: §6 · p. 7
  • PowerPlots.jl [22], GridSuite, and Electrisim support visualization or browser-based grid-study interfaces; tellegen combines local file ingestion, a compiled client-side solver, and sensitivity previews.The passage notes GridSuite is used in production at RTE and Electrisim interfaces with engines including pandapower and OpenDSS.Source: §6 · p. 7
  • GPU-oriented ExaModelsPower.jl [17] targets nonlinear AC OPF for GPU solvers, including multi-period and security-constrained studies, whereas tellegen emphasizes distributing an interactive study to an individual user.Source: §6 · p. 7
  • Tellegen’s sensitivity previews draw on derivatives from solved optimization conditions, while WebMCP exposes browser application tools to agents and is distinct from client–server Model Context Protocol.The passage also cites agent interfaces for power-system tools by Zhang and Xie.Source: §6 · p. 8

7 Conclusion and Future Work

The conclusion presents tellegen as a browser-based framework for local power-system analysis and visualization, supported by comparisons with reference tools. It identifies operational validation and full nonlinear AC OPF as future work.

7 Conclusion and Future Work

  • Tellegen combines local browser calculations with interactive power-system analysis and visualization; its evaluation checks transmission objectives, execution timings, and distribution voltages and currents against reference tools.The authors conclude these results support distributing useful numerical studies by web link without uploading private cases.Source: §7 · p. 8
  • Operational-planning validation remains a future direction, including comparison against PSS/E for bus voltages, flows, and dispatch.Such validation ultimately calls for utility network models designated CEII; local execution may ease access but does not reduce the model’s underlying sensitivity.Source: §7 · p. 8
  • Full nonlinear AC OPF remains future work and requires a suitable nonlinear solver and numerical validation; WebAssembly itself does not rule out such a solver.Other proposed extensions include distribution optimization controls, state estimation, and teaching materials evaluated with students.Source: §7 · p. 8

Disclaimer

The authors state that the paper’s views do not represent PJM Interconnection or its Board of Managers.

Disclaimer

  • The authors’ views do not reflect those of PJM Interconnection or its Board of Managers.Le Xie is a member of the Board of Managers.Source: Disclaimer · p. 8
Loading 2610.01922v1…