Personal project · AI × Mechanical Engineering
Ask the Blade
A chat interface on a wind-turbine blade element momentum (BEM) solver. Claude picks the tool, the solver runs the numbers, and a checker flags anything the solver did not compute.
- Project
- Ask the Blade
- Sheet
- 01 / 02
- Date
- Sep – Oct 2026
- Type
- AI × Engineering
Best Cp · NACA 4412
0.5415
Designs searched
4,200
Automated checks
109
Cost per question
$0.014
01
The problem
General-purpose LLMs give fluent engineering answers that nobody can verify. Ask one for the power coefficient of a blade and it will produce a plausible number, with no physics behind it.
Ask the Blade keeps the conversation in the model and the physics in a solver. You describe a blade in plain English. Every number you get back comes from a real BEM run that you can open and inspect.

02
How it works
A hand-written agent loop on the raw Anthropic SDK (no framework). Claude Haiku 4.5 chooses one of 11 solver tools, the Python solver executes, and the result goes back to the model, which reports only what the solver returned. Each step streams to the browser as it happens.
- Tools: design, four parameter sweeps (blade count, tip-speed ratio, angle of attack, chord cap), chord / twist / combined optimisers, airfoil comparison, a constrained whole-design search, and STL export.
- Physics: 20 m rotor, 8 m/s wind, 10 blade rings, a stand-in polar plus four real XFOIL polars (NACA 0012, 4412, 4415, NREL S809) with Viterna extrapolation past the data.
- The whole-design search grids 4,200 designs (7 tip-speed ratios × 6 angles × 4 blade counts × 5 chord caps × 5 airfoils) under thrust and blade-area limits, then refines the top three in about 15 s.
- Builds a watertight 3D blade mesh from the chord and twist distribution, shows it in a three.js viewer, and exports it as an STL for CAD or a slicer.



03
Keeping it honest
A separate checker tests every answer: are the numbers in the reply the numbers the solver returned, is Cp below the Betz limit, was the right tool chosen, and does the wording stay within what was computed? A judge model catches unsupported claims.
Before the system prompt was written from observed failures, the agent passed 7 of 25 test questions. Afterwards, all 20 re-run questions passed the number and wording checks.
- 109 zero-cost regression checks on the solver and tools.
- A deliberate "break it" suite: vague tool descriptions, a throwing tool, a huge result, no stop condition. Each failure is documented with its fix.
- Cost controls: a $0.10 per-session spend cap on the server, a 5-step cap, result trimming, and a repeat-call guard. About $0.014 per question.

04
Results
Baseline blade (tip-speed ratio 7, 6° angle of attack, 3 blades): Cp 0.4978, all rings converged. Twist optimisation lifts it to 0.502. Switching to the NACA 4412 airfoil gives the best result found, Cp 0.5415, against a Betz limit of 0.5926.



05
V1 → V2
V1 shipped the agent loop, input validation, logging, a test set and the web chat with five tools. V2 added chord and twist optimisation, real airfoil data, the constrained design search, the 3D viewer and STL export, and the 109 automated checks, growing the toolset to 11.
Honest limits
- No tip-loss or hub-loss correction, so Cp values are optimistic. Use the results to compare designs, not to predict a real turbine.
- The optimisers search a grid, so they report a "best found" design, not a proven optimum.
- Airfoil data is simulated at Re = 1 million, lower than a blade this size would see.
- A few corner combinations do not converge (e.g. 4 blades with a 3.0 m chord cap). The tool reports them rather than hiding them.