IKOPower: trying a hundred turbine geometries instead of checking three
A digital twin for hydropower design and optimization
🎯 The bottleneck
Designing a turbine means arbitrating between a dozen geometric parameters whose effects contradict one another. The only way to settle it is to look at the flow.
Looking at the flow is expensive. A serious fluid computation takes hours, sometimes days, and requires a mesh prepared for each geometry. A prototype costs more still, in money as in delay.
The consequence is always the same, and it is poorly understood by anyone who has not designed a machine: you only validate the ideas you are already fairly sure about. The risky variants — the ones that sometimes hold the best surprises — never cross the threshold, because they are not worth the stake.
⚡ What a fast simulation changes
We built IKOPower a digital twin of their turbine, on top of Merlin, our GPU simulation and rendering engine.
The goal was not to compute more accurately. It was to compute fast enough that trying becomes cheap again — and therefore for exploration to replace verification.
Three concrete differences in daily work:
- a modified geometry replays immediately, with no mesh preparation;
- the flow is seen while it is computed, which makes defects legible rather than deducible from curves;
- trying an unlikely idea costs nothing, so it gets tried.
🌊 Why this engine for this problem
Merlin is built on meshless methods: the fluid is represented by particles, with no computational grid to rebuild.
That choice is at its strongest on this kind of problem. Turbine flows combine free surfaces, strongly unsteady regimes and constant interaction with moving geometry — exactly the situations where a mesh-based approach spends most of its time remeshing.
Here, spinning the runner needs no special handling. Nor does changing a blade.
🧭 What this tool does not replace
Worth stating plainly, because an engineer will ask anyway: this digital twin does not replace a certification computation or a physical test.
It works upstream, where the right shape is still being sought. It narrows the field. The few geometries that come out of that exploration then deserve the heavy computation and the test rig — but they get sent there knowingly, rather than on a hunch.
That is a modest place in the process. It is also where most time is lost when the tool is missing.
🤝 What the collaboration produced
IKOPower now has a tool that speaks their language: their geometries, their operating conditions, their criteria. Not a general-purpose package in which the problem must be translated before the question can even be asked.
That is what distinguishes a digital twin built for one process from one bought off the shelf: it does a single thing, and it does it at the speed of design work.
💬 A process to mirror?
Are you designing a machine whose fluid behaviour decides its performance, with a validation loop that slows you down? That is precisely the problem we work on. Get in touch.