For a long time I thought a system got hard to model once it had enough moving parts. Payroll for a large employer has thousands of employees and a thicket of tax and pension rules. It’s tedious to model, but it isn’t hard. Given the inputs, the outputs follow, and once the rules are right you’re done.
I changed my mind by watching small systems misbehave. A small grid with a wind farm, a battery and a gas unit on standby has perhaps a dozen variables worth tracking. It’s much harder to model than payroll, because the variables push on each other, some of the rules only switch on past a threshold, and the people running it change what they do once they can see where the numbers are heading.
That’s the usual line between complicated and complex, and it changes the first question. With payroll you ask whether you’ve captured every rule. With the grid you decide what to leave out, and that decision settles more about whether the model is any good than the choice of algorithm.
Start with what can change
Before I write any code I try to list the states and the events. What can change? What changes it? Is anything conserved, like cash in a ledger or energy on a grid, so that a model which loses some is obviously broken? Where does uncertainty come in, and is it the kind you can put a distribution on or the kind you can’t?
The answers usually choose the technique for you. Something with conservation and time steps wants a simulation. A set of obligations that switch on and off wants rules. Most real problems are a mix, which is why I get uneasy when a project picks its tool in the first meeting.
A battery, worked through
The grid simulation started as a side project. In one version the question was whether a small system could get through a still evening without starting its reserve gas unit. Here it is with round numbers, for illustration rather than output from the model.
Say wind has been strong all day and there’s 100 MWh of surplus to put into a battery that holds 120 MWh. The forecast for the evening peak is low wind, which leaves demand 30 MW above what the wind and the baseload plant can supply for three hours. That’s a 90 MWh gap. The dispatch rule is simple: the battery charges from surplus wind and discharges when there’s a shortfall, and if it can’t cover the gap, the gas unit starts.
The chart runs it three ways: with no losses, with 85% round-trip efficiency, and with those losses plus an operator who tops the battery up by 20 MWh from baseload the night before.
The first model most people build is the first bar. It balances energy hour by hour and tells you something useful straight away: the battery is big enough, just. And “just” is carrying the whole answer.
The second adds round-trip losses.1 Nothing else changes. Losses sound like a detail to tidy up later, but 15% of 100 MWh is 15 MWh, and the answer flips from covered to a gas start. That’s the easy kind of omission, because it’s physics and the number can be measured.
The third is the harder one. An operator who can see a still evening coming will act on it. Topping up from baseload the night before puts another 20 MWh in, which is 17 MWh at the peak after losses, and the gas unit stays off. The overnight energy isn’t free, though, and the forecast still has to be right.
Whether that happens depends on who controls the battery. If the system operator runs it, pre-charging is a line in the operating procedures. If it belongs to a trader paid on prices, it may sell into an afternoon price spike and arrive at the evening peak half empty. Then what it does depends on the contract between the two, and you have to read that contract to know which bar you’re on.
So “does the gas unit start?” has no single answer. It depends on what people choose to do, and a model that reports one answer hides the choice.
One effect I expected to count for something didn’t. Batteries lose capacity as they cycle. But at the fade rates usually quoted, a few weeks of daily cycling takes well under 1% off capacity, which is smaller than the error on the wind forecast, so I left it out. For a ten-year question it would be one of the first things in.
Why not model everything?
You could answer all this with more model. Add the degradation anyway. Add the trader’s bidding strategy. Add an operator who pre-charges with some probability whenever the wind forecast drops below a threshold. Computing is cheap, so why choose?
Bigger models do sometimes surface interactions nobody guessed. That’s the fair case for agent-based simulation.
My objection is about what you can calibrate. Losses and degradation are physics, known well enough that putting them in tends to make a model more right. Whether an operator pre-charges depends on the procedures they work to, and on how much the control room trusts tomorrow’s wind forecast. Neither is in any dataset you can get hold of. Put that behaviour in as a probability and you’ve written a guess as a number, then buried it inside a model where it looks like a result.
So I’d put the losses in and keep the operator out of the mechanics, as a switch the user sets: pre-charge ahead of a low-wind forecast, or don’t. The model shows what each costs and whether the gas unit starts, and people can argue about which is likely. They know the control room better than I do.
When the question changes
Building the smallest model that still shows the behaviour you care about has two weak spots.
The first is that it assumes you know which behaviour you care about. A power engineer would put the losses in without thinking and might never ask whose battery it is. Someone who has spent years reading contracts, as I have, asks about ownership straight away and could quite easily forget the losses. Either could leave something out, and nothing in the method would warn them. At most it makes the gap easier to see once someone who knows points at it.
The second is timescale. A simulation that steps hourly can balance supply and demand perfectly well and say nothing useful about the few seconds after a large generator trips, which is where a lot of the resilience question sits. Ask it a question about those seconds and it will still give you a number.
Reuse is where this usually bites. A model built to answer “does the gas unit start on Thursday evening?” gets reused a year later to decide how much storage to buy, and nobody checks whether ignoring degradation still makes sense for a question about ten years of operation.
So at the top of every model I now write, in plain English, the question it was built for and what it leaves out on purpose. For the battery model that list would read: demand is fixed; losses are a single round-trip figure; the battery charges only from surplus wind unless the pre-charge switch is on; no degradation; hourly steps, so nothing about the seconds after a trip. It’s the first thing I reread when someone wants to use the model for something else.
- Round-trip efficiency is the share of the energy put into storage that you get back out. For lithium-ion systems figures in the 80s are commonly quoted, but it moves with temperature and with how hard the battery is driven, so treat the 85% here as illustrative. ↩