How LLMs Like Claude Opus Can Run a Complete CFD Study — From Prompt to Post-Processed Results

The LLM as CFD Engineer: A New Paradigm for Computational Simulation

CFD has always been one of the most expertise-intensive fields in engineering. Setting up an OpenFOAM simulation from scratch requires knowledge of domain decomposition, mesh topology, turbulence models, boundary conditions, numerical schemes, convergence diagnostics, and post-processing. Each step has its own failure modes. The barrier to entry is high — CFD expertise takes years to build.

This study asks: can an LLM act as a force-multiplier for a fluids engineer? Can it handle the entire implementation layer — OpenFOAM dictionaries, meshing, debugging, convergence monitoring, optimization, and post-processing — given just intent and shell access? We used Claude Opus; the approach works with GLM or Kimi too.

The answer is yes. The prompt was simply: "simulate airflow over a bear at 60 m/s in Anchorage." The LLM chose the solver, computed turbulence values from first principles, wrote every config file, debugged mesh errors, monitored convergence, designed a shape optimizer, wrote ParaView scripts, and generated animated GIFs.

"The user asked an engineering question in plain English. The LLM answered it with a working simulation, optimized geometry, and post-processed visualizations. This is the new interface for computational engineering."

What the LLM Did — Concretely

Here's what Claude handled unprompted:

• ▸Solver selection: Identified Ma ≈ 0.175 at 60 m/s, 15°C; chose incompressibleFluid with SIMPLE and k-ω SST.
• ▸Domain sizing: 3–5 body lengths upstream, 10+ downstream; lateral extent to avoid >5% blockage.
• ▸Turbulence inlet: Computed k = 13.5 m²/s², ω ≈ 50 s⁻¹ from 5% intensity and L_t = 0.07·L_ref.
• ▸Mesh refinement: 5 levels of snappyHexMesh (~30 mm near-body), volume refinement, 3 boundary layers at ratio 1.3.
• ▸Debugging: Fixed missing meshQualityDict by locating the system template. Switched to serial when MPI crashed.
• ▸Convergence: Parsed logs, extracted residuals, recognised oscillating Uy as physically expected in bluff-body RANS, stopped at appropriate convergence.
• ▸Optimization: Designed a C¹ blend for the ventral tummy, targeting ground-effect separation and underbody vortex. Vectorised NumPy: 272,662 vertices in <1 s.
• ▸ParaView automation: pvbatch scripts via ParaView 5.11 API, debugged deprecated calls, generated 27 renders across 3 angles and 3 timesteps for both cases.

Why a Bear? IP and ITAR

The bear is a deliberate choice. To publish all files, results, and scripts openly, the geometry must be free of IP restrictions and ITAR controls. Real aerospace or defence geometries cannot be shared — mesh files, pressure images, and drag coefficients may be controlled "technical data" requiring export licences. Industrial geometries carry NDAs. The bear, from Meshy AI, carries none of these. It's also complex enough to produce interesting turbulent flow, with a clear optimization target in the ventral belly.

The Aerodynamic Physics

The bear is a classic bluff body: drag is dominated by pressure, not friction. The rounded torso and protruding belly cause wide, early boundary layer separation. The suction wake runs hundreds of Pascals below ambient for many body lengths downstream. The ventral belly — close to the ground, forcing underbody flow to accelerate then abruptly separate — is the most important surface for drag reduction. That's why Claude targeted it for optimization.

The Subject: A 1,899 mm Seated Bear

The geometry was generated with Meshy AI using the reference photograph shown in Fig. 0 as the direct input to its image-to-3D pipeline. The output — a binary STL with 1,288,908 triangles — was scaled from millimeters to meters in Python. No manual geometry editing was performed.

Fig. 0 The original reference photograph uploaded to Meshy AI to generate the 3D STL geometry used in this study. A black bear (Ursus americanus) in a seated, upright resting pose — the same pose captured in the 1,899 mm tall STL model. The image was the direct input to Meshy AI's image-to-3D pipeline, which produced the 1,288,908-triangle binary STL scaled to meters for snappyHexMesh.

At 1,899 mm seated height, this matches a large adult Ursus arctos sitting upright — consistent with reported shoulder heights of 900–1,200 mm, which place the head well above 1.8 m in a sitting pose. The reference area used for C_d was A_ref = 1.85 m² (frontal projection), and the reference length was the bear's depth, L_ref = 1.404 m.

Fig. 1 Pressure contours on the bear surface at convergence (iteration 300). Red = high pressure (stagnation on the windward chest, ~+700 m²/s² kinematic). Blue = low pressure (suction on flanks and underbelly, down to −1,600 m²/s²). Wind flows left→right in the +X direction at 60 m/s.

What Claude Opus Actually Did — Step by Step

The flowchart below documents the complete pipeline as Claude executed it. Every configuration file, every solver call, every Python script, and every ParaView rendering instruction was generated by the LLM in response to natural-language requests. The user provided intent; Claude provided implementation.

Fig. 2 Complete pipeline. Purple = AI geometry input. Blue = Python data processing. Orange = mesh generation. Red = OpenFOAM CFD solver. Green = parametric optimizer and results. Teal = ParaView visualization.

1. 1

   Meshy AI → STL — Image-to-3D generation from the reference photograph (Fig. 0) produced a 1,288,908-triangle binary STL in millimeters.

2. 2

   Python pre-processing — struct + numpy parsed the binary header, extracted vertex coordinates, applied a ×0.001 scale, and rewrote normals from vertex cross-products.

3. 3

   Mesh generation — blockMesh built a coarse Cartesian background. snappyHexMesh carved the domain, applied five refinement levels on the bear surface (~30 mm cells), and added three boundary-layer rows.

4. 4

   Baseline CFD — potentialFoam seeded the velocity field. foamRun (SIMPLE, incompressibleFluid) advanced 350 iterations with k-ω SST. Force coefficients logged every 10 steps.

5. 5

   Parametric tummy optimizer — Python blend-function script modified 272,662 belly vertices: −20% lateral width, −15% fore-aft depth, +4 cm belly lift below waist height.

6. 6

   Optimized CFD — Modified STL re-meshed and re-solved under identical conditions. C_d compared against baseline.

7. 7

   ParaView pvbatch — Automated scripts rendered pressure contours, stream tracer tubes, wake slices, and animated GIFs at t = 100, 200, 300 iterations.

Domain, Mesh, and Solver Configuration

Anchorage Flow Conditions

Computational Domain

// Wind in +X; bear centred at origin on Z=0 ground plane
X = −5.0 m (inlet) to +15.0 m (outlet) // 3.6 L upstream, 10.7 L downstream
Y = −5.0 m to +5.0  m // ±3.6 L lateral
Z = 0.0 m (ground) to +8.0  m // 4.2 H height

Mesh Statistics

Taming the Tummy: Parametric Shape Modification

The ventral belly is aerodynamically the most problematic region of the bear geometry. It presents a large, rounded protrusion to the underbody flow, creates a horseshoe vortex at the ground junction, and drives early separation on the trailing curve of the rump. The optimizer targets only this zone using a smooth blend function — ensuring C¹ continuity, with no sharp ridges that would artificially trip the boundary layer.

Fig. 3 Geometry morph animation (loop). Orange = tummy modification zone (Z < 0.52 m). Ghost outlines show the original (blue) and fully-optimized (green) geometry simultaneously. Cross-sections at z = 0.10, 0.20, 0.30, 0.45 m reveal the progressive inward squeeze of the belly profile. Side and front silhouettes confirm the upper body remains unchanged.

Blend Function Implementation

# Python — parametric tummy optimizer
# Acts only below z = 0.522 m (lower 55% of body height)
# Strength = 1.0 at ground, 0.0 at waist — smooth transition

blend  = np.clip(1.0 - z / 0.522, 0, 1) # blend weight

x_new  = x - blend * (x - cx) * 0.20  # −20% lateral
y_new  = y - blend * (y - cy) * 0.15  # −15% depth

lift_blend = np.clip(1.0 - z / 0.15, 0, 0.8) # near-ground only
z_new  = z + lift_blend * 0.04  # +4 cm belly lift

Pressure, Flow Separation, and the Wake

Baseline: Flow Physics

The baseline shows a rich pressure field. On the windward face — chest, lower forelimbs — flow decelerates to near-stagnation, reaching +700 m²/s² kinematic pressure (≈ 858 Pa above ambient). The flanks and underbelly show large suction zones where flow accelerates then separates, producing a broad turbulent wake many body-lengths downstream.

Fig. 4 Baseline solution converging, t = 100 → 200 → 300. The stagnation zone (red, chest) sharpens and the wake deficit (blue, rear) deepens as SIMPLE drives residuals down. Streamline tubes are colored by pressure — red in the stagnation zone, transitioning to blue as they enter the separated wake.

"The wake behind the bear at 60 m/s contains pressure deficits exceeding 1,600 Pa below ambient — more than 70% of the dynamic pressure. That is the aerodynamic hole the bear punches through the airstream."

Baseline vs. Optimized — Three Views

Fig. 5 Isometric, left = baseline / right = optimized. The round belly (left) forces streamlines into a wide diversion, creating a large suction zone. The tightened underbelly (right) allows flow to follow the body surface further before separating — the blue suction region visibly shrinks.

Fig. 6 Wake cross-sections at x = 1.8 m and x = 4.0 m. The baseline wake (left) has a deeper, wider blue pressure deficit — more kinetic energy stripped from the flow. The optimized bear (right) shows a shallower, more circular deficit: earlier pressure recovery = less drag.

Fig. 7 Head-on view, looking directly upstream. The stagnation blob (red chest) is near-identical — same bluff frontal area. The key difference is in the underbelly: the optimized geometry shows reduced lateral suction spread because the belly no longer protrudes into the freestream.

Quantifying the Improvement

Fig. 8 Top: C_d convergence histories for both cases — optimized (green dashed) sits below baseline (blue) from iteration 50 onward. Bottom: mean C_d and drag force bars.

† Power = Drag Force × Velocity (2,663 N × 60 m/s ≈ 159.8 kW). This is the rate of aerodynamic energy dissipated by drag — a way to contextualise the 9.2% reduction in tangible terms, not an assertion that the bear is an engine.

The lift coefficient matters too. Baseline C_l = +0.282 — a significant upward force from the belly in ground effect. The optimized belly, raised and compressed, eliminates this (C_l = −0.046). In a real-world scenario, the optimized bear is less prone to being lifted off the ground under extreme wind.

A New Engineering Paradigm — and What Comes Next

The central result is not the 9.2% drag reduction — it's that LLMs like Claude Opus, GLM, and Kimi can be a powerful force-multiplier for the fluids engineer. A domain expert directing the LLM through natural language obtained a complete, publication-quality aerodynamics study. The engineer provided the physics framing and critical judgment; the LLM handled every config file, debugging decision, optimization script, and post-processing pipeline.

This changes how computational engineering is practiced. CFD has been gatekept by OpenFOAM's steep learning curve — thousands of config options, cryptic errors, and years of experience. LLMs now act as the knowledge intermediary between an engineer's question and specialized tools. The engineer retains physics and judgment; the LLM handles implementation.

The aerodynamic results are physically meaningful. Baseline C_d = 0.653 places the seated bear between a rough sphere (C_d ≈ 0.47) and a blunt cylinder (C_d ≈ 1.2) — consistent for a large, rounded bluff body at Re ≈ 5.7×10⁶. The 2,663 N drag force at 60 m/s is equivalent to roughly 272 kg, illustrating the structural loads extreme weather imposes on wildlife.

Limitations

Caveats apply. The geometry is a static AI approximation, not a laser-scanned specimen. Fur texture, limb position, and ear shape could affect results. Steady-state RANS doesn't capture transient vortex shedding; a real bear in gusty wind experiences unsteady forces that LES or DES would resolve. The parametric optimizer here is a single open-loop design step — gradient-based or evolutionary algorithms with more variables would likely find larger gains.

Most importantly: no simulation replaces experimental validation. The drag coefficient, wake structure, and pressure distributions are computational predictions subject to modeling assumptions — turbulence closure, wall treatment, mesh resolution, domain size all introduce uncertainty. Results must be validated against physical measurements: wind tunnel force balances, surface pressure tappings, PIV for wake structure, or hot-wire anemometry. The k-ω SST model is known to overpredict separation in some bluff body configurations. Without experimental data, treat these results as physically plausible estimates for comparative ranking, not absolute ground truth.

Implications and Future Work

The most important direction is extending the LLM-CFD paradigm to more demanding contexts. Near-term: closing the loop between LLM and formal optimization (CMA-ES or Bayesian, with LLM interpreting convergence and proposing next steps); extending to transient LES for time-accurate wake dynamics; applying the same workflow to structural mechanics, heat transfer, or acoustics. In each case, the LLM's role is the same: translate intent into working simulation files, interpret results, and iterate.

For the bear specifically, transient LES would capture vortex shedding, surface roughness modeling would account for fur, and multi-objective optimization would minimize drag and lift simultaneously. Standing, running, and swimming poses present distinct aerodynamic problems worth studying. But these are extensions of the methodology, not the demonstration itself.

Reproducibility & Key Code Fragments

OpenFOAM 13 (foamRun / incompressibleFluid solver)
Python 3.10 + numpy 2.3 + matplotlib 3.10 + Pillow 10
ParaView 5.11.2 (pvbatch headless rendering)
Hardware 4-core CPU, 7.5 GB RAM, Linux Mint (Ubuntu 22.04)

X (width, left–right): −566.1 → +564.1 span = 1,130.3 mm
Y (depth, front–back): −701.7 → +702.2 span = 1,404.0 mm
Z (height, ground–top): 0.0 → +1,899.4 span = 1,899.4 mm
Triangles: 1,288,908 (binary STL, Meshy AI)

forceCoeffs {
 type  forceCoeffs;
 patches  (bear);
 rho  rhoInf; rhoInf  1.225;
 liftDir  (0 0 1);
 dragDir  (1 0 0);
 magUInf  60;
 lRef  1.404; Aref  1.85;
}

# ── Baseline ──────────────────────────────────────────────
cd bear_baseline
blockMesh && snappyHexMesh -overwrite
renumberMesh -overwrite && potentialFoam
foamRun > log.foamRun

# ── Optimized ─────────────────────────────────────────────
python3 tummy_optimize.py # modifies STL, writes bear_optimized/
cd bear_optimized
blockMesh && snappyHexMesh -overwrite
renumberMesh -overwrite && potentialFoam
foamRun > log.foamRun

# ── Visualize ─────────────────────────────────────────────
DISPLAY=:0 pvbatch render_one_case.py baseline
DISPLAY=:0 pvbatch render_one_case.py optimized
python3 analyze_drag.py