Reactive power & voltage optimisation

This page produces an automatic volt-VAR recommendation through studyOptions.enableVoltVarOpt (engines/volt-var-opt.js): which capacitor step to switch in, how much SVG or APF output to use, and which transformer tap to select. The objective is compared lexicographically, in this order — the number of busbars outside the voltage band, the squared sum of the excursions, the over-compensation amount, and then the network loss (lowest wins). The algorithm is a heuristic greedy pass with local search: every candidate single-step action is evaluated by actually calling the existing load flow solver, never by a formula substitution, and any action that switches in capacitance must first pass a resonance re-check. The page also carries the plan-bank what-if card that compares the switching plans side by side. Standards: GB/T 12325-2008 for the voltage deviation band, GB/T 14549-1993 for the resonance re-check, GB 1094.1 / IEC 60076-1 for the 2.5% tap steps.

Voltage deviation and power factor are both compliance items: a busbar outside the band is a reason for the utility to object, and a power factor below the agreed value is charged for by the tariff. At the same time the obvious answer (switch in more capacitance) is exactly the action that can create a resonant condition, so the recommendation has to carry the resonance verdict with it. Having the tap position, the capacitor steps and the SVG output proposed from the same load flow, with the before-and-after numbers shown, is what turns a rule of thumb into something that can be defended in a review.

Input: the topology and loads, the transformer tap positions, the capacitor bank and SVG capacity and step sizes, the acceptable voltage band vMinPu / vMaxPu (default ±7% per GB/T 12325-2008, that is 0.93 and 1.07), the power factor ceiling pfMax (default 0.99) and the iteration limit → chain: a base load flow is solved, then for each round every single-step candidate action is applied and the existing solver engines/loadflow.js solveLoadflow is run for real → the results are compared lexicographically (violation count, squared excursion, over-compensation, network loss) and ties are broken by the smallest normalised action, which favours the best gain per unit of action → before accepting a capacitor step the candidate is re-checked against engines/harmonic-scan.js to see whether it pushes a resonance point towards a dominant harmonic, and if it does the action is downgraded to not recommended with the reason stated → the loop stops when nothing improves or the iteration limit is reached → the recommended setting is then run once more to self-check that the reported after-values match the measured ones → output: the action list, a summary of the before and after minimum voltage, power factor and network loss, and explicit notes. Linkage: capacitor kvar raises the voltage and cuts the loss but lowers h0 and can bring a resonance closer; a tap change moves the secondary voltage and the transformer loss; load cos φ sets the reactive gap and therefore the recommended step; cable section changes the loss and the voltage drop, which are the first and last terms of the objective. Approximations, all disclosed: a heuristic greedy plus local search, explicitly not a global optimum, with no mixed-integer solve, no exhaustive combination search and no continuous optimisation; the control variables are discrete steps.