| name | convergence-failure-mitigation |
| description | Senior power-engineer playbook for power-flow convergence failures. Use whenever a base case or post-change case diverges, oscillates, or fails to solve in PSS/E, PSLF, PowerWorld, pandapower, PyPSA, surge, or OpenDSS. Triggers on "power flow diverged", "case won't solve", "did not converge", "blown-up voltages", or "max iterations reached". Every tool skill stops on a non-convergent base case — this playbook is what to do next, separating data errors from numerical fragility from genuine physical infeasibility. |
Convergence failure mitigation
Start from the failed solve and its mismatch report. The goal is to learn why it failed, not just to force a solution.
Preferred action order
- Rule out data problems first: isolated or de-energized buses, zero or absurd branch impedances, missing or misplaced swing bus, transformer tap and phase-angle data, load/generation totals that cannot balance.
- Check islanding and slack coverage: every energized island needs a slack with feasible MW. Use the tool's island or topology report before touching solver settings.
- Simplify the solve, then restore: try flat start vs warm start, lock taps, switched shunts, and phase shifters, relax generator Q-limits — then re-enable controls stepwise once a solution exists.
- Seed from an easier point: a DC solve, a previously solved neighbor case, or a reduced-stress version of the case, then scale load or transfer toward the target in steps.
- If failure persists only near the target stress level, treat it as a feasibility boundary, not a numerical bug: reduce transfer or load, add reactive support, and flag possible voltage-collapse proximity.
Working rules
- The largest mismatch bus tells you where to look — start there, not with global solver settings.
- Change one solver setting at a time and record what finally solved.
- A case solved with controls locked or Q-limits relaxed is not finished; restore realism before reporting results from it.
- Distinguish "the math failed" from "the operating point does not exist" — the corrective actions are completely different.
Deliver
- The failure category: data error, control interaction, numerical fragility, or physical infeasibility.
- The specific change that made the case solve.
- Any realism caveats that remain (locked controls, relaxed limits) and what to re-check.
