RB-05 · Can AI Automate Automotive
CFD Preprocessing?

The hard part is not running the solver.

CAD is not a CFD model.

What arrives at the CFD engineer’s desk can include a large number of parts, complete manufacturing detail, assembly gaps, bolts, clips and brackets, small holes and faces, chamfers and fillets, penetrations and overlaps between parts, structures that are not fluid-relevant, internal structure, topology problems inherited from different CAD systems, and naming conventions that vary across versions and departments.

What the CFD engineer actually needs is a model that has been re-interpreted for a specific physical problem. The typical route looks like this:

The most notable thing about this chain is a statement that sounds obvious and is still easy to forget:

CAD itself is not a CFD model.

A large engineering conversion process sits between the two. That process is the subject of this brief.

The real work is deciding what the CAD should become.

• Should this part be kept?
• Should this gap be filled?
• Does this hole matter to aerodynamics?
• Should this structure be its own PID, or merged with the geometry around it?
• Should this surface defect be repaired, or sent straight to the wrapper?
• This part is small — but will it affect the local flow?
• Does this internal structure matter for the current external-aero case?

Every one of these decisions eventually feeds the same chain:

Geometry → Mesh → Flow → CFD result

Which is why the genuinely interesting question is not:

Can AI edit CAD?

It is:

Can AI learn the engineering decisions that turn a manufacturing CAD model into a simulation model?

These are two different questions. Most of what follows is about keeping them apart.

Much of the automation is already here — and it is not AI.

Today’s commercial tools already ship mature automated capabilities. Simcenter STAR-CCM+, for example, includes a surface wrapper, automatic surface meshing, parts-based meshing, a Java API and simulation operations. STAR-CCM+ 2510 goes further with an enhanced MPI surface wrapper. In the Corvette and Maserati Ghibli cases Siemens describes, the wrapper handles tens of millions of surface triangles and hundreds of millions of volume cells, and compresses the wrapping time to minutes. It should be kept explicit that these are Siemens’ own product-performance tests, not a generic benchmark from an independent paper.

The practical conclusion follows:

“Auto-repair geometry, auto-wrap, auto-mesh” is not an AI research problem.

In many cases, conventional algorithms already do these things very well.

Commercial preprocessing is heading the same way.

The features BETA CAE officially describes include a natural-language interface, skill-based automation, Python script generation, an interactive knowledge assistant, context-aware task understanding, geometry healing, intelligent part type detection, persistent memory, AI-powered part type detection, and CFD task-based workflows.

The combination worth watching is the one BETA CAE itself puts at the center:

AI-powered part type detection + established geometric methods

In other words, the direction commercial software is taking is not simply “an LLM writes Python.” It is a combination of machine learning, geometric methods and the engineering workflow:

This gives an important signal about research value: a “ChatGPT controls ANSA” demo is no longer very interesting on its own, because that direction has already moved into commercial software. What is worth studying sits above it:

How does AI understand why a CFD engineer processes CAD the way they do?

The academic pieces are clearly accumulating.

1. Part classification
2. Part segmentation
3. Mesh-quality prediction
4. Defeaturing
5. Mesh generation
6. Geometry reconstruction
7. Reinforcement learning
8. LLM-based scripting

The survey also reaches a judgment worth keeping front of mind:

AI is better positioned as a complement to traditional geometry and meshing algorithms than as a replacement for them.

That reading lines up closely with how automotive CFD actually works.

B-Rep is becoming the important representation.

A B-Rep model carries a solid decomposed into faces, edges and vertices, where a face sits on a surface and is bounded by edges, and edges meet at vertices. Alongside the entities it carries topological adjacency — which face borders which edge, which edge borders which vertex.

Because of that structure, CAD can be turned into a graph G = (V, E), where V are the faces, edges and vertices, and E are their topological adjacencies. That is what lets graph-based models — GNNs, graph transformers — learn from CAD geometry and topology directly.

B-Rep feature recognition already works on controlled parts.

The study converts the B-Rep model into a graph and recognizes design features using face, edge, connection and parallelism information. On the mechanical CAD models they tested, the F1 score reached:

0.9924, 0.9982 and 1.0000

These are very good results. But they have to be read carefully. What they demonstrate is:

AI can learn geometry and topology semantics on controlled B-Rep feature-recognition problems.

What they do not demonstrate is:

AI can already understand an entire car.

The test objects are still specific mechanical design features on relatively controlled CAD models — a long way from a full vehicle.

Deciding what to remove predates generative AI.

Danglade, Pernot and Véron studied exactly this in “On the use of Machine Learning to Defeature CAD Models for Simulation.” Their idea was to learn rules from the defeaturing configurations engineers had already produced. The paper carries a core sentence that still reads as the heart of the problem:

Defeaturing depends strongly on the simulation context.

In other words, feature importance is not a property of geometry alone:

Feature importance ≠ geometry only

It is closer to:

Feature importance ≈ f(geometry, simulation context)

This is one of the most important ideas in today’s automotive CFD preprocessing discussion — and it has been on the table for over a decade.

Mesh quality can be predicted before the mesh exists.

Their work builds a learned mapping from B-Rep to local mesh quality. In its basic form it can be read as M = f(G), where G is the B-Rep geometry and M is the predicted mesh quality. The objective is deliberately framed around the workflow:

Predict which CAD features are likely to cause mesh-quality problems before the mesh is actually generated.

The prediction then feeds a small, well-defined decision set:

This is a valuable direction. The boundary still has to be stated: the validation objects are CAD parts and local geometric defects, not the complete OEM vehicle-scale CAD → CFD-ready vehicle loop.

Every piece is being built. The chain that connects them is not.

Connecting the links into one chain — OEM vehicle CAD through assembly understanding, part and PID semantics, CFD relevance, defeaturing decisions, geometry repair, surface preparation and meshing, to a validated CFD result — is where the public literature currently shows no clearly verified, reproducible vehicle-scale end-to-end AI success.

Most CAD-AI work faces a single part, not a vehicle.

Between the components sits more than geometry: geometry and topology, assembly, BOM, naming, function, and CFD relevance all interact. This is an entirely different scale from the single part.

A 0.8 mm gap means nothing until you know where it is.

Suppose the model finds a gap of 0.8 mm. That number is not enough to decide what to do, because the answer depends on where the gap lives and what case is being run.

A cooling opening is a case where an apparently small geometric feature has a first-order effect on the physics: the opening sets the cooling mass flow, $\dot{m}_{\mathrm{cooling}}$. For such a feature, REMOVE can be exactly the wrong decision.

The input has to carry the context, not just the shape.

• G — geometry and topology
• A — assembly information
• B — BOM / engineering metadata
• C — CFD context

The model then predicts an action, a = f(X), drawn from a small engineering vocabulary: KEEP, REMOVE, FILL, MERGE, SPLIT, REPAIR, WRAP or MANUAL. With that input the problem becomes an engineering question rather than a geometry-classification one.

What we lack is a dataset of decisions, not of results.

The answer is: very little. Public datasets today mostly concentrate on a different pipeline, CAD to CFD to a few aerodynamic numbers. DrivAerStar is a strong and important example of that shape.

DrivAerStar covers complete engine compartments, cooling systems and realistic internal airflow, and the authors also carried out wind-tunnel validation. It is valuable data. But what it mainly addresses is CAD → CFD, and CAD parameters → aerodynamic performance — not raw OEM CAD → engineering preprocessing decisions.

The valuable data is what engineers actually did to the CAD.

A record of that kind looks less like a simulation database and more like a log of engineering decisions. Two illustrative entries:

A third kind of record captures the semantic mapping a preprocessor needs:

What these records log is an engineering decision — the part, its role, its context, the action and the reason — rather than geometry alone. That is a different kind of data from a CFD result database.

The dangerous abstraction is AI talking directly to ANSA.

A more defensible shape inserts a decision and a validation layer between the model and the tool:

Concretely, AI should not emit arbitrary ANSA code. It should emit a structured action proposal that a policy validator and a geometry QA step can check before anything executes. An example proposal:

The proposal then flows through the action schema, the policy validator and the ANSA Python API. AI and ANSA stay decoupled: the model proposes, the engineering layer disposes.

A system shape worth actually building.

The defining property of this architecture is where AI sits. It does not touch the geometry directly. It produces decisions and proposals; the policy validator and the adapters do the execution; and the outcome returns to the dataset.

Not every step needs AI at all.

The conclusion follows from the table:

AI should not replace the whole pipeline.

It should enter precisely where deterministic rules are hard to describe and where a large body of historical engineering experience already exists — and the final approval stays with an engineer.

The LLM is the workflow orchestrator, not the geometry brain.

An engineer states a requirement in natural language:

“Do external aero — keep all surfaces that could affect the external flow, internal non-flow-related structures can be simplified, and cooling openings must not be closed.”

The LLM’s job is to turn that requirement into an analysis context and a policy:

and then into a structured policy the actual decision machinery can read:

That policy is handed to the ML and rule layers. So the division of labor is:

LLM ≠ geometry brain

More precisely:

LLM = workflow orchestrator

The interesting step is the feedback loop.

Suppose the model proposes REMOVE for feature X, and the CFD comparison returns:

If that is acceptable, then REMOVE becomes a recorded success case. Suppose instead the comparison returns:

Then the same REMOVE is a recorded failure case. At that point the model is no longer learning only “what engineers usually do.” It is learning:

Which treatment genuinely does not change the CFD result.

That is what CFD-aware AI would mean.

Accuracy and F1 are not enough to evaluate this.

The comparison should cover preparation time, how much human intervention remains, how many meshes fail, how many geometry defects survive, and the resulting mesh quality — and then the aerodynamic deltas $\Delta C_D$, $\Delta C_L$ and $\Delta C_p$ that say whether the treated model still represents the physics.

Attribute the gain correctly before celebrating it.

The tempting headline would be “AI reduced preprocessing time by 58%.” That claim would be sloppy. The defensible statement is:

Traditional automation produced the majority of the time reduction, while AI further reduced the amount of engineering intervention.

The 100 → 50 min step is what automation delivered. The 50 → 42 min step is what AI added. This is exactly why the research must evaluate automation and AI separately.

Foam-Agent automates the CFD workflow — a different problem.

The original 2025 Foam-Agent version targeted OpenFOAM workflows and reported an 83.6% success rate across 110 simulation tasks; a later version extended to the full workflow and reported 88.2%. The version published in 2026 adds multi-index retrieval, dependency-aware generation, a trajectory-conditioned reviewer loop, and workflow-stage agents.

That work demonstrates something real:

LLMs can begin to handle the orchestration problem of CFD workflows.

But it still is not the problem in this brief. Foam-Agent operates mainly on a CFD case that already exists:

The boundary matters: Foam-Agent’s 83.6% → 88.2% applies to the OpenFOAM boundary-condition and configuration domain — automated setup and execution of an existing case — not to OEM CAD-preprocessing decisions.

A maturity map, read from the bottom up.

The most important part of this table is not the star counts — it is the bottom two rows.

Geometry AI is not CFD engineering intelligence.

Existing work has demonstrated:

CAD → feature recognition

and:

CAD → mesh quality

and it has begun to explore:

Natural language → CFD workflow

What the field actually needs is the step that joins the engineering metadata to the decision:

CAD + BOM + assembly + CFD context → engineering decision

and then the run that validates it:

Engineering decision → ANSA → mesh → CFD

That chain remains very incomplete in public research today.

The successes are on clean models. Production is not clean.

Even where an automotive model appears, it tends to be:

The gap between the two columns is large. Because of it, there is not yet enough public evidence to support the claim that:

“AI can already reliably complete production-grade vehicle CFD preprocessing on its own.”

That conclusion cannot be drawn now.

The empty space is where the value is.

Research in this area is not:

“Take a solved problem and swap the model for GPT.”

It is:

“Find the space between mature automation technology and genuine engineering decisions.”

The division of labor falls out cleanly. Traditional automation answers the question of how to execute. AI answers the question of what to do. The engineer answers the question of whether the result is acceptable.

Together they form:

Automation + Prediction + Engineering Judgment

not:

AI replaces Engineer

Do not start with a whole vehicle.

Stage by stage, the first MVP solves a narrow but real problem: mapping a part to a CFD semantic. Only after that is trustworthy does the loop extend toward geometry risk, defeaturing recommendations, and finally execution and validation.

The most valuable output is the decision dataset.

Each engineer operation would record geometry, semantic, context, action, reason and outcome. A single entry might read:

What this does, in effect, is convert CFD engineer experience into machine-readable engineering knowledge. The model becomes a downstream consumer of that knowledge; the dataset is what makes it reusable.

The knowledge loop closes on itself.

Rules and ML models branch out of the same decision dataset, converge on a single decision engine, and the result of every CFD validation returns to the dataset again. It is a closed loop — the same shape of system that makes the learning cumulative rather than one-off.

Two sentences that look close and are not.

The two statements look close. They are in fact very different. The first sells a future. The second proposes a researchable question.

Four hypotheses worth testing.

The automation is mature. The decision layer is not.

The layer AI is genuinely entering sits above them:

What should I do?

rather than:

How do I execute this command?

Academia has already demonstrated the components: B-Rep can be used for machine learning; CAD features can be recognized; mesh quality can be predicted; defeaturing decisions can be supported; and LLMs can generate and orchestrate CFD workflows.

Between those results there is still a clear gap — especially around the step from a real OEM whole-vehicle CAD, combined with BOM, assembly, engineering semantics and an explicit CFD objective, to deciding automatically how the geometry should be treated and then verifying CFD fidelity. As of now, the public literature offers no sufficiently convincing, reproducible vehicle-scale end-to-end success case. The most recent survey itself lists data, benchmarks, geometry representation and trustworthy integration as the key challenges for continued progress in the field.

So the direction worth researching is not:

“Let AI operate ANSA.”

It is:

Let machines begin to understand why an engineer processes CAD the way they do.

That may be the step that actually moves the field from CAD automation toward CFD engineering intelligence.

Evidence Sources