Establishing a Traceable PSS®E Workspace and File Structure

A power-system model becomes defensible only when another engineer can determine which inputs produced which result, and can rerun the case without guessing. In the previous lesson, you mapped the IEEE 9-bus topology and separated physical equipment from a solved operating condition. Now we add the file discipline that makes that distinction practical in PSS®E.

For the IEEE 9-bus case, this may seem formal. For an SPP cluster sensitivity, an ERCOT model-quality test, or a utility data request containing controlled information, it is essential. A .sav file with an ambiguous name such as final_final2.sav is not a study record.

By the end of this lesson, you should be able to create a traceable PSS®E workspace and explain what each core file type contributes to steady-state, fault, and dynamic studies.

---

The central idea: a PSS®E study is a reproducible file set

PSS®E has a working case in memory. You load data into it, modify the network, solve it, and save versions of it. The files around that working case serve different purposes:

• some define the electrical network;
• some preserve a solved operating condition;
• some add short-circuit or dynamic behavior;
• some preserve the state of a simulation already in progress;
• some drive a prescribed disturbance; and
• some record what happened during the run.

Do not treat these as interchangeable “case files.” Their relationships answer different engineering questions.

File type	Main role	Typical study phase	Does it define the full steady-state network?	Does it contain time-domain response data?
.raw	Human-readable static network input or exchange data	Build, import, audit, compare	Yes	No
.sav	PSS®E saved load-flow working case	Solve, modify, distribute a base case	Yes	No
.seq	Sequence and grounding data for unbalanced faults	Short-circuit preparation	Adds fault-specific data	No
.dyr	Dynamic-model records and parameters	RMS dynamic-model preparation	No; depends on a network case	No
.snp	Dynamic simulation snapshot or restart state	After dynamic initialization or during a run	Not independently	Not a plotted response record
Playback file, often .plb	Time-varying input signal to a playback model	Prescribed voltage, frequency, angle, or control-input tests	No	It provides an input trajectory
Dynamic output, commonly .out	Sampled simulation channels	Results and post-processing	No	Yes
.sld	One-line diagram layout and display information	Visualization and review	No	No

The strongest mental model is this:

A file extension tells you the artifact’s role, not whether the artifact is correct, current, approved, or suitable for your question.

A .sav can be perfectly solved but based on the wrong season, topology, dispatch, or project size. A .dyr can load successfully but represent a plant controller with the wrong setpoint, model version, or parameter order. Traceability must therefore record both the files and the assumptions behind them.

---

RAW and SAV: specification versus saved working case

The practical difference between .raw and .sav is foundational.

A RAW file is a text-based power-flow data representation. It contains the static network specification: buses, loads, generators, branches, transformers, shunts, areas, zones, ownership, and related power-flow records. Because it is text, it can be inspected, compared between revisions, and generated or edited carefully with controlled tools.

A SAV file is PSS®E’s saved, binary load-flow working case. It stores the case as PSS®E understands it, including the network data and the current solved state. It is normally quicker and more convenient to open for routine work than rebuilding from text inputs.

The distinction is similar to keeping an approved input-data package separately from a solved study database in ETAP: the solved case is useful, but it does not replace the source specification or explain every data transformation that occurred before solution.

What belongs in each file?

For this course, use the following practical rules.

Use RAW files to preserve static source data and auditable network changes. A RAW file is appropriate when you want to:

• import a published IEEE 9-bus dataset;
• archive a received static network package;
• compare two network revisions using a text-diff tool;
• document a limited set of static modifications; or
• exchange static data with another PSS®E user under an agreed format and version.

Use SAV files to preserve a solved, usable case at a named study milestone. A SAV file is appropriate when you want to:

• save the imported and successfully solved base case;
• preserve a scenario before applying contingencies;
• create a with-project or without-project starting point;
• distribute a working static case to a reviewer; or
• provide the static network foundation for a dynamic simulation.

A key caution: saving a .sav does not make it self-documenting. For example, suppose you add a 300 MW solar project at bus 5 and reduce output at the swing machine to maintain balance. The resulting .sav stores the outcome, but not necessarily the engineering rationale for that balancing choice. Record the rationale in a scenario note or manifest.

A naming pattern that survives review

Avoid names based only on informal status words such as new, test, or final. Instead, encode the study identity, scenario, and revision.

For example:

IEEE9_BASE_SUMMER_R00.sav
IEEE9_SOLAR150MW_BUS5_R01.sav
IEEE9_SOLAR150MW_BUS5_LINE4_5_OUT_R01.sav

For actual interconnection work, the identifier should also distinguish the source case and study phase. A useful name might include the provider, cycle, season/year, scenario, and controlled revision number. Do not put confidential project names in a filename if the file may be distributed outside the authorized study environment.

---

Sequence data: why a solved power flow is insufficient for unbalanced faults

A steady-state power-flow model represents the positive-sequence network needed to solve normal three-phase operating conditions. A short-circuit study, especially an unsymmetrical fault such as single-line-to-ground or line-to-line fault, needs more.

A SEQ file contains sequence-network and grounding-related data used to establish the positive-, negative-, and zero-sequence behavior needed for fault calculations. Depending on the equipment and study, that includes sequence impedances for generators and other devices, transformer winding connection and grounding information, and sequence representations of network elements.

The key distinction is:

• .raw and .sav establish the main power-flow network;
• .seq provides the additional sequence information required for credible unbalanced-fault analysis.

A .seq file is therefore not a substitute for a .raw or .sav case, and a valid solved .sav is not automatically sufficient for a fault study.

This becomes especially important at renewable and BESS POIs. For a three-phase fault-duty screening calculation, positive-sequence data may dominate the calculation. But for a single-line-to-ground fault, transformer vector group, grounding impedance, and zero-sequence paths can materially change the result. A generic or missing sequence-data package can make an apparently precise fault result meaningless.

For the IEEE 9-bus exercise, preserve the .seq file separately even if you are not yet running faults. That builds the correct habit: fault data have their own provenance and validation requirements.

---

DYR: dynamic behavior is additional data, not a property of the SAV

A .dyr file contains PSS®E dynamic-model data. It associates models and their ordered constants with network elements in the static case. A dynamic model can represent, for example:

• a synchronous-machine model, exciter, governor, and stabilizer;
• a converter representation;
• inverter electrical controls;
• a plant power controller;
• voltage or frequency protection; or
• a load or relay model.

The DYR does not replace the steady-state case. It relies on a compatible .sav because its records refer to buses, machine identifiers, and other objects that must exist in the network model.

For a utility-scale solar or BESS plant, a minimal conceptual model bundle is not just “a DYR.” It is usually:

1. a compatible solved .sav network;
2. a .dyr file containing the dynamic records;
3. any required user-model libraries, often supplied as compatible .dll files and supporting dependencies;
4. documentation establishing the PSS®E version, model-library version, and parameter source; and
5. a clear initialization and test procedure.

For this lesson, do not edit a DYR by guessing at constants. You will learn its record structure and renewable-model chains later. For now, make the discipline explicit:

• Keep the received or approved DYR as an immutable source file.
• Save any edited version under a new controlled name.
• Record exactly which SAV, DYR, and user-model library version were used for every dynamic result.
• Never assume that a DLL compiled for one PSS®E release will work correctly with another release.

A DYR that references a bus or machine ID absent from the SAV will fail or behave incorrectly. More subtly, a DYR can point to the right equipment but initialize differently after a static-case change. Dynamic results always need both static and dynamic traceability.

---

Snapshot, playback, and output: three time-domain files with opposite directions

Dynamic work introduces a common source of confusion: three files can all be associated with time, yet they serve very different roles.

Snapshot: preserve the state of an initialized simulation

A snapshot, commonly saved with a .snp extension, preserves the dynamic simulation state at a particular instant. It is useful for restarting a compatible dynamic simulation without repeating all prior steps.

A snapshot is typically created after dynamic conversion and initialization, or at a defined point during a simulation. It contains much more than the static topology: it preserves state variables needed for the models to continue from that instant.

Treat a snapshot as a restart artifact, not as an authoritative model source.

A snapshot must remain linked in your records to:

• the SAV case used to create it;
• the DYR loaded at initialization;
• the dynamic user-model libraries;
• the PSS®E version and build;
• the initialization conditions; and
• the simulation time at which it was saved.

If any of those dependencies change, do not casually reuse the snapshot.

Playback file: prescribe an input

A playback file is an input time series used by an applicable playback model. It may prescribe a changing voltage, frequency, phase angle, active-power order, or another signal, depending on the playback-model implementation and test setup.

In PSS®E workflows, .plb is a common playback-file convention, but the exact format and supported signals depend on the installed models and the study procedure. Its function is what matters:

A playback file tells the simulation what external signal to apply over time.

For example, an MQT test setup may use a playback signal to impose a specified POI voltage excursion. The file is part of the test definition. It needs its own metadata:

• signal names and units;
• scaling and sign convention;
• initial value;
• sample interval;
• event start and end times;
• source requirement or test procedure; and
• any interpolation behavior used by the playback model.

A malformed playback file can create a valid-looking plot of the wrong test. Always plot or inspect the applied source signal along with the plant response.

Output file: preserve the response

A PSS®E RMS dynamic run commonly writes sampled channels to a dynamic output file, often with a .out extension. These channels may include:

• POI voltage and frequency;
• plant MW and MVAr;
• inverter current components;
• controller references;
• generator speed or electrical power;
• relay status; and
• bus angles or branch flows.

The output is evidence of the simulated response; it is not the input case or test definition. Preserve it with the associated event script, playback file if used, and a log of simulation messages and warnings.

A sensible dynamic-run folder might therefore contain:

MQT_LVRT_SCR3_R01/
  IEEE9_MQT_SCR3_R01.sav
  PlantModel_R05.dyr
  OEM_UserModels_PSSERelXX/
  LVRT_Profile_R01.plb
  MQT_LVRT_SCR3_R01.snp
  MQT_LVRT_SCR3_R01.out
  MQT_LVRT_SCR3_R01.log
  run_manifest.md

The exact PSS®E output and log-file conventions can vary by release and by how the study is executed. Preserve the actual filenames used by your environment rather than renaming files after the fact without recording the mapping.

---

SLD: a useful one-line, not the model of record

An .sld file is a PSS®E single-line-diagram or “slider” file. It captures the visual layout and display choices used to show buses, branches, transformers, generators, loads, and result overlays.

An SLD is valuable because it lets you visually inspect the case: voltage coloring, branch loading, topology, and equipment status are much easier to review on a one-line than in a spreadsheet.

However, an SLD is not the authoritative electrical database. It can be stale, incomplete, or opened against the wrong case. A polished one-line can therefore conceal a modeling mismatch.

Use these rules:

• Open an SLD only with its identified companion SAV case.
• Record the SLD revision in the manifest if it appears in a report or review package.
• Verify important numerical findings using the actual SAV data and reports, not color alone.
• Never infer that equipment exists, is in service, or has a particular rating merely because it is drawn on a diagram.

The curated PSS®E introductory note also describes the SLD as a visual display capable of showing equipment and operating information. That is its value: it supports review and communication, while the static case remains the electrical source of record.

---

Build a workspace before building the nine-bus case

Create one project root folder for the training case. The point is not to impose a universal folder structure; it is to make the lineage of every important result obvious.

A practical structure is:

IEEE9_PSSE/
  00_source/
    published_static_data/
    published_sequence_data/
    source_notes/
  01_build/
    data_conversion_notes/
    manual_entry_records/
  02_cases/
    base/
    scenarios/
  03_dynamics/
    dyr/
    user_models/
    playback/
    snapshots/
  04_runs/
    powerflow/
    faults/
    dynamics/
  05_results/
    plots/
    tables/
    reports/
  06_documentation/
    manifest/
    assumptions/
    change_log/

What “traceable” means in practice

At minimum, create a short README or case manifest in 06_documentation/manifest/. For every saved case or major run, capture the following:

Record item	Example of what to document
Study and case ID	IEEE9_BASE_R00
Purpose	Initial published-data reconstruction for training
PSS®E environment	Installed PSS®E release, patch/build, operating system if relevant
Static source	Dataset title, source location, received date, checksum if available
Parent case	File from which the new SAV was derived
Static modifications	Bus, branch, transformer, load, machine, or shunt changes
Scenario assumptions	Dispatch, load level, balancing method, in-service topology
Sequence source	SEQ filename, revision, source, and changes
Dynamic source	DYR filename, model-library version, and any user-model dependencies
Simulation definition	Fault, switching event, playback profile, time step, duration, channels
Outputs	Output file, plot package, report, and reviewer status
Known limitations	Simplifications, unresolved warnings, missing data, or excluded tests

For text inputs such as RAW, SEQ, DYR, playback files, and scripts, version control is often practical and highly valuable. For large binary SAV, SNP, SLD, and OUT files, retain controlled copies in your designated storage and record their revision, path, and—where permitted—checksum.

Protect source files and preserve lineage

Use a simple status convention:

• Source: received, published, or otherwise authoritative input; do not overwrite.
• Build: files used to translate or construct a working case.
• Base: solved case before project changes or contingencies.
• Scenario: a controlled derivative that changes a stated set of assumptions.
• Run: a simulation execution using a particular scenario and test definition.
• Result: plots, tables, reports, and logs generated from that run.

For a future utility or SPP package, this separation also helps with confidentiality. Keep controlled or CEII-restricted files in the approved storage location; do not mix them with public training cases, personal cloud folders, or shareable report directories.

---

A repeatable lifecycle for this course

The following workflow will be used repeatedly, from the nine-bus case through larger network, MQT, and sensitivity work.

1. Preserve the source package. Keep RAW, SEQ, DYR, diagrams, and documentation unchanged in 00_source.

2. Create a documented working case. Import or build the static network, solve it, and save a clearly named base SAV.

3. Add only one defined set of changes. For example, add a project, alter dispatch, or apply a topology change. Save the result as a new scenario SAV rather than overwriting the base.

4. Attach the applicable analytical data. Load SEQ for fault work; load DYR and compatible user models for dynamic work.

5. Define the test. Record contingencies, event times, playback input, simulation duration, channels, and acceptance basis.

6. Run and retain evidence. Preserve outputs, logs, snapshots when relevant, plots, and the exact case files needed to reproduce them.

7. State the conclusion with its conditions. A result should always be read as “under this named case, these assumptions, this topology, and this model revision.”

This sequence prevents a common failure mode: a reviewer sees a violation plot but cannot determine whether it came from the approved base, a modified case, an incorrect DYR, or a different disturbance profile.

---

A compact file-selection guide

Before opening PSS®E, identify the question and the minimum controlled file set.

Question	Minimum controlled starting artifacts
“Does the IEEE 9-bus base case solve?”	RAW or existing SAV, plus source notes
“What changes after a line outage?”	Solved base SAV, contingency definition, saved scenario/result record
“What is the single-line-to-ground fault current?”	Solved SAV, compatible SEQ, fault assumptions, output report
“Does the plant ride through an LVRT event?”	Solved SAV, DYR, user-model libraries, initialization procedure, event or playback definition, dynamic output
“Can I resume a dynamic run from 10 seconds?”	The compatible dynamic setup and its SNP, with all dependencies recorded
“Why did PSS®E and PSCAD produce different traces?”	Both platforms’ network equivalents, dispatch, controls, disturbance definitions, measurement definitions, and outputs

Notice that the answer is almost never “open only the latest SAV.” That discipline will become particularly important when comparing PSS®E and PSCAD results later in the course.

---

Key takeaways

A .raw file is a text representation of static power-flow input data; a .sav file is PSS®E’s saved binary working power-flow case, including its solved condition. Preserve both when possible: RAW supports auditability and comparison, while SAV supports efficient, repeatable study execution.

A .seq file adds the sequence and grounding data needed for credible unbalanced-fault studies. A .dyr file defines dynamic models and parameters but depends on a compatible static case and, where applicable, compatible user-model libraries.

For RMS dynamics, a snapshot preserves the simulation’s state for restart, a playback file prescribes a time-varying input, and an output file records response channels. An .sld file is a valuable visualization artifact, but never the authoritative network data source.

Most importantly, establish your workspace before you construct the case: preserve source inputs, create named derivative cases, retain run evidence, and maintain a concise manifest connecting every conclusion to its inputs and assumptions.

Next, you will begin translating the published IEEE 9-bus topology into PSS®E bus and branch records.