Automating PSS/E with Python — A Practical Engineering Workflow

Siemens PTI’s PSS®/E is the workhorse of bulk-system planning and interconnection studies, and its graphical interface is excellent for interactive, one-off analysis. But the moment a study involves hundreds of buses, dozens of contingencies, or a base case that must be solved, screened, and reported over and over, point-and-click stops scaling. The answer is automation — driving PSS/E from Python so the software becomes a callable engine inside a repeatable, auditable workflow.

This guide walks through the automation path our team relies on every day: how to reach PSS/E from outside its own GUI, how to open and solve a case programmatically, how to extract results the software will not record for you, and how to scale single-value queries into bulk data pulls. It closes with two anonymized case studies showing where this discipline pays off in real interconnection work.

WHY AUTOMATE AT ALL?

Recording macros inside the GUI is a fine first step, but it is limited — you can replay a fixed sequence and little more. Accessing PSS/E externally through Python unlocks the full language: loops, lists, conditionals, file I/O, data structures, and integration with the rest of your toolchain. That is the difference between a recorded button-press and a genuine engineering pipeline.

1. Two Ways to Use Python with PSS/E

There are two distinct modes. The first is in-GUI recording: you press record, perform actions in the interface, stop, and PSS/E writes the equivalent Python (or response-file) script, which you can replay. It is the fastest way to discover the right API call for a task you already know how to do by hand — but it caps your capability at whatever the GUI exposes.

The second mode is external control: you launch Python first, import the PSS/E libraries, and initialize the engine headlessly. Now PSS/E runs underneath your script. You can iterate over thousands of elements, branch on results, and write outputs anywhere — the full power of the language is available. The rest of this guide focuses on this mode, with GUI recording used as a learning aid to find the calls you need.

Version-to-Python mapping (know this before you start)

PSS/E ships with a bundled Python interpreter, and the version pairing matters — calling the wrong interpreter is the single most common reason an import fails. The current landscape:

Pair the interpreter to the PSS/E version: launch Python 2 for v33/34, Python 3 for v35.

2. Reaching PSS/E from Outside the GUI

Start from a command prompt and launch the matching interpreter (for example, py -2 for the Python 2.7 that ships with v33/34, or py -3 for the Python 3.9 in v35). The classic, explicit setup tells Python where PSS/E lives, registers that location on both the interpreter and the OS search paths, then imports the core API module and initializes the engine:

Those path steps are easy to forget. A cleaner approach uses a small helper module that performs the path wiring for you. Install it once with pip, then a single call selects the version and prepares the environment:

For v35, the workflow is simpler still: from a Python 3 prompt, importing the version package wires the environment automatically — no manual path handling or extra install required — after which you import psspy and call psseinit() as usual.

KEENTEL PRACTICE NOTE

We wrap initialization in a single, version-aware startup routine kept under version control. Every study script imports the same routine, so the environment is identical on every engineer’s machine and on the build server. Reproducibility starts at psseinit().

3. Opening and Solving a Case Programmatically

With the engine live, the OS library handles navigation to your working directory and the case API loads the saved case (.sav). From there you can solve it exactly as the GUI would:

How do you discover the exact solve call and its option flags? Record it. Perform the power-flow solution once in the GUI with the record function active, stop, and PSS/E writes the precise API line — including the default option vector — which you paste straight into your script. Recording is the fastest route from “I know how to do this by hand” to “I have the API call.”

4. Extracting Results: Activities Are Recorded, Results Are No

This is the concept that trips up newcomers. In PSS/E, activities can be recorded but results cannot. An activity is an action — solving a power flow, building a subsystem, running a contingency. The voltage profile, branch flows, and mismatches that come out of that action are results, and there is no record button for them. To get results into Python for further analysis, you query them deliberately through the data-retrieval APIs documented in Chapters 7–9 of the API reference (api.pdf, in the installation’s doc folder).

System-level and single-element queries

Most retrieval APIs return a tuple whose first element is an error code (0 means the call succeeded) followed by the value. Complex returns carry real and imaginary parts — for power, real is MW and imaginary is MVAr. A representative set:

The pattern is consistent across element types — busdat for buses, brndat for branches, ardat for areas, and their relatives for zones, machines, plants, and loads. The API call stays the same; the keyword (PU, KV, CHARG, RATEA, GEN, and so on) selects what you get back. Learn the pattern once and the whole library opens up.

5. Scaling Up: Lists and Iteration for Bulk Retrieval

Querying one bus at a time is fine for a spot check, but interconnection studies need results for hundreds of elements. Python lists — ordered, iterable, mutable collections — turn a single-value query into a bulk operation. Define the elements of interest, loop over them, and collect the results:

Two details matter in practice. First, Python is zero-indexed — the first element of a record is at index 0, not 1. Second, indentation is syntax, not decoration: the body of a loop must be indented consistently or the interpreter will reject it. With those in hand, the same template extends naturally to branches, transformers, and contingency sets — the foundation of any automated screening routine.

6. Response Files, the CLI, and Progress Output

Python is the most powerful automation surface, but PSS/E offers two complementary mechanisms worth knowing.

Response files (.idv) and recorded scripts

When you record an activity, you can save it either as a Python script or as a response file (.idv) — a batch format that replays a fixed sequence of activities. Recorded option flags appear as 0s and 1s (again reflecting zero-based indexing). Response files are ideal for deterministic, repeatable solve-and-report sequences; Python is the choice when you need logic, loops, and data handling around those steps.

The Command Line Interface (CLI)

PSS/E’s CLI, reachable from the command-line input section of the output bar, lets you load cases and run reports without touching the GUI — for example, opening a case with the CASE activity (entry is case-sensitive), listing data by category, locating elements with FIND, or screening voltages with a limit check (VCHECK) that flags buses outside a defined band (with Vmax greater than Vmin). The full CLI command set spans roughly twenty documented chapters and is a fast path for interactive, no-GUI investigation.

Capturing the progress report (PDEV)

The iterative solution log — the progress output — is more than a status readout; it is a diagnostic record. Through Input/Output Control, the Direct Progress Output (PDEV) option redirects that log from the terminal to a file. This is invaluable when reconciling a case migrated between platforms (for example PSLF, PSCAD, or DIgSILENT into PSS/E): capture the progress output before and after each adjustment, then compare logs to see exactly which changes drove convergence. You can append successive runs to one file and set the lines-per-page for clean review.

THE ENGINEERING PAYOFF

Automation is not about replacing engineering judgment — it is about removing the manual, error-prone steps that stand between a solved case and a defensible result. Scripted retrieval is repeatable, auditable, and fast, which is exactly what regulators, interconnection customers, and internal QA all expect of a modern study workflow.

Case Studies

The following case studies are drawn from Keentel Engineering project experience. In keeping with our confidentiality practice, all client names, project names, locations, and proprietary identifiers have been removed; figures are representative and rounded to illustrate the engineering approach rather than any specific engagement.

CASE STUDY 01

Automated Voltage-Compliance Screening Across a Multi-Point Interconnection Portfolio

Challenge.

 A developer client advanced a portfolio of utility-scale generation and storage project sharing a congested study area, requiring steady-state voltage screening across more than 1,500 monitored buses under a large matrix of dispatch and contingency conditions. The original workflow relied on manual, bus-by-bus inspection in the PSS/E GUI after each solved scenario. The effort was slow, difficult to reproduce between analysts, and prone to transcription error when results were copied into spreadsheets for the compliance narrative.

Approach. 

 Keentel replaced the manual review with a Python layer driving PSS/E externally. A version-aware startup routine initialized the engine identically on every run; the monitored-bus set was loaded once into a Python list; and a screening function iterated the list with busdat, retrieving per-unit voltage for each bus after every solved scenario. Every API return was error-code-checked before use, and results were paired with bus identifiers using zip() and written directly to a structured output file — eliminating manual copying entirely. Buses outside the applicable voltage band were flagged automatically, mirroring a CLI-style limit check but applied programmatically across the full scenario matrix.

Result.

Per-scenario review time fell from hours of manual inspection to a script run measured in minutes, and the screening became fully reproducible: any analyst could regenerate identical results from the same inputs. The structured outputs fed directly into the compliance documentation, and the error-code checks surfaced two silently failed retrievals in an early batch that manual review would likely have missed — reinforcing the audit value of scripted retrieval in an interconnection-study context.

Engineering takeaway. 

List-driven iteration over single-element APIs turns a tedious manual task into a repeatable screening tool. The discipline that makes it defensible — standardized initialization, error-code checking, and direct-to-file output — is what distinguishes production automation from a one-off macro.

CASE STUDY 02

Cross-Platform Case Reconciliation During a Power-Flow Model Migration

Challenge. 

A client needed a large base case migrated from a different power-system platform into PSS/E for an interconnection study, then validated to confirm the migrated model behaved consistently with the source. After import, the case did not converge cleanly, and the team needed a structured way to identify which adjustments restored convergence — without resorting to undocumented trial-and-error that would be impossible to defend later.

Approach. 

Keentel combined PSS/E’s Direct Progress Output (PDEV) with scripted data extraction. Before and after each modeling adjustment, the iterative progress log was captured to file via PDEV, building a documented trail of how each change affected the solution path and tap-stepping behavior. In parallel, a Python routine extracted system totals (systot for load and generation) and key bus voltages (busdat) from both the source-platform export and the PSS/E case, then compared them element by element to quantify discrepancies and confirm alignment as the model was tuned. Successive progress runs were appended to a single log for side-by-side comparison.

Result. 

The captured progress logs isolated the specific adjustments that drove convergence, and the scripted comparison confirmed that migrated system totals and voltage results matched the source model within an acceptable tolerance once tuning was complete. The result was a defensible reconciliation package — progress logs plus a quantitative discrepancy report — that documented not just that the migrated case converged, but exactly why, and that it represented the same system as the original.

Engineering takeaway. 

Progress output is a diagnostic asset, not just a status readout. Pairing PDEV capture with scripted, element-by-element comparison converts an opaque convergence struggle into a documented, reviewable migration — the kind of traceability that holds up under study review.

Disclaimer & Notice

This document is provided by Keentel Engineering for general informational and educational purposes only. Code patterns are illustrative and simplified to convey workflow; API signatures, option vectors, and behavior vary by PSS/E version, and you should consult the API and CLI references shipped with your installation for authoritative usage. Examples reference the standard sample case distributed with PSS/E.

The case studies are anonymized composites of project experience; all client, project, and location identifiers have been removed and figures are representative. Nothing herein constitutes engineering, legal, or procurement advice. PSS®/E is a registered trademark of Siemens; PSLF, PSCAD, DIgSILENT, Python, and other product names are the property of their respective owners. Their use here is solely for factual technical context and does not imply any affiliation with, endorsement by, or sponsorship of Keentel Engineering.

Frequently Asked Questions