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

Computational fluid dynamics has historically been one of the most expertise-intensive disciplines in engineering. A practitioner setting up an OpenFOAM simulation from scratch must understand: domain decomposition, mesh topology and refinement strategy, turbulence model selection and its mathematical basis, appropriate boundary condition types for each field variable, numerical scheme stability, SIMPLE algorithm under-relaxation, convergence diagnostics, and post-processing pipelines. Each of these steps carries its own failure modes and requires specialist knowledge to navigate. The result is a significant access barrier: CFD expertise takes years to develop and is expensive to deploy.

This study poses a direct challenge to that paradigm: can a Large Language Model act as a force-multiplier for a fluids engineer? Specifically, can an LLM — given the engineer's intent and access to shell tools — handle the entire implementation layer: setting up OpenFOAM dictionaries, running and debugging the mesher, monitoring convergence, designing the optimiser, and scripting the post-processor? This study used Claude Opus to answer that question; the approach is equally applicable with other frontier LLMs such as GLM or Kimi.

The answer, demonstrated here, is yes. The conversation began with a request to "simulate airflow over a bear at 60 m/s in Anchorage." What followed was a complete autonomous engineering workflow: the LLM chose the appropriate solver and turbulence model, computed inlet turbulence values from first principles, generated every configuration file, debugged meshing errors in real time, monitored solver convergence by parsing log files, designed and ran a parametric shape optimiser, wrote automated ParaView rendering scripts, and generated animated GIFs of the results.

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

What the LLM Did — Concretely

To make this tangible, here is the specific knowledge Claude Opus applied during the session, entirely unprompted:

• ▸Solver selection: Identified that 60 m/s at 15°C gives Ma ≈ 0.175, confirming incompressible flow is valid; chose incompressibleFluid with SIMPLE and k-ω SST for a high-Re bluff-body configuration.
• ▸Domain sizing: Applied the standard rule of 3–5 body lengths upstream and 10+ lengths downstream; sized the lateral extent to avoid blockage effects above 5%.
• ▸Turbulence inlet values: Computed k = 1.5·(U·I)² = 13.5 m²/s² and ω ≈ 50 s⁻¹ from a 5% turbulence intensity assumption and turbulent length scale L_t = 0.07·L_ref.
• ▸Mesh refinement strategy: Applied 5 levels of snappyHexMesh surface refinement (~30 mm near-body cells), distance-based volume refinement, and 3-layer boundary layers with ratio 1.3.
• ▸Real-time debugging: When snappyHexMesh failed with a missing meshQualityDict error, Claude located the system template and resolved it immediately. When parallel MPI runs crashed, Claude switched to serial execution and explained why.
• ▸Convergence monitoring: Parsed solver log files, extracted residual histories, recognised that oscillating Uy residuals in a bluff-body RANS are physically expected (not a solver failure), and stopped the run at appropriate convergence.
• ▸Parametric optimisation: Designed a C¹-continuous blend function targeting the ventral tummy region, identified the aerodynamic rationale (ground-effect separation, underbody horseshoe vortex), and implemented it in vectorised NumPy — 272,662 vertices processed in under 1 second.
• ▸ParaView automation: Wrote pvbatch Python scripts using the ParaView 5.11 API, debugged deprecated method calls (Position2, SeedType='Plane'), and generated 27 publication-quality renders across 3 camera angles and 3 timesteps for both cases.

Why a Bear? IP and ITAR — A Tertiary but Important Point

The bear as geometry is a deliberate but secondary choice. To demonstrate this methodology openly — publishing all files, results, and scripts — the geometry must be free of intellectual property restrictions and ITAR (International Traffic in Arms Regulations) controls. A real aerospace or defence geometry cannot be shared: its mesh files, pressure contour images, and drag coefficients may all constitute controlled "technical data" requiring export licences. Industrial geometries carry NDA obligations. The bear, generated freely from Meshy AI, carries none of these constraints. It is also geometrically complex enough to produce genuinely interesting turbulent flow physics, with a clear optimisation target in the ventral belly region.

The Aerodynamic Physics

The bear presents as a classic bluff body: drag is dominated by pressure, not friction. The rounded torso and protruding belly cause wide, early boundary layer separation; the resulting suction wake can run hundreds of Pascals below ambient pressure for many body lengths downstream. The ventral belly — sitting close to the ground and forcing underbody flow to accelerate then abruptly separate — is aerodynamically the most important surface for drag reduction, which is why Claude targeted it for parametric optimisation.

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 millimetres to metres 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 metres 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 optimiser and results. Teal = ParaView visualisation.

1. 1

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

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 optimiser — 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

   Optimised 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 optimiser 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-optimised (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 optimiser
# 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 simulation reveals a physically rich pressure field. On the windward face — chest, lower forelimbs — flow decelerates to near-stagnation, reaching approximately +700 m²/s² kinematic pressure (≈ 858 Pa above ambient). The flanks and underbelly show large suction zones where flow accelerates around the body then separates, producing a broad turbulent wake that extends 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 coloured 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. Optimised — Three Views

Fig. 5 Isometric, left = baseline / right = optimised. 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 optimised 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 optimised 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 — optimised (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 result deserves particular attention. The baseline exhibits C_l = +0.282 — a significant upward aerodynamic force from the belly acting as an asymmetric underbody surface in ground effect. The optimised belly, raised and compressed, eliminates this almost entirely (C_l = −0.046). In a real-world scenario, this matters for structural loading: the optimised bear is less prone to being lifted off the ground under extreme wind.

A New Engineering Paradigm — and What Comes Next

The central result of this study is not the 9.2% drag reduction — it is the demonstration that LLMs like Claude Opus, GLM, and Kimi can serve as a powerful force-multiplier for the fluids engineer. A domain expert directing the LLM through a natural-language conversation obtained a complete, publication-quality aerodynamics study: the engineer provided the physics framing, the problem definition, and the critical judgment on results; the LLM handled every configuration file, every debugging decision, every optimisation script, and every post-processing pipeline. The combination is more capable than either alone.

This has significant implications for how computational engineering is practiced. CFD has historically been gatekept by the steep learning curve of tools like OpenFOAM — thousands of configuration options, cryptic error messages, non-obvious meshing strategies, and years of experience needed to interpret results correctly. LLMs like Claude Opus, GLM, and Kimi can now act as the knowledge intermediary between a fluids engineer's question and those specialised tools. The engineer retains responsibility for the physics question and the engineering judgment; the LLM handles the implementation machinery.

The aerodynamic results themselves are physically meaningful. The 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 with expectations 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 that extreme weather imposes on wildlife.

Limitations

Several important caveats apply. The geometry is a static AI approximation — not a laser-scanned biological specimen. Surface details such as fur texture, limb position, and ear shape could meaningfully affect results. Steady-state RANS does not capture transient vortex shedding; a real bear in gusty wind experiences unsteady forces that LES or DES would resolve. The parametric optimiser here is a single open-loop design step — a gradient-based or evolutionary algorithm operating on more design variables would likely find larger gains.

Most importantly: no simulation, however carefully set up, replaces experimental validation. The drag coefficient, wake structure, and pressure distributions reported here are computational predictions subject to modelling assumptions — the choice of turbulence closure, wall treatment, mesh resolution, and domain size all introduce uncertainty. Before drawing engineering conclusions from any CFD study, results must be validated against physical measurements: wind tunnel force balances, surface pressure tappings, particle image velocimetry (PIV) for wake structure, or hot-wire anemometry for turbulence intensity. The k-ω SST model is known to overpredict separation in some bluff body configurations; an independent experimental dataset for a comparable geometry is needed to quantify this bias. In the absence of such data, the results presented here should be treated as physically plausible estimates, useful for comparative ranking of design variants, rather than as absolute ground truth.

Implications and Future Work

The most important direction is not extending the bear simulation — it is extending the LLM-CFD paradigm to more demanding engineering contexts. Near-term possibilities include: closing the loop between the LLM and a formal optimisation algorithm (treating each STL modification as one iteration of CMA-ES or Bayesian optimisation, with the LLM interpreting convergence and proposing next steps); extending to transient LES for time-accurate wake dynamics; and applying the same workflow to geometries in 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 modelling would account for fur, and multi-objective optimisation would simultaneously minimise drag and lift. Standing, running, and swimming poses present distinct aerodynamic problems worth studying. But these are extensions of the methodology demonstration, 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

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

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