How we ran a genetic algorithm and CFD to design a boat propeller — and validated every winner

We were asked to design a propeller for a small high-speed unmanned surface vessel (USV): roughly 200 kg displacement, a design speed of 15 m/s (about 29 knots), and a required thrust of 380 N in seawater. The propeller is where the drivetrain either works or it does not. Pick the wrong diameter or blade count and you either cavitate, stall the motor, or leave efficiency on the table.

This post walks through how we ran the search, and, more importantly, how we checked that the search did not lie to us.

Two objectives that pull in opposite directions

There is no single "best" propeller here. We optimized against two objectives at once:

• Maximize open-water efficiency η₀ — how much of the shaft power becomes useful thrust.
• Minimize shaft torque Q at the design point — a stand-in for motor size and cost. A propeller that needs less torque lets you fit a smaller, cheaper motor and ESC.

These fight each other. A large, slow-turning propeller tends to be efficient but demands high torque. A small, fast-turning one needs less torque per revolution but usually gives up efficiency. So the honest output is not one number, it is a trade curve.

We constrained the search with real physics, not preferences:

• Cavitation, via the Keller criterion, so blade area stays large enough to avoid cavitation at the design point.
• Tip speed, capped to keep the blade tips out of the cavitation and noise regime.
• Motor torque, an upper bound set by the candidate motor.

The design vector

Each candidate propeller is described by a handful of genes:

• Blade count Z ∈ {3, 4, 5}
• Diameter, 0.12–0.20 m
• Shaft speed, 3000–6000 RPM
• Three chord-scale genes that stretch or shrink the chord distribution over a DTMB-4119-like baseline (NACA a=0.8 meanline, NACA 66 thickness form)

That is a mixed integer-continuous space. Small enough to reason about, large enough that you are not going to hand-tune your way to the frontier.

Fast evaluator first: OpenProp BEMT

You cannot run CFD on every candidate. A blade-resolved RANS case takes hours. A genetic algorithm wants thousands of evaluations. So the inner loop uses a fast physics model: OpenProp, a blade-element momentum theory (BEMT) code with an Epps-style circulation optimizer.

For each candidate we hand OpenProp the geometry and operating point and ask it to hit the 380 N thrust as a hard equality constraint. That matters. Every propeller the optimizer sees already produces the required thrust, so we are not comparing propellers that make different thrust. We are comparing propellers that all make 380 N and differ in how efficiently, and at what torque, they do it.

A single BEMT evaluation runs in a fraction of a second. That is what makes the search affordable.

The search: NSGA-II over 2,560 evaluations

We wrapped the evaluator in pymoo and ran NSGA-II, a multi-objective genetic algorithm that keeps a population of non-dominated solutions instead of collapsing everything into one weighted score.

• Population: 64
• Generations: 40
• Total: about 2,560 BEMT evaluations

The output is a Pareto front: the set of propellers where you cannot improve efficiency without paying in torque, or cut torque without losing efficiency. One end of the front is the low-RPM, high-torque, high-efficiency design. The other is the high-RPM, low-torque, lower-efficiency design. Neither is "right" until you decide how much motor you are willing to buy.

Picking a winner: the knee point

From the front we picked the knee point, the design where the trade-off stops paying off, where giving up a little more efficiency buys almost no torque reduction. It is the most defensible single pick when you do not already have a motor chosen. We lofted that geometry to an STL for the high-fidelity check.

High-fidelity validation: OpenFOAM RANS

Here is the part most optimization write-ups skip. BEMT is a model. It is fast because it approximates. Before we trust the winner, we run it in a real viscous solver.

We meshed the lofted blade with snappyHexMesh and ran simpleFoam in OpenFOAM v2506: steady incompressible RANS, k-ω SST turbulence, with a Multiple Reference Frame (MRF) rotating zone around the blade-resolved geometry. We ran two operating points and compared the thrust coefficient KT, torque coefficient KQ, and open-water efficiency η₀ from CFD against what BEMT had predicted.

This is the step that tells you whether the 2,560 cheap evaluations were pointing at a real design or a numerical artifact. When BEMT and RANS agree on KT/KQ/η₀ at the design point, the front is trustworthy. When they diverge, you learn where the fast model breaks and you correct.

What we did not model, and why that is fine

Being explicit about the limits is part of the method:

• Steady MRF, not sliding-mesh URANS. MRF freezes the rotor in a rotating frame. It is accurate for open-water performance at a fixed operating point and far cheaper than a time-accurate sliding mesh. For unsteady wake or inflow interaction you would move to URANS. We did not need to here.
• No cavitation model in the CFD. Cavitation was handled in the GA through the Keller area margin, so every candidate already respects a cavitation constraint. The RANS run confirms hydrodynamic performance, not bubble dynamics.
• Open-water only. No hull, no free surface, no maneuvering. That is the standard first cut for propeller design, and it is what the 380 N thrust requirement was specified against.

None of these are hidden. Each is a deliberate choice to spend fidelity where it changes the decision and save it where it does not.

Why the two-tier loop is the point

The whole approach is: search with a fast model, validate with a slow one. You do not simulate every candidate at high fidelity, because that is unaffordable and unnecessary. You use cheap physics to find the small set of designs worth looking at, then spend the expensive solver only on the winner, and its neighbors, to confirm the fast model did not mislead you.

The loop is automated end to end: parameterize, evaluate, evolve, select, loft, mesh, solve, compare. It is supervised by review agents that check the geometry, the mesh quality, the solver setup, and the running solution, so a bad mesh or a diverged case gets flagged instead of quietly producing a wrong KT.

If you want to see more of these builds, they live in the Curlscape Lab. And if you are trying to estimate what a study like this costs in solver hours before you commit, our simulation cost calculator is a reasonable starting point.

The takeaway for anyone running design optimization: the genetic algorithm is not the hard part, and neither is the CFD. The discipline is knowing which one to trust for which question, and always validating the answer the cheap model gives you.