Transmission Planning Study Management Problems: The 7 That Cost You a Rerun, and How to Avoid Them

Why does the project get scoped as a results dashboard instead of case lineage?

Planning groups drown in results, so the request that starts the project is almost always about seeing them: a violation browser, filters by season and scenario, charts by circuit. That is genuinely useful and it is quick to build against whatever output files exist today.

What it does not fix is the reason the results are untrustworthy. Every violation in your report is the output of a specific composition: a model version, an assumption set, a contingency definition, a set of parameters and a code path. Change the load forecast vintage and the violation moves. Change one retirement assumption and it disappears. Build a dashboard on top of a folder tree named 2026_Summer_Peak containing forty one saved cases with names like base_final_v3_rev2_USE_THIS, and you have made untraceable results easier to browse. The dashboard then gets quoted in a report, somebody disputes it, and the same three days of archaeology happen with a nicer front end.

Make lineage the first release and the dashboard the second. Model the study as a directed graph: a base case is a node, every transformation is an edge carrying the script, its parameters and who ran it, and the derived case is a node that can be regenerated rather than stored. Every results record references the node that produced it. The acceptance test is that an engineer picks any published violation from last year and reproduces it by replaying a path, in under an hour, without opening an inbox.

What goes wrong when you bring in the existing folder tree of saved cases?

Teams assume the migration is copying files into managed storage. It is not, because the files are opaque binaries and the meaningful information is not inside them, it is the relationship between them. What made base_final_v3_rev2 different from base_final_v3 is a change list nobody wrote down: this generator dispatched down, this line added, this load scaled.

Two failure modes follow. The first is volume: saved cases across seasons, scenarios and sensitivities grow into tens of terabytes fast, and a team that decides to preserve everything hands the utility a storage bill for data almost none of which will ever be opened again. The second is worse. Importing cases without their derivation gives you a catalogue that looks like lineage and is not, so engineers trust it, and the first dispute reveals that the system knows a case existed but not how it was made.

Reconstruct forward rather than backward. Bring in the base cases and the assumption sets that are still live, register them as nodes, and start capturing derivation from the next study cycle onward. For historic studies that carry real exposure, meaning anything under active dispute or feeding a project in a rate proceeding, reconstruct the lineage deliberately with the engineer who ran it, and mark everything else as archived with no derivation claim. An honest gap is defensible. A catalogue that implies lineage it does not have is not.

Why do the solver integrations break after launch?

Driving PSS/E through its Python interface, PowerWorld through its automation interface and TARA through its own is three integrations, not one, and each fails on its own terms. What breaks after launch is usually not the interface. It is the environment around it.

Licensing is the reliable one. Solver licences constrain how much you can parallelise, and a job runner that ignores licence accounting will either exhaust the pool and fail loudly or serialise itself into uselessness. Then a licence server moves, a version is upgraded, or a seat is reassigned during a busy week, and a batch that ran fine on Friday stalls on Monday. The second is version drift: a solver upgrade changes output formatting or default behaviour, and the parser that reads results keeps working while quietly misreading a column. The third is the script layer, since the transformation scripts your engineers write are the actual product and they evolve constantly.

Make licence awareness a first class feature of the queue, not an afterthought. Concurrency should be bounded by available seats with jobs queued rather than failed. Pin and record the solver version against every result, so a version change invalidates the right runs instead of silently producing incomparable numbers. And treat the transformation scripts as versioned artefacts inside the lineage graph, because a result produced by script version 4 is not the same result as one produced by version 3 even with identical parameters.

What happens when non convergence and reporting formats are not covered?

A batch of 600 cases runs overnight on a workstation under somebody's desk. Case 340 fails to converge. The script may keep going or may stop, and either way nobody finds out until morning, at which point the engineer reruns everything because they cannot tell which results are stale. That is the visible cost. The invisible one is far worse: if non convergent cases are quietly dropped, the study reports fewer problems than exist, which is the single worst failure available in this domain.

The second gap is reporting. The format arrives from your regional transmission organisation's business practice manuals and it is not negotiable, so somebody spends two weeks reshaping data by hand. Underneath that sits the deduplication problem: the same physical violation appears across dozens of contingencies, seasons and sensitivity runs, and the useful output is not a list of violations but a ranked list of distinct problems. Doing that reduction by pivot table is where planning engineers lose their weeks.

Require explicit non convergence handling in the specification: flag, classify and preserve the failing inputs for inspection, never drop. Give each violation a stable identity based on the monitored element and limit type so cross run analysis becomes a query. Land results in a columnar store and keep the raw output, because your grouping logic will change and you do not want to rerun 600 cases to change how a report is grouped. The regulator facing format then becomes a rendering step, so a manual change is a template edit rather than another fortnight.

Should you build custom or configure what you already own?

Buy the solvers, always. Siemens PSS/E, PowerWorld Simulator, DIgSILENT PowerFactory, PowerGEM TARA and PSCAD represent decades of validated numerical work, and any proposal that involves building your own power flow or dynamics engine should end the conversation on the spot. Keep paying for them and keep upgrading them.

Do not build the workflow layer at all if your group runs a handful of studies a year on a small footprint with two engineers who genuinely do hold the composition in their heads. Disciplined naming conventions and a shared assumption spreadsheet carry a small transmission owner further than people expect, and the money is better spent on solver licences and compute. We say this to groups regularly and it is usually correct for them.

Build when at least two of these are true. Cluster study deadlines under the current interconnection process make your throughput a compliance exposure rather than a workload problem. You have been asked to reproduce a result more than a year old and struggled. Your case count per assessment cycle runs into the thousands. More than three engineers touch the same study track. Or a result of yours has already been challenged by a developer or an intervenor, which is the moment lineage stops being a convenience and becomes evidence.

How do hidden costs get into the quote?

The number of distinct solvers is first and it is the one people understate, because a group that mostly uses PSS/E will mention TARA in passing and expect it to be free. It is a separate adapter with its own job semantics, its own failure behaviour and its own result parsing. Name every solver on the first call, including the one used by a single engineer for a single annual task.

Electromagnetic transient work in PSCAD alongside steady state is the second and it is not an increment. The data volumes and runtimes differ by orders of magnitude and the post processing question is different, so it belongs in its own phase with its own budget. Stability work is the third for the same reasons: dynamic simulation results are much larger and screening them is a different problem from thermal and voltage.

The fourth is footprint. Multiple regional transmission organisations means multiple business practice manuals, multiple report formats and multiple process conventions, and each is real work. Start with one study type, usually the annual thermal and voltage assessment, and one solver. Groups that try to model every study the department performs before shipping anything spend a year specifying and deliver nothing, and the $80,000 to $170,000 first release band over 12 to 18 weeks assumes the narrower scope.

What separates a build that works from one that fails here?

Ask a candidate developer whether they will store derived cases or regenerate them. The right answer is regenerate from lineage and store selectively, and a team that has not thought about it will propose keeping every binary and hand you a storage problem measured in tens of terabytes. Ask how they handle solver licence limits in the job queue, because orchestration that ignores this fails the first time it tries thirty concurrent jobs against a pool that allows eight.

Ask what happens to a non convergent case. The answer must include flagging, classification and preserving the failing inputs. Anything that quietly drops them produces a study that understates problems, and in this domain that is the failure with the longest tail. Ask how stale results are detected: when a base case is corrected, the system should mark exactly the downstream results that are now invalid rather than leaving an engineer to guess, and that single behaviour removes most of the wasteful rerunning.

Put ownership in the contract before kickoff, including the right to export the results store in an open format, because study evidence may need to be produced in a proceeding years after the developer relationship ends. Then run the test that costs nothing: hand a candidate one real past study and ask them to sketch how their model represents it. A planning engineer in the room will know within fifteen minutes whether the sketch survives contact with your actual process.