Why CFD is Stuck in the File Era

April 1, 2026

Computational Fluid Dynamics (CFD) workflows are stuck in the file era — results disconnected from their geometry, provenance tracked in spreadsheets, certification evidence scattered across email threads. At Flexcompute, we’re building Flexcompute Thread: artifact-native simulation where every result you would normally save to result.png becomes a traceable asset that knows where it came from, automatically.

The Problem Everyone Knows But Nobody Talks About

If you’ve worked in aerospace for more than six months, you’ve seen this folder:

|── results_v3_final.dat
|── results_v3_final_FINAL.dat
|── results_v3_final_FINAL_fixed.dat
|── results_v3_final_FINAL_fixed_newmesh.dat
|── results_to_IGES_mappingDONTCHANGEME (4).txt

You’ve also seen the Excel spreadsheet. The one that’s supposed to track which geometry version produced which results, who ran it, and what the reference conditions were. The one that “just gets painful to manage” (that’s an actual quote from one of our customers that spurred me to write this article.)

The canonical question in computational aerospace isn’t “how accurate is the solver?”.....it’s “which IGES does this .dat file belong to?”

In a previous life I was a police officer. The job taught me one thing: chain of custody is everything. Evidence without provenance is worthless — doesn’t matter how compelling it looks. Engineering data works the same way. A Cm value is just a number until you can prove where it came from.

The Standards Already Know This

Aerospace standards have been saying this for years. We’re just not listening.

NASA-STD-7009B (the standard for models and simulations, updated March 2024) puts it bluntly:

Flexcompute Thread — shown here — is the assembly line for simulation. The infrastructure that makes the solver useful, not just fast. (Image: Flexcompute)

“The primary purpose of this Standard is to reduce the risks associated with M&S (Modelling and Simulation)-influenced decisions by establishing a basic set of best practices applicable to any M&S and a generic, flexible M&S life-cycle process that includes several formal assessments to support the communication of M&S-based results credibility.”

In plain English: if you can’t prove where your simulation data came from, your decisions based on it are risky. And “credibility” isn’t just about solver accuracy — it’s about the entire chain from geometry to results.

The UK Ministry of Defense’s RA 5812 is even more explicit about what this means for certification:

“It is to be demonstrated that the M&S utilized in support of Airworthiness-related decision-making have been derived from a credible source and are appropriate for their intended use.”

You can see how a plot knows which geometry it came from, which CFD runs produced it - and as a consequence - all the solver settings accompanying those runs, the mesher settings, and all the geometry information. (Image: Flexcompute)

The nine required components? Data pedigree, verification and validation, uncertainty characterization, change management processes, and methods for analyzing results.

Everything that fragile Python scripts, Excel spreadsheets, and email threads conspicuously fail to provide.

The gap between what the standards require and what engineers actually have is enormous. And that gap is where certification risk lives.

Why CFD Vendors Don’t Solve This

Here’s the thing: CFD vendors sell solvers. That’s their business. They optimize for speed, accuracy, scalability — things they can benchmark and put in a press release.

Data provenance? That’s your problem.

“We gave you beautiful isocontours and Q-criterion renderings. What more do you want?”

I want to know which geometry produced which result. I want to understand what happens if I tweak the pylon — do I need to re-run everything, or just the affected cases? I want a response surface, not a single point on it. I want ∂CL/∂geometry, not another flythrough video.

But that’s not what CFD vendors are optimizing for. They optimize for the person who runs the simulation, not the person who uses the output. And those are often very different people.

Here’s a conversation I had repeatedly as an S&C engineer. An aerospace engineer would ask: “What control surface deflections should I run?” And my response was: “You tell me. If I knew where the aileron would stall, I wouldn’t need your database.” The whole point of the ADB is to discover those limits — but we’re asked to specify them upfront. It’s backwards.

The MLOps Analogy (and the Model T)

Machine learning (ML) figured this out years ago.

With Thread, this is how plots are related: one actually feeds into another, and certain data sets don’t feed into anything at all. (Image: Flexcompute)

In the early days of ML, data scientists had the same problem. “Which model was this? Which dataset did I train it on? What hyperparameters? Why is production different from my laptop?” They were drowning in files, notebooks, and tribal knowledge.

Then MLOps happened. Tools like MLflow, Weights & Biases, Neptune. The core insight: experiments are artifacts, and lineage is automatic. You don’t manually track which data produced which model — the system knows. Every experiment is connected to its inputs, its code, its parameters, its outputs. Reproducibility is built in, not bolted on.

Why hasn’t simulation caught up?

Partly because the CFD world is older and more conservative. Partly because the vendors have no incentive to solve this — they sell compute, not workflow. And partly because the problem is hard: it requires understanding both the physics domain and modern collaboration tooling.

To be fair, the big vendors have noticed the problem. They’ ll track your simulation files, manage versions, link your CAD BOM to your analysis BOM. For large organizations with dedicated PLM teams and six-figure budgets, they work for their intended purpose.

Flexcompute Thread has a multitude of geometry version control - including VSP, ESP, and whatever CAD you wish to import. (Image: Flexcompute)

But they’re fundamentally asset management systems — they track files and their relationships. They don’t treat derived outputs as first-class entities. Make a plot comparing CL across 50 runs? That plot doesn’t know where its data came from. Export data for a report? You’re back to dead data. The lineage stops at the simulation output; everything downstream is your problem again.

What’s needed isn’t better file management. It’s a different model entirely.

Artifact-Native Simulation

So here’s the idea — it’s simple once you see it.

Everything is an artifact. Geometry? Artifact. Mesh? Artifact. CFD run? Artifact. Plot? Artifact. Comparison between two configurations? Artifact (with two plots as parents).

Lineage is implicit. When you create a mesh, it knows which geometry it came from — automatically. When you run CFD, the results know which mesh, which solver settings, which boundary conditions. When you create a plot, it knows which results it’s aggregating.

Results can’t exist without their parent geometry. This is the key constraint. In a file-based world, you can have a results file with no connection to anything. In an artifact-native world, that’s structurally impossible.

All attributes in a provenance chain can be viewed and plotted against one another. So you can see how Dutch Roll Natural Frequency varies with sweep angle even though the sweep attribute belongs to the geometry, and a linearized model of multiple CFD results determined the Natural Frequency. But you can compare them in this framework because they’re all chained to the same geometry and all attributes are flattened into a queryable database.

It’s a bit like the shift from procedural to object-oriented programming. Before: data and functions floating around, connected by convention and programmer discipline. After: everything is an object with defined relationships, and the compiler enforces them.

The Boring Foundation

I’ll be honest: none of this is flashy.

Provenance tracking doesn’t make for exciting demos in the way that an isocontour sim does. “Look, every artifact knows its parent!” doesn’t get people out of their seats. But - the flashy stuff that this will enable is adaptive sampling, ML surrogates, automated ADB generation, adjoint-based optimization, and the list goes on.

You can’t build the flashy stuff without the boring foundation which joins data together from inputs to the things we actually care about. You need to be able to chain and propagate design inputs into solver outputs and make all these available to multiple models without having to remember where the “process_results.py” file lives.

Adaptive sampling needs to know what you’ve already run. Surrogates need provenance to be trustworthy. Adjoints require the geometry → results chain to be explicit. Every exciting feature downstream depends on this unsexy plumbing being in place.

So that’s what we’re building first. The artifact model. The lineage graph. The plot anything vs anything framework. The boring-but-necessary infrastructure that makes everything else possible.

We’re Building This — It’s Called Thread

Flexcompute already has the solver (Flow360 — genuinely fast, I don’t need to pitch it). What we’re adding is the workflow layer: artifact-native, lineage-tracked, collaborative.

We’re calling it Flexcompute Thread (for now) — the digital thread that connects everything. Geometry versioning with comments and diffs. Results that know where they came from. Plots that trace back through their entire lineage. Real-time collaboration (yes, Google Docs-style) so your team can work together instead of emailing files.

What This Unlocks

If you’re a systems-thinker, then you’ll hopefully be excited about the doors this opens up. Once you have artifact-native simulation, hard problems become tractable:

Incremental database updates. When geometry changes, the system knows which results are stale and which remain valid. You re-run the affected subset, not everything.

Sensitivity analysis as a query. If the geometry → mesh → CFD → results chain is explicit, you can differentiate through it.

Collaboration with context. Comments and conversations attach to specific artifacts, not floating in Slack. When you look at a result, you see who ran it, why, and what the team said about it. This matters because decisions live in conversations — the reasoning behind a design choice is as important as the choice itself.

Format-agnostic geometry ingestion. Bring your geometry in whatever form you have it. OpenVSP? STEP? IGES? Parasolid? Thread handles the conversion and tracks the lineage.

Certification-ready audit trails. When the DER asks where a number came from, you click “show lineage” and the answer is right there — timestamped, immutable, complete. NASA-STD-7009B compliance becomes a byproduct of normal work, not a separate documentation exercise.

Access for non-CFD engineers. The control engineer who needs hinge moments can query the database directly. If the data exists, they get it. If there’s a gap (in a plot of anything vs anything), they click it and queue a run and see the result in minutes.

Live plots, not dead PNGs. When you create a plot in Flexcompute Thread, it becomes an artifact — shareable, traceable, alive. You can still export to PNG if you really want to (old habits die hard), but you can also share the plot itself as a live web link. Your colleagues see it exactly as you intended: same data, same axes, same context. If they want to explore — zoom in, change the alpha range, toggle a data series — they can. Their changes are temporary; your plot stays intact. And if they discover something worth keeping, they save it as a new derived plot, with lineage back to yours. No more “which version of this chart is current?” — the chart is the version.

This article was written by Harry Smith, Director of Flight Sciences, Flexcompute (Boston, MA), it has been edited. For more information, visit here .