Gudrun spricht in dieser Folge mit Sarah Bischof, Timo Bohlig und Jonas Albrecht. Die drei haben im Sommersemester 2021 am Projektorientiertes Softwarepraktikum teilgenommen.

Das Praktikum wurde 2010 als forschungsnaher Lernort konzipiert. Studierende unterschiedlicher Studiengänge arbeiten dort ein Semester lang an konkreten Strömungssimulationen. Es wird regelmäßig im Sommersemester angeboten. Seit 2014 liegt als Programmiersprache die Open Source Software OpenLB zugrunde, die ständig u.a. in der Karlsruher Lattice Boltzmann Research Group (LBRG) weiter entwickelt wird.

Konkret läuft das Praktikum etwa folgendermaßen ab:
Die Studierenden erhalten eine theoretische Einführung in Strömungsmodelle, die Idee von Lattice-Boltzmann-Methoden und die Nutzung der Hochleistungrechner am KIT. Außerdem finden sie sich für ein einführendes kleines Projekt in Gruppen zusammen. Anschließend wählen sie aus einem Katalog eine Frage aus, die sie bis zum Ende des Semesters mit Hilfe von Computersimulationen gemeinsam beantworten. Diese Fragen sind Teile von Forschungsthemen der Gruppe, z.B. aus Promotionsprojekten oder Drittmittelforschung. Während der Projektphase werden die Studierenden von dem Doktoranden/der Doktorandin der Gruppe, die die jeweilige Frage gestellt haben, betreut. Am Ende des Semesters werden die Ergebnisse in Vorträgen vorgestellt und diskutiert oder es wird eine Podcastfolge aufgenommen. In einer Ausarbeitung werden außerdem die Modellbildung, die Umsetzung in OpenLB und die konkreten Simulationsergebnisse ausführlich dargelegt und in den aktuellen Forschungsstand eingeordnet.

Sarah, Timo und Jonas sind am KIT im Masterstudiengang Chemieingenieurwesen eingeschrieben. Neben den verschiedenen Masterstudiengängen Mathematik kommen aus diesem Studiengang die meisten Interessenten für das Softwarepraktikum. Im Podcast erläutern sie, was sie an der Strömungssimulation interessiert und inwieweit sie sich gut oder auch nicht so gut auf die Anforderungen vorbereitet gefühlt haben, wie sie sich die Arbeit in der Gruppe aufgeteilt haben und was sie an fachlichen und überfachlichen Dingen dort gelernt haben.

Das Thema des Projektes war ein Benchmark für die Durchströmung der Aorta. Dies ist einer der Showcases für OpenLB, die auf den ersten Blick die Leistungsfähigkeit der Software demonstrieren sollen.

Das Projekt wurde von der Gruppe in drei Teile gegliedert:

• Benchmark Test auf dem bwUniCluster 2.0 (High Performance Computer)
• Performance Analyse mit selbstgeschriebener Source Code Erweiterung
• Performance Analyse mit externer Software (Validierung der Source Code Erweiterung)

Mit Hilfe der Benchmark Tests auf dem HPC konnte die maximale Skalierbarkeit des Aorta Source Codes in Abhängigkeit der Problemgröße gefunden werden. Sie gibt an, auf wie vielen Computerprozessoren der Showcase mit der höchsten Performance simuliert werden kann. Des Weiteren wurde die parallele Effizienz mit Hilfe der Speedup Kennzahl untersucht. Diese beschreibt inwiefern sich die Simulationszeit infolge von Erhöhung der Prozessoranzahl verringert. In beiden Fällen zeigten die Performanceindikatoren ein Maximum bei 400-700 Prozessoreinheiten für Problemgrößen bis zu einer Resolution von N = 80.

Das Softwarepaket OpenLB beinhaltet in Release 1.4r0 keine detaillierten Schnittstellen zur Performancemessung. Durch eine Source Code Erweiterung konnte eine interne Zeitmessung der einzelnen Funktionen des Codes realisiert werden. Dabei wurden so genannte Bottlenecks identifiziert und dokumentiert, welche durch Updates in zukünftigen Versionen der Software eliminiert werden sollen. Des Weiteren konnte auch durch die Code Erweiterung eine Aussage über die Parallelisierung getroffen werden. Im Vergleich zu den Benchmark Tests können direkt Funktionen des Source Codes, die die Parallelisierung hemmen, bestimmt werden. Die Performance Analyse durch das externe Programm und durch die Source Code Erweiterung bestätigen eine gut funktionierende Parallelisierung.

Die Realisierung erfolgte dabei durch die Messung der Laufzeit der Hauptschritte einer OpenLB Simulation, sowie der detaillierten Analyse einzelner Funktionen. Diese finden sich zum aktuellen Zeitpunkt im Post-Processing des "Collide And Stream" Schrittes der Simulation. Collide And Stream beschreibt einen lokalen Berechnungsschritt, einen lokalen und einen nicht lokalen Übertragungsschritt. Der Kollisionsschritt bestimmt ein lokales Gleichgewicht der Massen-, Momenten- und Energiebilanzen. Im nicht-lokalen Streaming Schritt werden diese Werte auf die angrenzenden Blöcke des Simulationsgitters übertragen. Dies ermöglicht im Vergleich zu CFD-Simulationen, die auf Basis der Finite-Volumen-Methode (FVM) die Navier-Stokes Gleichungen lösen, effizientere Parallelisierung insbesondere bei Einsatz einer HPC-Einheit. Die Post Prozessoren im Collide And Stream wenden unter anderem bestimmte, im vorangegangenen Schritt gesetzte Randbedingungen auf definierte Bereiche der Simulationsgeometrie an. Sie werden dabei nur für nicht-lokale Randbedingungen verwendet, weitere Randbedingungen können auch innerhalb des Kollisionsschrittes modelliert werden. Im Showcase der Aorta ist für das Fluid (Blut) am Eingang der Simulation eine Geschwindigkeits-Randbedingung nach Bouzidi mit Poiseuille-Strömungsprofil und am Ausgang eine "stress-free" Bedingung gewählt. Für die Aortawand ist eine no-slip Bedingung mit Fluidgeschwindigkeit null implementiert (Für genauere Informationen zum Simulationsaufbau hier und hier.

Die Laufzeit der Post-Processor Funktionen, deren Aufgabe es ist die Randbedingungen anzuwenden, können mit dem Timer des Release 1.4r0 nicht analysiert werden. Mit Blick auf spätere Releases ist es mit der Source Code Erweiterung nun möglich mit geringem Aufwand Daten über die Effizienz der vorhandenen, neuer oder verbesserter Funktionen in OpenLB zu gewinnen.

Eine integrierte Zeitmessung als Analysetool kann einen direkten Einfluss auf die Performance des Source Codes haben, weshalb mit Hilfe der externen Software AMDµProf die Bottlenecks validiert wurden. Sowohl bei der internen als auch externe Performance Analyse sind die selben Post-Processing Schritte als Bottlenecks erkennbar, welches die Code Erweiterung validiert. Zusätzlich konnte mit der AMDμProf-Software die aktuelle OpenLB Version 1.4r0 mit der vorherigen Version 1.3r1 verglichen werden. Dabei fällt auf, dass sich die Bottlenecks vom Berechnungsschritt in Collide And Stream (Release 1.3r1) zum Post-Processing Schritt in Collide And Stream (Release 1.4r0) verschoben haben. Abschließend wurde eine vektorisierte Version von OpenLB erfolgreich getestet und ebenfalls auf Bottlenecks untersucht. Eine Vektorisierung eines Codes, auch bekannt als SIMD, soll die Parallelisierung verbessern und der Aorta Simulation eine bessere Performance verleihen. Das Bottleneck des Post-Processing Schritts in Collide And Stream, speziell durch Implementierung neuer Bouzidi Boundaries, wurde durch eine weitere Gruppe im Rahmen des Projektorientierten Softwarepraktikums optimiert. Es konnte eine Performance Verbesserung um einen Faktor 3 erreicht werden (mit OpenMP Compiler). Durch eine gezielte Analyse der Bottlenecks im Code konnte das Potential für die Beschleunigung der Simulation erweitert werden.

Aber natürlich lohnt es sich hier weiterhin anzusehen, wo noch konkretes Potential für die Beschleunigung der Simulation liegt. Zumal seit dem letzten Relounch einige Pardigmen in der Software OpenLB verändert wurden.