# Navier AI

> Design, simulate, and code in one platform, driven by agents. In Prism, an engineering agent plans the work, runs your solvers, and reports back.

Navier AI makes Prism, the AI platform for hardware engineering. Design,
simulate, and code in one platform, driven by agents. Our engineers also work
with teams directly.

## Key facts (as of October 2026)

- Prism is a native desktop app: an engineering agent, a code editor, a 3D viewport, and a local solver runtime in one window, working on files on your own machine.
- Platforms: macOS on Apple Silicon, Windows on x86-64, Linux on x86-64.
- Price: $500 per seat per month. The download is free; sign in with a Navier account after installing.
- Solvers: Ferro (structural FEA) is built in. OpenFOAM, SU2, Basilisk, code_aster, CalculiX, Elmer, Yade, Project Chrono, OpenModelica, Palace, openEMS, and ngspice install from inside Prism.
- Open-source solvers run as containers on your machine, so they need a container engine such as Docker. Prism's own solvers need nothing extra.
- Navier engineers also run simulation engagements and forward deployed engineering, scoped per project.
- Documentation: https://docs.navier.ai (index for AI tools: https://docs.navier.ai/llms.txt)

## Product

- [Prism](https://www.navier.ai/prism): Prism is a desktop app for hardware engineers. The agent sets up, runs, and reports. You make the calls.
- [Download](https://www.navier.ai/prism/download): Download Prism for macOS, Windows, or Linux.
- [Engagements](https://www.navier.ai/engagements): Our engineers run simulation work for your team and bring Prism into your workflows. See the studies we've published, from wind-tunnel validation to data-center cooling.
- [Pricing](https://www.navier.ai/pricing): Prism is one plan with the agent included. Forward deployed engineering and engagements are scoped with you.
- [ONERA M6 Transonic Validation](https://www.navier.ai/case-studies/onera-m6): Surface pressure validated against AGARD AR-138 — 270 of the 271 wind-tunnel taps at Mach 0.8395, with the λ-shock captured and merging between η = 0.80 and 0.90. Forces are compared code-to-code against a NASA multi-code reference; there is no measured lift or drag for the M6.
- [Wigley Hull Free-Surface Validation](https://www.navier.ai/case-studies/wigley-hull): The 3 m Wigley hull run at five Froude numbers against the 1983 cooperative towing-tank measurements. Sinkage stayed within 1.03 mm at every speed, and total resistance carries a ±2.10% numerical uncertainty across a converged grid family.
- [Data-Center Cooling Layout](https://www.navier.ai/case-studies/datacenter-cooling): A dense cooling yard loses about 12% of its capacity to its own exhaust. Four layouts compared in CFD; the best cuts that to about 5%.
- [Jet-Mixed Tank Sludge Deposition](https://www.navier.ai/case-studies/tank-sludge): A 12 m jet-mixed storage tank where the only variable is nozzle aim. Radial jets leave 90% of the floor below the shear stress that mobilizes settled sludge; turned 53° they leave 62%, sweeping 4.0× more floor for no new hardware and less pump-side head.
- [Heat Exchanger Inlet Duct Uniformity](https://www.navier.ai/case-studies/hx-duct): A short-radius elbow delivers 13.8% RMS non-uniformity across a heat exchanger tube face, against a 10% purchase specification. Turning vanes clear it and take 26 Pa off the fan; vanes with a distribution plate reach 1.9%, still cheaper to run than the duct as drawn.
- [Natural Ventilation in a Glazed House](https://www.navier.ai/case-studies/house-vent): A heavily glazed house with both openable windows at the same height: 13 air changes an hour in a 3 m/s breeze, 0.73 in still air, and a mezzanine at 35.7 °C. Roof vents 4.5 m higher remove the dependence on the weather; shading reaches a similar place on a fraction of the air flow.
- [Jet Mixing in a Stratified Water Tank](https://www.navier.ai/case-studies/tank-mixing): A transient simulation of jet mixing in a stratified 246,727-gallon potable water tank. Destratification orders on inlet momentum flux, not flow rate and not Froude number: half the flow through a throttled port mixes as well as twice the flow through a fixed nozzle.
- [CFRP Composite Layup Trade Study](https://www.navier.ai/case-studies/composite-layup): Four carbon/epoxy stacking sequences on the same bolted-edge plate, same plies and same mass, under 0.02 MPa. Only the unidirectional stack passes, at a margin of +0.87; the quasi-isotropic stack fails first, at 10.1 kPa. In every layup the matrix cracks before any fibre comes close.

## Blog

- [Navier AI Awarded AFWERX Phase I SBIR to Build a Geometry Reasoning Layer for Engineering Agents](https://www.navier.ai/blog/2026-08-18-navier-awarded-afwerx-phase-1-sbir): Navier AI has been awarded a Phase I SBIR from AFWERX to explore an ontology-based geometry embedding layer that gives AI agents the ability to reason about parts, features, and spatial relationships instead of guessing.
- [ONERA M6 Transonic Validation](https://www.navier.ai/blog/2026-08-04-onera-m6-validation): The standard transonic benchmark, run against 270 of the 271 published pressure taps. The double-shock structure comes out right and merges where the experiment puts it — and decomposing our own drag killed our first explanation for the part that did not.
- [From Prompt to Flight Software: Building a Missile Evasion Simulation with Stella](https://www.navier.ai/blog/2026-03-22-prompt-to-flight-software-stella): Stella, our agentic GNC platform, eliminates the path from scenario concept to working simulation code. Describe the engagement. Stella generates the simulation, flight software, guidance laws, autopilots, and runs SIL with up to a 50x speedup over traditional tooling.
- [Data to Decisions in Minutes: How Navier's Post-Processing Agent Transforms Simulation Analysis](https://www.navier.ai/blog/2026-03-03-faster-speed-to-insights): The gap between 'simulation complete' and 'actionable insight' is shockingly slow. Navier's Post-Processing Agent closes that gap, compressing hours of manual work into minutes.
- [Silent Bugs, Lost Missions: Why GNC Flight Software Is Moving to Rust](https://www.navier.ai/blog/2026-02-25-Silent-Bugs-Lost-Missions): The history of spaceflight is full of hundred-million dollar lessons in what happens when flight software hits edge cases. Rust eliminates entire classes of bugs that end missions.
- [Engineering Without Boundaries: Building a Unified Engineering Platform from Physics to Flight](https://www.navier.ai/blog/2026-02-12-engineering-without-boundaries): Explore how Navier AI's Agent-driven platform unifies CFD, GNC, FEA, and flight software into a single continuous workflow.
- [Introducing Agent-Driven Engineering: The Future of Hardware Design](https://www.navier.ai/blog/2025-01-15-introducing-agent-driven-engineering): Discover how Agent-Driven Engineering is transforming hardware design workflows, enabling engineers to focus on innovation while AI agents handle repetitive tasks.
- [Navier Raises $5.6M to Deploy Agent-Driven Engineering, the Next Engineering Unlock After CAD and Simulation](https://www.navier.ai/blog/2024-12-15-navier-raises-5-6m-seed-funding): Navier announces $5.6 million in seed funding and its launch from stealth, bringing autonomous engineering teams to hardware design and development.

## Company

- [About Navier AI](https://www.navier.ai/company): The team behind agent-driven engineering.
- [Contact](https://www.navier.ai/contact): Talk to an engineer about a problem or an engagement.

## Optional

- [Full text for AI tools](https://www.navier.ai/llms-full.txt)
- [Sitemap](https://www.navier.ai/sitemap.xml)


# Navier AI — The AI platform for hardware engineering
URL: https://www.navier.ai/

Accelerating engineering with AI. Navier builds AI agents that design, simulate, and code hardware, so your engineers can explore more designs in less time. See Prism Explore our engagements → The AI platform for hardware engineering. Design, simulate, and code in one platform, driven by agents. Explore Prism Solve your toughest engineering problems with us. We work with some of the most high-profile, high-performance brands in engineering. Let us help you solve your hardest engineering problems. Bring our engineers into your team. We work alongside your engineers to integrate Prism into your existing workflows and expand your engineering capabilities. Let us run the analysis. From setup through results, we manage the simulation so your team gets the answers it needs to move the design forward. Discuss your project AI for hardware is here. Contact us

# Prism — AI for real-world engineering | Navier AI
URL: https://www.navier.ai/prism

AI for real-world engineering. Prism is the AI platform for hardware engineering. Design, simulate, and code in one platform, driven by agents. Download Prism Pricing → Automate engineering workflows end-to-end. From natural language, the agent builds CAD, runs simulations, writes code, and authors the report. Optional review and approval at every step. 1 Design 2 Simulate 3 Visualize 4 Code 5 Report Design CAD from a prompt. Describe the part, its loads, and its constraints. The agent builds CAD you can open, edit, and export. Simulate Simulation in every domain. Structures, fluids, thermal, multibody, electromagnetics, and more. The agent sets up, runs, and verifies each case, and every file is yours to audit. Integrated solvers Open-source solvers install from inside Prism, next to Ferro, our GPU-native FEA. Ferro GPU-native FEA OpenFOAM CFD SU2 Compressible CFD Basilisk Multiphase CFD code_aster Structural FEA CalculiX Structural FEA Elmer Multiphysics FEM Yade Discrete element method Project Chrono Multibody dynamics OpenModelica Modelica modeling Palace Finite-element EM openEMS FDTD electromagnetics ngspice Circuit simulation Results Visualize your results. Fields, slices, plots, and side-by-side comparisons in Prism's results viewer, set up by the agent and yours to dig into. Code Code from scripts to firmware. The agent writes solvers, analysis scripts, and embedded firmware, then builds and runs them. Report Reports in your team's format. The agent writes reports as PDFs or PowerPoint decks, built on your templates and preferences, with the plots and visuals that tell the story. Plugins Connect the tools you already use. Plugins connect the agent to your CAD, code, trackers, docs, and chat. Install them from inside Prism. Onshape CAD & PLM Altium Designer (Beta) Electronics RMFG Manufacturing GitHub Code & CI GitLab Code & CI Atlassian Project tracking Linear Project tracking Monday Project tracking Smartsheet Project tracking Notion Docs & files OneDrive & SharePoint Docs & files Slack Communication Outlook Communication Microsoft Teams Communication Sentry Monitoring LangSmith Monitoring Onshape CAD & PLM Altium Designer (Beta) Electronics RMFG Manufacturing GitHub Code & CI GitLab Code & CI Atlassian Project tracking Linear Project tracking Monday Project tracking Smartsheet Project tracking Notion Docs & files OneDrive & SharePoint Docs & files Slack Communication Outlook Communication Microsoft Teams Communication Sentry Monitoring LangSmith Monitoring What will you build? Download Prism and give the agent your next design problem. Download Prism Pricing →

# Pricing — Prism plans and engineering engagements | Navier AI
URL: https://www.navier.ai/pricing

Pricing Transparent, simple pricing, with optional support from our engineers. The engineering agent, and everything it works in. $ 500 per seat per month Download Prism Subscribe 01 The full desktop app Code, CAD, simulation, and reports in one window. 02 A general-purpose engineering agent It plans the work, writes and runs code, drives CAD and solvers, and splits big jobs across sub-agents. 03 Integrated solvers and plugins OpenFOAM, SU2, CalculiX, code_aster, Project Chrono, and more install from the app, beside plugins for Onshape, GitHub, Jira, and Slack. 04 A durable harness Every step is saved as it happens, so a long run picks up where it left off after a restart or a dropped connection. With Navier engineers Our engineers can run Prism with your team or do the work for you. Tell us the problem and we come back with a scope and a price. Forward deployed engineering Navier engineers join your team, typically for three months, and put Prism to work across your engineering workflow. Prism deployed in your environment Workflows built for your code, CAD, and simulation Your engineers trained on live work Typically 3 months Learn more → Simulation engagements Hand us the simulation question. Our engineers run it in Prism and return the answer. Fluids, structures, thermal, and electromagnetics Delivered as a report you can inspect You keep the case files to rerun or audit Scoped per project How engagements work → Questions Do I need Docker? Only for the open-source solvers, which run in containers. Prism's own solvers need nothing extra. Which computers does it run on? Macs with Apple Silicon. Windows and Linux on Intel or AMD. How are forward deployed engineering and engagements priced? Both are scoped with you. Forward deployed engineering usually runs three months, but that isn't a fixed minimum. Simulation work is priced once we agree what it has to answer.

# Engagements — Work with our engineers | Navier AI
URL: https://www.navier.ai/engagements

Navier engineers, embedded in your program. Talk to our team → See an engagement Our engineers embed with your team to get AI working inside your engineering organization: running the studies, building the workflows around them, and leaving your people able to carry it on without us. 01 · Simulation engagements We do the work. Send the geometry, the operating point, and the decision it feeds. We return the answer, with a report you can inspect. Fluids, structures, thermal, and electromagnetics Run in Prism for faster turnaround The case files, yours to rerun or audit 02 · Forward deployed We bring Prism to your team. Our engineers join your team for three months and build Prism into the work you already do. Prism deployed in your environment Workflows built on your CAD, code, and solvers Your engineers trained on live projects Engagement examples and validation studies. Studies we ran ourselves, scoped like a customer engagement, and our solvers checked against wind-tunnel and towing-tank measurements. Engagement examples Data-center thermal management How much cooling capacity does your layout cost you? Alternative layouts of the dry coolers around a data hall, compared on identical hardware, duty, and weather, and taken from geometry to a defensible recommendation. Read the study → Storage-tank mixing Where sludge settles, and the aim that decides it. Two fixed mixing nozzles in a storage tank, compared on aim alone, to find which floor area stays below the shear stress that mobilizes settled sludge. Read the study → Show 4 more Validation studies Transonic external aerodynamics The λ-shock, where the wind tunnel puts it. The transonic wing benchmark against wind-tunnel pressure taps, with the double-shock structure captured and merging where the experiment brackets it. Read the study → Marine free-surface CFD Sinkage within 1.03 mm, across five speeds. The free-surface benchmark hull against towing-tank sinkage at five speeds, with total resistance carried to a stated numerical uncertainty. Read the study →

# Data-Center Cooling Layout — CFD Case Study | Navier AI
URL: https://www.navier.ai/case-studies/datacenter-cooling

Our own study Data-center thermal management How much cooling capacity does your layout cost you? We used CFD to compare four ways of arranging 42 dry coolers around a 44 MW-class data hall. The dense baseline quietly lost about 12% of its cooling capacity to its own exhaust. A better layout cut that penalty to about 5%. 56.3 MW HEAT REJECTED 42 DRY COOLERS 9 MIN AGENT SETUP · ALL FOUR LAYOUTS 5 DAYS FROM DATA-COMPLETE TO DECISION No customer commissioned this study. We built it on our own bench so you can see the method and check the assumptions. Every one is listed on this page, including the one that carries the headline: an assumed 2% per kelvin capacity derate. THE DECISION The cheapest layout on paper was not the cheapest layout to operate. On a hot, low-wind day, air-cooled units can start breathing their neighbors' discharge. Entering air gets warmer, condensing capacity falls, and the site pays twice: once for the compact layout and again in derated IT load or extra machines. The obvious fixes all spend something different. Wider aisles spend land downwind. Split banks spend parcel width. Rooftop placement spends structure and piping. The question is which layout protects capacity under the constraint your site actually has. Pathlines traced backward from one intake. They don't come from upwind. They come off the machine in front. Standing in a 6 m aisle of the dense baseline. The air the next row is about to breathe is the ceiling above you. WHAT WORKING WITH US LOOKS LIKE A five-day path from geometry to a design decision. This was an independent representative study, not customer work. The schedule below shows how we would structure the same problem as a focused service engagement. Exact timing depends on geometry quality, case count, and compute requirements. DAY 0 Frame the decision You bring geometry, duty schedule, fan curves, site weather, and your operating limits. We turn “will these coolers recirculate?” into the real decision: which layout protects capacity without spending land in the wrong direction. The clock starts when that data is complete, not at first contact. Signed-off simulation brief DAY 1 Build and challenge the baseline Our agents prepare the geometry, boundary conditions, mesh controls, and run configuration. An engineer checks the physical model before compute starts. The first baseline exists to find bad assumptions, not to make a pretty picture. Baseline model + setup review DAY 2 Return the first readout We review intake temperatures unit by unit and trace where the hot air is coming from. You get an early call with the dominant mechanism, any data gaps, and the options worth testing. You can redirect the study while it's still cheap to. Interim readout in 48 hours DAY 3 Run the useful alternatives The platform generates controlled variants and launches them in parallel. Here that means wider aisles, rooftop placement, and split flanking banks, each with identical hardware, duty, weather, and mesh recipe so the comparison stays fair. Building and meshing three new layouts took under seven minutes of the run. Four comparable layouts DAY 4 Try to disprove the result We check mesh quality, per-unit mass balance, atmospheric profile, convergence, and mesh sensitivity. This pass caught a fan-deck meshing error that ordinary residuals missed. Automation makes the sweep fast. Engineering review makes it defensible. Verification record + limitations DAY 5 Deliver a decision package You receive the recommendation, the trade space behind it, the solved fields, the verification record, and a short working session with our engineers. It is built to be defended in a design review, not a folder of contours. Report, visuals, fields, review THE RESULT Same machines. Same duty. A different answer. Widening the aisles reduced mean intake temperature rise by 59%, recovering roughly seven percentage points of fleet capacity under the stated derate assumption. A — DENSE GRID +5.95 K Mean intake rise 11.9% fleet derate · worst intake ≈50 °C B — WIDE AISLE LOWEST PENALTY +2.46 K Mean intake rise 4.9% fleet derate · worst intake ≈41 °C C — ROOFTOP +6.26 K Mean intake rise 12.5% fleet derate · not a controlled comparison — 5.2% low on discharge momentum, a dead heat with A D — SPLIT FLANKING +2.84 K Mean intake rise 5.7% fleet derate · trades parcel width for pad area A / DENSE GRID The penalty accumulates through the packed array. The worst unit reaches +15.2 ± 1.3 K above ambient — about 50 °C entering air. B / WIDE AISLE The same 42 units with wider row spacing cut the fleet mean from +5.95 K to +2.46 K. WHERE THE TIME WENT Nine minutes of setup. Five and a half hours of physics. The corrected sweep ran end to end in 5 h 35 m, unattended. Solving the four layouts took 5 h 26 m of that. Everything else (geometry, meshing, calibrating every unit, writing the case configs) took nine minutes. GEOMETRY + MESH 6.5 MIN three new layouts UNIT CALIBRATION <1 SEC 42 units, per case SOLVER 5 H 26 M four layouts ENGINEER TOUCH TIME 0 MIN during the sweep itself Agents took the part a traditional study spends days on: preparing geometry, building a mesh per variant, and keeping boundary conditions from drifting between cases. The review did not shrink. An engineer still owns the physical model, the checks, and the recommendation, and that is where the time in this schedule go. MESH SENSITIVITY 1.4% 7.5 M → 14.4 M cells UNIT HEAT INPUT ≤0.16% deviation from specification JET MOMENTUM 0.05% agreement across A, B, and D MESH QUALITY PASS every case checked CONSERVATION AUDIT Mass-neutral to machine precision, heat input within 0.16% of specification. The far-field balance closes to 4–24%, but that is a difference of two numbers 3000× larger: 4–19 mK of outlet temperature, with signs on both sides. MESH SENSITIVITY Nearly doubling the cell count moved the fleet-mean result by 0.09 K, or 1.4%, small against the 3.49 K spread between layouts. THE RECOMMENDATION Choose between wide aisles and split banks based on the land you actually have. Both roughly halved the baseline penalty. Wide aisles protected the worst machine better; split banks used less paved pad and less downwind extent, but needed a wider parcel. Rooftop placement bought nothing measurable: a dead heat with the dense baseline. Its discharge momentum also ran 5.2% low, so we exclude it from the conclusion. BRING US THE DECISION You don't need a finished brief. Send us the geometry, operating point, and the decision you are trying to make. We will tell you what can be answered, what is missing, and the fastest defensible way to get there. TALK TO AN ENGINEER Disclosure: This is an independent study created by Navier to demonstrate our workflow. It was not performed for a customer and uses no customer data. OpenFOAM v2412, buoyantBoussinesqSimpleFoam, steady RANS with k-ω SST and ABL-consistent inlet conditions, Boussinesq buoyancy (β = 1/308.15 K⁻¹), bounded Gauss linearUpwind momentum advection, 960 × 600 × 180 m domain, constant coil duty. Results cover a single design-day condition (35 °C ambient, 3 m/s at 10 m, wind normal to the hall's long face), not an annual weather rose. Direction sensitivity is the single most valuable extension and is not covered here. Capacity percentages apply an assumed 2% per kelvin derate, stated linear over 35–46 °C entering air; the baseline's worst unit at ≈50 °C is an extrapolation, and in practice a machine at that intake is near high-pressure trip.

# ONERA M6 Transonic Validation — CFD Case Study | Navier AI
URL: https://www.navier.ai/case-studies/onera-m6

Validation study Transonic external aerodynamics The λ-shock, where the wind tunnel puts it. The ONERA M6 wing has been the standard transonic benchmark since 1979. We ran it at Mach 0.8395 and 3.06° against 270 of the 271 published pressure taps. The double-shock structure comes out right, and it merges between the span stations the experiment brackets. 270 / 271 PRESSURE TAPS COMPARED 0.071 POOLED RMS ΔCp 12.96 M CELLS OVERNIGHT GEOMETRY TO SOLVED RESULT THE ACTUAL TEST Matching a lift coefficient is easy. The M6 asks for the shock structure. At Mach 0.8395 and 3.06° incidence, the M6 develops a λ-shock on its upper surface: two separate compressions inboard that merge into a single shock toward the tip. The case exists to test that topology, not an integrated coefficient. We ran it as steady RANS with the Spalart–Allmaras model, using a density-based solver with an AUSM+up flux and a van Leer limiter. That keeps the compression inside about three cells instead of ten. A smeared shock defeats the point of the benchmark. One grid, one solve, no tuning against the answer. All 270 taps, all seven stations, on one page. THE HEADLINE Two shocks inboard, one outboard, merging in the right place. Two distinct compressions exist at η = 0.44, 0.65 and 0.80 in both the experiment and the simulation, and both collapse to a single shock by η = 0.90. The merge therefore happens between η = 0.80 and η = 0.90. That is consistent with NASA's independent choice of η = 0.80 as the shock-intersection station, and with ONERA's own description of two shocks merging on this run. At four of the seven stations the shock sits within the experiment's own tap spacing. Topology is harder to get right than a single number. FORCES · VS FIVE SOLUTIONS FROM FOUR CODES Within a few percent of codes running up to 28× the grid. The M6 database is surface pressures only, so lift and drag are compared against NASA's reference study (five solutions from four codes), not a tunnel. Four of the five ran 61–363 M cells at the converged end of a refinement study. We ran 12.96 M, wall-modeled, once. LIFT · CL −1.14% 0.26718 vs 0.26932 – 0.27120 DRAG · CD +3.24% 0.01755 vs 0.01695 – 0.01705 DRAG, VISCOUS · CDv +1.1% 0.005327 vs 0.005232 – 0.005309 PITCHING MOMENT · CMy 1.6% less nose-down −0.18770 vs −0.19187 – −0.18976 Skin friction within a third of a percent of a wall-resolved band, at a mean y⁺ of 30. We split our drag instead of reporting a total. The viscous part, the one a wall-modeled mesh is expected to get wrong, lands 0.34% above the top of the wall-resolved band and 1.1% from its midpoint, against a band 1.5% wide. That points to a boundary layer modeled well, not a lucky total. THE PHYSICS, ACROSS THE SPAN The supersonic pocket, shrinking root to tip. Mach number at the seven validation stations, one color map and one physical scale on every panel. The two-lobed structure inboard is the λ; by η = 0.90 it is a single shock. WHY WE PUBLISH THIS We publish the benchmark so you can check us. The AGARD tap data is public and the NASA reference study is published. Each comparison is labeled for what it is: experiment for surface pressure, code-to-code for forces. Check us against the same sources. READ THE FULL WRITE-UP BRING US THE HARD CASE Transonic, separated, or just expensive to mesh. If your program needs aerodynamic numbers someone will have to defend in a design review, send us the geometry and the operating point. We'll tell you what we can resolve, what we can't, and how much to trust the answer. TALK TO AN ENGINEER OpenFOAM v2412 with HiSA, steady RANS (Spalart–Allmaras), M∞ = 0.8395, α = 3.06°, Re_MAC = 11.72×10⁶, 12,962,287 cells, 3000 iterations. Experimental reference: AGARD AR-138 (1979) run 2308, surface pressure only. The database contains no force data, so CL, CD and CMy are compared code-to-code against the NASA Turbulence Modeling Resource SA-neg study (AIAA 2018-1102), not against measurement.

# Wigley Hull Free-Surface Validation — CFD Case Study | Navier AI
URL: https://www.navier.ai/case-studies/wigley-hull

Validation study Marine free-surface CFD Sinkage within 1.03 mm, across five speeds. The 3 m Wigley hull, free to heave and pitch, at five speeds against the 1983 cooperative towing-tank measurements. Every sinkage result lands within 1.03 mm. Total resistance carries a ±2.10% numerical uncertainty on a converged grid family. ≤1.03 MM SINKAGE ERROR · FIVE SPEEDS ±2.10% CT NUMERICAL UNCERTAINTY 5 FROUDE NUMBERS 4.34 M CELLS THE BENCHMARK A hull where a systematic error has nowhere to hide. The Wigley hull's geometry is analytic, so there is no offset table to get wrong, and the published measurements span a speed sweep, not a single point. Run five speeds instead of one and a systematic error has to show itself somewhere across the curve. One did. OpenFOAM v2412: interFoam with a VOF free surface and dynamic body motion, k-epsilon with a turbulent-viscosity limiter. Half-domain, 4.34 million cells, three hull lengths to the side boundary, 10 L/U per speed. Heave and pitch are free; the other four rigid-body motions are restrained. One detail matters more than the rest, and gets its own section below: a cell face is aligned on the waterline. Free-surface elevation at Fr 0.408: the transverse and diverging components of the Kelvin wake. SINKAGE · VS TOWING TANK Within 1.03 mm at every speed. The worst point is the slowest speed, where sinkage itself is only 2.70 mm; at Fr 0.316 the difference is 0.09 mm. Computed trim changes sign between Fr 0.250 and Fr 0.316 and grows bow-down from there. Skin friction stays close to the ITTC line, with Cv/Cf between 0.99 and 1.07. Predicted and measured sinkage across the Froude sweep Simulation results remain within 1.03 millimeters of the 1983 towing-tank measurements at all five speeds. 0 4 8 12 16 0.18 0.24 0.30 0.36 0.42 Towing-tank measurement Simulation Froude number Sinkage (mm) Froude number Simulation · mm Experiment · mm Difference · mm 0.177 1.67 2.70 1.03 0.250 4.12 4.80 0.68 0.316 7.41 7.50 0.09 0.374 11.49 12.00 0.51 0.408 14.34 15.00 0.66 WHERE THE FIRST ANSWER WENT WRONG The shape of the error is what gave it away. Sinkage varied 5.6 times across the speed range while the error stayed near-constant at +6.59 ± 0.80 mm. An offset that does not scale with the quantity it corrupts is a measurement-datum problem, not a physics failure. The fix is a mesh decision, not a turbulence-model knob. Fixed at source. Nothing tuned toward the curve. Aligning a cell face on z = 0 and widening the side clearance to three hull lengths removed the offset where it originated, instead of subtracting it afterward. Nothing in this study is corrected, offset, or tuned toward the experimental curve. That is why the sinkage agreement above means anything. TOTAL RESISTANCE · THE UNCERTAINTY BUDGET A resistance number that has stopped moving. At Fr 0.316 the total-resistance coefficient is Ct = 5.638 × 10⁻³ with a combined numerical uncertainty of 2.10%. It no longer moves with grid, time step or iteration, so it can be quoted with its error bar instead of as a bare number. GRID 0.77% GCI on the fine grid, observed order p = 1.635 ITERATIVE 1.70% Ct peak-to-peak over the mean, trailing 25% TIME STEP 0.95% Ct shift when the max Courant number is halved COMBINED 2.10% root-sum-square of the three components Fr 0.316: free surface, rigid-body motion, and the pressure and viscous resistance coefficients. The iterative uncertainty is the peak-to-peak scatter over the trailing quarter of these traces. THE GRID FAMILY Three grid studies failed before one worked. None failed on physics. Refining everything at once let the mesher reach a different prism-layer coverage on each member (75, 88 and 91%), so the near-wall treatment changed along with the grid, and Cv/Cf drifted from 1.009 to 1.159. A grid study whose members do not share a wall model is not measuring discretization error. Holding the hull-adjacent cell at 12.5 mm and coarsening only the bulk restored geometric similarity. Ct then moved 1.4% across a 14× cell-count range, at an observed order of 1.635. Grid Cells Layer coverage · % Ct × 10³ Cv/Cf Coarse 305,468 88.0 5.558 1.015 Medium 711,709 90.9 5.579 0.997 Finest 4,338,220 88.1 5.638 1.009 THE WAVE TANK ITSELF Check the instrument before you trust the reading. Before the hull results mean anything, the tank gets checked on its own: a two-dimensional Stokes II case with no hull in the domain. Wavelength lands within 1.79% of linear theory and wave height within 2.30%. This says nothing about the hull. It says the waves arriving at the hull are the waves we asked for. One feature is still unexplained. Wave-height modulation grows from 10.4% to roughly 21% with distance down the tank. The obvious suspect is outlet reflection, but porous beaches of two and three wavelengths each moved it by less than a point. That explanation is not established, and we don't claim it. SCOPE What the study covers, and what it leaves out. Sinkage is validated against the 1983 cooperative towing-tank measurements at all five speeds. Total resistance is reported with its numerical uncertainty from the grid, time-step and iterative studies, and the skin-friction component stays within 7% of the ITTC line at every speed. The domain sizing, the waterline-aligned mesh and the single near-wall setting were chosen for this hull at these speeds. The study establishes nothing about the items listed outside it. SUPPORTED BY THIS STUDY Sinkage at five Froude numbers Computed trim trend and sign reversal Skin-friction ratio, Cv/Cf Numerical uncertainty on Ct, ±2.10% Grid convergence across the mesh family Wave generation and propagation OUTSIDE THIS STUDY Trim against measurement Far-field wave-tank modulation Seakeeping or RAOs A second mesh family or near-wall setting BRING US THE HARD CASE Free surface, moving bodies, or a number someone has to defend. Send the geometry, the operating conditions and whatever reference data exists. An engineer will tell you what can be tested, what evidence it will take, and what the comparison will not be able to prove. TALK TO AN ENGINEER OpenFOAM v2412, interFoam VOF with DFBI rigid-body motion, k-epsilon with a turbulent-viscosity limiter. L = 3 m Wigley hull (B/L 0.1, T/L 0.0625, Cb = 4/9), free in heave and pitch, restrained in surge, sway, roll and yaw. Half-domain, 4,338,220 cells, three hull lengths of side clearance, 10 L/U per point, a cell face aligned on z = 0. Scatter is quoted peak-to-peak over the trailing 25%. Experimental reference: the 1983 cooperative towing-tank program, sinkage. Ct is reported with its combined numerical uncertainty from the grid, iterative and time-step studies.

# Jet-Mixed Tank Sludge Deposition — CFD Case Study | Navier AI
URL: https://www.navier.ai/case-studies/tank-sludge

Design study Storage-tank mixing Where sludge settles, and the aim that decides it. A 12 m storage tank with two shell-mounted mixing nozzles. The pump, the nozzles and the flow rate are fixed; the only variable is which way the nozzles point. Aimed across the tank, they leave 90% of the floor below the shear stress that keeps sludge moving. Turned 53° to spin the tank, they leave 62%, and the tank-side pressure the loop has to overcome falls instead of rising. The tank and the loop. Red is the as-installed radial aim; green is the recommended 53°. Nozzle position, elevation, throat area, flow rate and jet velocity are identical in both. 90% → 62% FLOOR BELOW SLUDGE THRESHOLD 4.0× MORE SWEPT FLOOR AREA 0 NEW HARDWARE · SAME PUMP 13 CONFIGURATIONS THE PROBLEM Given a fixed pump, how much of the floor stays clear, and what decides it? Sludge does not settle evenly. It settles where the liquid above it is not moving fast enough to carry it, and that is a property of the flow field, not of the tank. A cleaning contractor who knows where the deposit is can plan a non-entry clean against a drawing instead of an estimate. An operator who knows why it is there can often stop it forming. The quantity that decides whether a deposit forms is the wall shear stress on the floor, so the deliverable is one number: the fraction of floor area where shear falls below the critical value. The answer turns out to be the nozzle aim, which costs nothing to change and is usually set by whatever the pipe routing made convenient. Tank 12.0 m × 4.0 m 452 m³, 113 m² of floor Fluid 870 kg/m³, 11.5 cSt medium crude at storage temperature Nozzles 2 × 168 mm bore at 0.50 m above the floor Jet velocity 7.0 m/s jet Re 1.0 × 10⁵ Recirculation 1113 m³/h one tank turnover every 24 min Sludge threshold τc = 1.5 Pa swept over 0.5–3.0 Pa as a sensitivity AS INSTALLED The momentum is not too small. It is aimed at the outlet. Two jets fired radially into a cylinder do not organize the tank. They cross, meet, and leave together for the suction. The result is a narrow high-shear lane joining the two nozzles to the outlet and stagnant liquid everywhere else: 90% of the floor below threshold, and a mean floor shear of 0.66 Pa against a peak of 8.7 Pa. There is enough momentum in the tank. It is spent in one direction and removed through the suction, instead of being handed to the tank as circulation. Speed on the nozzle plane. Left: radial aim. The jets meet near the center and the combined stream runs straight to the suction, leaving the rest of the tank still. Right: re-aimed, the same two jets set the whole tank rotating. Floor wall shear stress, area-weighted onto a polar grid and averaged over the settled part of the run. Red is below the sludge threshold and will accumulate; green is swept. The dead region is not opposite the nozzles; it is everywhere the jets are not. TURNING THE NOZZLES The recommendation is a band, not an angle. The sweep varies aim and nothing else: nozzle position, elevation, throat area, flow rate and delivered momentum are identical at every angle. The first 31° of turn takes 90% to 63%, which is 97% of the whole available gain for a change that costs a flange rotation. Aim β Dead area · % settled Swept · % Mean τw · Pa Median τw · Pa Tank head · Pa 0° 90.4 ±3.3 9.6 0.66 0.32 8769 31° 63.0 ±2.9 37.0 1.48 1.27 8536 41° 62.1 ±2.3 37.9 1.56 1.25 8279 48° 62.1 ±0.9 37.9 1.64 1.23 7952 53° 62.0 ±0.7 38.0 1.70 1.23 8018 60° 65.6 ±0.8 34.4 1.74 1.23 8261 65° 68.9 ±0.7 31.1 1.72 1.16 8515 Dead floor area against aim angle. Vertical bars are the scatter of the per-iteration answer across the averaging window: the flow does not settle to a fixed point, and that scatter is carried rather than hidden. Between 41° and 53° the answer moves by 0.1 points, which is inside the run-to-run scatter, and past 53° it gets worse again. So the recommendation is 41–53°: every angle whose answer falls inside the best case's own window scatter. That matters in practice. An installer setting a nozzle against a shell has a few degrees of tolerance at best, and a recommendation that needed 53° exactly would not survive the field. WHY IT WORKS, AND WHY IT STOPS The two arrangements fail in opposite places. A tangentially aimed jet does not spend its momentum on the far wall. It attaches to the shell and drives a rotating cell that fills the tank, so the near-wall floor sees moving liquid all the way around instead of only along one lane. Mean floor shear rises from 0.66 to 1.70 Pa, a factor of 2.6, on identical pump duty. But rotation has a center, and the center does not move. Past the optimum the flow is increasingly a solid-body-like swirl with a stagnant core, and floor area lost at the middle starts to outweigh floor area gained at the rim. That trade is the minimum in the curve, and the reason the recommendation tops out around 53° rather than running as tangential as the shell will allow. Floor shear against radius, averaged around the tank, for every aim angle. Red is the as-installed radial aim; blues run from 31° to 65°. The radial arrangement puts its highest shear at the center and falls to 0.23 Pa at the shell; the swirling one does exactly the reverse. The two cross at about 3.3 m. Swirl wins on total area only because area grows with radius: the floor outside 3.3 m is 70% of the tank. It is not a better flow everywhere; it is a better flow where most of the floor is. WHAT RE-AIMING DOES NOT FIX 62% of the floor is still below threshold. That is a 4.0× improvement at no hardware cost, but it is not a clean tank, and stopping at the good number would mislead. The residual is concentrated in the central core, the same core the radial arrangement was scouring. Two things follow directly, and both were run. Tilting the nozzles down It does not help, and how it fails is instructive. Tilting the jets down raises mean floor shear sharply, 1.64 to 3.12 Pa or 91% more, while making the dead area worse. The extra shear all lands in a small patch directly under each nozzle, where the floor was already being swept, and it is paid for out of the bulk rotation that was sweeping everywhere else. This is why we don't report a mean alone. Downward tilt α Dead area · % settled Mean τw · Pa 0° 62.1 ±0.9 1.64 23° 66.1 ±1.2 2.64 31° 70.2 ±1.0 3.12 One nozzle of each If the radial arrangement sweeps the core and the swirling one sweeps the rim, the obvious move is one of each. It is the first thing anyone suggests on seeing the radius plot, and it is the worst of the three. The radial jet fires straight through the middle of the rotation the other nozzle is trying to establish and breaks it up, while half the radial momentum is not enough to scour the core. Circulation in a tank is not additive across nozzles: it has to be driven coherently or it is not driven at all. Aim · N1 / N2 Dead area · % settled Mean τw · Pa τw on axis · Pa τw at wall · Pa 53° / 53° 62.0 ±0.7 1.70 0.05 2.70 0° / 53° 89.7 ±1.3 0.95 0.37 0.92 0° / 65° 89.3 ±1.1 1.01 0.26 1.77 Both nozzles turned, against one radial and one tangential. The mixed arrangement has flow everywhere and enough shear almost nowhere. Dead area against the assumed sludge threshold. The direction of the recommendation holds across the whole plausible range; its size does not. At 0.5 Pa the re-aim is worth 52 points of floor area, at 1.5 Pa 28, and at 3.0 Pa 9. Everything that would actually close the remaining 62% needs momentum delivered somewhere the shell cannot reach it from, or more of it: a third nozzle, a floor-mounted riser, or a higher jet velocity at the same pump flow through a smaller bore. None of those was run, and no number is claimed for them. LIMITATIONS Stated rather than buried. Steady solver on an unsteady flow. The largest single source of uncertainty here. Single phase. The sludge itself is not modeled; floor shear stands in for it. The 1.5 Pa threshold is an assumption, not a measurement of this sludge. Wall functions. The near-wall profile is modeled, not resolved. Rigid flat lid. The free surface cannot deform. One duty point: 1113 m³/h at 7 m/s. BRING US THE DECISION Before you book the tank clean. If you are budgeting a non-entry clean, or wondering why one tank in a farm keeps filling with solids, send us the arrangement and the duty. Some of the answers cost a flange rotation. TALK TO AN ENGINEER OpenFOAM v2512, simpleFoam, steady, incompressible, SIMPLEC, k–ω SST with wall functions. Five-block O-grid from blockMesh with four nested hexRef8 levels on the floor band, jet paths and port mouths; max non-orthogonality 52.8, max skewness 0.61. Nozzle ports are a whole number of mesh faces at every admissible aim angle so flow rate and jet velocity are both held exactly. 3,000 SIMPLE iterations, fields averaged over the last 1,000. Basis: a representative geometry, not a named client.

# Heat Exchanger Inlet Duct Uniformity — CFD Case Study | Navier AI
URL: https://www.navier.ai/case-studies/hx-duct

Design study Industrial ductwork The elbow that starves a heat exchanger. A short-radius bend discharging into an exchanger casing delivers 13.8% RMS non-uniformity across the tube face, against a 10% specification. Turning vanes inside the existing elbow clear it and take pressure off the fan instead of adding it. Add a distribution plate to the same vanes and the face reaches 1.9%, still cheaper to run than the duct as drawn. Gas enters at 12 m/s, turns through a short-radius elbow, dumps into the casing and passes the tube bundle. Uniformity is judged on the plane where the gas enters the bundle. 13.8% RMS AS DESIGNED · SPEC IS 10% 1.9% RMS · VANES AND PLATE −26 PA FAN DUTY, NOT MORE 12 CONFIGURATIONS THE PROBLEM An exchanger is bought on a duty, and the duty assumes the gas arrives evenly. Ductwork rarely obliges. Where the plant room is tight, the last thing upstream of the casing is often a short-radius elbow and a sudden expansion, and both do the same thing: they put all the momentum on one side and leave the rest of the face to be fed by whatever recirculates back into it. Non-uniformity here is the area-weighted RMS deviation of flow per unit area from its own mean. Flow rather than velocity, because it sums to the inlet flow exactly. Recirculation is reported separately, and measured upstream of the face: a core this resistive suppresses reverse flow at its own inlet plane, so a face-only metric would report zero recirculation for a plenum half filled with it. Duct 500 mm square 12 m/s, Re 1.7 × 10⁵ Bend R/D = 0.75 short radius, no vanes as designed Casing 1200 mm square 1.44 m² face, 5.8:1 expansion Core 250 mm deep, 150 Pa face velocity 2.08 m/s Fluid 0.746 kg/m³, 34.9 cSt flue gas at about 200 °C Flow 10,800 m³/h 3.00 m³/s AS DESIGNED The gas cannot turn a corner that tight. It separates off the inner wall of the elbow, and the separation bubble narrows the duct's effective exit, so the gas arrives at the expansion as a jet that is both faster and narrower than the duct that made it. It then crosses the plenum as a jet instead of spreading into it, and 16% of the plenum ends up recirculating around it. At the face that lands as 13.8% RMS against a 10% specification, with a peak of 1.41× the mean. The duct fails. Speed on the plane of the bend. Left: as designed. The jet separates off the inner wall, crosses the elbow and drives straight through the plenum to one side of the core, with a recirculation filling the rest of the casing. Flow per unit area where the gas enters the bundle, as a multiple of the mean. The dashed rectangle is the duct footprint projected onto the face. The defect is mostly a center-peaked jet with a starved perimeter. TURNING VANES The fix that pays for itself. A turning vane is a strip of sheet metal on a constant radius inside the elbow. It splits one impossible turn into several achievable ones: each channel is short enough and its radius ratio gentle enough that the gas stays attached. Nothing else about the duct changes. Vanes RMS · % settled Plenum recirc · % Peak / mean Duty short · % Δp · Pa 0 13.8 ±0.39 16 1.41 0.57 211 1 11.5 ±0.06 14 1.35 0.41 193 2 9.5 ±0.30 13 1.25 0.28 186 3 8.4 ±0.20 9 1.23 0.22 182 4 7.7 ±0.27 11 1.22 0.19 185 Uniformity and duty against vane count. Bars are the movement of the answer over the last part of the run. The first vane does most of the work: 13.8% becomes 11.5% for a single strip of steel. Where to put them Three vanes can be spaced evenly across the gap, or on a constant radius ratio, the classical rule, which crowds them toward the inner wall where the turning is sharpest. Both were run, at the same vane count, in the same elbow. The classical rule wins, and the margin is small enough that fabrication tolerance matters as much as the rule does. 3 vanes at Radii · mm RMS · % Duty short · % Δp · Pa even spacing 250, 375, 500 8.4 0.22 182 constant radius ratio 179, 286, 411 8.1 0.21 179 THE OTHER FIX A plate is the more powerful device, and the more expensive habit. The standard alternative is to leave the elbow alone and put a perforated distribution plate across the casing ahead of the core. It adds a resistance in series with the bundle, and a resistance in series makes the flow through it more even. It works better than the vanes do, 4.3% RMS from a K = 2 plate against 7.7% from four vanes, because it acts on the whole face at once instead of on the thing that spoiled it. But look at what it does upstream of itself. Plenum recirculation goes up with a plate fitted, from 16% to 24%, because the plate blocks the jet and the blocked gas has to go somewhere. The vanes take the same number from 16% to 9%. The plate does not remove the recirculation; it stops the recirculation reaching the face. One treats a symptom, the other removes the cause, and the numbers show it. Plate RMS · % Center peak · % Duty short · % Δp · Pa vs as designed none 13.8 28 0.57 211 +0 K = 2 4.3 9 0.06 246 +35 K = 4 3.0 6 0.03 249 +38 Uniformity against the pressure drop it costs. The two fixes move in opposite directions. Vanes go down and to the left: more uniform and cheaper. A plate goes down and to the right: more uniform and costlier. It also has to be paid for on every hour the plant runs. The K = 2 plate costs +35 Pa, about 160 W of shaft power at 3.0 m³/s and 65% fan efficiency. The vanes cost −26 Pa, which is to say they give 119 W back, because a vaned elbow has a lower loss coefficient than a separated one. The two fixes at the face. A plate flattens the profile by resisting it everywhere; vanes flatten it by never creating the jet. BOTH TOGETHER Fix the cause first and the plate costs less than it does alone. Three vanes and a K = 2 plate give 1.9% RMS at 204 Pa: seven times more uniform than the duct as designed, for 7 Pa less pressure drop than the duct as designed. The duty shortfall falls from 0.57% to 0.01%. The arithmetic is not additive. Separately the vanes save 29 Pa and the plate costs 35 Pa, which would put the combination +6 Pa against the duct as designed. It actually comes out −7 Pa, some 13 Pa better than the parts predict: with the jet already removed the plate has less to correct, and its own loss does less harm. If the specification is the 10% this study started from, the combination is not needed. Three vanes reach 8.4% and save 133 W. Two reach 9.5%, inside the specification but not clear of it once the 0.6-point spread across the grid study is allowed for, so three is the number to fit. Face velocity across the casing in the plane of the bend, labeled by vane count. The as-designed profile is the one that goes negative. LIMITATIONS Stated rather than buried. Single phase and isothermal. No buoyancy in the plenum, no fouling layer. The core is a porous zone with real depth, not modeled tubes. The plate's uniformity benefit is model-dependent. Its pressure penalty is not. Grid convergence on uniformity is not monotone, so no GCI is quoted. Uneven fouling and tube metal temperature are not priced. BRING US THE DECISION Before the casing is fabricated. If an exchanger is not making its duty, or a purchase specification names a uniformity figure nobody has checked, send us the duct arrangement and the flow. The cheapest fixes are usually upstream of the thing that is failing. TALK TO AN ENGINEER OpenFOAM v2512, simpleFoam, steady, incompressible, k–ω SST with wall functions. Hexahedral mesh from blockMesh, Cartesian throughout except the bend; max non-orthogonality 0.74, max skewness 0.034. Core as a Darcy–Forchheimer zone 250 mm deep, F = 371 m⁻¹ along the flow and 3706 across it. Vanes as zero-thickness walls cut from internal faces at constant radius. 2,500 iterations. Pressure differences are inlet-to-outlet static. Basis: a representative duct, not a named client.

# Natural Ventilation in a Glazed House — CFD Case Study | Navier AI
URL: https://www.navier.ai/case-studies/house-vent

Design study Natural ventilation The house that only cools when the wind blows. A heavily glazed house was designed on the assumption that natural wind would ventilate it. It has two openable windows and they are at the same height. In a 3 m/s breeze that gives 13 air changes an hour. In still air it gives 0.73, and the mezzanine reaches 35.7 °C with the outdoor air at 24 °C. Roof vents remove the dependence on the weather, and shading the glass reaches a similar place on a fraction of the air flow. The house in section. Both openable windows sit at 1.5 m, so there is no height difference between them for warm air to exploit. 0.73 ACH STILL AIR, AS BUILT 35.7 °C MEZZANINE · 24 °C OUTDOORS −5.8 K MEZZANINE, FOUR ROOF VENTS 13 CONFIGURATIONS · 18 SOLUTIONS THE SYMPTOM The design assumed natural ventilation. It said nothing about what happens when the wind stops. A glazed, open-plan house with a mezzanine over the back half: comfortable on some days, unbearable on others, and the mezzanine always worse than the ground floor. The design argument holds when the wind blows. Then the building performs. The house is extensively glazed, but as usual almost all of that glazing is fixed. Only two windows open, and they are at the same height. That single fact is the whole fault. It leaves the building with one driver, and it is the one nobody controls. Volume 389 m³ 9 × 7.2 × 6 m, mezzanine at 3 m Openable area 1.44 m² two windows, both at 1.5 m Outdoor air 24 °C a warm day Solar load glazing 50 °C roof 35 °C, floor 32 °C Design wind 3 m/s Cp +0.70 windward, −0.30 leeward, −0.60 roof WHAT THE WIND WAS DOING FOR THE DESIGN Halving a light breeze does not halve the cooling. It removes most of it. Ventilation is not imposed here. The openings are held at the static pressure the wind puts on them, and how much air actually moves is an outcome. Between 1.5 and 0.75 m/s the ventilation rate falls from 5.7 to 1.2 ACH and the mezzanine gains 2.9 K. Below about 1 m/s the wind pressures fall to the same order as the buoyancy this house cannot exploit, and neither driver has much left. Wind · m/s As built · ACH Mezz · °C Ground · °C ΔT floors · K Vented · ACH Vented mezz · °C 0.00 0.73 35.7 31.3 4.39 3.59 29.9 0.75 1.18 34.9 30.5 4.46 4.75 29.0 1.50 5.67 32.0 26.8 5.24 8.72 27.2 3.00 12.79 29.7 26.1 3.59 19.49 26.6 Ventilation rate against wind speed. The as-built house is almost entirely wind-driven: take the wind away and the ventilation goes with it. The vented house keeps working, because it has a second driver that does not depend on the weather. The second thing in that table is easier to miss and harder to fix. Stratification is 4.4 K in still air and 5.2 K at 1.5 m/s: cross-ventilation makes the split between the floors worse before it makes it better, because it flushes the story its windows are on and leaves the one above untouched. At 13 air changes an hour the ground floor is comfortable at 26.1 °C while the mezzanine is still at 29.7. More wind does not settle the argument. STILL AIR The height matters more than the hole. With no wind, the only thing left to move air is buoyancy. Warm air rises and will leave through any opening above the level it entered, and the as-built house has no such opening. Both windows are at 1.5 m, so what is left is each window exchanging air with itself: warm air out of the top, cooler air in at the bottom. That carries 0.73 air changes an hour against the 13 the same house achieves in a breeze. Roof vents do not fix this by area alone. Adding the same 1.44 m² at window height would do almost nothing. They fix it by putting an opening 4.5 m above the windows, which gives buoyancy something to work against. In still air the vented house reaches a mezzanine at 29.9 °C, very nearly what the as-built house achieves on its best day, in a full breeze. The vents do not make the house better than it has ever been. They make its worst day as good as its best one. Air temperature on a section through the room, in still air. Left: as built. Heat from the glazing and the floor collects under the roof and floods the mezzanine. Right: with roof vents, the same heat leaves through the top of the room instead of accumulating in it. Horizontally averaged air temperature against height, in still air. The as-built profile is the one that climbs; adding vent area both lowers it and flattens it. HOW MUCH VENT IS ENOUGH The first pair does most of it. All in still air, which is the condition the design has to survive. Returns flatten once the vent area approaches the window area: openings in series combine as 1/A² = 1/A²in + 1/A²out, so beyond that point the fixed 1.44 m² of window limits the flow, not the roof. Vents Area · m² ACH Mezz · °C Ground · °C ΔT floors · K % out through roof 0 0.00 0.73 ±0.07 35.7 31.3 4.39 0 2 0.72 2.51 ±0.66 31.3 27.9 3.45 99 4 1.44 3.59 ±0.54 29.9 26.9 3.06 100 6 2.16 5.04 ±0.45 29.2 26.5 2.64 100 Ventilation and occupied temperature against roof vent area, in still air. The ground floor was never the problem; the mezzanine is where the vents do their work. THE OTHER LEVER Stop the heat arriving, and you need a sixth of the air. External shading takes the sunlit glazing from 50 to 32 °C and the sunlit slab from 32 to 26 °C, and changes nothing else about the building. Vents alone give a mezzanine at 29.94 °C; shading alone gives 30.62. Ventilation is ahead by 0.68 K, and the grid convergence index on occupied temperature is 0.58 K, so the two levers are not separable at this level of numerical accuracy. What does separate them: shading reaches the same place on six times less air. Still air ACH Ground · °C Mezzanine · °C ΔT floors · K kW removed by the air as glazed 0.73 31.3 35.7 4.39 0.83 as glazed + vents 3.59 26.9 29.9 3.06 1.78 shaded 0.57 26.7 30.6 3.91 0.29 shaded + vents 2.13 25.1 26.9 1.73 0.46 The four still-air arrangements, and the as-built house on a windy day for scale. The best result is not the one with the most ventilation; it is down and to the left, at less than a fifth of the windy-day air change rate. How much of the mezzanine sits above a given temperature. The threshold is a judgment rather than a measurement, so the whole curve is shown instead of one number. Does it matter where the vents go? Barely. Moving all four vents from over the double-height void to over the mezzanine changes ventilation from 3.59 to 4.13 ACH and the mezzanine from 29.9 to 29.88 °C, differences sitting right at the edge of the settled band on either case. The negative result is the useful one. What makes a roof vent work is the height difference between it and the inlet, and both positions have essentially the same one. Plan position is a detail; section position is the design. LIMITATIONS Stated rather than buried. Solar gain is imposed as surface temperatures, not computed. No radiation model. Steady solver on an unsteady flow. Ventilation is over-predicted by 42 to 54%. Read an absolute air change rate as good to about a factor of two. One weather condition and one occupancy. No internal gains, no night purge. BRING US THE DECISION Before the glazing is ordered. If a building is being asked to cool itself, the question is what it does on the day the wind stops. Send us the section and the climate, and we will tell you which lever actually moves the answer. TALK TO AN ENGINEER OpenFOAM v2512, buoyantBoussinesqSimpleFoam, steady, Boussinesq buoyancy, k–ω SST with wall functions. Hexahedral mesh from blockMesh; mezzanine as a zero-thickness baffle; openings cut on existing face boundaries, held at wind static pressure via totalPressure on p_rgh. Solar gain imposed as raised surface temperatures, no radiation model. 4,000 iterations, settled band taken over the last 1,000. Basis: a representative house, not a named client.

# Jet Mixing in a Stratified Water Tank — CFD Case Study | Navier AI
URL: https://www.navier.ai/case-studies/tank-mixing

Design study Potable water storage What decides whether a storage tank actually mixes. Transient, buoyancy-driven jet mixing in a stratified 246,727-gallon potable water tank, five inlet configurations run concurrently on one workstation. Destratification is set by the momentum flux the inlet delivers, not by flow rate and not by Froude number. 2.7× MORE DESTRATIFICATION · SAME FLOW 1.6% APART ON A CONTROLLED MESH 5 CASES CONCURRENT ON ONE BOX 2.8 H WALL CLOCK, ALL FIVE THE FINDING Mixing tracks jet momentum flux. The matrix was built to let that answer lose. The case matrix was organized on the densimetric Froude number, Fr = U/√(g′d), on purpose, because it gives a velocity-holding port a chance to fail. It didn't. The destratification rate tracks jet momentum flux, Q·U. This is not a new result. Rossman and Grayman established from scale-model experiments in 1999 that tank mixing time during fill scales as V²ᐟ³/M¹ᐟ², with M = Q·U, and it is the basis variable-orifice inlets are designed on. This study reproduces that structure independently, from first principles. Tank 40 ft × 26 ft SWD 246,727 gallons, potable water Stratification 5 K thermocline at 55% of depth Solver OpenFOAM v2412 buoyantBoussinesqPimpleFoam, transient Model URANS k-ω SST deliberately not labeled LES Mesh block-structured O-grid locally refined on the four jet columns Cases 5 concurrent one 64-core workstation TWO CASES SETTLE IT Froude numbers 2.8× apart, momentum flux identical. The results overlap. A2 is a fixed nozzle at 500 gpm. A5 is a variable orifice at 250 gpm with the port throttled to a quarter of its area. Their momentum flux is identical by construction, and they land within 1.1% of each other on mixing index, on residual stratification, and on tracer uniformity. A3, meanwhile, has a lower Froude number than A5 and almost three times the mixing. Froude ordering is wrong by about 200%, far outside any numerical doubt here. Mixing index against jet momentum flux at the common comparison time. The variable-orifice case sits on the fixed-nozzle curve, not above it, which is the point: it is not doing anything exotic, it is buying momentum that a fixed nozzle only gets from more flow. Froude number still does a job: it predicts whether the jet penetrates the thermocline at all. A1 at Fr 17 stalls at 0.57× tank depth, A5 at Fr 98 reaches 1.61×. What it does not set is how fast the tank then turns over. That is two parameters, not one. THE CONTROLLED COMPARISON Same mesh, same timestep, only the port differs. C2 (fixed 4×100 mm port, 500 gpm) against A5 (variable orifice 4×50 mm, 250 gpm) on an identical mesh at an identical 0.3727 s timestep. They finish 1.6% apart on mixing index, 0.2542 against 0.2501, while A5 carries half the flow. Mesh and timestep are controlled; only the port area differs. Half the flow, the same mixing. Case Inlet gpm U · m/s Fr Re z max /H M @ 18 min A1 Fixed nozzle 250 0.50 17 50k 0.57 0.091 A2 Fixed nozzle 500 1.00 35 100k 1.14 0.247 A3 Fixed nozzle 1000 2.00 69 199k 2.28 0.734 A4 Fixed nozzle 2000 3.99 138 399k 4.56 0.984 A5 Variable orifice 250 2.00 98 100k 1.61 0.250 C2 Fixed nozzle 500 1.00 35 100k 1.14 0.254 Every case was generated from one parameter table, and all values are as simulated, computed from the discrete inlet area of the mesh, not from the nominal circle. A3 is both design points: at 1000 gpm the variable orifice is fully open, so fixed and variable are the same simulation. It is run once and reported once. WHAT THE TANK LOOKS LIKE One jet stalls under the thermocline. The other works on it. Vertical section through two opposed nozzles, colored by temperature. Cold inflow enters at the floor; the warm stored layer sits above the thermocline at 55% of depth. Both frames are the same 250 gpm. A1, fixed nozzle at 250 gpm. The jet cannot reach the thermocline. Cold water spreads along the floor toward the drain. A5, variable orifice at the same 250 gpm. The jet reaches the thermocline and works on it: residual stratification is 3.96 K after 18 minutes, against A1's 4.82 K. A1. The four jets rise but stall below the thermocline (orange surface). The stratified layer above is barely touched. A5. Same flow as A1, four times the jet velocity. The jets reach the thermocline and spread along it, eroding it from below. One panel per case, single series each, the whole matrix on one row. THE COMMERCIAL ARGUMENT Q² becomes Q. That is the case for a variable orifice. For a fixed nozzle, U = Q/A, so momentum flux Q·U scales as Q². Mixing performance therefore falls with the square of turndown. Halve the flow and you lose three quarters of your mixing energy. A variable orifice that throttles area to hold jet velocity makes momentum scale as Q instead: linear, not quadratic. At 8:1 turndown that is an 8× advantage in momentum. Scaling beyond what was simulated is arithmetic, not simulation, and is flagged as such. The fitted exponent on the unsaturated fixed-nozzle cases is M ∝ (Q·U)⁰·⁷⁵², so an 8× momentum advantage extrapolates to roughly 4.8× the mixing, not 8×. The largest turndown actually simulated is 2:1 in flow at 4:1 in area. MEASURED HERE, UNDER CONTROL Throttling to 25% port area at 250 gpm produced mixing indistinguishable from a fixed nozzle at 500 gpm: 0.2501 against 0.2542, a 1.6% difference against a measured numerical uncertainty of 2.7%. Half the flow, the same mixing. BRING US THE DECISION Before the inlet manifold is specified. If a tank has to hold water quality across an 8:1 turndown, the question is what the inlet delivers at the bottom of that range, not at the top. Send us the tank and the duty curve. TALK TO AN ENGINEER OpenFOAM v2412 (ESI), buoyantBoussinesqPimpleFoam, transient, Boussinesq buoyancy, k-ω SST run URANS. Block-structured O-grid, locally refined on the four jet columns; max non-orthogonality 39.9°, max skewness 0.635, volume error −0.03%. Transported scalars: temperature, inlet tracer, water age and chlorine with first-order decay. Full prototype scale, no model scaling. Comparison time 1080 s of tank fill. Basis: a representative tank, not a named client.

# CFRP Composite Layup Trade Study — FEA Case Study | Navier AI
URL: https://www.navier.ai/case-studies/composite-layup

Design study Composite structures Which carbon-fibre layup survives the load? Same plies, same mass, same plate: only the stacking order changes. Under 0.02 MPa only the unidirectional stack passes. The quasi-isotropic stack, the usual safe default, is the first to fail. In all four it is the matrix that cracks, at the bolted edge, while the fibres never reach 90% of their strength. Tsai-Wu failure index over the plate at the design load, worst ply through the thickness. Inside the black contour the ply has failed; the star marks the critical point, always on the bolted edge. +0.87 MARGIN · [0]₁₆, THE ONLY PASS 10.1 KPA QUASI-ISOTROPIC FAILS FIRST 180% PEAK TRANSVERSE STRESS / Yₜ 20 SOLVES · 86 S IN TOTAL THE PROBLEM The plies are fixed. Only their order is up for decision. A flat carbon/epoxy plate is bolted along one edge and loaded by a uniform pressure over its face. Sixteen plies, 2 mm of laminate, one material. The four candidate stacks share the mesh, the mass and the ply properties, so any difference in the results is the layup and nothing else. Each composite shell is expanded into a stack of sixteen quadratic bricks, one per ply, so stress and strain are resolved inside every individual ply rather than smeared through the thickness. Failure is then judged in each ply's own fibre axes, at every node, by three criteria: maximum stress, Tsai-Hill and Tsai-Wu. Tsai-Wu carries the headline margins. Plate 200 × 100 × 2.000 mm left edge bolted, three edges free Plies 16 × 0.125 mm carbon/epoxy, T300/914 class Mass 3.16 kg/m² identical for all four layups Load 0.02 MPa, uniform 400 N over the face, normal to it Cure 453 K → 293 K stress-free at cure, 160 K cool-down Model 128 S8R composite shells expanded to 2,048 C3D20R ply bricks Case Stacking sequence · bottom to top Symmetric Balanced ud [0]₁₆ yes yes crossply [0/90]₄ₛ yes yes quasi [45/0/−45/90]₂ₛ yes yes unsym [0]₈[90]₈ no yes The supplied model carries stiffness but no strength, so the five ply allowables a failure criterion needs were added from the standard published set for this class of material. They are an assumption, and the conclusion rests on one of them in particular: Yₜ, the tensile strength across the fibres. Fibre tension · MPa Fibre compression · MPa Transverse tension · MPa Transverse compression · MPa In-plane shear · MPa 1500 1200 50 250 70 STIFFNESS In-plane isotropy is the wrong thing to buy for bending. Bending along the plate is resisted by the plies furthest from the mid-plane. [0]₁₆ puts fibres there and is the stiffest. The quasi-isotropic stack puts ±45° plies on both surfaces and deflects 2.1× further. The unsymmetric stack is worst at 3.5×, because its extension–bending coupling lets the bending moment stretch the laminate as well, a compliance no symmetric stack has. Deformed shape at 0.02 MPa, true scale, one colour scale. Only the quasi-isotropic stack twists, 4.25 mm across the tip: it is isotropic in-plane, but its bend–twist coupling terms are not zero. Mid-width deflection, large-deflection solid against linear dashed. The plate deflects 21 to 73 times its own thickness, far outside small-deflection plate theory. The deflections are large enough that a linear solution is no longer the answer. It over-predicts by 1% for [0]₁₆ and by 25% for the unsymmetric stack, which rotates far enough that the pressure stops acting on its original moment arm. Every margin below therefore comes from the geometrically nonlinear solution. The linear one is kept as a comparison, and the comparison turns out to matter less for stress than for shape: the root moment is fixed by statics, so the peak ply stress at the bolted edge moves by under 2% in the symmetric stacks. Layup Tip deflection · linear, mm Tip deflection · nonlinear, mm Linear over-predicts Tip twist · mm Deflection / thickness [0]₁₆ 42.7 42.1 +1% 0.00 21 [0/90]₄ₛ 68.4 66.2 +3% 0.00 33 [45/0/−45/90]₂ₛ 96.1 86.9 +11% 4.25 43 [0]₈[90]₈ 181.8 145.3 +25% 0.00 73 PLY BY PLY The fibres are fine. The matrix runs out. The largest fibre stress anywhere is 1,302 MPa in the quasi-isotropic stack, 87% of Xₜ. The transverse stress reaches 90 MPa, 180% of Yₜ. Carbon/epoxy is about thirty times stronger along the fibre than across it, so unless a laminate is designed to keep transverse stress out of its plies, the matrix fails first. Ply stress in fibre axes through the thickness at the bolted edge, against the allowables. Fibre stress, top, stays inside Xₜ everywhere. Transverse stress, bottom, breaks out of ±Yₜ in three of the four layups. The saw-tooth is real: each ply carries the share of load its own fibre direction earns, so stress jumps at every interface. Two sources of transverse tension, both set by the layup A 90° ply between 0° plies is forced to follow their axial strain, which puts it into tension across its own fibres. That is why the cross-ply's critical ply is a 90° ply carrying 70 MPa of transverse stress and almost no fibre stress at all. The bolted edge adds the rest. It holds the plate's width while the plate tries to contract under axial tension, and the restraint becomes transverse tension directly. Every critical point in the study lies on that edge, in an outer ply on the tension face. Layup Critical ply Fibre stress · MPa Transverse stress · MPa Shear stress · MPa Mode [0]₁₆ 1 · 0° 614 21.4 0.9 matrix tension [0/90]₄ₛ 2 · 90° 27 70.2 −0.3 matrix tension [45/0/−45/90]₂ₛ 1 · +45° 712 89.8 −59.1 matrix tension [0]₈[90]₈ 1 · 0° 1268 56.6 −7.0 matrix tension Failure index in every ply. The heavy box marks the critical ply. The linear solution misplaces the unsymmetric stack's critical ply at ply 16; the nonlinear solution puts it at ply 1. Up through the laminate one ply at a time at the design load: transverse stress, top, and failure index in that ply, bottom. Both colour scales are fixed for every ply and every layup. MARGINS Three criteria, one ranking, one survivor. The criteria agree on the order and on the mode, and differ only in magnitude. The largest gap is for [0]₁₆ : maximum stress gives a margin of +1.34, Tsai-Wu +0.87, because Tsai-Wu accounts for 614 MPa of fibre tension and 21 MPa of transverse tension acting in the same ply. Quoting the least favourable criterion in every case changes no verdict. The quasi-isotropic stack is the worst performer, not the safe one. It has the lowest bending stiffness, and it puts a +45° ply on the most strained surface, where that ply picks up transverse tension and 59 MPa of in-plane shear against an allowable of 70. Layup FI · Tsai-Wu MS · max stress MS · Tsai-Hill MS · Tsai-Wu First-ply failure · kPa At 20 kPa [0]₁₆ 0.40 +1.34 +0.70 +0.87 38.2 pass [0/90]₄ₛ 1.50 −0.29 −0.29 −0.28 14.2 fail [45/0/−45/90]₂ₛ 2.53 −0.44 −0.51 −0.49 10.1 fail [0]₈[90]₈ 1.37 −0.12 −0.29 −0.19 15.3 fail Left: margin of safety at 0.02 MPa by criterion. The diamonds are an independent check, the margin implied by the solved nonlinear ramp rather than by scaling one solution. Right: the cure residual stress, discussed below. SOLVED, NOT SCALED The failure pressure, read off the solution. Once the plate deflects, stress grows more slowly than pressure, so a failure pressure cannot honestly be found by scaling one solution. Each layup was re-run with the pressure ramped past its own failure point, and first-ply failure read where the solved failure index crosses 1. Left: maximum failure index against applied pressure; first-ply failure is where each curve crosses FI = 1. Right: load against deflection, visibly stiffening as the plate takes membrane load. The failed region spreading from the bolted edge as the ramp runs. Each panel shows its nearest solved increment and labels the pressure it was solved at; nothing is interpolated. The colour scale is fixed at 0 to 3 and saturates. [0]₁₆ reaches first-ply failure at 38.2 kPa, 1.91× the design pressure. The unsymmetric stack fails at 15.3 kPa, the cross-ply at 14.2 and the quasi-isotropic stack at 10.1, half the design load and 3.8× lower than [0]₁₆ . As margins, the ramp gives +0.91, −0.23, −0.29 and −0.49, each within 0.05 of the margin from scaling the single design-load solution. The response is distinctly nonlinear, but the scaled strength ratio holds up here, and now that is checked rather than assumed. CURE RESIDUAL STRESS Most of the budget is spent before any load arrives. A laminate is stress-free at its cure temperature, not at room temperature. On cooling, a ply contracts across its fibres by 28 × 10⁻⁶ per kelvin and barely moves along them, so a 0° ply and a 90° ply bonded together fight each other. The 160 K cool-down from cure leaves every ply of the cross-ply and quasi-isotropic stacks with 40.6 MPa of transverse tension away from the edge. That is 81% of Yₜ, consumed by the layup itself. Superpose the cure state on the pressure case and no layup passes. [0]₁₆ carries almost no ply-to-ply residual stress in the far field, but at the bolted edge the restraint gives it its own, and it reaches a failure index of 2.16. The cool-down also disqualifies the unsymmetric stack outright: with no load at all it bows 11.1 mm out of plane from its extension–bending coupling, while the symmetric stacks stay flat to 0.01 mm. Cool-down from 453 K to 293 K with no pressure, on one fixed colour scale. The three symmetric stacks only shrink in plane; the unsymmetric stack bows into a saddle. Layup Warpage · mm FI · pressure FI · cure FI · both MS · both [0]₁₆ 0.01 0.41 1.68 2.16 −0.39 [0/90]₄ₛ 0.01 1.54 0.87 2.80 −0.55 [45/0/−45/90]₂ₛ 0.01 2.38 1.00 3.50 −0.61 [0]₈[90]₈ 11.12 1.79 1.07 2.82 −0.54 VERIFICATION A peak on a constraint is a question, not an answer. Every critical point sits exactly on the bolted edge, which always raises the question of a constraint singularity. Over a 3× in-plane refinement the critical failure index moves by 1.0% at most and tip deflection by under 0.3%. The peak is a converged, physical stress, not an artefact of the mesh. Layup FI · 2,048 el. FI · 8,192 el. FI · 18,432 el. Spread [0]₁₆ 0.406 0.404 0.404 0.6% [0/90]₄ₛ 1.540 1.541 1.541 0.1% [45/0/−45/90]₂ₛ 2.385 2.398 2.409 1.0% [0]₈[90]₈ 1.790 1.788 1.784 0.3% Critical failure index against element size. Right: the same with the first element row excluded, which is the place to look if the real joint is compliant. Ply-level stress in a rotated material frame is easy to get silently wrong, so the extraction chain was checked as well. At every node the stress rotated into ply axes was compared with the ply stiffness acting on the strain rotated the same way. The worst relative error over all four linear models is 4 × 10⁻⁶, which confirms the frame, the ply-angle mapping and the sense of the rotation in one test. Statics closes too. Integrating bending stress over the bolted section recovers 99.9% of the 40,000 N·mm root moment the load requires, for every layup. RECOMMENDATION [0]₁₆ wins the study. It should not be the part. [0]₁₆ is best on every measure here: stiffest, lowest failure index, highest failure pressure, no twist and no warpage. But it wins only because the load is pure bending in one direction. A pure unidirectional laminate has no shear capability and no damage tolerance across the fibres. A 0°-dominated stack with some off-axis plies, such as [0/0/0/45/0/−45/0/90]ₛ, keeps most of the bending stiffness and buys those back. The larger finding is that the plate is under-designed for this pressure whatever the order. Bending stress goes as one over thickness squared, so reaching a failure index of 1 needs about 2.4 mm for the cross-ply and 2.8 mm for the quasi-isotropic stack before cure stress or any factor of safety. And even the best stack deflects 42 mm, 21% of its span. A stiffness requirement will size this part before strength does. The right next step is to set that requirement and a joint model, then size thickness and layup together. LIMITATIONS Stated rather than buried. The strength allowables are assumed: standard published values for this class of ply, not coupon data. Every margin scales with them, and Yₜ = 50 MPa alone decides the outcome. No knockdowns and no factor of safety. Under a 1.5 factor and a 0.8 hot/wet knockdown, the winning layup falls just short as well. The bolted edge is idealised as fully built-in. Every critical point lands on it, so the joint model is the largest single uncertainty in the strength result. First-ply failure only. No progressive damage and no delamination check, although interlaminar stress reaches 17 to 114 MPa at the bolted edge in the nonlinear runs. Cure and pressure are combined by linear superposition. A combined nonlinear case was not run. BRING US THE DECISION Before the layup is frozen. If a stack is being chosen on habit, or a margin rests on a laminate-level number nobody has taken down to the ply, send us the geometry, the loads and the candidate layups. Whichever ply fails first, and why, is cheaper to find before the tooling is cut. TALK TO AN ENGINEER CalculiX 2.23, run through Prism's solver daemon in a containerised runtime: 20 solves, 86 s of solver time in total. 16 × 8 S8R composite shells, expanded by CalculiX to 2,048 C3D20R ply bricks and 16,304 nodes; root edge fixed in all six degrees of freedom. Linear static and geometrically nonlinear in 7 to 13 increments, a nonlinear ramp past first-ply failure, and a mesh study to 48 × 24. Ply stress rotated to material axes per node, with the material rotation removed by polar decomposition in the nonlinear runs. Tsai-Wu with F₁₂ = −0.5√(F₁₁F₂₂). Ply stiffness as supplied; strength allowables assumed. Basis: a representative plate, not a named client.

# Navier AI Blog — Agent-Driven Engineering, CFD, and Simulation
URL: https://www.navier.ai/blog

Prism Engagements Pricing Company Contact Blog NOTES FROM THE WORK PRESS RELEASE AUG 18, 2026 Navier AI Awarded AFWERX Phase I SBIR to Build a Geometry Reasoning Layer for Engineering Agents Navier AI has been awarded a Phase I SBIR from AFWERX to explore an ontology-based geometry embedding layer that gives AI agents the ability to reason about parts, features, and spatial relationships instead of guessing. READ MORE TECHNICAL ONERA M6 Transonic Validation The standard transonic benchmark, run against 270 of the 271 published pressure taps. The double-shock structure comes out right and merges where the experiment puts it — and decomposing our own drag killed our first explanation for the part that did not. AUG 4, 2026 TECHNICAL From Prompt to Flight Software: Building a Missile Evasion Simulation with Stella Stella, our agentic GNC platform, eliminates the path from scenario concept to working simulation code. Describe the engagement. Stella generates the simulation, flight software, guidance laws, autopilots, and runs SIL with up to a 50x speedup over traditional tooling. MAR 22, 2026 TECHNICAL Data to Decisions in Minutes: How Navier's Post-Processing Agent Transforms Simulation Analysis The gap between 'simulation complete' and 'actionable insight' is shockingly slow. Navier's Post-Processing Agent closes that gap, compressing hours of manual work into minutes. MAR 3, 2026 INSIGHTS Silent Bugs, Lost Missions: Why GNC Flight Software Is Moving to Rust The history of spaceflight is full of hundred-million dollar lessons in what happens when flight software hits edge cases. Rust eliminates entire classes of bugs that end missions. FEB 25, 2026 TECHNICAL Engineering Without Boundaries: Building a Unified Engineering Platform from Physics to Flight Explore how Navier AI's Agent-driven platform unifies CFD, GNC, FEA, and flight software into a single continuous workflow. FEB 12, 2026 TECHNICAL Introducing Agent-Driven Engineering: The Future of Hardware Design Discover how Agent-Driven Engineering is transforming hardware design workflows, enabling engineers to focus on innovation while AI agents handle repetitive tasks. JAN 15, 2025 PRESS RELEASE Navier Raises $5.6M to Deploy Agent-Driven Engineering, the Next Engineering Unlock After CAD and Simulation Navier announces $5.6 million in seed funding and its launch from stealth, bringing autonomous engineering teams to hardware design and development. DEC 15, 2024 Let's build together. Talk to an engineer → Navier AI · San Francisco Prism Engagements Pricing Company Docs X LinkedIn Contact Blog Terms Privacy Careers Log in Status Security Cookies © 2026 Navier AI Corp.

# About Navier AI — Engineers building tools for engineers
URL: https://www.navier.ai/company

Prism Engagements Pricing Company Contact Our vision Give every engineer a team of autonomous engineers. Software got its AI moment, but hardware is still built by hand. Every physical product goes through the same manual loop of design, simulation and validation. We're building autonomous engineers that run the loop themselves, from design intent to validated, buildable hardware. Our team Built by engineers, for engineers. We've built rockets, aircraft and vehicles, and the software that runs them. Now we build the tools we wished we had. SpaceX Falcon 9 Founders Cameron Flannery CEO Built Starlink avionics at SpaceX and self-driving trucks at Aurora before leading vehicle engineering on hydrofoiling boats. Evan Kay COO Developed propulsion for SpaceX's Raptor 1 and 2 rocket engines and worked on metal additive manufacturing at General Atomics. Advisors James Crook Advisor Led aerodynamic development of the Tesla Roadster and was principal aerodynamicist for the Williams F1 team. Team experience Backed by Build the tools with us. We're always hiring engineers who want to work on simulation, agents, and the infrastructure underneath both. Email us → Let's build together. Talk to an engineer → Navier AI · San Francisco Prism Engagements Pricing Company Docs X LinkedIn Contact Blog Terms Privacy Careers Log in Status Security Cookies © 2026 Navier AI Corp.

# Contact Navier AI — Talk to an Engineer
URL: https://www.navier.ai/contact

Tell us what you're trying to answer. Describe the problem you want our engineers to take on, or the team you want Prism deployed with. An engineer replies with next steps or a proposed scope. Trouble loading? Open the form in a new tab

# Silent Bugs, Lost Missions: Why GNC Flight Software Is Moving to Rust | Navier AI
URL: https://www.navier.ai/blog/2026-02-25-Silent-Bugs-Lost-Missions

Prism Engagements Pricing Company Contact BACK TO BLOG INSIGHTS February 25, 2026 Silent Bugs, Lost Missions: Why GNC Flight Software Is Moving to Rust By Evan Guidance, Navigation, and Control (GNC) software has a uniquely unforgiving failure profile. There's no graceful degradation when your state estimator feeds corrupted quaternion data to the control law at 10 kilometers per second. There's no rollback when your thruster firing sequence overflows an integer during terminal descent. The software either works, or you lose the mission. This isn't hypothetical. The history of spaceflight has no shortage of hundred-million dollar lessons in what happens when flight software hits edge cases no reviewer thought to test. Historical Case Files Ariane 5 Flight 501 — June 4, 1996 Forty seconds after liftoff, the maiden flight of Europe's most powerful rocket ended in a fireball over French Guiana. The root cause: a 64-bit floating-point value representing horizontal velocity was cast to a 16-bit signed integer. The value overflowed. The SRI software had been inherited from Ariane 4, where horizontal velocity never exceeded the 16-bit range. Ariane 5's faster trajectory did. The overflow shut down the active SRI. The backup — running identical software — had already failed 72 milliseconds earlier for the same reason. With both inertial reference units offline, the flight computer fed raw diagnostic data to the nozzle actuators. The rocket veered 90 degrees off course and self-destructed. The cost was approximately $370 million in payload alone. Ariane 5 Flight 501 self-destructs 40 seconds after liftoff (ESA) Mars Polar Lander — December 3, 1999 NASA's Mars Polar Lander was designed to touch down near Mars' south pole. During descent, touchdown sensors on the landing legs generated spurious signals when the legs deployed. The software interpreted the vibrations as surface contact and shut down the descent engines at roughly 40 meters altitude. The lander hit Mars at about 50 miles per hour. No software requirement existed to filter false signals, and a wiring error during testing masked the flaw entirely. Mars Polar Lander (NASA) Beresheet — April 11, 2019 SpaceIL's Beresheet was attempting to become the first privately funded spacecraft to land on the Moon. During final lunar descent, a software command reset the inertial measurement unit, triggering a chain of errors in the main engine control logic. The engine shut down during braking. Beresheet impacted the lunar surface at over 3,000 km/h. The failure traced back to an unintended interaction between fault handling and engine restart sequences. Beresheet spacecraft during pre-flight prep (IAI) Notice what these have in common. None were algorithmic errors. Nobody got the orbital mechanics wrong or designed a flawed control law. They were mechanical software bugs: an unprotected type conversion, a missing input filter, an unhandled state transition. The kind that live in the seams between subsystems, survive code reviews, pass unit tests, and activate at the worst possible moment. The Bugs That End Missions These aren't the bugs your linter catches. They hide in the gap between what the language permits and what the physics demands. NaN propagation: A single NaN introduced anywhere in a Kalman filter propagates silently through every downstream computation. In C/C++, there's no compile-time guarantee you're checking for NaN at every interface boundary. In practice, you don't. The NaN reaches the control law, produces nonsensical thruster commands, and by the time telemetry reveals the problem (if it does at all) the vehicle is unrecoverable. Integer overflow and wraparound: Angle computations in GNC code frequently operate near wraparound boundaries (e.g. 0°/360°, ±180°, ±π). A single unchecked integer cast can invert a steering command. This is exactly what destroyed Ariane 5: a value that was perfectly safe on one vehicle exceeded the representable range on another, and the language made it trivially easy to ignore. Uninitialized or stale state: A sensor driver that misses an update cycle. A mode flag that isn't cleared on transition. In C, reading uninitialized memory is undefined behavior, meaning the compiler is free to generate code that works in testing and fails in flight. This has been directly implicated in mission anomalies. Data races in concurrent systems: Modern GNC architectures run sensor acquisition, state estimation, control law execution, and health monitoring as concurrent tasks sharing state. A variable written by the estimator and read by the controller without synchronization produces control commands based on a physically impossible vehicle state. In C/C++, this is managed through developer discipline and code review. It's not enforced by the compiler. What Rust Changes Rust's value proposition for GNC isn't syntax preferences. It's about the compiler's default posture toward the exact categories of bugs that end missions. Click to enlarge The point isn't making it harder to write bugs. It's making entire classes of bugs unrepresentable. The compiler rejects programs that contain data races, use-after-free, or uninitialized reads. Not with warnings. With hard errors. Consider Ariane 5. In Rust, that 64-bit to 16-bit conversion requires an explicit checked conversion the compiler forces you to handle: Rust let bh_64: f64 = compute_horizontal_bias(velocity); // Checked conversion — compiler forces you to handle the overflow let bh_16: i16 = match i16::try_from(bh_64 as i64) { Ok(v) => v, Err(_) => { trigger_safe_mode(); return Err(GncError::SensorOverflow); } }; The silent, catastrophic overflow that destroyed a $370M rocket becomes a handled error case. For concurrency, Rust's ownership model makes data races a compile-time error. Share a mutable reference across threads without synchronization, and the program won't compile. You don't find the race condition during a 3 AM anomaly review. You find it when you build. Performance and Certification A common objection to Rust in safety-critical contexts is performance overhead. GNC software runs on deterministic real-time schedules. For example, a control law that misses its 100 Hz deadline is a failure mode regardless of correctness. Rust's safety guarantees sidestep this entirely because they're enforced at compile time, not runtime. The ownership model, borrow checker, and lifetime system don't exist in the generated binary. The resulting code is as fast as equivalent C, and often identical at the assembly level. There's no garbage collector, no runtime, no hidden allocation. Rust's no_std mode targets bare-metal embedded systems with full safety guarantees and a binary that starts at a few kilobytes. The other historical barrier has been certification. For GNC software to fly on any certified vehicle, the toolchain matters as much as the code. A compiler that hasn't been qualified under DO-178C, ISO 26262, or IEC 61508 is a non-starter. That barrier is falling fast. Ferrous Systems' Ferrocene compiler achieved TÜV SÜD qualification under ISO 26262 at ASIL D and IEC 61508 in 2023, becoming the first qualified Rust compiler for safety-critical development. By late 2025, Ferrocene achieved IEC 61508 SIL 2 certification for a subset of the Rust core library, and DO-178C aerospace qualification is actively in progress. For NewSpace companies building under launch-specific safety regimes or non-crewed vehicles, Rust is viable today. The Adoption Curve The embedded Rust ecosystem has reached an inflection point. N7 Space uses Rust in aerospace software components. Parallel Systems runs it on autonomous rail vehicles. Fusion Engineering uses it for drone flight controllers. Multiple satellite companies such as Gama Space use Rust for flight software. The policy signal from the U.S. government is equally clear. The NSA, CISA, and the White House have all issued guidance urging a shift to memory-safe languages, with the White House's 2024 report explicitly naming Rust. DARPA went further with its TRACTOR program, funding automated translation of legacy C codebases to Rust across DoD systems. For aerospace and defense firms, this isn't background noise, but a critical procurement signal. Companies building flight software, embedded systems, or safety-critical code for defense programs should expect memory safety to become a contractual expectation, not a technical preference in the near future. NewSpace companies are already listing Rust as a desired or required skill for GNC and flight software roles. This is a practical response to the reality that the bugs Rust prevents are the bugs that cause launch failures, and that the organizations buying flight software are starting to demand the languages that prevent them. Stella: Rust Native from Simulation to Flight Software This is exactly why Stella, Navier's GNC agent, is designed for Rust natively. Most GNC teams that want to use Rust face a significant 0-to-1 barrier. Standing up a Rust-based GNC development environment from scratch — configuring toolchains, writing boilerplate for state estimation and control architectures, building simulation harnesses, setting up concurrent task structures — can take weeks before anyone writes a single guidance algorithm. Stella removes that barrier entirely. Engineers start with a fully configured simulation environment and have GNC models running in under an hour, not months. Inside Stella, those models don't stay confined to simulation. Control laws, autonomy behaviors, and maneuver logic developed in Stella's simulated environment compile directly into Rust-based flight software. No model-to-flight translation gap. What's simulated is what flies. The traditional handoff from MATLAB or Simulink to a C reimplementation is completely eliminated. Engineers iterate on guidance algorithms, estimator tuning, and fault management logic inside the simulation environment, and the flight code that comes out the other side inherits Rust's compile-time safety guarantees automatically. This results in a meaningful change in development velocity. No separate V&V cycle to hunt down memory bugs that a better toolchain would have prevented. No manual reimplementation where context degrades and assumptions drift. GNC teams should be spending their time on the actual hard problems, not hunting bugs that a better language and a better toolchain would have prevented. Stella exists to make that tradeoff unnecessary. Rust eliminates the bugs. Stella eliminates the barrier to using it. Ready to experience Agent-Driven GNC Engineering with Stella? Learn more about Navier's Stella platform or contact us to see how we can transform your GNC workflows. References Lions, J.L. et al. "ARIANE 5 Flight 501 Failure: Report by the Inquiry Board." European Space Agency, July 1996. sunnyday.mit.edu Mars Program Independent Assessment Team. "Summary Report." NASA, March 14, 2000. sunnyday.mit.edu Marsh, Jason. "'Could Not Have Survived': 20 Years Since NASA's Ill-Fated Mars Polar Lander." AmericaSpace, January 6, 2019. americaspace.com Davis, Jason. "Software Command to Fix Faulty Sensor Doomed Beresheet." The Planetary Society, April 17, 2019. planetary.org "What Happened to Beresheet?" Davidson Institute of Science Education, Weizmann Institute. davidson.org.il Ferrous Systems. "Officially Qualified." Ferrous Systems Blog, October 2023. ferrous-systems.com Ferrous Systems. "Ferrocene 25.11.0 Now Available." Ferrous Systems Blog, November 2025. ferrous-systems.com N7 Space. "Evaluation of Rust Usage in Space Applications." n7space.com Parallel Systems. "RustConf 2022 — All Aboard the Rust (Electric Freight) Train!" LinkedIn, September 2022. linkedin.com Fusion Engineering. "Introduction to Rust and Its Benefits." Fusion Engineering Blog, August 2022. fusion.engineering Tech.eu. "Aiming to Harness Solar Photons to Accelerate Satellite Propulsion, Paris-based Gama Prepares New Year's Ride on SpaceX Payload." Tech.eu, January 2023. tech.eu BACK TO BLOG Let's build together. Talk to an engineer → Navier AI · San Francisco Prism Engagements Pricing Company Docs X LinkedIn Contact Blog Terms Privacy Careers Log in Status Security Cookies © 2026 Navier AI Corp.

# Navier Raises $5.6M to Deploy Agent-Driven Engineering, the Next Engineering Unlock After CAD and Simulation | Navier AI
URL: https://www.navier.ai/blog/2024-12-15-navier-raises-5-6m-seed-funding

Prism Engagements Pricing Company Contact BACK TO BLOG PRESS RELEASE December 15, 2024 Navier Raises $5.6M to Deploy Agent-Driven Engineering, the Next Engineering Unlock After CAD and Simulation By Navier SAN FRANCISCO, CA, December 15, 2025 - Navier, which builds autonomous engineering teams for hardware design and development, today announced $5.6 million in seed funding and its launch from stealth. The round includes participation from GV (Google Ventures), HCVC, and Y Combinator. Engineering has undergone two major productivity shifts: Computer-Aided Design (CAD) replaced manual drafting in the 1960s, then simulation software enabled virtual testing in the 1990s. Each shift reduced overhead requirements while expanding what engineers and designers could accomplish. Navier introduces the third shift: Agent-Driven Engineering (ADE), in which AI agents automate repetitive workflows between design and engineering disciplines, which still consume a significant portion of an engineer's time. "In the same way design and engineering projects used to require as many as a hundred draftspeople before the advent of CAD, our agents empower nimble teams to automate repetitive tasks, scale processes, and dramatically shorten project timelines. Instead of spending hours setting up a simulation case, we can do that in a couple of minutes, meaning teams can focus on doing what they do best: innovating, building, and solving hard problems." — Cameron Flannery, Founder and CEO of Navier Navier's ADE enhances existing CAD and simulation tools, enabling teams to maintain their current workflows while gaining automated cross-disciplinary translation. Previously, companies had to piece together a patchwork of vendors for software licenses, compute management, and other tools while manually coordinating the various systems. This complexity was furthered by the need to translate terms and processes within engineering or design disciplines. Navier empowers teams of any size to triple their output by developing repeatable workflows and improving the scalability of smaller teams. By consolidating the entire stack into a single platform that combines AI agents, compute infrastructure, and seamless tool integration, Navier's AI agents reduce the engineering gap that leads to costly delays. Additionally, the reduced friction enables teams to explore higher-order use cases and capabilities, pushing the boundaries of what was previously possible. Built on proven autonomous vehicle technology from SpaceX, Tesla, and Aurora experts, Navier's agents leverage computer vision and spatial reasoning to interpret 3D geometry and automatically align design concepts with engineering validation needs. Further, Navier's ADE platform enables continuous validation through parallel testing and automated reporting, allowing teams to catch design-engineering misalignments. "As a former semiconductor design engineer for 12 years and an ex-founder, I have experienced some deep pain in simulation speeds and the often unexplainable gap to the actual performance. When I met Navier, it instantly clicked for me. The teams we're backing are solving collaboration problems that cost hardware companies millions in delays and failed iterations. When design and engineering teams can work together in real-time with AI handling the translation between disciplines, you compress development cycles from months to weeks, with much fewer unpleasant surprises. That changes the economics of hardware companies completely." — Jerry Yang, General Partner at HCVC The funding will support platform development and expansion across aerospace and automotive companies, where ADE represents the next performance increase after CAD and simulation. About Navier Navier is a startup building autonomous engineering teams for hardware design and development. Its Agent-Driven Engineering (ADE) streamlines engineering workflows by eliminating time spent on mundane tasks through the application of proven autonomous vehicle technology. By democratizing engineering capabilities, the platform enables teams of any size to leverage advanced tools, multiplying their impact. Teams can now achieve in days what previously took large engineering departments weeks to develop. Learn more at navier.ai BACK TO BLOG Let's build together. Talk to an engineer → Navier AI · San Francisco Prism Engagements Pricing Company Docs X LinkedIn Contact Blog Terms Privacy Careers Log in Status Security Cookies © 2026 Navier AI Corp.

# Introducing Agent-Driven Engineering: The Future of Hardware Design | Navier AI
URL: https://www.navier.ai/blog/2025-01-15-introducing-agent-driven-engineering

Prism Engagements Pricing Company Contact BACK TO BLOG TECHNICAL January 15, 2025 Introducing Agent-Driven Engineering: The Future of Hardware Design By Cameron Every physical product — from drones to spacecraft — advances too slowly. Not because engineers aren’t fast, but because they’re waiting: for simulations, data, and hardware. The world can’t afford that anymore. At Navier AI, our mission is to build autonomous hardware engineers — AI agents that help humanity build faster. We started by trying to teach AI physics. It worked — sort of. Then we realized the hard part isn’t the physics. It’s the engineering. Here’s what we learned, and what drove us to build AI engineering agents 👇 The Physics ML Era We started Navier AI in late 2023 with a simple idea: make engineering move faster. Our first plan was straightforward — use Physics ML to speed up fluid dynamics simulations with “physics-foundation” models. Before explaining why that didn’t work, it’s worth clarifying what people mean by Physics ML. There are two dominant approaches: data-driven models and equation-driven models (PINNs). Data-Driven In the data-driven world, you generate large amounts of high-fidelity training data — usually from traditional solvers — and train a model on top of it. Neural Operators fall into this category, and this is where we saw the most success. The model itself isn’t the hardest part. The data is. Do you already have it? Do you need to generate it? Do you know the design space in advance? Do you trust the labels? These questions quickly become the bottleneck. PINNs On the other side are equation-driven approaches — Physics-Informed Neural Networks (PINNs). Instead of relying on large datasets, you bake the governing equations directly into the training loss. Elegant in theory. Brutal in practice. The moment you move beyond toy problems like 1D Burgers’ equations and into full Navier–Stokes systems, GPU memory usage explodes. Each additional term in the loss compounds the computational cost. What looks clean on paper becomes a training nightmare in reality. So for about a year, we went deep — experimenting, building, and benchmarking. We made real progress. Our models outperformed much of what we saw in the research literature. On the surface, this was exciting. We had built an ML model that could predict results on new geometries 100,000× faster than traditional CFD. We didn’t just make it fast — we eliminated meshing entirely. Give us a geometry, we quantize it and push it straight through the model. For a moment, this felt like the breakthrough. The Real Bottleneck Any aerospace engineer will tell you: simulations that are 10,000× faster , meshless, and accurate feel revolutionary. At first, we thought that was the answer. But here’s the catch: these models aren’t truly general. You can’t throw arbitrary geometries at them and expect high-quality results. Each meaningful use case requires its own carefully defined design space — along with the data generation, validation, and retraining that comes with it. If you have to run thousands of expensive simulations just to train the Physics ML model… …doesn’t that defeat the purpose? As we started taking our Physics ML approach to market, this became unavoidable. It was a powerful tool — but only in narrow, high-value optimization problems where the upfront cost could be justified. For the vast majority of engineering work, Physics ML is the wrong abstraction. It takes longer to get meaningful results, costs more to deploy, and is harder to trust. That realization forced us to zoom out. If our goal was to accelerate hardware engineering, maybe the bottleneck wasn’t physics modeling at all. Maybe it was the human loop around it. Engineering Autonomy That’s when we turned to AI agents. They weren’t part of the original plan. At first, we imagined something lightweight — maybe a chatbot to help with documentation or setup questions. But as we listened more closely to engineers, their frustrations sounded different. When someone said, “I can never run as many simulations as I want,” we used to hear a need for faster solvers. Now we heard something else: A need for automation. Click to enlarge Our agent works across the full simulation pipeline Demo We watched as our agent set up and ran 40 CFD simulations overnight — and woke up to a clean Cl–Cd curve waiting for us. Normally, this is days of tedious setup, solver babysitting, and second-guessing convergence. I gave the agent a single prompt: Generate a Cl–Cd curve for this new fixed-wing drone design. Without any further input, it began planning a mesh-independence study, selecting mesh resolutions, launching a batch of simulations, checking convergence, aggregating results, and stitching together a performance curve. No scripts. No manual setup. No babysitting. Watching that loop unfold felt surreal — not like using software, but like onboarding a junior engineer who quietly did the work while we slept. Click to enlarge Agent-driven engineering workflow, showing a mesh configuration from a single prompt. That's when it clicked. The future of engineering wasn't faster simulations. It was engineers that could think and act. Teaching AI to Engineer Teaching AI to engineer means teaching it to understand the 3D world — geometry, physics, and context. LLMs can’t do that out of the box. They hallucinate geometry, misread meshes, and lose track of causality. So we’re building the vision, cognition, and action stacks from scratch — the same way autonomy teams did for self-driving cars. Our first product is an engineering copilot — a step toward autonomous engineers. Ask it to: run a mesh study run a batch of simulations push a CFD case to convergence It just handles it. Today, it’s helping our early partners run five times more design iterations per week . But this is just the beginning. If code copilots transformed how we build software, AfiI engineers will transform how we build everything else. The last era of progress scaled software. The next era will scale engineering by freeing engineers from the bottlenecks that slow them down. We’re building that future at Navier AI — and we’re looking for the engineers, partners, and dreamers who want to build it with us. Ready to experience Agent-Driven Engineering? Learn more about Navier's platform or contact us to see how ADE can transform your workflows. BACK TO BLOG Let's build together. Talk to an engineer → Navier AI · San Francisco Prism Engagements Pricing Company Docs X LinkedIn Contact Blog Terms Privacy Careers Log in Status Security Cookies © 2026 Navier AI Corp.

# Data to Decisions in Minutes: How Navier's Post-Processing Agent Transforms Simulation Analysis | Navier AI
URL: https://www.navier.ai/blog/2026-03-03-faster-speed-to-insights

Prism Engagements Pricing Company Contact BACK TO BLOG TECHNICAL March 3, 2026 Data to Decisions in Minutes: How Navier's Post-Processing Agent Transforms Simulation Analysis By Evan Engineering teams run simulations to inform decisions about geometries, operating conditions, and design tradeoffs. But the simulation itself is just a means to an end. What actually matters is the insight: the moment a decision-maker can look at the results and say, "here's what we're doing next." That gap between "simulation complete" and "actionable insight" is what we call speed to insight, and for most engineering teams, it's shockingly slow. Post-processing, visualization, comparison, interpretation, and report generation can take as long as the simulation itself, sometimes longer. And unlike solver runtime, which has benefited from faster hardware and better algorithms, post-processing has remained a stubbornly manual, human-bottlenecked process. Until now. To illustrate what we mean, we're going to walk through a classic case: a NACA 2412 alpha sweep. It's a bread-and-butter workflow that every aerodynamics engineer is familiar with, making it a perfect lens for showing just how much time gets burned between "results ready" and "report in hand." The Manual Workflow: Death by a Thousand Clicks If you've ever post-processed a multi-case sweep by hand, you understand the pain point. You open your visualization tool — ParaView, Tecplot, whatever your team uses — and you start clicking. Load the first case. Set up your contour plots. Adjust the color map. Position the camera. Export a screenshot. Now do it again for the next angle of attack. And the next. And the next. For a 10-case alpha sweep, you're repeating essentially the same sequence of clicks dozens of times, making sure you keep the visualization settings consistent across cases so the comparison is actually meaningful. Setting up velocity contour visualization for just one case in the angle-of-attack sweep. The same workflow must then be repeated for pressure contours and stream tracers, and again for every additional case. Then comes the quantitative analysis. You need the Cl vs. alpha curve, Cd vs. alpha curve, and drag polars. So you fire up Python and start scripting. Or, increasingly, you ask a coding agent to write the script for you. While LLM assisted coding might make this process faster, it is still prone to mistakes. The first output might forget to label the axes. Or it plots everything on the same scale when it shouldn't. Or it uses the wrong column from the data file. So you prompt again, correct, re-run, tweak, re-prompt. What felt like a shortcut turns into its own iteration loop. Click to enlarge Plotting script generated by Claude Code. Still required >20 minutes and multiple prompts. None of this is intellectually hard. That's what makes it so frustrating. You're not solving engineering problems. You're doing data janitorial work. And every hour spent on it is an hour not spent on the design decisions that actually move the project forward. Automated Scripting: Better, But Not Enough The natural response to this pain is automation. Write a Python pipeline that ingests your simulation outputs, generates standard plots, and spits out a PDF. This is a real investment of time and engineering resources, and it does pay off for repeatable workflows. But there are two fundamental limitations that scripting can't overcome. First, the setup cost is significant, and the result is brittle. Building a robust post-processing pipeline can take days of engineering time. And the moment something changes — a different mesh topology, a new output format, an additional variable to track — the pipeline breaks and someone has to fix it. These scripts are not generalizable. They're tuned to a specific simulation setup, and adapting them to a new class of problems often means starting from scratch. Second, and more importantly, scripts don't reason. A pipeline can generate a pressure contour, but it can't tell you that the separation bubble on the upper surface at 12° looks anomalous compared to the other cases in the sweep. It can't flag that the wake structure behind one geometry variant suggests an unexpected interaction. It can't recommend that you re-run a specific case with a finer mesh because the convergence behavior looks suspect. Scripts automate plotting, but they don't automate understanding. And understanding is the real value. Assembling the Deliverable Even after you've generated all your visualizations and plots, you're still not done. Now you have to turn those outputs into something a decision-maker can actually use. That means opening PowerPoint or Word and starting to manually put together a report. Screenshot the contour plot. Paste it in. Resize it. Screenshot the next one. Align them side by side so the comparison is visually clean. Repeat for every flow variable and case. Then do the same for your quantitative plots. And then comes the real time sink: writing the commentary. Every plot needs context. What is the reader looking at? What's significant about this result? How does case 7 compare to case 3, and why does it matter for the design decision at hand? This is skilled engineering writing, and it requires someone who understands the physics, understands the project objectives, and can connect the two in language that a program manager or chief engineer can act on. It's not something you can template your way out of, because every sweep tells a different story. For a multi-case alpha sweep, this report assembly process routinely takes hours. For larger trade studies or design reviews with multiple geometry variants, it can stretch into days. It's almost always the engineer who ran the simulations doing the assembly, because they're the one who understands the results well enough to narrate them. That means your most technically capable people are spending their time arranging screenshots in slide decks instead of doing engineering. Manually exporting simulation visuals, inserting them into PowerPoint, formatting each slide, and writing technical commentary for every case can consume hours or even days of valuable engineering time. Navier's Post-Processing Agent: From Data to Decisions in Minutes This is the problem we built the Navier Post-Processing Agent to solve. The Post-Processing Agent reads CFD and FEA simulation outputs, reasons about the physics, and produces engineering reports that a decision-maker can act on. It doesn't just programmatically plot data. It reasons about what it sees: identifying separation regions, comparing wake structures across geometries, flagging convergence issues, taking extra slices, and recommending next steps. The result is a dramatic compression of the time between "simulation complete" and "engineering decision made." What the Agent Actually Does On the platform capability side, the agent handles the full spectrum of post-processing deliverables. It takes simulation results from your existing simulation infrastructure and generates multi-case comparison reports, produces flow field images across your entire sweep, and outputs results in PowerPoint and PDF formats ready for stakeholder review. Report templates are fully customizable, and optional interactive reports allow users to gain deeper insights. But the capabilities that truly set the agent apart are on the analysis side. The agent performs physics-aware interpretation, meaning it doesn't just render a velocity field, it understands what the velocity field means for your design. It autonomously identifies flow features like separation zones, recirculation regions, and shock structures. It detects anomalies across case sweeps, catching the one result out of fifty that doesn't fit the pattern and flags it in the report. It evaluates convergence quality and mesh adequacy. And it generates actionable recommendations for what to investigate next. Most importantly, the agent operates orders of magnitude faster than traditional workflows. For a full angle-of-attack sweep of a NACA2412 airfoil, it completed the analysis, generated a comprehensive report, and correlated the results with experimental data — all in under 10 minutes . That means hours or even days of engineering effort reclaimed. It also means decisions can be made dramatically faster. Click to enlarge The Navier Post-Processing Agent at work (left) and its output — a full aerodynamic performance report generated in <10 mins (right). What Makes Our Agent Different Domain-native reasoning: The agent doesn't just plot data — it interprets physics. It knows what flow features mean, which results to trust, and what to investigate further. This is the knowledge layer that takes a junior engineer years to develop. With the Post-Processing Agent, that interpretive capability is available from the first case you run. Autonomous investigation: The agent finds things you didn't ask for. If it sees an anomaly in one case out of fifty, it pulls additional slices, cross-references with other geometries, and flags it in the report. No scripting tool does this, because no scripting tool has the capacity to decide on its own that something warrants a closer look. The agent operates more like an experienced colleague who notices something off and says, "hey, you should look at this." Fully customizable via natural language: Every aspect of the agent's output, including report structure, plot selections, comparison metrics, and naming conventions, can be configured through natural language instructions. No scripting. No config files. Your team retains full flexibility to adapt the agent to their workflow without engineering overhead. If you want a different comparison metric for next week's design review, you tell the agent in plain English and it adjusts. Why This Matters Engineering teams are under constant pressure to move faster. Even as simulation speed improves, the post-processing bottleneck remains. Manual workflows don't scale. Scripts help but don't reason. The gap between "results ready" and "decision made" is where projects stall. Navier's Post-Processing Agent closes that gap. It executes the full workflow, from visualization and comparison to interpretation and reporting, and compresses it from hours or days into minutes. More importantly, it delivers insight, not just images. It explains what the results mean, highlights anomalies, and suggests the next step. When work that once took hours or days is completed in minutes, two things happen. First, your best engineers reclaim meaningful time to focus on design and strategy rather than formatting slides. Second, decision cycles accelerate. The time between simulation and action shrinks, and that speed compounds over time, enabling dramatically faster development cycles. That's faster speed to insights. And it fundamentally changes how engineering teams work. Want to see the Post-Processing Agent in action on your own simulation data? Get in touch with our team to schedule a demo. BACK TO BLOG Let's build together. Talk to an engineer → Navier AI · San Francisco Prism Engagements Pricing Company Docs X LinkedIn Contact Blog Terms Privacy Careers Log in Status Security Cookies © 2026 Navier AI Corp.

# ONERA M6 Transonic Validation | Navier AI
URL: https://www.navier.ai/blog/2026-08-04-onera-m6-validation

Prism Engagements Pricing Company Contact BACK TO BLOG TECHNICAL August 4, 2026 ONERA M6 Transonic Validation By Evan The ONERA M6 wing has been the standard transonic validation case since 1979. At Mach 0.8395 and 3.06° incidence it develops a λ-shock on the upper surface: two separate compressions inboard that merge into a single shock toward the tip. Reproducing that structure — not just an integrated coefficient — is the actual test. A lift coefficient is one number, and one number can be right for the wrong reasons. A shock system is a shape. It has a position at every span station, a topology that changes across the span, and a place where that topology changes. You do not get those by accident. We ran the case as steady RANS with the Spalart–Allmaras model, using HiSA , a density-based solver built against OpenFOAM v2412. The flux scheme matters here: with AUSM+up and a van Leer limiter the compression stays inside about three cells instead of smearing across ten, and a smeared shock defeats the purpose of the benchmark. 12,962,287 cells. 3000 iterations. One overnight run. Lift drifted 0.011% over the final 500 iterations — flat to five significant figures. What is being compared to what AGARD AR-138 contains surface pressure distributions and nothing else. There is no experimental lift or drag for the ONERA M6; the report marks aerodynamic coefficients "not relevant," and ONERA state the database consists exclusively of pressure distributions. So this study has two halves, and they carry different weight: Surface Cp at the seven AGARD span stations is validation against experiment. 271 published taps, 270 of them comparable — one at η = 0.80 falls outside the CFD abscissa. Measured in a wind tunnel at Modane. CL, CD and CMy are code-to-code comparison. The reference is NASA's Turbulence Modeling Resource SA-neg multi-code study (AIAA 2018-1102) — five solutions from four codes, four of them at 61–363 million cells, at the converged end of a grid-refinement study. Both are useful. Only one is validation, and we label it that way everywhere. Surface pressure, station by station Click to enlarge All 270 taps, all seven stations. Circles are AGARD AR-138 run 2308; the line is this solution. η = y/b RMS ΔCp Max |ΔCp| Taps inside ±0.02 0.20 0.078 0.279 6 / 34 0.44 0.053 0.152 11 / 34 0.65 0.045 0.192 17 / 34 0.80 0.066 0.331 19 / 33 0.90 0.105 0.578 24 / 45 0.96 0.037 0.134 25 / 45 0.99 0.078 0.238 18 / 45 all 0.071 0.578 120 / 270 (44%) ±0.02 is the experiment's own quoted Cp accuracy. 187 of 270 taps fall inside ±0.04. 44% of the taps land inside the measurement's own uncertainty band, and 69% inside twice it. But the distribution of the error is the more useful result. The lower surface is essentially exact — RMS ΔCp of 0.012 to 0.045 across all stations, at or inside the experiment's own accuracy at four of the seven. It is attached, subsonic and shock-free, and there is nothing hard about it; that is exactly why it is worth checking. If the geometry, the far field, the incidence or the reference normalization were wrong, the lower surface would be wrong too. It is not. Click to enlarge Averaged over the seven stations, upper-surface RMS ΔCp is 3.0× the lower-surface value. Virtually all of the disagreement is on the upper surface, and virtually all of that is within one or two taps of a shock. A shock displaced by 0.03 chord produces a pointwise ΔCp of order the shock's own Cp jump while the rest of the profile lies on top of the data. That is precisely the pattern in the figure above — and it is why RMS ΔCp is 0.037 at η = 0.96 and 0.105 at η = 0.90, two stations 6% of semi-span apart. A modeling error would not be that localized. A shock-position error at a station where the shock is strong is. Click to enlarge η = 0.90, the worst station. The suction plateau ahead of the shock and the recovery behind it both track the data; the shock itself sits about 0.03 chord upstream. The λ Click to enlarge Shock position vs span. Two branches inboard, one outboard. Experimental bars are tap spacing, not measurement uncertainty. η Experiment, x/c This run, x/c Δ 0.20 0.575 0.619 +0.044c 0.44 0.122 / 0.528 0.118 / 0.537 −0.004c / +0.009c 0.65 0.176 / 0.473 0.195 / 0.461 +0.019c / −0.012c 0.80 0.223 / 0.372 0.274 / 0.358 +0.051c / −0.014c 0.90 0.278 (merged) 0.253 (merged) −0.025c 0.96 0.200 0.192 −0.008c 0.99 0.122 / 0.200 0.183 inside tap spacing Shock taken as the steepest upper-surface compression. Tap spacing near the shocks is 0.04–0.05c, so the experimental column carries roughly ±0.025c of its own. The double-shock structure is captured. Two distinct compressions exist at η = 0.44, 0.65 and 0.80 in both the experiment and the simulation, and both collapse to a single shock by η = 0.90. The merge therefore occurs between η = 0.80 and η = 0.90 in our solution — matching NASA's independent choice of η = 0.80 as the shock-intersection station, and ONERA's own description of "two shocks merging" for this run. At four of the seven stations the shock sits inside the experiment's tap spacing. Where it misses, it misses in a coherent direction: the forward branch is aft of measured inboard, and the merged shock is forward of measured outboard. Our λ is a little more swept than the measured one. That is one error with one shape, not seven independent ones. Getting shock topology right while getting shock position slightly wrong is a different and more encouraging class of result than matching an integrated number. Forces, against five other codes This run Reference band (5 codes) vs midpoint CL 0.26718 0.26932 – 0.27120 −1.14% CD 0.01755 0.01695 – 0.01705 +3.24% CD, pressure 0.012223 0.011654 – 0.011747 +4.5% CD, viscous 0.005327 0.005232 – 0.005309 +1.1% CMy −0.18770 −0.19187 – −0.18976 1.6% less nose-down Code-to-code against the NASA TMR SA-neg study (AIAA 2018-1102). Not validation — there is no experimental force data for the M6. Lift within 1.2% and drag within 3.3% of the band midpoint, on one grid, wall-modeled, with no tuning. The largest of those solutions ran 28× our cell count. The diagnosis we got wrong Our first explanation for the +3.2% drag was the obvious one. We ran wall functions at a mean y⁺ of 30, against wall-resolved reference computations. Under-resolved shock/boundary-layer interaction, therefore too much drag. The arithmetic even worked: viscous drag is about 0.0053 of a total 0.0170, so a 10% error in the viscous part alone is roughly +3% on CD — the size of the discrepancy observed. It was a good hypothesis. It was also testable, and the test killed it. Click to enlarge 93% of the drag excess is pressure drag. The wall-modeled skin friction sits within a third of a percent of the wall-resolved codes' own spread. Splitting the drag into pressure and viscous parts puts 93% of the excess in pressure drag . The wall-modeled skin friction lands 1.1% from the midpoint of five wall-resolved codes whose own spread is 1.5% — essentially inside their scatter. The wall-function hypothesis predicts an error in the component that is correct, and no error in the component that is wrong. That is a genuinely useful result in its own right, and it is the one we would carry to another case: a well-built wall-modeled mesh delivers wall-resolved skin friction on a swept transonic wing. Click to enlarge y⁺ over 139,141 wing faces: median 19.9, mean 30.3. In the shock band the maximum is 72.5 — the extremes are all at the leading edge. The pitching moment closes the argument. CMy comes out 1.6% less nose-down than the reference band. A shock sitting forward truncates the upper-surface suction earlier, moves the center of pressure forward, and reduces the nose-down moment. Low lift, high pressure drag, and a light nose-down moment are not three defects. They are one: the shock sits slightly too far forward. Three independent integrals point at one shock-position error rather than at three separate problems. That is what a diagnosis looks like when it is finished. A trap worth knowing OpenFOAM's forceCoeffs function object writes Cd(f) and Cd(r) columns. These are a front/rear split derived from the pitching moment, not a friction/pressure split. In our case they read 0.2227 and −0.2051, and they sum to the correct total. A careless reading survives a sanity check and yields an entirely fictitious "viscous drag" of 93% of the total. The pressure/viscous decomposition has to come from the forces function object, which writes total, pressure and viscous force vectors in newtons. The grid Click to enlarge Three cells through the compression — about 2% of local chord. Resolution shown against the feature it has to resolve. Cells 12,962,287 96.6% hexahedra, zero tets Non-orthogonality 4.74° average max 84.2°; 0.003% of faces above 70° Max skewness 2.85 checkMesh: Mesh OK Layer coverage 96.31% 20 target layers, 28 µm first cell Far field 37–56 chords dedicated box carrying the tip vortex Mesh quality. The maximum non-orthogonality looks alarming in isolation; the average across 39.8 million faces is the number that matters, and the schemes were set to match it. The fine shell carries 3.9 mm cells 100 mm off the surface, so the entire supersonic pocket — not just the wall — sits in the fine grid. That is what puts three cells through the shock instead of one. Layer addition on a 30° swept leading edge normally collapses. Running castellation and snapping with strict quality settings, then layer addition as a separate invocation with relaxed ones, took coverage from 57.6% to 96.31%. Raising the outer iteration count did most of the rest: 57.6% → 80.8% → 90.2% → 93.3%. The default of 3 iterations would have stopped near 90%. Three things we deliberately did not reuse This case built on prior in-house work — the official sharp-trailing-edge geometry and the two-stage meshing strategy. Three parts of the earlier setup did not survive contact with the transonic case: The AUSM+M flux scheme. Its shock sensor reads near zero on a smeared unstructured shock and switches off the very dissipation holding the shock together. The wSuperBee limiter. It overshoots at the 2:1 refinement jumps an octree mesh is full of; combined with unlimited Laplacians it diverged outright. An 18-chord domain. Marginal for transonic circulation. Ours is 37–56 chords. We also found, and re-derived, a force-coefficient error in the earlier run: dragDir and liftDir had been set in body axes, which at 3.06° reports axial force rather than drag. Rotating it into wind axes put the earlier result back in family with the reference. A coefficient that disagrees with a reference by a suspiciously round factor deserves a re-derivation before it is attributed to physics. What this establishes Click to enlarge Numerical schlieren across the span. Two shock branches at η = 0.44–0.80, one by η = 0.90. The double-shock structure is captured, and it merges in the right place — the feature ONERA themselves call "a challenging feature for transonic simulations." The lower surface matches to the experiment's own accuracy at four of seven stations, which is as good as the measurement can resolve. Skin friction lands 0.34% above the top of a wall-resolved band 1.5% wide at a mean wing y⁺ of 30. Lift is within 1.2% and drag within 3.3% of that same band, on one grid, with no tuning. The next runs are already scoped, and they are cheap: bracket the tunnel's 0.3° upwash by running both 3.06° and 3.36° on the existing mesh, and a three-grid convergence study at √2 spacing to put a number on the discretization error rather than an assumption. None of that is "validated lift and drag" on the M6. Nobody has that, because the measurement does not exist. What we have is a shock system in the right place, a skin friction within a third of a percent of a wall-resolved band, and every comparison labeled against a public reference anyone can pull. Simulation: OpenFOAM v2412 + HiSA, steady RANS (Spalart–Allmaras), M∞ = 0.8395, α = 3.06°, Re_MAC = 11.72×10⁶. Experimental reference: AGARD AR-138 (1979) run 2308, via NASA's machine-readable transcription, cross-checked value-by-value against the NPARC Alliance archive. Code-to-code reference: NASA Turbulence Modeling Resource, AIAA 2018-1102. The visual write-up of this case is at Case Studies — ONERA M6 . BACK TO BLOG Let's build together. Talk to an engineer → Navier AI · San Francisco Prism Engagements Pricing Company Docs X LinkedIn Contact Blog Terms Privacy Careers Log in Status Security Cookies © 2026 Navier AI Corp.

# From Prompt to Flight Software: Building a Missile Evasion Simulation with Stella | Navier AI
URL: https://www.navier.ai/blog/2026-03-22-prompt-to-flight-software-stella

Prism Engagements Pricing Company Contact BACK TO BLOG TECHNICAL March 22, 2026 From Prompt to Flight Software: Building a Missile Evasion Simulation with Stella By Evan Suppose you need to simulate an air-to-air engagement: a F-16 detects an incoming IR-guided missile and executes a high-G defensive break turn to defeat it. You know the scenario parameters and you need a full 6-DOF simulation that runs both vehicles simultaneously, computes miss distance at closest approach, and produces a verified result. Today, the path from scenario concept to working simulation code runs through hours or days of MATLAB prototyping, C++ translation, painful integration testing, and the quiet dread of discovering your engagement model doesn't quite match your flight dynamics. The result is that teams can't easily experiment with different evasion strategies, threat geometries, or countermeasure timelines, let alone explore the full trade space of what's survivable. Stella, our agentic GNC platform, eliminates those constraints. You describe the engagement. Stella generates the simulation, the flight software for both vehicles, the guidance laws, the autopilots, and runs Software-in-the-Loop before you've touched a compiler. The result is up to a 50x speedup over traditional tooling, letting you test dozens of engagement scenarios in the time it used to take to set up one. This post walks through how that actually works, end to end, for a missile evasion scenario. But first, a question that comes up constantly: why can't you just do this with Claude or ChatGPT? Why Base LLMs Fall Short Large language models can write code. They can explain flight dynamics. They can even produce something that looks like a 6-DOF engagement simulation if you prompt them carefully. But looking right and being right are very different things in flight mechanics, and the failure modes are subtle enough to be dangerous. Coordinate Transformations Flight dynamics work is fundamentally a coordinate transformation problem. You're constantly moving between Earth-centered inertial, body-fixed, wind, stability, and navigation frames. Every transformation has to be consistent, right-handed, and correctly sequenced. Base LLMs routinely botch this. They'll mix up the rotation order in a DCM. They'll confuse the direction of an NED-to-body transformation. They'll silently apply a quaternion convention that's inconsistent with the rest of the codebase. The output compiles. The aircraft banks the wrong way. The missile guides into the ground. This isn't a prompting problem you can engineer around. Frame transformations require global consistency across every module in the system. A base LLM generating code one function at a time has no mechanism to enforce that consistency. Rust /// Compute aerodynamic forces on the F-16 in body frame. /// Called at 100 Hz by the flight software loop. fn compute_aero_forces( v_ned: [f64; 3], // NED velocity from nav filter [m/s] attitude: [f64; 4], // quaternion [w, x, y, z] body-to-NED altitude: f64, // [m] ) -> [f64; 3] { let s_ref = 27.87; // F-16 wing area [m²] let cl_alpha = 3.44; // lift curve slope [/rad] let cd0 = 0.0175; // zero-lift drag let k = 0.12; // induced drag factor // Atmosphere (exponential model) let rho = 1.225 * (-altitude / 8500.0_f64).exp(); // Rotate NED velocity into body frame let v_body = quat_rotate(attitude, v_ned); let vt = (v_body[0]*v_body[0] + v_body[1]*v_body[1] + v_body[2]*v_body[2]).sqrt(); let alpha = (v_body[2] / v_body[0]).atan(); // angle of attack let qbar = 0.5 * rho * vt * vt; // Force coefficients let cl = cl_alpha * alpha; let cd = cd0 + k * cl * cl; // Forces in body frame let lift = qbar * s_ref * cl; let drag = qbar * s_ref * cd; [ -drag, // axial (body X, forward) 0.0, // side force (body Y) -lift, // normal (body Z, down) ] } Claude generated aero force model for a F-16 break turn. The quaternion convention is inverted and lift is resolved along the wrong axis. Physically Realistic Plant Models Ask a base LLM to build a vehicle dynamics model and you'll get something. It will have gravity. It might have drag. But the foundational physics that the entire simulation depends on, such as 6-DOF rigid body propagation or coupling between translational and rotational states, often either get omitted entirely or implemented with subtle errors that propagate silently through every downstream result. This is where base LLMs are most dangerous, because the math looks right at first glance. An LLM will write a quaternion integration step that doesn't renormalize. It will implement a gravity model that doesn't account for the vehicle's attitude when resolving force components. The simulation runs. The numbers come out. They're just not physically correct. Autonomous Iteration The deepest problem is that engagement simulation development is iterative. You don't write a guidance law, test it once, and ship it. You run Monte Carlo campaigns. You discover that the evasion maneuver timing is too late at certain launch ranges. You find that the missile's lateral acceleration saturates at 30 G but only needs 28 G to track through your break turn. You redesign, retest, and repeat. Base LLMs don't do this. They can't look at a Monte Carlo spread and decide that the 3-sigma miss distance falls inside the warhead lethal radius for 15% of cases and that the fix is to increase bank angle or add a barrel roll at closest approach. Every iteration requires a human in the loop reinterpreting results and re-prompting. The "autonomous" part of autonomous engineering doesn't exist. Walking Through a Missile Evasion Scenario with Stella Let's walk through how Stella actually builds a missile evasion simulation from a single prompt, and more importantly, what's happening under the hood at each stage. The Prompt We started with a natural-language scenario description. Here's what we asked Stella to do: Set up a simulation of a missile evasion scenario. We have a f16 evading a sidewinder-like missile with the goal of the f16 having GNC code to evade the missile. Both the missile and the f16 should have simulated flight software. Let's have the f16 do something like a defensive break turn. Alternatively, you can point Stella to a mission description in a .txt file. The agent takes it from there. The Foundation: StellaRust Everything Stella generates is built on top of StellaRust, a Rust-native numerical framework that our team wrote by hand. This is the critical distinction from what a base LLM does. The foundational flight dynamics math, such as 6-DOF propagation, state-space methods, integrators, coordinate transformations, aerodynamic models, actuator models, lives in a validated, human-authored library. It was deliberately not left to AI to write. This is the layer where the failure modes we described earlier would be fatal. Coordinate transformations, quaternion conventions, integrator numerics, frame definitions: these have to be correct once and reused everywhere. StellaRust provides that single source of truth. When the agent generates code for this missile evasion scenario, it isn't inventing a proportional navigation law from scratch or writing its own RK4 integrator. It's composing calls into a framework where those primitives have already been built and validated. The framework also provides a SIM harness architecture that separates flight software from simulation truth. On one side sits the actual flight code: the F-16's break-turn autopilot, the missile's PN guidance law. On the other side sit truth models for the environment, aerodynamics, and propulsion, with configurable fidelity. The flight software is navigating and controlling against sensor measurements that behave like real hardware, not feeding on its own truth state. Because it's all Rust, there's no translation step. The flight software code that runs inside the SIM harness is the same code that compiles to an embedded flight processor. We've already flashed embedded hardware to prove this path works end to end. Compare that to the traditional Simulink workflow: design in blocks, export to auto-generated C that nobody can read, then have your flight software team translate it into something maintainable. That translation is where many bugs live. Stella eliminates that step entirely. The Agent: From Prompt to Code The Navier GNC agent layer sits alongside the StellaRust source code in Prism, our desktop application. The UX is similar to a coding agent like Claude Code or Cursor, but with deep context about the flight dynamics domain and the full StellaRust API. When you submit a prompt, the agent doesn't just generate generic code. It reads your scenario parameters, decides which StellaRust modules to pull in, and writes the full simulation and flight software from scratch. For this missile evasion scenario, that means the agent has to make real engineering decisions. Running two vehicles simultaneously at different update rates (1 kHz physics, 100 Hz flight software) requires a carefully structured sim harness with synchronized time stepping. The F-16's autopilot needs a three-phase architecture: cruise at level flight with 40% thrust until threat detection, immediate hard right break at 80° bank with max angle of attack and 95% thrust for the evasion window, then wings-level extend to accelerate away. The aerodynamic force model uses a linear lift curve with a parabolic drag polar, exponential atmosphere, and a 9 G structural limit. On the threat side, the AIM-9's augmented proportional navigation needs two distinct flight phases: boost with thrust-vector control steered toward the PN guidance command, then terminal coast or partial thrust with aerodynamic fin steering. The missile's 30 G lateral acceleration limit is the parameter the evasion maneuver is designed to exploit, as the break turn's angular crossing rate is specifically chosen to force the seeker beyond this limit. The agent writes all of this as Rust code that calls into StellaRust. The guidance laws use the framework's propagation and steering tools. The autopilots use the framework's actuator models with proper aerodynamic geometry. Every module references the same coordinate frame definitions, the same quaternion conventions, and the same time system because they're all built on the same foundation. The Navier GNC agent generating the plan for a full missile evasion simulation from a single prompt inside Prism. The Iteration Loop: Where It Gets Interesting Here's what separates Stella from a coding agent that happens to know some flight mechanics. The agent doesn't generate code, hand it back, and wait for you to tell it what's wrong. It runs the simulation, analyzes the results, identifies problems, and fixes them autonomously. For a missile evasion scenario, the first version of the code is almost certainly not the final version. Maybe the F-16's autopilot can't achieve the commanded bank angle fast enough and the break turn initiates too slowly to generate sufficient crossing rate. Maybe the missile's PN gain is tuned too aggressively and the guidance oscillates in the terminal phase, artificially inflating miss distance. Maybe the aerodynamic model's lift curve saturates at high AoA and the aircraft can't sustain 7.5 G at the specified altitude and Mach number. In a traditional workflow, an engineer would run the sim, stare at the plots, diagnose the problem, and go fix it. Then do it again. And again. Stella's agent does this loop autonomously. It runs the simulation, parses the output, compares results against the scenario requirements in the prompt, traces violations to root causes, modifies the design, and re-runs. If the autopilot can't track the commanded bank angle, it can adjust gains or try different control methodologies. If the evasion geometry doesn't generate enough miss distance, it can modify the break timing or bank angle. Each iteration is done autonomously in minutes, not hours. The agent diagnosed the original F-16 model it generated had no aerodynamic forces. It then worked to correct the error until it verified that the break turn is physically accurate. What You Get When Stella finishes, the output is a complete Rust codebase: F-16 autopilot and missile guidance flight software running inside a full two-vehicle simulation environment. Not MATLAB prototypes. Not pseudocode. Not auto-generated C from a block diagram. Readable, maintainable Rust code with a clean architecture: src/ main.rs # Scenario setup, sim harness, results analysis, output vehicles.rs # Vehicle parameters (mass, inertia, thrust, initial states) f16_fsw.rs # F-16 flight software: aerodynamic force model + break-turn autopilot missile_fsw.rs # AIM-9 flight software: augmented proportional navigation guidance gen_charts.py # Post-processing: engagement geometry and telemetry charts The simulation runs both vehicles simultaneously at 1 kHz physics / 100 Hz flight software, computes miss distance at closest point of approach, and writes a bundle for 3D visualization. 3D visualization of the missile evasion engagement generated by Stella. The agent can also generate structured engineering documentation directly: engagement analysis reports, survivability assessments, and trade study summaries formatted as proper deliverables with title blocks, revision fields, and chapter organization. These take the agent minutes to compile versus the days an engineer typically spends assembling them by hand. Full algorithm description document generated by Stella, featuring visulizations and commentary. Why This Matters The missile evasion scenario above took just under 40 minutes to go from prompt to verified simulation. That speed changes what's possible. Run the evasion with a 7.5 G break turn. Then run it again at 5 G and find exactly where survivability degrades. Try initiating the break at 2.5 km threat range instead of 3 km and quantify the sensitivity. Swap the AIM-9 for a longer-range semi-active threat with different guidance dynamics and see whether the same evasion maneuver works. Increase the missile's lateral acceleration limit from 30 G to 40 G and find out where the break turn stops being effective. Add chaff or flare deployment at a specific time and model the seeker's response. Each of these is a full 6-DOF simulation with flight software, not a back-of-the-envelope estimate. This is how you find out that the 80° bank angle is actually the sweet spot, or that initiation timing matters more than G-loading for survivability, or that the evasion works against the AIM-9's 30 G limit but fails if the threat is upgraded to 35 G. You find it in simulation, in an afternoon, instead of discovering it in flight test six months from now. The translation gap matters too. The Rust code Stella generates in the SIM harness is the same code that compiles to an embedded flight processor. There's no Simulink-to-C export step, no manual reimplementation, no praying that the flight software matches the model. What is designed, tested, and reviewed is exactly what flies. But the real shift is what your engineering team spends their time on. Instead of hand-coding the same proportional navigation law for the tenth time or debugging a frame transformation that got flipped during reimplementation, they're evaluating engagement geometries, interrogating evasion trade studies, and making tactical decisions backed by simulation evidence. Stella handles the implementation. Your engineers do the engineering. Want to see Stella in action on your GNC use cases? Get in touch with our team to schedule a demo today. BACK TO BLOG Let's build together. Talk to an engineer → Navier AI · San Francisco Prism Engagements Pricing Company Docs X LinkedIn Contact Blog Terms Privacy Careers Log in Status Security Cookies © 2026 Navier AI Corp.

# Engineering Without Boundaries: Building a Unified Engineering Platform from Physics to Flight | Navier AI
URL: https://www.navier.ai/blog/2026-02-12-engineering-without-boundaries

Prism Engagements Pricing Company Contact BACK TO BLOG TECHNICAL February 12, 2026 Engineering Without Boundaries: Building a Unified Engineering Platform from Physics to Flight By Evan If you've worked on any advanced hardware program — aerospace, defense, automotive — you already know the problem. Your aero, GNC, and structures teams are all engineering the same vehicle, but they're doing it in completely separate environments with separate toolchains, separate data formats, and separate assumptions. They're solving deeply coupled problems in total isolation. That isolation has a cost. Every integration point becomes a manual translation exercise — re-deriving aerodynamic models for GNC, re-validating structural limits against updated loads, reconciling assumptions that drifted apart weeks ago. It's not just slow. It compounds risk, because engineering context degrades at every boundary. We started Navier AI to fix this. We're building a connected engineering environment where disciplines share context natively, accelerated by AI agents that handle the tedious work so engineers can focus on the actual engineering. Here's what that looks like in practice. The Next-Gen Hardware Simulation Stack 1. Mission Intent → Simulation Environment Most aerospace programs spend days, sometimes weeks, just standing up mission simulations. Defining orbital parameters, configuring environmental assumptions, validating propagation models, scripting maneuver logic. All before anyone evaluates feasibility. Stella, our GNC and mission simulation platform, compresses that dramatically. Engineers start with a few prompts or upload a mission requirements document and have a fully configured simulation running in under an hour. Stella auto-generates orbital and trajectory parameters, propagation timelines, maneuver scenarios, and constellation dynamics. Instead of building simulations from scratch, you start with an operational mission environment that evolves as vehicle and system designs change. Mission feasibility becomes the foundation for everything downstream. Walker Constellation Simulation Generated by Stella 2. Aerodynamic & Flow Physics Validation Once mission profiles are defined, vehicle performance needs to be validated aerodynamically. Traditionally this is slow and infrastructure-heavy. Geometry cleanup, mesh generation, boundary condition setup, solver validation. It can take days to stand up a single CFD run before you get any performance insight. Stokes, our aerodynamicist agent, handles simulation setup autonomously, allowing geometry and operating conditions to move directly into CFD analysis. Instead of spending time configuring solvers, teams focus on interpreting results, when design changes are still cheap to make. Click to enlarge Flow Visualization Generated by Stokes 3. Closed-Loop Mission Iteration This is where the integrated stack starts to pay off. CFD outputs from Stokes don't end up as static reports sitting in someone's folder. They become structured system data. Stokes runs automated parameter sweeps across flight regimes (altitude, velocity, angle of attack, control states) and generates full aerodynamic performance datasets. That data feeds directly back into Stella, where it informs mission and GNC simulation with real vehicle performance numbers. Mission design and aerodynamic performance evolve together, not sequentially. That's the closed loop. Click to enlarge Aero Database Generated By Stokes 4. Structural Analysis & Mechanism Sizing Once aero and mission requirements are validated, structural feasibility is the next constraint. This is where Ferro, our structural analysis platform and agent, comes in. Ferro takes aerodynamic loads and mission profiles as inputs and autonomously evaluates structural stresses, material selection, and payload supports. Subsystems get sized against real operating conditions from day one, not in isolation. This directly attacks one of the most expensive failure modes in aerospace: late-stage structural redesigns driven by loads that were poorly understood early on. Wing loading on an Onera M6 wing using Ferro 5. From GNC Models → Flight Software Designing a mission and validating vehicle performance is only half the equation. Aerospace systems have to actually execute these missions through flight software. Inside Stella, GNC models don't stay confined to simulation. Control laws, autonomy behaviors, and maneuver logic developed in Stella's simulated environment compile directly into Rust-based flight software. No model-to-flight translation gap. What's simulated is what flies. Click to enlarge Rust-Based Flight Code Generated by Stella 6. Integrated Product Convergence At this point, four traditionally siloed disciplines are operating inside one continuous loop: mission engineering, fluid dynamics, structural analysis, and flight software. Because each layer shares context, everything stays connected. Structural mass informs fuel requirements. Aerodynamic refinements adjust guidance strategies. Mission changes reshape load cases. Engineering becomes multidimensional design exploration instead of a linear handoff chain, and products converge faster because tradeoffs are evaluated continuously. Why This Matters When agents own the loop, engineering changes fundamentally. When you can iterate across disciplines in the same environment, you get faster development timelines, broader design space exploration, earlier risk identification, and lower integration overhead. In an industry where performance margins are thin and timelines are long, iteration speed is a strategic advantage. Click to enlarge Legacy vs. Navier Workflow This Is Just the Beginning Today, Navier AI's ecosystem enables closed-loop workflows across mission design and fluid simulation. Structural analysis is entering the stack next. On March 1st, we're launching the beta of Ferro, bringing structural analysis directly into the agent-driven engineering environment. This is just the start, with additional solvers and disciplines coming soon. Launching March 1, 2026 Get Early Access to Ferro Structural analysis is entering the agent-driven engineering stack. Be among the first to use it. Register for Early Access → BACK TO BLOG Let's build together. Talk to an engineer → Navier AI · San Francisco Prism Engagements Pricing Company Docs X LinkedIn Contact Blog Terms Privacy Careers Log in Status Security Cookies © 2026 Navier AI Corp.

# Navier AI Awarded AFWERX Phase I SBIR to Build a Geometry Reasoning Layer for Engineering Agents
URL: https://www.navier.ai/blog/2026-08-18-navier-awarded-afwerx-phase-1-sbir

Prism Engagements Pricing Company Contact BACK TO BLOG PRESS RELEASE August 18, 2026 Navier AI Awarded AFWERX Phase I SBIR to Build a Geometry Reasoning Layer for Engineering Agents By Navier AI SAN FRANCISCO, CA, August 18, 2026 - Navier AI, which is building the autonomous engineer for hardware design and development, today announced it has been awarded a Phase I Small Business Innovation Research (SBIR) contract from AFWERX, the innovation arm of the Department of the Air Force. The award funds the exploration of an ontology-based geometry embedding layer for agentic spatial reasoning. Foundational model AI agents have proven to be capable at code and language. However, they remain weak at 3D. Ask an agent to reason about a bracket, a manifold, or a control surface, and it has no reliable way to know what it is looking at: which face is a mating surface, which feature is a fastener hole, what is upstream of what, or which part carries the load. Today's models see triangles and coordinates, not engineering intent. Under this Phase I effort, Navier AI is building the layer that enables agents to do spatial reasoning. "Agents have uneven performance across engineering problems. They're great at code, which actually makes them great for a lot of engineering work, but 3D and spatial reasoning remain large gaps. We're exploring the development of an agent ontology for 3D and spatial reasoning so agents can do more meaningful work in 3D. We see this as a fundamental layer of the autonomous hardware engineer." — Cameron Flannery, Founder and CEO of Navier AI About Navier AI Navier AI is building the autonomous engineer for hardware design and development. Its Agent-Driven Engineering (ADE) platform combines AI agents and compute infrastructure so engineering teams can automate simulation and analysis workflows. Navier AI's agents run physics simulations across aerospace, defense, automotive, and industrials. Learn more at navier.ai About AFWERX AFWERX is the innovation arm of the Department of the Air Force and a directorate within the Air Force Research Laboratory. It manages the Department of the Air Force SBIR/STTR program, connecting small businesses and non-traditional partners with Air Force and Space Force needs to accelerate the delivery of new technology. The views expressed are those of the author and do not reflect the official guidance or position of the United States Government, the Department of Defense, or the United States Air Force. BACK TO BLOG Let's build together. Talk to an engineer → Navier AI · San Francisco Prism Engagements Pricing Company Docs X LinkedIn Contact Blog Terms Privacy Careers Log in Status Security Cookies © 2026 Navier AI Corp.