Why One Customer's Solar Can't Cause Overvoltage
Seventh entry in this series, and the start of a new thread: does the same audit discipline that found operating state dominates over event magnitude in German redispatch data hold up somewhere structurally different — Australian rooftop-solar-driven overvoltage instead of German redispatch-driven undervoltage? Same methodology, different country, different physical direction entirely. This post is where that thread starts, and it starts with a very small result.
The setup, and the opposite direction
Everything from the German series carries over on purpose: causal threshold calibration from the first 10% of a stream, exhaustive AC-validated audit of every event (not a sample), the same magnitude/rate-of-change selector. What's different is the physics. German redispatch data drives under-voltage on a benchmark MV network. Rooftop solar export drives over-voltage on a real Australian LV feeder — the violation criterion flips from V < 0.90 p.u. to V > 1.10 p.u., and the network comes from real CSIRO/ARENA taxonomy data instead of a CIGRE benchmark.
The first real network tried (Network H — uniform three-phase, no transformer) let the solver run cleanly, which was worth confirming before anything else: inject power at a bus, watch voltage respond. It did, monotonically. But the actual test was whether a single customer's realistic solar capacity could ever push that response far enough to matter.
The test, and the honest result
5.5 kW is CSIRO's own documented default for a single residential system — the taxonomy report's own Table 15 figure, not an arbitrary round number. Attached at the best available bus (the one closest to the transformer, most favorable for voltage rise), it moved the network to 1.016 p.u. — real movement, but nowhere near the 1.10 p.u. threshold.
So the test was pushed further: 100 kW at the same bus — nearly 20× a realistic single-customer capacity, well past anything one real rooftop system could ever export. That reached 1.014 p.u. Barely more than the realistic case, and still nowhere close.
That's not a bug in the solver. It's a real finding: a single customer, however hard you push the number, cannot move voltage meaningfully on this class of network. Overvoltage from rooftop solar, if it happens at all, has to be a collective phenomenon — many customers exporting simultaneously, not one customer acting alone.
Spreading didn't help either
The natural next question: if one customer can't do it, what about several? Twelve real customers were placed at twelve different buses across Network H, spread across the network rather than concentrated. If anything, this made the effect smaller — voltage rise is local, not additive across a whole network the way you might naively expect from summing injected power. Concentrating the same twelve customers at one shared-service bus didn't help either.
That result pointed at something more specific than "need more customers": Network H itself, not the single-customer or spread-customer assumption, was the limiting factor. A uniform three-phase network with no real per-phase asymmetry doesn't have the electrically remote, high-impedance corners where voltage rise actually concentrates in a real LV feeder.
What this ruled out, cleanly
Two real possibilities eliminated, not assumed away: a single customer cannot cause overvoltage regardless of capacity, and spreading customers across a network dilutes the effect rather than compounding it. What was still open was whether a different network — one with real single-phase residential connections and genuine electrical remoteness, rather than Network H's uniform three-phase layout — would behave differently. That's where this series goes next.
Reproducibility: single-customer and multi-customer smoke tests
# Single customer, escalating capacity, Network H, best available bus
for capacity_kw in [5.5, 100]:
# attach one PVSystem at the most favorable bus, solve
# 5.5 kW -> 1.016 p.u.; 100 kW -> 1.014 p.u. -- neither near 1.10 p.u.
pass
# 12 customers, spread across Network H at 12 different buses
# vs. 12 customers concentrated at one shared-service bus
# Neither configuration reached 1.10 p.u. -- spreading diluted the effect,
# concentrating it at Network H's available buses didn't fix the underlying
# topology limitation.
Full scripts (superseded, kept for the record rather than deleted):
au_engine_dss.py, au_engine_dss_multi.py in the Australia repository.
