The Use Case
A part that must stay as flat as a red blood cell — under fire
Picture a precision wafer chuck — a circular disc, 200 mm across, spinning at 1,500 RPM under vacuum. Beneath it, a 130°C heater fires continuously. Above it, a silicon wafer worth thousands of dollars rests in perfect contact. The job of the chuck is deceptively simple: stay flat. Micron flat.
Any thermal bow beyond 3 micrometres — that's 3 millionths of a metre, roughly the diameter of a red blood cell — shifts the focal plane of the lithography system above it. A shifted focal plane means blurred circuit patterns. Blurred patterns mean defective chips. A 10× bow overrun doesn't mean a 10× cost overrun. It means scrapped silicon, halted production, and engineers staring at failure plots at midnight.
The starting design failed on two of four physics checks. Not by a whisker — by a country mile. The thermal bow was 29.9 µm against a 3.0 µm limit. Ten times over. The kind of failure that makes a simulation engineer's stomach drop. And that's exactly where the co-pilot took over.
Two fails. Two passes. The fails were not gentle misses — the bow was catastrophically off. No human-supervised parameter sweep was going to find its way out of this. You need something that can read the physics, diagnose the root cause, and reason about what class of fix is required. Not something that just tweaks a slider and hopes.
Why It's Hard
Five constraints that actively fight each other
This isn't a single-objective problem. It's a multi-physics, multi-objective problem where every fix breaks something else. These are the five coupled constraints the co-pilot had to navigate — simultaneously, not sequentially:
Bow ↔ Plate thickness
Thicker top plate reduces bow — but raises mass, cost, and makes cooling channel geometry harder to machine.
Cooling vs. pumping power cost
More channels and higher HTC reduces ΔT and bow — but maximises the cooling power penalty in the cost model.
Material CTE vs. cost index
Low-CTE materials like Invar or SiC are the only way to meet the bow target — but cost 4–9× more than aluminium.
Mesh failure from slim geometry
Cost-optimised slim geometry eventually creates features too thin to mesh — silently crashing the solver mid-run.
Two-phase convergence trap
Optimising cost before physics feasibility causes oscillation — you thrash between designs with no stable exit.
"These constraints are impossible to resolve one parameter at a time. You need to reason about the whole system simultaneously — or you thrash forever."
— Engineering Design Co-Pilot · Architecture NoteSystem Architecture
The loop that never sleeps — and never stops watching
The entire pipeline runs on a personal laptop. No cloud compute. No commercial licences. Four open-source tools stitched together by a Python orchestrator, with an AI reasoner watching every output and an engineer in the loop at every decision that matters.
What makes this different from a scripted optimisation loop is what happens at the AI node. It doesn't read a number and increment a parameter. It reads the full FEA output — stress field, temperature distribution, bow magnitude, cost components — identifies the dominant failure mode from first principles, reasons about which class of fix addresses the root cause, and then presents that reasoning to the engineer before proceeding.
You are always in the loop. But you're in the loop at the right moment: when a decision has real engineering consequences. Not when a wall thickness increments by 0.5 mm.
The AI proposes and explains. The engineer accepts, modifies, or overrides. If the engineer overrides with something the AI believes will fail, the AI states the implications clearly — then runs it anyway. The result either proves the AI right or teaches it something. Either way, no decision is taken without human awareness of the trade-off.
Iteration 1 → 2 · The Critical Decision
The material call that no script would ever make
After iteration 1, the co-pilot did something a gradient-free parameter sweep cannot do: it identified that the root cause of the bow failure was not the geometry — it was the material itself. AL6061 has a coefficient of thermal expansion (CTE) of 23.6 µm/m°C. At the thermal loads present in this design, every degree of temperature difference across the chuck translates directly into bow. And with a 130°C heater below and coolant channels above, there is a very large ΔT.
The diagnosis: even at maximum plate thickness — 8 mm — AL6061 bow only falls to approximately 11 µm. Still 3.7× over the limit. Geometry cannot fix a CTE problem. A material change was required.
Bow 29.86 µm is 9.95× over the 3.0 µm limit — the primary and catastrophic failure mode. AL6061 CTE (23.6 µm/m°C) makes it physically impossible to meet the 3 µm bow target with geometric changes alone given the 10× bow overrun. Recommending material escalation to Invar (CTE ~1.2 µm/m°C, ~20× lower). This alone would reduce bow from ~29.86 µm to ~1.5 µm, even before HTC improvements.
The AI recommended Invar over SiC — not because it's more capable, but because SiC (cost index 8.5) was not yet justified when Invar (cost index 4.2) was sufficient to meet all targets. The co-pilot understood the cost model, not just the physics. But what if the engineer disagreed?
Root cause is thermal expansion, not geometry. I'm recommending a material switch from AL6061 to Invar (CTE 1.2 µm/m°C) — 20× lower expansion. Combined with max HTC (1×10⁻²) and 10 cooling channels, predicted bow drops to ~1.5 µm in the next iteration. Invar is preferred over SiC as cost index 4.2 is within budget threshold vs. SiC at 8.5. Do you want to proceed, or would you like to override?
Even at maximum top plate thickness (8 mm), AL6061 bow is estimated at ~11 µm — still 3.7× over the 3.0 µm limit. The physics is bow ∝ α·ΔT·L²/t, where α is CTE. Increasing t (plate thickness) helps, but α (23.6 µm/m°C) is the dominant multiplier. Geometry changes cannot overcome a CTE problem at this thermal load. I'll run it so the result is visible directly.
CTE: 23.6 → 1.2 µm/m°C. Cost index: 1.0 → 4.2 (within 0.70 budget threshold). Simultaneously maximising HTC to 1.0×10⁻² W/mm²·°C, 10 cooling channels, top plate to 8.0 mm, wall to 16.0 mm for structural rigidity. Rebuilding geometry in FreeCAD now. Expected bow: ~1.4 µm.
This exchange is what the co-pilot is designed for. The engineer's reluctance was valid — Invar costs more. The AI explained the physics clearly, offered to run the geometry-only option, and let the evidence do the arguing. The iteration confirmed the diagnosis. Trust was earned through demonstration, not through authority.
Iteration 2 result: bow dropped from 29.9 µm to 1.38 µm. Stress fell from 187.6 MPa to 11.78 MPa. Safety factor jumped from 1.47 to 23.4. All physics targets passed — in a single step.
Iterations 3 & 4 · Phase 2
Physics passes. Now the co-pilot hunts cost.
Once all physics targets were met with large margins, the co-pilot shifted operating mode. Safety factor of 23.4 is enormously over-designed — the requirement is 1.5. Bow at 1.38 µm leaves 1.62 µm of headroom. These margins are not slack to ignore; they are headroom to exploit. The dominant cost driver after iteration 2 was the cooling power — HTC at maximum, 10 channels running at full intensity. Cooling power score: 1.000. Maximum penalty.
Phase 1: get feasible. Phase 2: exploit margin. The co-pilot shifted from "find a design that passes" to "relax the most expensive constraints while physics targets stay within limits." Reducing HTC from 1×10⁻² to 1.5×10⁻³ W/mm²·°C (a 6.7× reduction in cooling intensity) while the safety factor and bow margins absorb the resulting ΔT increase. This two-phase structure prevents the oscillation and thrashing that kills most parameter sweeps.
Each iteration's cost decomposition was presented to the engineer, showing exactly which sub-score was dominant and what parameter lever would address it. Cooling power → reduce HTC and channels. Mass → reduce wall thickness. Manufacturing complexity → reduce channel depth. The engineer could see precisely where cost was being spent and why each change was proposed.
Iteration 4 · The Moment That Defines This
The mesh failed. No one noticed. The co-pilot fixed it.
Deep into cost optimisation, the co-pilot proposed reducing wall thickness to 12 mm with channel depth at 6 mm. The geometry was built. Gmsh attempted to mesh at 8 mm element size — zero elements. Retried at 12 mm — zero elements. Retried at 18 mm — zero elements. The wall section between channel and outer edge had become thinner than the mesh could resolve. A silent crash.
In a traditional workflow this is a dialog box, a confused engineer, a restart. In this workflow:
Nobody touched the keyboard. The AI diagnosed the mesh failure, proposed a geometry repair, rebuilt the STEP file in FreeCAD, re-meshed in Gmsh, re-solved in CalculiX, and continued the optimisation — all in under 30 seconds. The engineer found out it had happened when they looked at the iteration log.
— Iteration 4 Repair Sequence · 0 human inputs · Fully autonomous recoveryThis is what distinguishes the co-pilot from a brittle script. Scripts crash on unexpected states. A reasoning engine diagnoses the unexpected state, determines the right response, acts, and continues. This kind of graceful, autonomous recovery from silent solver failures is what makes unattended overnight optimisation runs genuinely feasible in real engineering workflows.
The Full Journey
Five iterations. Every decision traceable.
Here is the complete optimisation trajectory. Every row represents a full FreeCAD geometry build, Gmsh mesh, CalculiX solve, AI diagnosis, and either an engineer decision or an autonomous action. Total elapsed time: 150 seconds.
| Iter | Wall | Ch Depth | Top Plate | Material | HTC (W/mm²·°C) | Bow (µm) | Stress (MPa) | Temp (°C) | Cost Score | Status |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 14.0 mm | 5.0 mm | 3.0 mm | AL6061 | 3×10⁻⁵ | 29.86 | 187.6 | 113.2 | 0.11 | Fail |
| 2 | 16.0 mm | 7.0 mm | 8.0 mm | Invar ★ | 5×10⁻³ | 1.38 | 11.78 | 84.9 | 0.60 | Pass |
| 3 | 13.0 mm | 6.0 mm | 8.0 mm | Invar | 1.5×10⁻³ | 1.66 | 15.64 | 102.7 | 0.59 | Pass |
| 4 ⚡ | 13.0 mm | 3.0 mm | 8.0 mm | Invar | 1.5×10⁻³ | 1.90 | 18.24 | 106.7 | 0.42 | Pass |
| 5 ★ | 12.0 mm | 3.0 mm | 8.0 mm | Invar | 1.5×10⁻³ | 2.00 | 17.52 | 106.6 | 0.41 | Converged |
⚡ Iteration 4: autonomous mesh failure repair · ★ Material escalation from AL6061 to Invar · ★ Final converged design
Final Converged Design
All targets passed. Cost score 0.41 against a 0.70 budget.
The design converged at iteration 5. Every physics target met with margin. Cost score well below threshold. All geometry parameters at their structural bounds — no remaining design freedom. Here is where the design began versus where it landed:
Final design specification: 12.0 mm wall · 3.0 mm channel depth · 8.0 mm top plate (at bound) · 8 cooling channels · HTC 1.5×10⁻³ W/mm²·°C · Invar (CTE 1.2 µm/m°C). A design that started bowed beyond recognition and landed as a geometry that is simultaneously cost-efficient, thermally controlled, and mechanically conservative to a degree that suggests significant further weight optimisation is possible in subsequent studies.
What This Proves
Five things AI-in-the-loop engineering gets right that brute force cannot
-
1
Physics reasoning beats parameter sweeping
The AI diagnosed CTE as the root cause of bow — not plate thickness, not channel count — and escalated material accordingly. A gradient-free search would have spent its entire budget proving aluminium doesn't work.
-
2
Two-phase optimisation prevents the thrashing trap
Decoupling feasibility from cost optimisation means you never end up oscillating between designs where every cost saving breaks a physics constraint. Feasibility first. Always. Then exploit margin.
-
3
Autonomous recovery from solver failures
The mesh failure in iteration 4 was diagnosed, repaired, and recovered without human input. This kind of silent failure resistance is what makes unattended simulation runs actually viable in real engineering environments.
-
4
The co-pilot earns trust — it doesn't demand it
When the engineer pushed back on Invar, the AI explained, ran the engineer's preferred option, and showed the result. That's the right human-AI dynamic for high-stakes engineering decisions. Evidence, not assertion.
-
5
Open-source FEA is genuinely production-grade
FreeCAD · Gmsh · CalculiX. Zero licence cost. Ran on a personal laptop. Converged in 150 seconds. The barrier to serious simulation capability has essentially collapsed — and the reasoning layer is now accessible via API.
"Engineers don't get replaced. They get a co-pilot that never gets tired, never skips the physics, and tells you the truth even when you don't want to hear it."
This project was built as a personal hobby, entirely in evenings and weekends, on personal hardware. The stack is open-source. The concepts are transferable to any parametric simulation domain — thermal management, structural optimisation, fluid systems, acoustics, electromagnetics. Every discipline that runs simulations and iterates on designs could have a version of this. The only ingredient that wasn't free was curiosity about what was possible.
The possibilities don't stop at wafer chucks. They start there.
The Stack
This is an independent personal project, done entirely on personal hardware using free open-source software. The wafer chuck scenario is a realistic multi-physics challenge — not derived from, affiliated with, or representative of any employer, project, or client. All geometry, loads, materials, and results are synthetically constructed for demonstration purposes. Intent: to explore AI-augmented engineering workflows and share findings with the community.