02simulation2026

Conformal Cooling Channel Generation

ConformalFlow automatically designs cooling passages that follow an injection-mold cavity. The goal is to remove heat more evenly so molded parts can reach ejection temperature sooner, while keeping the geometry inspectable and compatible with complex internal passages enabled by metal additive manufacturing.

This engineering prototype that converts injection-mold cavity geometry into cooling passages completed a fresh browser-driven gear-cavity job, produced four UI/API export artifacts, and separately generated two watertight split-mold halves with a passing repository validation report and two recorded volume warnings.

Open the project video
A 31-second chronology assembled from the accepted gear-cavity capture and its generated evidence figures.
Role
Prototype architecture, Python geometry and validation engine, React and Three.js workflow, deterministic evidence capture, and public-safe case-study verification.
System boundary
A React and Three.js client uploads cavity geometry to a FastAPI service, follows generation progress over WebSockets, and exposes completed STL and 3MF exports; a separate Python command generates and validates split mold halves for the same parameterized gear family.
Primary constraint
The public portfolio cannot expose a live geometry backend, so the proof must remain useful as captured static media.
Strongest evidence
A real browser-driven UI/API job completed in 1.1 seconds with 20 channel segments and four hashed exports; the separate split-mold command produced two watertight mold halves and a PASS report with two retained volume warnings.

The situation

Cooling paths inside an injection mold need to follow part geometry closely enough to be useful while remaining inspectable as geometry, bounded by manufacturing-oriented checks, and exportable for downstream engineering work.

A visually plausible path is not enough: disconnected channels, poor wall clearance, unsupported overhangs, trapped powder, or ambiguous mold interfaces can turn an attractive rendering into unusable geometry.

Constraints

  • The public portfolio cannot expose a live geometry backend, so the proof must remain useful as captured static media.
  • Every published artifact must trace to a clean source commit and a real completed browser-driven job.
  • The UI/API export path and the repository's separate split-mold generator must remain clearly distinguished.

My responsibility

Prototype architecture, Python geometry and validation engine, React and Three.js workflow, deterministic evidence capture, and public-safe case-study verification.

The system

A React and Three.js client uploads cavity geometry to a FastAPI service, follows generation progress over WebSockets, and exposes completed STL and 3MF exports; a separate Python command generates and validates split mold halves for the same parameterized gear family.

Architecture descriptionA browser uploads deterministic gear geometry to a Python API, receives generation progress, and downloads channel exports, while a separate generator produces validated split mold halves and ports.

Critical decisions

01

Original synthetic gear geometry

Choice
Generate a deterministic first-party gear cavity so the input, source hash, and resulting evidence can be reproduced without third-party geometry.
Alternatives considered
  • Use an untraceable sample model or customer geometry.
Tradeoff
The synthetic part is intentionally simple, but its provenance and repeatability are explicit.

02

Manufacturing-aware generation and validation

Choice
Treat channels as engineering geometry with clearance, continuity, overhang, powder-removal, and flow checks rather than as decorative path rendering.
Alternatives considered
  • Render attractive centerlines without export or validation boundaries.
Tradeoff
The pipeline carries more geometric and validation complexity, while the resulting artifacts remain inspectable and exportable.

03

Captured static proof

Choice
Publish optimized video and responsive stills from a real local run instead of exposing the prototype backend.
Alternatives considered
  • Host a public geometry-generation service.
Tradeoff
Visitors cannot submit arbitrary parts, but the portfolio remains fast, secure, and auditable against fixed evidence.

Proof

Fresh gear-cavity captureA real browser-driven UI/API job completed in 1.1 seconds with 20 channel segments and four hashed exports; the separate split-mold command produced two watertight mold halves and a PASS report with two retained volume warnings.

Evidence boundary
UI/API evidence comes from clean source commit 5514afad8321812037c556d6e21b6c2559851a8d. Geometry figures were rendered by commit a51b70ae524e13ef56d79bb07a83462256d361f9. The split-mold/ports figure comes from a separate repository generator for the same gear family, not from the UI/API exports.
Known limits
This capture did not establish thermal performance, hydraulic performance, cycle-time improvement, shop-floor manufacturability, or physical prototype behavior. The full repository baseline retained five known test failures plus existing Ruff and MyPy debt; the focused capture and renderer checks passed.

Reflection

This engineering prototype that converts injection-mold cavity geometry into cooling passages completed a fresh browser-driven gear-cavity job, produced four UI/API export artifacts, and separately generated two watertight split-mold halves with a passing repository validation report and two recorded volume warnings.

  • Geometry evidence is strongest when the input, running state, output meshes, and validation boundary are all preserved together.
  • Separate generator paths need separate provenance; visual similarity is not evidence that two artifacts came from the same workflow.
  • A public case study can show a private engineering prototype honestly without operating a public compute service.