PSS®E dynamic model validation for data centers: a disturbance-data workflow

A .dyr file that imports is not yet a validated model

A PSS®E dynamic model can be syntactically valid, initialize without error, and still describe the wrong facility. Import proves that the file can be parsed. Initialization proves that the selected model and case can establish a starting state. Neither proves that the active and reactive power response, current limit, cease fraction, reconnect delay, or restoration ramp matches the site.

For a data-center load model, validation should connect four things:

• the physical claim, such as “40 percent of compute load ceases after this voltage condition”;
• the source, such as an as-left UPS setting, commissioning test, or terminal disturbance record;
• the executed model behavior in the named PSS®E version; and
• the review boundary, including conditions the evidence did not test.

Dominion Energy Virginia’s current customer-delivery-point criteria request CMLD, PERC1, and/or a user-defined model representing the load facility in PSS®E format. NERC’s computational-load alert asks planners to collect the dynamic characteristics, UPS configuration, protection, reconnect, and composition data needed to populate that kind of model. The file and the evidence belong together.

The minimum useful disturbance record

For positive-sequence terminal validation, the smallest useful record normally contains synchronized voltage magnitude, frequency, active power, and reactive power at—or correctly referred to—the model boundary. It also needs enough pre-event data to establish the operating point and enough post-event data to observe the recovery or reconnect sequence.

COMTRADE, DFR, PMU, relay, meter, and commissioning-system exports can all be useful. File type alone does not establish fitness. A 30-sample-per-second record cannot substantiate a 10-millisecond timing claim, and a frequency channel that never leaves nominal cannot identify frequency droop regardless of its precision.

A seven-step PSS®E dynamic model validation workflow

1. Freeze the review target. Name the authority, study stage, PSS®E version, steady-state case, model class, electrical bases, and point of interconnection.
2. Ingest the evidence. Preserve source records and settings, normalize channels explicitly, and write provenance before manipulating the trace.
3. Reproduce the baseline. Import the existing model, capture defaults and initialization, and verify that independent implementations agree on the starting response before calibration.
4. Lock what is independently known. Bind cease thresholds, timer delays, reconnect settings, fractions, and bases to reviewed settings where available. Do not let an optimizer move them merely to improve the overlay.
5. Screen identifiability. Ask whether the event excites each proposed fit parameter and whether the sensitivity directions are distinguishable at the available sample rate.
6. Calibrate and hold out. Fit only the supported continuous parameters, use robust normalized residuals, and score the result against an event that tests a different behavior or disturbance class.
7. Export and replay. Render the final PSS®E artifact from the reviewed parameter set, execute it in the exact accepted version, compare its trace to the reference, and bind the results to the artifact hash.

This order is deliberate. If fitting starts before the tool version, bases, switching settings, and record capability are fixed, the optimizer becomes a machine for absorbing project mistakes into whatever parameters it is allowed to move.

Screen identifiability before optimizing parameters

A parameter is identifiable from a record only when changing it produces a distinguishable change in the observed channels under that event. A perfectly flat frequency channel contains no information about a frequency gain that multiplies frequency deviation. A deep voltage sag that causes the load to cease may contain less information about continuous voltage response than a shallower sag that keeps the load online.

This is why event severity is not a substitute for event content. Before fitting, compute or otherwise review the sensitivity of the proposed parameters over the usable interval. Report rank and conditioning, but do not treat full rank as proof that the chosen fit set contains every mechanism that actually differs.

Our technical note on PERC1 parameter identifiability shows both sides on synthetic records with known truth: clear structural refusals when excitation is missing, and a case where a full-rank fit still returns the wrong value because another differing parameter was held fixed.

Use a holdout that can fail for a new reason

A held-out record should challenge the candidate outside the exact pattern used to fit it. A second voltage sag at nearly the same depth may show repeatability, but it can reproduce the same structural misspecification. When possible, vary the disturbance class, operating point, voltage depth, frequency content, or recovery sequence according to the claim being tested.

If only one record exists, say so. Fit and validation can still be useful, but the claim is reconstruction of that event, not demonstrated generalization to all study conditions.

Replay the exact PSS®E artifact the reviewer will receive

A calibration engine and PSS®E are two executed programs. Even when they expose parameters with the same names, initialization, defaults, parameter order, limit handling, and patch-level behavior can differ. “Exported to PSS®E format” is therefore a weaker claim than “the exported artifact was replayed in PSS®E version X and its terminal response matched the reviewed reference within these tolerances.”

The conformance run should start from the same steady-state operating point, apply the same voltage and frequency input record, align sign conventions and bases, and compare at least active power, reactive power, and the switching/reconnect transitions the model exposes. Save the accepted-tool output as an independent trace; do not compare a renderer to its own runtime and call that external validation.

The thing under review is not the parameter list. It is the behavior of a specific artifact in a specific simulator build.

For the model semantics, see PowerWorld’s current PERC1 documentation. For one current PSS®E delivery requirement, see Dominion Energy Virginia’s April 2026 criteria.

Package the evidence so it can be checked offline

A useful validation report is not just a PDF plot. It should let another engineer trace the result without depending on the original workstation or a live vendor portal. Include:

• requirement source, revision, effective date, and applicable row or reviewer comment;
• model source, target simulator and version, electrical bases, and initialized parameter set;
• source-record hashes, channel mappings, transformations, and normalized event files;
• which settings were locked, which parameters were fitted, and why;
• train and holdout overlays, residual definitions, parameter bounds, rank, and conditioning;
• cease, timer reset, reconnect, and ramp transition ledger;
• PSS®E export hash and independent replay/conformance result;
• limitations, refused claims, open evidence gaps, and the test plan that would close them; and
• approval identity plus a machine-verifiable signature or other chain-of-custody mechanism.

Offline verification can confirm artifact hashes and signatures without exposing the model or record to another service. It cannot recompute a proprietary simulation without the named engine and version. State that distinction explicitly.

State what the validation does—and does not—show

A positive-sequence validation at the point of interconnection can show that an aggregate model reproduces the measured terminal response for the tested events and operating conditions. It does not automatically validate every internal UPS mode, transfer switch, backup-system sequence, harmonic interaction, control instability, or EMT switching transient. Those may require additional records, an OEM model, EMT analysis, or a dedicated commissioning test.

The strongest closing sentence in a validation report is specific: “This artifact reproduces these channels, for these event classes, at this boundary, in this software version, using parameters supported by these records.” That is narrower than “the facility is validated.” It is also much easier for a reviewer to trust.

If the model class itself is still undecided, start with the practical guide to PERC1, ZIP, and CMLD. If the submission inputs are scattered across teams, use the data-center dynamic model requirements checklist to assign the evidence first.

Frequently asked questions

What data is needed to validate a PSS/E dynamic load model?

At minimum, use a time-aligned terminal record with voltage, frequency, active power, and reactive power, plus the channel mapping, units, bases, sample rate, timestamp source, and any filtering or resampling. The event must excite the behavior and parameters being validated.

Does a good measured-versus-modelled fit prove the parameters are correct?

No. Different parameter combinations or an omitted mechanism can produce similar traces. Check parameter identifiability, lock independently known settings, and test the candidate against a genuinely different held-out event.

Why must the exact PSS/E version be recorded?

The accepted artifact is executed software, not an abstract parameter list. Model availability, initialization, defaults, parameter order, and runtime behavior can vary across tools and versions. Record and replay the exact target build used by the reviewer.

Can PMU data validate cease and reconnect timing?

Sometimes, but only within the record’s timing resolution and channel quality. A lower sample rate can miss short timers or make parameters indistinguishable. State the minimum timing claim the data can resolve and request a DFR or commissioning record when needed.