Power system contingency analysis on a large transmission network holds up only when three disciplines work together: the N-2 cases it studies are physically credible and chosen on purpose rather than enumerated blindly, the contingency list matches the network as it is built today, and the full run finishes inside the window in which operators have to act. Brute-force enumeration of every N-2 combination is realistically infeasible, which forces operators to rely on screening or engineering judgement. The time window is not a matter of taste either: NERC requires each Transmission Operator to ensure a real-time assessment is performed at least once every 30 minutes.
A library of synthetic cases sampled uniformly is skewed towards contingencies that are unlikely in practice. A critical N-2 list depends on the operating point and has to be updated regularly. A run can work in development and fail in production for reasons that have nothing to do with the solver. The rest of this article takes each in turn. TechnoLynx’s wider engineering for grid operators is described on its page on AI and GPU engineering for energy and utilities.
Generating N-2 contingency cases your power system has never seen
Published studies generate N-2 cases by simulation on network models, including synthetic grids such as ACTIVSg2000. A steady-state scenario is a complete system model with a power flow solution that can be adapted to represent a broad range of operating conditions. Researchers at Texas A&M describe a general procedure for building such scenarios: set the load and generation level, apply scheduled outages, then fix unit commitment and dispatch. Commercial packages such as PSS/E and PowerFactory, and open tools such as PyPSA, all solve the power flows this needs. Published contingency studies have also used open Python environments such as VeraGrid and pandapower.
A converged power flow shows that the scenario has a feasible solution and gives a starting point for contingency analysis, optimal power flow or transient stability studies. When a scenario is far from the base case, Newton-Raphson can diverge; the same Texas A&M work moves the solution towards the target in incremental steps, using each step’s solution as the next initial guess. A case that converges only because the solver was coaxed into it still deserves a second look: a negative dV/dQ sensitivity at a bus indicates that a low-voltage solution has been reached.
A 2026 feasibility-guided diffusion approach reports a 94.5% AC power-flow convergence rate on the EU 36-bus system. In the paper’s ablation study, removing the feasibility guidance cut N-1 convergence from 76.8% to 54.7%. INL and FSU’s GAN-based SCANN, which predicts higher-order contingencies from N and N-1 training data, was evaluated in preliminary studies on a 5-bus system. We would treat both as research leads rather than production generators, because a scenario being feasible says nothing about whether it is likely.
Is there a standard stress-scenario library to validate against?
Public datasets do exist: PF∆ provides 859,800 solved AC power flow instances with N-1 and N-2 perturbations across six systems from IEEE-14 to GOC-2000. PF∆ removes randomly chosen generators and lines with equal probability. That makes PF∆ useful for testing solvers and learned models, but it is no substitute for a library built on your own topology and outage history.
Where synthetic cases stop being trustworthy
A synthetic case is only as credible as the grid model behind it, and steady-state screening is a filter, not a verdict. Steady-state simulation is much faster than dynamic simulation, so it is used to prescreen extreme contingencies, rank them and pass a limited number of the most severe to in-depth dynamic simulation. The two can disagree in both directions: a combination flagged critical by steady-state screening may prove benign under dynamic simulation, or the reverse. Steady-state analysis also assumes nominal frequency throughout. Including machine dynamics reveals failures that static power flow models mask.
How do we focus N-2 analysis on the combinations that matter?
Focus comes from screening and weighting, not from more enumeration. The scale problem is plain: for a system with 5,000 branch elements, the number of double branch outages is almost 12.5 million. Davis and Overbye tested a 5,395-bus, 7,616-line system based on a large North American utility, where every double line outage gives 28,997,920 events.
This is where TechnoLynx looks first, because the largest gains are frequently found by changing what is computed rather than how. The published methods fall into a few families:
- Certified screening. Kaplunovich and Turitsyn (IEEE, 2016) build safety certificates that prove most contingencies safe without solving them, with a guaranteed zero missing rate in DC approximation models. Their method filtered 99.9% (Summer) and 99.1% (Winter) of non-islanding double outages on a 2,737-bus grid in two iterations, and across the cases tested ran 30 to 1,000 times faster than brute force.
- Sensitivity-based lists. On the 7,616-line system, Davis and Overbye’s outage-tracking list of 598,504 contingencies (2.06% of all double outages) captured over 99% of the double outages with violations.
- Disturbance-value ranking. Columbia researchers show that ranking cases by disturbance value cuts the number to be analysed by more than 90%, with approximation error below 10% in most cases on the 118- and 300-bus systems.
- Learned screening with a guarantee. Input-convex neural networks can be trained to a provably zero false negative rate; on the IEEE 39-bus system they gave 10-20x speedups with a 2-5% false positive rate. Ordinary neural networks in the same study showed 1-3% false negatives, so they cannot reliably be used for screening.
Weighting generation toward failures that actually happen
Uniform sampling treats every N-2 pair as equally likely, and Zhou, Dobson and Wang argue that this assumption skews sampling towards contingencies that are unlikely in practice. In their Bonneville Power Administration example with 528 lines, there are 139,128 possible double contingencies, of which 2,116 (1.5%) are pairs of lines sharing a common bus; yet 81% of the double contingencies that actually occurred over 14 years were of that shape. Physical causes behind this motif include a stuck breaker in a breaker-and-a-half substation, primary protection failing so zone 2 operates, and hidden relay failures.
The risk index proposed in a 2026 HPC study weights the severity of each contingency by the failure frequency of the elements involved. That study used uniform literature rates on the IEEE 118-bus system, but its framework supports component-specific failure rates drawn from operational data. Its result is a useful warning against spreading effort evenly: a small set of components produced most of the expected annual risk.
If you build such priors, treat them as uncertain inputs and check the sensitivity of your ranking to them, because a confident wrong prior just moves the blind spot.
A simpler heuristic also appears in the literature. One Texas A&M cascading study chose the 100 most heavily loaded lines out of 2,345 and simulated every pair: 100 × 99 / 2 = 4,950 N-2 scenarios.
Screening approaches compared
| Approach | What it guarantees | Published scale | Main limit |
|---|---|---|---|
| Safety-certificate screening | Zero missed overload contingencies in DC approximation | 2,737-bus grid; 30-1000x across cases tested | Guarantee holds only in the linearised model |
| Outage-tracking sensitivity list | None; over 99% of violating double outages captured in test | 7,616-line utility-based system | Weaker than inner tracking on violations needing both outages |
| Disturbance-value ranking | None; error under 10% in most test cases | IEEE 118- and 300-bus | Cannot by itself identify important contingencies |
| Motif-based selection | None; probability coverage from history | BPA and NYISO outage data | Needs outage history; neglects rarer patterns |
| ICNN classifier | Provable zero false negatives | IEEE 39-bus | Significant offline training cost |
Is our synthetic N-2 library representative, or just large?
A synthetic N-2 library is representative when it covers the outages that actually occur and the structural variety of the network, and generation volume proves neither. Zhou, Dobson and Wang split 19 years of BPA outage data, using the first 14 for analysis and the last 5 for testing. A deterministic list of 6,831 motif contingencies accounted for 78% of multiple outages in that test data. The same authors suggest motif-based lists can help confirm a utility’s own contingency selection.
Random-walk topology perturbations can preserve coarse topology statistics while weakening contingency margins. The PF∆ authors name scalable generation with high feature diversity for networks with thousands of nodes as an open problem. In practice we would check three things before trusting a library: hit rate on held-out outage records, agreement with the engineers’ existing list, and a dynamic spot-check on a sample of cases the steady-state screen passed.
How do we keep the contingency list in sync as equipment is added or retired?
A contingency list stays accurate only if every equipment change triggers a mandatory list update, one named role owns that update, and a reconciliation check compares the list with the network model on a schedule. The base list is typically retrieved from the EMS database and then enabled and modified by hand before contingency analysis uses it.
The record of failures is specific. In August 2003, a Cinergy 230-kV line was out of service but its status had not been updated in MISO’s state estimator, which produced a solution with an unacceptable mismatch. Later that afternoon a flowgate monitoring tool assumed an outaged line was still available and so did not predict the next overload. In a NERC lesson learned, an error in a model topology change file stalled real-time contingency analysis for 46 minutes. That error was absent in the development environment and was introduced when the change migrated to production. NERC’s conclusion was that real-time tools, state estimators and contingency analysis need validating on the production system after a model change, with automated review, peer review or both.
For planning, NERC TPL-001-5.1 requires Transmission Planners and Planning Coordinators to prepare an annual Planning Assessment, keep the rationale for selected contingencies available, and coordinate so that contingencies on adjacent systems appear on their lists. For the operational list, we recommend naming the role that owns updates. Our recommendation is that an equipment change ticket cannot close until the owner of the list has signed off the list update. Cadence matters too: the critical N-2 list depends on the operating point and has to be updated regularly.
Drift check between network model and contingency list
Run this at every model release and on a fixed schedule in between; tighten the schedule if the network changes faster than you review it.
- Every in-service line, transformer and generator in the production network model has a matching contingency entry, or a recorded reason for exclusion.
- No contingency entry refers to an element that is retired, renamed or absent from the model.
- Elements commissioned since the last review appear on the list with the change ticket that added them.
- Contingencies on adjacent systems that can affect yours are present and match the neighbour’s current topology.
- After any model change, contingency analysis has converged on the production system, not only in development.
- The rationale for each selected contingency is recorded where an auditor can find it.
How long should a full N-1 contingency analysis run take, and is it fast enough?
Full N-1 contingency analysis is fast enough when its measured end-to-end time, on the production model with production data, leaves margin inside the decision deadline. NERC sets the outer limit by requiring each Transmission Operator to ensure a real-time assessment at least once every 30 minutes. The four US ISOs below run real-time contingency analysis every one to five minutes. We would treat a run measured in tens of minutes as a warning sign.
TechnoLynx starts this work by characterising your existing N-1 workload (solver type, the data flow from SCADA and the EMS, forecasting inputs) and agreeing the shift-change latency target, then profiles where the time actually goes before choosing between software optimisation, hardware acceleration or workload triage. TechnoLynx delivers the optimisation through its Inference Cost-Cut Pack, with results checked against your existing full-run baseline for both accuracy and timing.
For reference, published RTCA cycles at US ISOs look like this:
| Operator | Contingencies simulated | Cycle |
|---|---|---|
| MISO | More than 11,500 | Every four minutes |
| PJM | About 6,000 | Every minute |
| CAISO | About 2,200 pre-specified | Every five minutes |
| ERCOT | About 4,000 modelled (2012) | Executes every five minutes; heuristic screen, then full AC |
Some operators prioritise instead of evaluating the whole list each cycle. PJM’s database holds every contingency, but not all of them are evaluated in each RTCA run. ERCOT runs a heuristic screen to find the most severe contingencies, then full AC analysis on those plus a pre-specified set. The cost of prioritisation is coverage: Newton Energy Group notes that limiting contingency constraints by offline assessment misses relevant events as the system state changes in real time. A ranked subset should therefore be paired with a periodic full run, or with a screen that carries a guarantee.
Is the bottleneck compute or the data pipeline?
The bottleneck has to be found by profiling the whole chain, because contingency analysis depends on data as well as arithmetic. Real-time contingency analysis relies on a base case from a state estimator, so losing the state estimator also removes contingency analysis. In the NERC case, a topology file error kept real-time contingency analysis from converging for 46 minutes.
When the solve itself is the limit, check whether the software can use the hardware. PNNL identified that most commercial power-industry tools were optimised for single-processor computers, with core algorithms developed 10 to 30 years ago for much smaller models. In the 2026 HPC study, each contingency ran as an independent task of around 30 seconds and total time scaled almost linearly as resources were added. Its authors suggest that this scaling could bring the full workflow within operational timeframes of under 15 minutes. PNNL’s BPA example processed 400 power-flow contingencies plus dynamic cases on a 16,000-bus WECC-size model in under 5 minutes with 400 processors, and under 10 minutes with 200.
In Newton Energy Group’s MISO study of 2,324 contingencies (21,761,936 constraints), the volume of data forced the GPU algorithm to solve contingencies in batches, limiting parallelism.
| Symptom | Likely bottleneck | What to fix first |
|---|---|---|
| Run waits on state estimator convergence | Data and model quality | Telemetry, topology status, model change control |
| Tool optimised for a single processor | Serial solver software | Parallelise over contingencies |
| Many full AC solves on a long list | Compute volume | Screening before full AC solves |
| GPU memory full, contingencies processed in batches | Data volume on the device | Reduce data held on the GPU, or split across devices |
| Works in development, fails in production | Model migration error | Validate tools on the production system after model changes |
LynxBenchAI publishes results showing how each device runs the public PyTorch stack, broadly indicative for a learned screen such as an ICNN classifier written in PyTorch; the LynxBenchAI results are a starting point for choosing hardware, not a measurement of your power-flow solver, your EMS or your contingency run time.
Who can help us make contingency analysis fast enough for the control room?
TechnoLynx profiles, ports and optimises the compute-heavy parts of contingency analysis so a full run fits the decision window your operators work to. On whether to build in-house or bring in a specialist: if your team already profiles and parallelises its own solvers, keep the work in-house; if the run is slow and nobody can say why, bring in outside profiling first. That work is delivered through the Inference Cost-Cut Pack. When choosing any partner, ask to see their validation against a baseline, not only a speedup figure.
This is engineering help, not regulatory sign-off: compliance evidence and protection settings remain with your engineers and auditors. Small Transmission Operators may not need an EMS-based RTCA at all; NERC notes that outage distribution or shift factor calculations can be adequate for monitoring SOL exceedances.
What the published speedups do and do not prove
The screening results above are strong evidence that N-2 analysis can be made tractable, and weak evidence about your network. The 2026 HPC study demonstrates systematic N-2 analysis on a medium-sized system and expects the workload to grow substantially on larger networks. The ICNN results come from the IEEE 39-bus system. The zero-miss guarantee of certified screening holds for contingencies critical in the DC approximation. Even good screens can miss the hardest cases: the inner tracking algorithms Davis and Overbye tested captured between 30.6% and 66.5% of contingencies that violate limits only when both lines are out.
So the question to settle on your own system is not which method is fastest on paper, but which misses you can tolerate and how you will find out. A miss-rate metric that reliability auditors accept, a replay harness comparing a new screen against the legacy study over the same historical and synthetic cases, and an evidence pack for regulatory review each need to be designed on their own.
FAQ
What does contingency analysis mean?
Contingency analysis is a “what if” simulator that evaluates and prioritises the impact on a power system when a line, generator, transformer or other element fails. It uses a simulated model of the network to calculate overloads resulting from each outage.
What are the N-1 contingency criteria for power systems?
The N-1 criterion requires the system to withstand and recover from the loss of any single element. In NERC TPL-001-5.1, single contingencies (category P1) include loss of a generator, transmission circuit, transformer or shunt device.
