Cases / Power-grid software
Power-grid software said its calculation worked, at nearly a million times the normal voltage
- It said
- The calculation worked.
- Actually
- Part of a 400-volt network came out at nearly a million times its normal voltage.
- Then
- Reported to the developers. Still open; a contributor plans to add my test cases.
pandapower is open-source software for modelling electricity networks. I gave it 18 kinds of transformer. For seven it said the calculation had worked, with no warning. Four of those seven were physically impossible.
The technical record
Converged. No warning.
A 0.4 kV bus at about a million times its rated voltage.
pandapower’s three-phase power flow returned converged=True, with no warning, for four transformer types it does not support. The results were physically impossible: low-voltage buses at about a million times their rated voltage (about 994,686 per unit), transformer loading of 714%, and a 10.9 MW power-balance residual on a 0.1 MW load. Eleven other types were refused with an error.
The software has answered. Nobody has checked it yet.
A skipped step
For these four transformer types, the software skipped the step that should have refused them, so it calculated anyway and reported success.
Zero-sequence modelling is skipped for these four strings before the gate that rejects the other unsupported types.
Reported to the developers
Reported with all 18 results as pandapower issue #3122. Still open; a project contributor plans to add the 18 cases as a test.
“It worked” wasn’t true
For these four types, the software’s report of success meant nothing. The three that pass every check look plausible; they are not proven correct.
Technical record: all 18 results
Per unit means multiples of the normal voltage. The five checks: values finite; low-voltage bus magnitudes between 0.9 and 1.1 per unit; external-grid power in band; power balance under 0.001 MW; transformer loading under 100%. One network, one load, zero phase shift.
| Type | Supported | Solver said | Low-voltage buses (per unit) | Checks passed |
|---|---|---|---|---|
Dyn | Yes | True | 1.050 | 5 of 5 |
YNyn | Yes | True | 1.050 | 5 of 5 |
Yzn | Yes | True | 1.051 | 5 of 5 |
Yyn | Unclear | error raised | n/a | n/a |
Dy | No | True | 994,686 to 994,688 | 1 of 5 |
Yy | No | True | 994,686 to 994,688 | 1 of 5 |
Yd | No | True | 994,686 to 994,688 | 1 of 5 |
Dd | No | True | 994,686 to 994,688 | 1 of 5 |
YNd | No | error raised | n/a | n/a |
Yny | No | error raised | n/a | n/a |
ZNyn | No | error raised | n/a | n/a |
ZNd | No | error raised | n/a | n/a |
ZNy | No | error raised | n/a | n/a |
Zd | No | error raised | n/a | n/a |
Yy0 | No | error raised | n/a | n/a |
YNd5 | No | error raised | n/a | n/a |
Dyn5 | No | error raised | n/a | n/a |
Yzn5 | No | error raised | n/a | n/a |
How the finding was reached
Claim
When
runpp_3phreportsconverged=True, the result is a valid three-phase power flow.Test
I ran all 18 transformer vector-group strings found in the source, the docs and the shipped standard types, on the network from closed issue #1041, each in its own process. Before running, I recorded the expected outcome of every one (the prediction file is not public). Every result that reported convergence then went through five sanity checks a power engineer would apply.
What happened
The three supported types converged and passed all five checks. Eleven types raised the intended
NotImplementedError: ten documented as unsupported, and one whose support status is unclear in the docs. Four unsupported types (Dy, Yy, Yd, Dd) reported convergence and failed four of the five checks, with results identical to the last digit.Trying to break the finding
Could the checks be wrong rather than the solver? The same five checks passed all three supported types. Could the environment have drifted? A known-good type and a known-bad type were re-run the same day and matched earlier runs to the digit, and the source tree was diffed against the pinned archive afterwards. Is it a quirk of one network? The cause is in the control flow: zero-sequence modelling is skipped for those four strings before the gate that rejects the other ten.
Evidence
All 18 results matched the recorded predictions. The full 18-result matrix and a reduced reproducer are public on the issue thread. A commenter on the issue checked the current branch and agreed with the control-flow explanation.
What survives
On this commit, for these four transformer types,
converged=Trueis not evidence of a valid result.
What this does not show
One network, one load, zero phase shift, one pinned commit. The supported types were shown plausible, not correct: no independent power-flow solver was run as a reference, and line loading (109% on one line in the supported cases) is not one of the five checks.
If this had been your system
If this were your solver, you would have received the 18-cell matrix, the five checks and their thresholds, the control-flow cause, a one-file reproducer, and a regression test that fails until the gate covers all unsupported types.