Simulations-Surrogate (CFD-/FEM-Beschleunigung)

Ein vollständiger CFD- oder FEM-Lauf kann auf einem Cluster Stunden bis Tage dauern, sodass Ingenieure nur eine Handvoll Entwurfsvarianten bewerten. Ein neuronales Surrogat, trainiert mit einigen hundert bis tausenden gelösten Simulationen, sagt das Ergebnis für eine neue Geometrie in Sekunden voraus. Das ermöglicht interaktive Entwurfsvariation, Optimierungsschleifen und digitale Zwillinge in Echtzeit. Der hochgenaue Solver bleibt die Referenz für Validierung und Freigabe.

Problem & Nutzen

• Heute: Die Simulation (ANSYS, Siemens Simcenter, Dassault SIMULIA, Altair, OpenFOAM, COMSOL) ist ein Engpass: Vernetzen, Lösen und Nachbearbeiten dauern pro Variante Stunden bis Tage, der Entwurfsraum wird nur dünn abgetastet, und Ergebnisse liegen spät im Entwicklungszyklus vor.
• KI-Nutzen: Nach dem Training dauert die Inferenz Sekunden; tausende Varianten lassen sich vorab prüfen, und gradientenbasierte oder Bayes'sche Optimierung wird praktikabel. Surrogate machen die Simulation zudem für Konstrukteure zugänglich, die keine Solver-Spezialisten sind.
• Nutzenangaben: Anbieter berichten bei der Inferenz von Beschleunigungen um mehrere Größenordnungen gegenüber dem Solver (z. B. in Unterlagen von NVIDIA und Neural Concept [1][3]); darin sind die einmaligen Kosten für Trainingsdaten und Training nicht enthalten, und sie hängen vom Fall und der Genauigkeitsvorgabe ab. Behandeln Sie sie als Herstellerangaben, bis sie an Ihren eigenen Geometrien nachvollzogen wurden.

Varianten

• Äußere Aerodynamik (Automobil, Motorsport, Luftfahrt, Lkw): Vorhersage von Oberflächendruck und Widerstand an fahrzeugähnlichen Formen; es gibt öffentliche Datensätze wie DrivAerML und AhmedML [4].
• Strukturmechanik / Crash / thermische FEM: Spannung, Verformung, thermische Felder von Batterie und E-Motor.
• Turbomaschinen, Lüftung/Klima, Rechenzentrumskühlung, Prozessanlagen: Innenströmungen.
• Parametrische Modelle reduzierter Ordnung (ROMs) und digitale Zwillinge: niedrigdimensionale Surrogate, eingebettet in Regler oder Bediener-Dashboards.
• KMU: Engineering-Dienstleister oder Zulieferer mit einem CFD-Archiv, die in der Regel eine Plattform kaufen.
• Privatnutzung: keine realistische, außer Hobby- oder akademischen Experimenten.

So funktioniert es

1. CAD/Parameter
2. Stichproben per Versuchsplanung
3. hochgenaue Solver-Läufe (CFD/FEM)
4. Datenpipeline (Netze, Felder, Normalisierung)
5. Surrogat-Training (Neural Operator / GNN / Transformer / ROM)
6. Validierung an zurückgehaltenen Entwürfen + Unsicherheits-/OOD-Prüfung
7. Bereitstellung (API, CAD-Plug-in, Optimierungsschleife)
8. Active Learning: zusätzliche Solver-Läufe dort, wo das Surrogat unsicher ist

• Modellfamilien: Fourier Neural Operators und DeepONet (Operator Learning), netzbasierte Graph- Netze (MeshGraphNet), Punkt-/Transformer-Modelle (z. B. Transolver, Universal Physics Transformers) und physikinformierte Netze (PINNs), die Residuen der Differentialgleichung als Verlustterm ergänzen, aber oft schwerer zu trainieren sind als datengetriebene Operatoren. Klassische Alternativen (POD-basierte ROMs, Gauß- Prozesse) bleiben starke Vergleichsmodelle für niedrigdimensionale Parameterräume.
• Mensch-in-der-Schleife (Human-in-the-Loop): Ingenieure legen den Entwurfsraum fest, prüfen die Surrogatgenauigkeit an zurückgehaltenen Fällen und bestätigen in die engere Wahl genommene Entwürfe vor der Freigabe mit dem vollständigen Solver. Zertifizierungs- oder sicherheitsrelevante Entscheidungen beruhen nie allein auf dem Surrogat.

Datenaufbereitung

Benötigte Daten: gelöste CFD-/FEM-Läufe mit ihren Eingangsgeometrien, Randbedingungen und Ergebnissen. In einem KMU liegen sie in Solver-Ergebnisordnern auf Engineering-Dateiablagen, in PDM-/PLM-Systemen (CAD) und manchmal nur auf einer Workstation oder dem Scratch-Laufwerk eines Clusters.

Typische Lücken: nach dem Berichtswesen gelöschte Ergebnisse, uneinheitliche Netztopologie und Benennung, fehlende Parameterdateien, viele Solver- oder Setup-Versionen und Geometriefamilien, die für ein einzelnes Modell zu vielfältig sind. Zugriffsrechte lauten oft „gesamtes Engineering-Team“.

Aufbereitungsschritte: 1. Vorhandene Läufe inventarisieren und nur vergleichbare, konvergierte Fälle behalten (PREP-001, GUIDE-003). 2. Geometrie, Parameter und Felder in ein einheitliches Format (z. B. VTK/HDF5) mit einer Parametertabelle exportieren (PREP-005, PREP-011). 3. Den Gültigkeitsbereich (Parameterbereiche) festlegen und gemeinsam mit Fachleuten einen Testsatz zurückhalten (PREP-018). 4. Zusätzliche Läufe per Versuchsplanung erzeugen, wo die Abdeckung dünn ist.

Werkzeuge: PyVista/ParaView, MLflow oder DVC zur Versionierung, Import-Werkzeuge der Hersteller.

Aufwandsanteil: etwa 40-60 Prozent, überwiegend Aufbereitung und Erzeugung fehlender Simulationen.

Umsetzungswege

Welcher Weg für wen

• Enterprise: Weg C, weil Simulationsdaten und Geometrien zentrales geistiges Eigentum sind, die Zahl der Trainingsläufe hoch ist und meist eine gemeinsame interne GPU-/HPC-Plattform existiert.
• Developer: Weg C, weil offene Frameworks (PhysicsNeMo, neuraloperator) volle Kontrolle über Architekturen und Daten geben.
• KMU: Weg A, weil eine Herstellerplattform aus einem vorhandenen Solver-Archiv ein funktionierendes Surrogat liefert, ohne ein ML-Team aufzubauen.

Weg A — Kaufen (Standardsoftware, empfohlen)

• Plattformen: Neural Concept (Schweiz, EU-nah), PhysicsX (UK), Luminary Cloud (USA), Emmi AI (Österreich, EU), Altair physicsAI, Siemens Simcenter (KI-basierte Surrogat-Funktionen), Ansys SimAI (jetzt Teil von Synopsys), NVIDIA-Omniverse-Blueprints für CAE. Prüfen: On-Premises- oder EU-Region-Hosting, Eigentum an trainierten Modellen, Solver-Integration, Geometrieimport, Unsicherheitsausgabe.
• A wählen, wenn: Sie ein Archiv gelöster Fälle in einem kommerziellen Solver haben und Ergebnisse in Monaten wollen, ohne ein ML-Team aufzubauen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Trainingsdaten mit Ihrem vorhandenen Solver auf Cloud-HPC erzeugen (Azure HPC, AWS ParallelCluster, EU-Anbieter wie OVHcloud oder nationale HPC-Zentren über EuroHPC-Zugangsausschreibungen) und anschließend mit verwalteten ML-Diensten trainieren. Allgemeine LLM-APIs stehen hier nicht im Kern; sie helfen nur als Engineering- Copilot (Solver-Setups skripten, Nachbearbeitungscode) — siehe Anwendungsfälle der Familie CODE.
• B wählen, wenn: Ihnen GPUs fehlen, Sie aber über ML-Kompetenz im Haus verfügen.

Weg C — Selbst betreiben (Open Source)

• NVIDIA PhysicsNeMo (Open-Source-Framework mit FNO, MeshGraphNet und weiteren) [1], die neuraloperator- Bibliothek, PyTorch Geometric, DeepXDE für PINNs [5], OpenFOAM oder SU2 zur Datenerzeugung, PyVista/ParaView zur Nachbearbeitung, MLflow für das Experiment-Tracking.
• Hardware: HW3 (eine GPU mit 48–141 GB) trainiert die meisten 3D-Surrogate für eine einzelne Geometrieklasse; HW4 für große industrielle Netze mit zig Millionen Zellen.
• Betriebsaufwand: erfordert ML-Ingenieure sowie CFD-/FEM-Fachleute.

Weg D — Eigenes Training

Dies ist der Kern des Themas: Surrogate werden auf Ihren Daten trainiert. Lohnt sich, wenn dieselbe Geometriefamilie wiederholt simuliert wird (hunderte Läufe und mehr). Der Datenbedarf reicht von einigen hundert gelösten Fällen bei engen parametrischen Familien bis zu tausenden bei vielfältigen Formen. Vortrainierte Physikmodelle im Stil von Foundation Models entstehen gerade, doch domänenspezifisches Feintuning bleibt die Regel.

Stand der Technik (2026)

• Transformer- und Operator-Architekturen für große 3D-Netze (Transolver, Universal Physics Transformers und Nachfolger) bewältigen inzwischen Oberflächen- und Volumendaten in Fahrzeuggröße und werden an öffentlichen Datensätzen wie DrivAerML verglichen [4]; ML-basierte CFD ist aus der Forschung in kommerzielle Plattformen gelangt.
• Neural Operators (FNO) lernen Abbildungen zwischen Funktionsräumen und verallgemeinern auf regulären Gebieten über Auflösungen hinweg [2].
• Physikinformiertes Lernen hilft bei knappen Daten, ersetzt aber nicht die Validierung.
• Grenzen und Fehlerbilder: schlechte Extrapolation außerhalb des Trainings-Entwurfsraums (neue Topologie, Reynolds-Zahl oder Randbedingungen), Glättung scharfer Merkmale wie Verdichtungsstöße oder Ablösung, Fehler bei den integralen Größen, auf die es am meisten ankommt (Widerstand auf wenige Counts genau), teure Erzeugung der Trainingsdaten sowie Abweichungen bei der Netz-/Geometriedarstellung. Gute Praxis sind Unsicherheitsschätzung, OOD-Erkennung und eine verpflichtende Solver-Prüfung des endgültigen Entwurfs.

Gemeinsame Bausteine & Kombinationen

• Gemeinsamer Stack (Simulation + scientific-fm + 3d-vision): SCI-006 generatives Design und Topologieoptimierung nutzt Surrogate als schnelle Bewerter in der Schleife; SCI-022 Testdaten- Analytik teilt Datenpipelines; SCI-010 Klima-/Erdsystem-Emulatoren verwenden dieselbe Neural-Operator-Werkzeugkette; SCI-024 CAD-Generierung liefert Geometrien; PRED-006 vorausschauende Wartung und ROBO-010 digitale Zwillinge nutzen Surrogate reduzierter Ordnung.
• Hardware: Ein HW3-/HW4-GPU-Server wird für das Training verschiedener Surrogate gemeinsam genutzt; Solver-Lizenzen und HPC-Kapazität sind die weiteren gemeinsamen Ressourcen.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bis zum Pilot, einige Monate bis zur Produktion; Plattformlizenzen plus Solver-Läufe für Trainingsdaten.
• Weg B/C: 6-12 Monate für eine robuste Pipeline mit einem Team aus ML-Ingenieur(en) und CFD-/FEM-Fachleuten.
• Kostentreiber: Anzahl und Kosten der Trainingssimulationen, GPU-Training, Zeit der Fachleute für die Validierung.
• Kennzahlen: Fehler an zurückgehaltenen Entwürfen (L2-Fehler der Felder, Widerstands-/Spannungsfehler gegenüber dem Solver), Beschleunigung pro Bewertung, Break-even-Zahl der Varianten, Anteil der per Surrogat vorab geprüften Designentscheidungen, Anteil der Surrogat-Vorhersagen mit OOD-Markierung, eingesparte Solver-Stunden.

Menschen & Veränderung

• Früh einbinden: Geschäftsleitung (Budget, Umfang), Abteilungsleitung und Simulationsingenieure als Prozessverantwortliche, IT für GPU/HPC und Speicher, IT-Sicherheit für Geometrie- und Exportkontrolldaten, Datenverantwortliche der Solver-Archive.
• Betriebsrat: hängt davon ab. Simulationsdaten sind nicht personenbezogen, aber Plattform-Konten protokollieren die Nutzeraktivität, und nach der BAG-Rechtsprechung genügt die objektive Eignung zur Überwachung, sodass §87(1) Nr. 6 BetrVG greifen kann; informieren Sie den Betriebsrat rechtzeitig nach §90(1) Nr. 3 und siehe GUIDE-004. Öffentlicher Dienst: Personalrat.
• Datenschutz: Die Beteiligung der/des Datenschutzbeauftragten ist gering (keine personenbezogenen Daten außer Konten), aber schließen Sie mit Cloud-Plattformanbietern einen AVV (Art. 28 DSGVO) ab.
• KI-Kompetenz: Nach Art. 4 der KI-Verordnung (AI Act) (seit 27. Juli 2026) müssen Arbeitgeber und Anbieter Maßnahmen ergreifen, um die KI-Kompetenz des Personals zu fördern; planen Sie eine kurze Schulung ein (siehe GUIDE-006).
• Pilot und Kommunikation: mit einer Produktfamilie und 2-3 skeptischen, aber aufgeschlossenen Simulationsingenieuren beginnen; das Surrogat als Vorauswahl-Werkzeug darstellen, nicht als Ersatz (GUIDE-008, GUIDE-009).
• Typische Bedenken: Angst, dass Fachleute überflüssig werden (Antwort: Der Solver bleibt Referenz), übermäßiges Vertrauen (verpflichtende OOD-Markierung und Solver-Bestätigung vor der Freigabe).
• Menschliche Kontrolle: Ingenieure entscheiden über die Freigabe des Entwurfs; jedes Surrogat-Ergebnis außerhalb des Gültigkeitsbereichs wird im Solver erneut gerechnet.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko für Engineering-Analysewerkzeuge; Art. 4 (KI-Kompetenz) gilt. Wird ein Surrogat zur Sicherheitskomponente eines regulierten Produkts (z. B. Maschine, Medizinprodukt, Luftfahrt), gelten Branchenregeln und Konformitätsbewertung für das Produkt, nicht für das Werkzeug als solches. Keine Rechtsberatung.
• DSGVO: Simulationsdaten sind normalerweise nicht personenbezogen; Nutzerkonten in Plattformen sind die einzigen personenbezogenen Daten.
• Weitere Regelwerke: Exportkontrolle für Geometriedaten aus Luft- und Raumfahrt/Verteidigung sowie Geschäftsgeheimnisse (Richtlinie (EU) 2016/943) — EU- oder On-Premises-Hosting bevorzugen; ITAR-/EAR-Risiko bei US-Cloud-Anbietern. Typgenehmigungen in Luftfahrt, Schienenverkehr und Automobil verlangen weiterhin validierte, nachvollziehbare (Solver- oder Test-basierte) Nachweise.
• Technische Risiken: unbemerkte Extrapolationsfehler, Modell-Drift bei wechselnden Geometriefamilien, übermäßiges Vertrauen von Nicht-Spezialisten. Gegenmaßnahmen: dokumentierter Gültigkeitsbereich, OOD-Markierungen, regelmäßige Neuvalidierung gegen den Solver, versionierte Trainingsdaten.

Erste Schritte

1. Eine wiederholbare Simulationsaufgabe wählen (gleiche Geometriefamilie, gleiches Solver-Setup) mit mindestens einigen hundert früheren Läufen oder Budget für zusätzliche Läufe.
2. Die Zielgrößen und die für eine Entscheidung nötige Genauigkeit festlegen (z. B. Widerstand auf X % genau).
3. Zuerst ein Vergleichsmodell laufen lassen (POD-ROM oder Gauß-Prozess), dann einen Neural Operator/Transformer (PhysicsNeMo oder eine Herstellertestversion) auf derselben Aufteilung.
4. An zurückgehaltenen Entwürfen auswerten, auch an bewusst außerhalb des Bereichs liegenden; Unsicherheits-/OOD-Prüfungen ergänzen.
5. In die Entwurfsschleife einbetten, mit verpflichtender Solver-Bestätigung, und den Break-even gegenüber den Solver-Kosten verfolgen.

Quellen

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