Grid Designer is a free simulator that allows you to design and test a zero-carbon grid for the UK, and test it using real-world demand and weather data. This article explains how the model works, and what it might teach us about our energy choices.
Have you ever wondered how hard it will be to transition to green energy? 🌍
With energy and climate rarely out of the news cycle, I started asking myself these questions. As I learned more, I began to think about how our energy system and choices might be modeled in software.
The result of this exploration is Grid Designer – a simple game that allows you to design your ideal green energy grid and test it using real UK energy demand and weather data. It works best on mobile, and you can try it out here.
The fun thing about creating software to solve a problem is that it requires us to understand the problem deeply enough to describe it in code. This article explains how the sim was built, and how we might think more clearly about energy sources: their benefits, tradeoffs, and costs.
If we are to meet our climate ambitions, we need our electricity system to be zero carbon. Not mostly green, not nearly zero – zero.
Therefore the model focuses exclusively on scalable zero-carbon energy sources:
Solar ☀️ (Photovoltaic)
Wind 💨 (On-shore & Offshore),
Nuclear ⚛️ (Fission)
Batteries / Storage 🔋
Other sources such as hydro and geothermal power can only be deployed in very select places, and so are excluded. The same applies to theoretical technologies like Fusion – as exciting as they might be, my focus is on the most plausible solutions to the climate crisis.
We also need 100% uptime from our grid. Civilization should not and will not tolerate a step backward in living standards. If our green energy system cannot meet demand, we must expect a fallback to fossil fuels and a failure to reach zero CO2. Communities will not tolerate blackouts or rationing. We must optimize for abundance.
Given the rapid fluctuations in demand and the intermittency of some renewable sources, I wanted to model the system in high resolution. This means every hour for an entire year.
The simulator is focused on the UK, but the software can be applied to any country or group of countries (nations import & export power).
The sim includes an imaginary budget of £400 billion. This number is quite arbitrary, and its purpose is to make sure players consider the constraint of capital. The UK can’t spend a trillion on its grid! Complex financial topics like amortization, unit lifespan, and recycling costs are beyond its scope.
Wherever possible I've leaned towards optimism -- whether its cost or energy output. This sim is focused on power production and consumption only, meaning advanced topics like efficient electricity transmission are not included.
The aim is not to create an ultra-high fidelity model, but something that is accurate enough to be thought-provoking and informative!
Let’s begin…. ⚡️
Just how much power do we need? I was able to get a csv file containing 10 years worth of national grid data recorded at 5m intervals. The file was too big for excel (>1M rows), so I used Python to isolate the year 2021 and calculated the average demand each hour. Converted into JS it looks something like this:
export const uk_grid_demand_2021 = [
// Jan 1st - each value is avg demand by hour, starting at 00:00. (MWs)
[28956, 28183, 27092, 26254, 25416, 25050, 25632, 25740, 26609, 28927, 31482, 33423, 34821, 35424, 35540, 36051, 38430, 40352, 39044, 36578, 34266, 32093, 29887, 27168],
// Jan 2... etc
]
Demand varies across the year, and throughout the day:
Next, we'll look at how we can model individual energy sources: Solar Power, Wind, Nuclear, Storage, and Fossil Fuels….
solar: {
name: 'Solar',
unit: 'hectares',
unitToMw: 1.2, // 1.2 hectares = 1 MWp
capex_per_mw: 0.92, // Million USD per MWp
opex_per_mw: 0.017,
}
Area is the key unit to consider when scaling solar power. As we design our grid, we'll define the amount of solar panels we want in hectares.
Solar panels have a 'rated capacity' defined by the unit Megawatt peak (MWp)
. A solar array rated at 1 MWp can generate 1MW electrical power in ideal conditions. The actual output will depend on factors like latitude, orientation, and weather. Of these, latitude is most significant when designing a grid: a panel placed in the South of France will come much closer to its 'rated' performance than the same panel placed in Scotland.
In Grid Designer I’ve assumed we’ll place our solar panels exclusively in the South of England, where the most solar energy is available. Based on government figures we assume that 1.2 ha of land is required for every 1 MWp of panels.
Solar Rated Capacity (MW) = Area in Hectares * 1.2
To calculate the output each hour we use data from the Global Solar Atlas
You will notice how power output varies across the day and throughout the year. In the short days of December, our Solar farms will yield just a tenth of the energy they provide in the summer. At height of summer, our solar panels will produce about half of their rated capacity at noon.
Note: Our solar reference data is grouped by month instead of actual day. This means the solar model is less granular than for other sources : Every day in Jan is considered the same, then it changes for Feb, and so on. We also ignore weather, generously assuming ideal conditions at all times.
The simulator uses the above data to compute the hourly output for each day in the year: Output = solarOutput[month][hour] * MWp
NB: You can view real-time UK solar output on the University of Sheffield's Solar website.
The cost of PV Solar panels has fallen precipitously in the last 20 years and solar is celebrated for its very low running costs. Our Capex and Opex figures are taken from the National Renewable Energy Lab’s forecasts for 2025.
Note that we only consider large-scale solar installations to be viable. Rooftop solar is at least twice as expensive per MWp as utility-scale solar farms, and there is not enough appropriate roof space available to meet demand at a national scale. Equally, panels placed at higher latitudes are much less cost-effective than those in the south.
Finally, the financial estimates for Solar exclude land costs, which will be significant given the areas required in places like Kent and Cornwall! The model also doesn't take a view on the ecological and biodiversity costs of repurposing farmland and hedgerows for panels.
wind_l: {
name: 'Onshore Wind',
unit: 'Turbines',
unitToMw: 4, // i.e 4MW Turbines
capex: 1.7, // Million USD per MW
opex: 0.02,
}
wind_os: {
name: 'Offshore Wind',
unit: 'Turbines',
unitToMw: 15, // i.e 15 MW Turbines
capex_per_mw: 6.04, // Million USD per MW
opex_per_mw: 0.12,
}
To model wind, we’ll set the number of onshore and offshore wind turbines we would like to build. The simulator distributes these at existing sites across the UK and uses historical weather data to model the energy output. This is done every hour for an entire year.
Our onshore and offshore turbines are modeled based on open-source information from the National Renewable Energy Laboratory.
Historic hourly wind speed data has been gathered using Visual Crossing's weather API. These data were processed in python and are made available to the sim in a separate JSON file.
The weather data denotes wind speed recorded at a height of 10m. However, wind speed increases with distance from the ground, and will be higher at the altitude of a wind turbine. This is why turbines (and sailing ships) have such tall masts: the higher the mast, the more energy available. The increase in wind velocity depends on the friction of the surrounding surface, called 'roughness' (see here for an explainer).
For our onshore turbine sites, we have assumed a roughness of 0.055m, and adjusted wind speed for a turbine hub height of 110m. For offshore we assume a roughness of 0.0002m, and adjust wind speed for a hub height of 150m. All values were converted to m/s.
The operating performance of a wind turbine is described by its power curve.
Below the cut-in
wind speed, the blades cannot turn and no power is generated. Above this threshold, the power output follows a curve up to the turbine's maximum output. The value at which a turbine reaches its maximum output is its rated wind speed
. Turbines will continue to operate at close to their maximum output until they reach their cut-out
speed – that is the wind speed at which the rotor must apply brakes to avoid damage.
To create the simulator, I simplified the curve of the power curve to a straight line:
For wind speeds above the cut-in
value, we calculate the power output using the formula for a straight line: y = mx + c
, where y
is the output in MW, m
is gradient, x
is windspeed, and c
is the y-intercept.
The power curve data for our simulated onshore and offshore turbines has been taken from the NREL's GitHub. The values are defined in code as follows:
// Onshore Turbine 4MW, 110m
const wl_power_curve = {
cut_in: 3.25, // m/s
rated: 9.75,
cut_out: 25,
}
// Off-Shore Turbine 15MW, 150m
const ws_power_curve = {
cut_in: 4,
rated: 11,
cut_out: 25,
}
A wind gust is a short period of increased windspeed. The API source data includes values for gusts that lasted at least 25 seconds, and in many cases, these are greater than the turbine cut-out
wind speed. However, I was not able to find consistent data from manufacturers on how exactly turbines respond to gusts and thus have excluded them from our model. Maintenance downtime for turbines is small (~24 hr per year) and has also been excluded.
Modern turbines are capable of turning to face the wind in any direction, and so we assume they do this immediately and perfectly. When air passes across a blade's surface it creates turbulence or a wake, which reduces the energy available to any turbine downstream. Wind Farms are designed to minimize this by positioning turbines to optimize for the prevailing (most common) wind direction. Hence these effects are usually small and I have not included them in the model.
In the course of this work, I was surprised to learn that wind speed values are not averages. Instead, they are the highest sustained wind speed in that time period. Hence, if the API says the wind speed was 15 m/s on Tuesday, we can only be sure that this threshold was recorded once the entire day. The average wind speed may have been much lower.
This has important implications for any modeling, since using daily windspeed values leads to huge overestimations of power output. Consider the following real example:
In the red line, we can see the 'daily' windspeed of 5.3 m/s. If used for every hour of the day, the turbine operates at 30% of its rated output (red-shaded area). Yet, if we look at the hourly data for the same day in blue, we can see that for most hours the maximum recorded wind speed failed to meet the Turbines cut-in threshold, and the total energy produced was much less (blue shaded area).
Wind is intermittent, so fine-grained resolution is essential to understand the performance of turbines.
Each hour we calculate wind output as follows for each site:
// installed_mw = number of turbines * MW rating of turbine. const m = 1 / (power_curve.rated - power_curve.cut_in) const c = -1 * m * power_curve.cut_in let output;
if (windData[d][h] < power_curve.cut_in) {
output = 0
}
else if (windData[d][h] > power_curve.cut_out) {
output = 0
}
else if (windData[d][h] >= power_curve.rated) {
output = installed_mw
}
else {
// y = mx + c; x=wind speed, y=power output, c = y-intercept
let y = m * windData[d][h] + c // Fraction of rated output
output = y * installed_mw
}
return output
This code finds gradient (m) and the y-intercept (c) of our simplified power curve. If the windspeed is above the cut-in threshold and below the rated threshold, it calculates the fraction of maximum out (y) based on the wind speed, and uses this to return the output in MW.
At present, the simulator provides data for just 1 onshore and 1 offshore wind farm site (Scout Moor & Hornsea), and this is certainly a limitation! By adding more sites we could mitigate the risk of low-wind days on the simulated grid: if the wind isn't blowing in Hornsea, it may be blowing off the coast of Kent or Aberdeenshire. This strategy is valid but requires us to 'over-build' on each site to compensate for the others, increasing costs, and wouldn’t help on days when wind speeds are low at a large number of sites.
Cost assumptions are taken from the US Energy Information Agency.
We set the number of turbines we wish to build onshore and offshore.
We locate our turbines at existing wind farm sites across the UK, and use real weather data from 2022 to calculate output.
At present only 2 sites are available for simulation.
Windspeed is adjusted for the height of each turbine and the 'roughness' of the surrounding land/sea.
We use a simplified power curve to calculate turbine performance.
Output is modelled on an hourly basis, 365 days of the year.
The effects of gusts and turbine wake are ignored.
nuclear: {
capacity_factor: 0.9,
capex_per_mw: 7.0,
opex_per_mw: 0.13,
}
Nuclear power is a divisive topic, and sadly not all of the criticism leveled at it is supported by the evidence. I'll get into specifics in a different post, but I think a fair summary of the technology would be to observe the following:
Nuclear is generally more expensive and time-consuming to build relative to other sources. However, it produces enormous amounts of zero-carbon energy, with extremely high uptime, at low marginal costs per MW.
Grid Designer models nuclear in terms of 'power stations', using the recently commissioned Sizewell C as a reference. Using a well-established PWR design, its two reactors will provide a total of 3200MW of energy over its 60-year lifespan.
There are other nuclear reactor designs with different cost and output profiles. These include Small Modular Reactors (SMRs) and Molten Salt Reactors (MSRs), however, none of these are as well-established as PWRs and so are not included as an option in our simulator.
Nuclear energy has an extremely high capacity factor. The only time a reactor doesn't produce energy is when it is shut down for scheduled maintenance or refueling. Given these shutdowns are planned events, we'll take a simplistic approach to how we model it: assuming a 90% capacity factor and applying this discount to output year-round.
Hourly output = 3200 * Number of Stations * 0.9
Nuclear plants provide predictable baseline energy:
A similar stable pattern is seen in the UK's actual Grid data.
The cost of building and running a nuclear power plant is hotly debated, with some infamous project overruns. Detractors argue that this proves the unfeasibility of the technology, while defenders point to the importance of consistent investment. South Korea is often cited as an example of a nation that has been able to build its nuclear fleet with increasing speed and decreasing costs. Grid Designer’s cost estimates are again taken from the US Energy Information Agency, and it should be understood that opex costs include fuel and the safe disposal of waste.
3200*0.9
storage: {
name: 'Battery Storage (Li-Ion)',
unit: 'MWh',
capex_per_mw: 0.2, // Million USD per MWh
opex_per_mw: 0.025
}
Electricity storage is essential for grids that rely on renewables – blackouts are not acceptable, so batteries are needed to make up any shortfall caused by wind and solar intermittency.
Battery systems have a rated output - the maximum amount of power they can give at any one time (Megawatts), and a separate capacity value (Megawatt Hours). A fully charged 60MW/240MWH battery system can therefore deliver 60MW for 4 hours, or 30MW for 8 hours, etc.
For simplicity I decided to ignore rated output and focus solely on capacity. This means that we assume our batteries can always meet the output demand, and are only limited by their capacity (in MHW). We also ignore factors like cycle time and overheating.
Since our grid requires roughly 30GW of energy each hour, this means we we would need a 30,000MWH installation to meet 1 hour of demand with storage alone - this is a lot!
Our batteries are either charged or discharged depending on whether or not there is a deficit or surplus of energy available for that hour. The hourly simulator code looks like this:
let d = demand[day][hour];
let s = solar_output + wind_l_output + wind_os_output + nuclear_output;
let balance;
//demand exceeds supply
if (d >= s) {
const deficit = d-s
// ...code to drain batteries
}
//supply exceeds demand
else if (d < s) {
const surplus = s - d
// ...code to charge batteries with the surplus
}
return balance
The cost of batteries and their predicted future cost is debated. The model uses predictions from the National Renewable Energy Laboratory, and assumes a very optimistic $200 per KWH for Lithium Ion. In reality, it is doubtful such a price could be maintained if buying and deploying batteries at grid-scale. For example, powering the UK for just 12 hours (at our current demand level) would require a ~420 GWHs storage solution – more than the annual global production of Lithium Ion batteries! Finally, it’s also worth noting that any such battery would likely need to be replaced every 5 years.
Alternative grid-scale storage technologies like Vanadium Redox Flow Batteries (VRBF) have similar projected price tags, and our model is simple enough that these may be thought of as interchangeable. Iron Air batteries are a technology predicted to be significantly cheaper, but have yet to enter large-scale production.
It is worth remembering that every penny spent on storage is a penny that could have spent on energy production.
fossil_co2_mwh = 233 // Kg CO2
Whenever our green energy grid cannot meet the demand we will fall back to fossil fuels. We assume an optimistic 233kg of CO2 per MWH of fossil-fuel electricity by using natural gas (source). NB: The UK's current average is >500kg.
Grid Designer considers any CO2 release as a failure – in other words, we want to completely decommission the UK’s fossil fuel infrastructure. Although the overarching mission is net zero, the cost of removing CO2 from the atmosphere, once emitted is very high ($100-300M per Mt), so much better not to burn it in the first place.
The simulator outputs a 'green uptime' chart (inspired by github!). It shows every day of the year, and gives a visual reference to show many hours the grid ran on zero-carbon energy:
The sim also provides a summary of your grid's performance, including an option for daily analytics.
When assessing performance, the sim is evaluating effective energy output.
This has been a deep dive into the technical thinking behind the simulator. I’ll save my policy conclusions for another post. For now, having researched the topic at some length I’ll simply observe the following:
Feedback, opinions, rebuttals, corrections, and counterfactuals are welcomed in the comments!