Losses & allocation
Network losses split per device (iron / copper / line losses) with the annual energy and cost, plus the transformer efficiency grade and temperature rise.
Select or create a scheme to open this page
Not run yet — opening this page sends no engine request
Not computed — press Run
About losses and loss allocation
This page answers "who loses how much". Two engine products are shown: the per-device loss allocation table from engines/loss-allocation.js (design.lossAllocation; the option options.lossAllocation defaults to on) and the loss / efficiency / temperature-rise study from engines/studies2.js (study "losses", GB 20052-2020 efficiency-grade typical values, annual loss energy and its cost). The allocation table lists every device as its own row: a transformer is split into a constant core-loss row P0 and a copper-loss row Pk×(S/Sn)², cables, busbar and switchgear connections take the true load-flow branch I²R, the MV incoming cable is its own row, and compensation or reactor branches are listed with lossKw = 0 because the load flow models them as constant reactive injection with no I²R — disclosed instead of invented. Every row carries its share of the total, and the table is reconciled against the load-flow network loss.
Losses are money and heat at the same time: they drive the annual energy cost and the life-cycle cost, they raise the transformer hot-spot temperature and shorten insulation life, and they are the reason a larger section or an efficiency-grade upgrade can pay for itself. Showing the split per device is what makes the decision actionable — whether the iron loss of a lightly loaded transformer or a long feeder is the item worth changing is not visible from the total alone. The reconciliation block is the honesty check: the allocation has to add up to the load-flow loss within a stated tolerance.
Input: the same topology, ratings, sections and lengths as the other pages, plus the transformer no-load loss P0 and load loss Pk, the load flow result and the operating case → chain: engines/loss-allocation.js aggregates, it does not compute a second set of losses: the transformer row comes from the load-flow branch model P_loss = P0 + Pk×(S/Sn)² split into a constant core term and a copper term that follows the square of the loading rate, cable and busbar rows take branches[].lossKw from the real load flow, and a per-row I²R cross-check (3·I²·R) is printed next to it → the table total is reconciled against the load-flow network loss with a 0.5% tolerance, and the pure I²R figure (which excludes magnetising core loss) is shown separately with its difference explained row by row → output: device rows with kW and kvar, shares that add to 100% (the rounding remainder is put on the largest row and marked), the annual kWh and cost, the transformer economic operating band and the temperature rise. Linkage: the section and length of a feeder move its I²R row and the total loss at the same time as they move the voltage drop and the fault current; the transformer loading rate moves the copper row linearly with its square and the hot-spot temperature; the annual energy figure is the one the economics and LCC pages consume. Approximations, all disclosed: capacitor-bank and reactor dielectric and winding loss is not modelled (row shown as 0 with a note), busbar contact resistance and harmonic extra loss are outside the model, and the I²R cross-check carries up to about 2% deviation from branch resistance rounding and from the π-equivalent charging current.
Two lazy cards: the per-device allocation table (moved from /powerflow) and the engine loss/efficiency/temperature study.