Simulation surrogates (CFD/FEM acceleration)

A full CFD or FEM run can take hours to days on a cluster, so engineers evaluate only a handful of design variants. A neural surrogate, trained on a few hundred to thousands of solved simulations, predicts the result for a new geometry in seconds, enabling interactive design exploration, optimisation loops and real-time digital twins. The high-fidelity solver remains the reference for validation and sign-off.

Problem & value

• Today: simulation (ANSYS, Siemens Simcenter, Dassault SIMULIA, Altair, OpenFOAM, COMSOL) is a bottleneck: meshing, solving and post-processing take hours to days per variant, design space exploration is sparse, and results arrive late in the development cycle.
• AI value: once trained, inference takes seconds; thousands of variants can be screened, and gradient-based or Bayesian optimisation becomes practical. Surrogates also make simulation accessible to design engineers who are not solver specialists.
• Benefit figures: vendors report speed-ups of several orders of magnitude over the solver at inference time (e.g. in NVIDIA and Neural Concept material [1][3]); these exclude the one-off cost of generating training data and training, and depend on case and accuracy target. Treat them as vendor claims until reproduced on your own geometries.

Variants

• External aerodynamics (automotive, motorsport, aerospace, trucks): surface pressure and drag prediction on car-like shapes; public datasets such as DrivAerML and AhmedML exist [4].
• Structural / crash / thermal FEM: stress, deformation, battery and e-motor thermal fields.
• Turbomachinery, HVAC, data-centre cooling, process equipment: internal flows.
• Parametric reduced-order models (ROMs) and digital twins: low-dimensional surrogates embedded in controllers or operator dashboards.
• SMB: engineering service providers or suppliers with a CFD archive, typically buying a platform.
• Private use: none realistic beyond hobbyist or academic experiments.

How it works

1. CAD/parameters
2. design-of-experiments sampling
3. high-fidelity solver runs (CFD/FEM)
4. data pipeline (meshes, fields, normalisation)
5. surrogate training (neural operator / GNN / transformer / ROM)
6. validation on held-out designs + uncertainty / OOD check
7. deployment (API, CAD plug-in, optimisation loop)
8. active learning: add solver runs where the surrogate is uncertain

• Model families: Fourier Neural Operators and DeepONet (operator learning), mesh-based graph networks (MeshGraphNet), point/transformer models (e.g. Transolver, Universal Physics Transformers), and physics-informed networks (PINNs) which add PDE residual losses but are often harder to train than data-driven operators. Classical alternatives (POD-based ROMs, Gaussian processes) remain strong baselines for low-dimensional parameter spaces.
• Human-in-the-loop: engineers define the design space, review surrogate accuracy on held-out cases, and confirm shortlisted designs with the full solver before release. Certification or safety-relevant decisions are never based on the surrogate alone.

Data preparation

Data needed: solved CFD/FEM runs with their input geometries, boundary conditions and results. In an SMB these sit in solver result folders on engineering file shares, in PDM/PLM systems (CAD) and sometimes only on a workstation or cluster scratch disk.

Typical gaps: results deleted after reporting, inconsistent mesh topology and naming, missing parameter files, many solver or setup versions, and geometry families too diverse for one model. Access rights are often "whole engineering team".

Preparation steps: 1. Inventory existing runs and keep only comparable, converged cases (PREP-001, GUIDE-003). 2. Export geometry, parameters and fields into one format (e.g. VTK/HDF5) with a parameter table (PREP-005, PREP-011). 3. Define the validity envelope (parameter ranges) and hold out a test set with domain experts (PREP-018). 4. Generate additional runs by design of experiments where coverage is thin.

Tools: PyVista/ParaView, MLflow or DVC for versioning, vendor import tools.

Share of effort: about 40-60 percent, mostly curation and generating missing simulations.

Implementation paths

Which path for whom

• Enterprise: Path C, because simulation data and geometries are core IP, volumes of training runs are high and a shared internal GPU/HPC platform usually exists.
• Developer: Path C, because open frameworks (PhysicsNeMo, neuraloperator) give full control over architectures and data.
• SMB: Path A, because a vendor platform delivers a working surrogate from an existing solver archive without building an ML team.

Path A — Buy (recommended)

• Platforms: Neural Concept (Switzerland, EU-adjacent), PhysicsX (UK), Luminary Cloud (US), Emmi AI (Austria, EU), Altair physicsAI, Siemens Simcenter (AI-based surrogate features), Ansys SimAI (now part of Synopsys), NVIDIA Omniverse blueprints for CAE. Check: on-prem or EU-region hosting, ownership of trained models, solver integration, geometry import, uncertainty output.
• Choose A when: you have an archive of solved cases in a commercial solver and want results in months without building an ML team.

Path B — Build on cloud APIs

• Generate training data with your existing solver on cloud HPC (Azure HPC, AWS ParallelCluster, EU providers such as OVHcloud or national HPC centres via EuroHPC access calls), then train with managed ML services. General LLM APIs are not the core here; they help only as an engineering copilot (scripting solver set-ups, post-processing code) — see CODE family use cases.
• Choose B when: you lack GPUs but have in-house ML skills.

Path C — Self-host (open source)

• NVIDIA PhysicsNeMo (open-source framework with FNO, MeshGraphNet and others) [1], neuraloperator library, PyTorch Geometric, DeepXDE for PINNs [5], OpenFOAM or SU2 for data generation, PyVista/ParaView for post-processing, MLflow for experiment tracking.
• Hardware: HW3 (one 48–141 GB GPU) trains most single-geometry-class 3D surrogates; HW4 for large industrial meshes with tens of millions of cells.
• Ops effort: needs ML engineers plus CFD/FEM domain experts.

Path D — Custom training

This is the core of the topic: surrogates are trained on your data. Worth it when the same geometry family is simulated repeatedly (hundreds+ runs). Data needs range from a few hundred solved cases for narrow parametric families to thousands for diverse shapes. Foundation-style pre-trained physics models are emerging but domain-specific fine-tuning is still the norm.

State of the art (2026)

• Transformer and operator architectures for large 3D meshes (Transolver, Universal Physics Transformers and successors) now handle car-scale surface and volume data and are benchmarked on public sets such as DrivAerML [4]; ML-based CFD has moved from research into commercial platforms.
• Neural operators (FNO) learn mappings between function spaces and generalise across resolutions on regular domains [2].
• Physics-informed learning helps in data-scarce settings but does not remove the need for validation.
• Limits and failure modes: poor extrapolation outside the training design space (new topology, Reynolds number or boundary conditions), smoothing of sharp features such as shocks or separation, errors in integral quantities that matter most (drag within a few counts), expensive training-data generation, and mesh/geometry representation mismatches. Good practice is uncertainty estimation, OOD detection and a mandatory solver check for the final design.

Shared resources & combinations

• Shared stack (simulation + scientific-fm + 3d-vision): SCI-006 generative design and topology optimisation uses surrogates as fast evaluators in the loop; SCI-022 test-data analytics shares data pipelines; SCI-010 climate/earth-system emulators use the same neural-operator toolchain; SCI-024 CAD generation provides geometries; PRED-006 predictive maintenance and ROBO-010 digital twins consume reduced-order surrogates.
• Hardware: one HW3/HW4 GPU server is shared between training of different surrogates; solver licences and HPC capacity are the other shared resources.

Effort, cost & KPIs

• Path A: weeks to pilot, a few months to production; platform licences plus solver runs for training data.
• Path B/C: 6-12 months for a robust pipeline with a team of ML engineer(s) and CFD/FEM experts.
• Cost drivers: number and cost of training simulations, GPU training, domain-expert time for validation.
• KPIs: error on held-out designs (field L2 error, drag/stress error vs. solver), speed-up per evaluation, break-even number of variants, share of design decisions screened by surrogate, fraction of surrogate predictions flagged OOD, solver hours saved.

People & change

• Involve early: management (budget, scope), the department lead and simulation engineers as process owners, IT for GPU/HPC and storage, IT security for geometry and export-control data, data owners of the solver archives.
• Works council: depends. Simulation data is not personal, but platform accounts log user activity and BAG case law only requires objective suitability for monitoring, so §87(1) no. 6 BetrVG can apply; inform the council in good time under §90(1) no. 3 and see GUIDE-004. Public sector: Personalrat.
• Data protection: DPO involvement is light (no personal data beyond accounts), but sign an AVV (Art. 28 GDPR) with cloud platform vendors.
• AI literacy: under AI Act Art. 4 (since 27 Jul 2026) employer and provider must take measures to support staff AI literacy; plan a short training (see GUIDE-006).
• Pilot and communication: start with one product family and 2-3 sceptical but willing simulation engineers; position the surrogate as a screening tool, not a replacement (GUIDE-008, GUIDE-009).
• Typical concerns: fear that experts become redundant (address: solver stays reference), over-trust (mandatory OOD flag and solver confirmation before sign-off).
• Human control: engineers decide on design release; every surrogate result outside the validity envelope is re-run in the solver.

Risks, regulation & compliance

• EU AI Act: minimal risk for engineering analysis tools; Art. 4 AI literacy applies. If a surrogate becomes a safety component of a regulated product (e.g. machinery, medical device, aviation), sector rules and conformity assessment apply to the product, not to the tool as such. Not legal advice.
• GDPR: simulation data is normally non-personal; user accounts in platforms are the only personal data.
• Other regimes: export control for aerospace/defence geometry data and trade secrets (Directive (EU) 2016/943) — prefer EU or on-prem hosting; ITAR/EAR exposure with US cloud vendors. Aviation, rail and automotive type approval still require validated, traceable (solver- or test-based) evidence.
• Technical risks: silent extrapolation errors, model drift when geometry families change, over-trust by non-specialists. Mitigations: documented validity envelope, OOD flags, periodic re-validation against the solver, versioned training data.

Getting started

1. Pick one repeatable simulation task (same geometry family, same solver set-up) with at least a few hundred past runs, or budget runs.
2. Define the target quantities and the accuracy needed to make a decision (e.g. drag within X%).
3. Run a baseline (POD ROM or Gaussian process) first, then a neural operator/transformer (PhysicsNeMo or a vendor trial) on the same split.
4. Evaluate on held-out designs, including deliberately out-of-range ones; add uncertainty/OOD checks.
5. Embed in the design loop with mandatory solver confirmation, and track break-even versus solver cost.

Sources

1. NVIDIA PhysicsNeMo (open-source framework) — https://github.com/NVIDIA/physicsnemo
2. Li et al., "Fourier Neural Operator for Parametric PDEs" (ICLR 2021) — https://arxiv.org/abs/2010.08895
3. Neural Concept — platform documentation and product pages — https://www.neuralconcept.com
4. Ashton et al., "DrivAerML: High-Fidelity Computational Fluid Dynamics Dataset for Road-Car External Aerodynamics" — https://arxiv.org/abs/2408.11969
5. DeepXDE (physics-informed learning library) — https://github.com/lululxvi/deepxde
6. Wu et al., "Transolver: A Fast Transformer Solver for PDEs on General Geometries" — https://arxiv.org/abs/2402.02366
7. Alkin et al., "Universal Physics Transformers" — https://arxiv.org/abs/2402.12365
8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj