Aktuelle Trends und Herausforderungen in der Finite-Elemente-Simulation

Transkript

1 Aktuelle Trends und Herausforderungen in der Finite-Elemente-Simulation Kai Diethelm GNS Gesellschaft für numerische Simulation mbh Braunschweig engineering software development Folie 1

2 Überblick Vorstellung GNS Vorstellung der Software-Produkte Ansätze zur Parallelisierung von Programmen Reproduzierbarkeit paralleler Lösungen Zusammenfassung Folie 2

3 GNS im Überblick Allgemeines Firmengründung Gegenstand der Firma Umsatz (GNS mbh) Sitz der Gesellschaft Mitarbeiter Kunden 1994 Berechnungsdienstleistungen, Entwicklung und Vertrieb von Simulations-Software Derzeit ca. 9 Mio, davon jeweils ca. 50% mit Dienstleistung und mit Software-Lizenzverkäufen Braunschweig ca. 120 (Ingenieure, Physiker, Mathematiker,...) Internationale Automobil-, Luft- und Raumfahrtindustrie Folie 3

4 GNS im Überblick Standorte (national) Braunschweig Berlin Flörsheim (Rhein/Main) Sindelfingen Ingolstadt Landkarte: (cc-by) geo.dianacht.de Folie 4

5 GNS im Überblick Standorte (international) Prag Pune Shanghai Melbourne Landkarte: (cc-by) geo.dianacht.de Folie 5

6 GNS im Überblick Software-Produkte Animator Indeed Generator OpenForm Folie 6

7 Indeed Anwendungsgebiete Hauptanwendung: Tiefziehsimulation von Karosseriebauteilen Ebenes Blech wird mittels Werkzeugen (Blechhalter, Stempel, Matrize) in einer Presse plastisch ausgeformt Folie 7

8 Indeed Theoretische Grundlagen Quasi-statisches Finite-Elemente-Programm für die numerische Simulation von Umformprozessen Implizite Integration der Gleichgewichtsbedingungen Verschiedene nichtlineare Elementtypen Schalenelemente (Crisfield-Formulierung / Schoop) Tetra- und Hexa-Elemente (linear/quadratisch) Diverse elasto-plastische Materialmodelle Kontakt-Formulierungen: starr - deformierbar deformierbar - deformierbar (Penalty-Methode) Adaptive Netzverfeinerung Parallele Versionen: Shared Memory Distributed Memory Anspruch: High-End-System für Nutzer mit hohen Genauigkeitsanforderungen Folie 8

9 Ansätze zur Parallelisierung - Shared Memory Grundidee: Rechner enthält System von Multiprozessoren, die sich Speicher teilen Gleiche Datenzugriffszeiten für alle Prozessoren ( uniform memory access ) Verschiedene Programmiermodelle verfügbar In INDEED verwendet: OpenMP Unterstützung von FORTRAN, C, C++ Plattformunabhängigkeit Relativ einfach zu verwenden (direktivenbasiert) Folie 9

10 Reproduzierbarkeit der Lösung Simulation 1* Simulation 2* Simulation 3* *:12cores, Intel SandyBridge Nicht reproduzierbare Ergebnisse im parallelen Fall Ursache: Fließkommaoperationen sind nicht assoziativ, z.b. (a + b) + c a + (b + c) Auswirkung je nach Konditionierung des Gleichungssystems mehr oder weniger stark Folie 10

11 Reproduzierbarkeit der Lösung Simulation 1* Simulation 2* Simulation 3* *:12cores, Intel SandyBridge Reproduzierbarkeit gewährleistet, wenn Operationen immer in der gleichen Reihenfolge ausgeführt werden Programmanpassung zur Erzielung reproduzierbarer Ergebnisse erforderlich für Aufbau der Gesamtsteifigkeitsmatrix Lösen des Gleichungssystems ( PARISOL) Folie 11

12 Ansätze zur Parallelisierung - Shared Memory Grundidee: Rechner enthält System von Multiprozessoren, die sich Speicher teilen Gleiche Datenzugriffszeiten für alle Prozessoren ( uniform memory access ) Verschiedene Programmiermodelle verfügbar In INDEED verwendet: OpenMP Unterstützung von FORTRAN, C, C++ Plattformunabhängigkeit Relativ einfach zu verwenden (direktivenbasiert) Reproduzierbarkeit in INDEED unabhängig von der Prozessoranzahl gewährleistet Im Idealfall ist die Beschleunigung mit wachsender Prozessoranzahl linear Bei heutigen Prozessoren sind gleiche Datenzugriffszeiten immer weniger gewährleistet ( non-uniform memory access ) Folie 12

13 Ansätze zur Parallelisierung - Distributed Memory Grundidee: Rechner besteht aus System von mehreren Einzelrechnern Datenaustausch über Netzwerk erforderlich Klassische Anwendung in der FEM: Gebietszerlegung (domain decomposition) Seit Mitte 1990 MPI als Standard-Programmiermodell verfügbar Unterstützung von FORTRAN, C, C++ Plattformunabhängigkeit Hoher Programmieraufwand Kombination mit Shared-Memory-Parallelisierung möglich Keine Reproduzierbarkeit in INDEED Folie 13

14 Ansätze zur Parallelisierung - Hardwarebeschleuniger Grundidee: Entlastung des Hauptprozessors durch Co-Prozessoren (Grafikkarten) Programmausführung erfolgt in der Regel parallel Grafikkarten (GPUs) verarbeiten Daten nach dem SIMD Prinzip (Single Instruction, Multiple Data) Verschiedene Techniken zur Programmierung von GPUs CUDA (Compute Unified Device Architecture) Nur Unterstützung von NVIDIA GPUs Direkte Unterstützung nur für C/C++ OpenCL Plattformunabhängigkeit Standardisierte Erweiterung von C Datentransfer von der bzw. zur GPU notwendig Kombination mit Shared- und Distributed-Memory-Parallelisierung möglich Folie 14

15 Ansätze zur Parallelisierung - Hardwarebeschleuniger CPU memory Vorbereitung der Elementblöcke CPU GPU Berechnung der lokalen Steifigkeiten Assemblierung zu globaler Steifigkeitsmatrix Folie 15

16 Ansätze zur Parallelisierung - Hardwarebeschleuniger Aufbau der Gesamtsteifigkeitsmatrix Time [s] 20000,00 Time [hh:mm:ss] 18000, , , ,00 GPU node (CPU only) 10000, , ,00 GPU node (CPU + GPU) 1GPU 4000,00 2GPUs 2GPUs 2000,00 2GPUs 0, % 22:00:00 20:00:00 18:00:00 16:00:00 14:00:00 12:00:00 10:00:00 08:00:00 06:00:00 04:00:00 02:00:00 00:00:00 8 #CPU cores Gesamtlaufzeit 1GPU 2GPUs 2GPUs % 2GPUs 8 #CPU cores Nichtbeschleunigte Programmteile verhindern eine signifikante Verringerung der Gesamtlaufzeiten Problem: Datentransfer zur / von der GPU Hoher Zeitaufwand für die manuelle Portierung mittels CUDA Mögliche Alternative: Automatische Code-Generatoren, z.b. HMPP oder OpenACC; OpenMP 4.0 Folie 16

17 Softwarewerkzeuge zur Perfomance-Analyse - Vampir Zeitlicher Verlauf der Programmausführung Zusammenfassung Ungenutzte CPU-Ressourcen Legende Unzureichende Lastbalancierung zwischen CPU und GPU verhindert bessere Performance Folie 17

18 Zukünftige Herausforderungen Skalierbarkeit Anzahl der Rechenkerne wächst stark weniger Hauptspeicher pro Rechenkern Aufgabe: Anpassung des Programmcodes an geänderte HardwareArchitekturen, um Leistung der Hardware optimal auszunutzen Energiebedarf 35% der Kosten eines modernen Hochleistungsrechners entfallen auf Energieversorgung (Tendenz steigend) Struktur des Programmcodes hat Einfluss auf Energiebedarf Aufgabe: Erweiterung vorhandener Performance-Analysewerkzeugen auf Energieanalyse (Gemeinschaftsprojekt Score-E von GNS mit RWTH Aachen, GRS Aachen, FZ Jülich, TU Dresden, TU München; Förderung durch BMBF) Folie 18

19 Zusammenfassung Rechnerarchitekturen werden immer heterogener. Wachsende Anzahl verfügbarer Prozessoren pro Rechenknoten erfordert genaue Kenntnis der Rechnerarchitektur. Konflikt zwischen Forderung nach reproduzierbaren Ergebnissen und Forderung nach hoher Skalierbarkeit. Breiter Einsatz von Hardware-Beschleunigern erfordert Entwicklung anwenderfreundlicher Programmiermodelle. Optimierung des Programmcodes muss auch Energiekosten als Zielgröße berücksichtigen. Folie 19