Every now and then, a new algorithm turns up and claims to revolutionise wind farm layout optimisation — typically a new gradient-free metaheuristic with a name evocative enough for a conference poster. Meanwhile, when you look at how the top performers in the field actually perform against each other on the same problem, the differences tend to be small. IEA Wind Task 37's Case Study 4 makes the point well: a benchmark based on the Borssele III/IV site, with 81 turbines and five disconnected boundary regions. Here, eight published methods — gradient-based, gradient-free, and hybrid — all landed within roughly a quarter of a percentage point of each other on wake loss. Whatever revolution is supposedly underway, it isn’t showing up in results like these. Once a problem is posed properly, most of the differences between rigorously developed algorithms wash out. Which is exactly why I don’t think the algorithm is where a customer’s real risk sits. If every credible method lands within a fraction of a per cent of the others on the same well-defined problem, the thing that actually decides the outcome is whether the problem was well-defined in the first place. That’s not an optimisation question, it’s a modelling one. And it’s where the gap between tools isn’t a fraction of a per cent, it’s however large the underlying mistake happens to be.
This is where I think a lot of layout tools quietly cut corners. Not in the solver, but in what gets handed to it. Spacing rules used as a stand-in for loads. Environmental and social constraints such as noise, shadow flicker, and visual impact are simplified past the point of matching the actual design guidelines, or left out and checked manually afterwards. Terrain, buildings, and existing infrastructure pulled once from a separate GIS tool at the start of a project, then left untouched as the layout evolves. None of that shows up as an algorithm problem, because the solver did its job perfectly on the problem it was given. It shows up as a layout that looks optimised and is quietly wrong: non-compliant, leaving yield on the table in an area that was never actually constrained, or built on an assumption that won’t survive the next planning submission.
None of this is an argument for not caring about the algorithm. Ask any yield engineer and they’ll tell you that 0.1% of production is real money over a project’s lifetime, which is exactly why we still take it seriously and build our own solver rather than treating it as a solved problem we don’t need to think about. It’s an argument for being honest about the size of that number relative to the other one. We ran our own engine against Case Study 4 to see where it landed: second among the eight published results, which is a result I’m truly proud of. You shouldn’t assume every commercial layout tool will get you similar results on AEP, because it won’t. Plenty of tools trade off algorithmic rigour for generality, ease of use, or speed, and we have customers who came to us specifically because switching improved the AEP they were getting out of their previous tool on the same site. Clearing the bar these methods set is necessary, not sufficient, and it’s not something to take for granted.
Under the hood, we build for both speed and accuracy. Gradient-based optimisation with analytical derivatives. An initialisation method that is both accurate and sufficiently random. A few tricks to reduce the multimodality of the problem itself, not just the search across it. Highly efficient multistart through parallelisation, enabled by modern cloud computing. We didn’t build it this way to win a benchmark; we built it because modelling reality properly isn’t free, and an efficient solver is what lets the fidelity and iteration below run on top of an already fast, already accurate engine, instead of at its expense.
The key is not just to solve the problem correctly, it’s to make sure you’re solving the correct problem. At Vind AI, that’s where most of our effort actually goes:
Not all uncertainties can be eliminated through better modelling; some are inherent to the data and assumptions themselves. But being able to set up realistic problems and quickly explore variations makes those uncertainties visible, and that’s usually where the real insight comes from.
The algorithm got us into the room, but what we do once we’re there is worth talking about too.
Every now and then, a new algorithm turns up and claims to revolutionise wind farm layout optimisation — typically a new gradient-free metaheuristic with a name evocative enough for a conference poster. Meanwhile, when you look at how the top performers in the field actually perform against each other on the same problem, the differences tend to be small. IEA Wind Task 37's Case Study 4 makes the point well: a benchmark based on the Borssele III/IV site, with 81 turbines and five disconnected boundary regions. Here, eight published methods — gradient-based, gradient-free, and hybrid — all landed within roughly a quarter of a percentage point of each other on wake loss. Whatever revolution is supposedly underway, it isn’t showing up in results like these. Once a problem is posed properly, most of the differences between rigorously developed algorithms wash out. Which is exactly why I don’t think the algorithm is where a customer’s real risk sits. If every credible method lands within a fraction of a per cent of the others on the same well-defined problem, the thing that actually decides the outcome is whether the problem was well-defined in the first place. That’s not an optimisation question, it’s a modelling one. And it’s where the gap between tools isn’t a fraction of a per cent, it’s however large the underlying mistake happens to be.
This is where I think a lot of layout tools quietly cut corners. Not in the solver, but in what gets handed to it. Spacing rules used as a stand-in for loads. Environmental and social constraints such as noise, shadow flicker, and visual impact are simplified past the point of matching the actual design guidelines, or left out and checked manually afterwards. Terrain, buildings, and existing infrastructure pulled once from a separate GIS tool at the start of a project, then left untouched as the layout evolves. None of that shows up as an algorithm problem, because the solver did its job perfectly on the problem it was given. It shows up as a layout that looks optimised and is quietly wrong: non-compliant, leaving yield on the table in an area that was never actually constrained, or built on an assumption that won’t survive the next planning submission.
None of this is an argument for not caring about the algorithm. Ask any yield engineer and they’ll tell you that 0.1% of production is real money over a project’s lifetime, which is exactly why we still take it seriously and build our own solver rather than treating it as a solved problem we don’t need to think about. It’s an argument for being honest about the size of that number relative to the other one. We ran our own engine against Case Study 4 to see where it landed: second among the eight published results, which is a result I’m truly proud of. You shouldn’t assume every commercial layout tool will get you similar results on AEP, because it won’t. Plenty of tools trade off algorithmic rigour for generality, ease of use, or speed, and we have customers who came to us specifically because switching improved the AEP they were getting out of their previous tool on the same site. Clearing the bar these methods set is necessary, not sufficient, and it’s not something to take for granted.
Under the hood, we build for both speed and accuracy. Gradient-based optimisation with analytical derivatives. An initialisation method that is both accurate and sufficiently random. A few tricks to reduce the multimodality of the problem itself, not just the search across it. Highly efficient multistart through parallelisation, enabled by modern cloud computing. We didn’t build it this way to win a benchmark; we built it because modelling reality properly isn’t free, and an efficient solver is what lets the fidelity and iteration below run on top of an already fast, already accurate engine, instead of at its expense.
The key is not just to solve the problem correctly, it’s to make sure you’re solving the correct problem. At Vind AI, that’s where most of our effort actually goes:
Not all uncertainties can be eliminated through better modelling; some are inherent to the data and assumptions themselves. But being able to set up realistic problems and quickly explore variations makes those uncertainties visible, and that’s usually where the real insight comes from.
The algorithm got us into the room, but what we do once we’re there is worth talking about too.
To get the newest product updates, case stories and news releases, sign up for our monthly newsletter.
Please reach out if you are interested in seeing a demo, asking a question or sharing feedback.
.svg){kind=icon}
.png)
.png)
