-
Gemeinsamer Abschlussberichtdes BMBF-Verbundprojekts
S K A L B
Lattice-Boltzmann-Methoden frskalierbare
Multi-Physik-Anwendungen
J. Habich, G. Wellein, M. Wittmann T. ZeiserRegionales
Rechenzentrum Erlangen (RRZE)
Friedrich-Alexander-Universitt Erlangen-Nrnberg (FAU)
C. Feichtinger, K. Pickl, U. Rde, F. SchornbaumLehrstuhl fr
Systemsimulation (LSS)
Friedrich-Alexander-Universitt Erlangen-Nrnberg (FAU)
M. Geveler, S. TurekLehrstuhl fr Angewandte Mathematik &
Numerik (TUDo)
Technische Universitt Dortmund
M. Krafczyk, K. Kucher, M. SchnherrInstitut fr rechnergesttzte
Modellierung im Bauingenieurwesen (iRMB)
Technische Universitt Braunschweig
U. Kster, M. ReschHchstleistungsrechenzentrum Stuttgart
(HLRS)
Universitt Stuttgart
F. PlatteIANUS GmbH, Dortmund (IANUS)
Das diesem Bericht zugrundeliegende Vorhaben SKALB wurde mit
Mitteln des Bun-desministeriums fr Bildung und Forschung (BMBF)
unter dem Frderkennzeichen01IH08003 im Rahmen des ersten Calls
HPC-Software fr skalierbare Parallelrech-ner von Anfang 2009 bis
Ende 2011 gefrdert. Die Verantwortung fr den Inhaltdieser
Verffentlichung liegt bei den Autoren.
-
Inhaltsverzeichnis
1 Kurze Darstellung des Projekts 11.1 Aufgabenstellung . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 21.2
Randbedingungen und Voraussetzungen . . . . . . . . . . . . . . . .
. 41.3 Planung und Ablauf des Vorhabens . . . . . . . . . . . . . .
. . . . . . 41.4 Wissenschaftlicher und technischer Stand, an den
angeknpft wurde . . 5
1.4.1 Ausgangssituation VirtualFluids . . . . . . . . . . . . .
. . . . . 61.4.2 Ausgangssituation waLBerla . . . . . . . . . . . .
. . . . . . . . 61.4.3 Ausgangssituation ILBDC . . . . . . . . . .
. . . . . . . . . . . 71.4.4 Ausgangssituation FEAT* und FEAST* . .
. . . . . . . . . . . 8
1.5 Zusammenarbeit mit anderen Stellen . . . . . . . . . . . . .
. . . . . . 9
2 Eingehende Darstellung des Projekts 112.1 Verwendung der
Zuwendung und erzielte Ergebnisse . . . . . . . . . . . 11
2.1.1 AP1: Portierung und Optimierung von LB-Anwendungen
aufmassiv parallele HPC-Systeme . . . . . . . . . . . . . . . . . .
. 11
2.1.2 AP2: Weiterentwicklung von LB-Methoden fr praktische
An-wendungen auf hochskalierenden Systemen . . . . . . . . . . . .
16
2.1.3 AP3: Verbesserte numerische Anstze fr LB-Methoden . . . .
. 212.1.4 AP4: Hardwarenahe Implementierung fr Nicht-
Standardprozessoren . . . . . . . . . . . . . . . . . . . . . .
. . 232.1.5 AP5: Benchmarking und Showcases . . . . . . . . . . . .
. . . . 252.1.6 Erzielte Fortschritte in den weiterentwickelten
LB-Codes . . . . 35
2.2 wichtigste Positionen des zahlenmigen Nachweises . . . . . .
. . . . . 402.2.1 FAU / RRZE . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 402.2.2 FAU / LSS . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 412.2.3 iRMB . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 412.2.4 TUDo . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . 422.2.5 HLRS . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.2.6
IANUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 43
2.3 Notwendigkeit und Angemessenheit der geleisteten Arbeit . .
. . . . . . 442.4 Voraussichtlicher Nutzen, insbesondere
Verwertbarkeit der Ergebnisse
im Sinne des fortgeschriebenen Verwertungsplans . . . . . . . .
. . . . 462.5 Whrend der Durchfhrung des Vorhabens bekannt
gewordene Fort-
schritte bei anderen Stellen . . . . . . . . . . . . . . . . . .
. . . . . . . 472.6 Erfolgte oder geplante Verffentlichungen der
Ergebnisse . . . . . . . . 47
2.6.1 Verffentlichungen FAU . . . . . . . . . . . . . . . . . .
. . . . 472.6.2 Verffentlichungen TUDo . . . . . . . . . . . . . .
. . . . . . . . 502.6.3 Verffentlichungen iRMB . . . . . . . . . .
. . . . . . . . . . . . 53
I
-
Inhaltsverzeichnis
2.6.4 Verffentlichungen HLRS . . . . . . . . . . . . . . . . . .
. . . . 542.6.5 Vortrge FAU . . . . . . . . . . . . . . . . . . . .
. . . . . . . . 542.6.6 Vortrge TUDo . . . . . . . . . . . . . . .
. . . . . . . . . . . . 602.6.7 Vortrge iRMB . . . . . . . . . . .
. . . . . . . . . . . . . . . . 622.6.8 Vortrge HLRS . . . . . . .
. . . . . . . . . . . . . . . . . . . . 622.6.9 Vortrge IANUS . . .
. . . . . . . . . . . . . . . . . . . . . . . 63
2.7 Sonstige Referenzen . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 64
II
-
Kapitel 1
Kurze Darstellung des Projekts
Die Modellierung und Simulation strmungsmechanischer Prozesse
hat in den letztenJahrzehnten groe Fortschritte gemacht.
Triebfedern waren gleichermaen rasante Ent-wicklungen in der
Rechnertechnologie sowie substanzielle Neuerungen im
methodisch-algorithmischen Bereich. Die Simulation hat sich daher
im Bereich der Strmungs-mechanik neben Experiment und Theorie
etabliert. Vielfach muss dabei aber nochimmer auf vereinfachte
Modelle mit problemspezifisch angepassten Korrelationspara-metern
zurckgegriffen werden. Dies ermglicht typischerweise qualitativ
aussagekrf-tige CFD-Simulationen (Computational Fluid Dynamics).
Ein verlssliches Scale-Upvom Labor- zum Produktionsmastab, im Zuge
einer numerischen Prozessoptimierung,kann selbst bei
Standardprozessen hufig nicht erfolgen.
Weit verbreitete kommerzielle CFD-Werkzeuge besitzen oft weder
die numerische Leis-tungsfhigkeit moderner Methoden der Angewandten
Mathematik und des Wissen-schaftlichen Rechnens, noch sind sie fr
hochskalierbare Rechnersysteme mit potenti-ell heterogener
Architektur ausgelegt. Ein weiteres Problem sind
Lizenzkostenmodelle,deren Kostenfunktionen mit dem
Parallelisierungsgrad ansteigen.
Die Verfgbarkeit validierter, kostengnstiger, hochskalierbarer
CFD-Software, welchemodernste Rechnersysteme effizient nutzen kann
und gleichzeitig fortschrittliche nu-merische Methoden
implementiert, ist daher von grundlegender Bedeutung, um dieweiter
ansteigende Rechenleistung fr die numerische Strmungsmechanik
nutzbar zumachen. Das vorliegende Projekt SKALB adressiert in
diesem Zusammenhang dieLattice-Boltzmann-(LB)-Verfahren [Hn04],
welche sich in den letzten 15 Jahren zu ei-ner vielversprechenden
methodischen Alternative zu konventionellen Lsungsverfahrenfr die
gngigen Navier-Stokes-Gleichungen entwickelt haben. Neben den
klassischenCFD-Bereichen, wie etwa der Automobilbranche, haben sie
inzwischen auch Eingangin die Verfahrenstechnik, das
Bauingenieurwesen, die Biomedizin und viele weitereGebiete
gefunden.
Im Rahmen von SKALB wurde das Zusammenspiel von numerischen
Methoden, Da-tenstrukturen und mglichen
Implementierungsalternativen fr LB-Verfahren im Hin-blick auf
knftige hochparallele, heterogene Rechnerarchitekturen untersucht.
Frh-zeitige Umsetzung auf verfgbare High-End-Rechnersysteme und
Nachhaltigkeit derentwickelten Softwarestrukturen, breite
methodische Abdeckung sowie Validierung derSoftware insbesondere
vor dem Hintergrund einer industriellen Nutzung waren die
zen-tralen Aspekte des Projekts.
1
-
Kapitel 1 Kurze Darstellung des Projekts
Die Programmpakete der beteiligten Partner konnten dabei auf ein
nachhaltiges undhocheffizientes Niveau gebracht werden, das den
beteiligten Gruppen die Mglichkeiterffnet, ihre international
fhrende Stellung ausbauen zu knnen selbst unter Be-rcksichtigung
der vielen Unbekannten hinsichtlich der weiteren
Hardwareentwicklung.Darber hinaus konnten zahlreiche breit nutzbare
Erkenntnisse zur Entwicklung zu-kunftssicherer und
hardwareeffizienter Softwarestrukturen fr hochparallele,
hetero-gene Hardwarearchitekturen gewonnen werden. Im Rahmen eines
engen industriel-len Austausches, der vom KMU-Partner
kontinuierlich koordiniert und vorangetriebenwurde, konnte auch das
wirtschaftliche Potential der SKALB-Entwicklungen demons-triert
werden. Im Rahmen von zahlreichen wissenschaftlichen Vortrgen und
Publika-tionen wurden die Projektergebnisse kontinuierlich an
Dritte weitergegeben und stie-en auf groes internationales Echo.
Die SKALB-Ergebnisse haben das Potential, dieweiteren Entwicklungen
in der gesamten LB-Community hinsichtlich Methodik
undHardwareeffizienz nachhaltig zu beeinflussen.
1.1 Aufgabenstellung
Zentrale Aufgabe des Projekts SKALB war es,
Lattice-Boltzmann-Lser vor dem Hin-tergrund des stattfindenden
Wechsels hin zu homogenen und heterogenen Mehr-
undVielkernarchitekturen methodisch und technisch
weiterzuentwickeln. Damit sollte einBeitrag zum nachhaltigen
Einsatz von LB-Verfahren in Virtuellen Strmungslaborengeleistet
werden, in denen Modellbildung, Simulation, Optimierung und
experimentelleUntersuchung iterativ gekoppelt werden knnen. Zentral
fr das Projekt war die inter-disziplinre Zusammenarbeit von
Wissenschaftlern aus den Ingenieurwissenschaften,der angewandten
Informatik und Mathematik sowie Experten der Rechenzentren.
Lattice-Boltzmann-Verfahren zhlen zu den Emerging Technologies,
deren Entwicklungnoch immer dynamisch voranschreitet. Daher war es
nicht das Ziel von SKALB eineneinzigen gruppenberspannenden
Applikationscode zu erstellen. Die in den Gruppenexistierenden
LB-Programmsysteme sollten vor dem Hintergrund ihrer jeweiligen
An-wendungsbereiche weiterentwickelt werden und damit auch
langfristig als hocheffizienteTools zur Verfgung stehen.
Gleichzeitig wurde der hohe Aufwand vermieden, der miteiner
Neuentwicklung von Grund auf verbunden ist. Die abgedeckten
Themengebieteumfassten dabei:
Der ILBDC-Code (RRZE) ist auf die Simulation von laminaren
Strmungen inextrem komplexen Geometrien mit geringem Hohlraumanteil
(z.B. porse Medienoder Katalysatorschttungen in chemischen
Reaktoren) spezialisiert.
waLBerla (LSS) ist ein Software-Framework fr massive parallele
Multi-Physik-Anwendungen basierend auf der
Lattice-Boltzmann-Methode, das durch sein sys-tematisches Design
sowohl flexible, anwendbar und erweiterbar ist als auch effi-zient
und skalierbar.
2
-
1.1 Aufgabenstellung
VirtualFluids (iRMB) ist ein adaptiver, hierarchischer Fluidlser
basierend aufder Lattice-Boltzmann-Methode, der den vollen
Simulationszyklus von der Git-tergenerierung bis zur
Datenpersistierung abdeckt und eine hochskalierende
Par-allelisierung auf Multi- und Many-Core-Architekturen
erlaubt.
FEAST (TUDo) ist ein Finite Element Framework fr massiv
parallele Multi-Physik-Anwendungen und enthlt neben seinen
numerisch hochgradig robustenKomponenten auch Backends fr
Hardwarebeschleunigung u.a. mit GPGPUs.
ber dieses Anwendungsspektrum hinweg besitzen LB-Verfahren einen
gemeinsamenmethodischen Kern, hnliche algorithmische Grundmuster
sowie Datenstrukturen undberuhen auf sehr hnlichen numerischen
Kernroutinen. Zahlreiche Projektaufgaben wa-ren daher als stark
integrierendes Element angelegt und wurden
gruppenbergreifenddurchgefhrt:
Portierung und Optimierung fr verfgbare High-End-Systeme und
Bereitstel-lung von Benchmarkkonfigurationen fr Rechenzentren der
Gau-Allianz unddas Gau-Center for Supercomputing (GCS).
Entwicklung skalierbarer und effizienter LB-spezifischer
Gebietszerlegungsanst-ze und Lastbalanzierungsmethoden.
Etablierung eines strukturierten
Performance-Engineering-Ansatzes.
Evaluierung neuer Hardwarekonzepte und (prototypische)
Implementierung vonLB-Verfahren mit besonderem Schwerpunkt auf
parallelen GPGPU-Clustern.
Nutzbarkeit neuer Programmiermodelle wie hybrides MPI/OpenMP
oder PGAS-Sprachen.
Methodische Weiterentwicklung der LB-Verfahren hinsichtlich
lokaler Verfeine-rung, Randbedingungen, Kollisionsmodelle.
Evaluierung der Mglichkeiten eines FEM-Ansatzes fr
LB-Verfahren.
Optimiertes Workflowmanagement bezglich Pre-/Postprocessing
Computatio-nal Steering und Checkpoint-Restart Mechanismen.
Benchmarking und Validierung industrierelevanter
Strmungsprobleme.
Aufgrund der regulren Grundstruktur von LB-Verfahren wird im
akademischen Um-feld erwartet, dass viele der in SKALB gewonnenen
Erkenntnisse auch auf anderenumerische Verfahren bertragbar sind,
insbesondere wenn sie mit einem explizitenZeitschritt auf
Normzellen arbeiten und nur nchste oder bernchste Nachbarn beider
Kommunikation bercksichtigen.
3
-
Kapitel 1 Kurze Darstellung des Projekts
1.2 Randbedingungen und Voraussetzungen
Bei der methodischen Entwicklung und der ingenieurmigen
Anwendung von LB-Verfahren ist Deutschland neben den USA und
Frankreich (letztere speziell fr me-thodische Fragestellungen)
federfhrend. Allgemein ist jedoch zu beobachten, dass inschnellen
und skalierbaren LB-Lsern derzeit nur einfache Physik, einfache
Nu-merik und einfache Gitterstrukturen implementiert sind mit
entsprechenden Ein-schrnkungen an die zu modellierende Komplexitt.
Bei Forschungscodes, die sowohl inphysikalischer als auch in
numerischer Hinsicht deutlich weiter entwickelt sind,
werdenHPC-Aspekte dagegen weitgehend vernachlssigt.
Das interdisziplinre Softwareprojekt SKALB, das zwischen
akademischer Forschungund industrieller Anwendung anzusiedeln ist,
sollte laufende methodische Forschungs-arbeiten im LB-Umfeld mit
neuesten Techniken des High-Performance-Computing
zu-sammenbringen.
Da zu Beginn des SKALB-Projekts bei alle universitren
Projektpartnern bereits lang-jhrig entwickelte LB-Simulationscodes
vorlagen, die auf spezifische Anwendungsbe-reiche optimiert sind,
war es von Anfang an nicht geplant, im Rahmen des ProjektsSKALB
eine gemeinsame Codebasis zu schaffen. Vielmehr sollten die
bestehenden Si-mulationsprogramme so weiterentwickelt werden, dass
sie in ihrem jeweiligen Anwen-dungsbereich eine Spitzenposition
einnehmen, also eine wesentlich hhere Effizienz alsverfgbare
kommerzielle und akademische CFD-Software aufweisen, andererseits
aberauch die notwendige Flexibilitt und Robustheit hinsichtlich
industrieller Aufgaben-stellungen besitzen.
1.3 Planung und Ablauf des Vorhabens
Das Projekt SKALB wurde vom 1.1.2009 bis zum 31.12.2011 durch
das BMBF gefr-dert. Die Arbeiten gliederten sich in fnf
Arbeitspakete:
AP1: Portierung und Optimierung von LB-Applikationen auf massiv
paralleleHPC-Systeme (RRZE, LSS, iRMB, TUDo, HLRS)
AP2: Weiterentwicklung von LB-Methoden fr praktische Anwendungen
aufhochskalierenden Systemen (RRZE, LSS, iRMB, TUDo, HLRS)
AP3: Verbesserte numerische Anstze fr LB-Methoden (LSS, iRMB,
TUDo)
AP4: Hardwarenahe Implementierung fr Nicht-Standard-Prozessoren
(RRZE,LSS, iRMB, TUDo)
AP5: Benchmarking und Showcases (RRZE, LSS, iRMB, TUDo,
IANUS)
4
-
1.4 Wissenschaftlicher und technischer Stand, an den angeknpft
wurde
Die Gesamtkoordination des Projekts SKALB lag bei Prof. Wellein
vom RRZE an derFAU. An den meisten Arbeitspaketen waren alle
universitren Projektpartner beteiligt.Der fr ein Arbeitspaket
hauptverantwortliche Projektpartner ist in der obigen
Listehervorgehoben.
Das Ziel der Arbeitspakete AP1 und AP4 war es, numerische
Building Blocks zuerstellen und auszutauschen; ferner sollten
Kernelroutinen zum systematischen Testvon
Implementierungsalternativen und Skalierbarkeitseffekten entwickelt
und verwen-det werden. In den Arbeitspaketen AP2 und AP3 sollten
existierende Codes metho-disch und algorithmisch unter konsequenter
Bercksichtigung hoher Parallelisierungs-grade weiterentwickelt
werden. Die industrielle Relevanz der im Rahmen dieses Pro-jekts
entwickelten Lsungen sollte schlielich in Arbeitspaket AP5 unter
Federfhrungdes KMU-Projektpartners IANUS GmbH nachgewiesen
werden.
Die Vernetzung und Koordination innerhalb des Projekts erfolgte
ber gemeinsameProjekttreffen, Telefon- und Videokonferenzen sowie
Mailinglisten, Wikis und einenBSCW-Dokumentenserver, aber auch
durch koordinierte Konferenzteilnahmen.
Die Aussendarstellung erfolgte ber den Webauftritt www.skalb.de,
der die wesentli-chen Ziele und Arbeitsschritte des Projekts
darstellt und in weiten Teilen zweisprachig(deutsch/englisch)
ist.
1.4 Wissenschaftlicher und technischer Stand, an denangeknpft
wurde
Durch die amerikanische Firma EXA Corp. wird das kommerzielle
Produkt Po-werFlow vertrieben, das insbesondere in der
Automobilindustrie verbreitet eingesetztwird. Dieser LB-basierte
Lser zeichnet sich vor allem durch ein sehr anwenderfreund-liches
und automatisches Pre- und Postprocessing aus. Details der
methodischen, nu-merischen und algorithmischen Anstze sind jedoch
unbekannt.
Im Rahmen des englischen Reality-Grid-Projekts konnte eine
Gruppe um Prof. Cove-ney sehr erfolgreich und medienwirksam
hochskalierende LB-Simulationen (TeraGy-roid) demonstrieren und
hierbei auch ein rudimentres Computational Steering er-mglichen.
Wie auch bei einigen hochskalierenden Show-Cases der Antragsteller
desvorliegenden Projekts hat sich die Gruppe um Prof. Coveney auf
einfache Anstzekonzentriert und durch die bloe Menge an
Rechenleistung einen Rekord erzielt.
Palabos1 und das OpenLB-Projekt2 sind eine Gemeinschaftsarbeit
mehrerer internatio-naler Forschungsgruppen (v.a. Uni Genf, Uni
Karlsruhe und Tufts University). Palabosund OpenLB sind als
modulares, erweiterbares und plattformunabhngiges System
frLB-Simulationen konzipiert. Sie stellen eine gemeinsame Codebasis
fr Forscher dar,
1http://www.palabos.org2http://www.openlb.org
5
www.skalb.dehttp://www.palabos.orghttp://www.openlb.org
-
Kapitel 1 Kurze Darstellung des Projekts
die Forschungsergebnisse vergleichen und austauschen wollen und
bietet einige Werk-zeuge zur Vor- und Nachbehandlung von
Simulationsdaten. Dabei spielt die hochska-lierende
Parallelisierung und Performance-Optimierung fr verschiedene
Architektureneine untergeordnete Rolle.
Im Rahmen eines frheren BMBF-Projekts (HPSC) wurde die
Parallelisierung undOptimierung des am Fraunhofer-Instituts fr
Wirtschafts- und Technomathematik inKaiserslautern entwickelten
LB-Lsers ParPac vorangetrieben, so dass fr die dortanvisierten
Anwendungsbereiche (z.B. Gie- und Fllprozesse) ein marktreifer
deut-scher Produktionscode zur Verfgung steht.
Grundlage fr das Projekt SKALB waren die vier LB-Lser der
Projektpartner, dieim Folgenden genauer beschrieben sind.
1.4.1 Ausgangssituation VirtualFluids
Bei VirtualFluids des iRMB handelt es sich um einen
plattformunabhngigen 2D/3DLB-Code auf hybriden Gittern
(hierarchisch/blockstrukturiert), die durch Quad-/Octrees mit
uniformen Matrizen als Blttern und einem lokalen
Gitterlevelunterschiedvon eins realisiert sind. Der Code ist in C++
geschrieben, umfasste vor Projektbeginn2 135 Dateien und bestand
aus 300 000 Code-Zeilen und 100 000 Kommentarzeilen.
DerDesignansatz verfolgt folgende Konzepte:
Grtmgliche Generalisierung/Abstrahierung der
Algorithmen/Pakete/Modu-le u.a. durch generische Programmierung
(Gitter-/Strmungsanpassung mittelsStrategien: durch Verwendung von
Model-Traits gelten die Strategien immer fralle Modelle, wodurch
eine minimale Code-Redundanz erreicht wird).
Verallgemeinertes Kommunikationskonzept zur Minimierung von
Redundanzund Parallelisierungsaufwand bzgl. neuer numerischer
Kernel (Transmitter-Connector-Konzept).
Effizientes Mapping von Geometrien auf das Berechnungsgitter
mittelsRaytracing-Methoden und optimierter
Verschneidungsalgorithmen.
Austauschbare Kommunikationsmodule (MPI, RCF und JADE) fr die
paralleleBerechnung.
Adaptive Gitteranpassung.
1.4.2 Ausgangssituation waLBerla
Das waLBerla-Framework (widely applicable lattice Boltzmann flow
solver from Er-langen) des LSS stellte bereits zu Projektbeginn
einen parallelen 3D-LB-Lser mitflexibel anpassbarer Funktionalitt
fr verschiedene strmungsmechanische Anwen-dungen dar [FGD+07]. Es
sttzt sich dabei auf das D3Q19-Diskretisierungsschema,
6
-
1.4 Wissenschaftlicher und technischer Stand, an den angeknpft
wurde
nutzt verschiedene Kollisionsmodelle (BGK, TRT, MRT) und
untersttzt vielfltigeRandbedingungen, zeit- und ortsabhngige
Einflussbedingungen, Beschleunigung undDruckrandbedingungen. Der
C++-Code besitzt eine Programmierer-Dokumentationund ist
plattformunabhngig. Die Flexibilitt des Codes bezieht sich auf
verschiedeneGesichtspunkte:
Flexible Integration weiterer Anwendungen/Funktionalitten:Durch
ein Konzept zur Minimierung der Code-Redundanz, wie auch
generischeund objektorientierte Design-Patterns wird die einfache
Integration und Paralle-lisierung neuer Funktionalitt
ermglicht.
Flexible Spezialisierung von Funktionalitt zur
Effizienzsteigerung:Komplexe Funktionalitt wird nur dort genutzt,
wo sie auch bentigt wird.Durch generische Datenstrukturen, die das
kartesische LB-Gitter in hierarchi-sche blockstrukturierte
Unterregionen (Blcke) zerlegen, knnen rumlich limi-tierte Gebiete
mit verschiedener Funktionalitt ausgestattet werden. Dies
hatentscheidenden Einfluss auf die Recheneffizienz, da
algorithmischer Overheadweitgehend vermieden werden kann.
Flexibler Datenaustausch:Die Blcke dienen als Grundstruktur
neben der gebietsweisen Anpassung an diejeweilige Funktionalitt
auch zum parallelen Datenaustausch und als geplan-te Schnittstelle
fr heterogene Computerarchitekturen. Der gleiche Ansatz wirdauch
von TUDo verwendet. Bisher ist es nur mglich, uniforme Blcke
ohneGitterverfeinerung und mit statischer Funktionalitt zu
erzeugen, eine entspre-chende Erweiterung basierend auf der
Vorarbeit des iRMB ist geplant. Auch diefr die Parallelisierung
ntige Verteilung der Blcke auf Prozesse erfolgt derzeitstatisch. Da
die Implementierung der MPI-Parallelisierung es erlaubt,
gitterba-sierte Daten beliebigen Typs und beliebiger Gre zu
versenden, knnen nicht nuranwendungsspezifische LB-Daten versandt
werden, sondern auch ganze Blcke,um eine dynamische Lastverteilung
oder dynamische Vernderung anwendungs-spezifischen Funktion zu
realisieren. Die optimale Gre der Blcke dafr soll inZusammenarbeit
mit dem HLRS ermittelt werden (siehe Arbeitspunkt I.c).
Mit der bereits realisierten Funktionalitt war es mglich,
Strmungen in porsenMedien, Strmungsprobleme mit freien Oberflchen,
Diffusionsprobleme, partikelbe-ladene Strmungen
(Fluid-Struktur-Interaktion fr bewegte Starrkrper),
BrownscheMolekularbewegung (fluctuating LB) und Strmungen in
Blutadern zu simulieren.
1.4.3 Ausgangssituation ILBDC
Die beiden Rechenzentren, HLRS und RRZE, haben sich vor einigen
Jahren demInternational Lattice Boltzmann Development Consortium
(ILBDC) angeschlossenund sich darin speziell mit
Performanceaspekten und der Parallelisierung beschftigt.Der ab 2002
von Grund auf neu entwickelte ILBDC-Code wurde bereits in diver-sen
Forschungsprojekten (z.B. den FP6-Vorhaben @neurIST und COAST)
eingesetzt.
7
-
Kapitel 1 Kurze Darstellung des Projekts
Der ILBDC-Code basiert auf dem D3Q19-Modell in unterschiedlichen
Ausprgungen(LBGK, TRT und MRT). Erweiterungen fr nicht-newtonsche
Fluide (Carreau-YasudaModel), Turbulenzmodellierung (Smagorinsky
LES-Ansatz), Energietransport, Diffusi-on und geometrische
Randbedingungen zweiter Ordnung sind produktionsreif vorhan-den
oder in Arbeit. Lokale Gitterverfeinerung ist dagegen noch in der
Planungsphase.
Bei den Datenstrukturen wurde der strukturierte Ansatz
vollstndig aufgegeben, indemnur noch Fluidzellen und deren
Nachbarschaftsbeziehung abgespeichert werden. In die-ser Hinsicht
unterscheidet sich der ILBDC-Code grundstzlich von den
patchbasiertenLB-Implementierungen, die von den anderen Gruppen in
SKALB eingebracht werden.Bei hochkomplexen Geometrien bedeutet der
ILBDC-Ansatz natrlich eine signifikanteSpeicherersparnis, die
allerdings mit indirekten Feldzugriffen im Kernel erkauft wird.Das
Datenlayout kann je nach Rechenarchitektur gewhlt werden, um
beispielsweiseauf Datenlayoutebene bereits eine Cacheoptimierung zu
erreichen [WZDH06]. Durchden unstrukturierten aber dennoch auf
kartesischen Gittern basierenden Ansatz isteine sehr flexible
Gebietsaufteilung mglich [Zei08], die jedoch nur mit
zustzlichemAufwand dynamisch verndert werden kann.
1.4.4 Ausgangssituation FEAT* und FEAST*
Die numerischen und algorithmischen Vorarbeiten der AG Turek
(TUDo) lie-gen schwerpunktmig auf der Lsung der
Navier-Stokes-Gleichungen und sind imOpenSource-Strmungscode
FEATFLOW zusammengefasst. Sie zielen auf sehr leis-tungsstarke
hierarchische Mehrgitterlser und adaptive FEM-Diskretisierungen
frkomplexe Fluide ab und folgen modernen Pressure Schur Complement
Anst-zen [Tur99]. In einem weiten Bereich konnten so
Konfigurationen, die prototypisch frindustrielle Probleme sind, mit
hoher numerischer Effizienz und Robustheit erfolgreichgelst
werden.
Analog zu FEATFLOW wurde im Vorfeld prototypisch der LB-Code
FEATLBM ent-wickelt, der ebenfalls auf der Finite-Element
Basisbibliothek FEAT basiert. Mit derHilfe dieses Codes wurde
algorithmische Grundlagenforschung zur Behandlung der LB-Gleichung
betrieben, insbesondere mit modernen numerischen Verfahren fr
partielleDifferentialgleichungen (vollimplizite
Zeitschrittverfahren hoher Ordnung, unstruktu-rierte Gitter,
Krylow-Raum- und Mehrgitterverfahren, Newton-Lser zur Behandlungder
Nichtlinearitten etc.).
Parallel zu diesen eher mathematisch orientierten Codes wurde
das HPC-Paket FEASTentwickelt [Bec07], das die Flexibilitt,
numerische Leistungsfhigkeit und Robust-heit von FEAT und FEAT
-basierten Applikationen um Techniken der hardware-orientierten,
massiv parallelen Numerik [TBK06] erweitert. Als
Lsungsverfahrenkommt hierbei ein hocheffizienter ScaRC-Lser [KT98,
Kil01] als verallgemeinertesparalleles Mehrgitter-/
Gebietszerlegungsverfahren zum Einsatz.
8
-
1.5 Zusammenarbeit mit anderen Stellen
Mit dieser Ausgangssituation war es ein wesentliches Ziel
innerhalb von SKALB,diese numerischen und HPC-Komponenten als
Module fr ein neues OpenSource-Software-Framework, das sowohl die
numerischen Features von FEAT als auch dieHPC-Fhigkeiten des ersten
FEAST -Paketes hat, zusammen zu fhren. Des weite-ren sollte dieses
neue Framework als Komponenten weiterentwickelte Versionen
vonFEATFLOW und FEATLBM enthalten. Dieses neue Softwarepaket trgt
den tra-dierten Namen FEAST und beinhaltet dementsprechend die
Module FEASTFLOWund FEASTLBM, vergleiche Abschnitt 2.1.6.
1.5 Zusammenarbeit mit anderen Stellen
Die assoziierten Partner Intel, Cray und IBM sowie zustzlich
Fujitsu haben die Pro-jektarbeit durch Bereitstellung von
Early-Access-Testsystemen am RRZE sowie durchtechnischen Experten
nachhaltig gefrdert. NLE-IT hat bis zur Auflsung des
For-schungslabors in St. Augustin die Implementierung skalierbarer
LB-Algorithmen aktivbegleitet.
Die BASF AG hat einen industrierelevanten Anwendungsbenchmark
aus dem Bereichder chemischen Verfahrenstechnik gestellt, der in
AP5 von allen beteiligten Projekt-partnern intensiv bearbeitet
wurde. Der von der Sulzer Chemtech AG vorgeschlage-ne Benchmarkcase
konnte nicht untersucht werden, da fr die dabei zu
simulierendeMehrphasenstrmung umfangreiche physikalische
Modellentwicklungen ntig gewesenwren, die nicht Gegenstand des
Projekts waren.
Es wurde von Seiten der AG Turek (TUDo) mit dem SINTEF in Oslo
erfolgreich aneiner gemeinsamen Codeschnittstelle zum Vergleich von
LB-Codes gearbeitet.
Zum Intel Exascale Laboratory unter der Leitung von Prof. Jalby
an der UniversittVersailles Saint-Quentin-en-Yvelines bei Paris
konnte ebenso ein intensiver Kontaktaufgebaut werden, wie zu Prof.
Aoki vom Tokyo Institute of Technology, ber denauch Zugang zum
japanischen Tsubame-2.0 Supercomputer erhalten werden konnte.Jan
Treibig und Markus Wittmann vom RRZE haben mehrmonatige
Forschungsauf-enthalte in Versailles bei Prof. Jalby verbracht und
Christian Feichtinger (LSS) wirdin Krze eine PostDoc-Stelle bei
Prof. Aoki antreten.
Im Rahmen der Gau-Allianz stand das RRZE in regelmigem Kontakt
mit anderenGruppen bundesweit.
Ergebnisse aus dem Projekt SKALB sind in Blockkurse
eingeflossen, die das RRZEregelmig zusammen mit dem Leibniz
Rechenzentrum in Mnchen und dem Hchst-leistungsrechenzentrum in
Stuttgart durchfhrt.
9
-
Kapitel 1 Kurze Darstellung des Projekts
10
-
Kapitel 2
Eingehende Darstellung des Projekts
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
Die Zuwendung wurde verwendet, um Doktoranden und PostDocs in
den beteiligtenGruppen zu finanzieren, welche die LB-Codes der
jeweiligen Gruppen im Sinne desBMBF-Calls fr hochskalierende
HPC-Systeme weiterentwickelt haben. Die durchge-fhrten Arbeiten
gliedern sich in fnf Arbeitspakete, die von der Portierung und
Opti-mierung der Codes (AP1) ber algorithmische (AP2) und
methodische Weiterentwick-lungen (AP3) sowie die Nutzung
alternativer Hardware (insbesondere GPGPUs, AP4)bis hin zur
exemplarischen Anwendung auf industrierelevante Anwendungen (AP5)
rei-chen. In den folgenden Unterabschnitten wird auf die
durchgefhrten Arbeiten der ein-zelnen Arbeitspunkte genauer
eingegangen, wobei jeweils auch die ausfhrende Gruppeangegeben
ist.
Aufgrund des theoretischen und ergebnismigen Umfanges der
einzelnen Arbeitenwerden in den folgenden Abschnitten bei der
einzelne Arbeiten und Ergebnisse exem-plarisch herausgegriffen und
werden nher ausgefhrt. Weitergehende Informationenfinden sich in
den projektbezogenen Publikationen der Projektpartner, auf die
hufigverweisen wird.
2.1.1 AP1: Portierung und Optimierung von LB-Anwendungen auf
massivparallele HPC-Systeme
Portierung und Optimierung
Ziel von AP1 war es zunchst, die verwendeten Codes auf die
unterschiedlichen zur Ver-fgung stehenden HPC-Systeme zu portieren
und dort die Performance der in das Pro-jekt eingebrachten
LB-Applikationen zu optimieren. Neben lokalen HPC-Clustern
allerbeteiligten Einrichtungen und den Tier-1 Systemen an den
Bundeshchstleistungsre-chenzentren in Jlich, Mnchen und Stuttgart
standen ber die europischen Pro-jekte DEISA und PRACE zustzliche
Ressourcen bei CINECA in Italien, am EPCCin England sowie beim
Barcelona Supercomputing Center bereit. Hervorzuheben ist,dass auch
hochskalierende Systeme in den USA (z.B. am National Energy
Research
11
-
Kapitel 2 Eingehende Darstellung des Projekts
Scientific Computing Center (NERSC) in Berkeley) sowie eines der
grten GPGPU-Systeme (Tsubame 2.0 am Tokyo Institute of Technology)
fr Testlufe genutzt werdenkonnten.
Nach der Portierung wurden die unterschiedlichen Systeme sowohl
fr Skalierungs-und Benchmarkuntersuchungen aber auch im Rahmen
komplementrer Projekte frProduktionslufe verwendet. Als eines von
nur acht Teams wurde der LSS im Febru-ar 2010 mit waLBerla zum
Extreme Scaling Workshop nach Jlich eingeladen undhatte so die
Mglichkeit, Skalierungsmessungen und Programmoptimierungen auf
dergesamten Jugene (eine IBM Blue Gene/P mit knapp 300.000 Cores)
durchzufhren [9].Durch die Vorarbeiten im Rahmen von SKALB ist
davon auszugehen, dass der derzeitschnellste Rechner Deutschlands,
SuperMUC am LRZ, innerhalb krzester Zeit auchproduktiv genutzt
werden kann.
Die Portierung von FEAST durch TUDo auf die Cell-BE
Zielplattform nahm eineSonderstellung ein: Whrend andere
Portierungen lediglich minimale Manahmen er-forderten, war die
Entwicklung einer Laufzeitbibliothek zur Nutzung der SPEs
derCell-BE erforderlich. Zudem mussten von IBM extern
bereitgestellte Cell-Blades ver-wendet werden. Leider hat IBM
whrend der Projektlaufzeit bekanntgegeben, dass dieHardware der
Cell-BE nicht weiterentwickelt wird, so die Aktivitten in diesem
Bereichreduziert wurden. Im Rahmen der Forschung im Bereich
Unconventional HPC undEnergieeffizientes Rechnen hat TUDo dafr
zuletzt einen LB-Code der Arbeitsgruppeauf einen prototypischen
Cluster des Barcelona Supercomputing Center portiert, derauf
low-power ARM Kernen basiert.
Implementierungs- und Parallelisierungskonzepte,
Performance-Engineeringund Performancemodelle
Nach den Portierungen galt es, in einem zweiten Schritt, anhand
von berschaubarenBenchmark-Kerneln neue Implementierungs- und
Parallelisierungskonzepte zu evalu-ieren und durch einen
strukturierten Ansatzes fr das Performance-Engineering
berPerformancemodelle die zu erwartende Performance abzuschtzen und
das Optimie-rungspotential einzuschtzen.
Das RRZE hat sich auf die Aspekte Performancemodelle und
Performance-Engineering [10, 25] sowie die Implementierung
(einfacher) Benchmarkkernelmit SSE/AVX-Intrinsics fr x86_64-CPUs
[10] konzentriert. Wavefront- undMulti-Halo-Parallelisierungsanstze
wurden als spezielle Anstze fr Multi-Core-Implementierungen
untersucht [12, 21, 23, 24]. Mit optimierten Benchmarkkernelnkonnte
annhernd die durch die Performancemodelle theoretisch vorhergesagte
Per-formance erreicht werden. Die Benchmarkkernel wurden
anschlieend weiterentwi-ckelt und beispielsweise als Teil der
SPEC-OpenMP-Suite submittiert oder sind in dieBenchmarksuiten zur
Beschaffung von HPC-Systemen am RRZE und dem LRZ ein-geflossen. Die
Benchmarkkernel wurden aber auch in Produktionscodes bernommenund
erreichen sowohl im ILBDC als auch waLBerla annhernd die gleiche
Performance
12
-
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
Abbildung 2.1: Erzielte Performance in Abhngigkeit von der
gewhlten Implemen-tierung und der Zahl der verwendeten Kerne fr
Berechnungen indoppelter Genauigkeit.
wie in den eigenstndigen Benchmarkkerneln [5, 10, 22].
Ausgangspunkt fr jeglicheOptimierung muss auch im
Exascale-Zeitalter weiterhin der einzelne Kern und
einzelneRechenknoten sein. Abbildung 2.1 und 2.2 zeigen daher die
auf einem Single-Socket-System erzielte Performance in Abhngigkeit
von der gewhlten Implementierung undder Zahl der verwendeten Cores.
Mit optimierten Implementierungen (SIMD bzw. teil-weise auch SPLIT)
wird dabei bereits mit nur einem Teil der verfgbaren Kerne imKnoten
eine Sttigung der Performance erreicht, wobei die erzielte Leistung
nahe andie aufgrund der aggregierten Speicherbandbreite
vorgegebenen maximale Performan-ce heranreicht [10, 25]. Die
schlechte Skalierung innerhalb eines Knotens ist somitkein Zeichen
dafr, dass schlecht implementiert wurde, sondern fr genau das
Gegen-teil und die Unausgeglichenheit der Hardware mit hoher
Rechenleistung aber geringerSpeicherbandbreite. In der Praxis kann
die Tatsache, dass bereits wenige Kerne die ma-ximale
Anwendungsleistung auf dem Knoten erreichen, ausgenutzt werden,
indem mannicht bentigte Kerne in einen Schlafmodus versetzt und
somit den Stromverbrauchreduziert.
Vom LSS wurde ein Performancemodell fr den Kommunikationsaufwand
frStandard- und Nicht-Standard-Architekturen erstellt. Hiermit
konnte unter anderemdie zu erwartende Performance auf Tsubame 2.0
vorhergesagt und mit der gemessenenPerformance verglichen werden
[5]. Auftretende signifikante Abweichungen bei den ers-ten
Messungen konnten auf Hardwareprobleme zurckgefhrt werden, haben
aber auchdie Notwendigkeit der berlappung von Kommunikation und
Berechnung deutlich ge-macht [5], siehe auch Abbildung 2.3. Ferner
konnte der Overhead bei hybrider undheterogener Ausfhrung evaluiert
werden. Es hat sich gezeigt, dass es lohnenswert ist,
13
-
Kapitel 2 Eingehende Darstellung des Projekts
Abbildung 2.2: Erzielte Performance in Abhngigkeit von der
gewhlten Implemen-tierung und der Zahl der verwendeten Kerne fr
Berechnungen ineinfacher Genauigkeit.
GPGPUs nicht nur im Accelerator Mode zu betreiben, sondern die
Rechenleistungder CPU-Kerne im Knoten auch mitzubenutzen.
Durch Kernel-Prototypen fr parallele Programmiermodelle wurden
von TUDo ins-besondere im Bereich von Basiskerneln
(SIMD/Multi-Core) [33, 37, 48], aber auchbei Gebietszerlegungs- und
parallelen Mehrgitterverfahren weitreichende Ergebnisseerzielt
[3436, 39, 40, 49, 50]. Basierend sowohl auf OpenMP, als auch auf
PThreadswurden LBM- und FEM-Kernel portiert, optimiert und
evaluiert [33, 37, 48]. Fernerwurden die in FEAST eingesetzten
SBBLAS-Bibliotheken fr effiziente numerische li-neare Algebra vor
dem Hintergrund des Einsatzes Finiter Elemente hherer Ordnungsowie
nicht konformer Finite Element Rume erweitert und evaluiert.
Von TUDo wurden auerdem in den Bereichen hybride Ausfhrung,
Laufzeitumge-bungen und Softwaretechnik substantielle Fortschritte
erzielt: [3337, 48]
Es wurden sehr erfolgreiche Softwarebibliotheken fr die hybride
Ausfhrung(MPI in Verbindung mit OpenMP/PThreads oder GPGPU
(beispielsweiseCUDA oder OpenCL) ) fr FEAST entwickelt.
Laufzeitumgebungen fr die Speicherkonsistenz, das
Job-Scheduling, RTTI frdie Cell-BE, und Speichertransfers bei
Einsatz von GPGPUs und hybrider Aus-fhrung wurden entwickelt und
finden inzwischen Einsatz in FEAST.
Fr geometrische Mehrgittermethoden wurden neuartige
Funktor-basierte Ope-ratorketten entwickelt, die innerhalb des
Lsungsvorgangs Rekursionen minimie-ren sollen.
14
-
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
Abbildung 2.3: Heterogene Weak-Skaling-Performance von waLBerla
auf bis zu1029 GPGPUs des Tsubame 2.0-Clusters. Die blaue Kurve
ent-hlt keine berlappung von Berechnung und Kommunikation.
Durchexplizite berlappung wird eine signifikante
Performancesteige-rung erreicht (magenta Kurve), die sehr nahe an
die extrapo-lierte Kernel-Performance einer GPGPU herankommt
(gestrichelteschwarze Kurve).
Fr die numerische lineare Algebra (vormals SBBLAS) von FEAST
wurde einFrontend entwickelt, das die Applikationsentwicklung/
-anpassung insofern er-leichtern soll, als dass es die Vorzge von
C++ Operator-Overloading mit per-formanter kernelbasierter
Ausfhrung kombinieren kann (hardware-orientierteExpression
Templates).
Die Nutzung hybrider Programmiermodelle (insbesondere OpenMP+MPI
aber auchCPU+GPGPU) hat sich bei allen SKALB-Gruppen insgesamt
bewhrt. PGAS-Sprachen wie UPC oder Co-Array Fortran stecken dagegen
noch in den Kinderschu-hen und sind (noch) keine Alternative zu
MPI. Insbesondere ist ein MPI-artiger Pro-grammieransatz mit
expliziter Gebietszerlegung und HALO-Austausch ntig, um
mitPGAS-Sprachen eine mit MPI vergleichbare Performance zu erzielen
[19, 63].
Die sogenannte Adaptive Data and Communication Library (ADCL),
die von derUniversitt Houston und dem HLRS entwickelt wird und zur
Laufzeit die optimaleWahl des zu verwendenden
MPI-Kommunikationsschemas treffen soll, wurde am HLRSevaluiert. Da
fr die untersuchte Lattice-Boltzmann-Applikation kein signifikanter
Ge-
15
-
Kapitel 2 Eingehende Darstellung des Projekts
winn festgestellt werden konnte, wurden diese Arbeiten im Rahmen
von SKALB nichtweiter verfolgt.
2.1.2 AP2: Weiterentwicklung von LB-Methoden fr
praktischeAnwendungen auf hochskalierenden Systemen
Datenstrukturen
Die Performance von LB-Anwendungen ist meist durch die
Speicherbandbreite be-schrnkt. Grundstzlich sind verschiedene
Datenstrukturen denkbar und in der Lite-ratur auch verffentlicht,
um einerseits den Gesamtdatenumfang zu minimieren undandererseits
die Anzahl der Speicherzugriffe zu minimieren. In diesem Kontext
wur-de vom iRMB ein neues Verfahren entwickelt, welches als
Esoteric Twist bezeichnetwird. Dieses ermglicht die Verwendung von
einem Datensatz fr die Speicherungder Verteilungen (in den meisten
Implementationen werden zwei Felder verwendet,was zu einer
Verdoppelung des Speicherbedarfs der Simulation fhrt). Hinzu
kommtdie Vereinigung des Kollisions- und Propagationsschritts.
Insgesamt wird die Mengeder Speicherzugriffe pro Berechnungsschritt
signifikant reduziert. Ein entscheidenderVorteil von Esoteric Twist
liegt darin, dass man nur einen Verteilungssatz verwendetund die
Gitterknoten trotzdem unabhngig voneinander (parallel) bearbeitet
werdenknnen. Weiterhin wurde vom iRMB eine kompakte Randbedienung
zweiter Ordnungentwickelt, die fr das Esoteric Twist-Verfahren
besonders geeignet ist. Die Randbe-dingung ist gut fr parallele
Anwendungen geeignet, weil sie ein sehr lokales Verfahrendarstellt,
das keine Informationen von Nachbarknoten bentigt.
Sowohl waLBerla als auch VirtualFluids verwenden Blcke,
Untergebiete der Simulati-onsregion, als grundlegende Datenstruktur
zur Gebietszerlegung. Es kann ein Block proProzess verwendet werden
oder fr Lastbalancierungszwecke mehrere Blcke pro Pro-zess (Abb.
2.4). Darber hinaus bietet die Block-Datenstruktur weitere
Funktionali-tt, z.B. die lokale Anpassung der Simulationsdaten an
unterschiedliche Architekturen,Speicherlayouts und physikalische
Funktionalitt. In VirtualFluids werden Blcke insogenannten Patches
organisiert (Abb. 2.5). Unterschiedliche Adaptivittslevel
werdendurch die hierarchische Anordnung der Patches ermglicht.
waLBerla organisiert dieBlcke in einer Octree-hnlichen
Datenstruktur (Abb. 2.6), um Adaptivitt zu unter-sttzen. Weiterhin
knnen Blcke in waLBerla in nicht-uniforme Sub-Blcke
unterteiltwerden, um heterogene Rechenknoten abzubilden. Hierbei
entspricht jeder Sub-Blockeiner heterogenen Hardwareeinheit, z.B.
ein Rechenknoten mit zwei CPU-Sockeln unddrei GPGPUs allokiert fnf
Sub-Blcke pro regulrem Block, und ermglicht die sta-tische
Lastbalancierung trotz der unterschiedlichen Rechenleistung der
heterogenenHardwareeinheiten. Des weiteren wurden Datenstrukturen
fr massive parallele drei-dimensionale Simulationen auf
GPGPU-Clustern entwickelt. Hierzu werden Puffer aufSeiten der
GPGPUs verwendet, um die Daten zunchst zu aggregieren und dann
mitHilfe von einem einzigem PCI-Express-Transfer zum Host zu
kopiert. Diese Daten-strukturen ermglichen massive parallele
adaptive dynamisch lastbalancierte Simula-
16
-
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
Abbildung 2.4: Gebietszerlegung in Blcke.
tionen auf Standard- wie auch auf Nicht-Standard-Architekturen,
das berlappen vonBerechnung mit Kommunikation und MPI-, hybride
oder heterogene Parallelisierungs-anstze.
Gebietszerlegung und dynamische/adaptive Lastbalanzierung
Beim ILBDC erfolgt der Zugriff auf die Zellen indirekt ber eine
Adjazenzliste (Abbil-dung 2.7). Lediglich Fluidzellen werden
allokiert und in einem 1-D Array gespeichert.Durch den Prprozessor
wird diese Liste auf skalierbare Weise parallel erzeugt,
wasvollstndig entkoppelt von der spteren Strmungssimulation
erfolgt, wobei allerdingsdie Reihenfolge der Fluidzellen die
Performance der Strmungsimulation beeinflusst.Eine Art
Cacheblocking kann bereits im Prprozessor-Schritt erfolgen, ohne
dass nde-rungen im Strmungslser ntig sind [28]. Zur Anordnung der
Zellen im Array wurdendiskrete raumfllende Kurven, wie die Z-Kurve,
aber auch die lexikographische Sor-tierung mit Blocking untersucht
(Abbildung 2.8), wobei letztere Variante die bestenErgebnisse
erzielt. Jedoch ist der richtige Blockingfaktor a priori schwer zu
bestimmenund wird deshalb per Autotuning ermittelt [26]. Aufgrund
der gewhlten Daten-struktur und der indirekten Adressierung der
Fluidzellen ber die Adjazenzliste isteine dynamische Anpassung zur
Laufzeit nicht leicht mglich.
In VirtualFluids wurde eine serviceorientierte
Master-Slave-Architektur durch ein neu-es Parallelisierungskonzept
basierend auf einem dezentralisierten Verfahren inklusiveeiner
Multi-Core-Untersttzung implementiert. Ein MPI-Prozess wird dabei
als multi-threaded betrachtet, wobei die Anzahl der Threads der
Anzahl der Prozessorkerne ent-spricht. Ein Patch wird im ersten
Schritt entsprechend der Anzahl der MPI-Prozessezerlegt. Dann
werden die Blcke, die zu einem MPI-Prozess gehren, gleichmig
zwi-schen Berechnungsthreads verteilt. Ein dedizierter Thread pro
CPU-Knoten ist fr die
17
-
Kapitel 2 Eingehende Darstellung des Projekts
Abbildung 2.5: Datenstrukturen fr hochparallele,
dynamisch-adaptive Simulatio-nen basierend auf Blcken. Blcke
speichern Simulationsdaten undauch Zusatzinformationen fr die
Parallelisierung. Fr adaptive Si-mulationen werden Blcke in Patches
zerlegt, welche hierarchisch an-geordnet sind. Jede Patchebene
entspricht einem Adaptivittslevel.Blcke eines Patches knnen auf
mehrere MPI-Prozesse aufgeteiltwerden.
MPI-Kommunikation zustndig. Ferner wurde die Bibliothek Zoltan
integriert, welchedie Partitionierung und dynamische
Lastbalanzierung realisiert. Das ermglicht dieVerwendung
verschiedener Partitionierer, z.B. fr geometriebasierte oder
graphen-/,hypergraphenbasierte Gebietszerlegung, sowie Migration
der Daten nach der Partitio-nierung. Ein weiterer Vorteil von
Zoltan ist die Untersttzung paralleler Partitionie-rung, welche die
Basis fr die Verfahren der dezentralisierten Parallelisierung
darstellt.Fr die Zerlegung auf Interthreadebene wurde eine schnelle
und effektive Alternativeder graphenbasierten Partitionierung
entwickelt, die auf einem Priority Queue Algo-rithmus basiert. Die
Blcke haben verschiedene Gewichtungen, die der Anzahl voninneren
und ueren Kommunikationskanlen entspricht. Nach diesen
Gewichtungenwerden die Blcke mglichst gleichmig zwischen Threads
verteilt.
Zur dynamische Lastbalancierung wurde sowohl in VirtualFluids
als auch waLBerlaeine Methode fr massiv parallele und heterogene
Umgebung implementiert, die aufeinem erweiterten verteilten
Diffusionsalgorithmus basiert. Die Initialzerlegung wird
18
-
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
Abbildung 2.6: Gebietszerlegung in waLBerla mittels
Octree-Datenstrukturen. Je-der Block enthlt gleich viele Zellen.
Zur dynamischen Lastbalanzie-rung werden Blcke je nach ihrer Last
auf die MPI-Prozesse verteilt.In der Abbildung ist dies schematisch
fr vier MPI-Prozesse gezeigt.
mittels einer statischen Partitionierung im Prprozessor
durchgefhrt, um bessere Be-dingungen fr eine schnellere Konvergenz
der Lastverteilung, zu erhalten. Zur Simu-lationszeit wird die Last
fr jeden Prozess ausgerechnet. Die berbelasteten Prozesseschicken
einen Teil ihrer Last zu weniger belasteten Nachbarprozessen. Bei
der Last-verteilung wird bercksichtigt, dass die Kontaktoberflchen
zwischen den Nachbarpro-zessen immer minimal bleiben.
Ein wesentlicher Bestandteil der an der TUDo entwickelten
Ergebnisse bezieht sich aufdie Diskretisierung und die
Lastbalancierung von FEAST vor und whrend des (par-allelen)
Lsungsvorgangs. Dabei ist ein auf einer Mischung aus
Gebietszerlegung undMehrgitterverfahren basierendes System
zugrundegelegt, wobei die einzelnen Teilgebie-te zu Clustern (so
genannter Matrixpatches) zusammengefasst werden knnen.
Schwie-rigkeiten dabei sind die lokal durchaus sehr
unterschiedlichen numerischen Erforder-nisse, die ein hohes Ma an
Flexibilitt verlangen. Beispielsweise mssen strukturierteund (im
Fall von LBM insbesondere ungewhnliche) unstrukturierte Gitter
zuzglichentsprechender Adaptivittsanstze und eine Vielzahl von
Datenstruktur-Operationenuntersttzt werden. Gleichzeitig mssen
statisches und dynamisches Loadbalancinguntersttzt werden.
Entsprechende Datenstrukturen wurden im Rahmen von
SKALBentwickelt.
Preprocessing und Visualisierung
Am HLRS wurde ein SMP-paralleler Voxelizer entwickelt, der neben
der Diskretisie-rung eines Objekts durch Voxel auch die sogenannten
q-Werte zur besseren Ap-proximation des Randes [BFL01] berechnet.
Zudem wurde ein Ansatz verfolgt, derauf cad2octree und OpenCascade
basiert. Cad2octree ist hervorgegangen aus einerDiplomarbeit an der
Universitt Stuttgart (http://cad2octree.berlios.de/),
undOpenCascade (http://www.opencascade.org/) ist OpenSource. Der
Ansatz basiert
19
http://cad2octree.berlios.de/http://www.opencascade.org/
-
Kapitel 2 Eingehende Darstellung des Projekts
N NE SW N SW SW N NE SW
N NE SW N SW NE N NE SW
solverpreprocessor
rank 0 rank m
(a) (b) (c)
1
n
2
N NE SW
neighbors#
1 2 n
pd
fsa
dj.
lis
t
adjacency list
SWrank 0 rank 2rank 1
rank 3 rank 4 rank 5
0 0
1
2
Nf
0
0 0
3
4
0
In
In+1On
On+1
5
6
7
8
Abbildung 2.7: Durch den Prprozessor wird das Simulationsgebiet
geometrisch zer-legt und die resultierenden Partitionen werden
Prozessen zugewie-sen (a). In diesem Fall wird eine
lexikographische Sortierung mitBlockingfaktor 3 verwendet, um die
Adjazenzliste (b) der Fluidzel-len (weie Zellen) aufzustellen. Dazu
erhalten die Fluidzellen einenglobal eindeutigen und
kontinuierlichen Index, der die Feststoffzellen(dunkle Zellen mit
Index 0) auslt. Vom Strmungslser wird dieseListe in gleich groe
Stcke zerlegt, so dass jeder Prozess gleich vieleFluidzellen
besitzt (c). [26]
auf einer hierarchischer Diskretisierung und wurde in einem
hybrid-parallelen Pro-gramm realisiert, womit mehrere zehn
Millionen Voxel verarbeitet werden knnen. Dievoxelisierten Daten
wurden von diversen Gruppen erfolgreich fr die Simulation
derBASF-Geometrie aus AP5 verwendet.
Der Aspekt der Visualisierung wurde primr ebenfalls am HLRS
bearbeitet. Zum einenwurde das Computational-Steering-Framework
Steereo1 im Rahmen von SKALB u.a.um ein Fortran-Interface erweitert
und die parallele Skalierbarkeit konnte verbessertwerden. Von den
LB-Codes aus SKALB wurde der ILBDC-Solver erfolgreich in
dasSteereo-Framework integriert. Zum anderen wurde die am HLRS
entwickelte und vonVisenso GmbH vertriebene Visualisierungssoftware
COVISE angepasst, da der in AP5bearbeitete BASF-Showcase aufgrund
seiner Gre zunchst nicht visualisiert werdenkonnte. Die Daten
werden nun auf einem vereinfachten Gitter dargestellt, welches
dasDatenaufkommen soweit reduziert, dass mehrere Partitionen und
mehrere Zeitschrittevisualisiert werden knnen.
Von TUDo wurde ein auf OpenGL- und Qt-basierender Visualisierer
zur 3D-Datenvisualisierung und Echtzeitdarstellung von
Zeitschrittverfahren entwickelt, derin Lehrveranstaltungen
verwendet wird. Ansonsten haben die meisten Gruppen dieAnbindung
ihrer LB-Solver an die OpenSource-Visualisierungssoftware ParaView
ver-bessert.
1http://steereo.hlrs.de/
20
http://steereo.hlrs.de/
-
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
blk
. =
100
blk
. =
50
blk
. =
35
blk
. =
27
blk
. =
25
1 8 16 32 64nodes
0
500
1000
1500
2000
2500
3000
3500
4000
per
form
ance
[M
FL
UP
/s]
lex. ordering, blk. = 1
lex. ordering, blk. = 50
lex. ordering, best blk.
Z curve, 1 bitZ curve, 2 bitMetis, k-way
PT-SCOTCH, FN
Abbildung 2.8: Strong-Scaling eines Festbettreaktors der Gre 500
100 100Zellen mit ungefhr 2,1 106 Fluidzellen auf 1 64
Westmere-Rechenknoten (12 MPI-Prozesse pro Knoten). Als
Nummerierungs-chemata wurde eine lexikographische Sortierung mit
Blocking unddie diskrete Variante der raumfllenden Z-Kurve (1 und 2
Bit) ver-wendet, sowie die Graphpartitionierer METIS und PT-SCOTCH
[26].
2.1.3 AP3: Verbesserte numerische Anstze fr LB-Methoden
AP3 wurde primr von TUDo und iRMB bearbeitet. Einzelne
Ergebnisse (z.B. hin-sichtlich Adaptivitt) wurden insbesondere vom
LSS verwendet und prototypisch inwaLBerla umgesetzt.
Zentral fr die Arbeiten der TUDo in diesem Arbeitspaket war die
Auslotung derMglichkeiten der Anbindung der LBM an modernste
Methoden der numerischenMathematik (z.B. hierarchische
Mehrgitterlser auf adaptiven Rechengittern). Dazumuss man die
LB-Gleichung als PDE auffassen und dann entsprechend (ohne die
derklassischen LBM zugrunde liegende Partikel-Gasdynamik) in Ort
und Zeit diskreti-sieren. Dazu wurde ein vollimpliziter Ansatz
entwickelt (FEASTLBM ) [41, 42]. DieShort-Characteristic Upwind
Diskretisierung von 1. und 2. Ordnung wurde in
einerGEF-Formulierung der Lattice-Boltzmann-Gleichung (diskretes
Geschwindigkeitsmo-dell) eingesetzt und effiziente Lsungsmethoden
wurden in diesem Rahmen untersucht.Speziell wurde ein
Mehrgitter-Lser entwickelt, der einen effizienten
monolithischenZugang fr stationre Probleme ermglicht. In FeatLBM
wurden effiziente und stabileZeitdiskretisierungen bis zu zweiter
Ordnung fr zeitabhngige Probleme eingesetztund Resultate fr den
instationren Benchmark (Umstrmter Zylinder) erreicht, wo-bei
Referenzwerte fr Drag und Lift mit grosser Zeitschrittwahl (t =
0.01) akkuratreproduziert wurden.
Wesentliche Komponenten impliziter Lserpipelines sind
geometrische Mehrgitterme-thoden und starke Gltter fr
unstrukturierte Gitter, die auch mit moderner Beschleu-
21
-
Kapitel 2 Eingehende Darstellung des Projekts
nigerhardware (wie GPGPUs) vertrglich sein mssen: Als
grundlegende Komponentedes Lsungsvorgangs in FEAST (und damit fr
FEASTLBM ) wurden die auf FiniteElemente Methoden zugeschnittenen
Mehrgitterlser fr unstrukturierte Gitter (FE-gMG) insbesondere im
Hinblick auf moderne Beschleuningerhardware wie GPGPUsneu
konzipiert. In diesem Teilprojekt vereinen sich drei wesentliche
Aspekte: (1) Dienumerische Effizienz von Mehrgittermethoden selbst
und starker Glttungsoperato-ren, (2) die Hardwareeffizienz
angepasster Komponenten (s.u.) und (3) die
Flexibilittunstrukturierter Gitter [3436].
Innerhalb dieser Mehrgitteroperatoren kommen hochoptimierte
Basiskomponentenzum Einsatz. In diesem Fall sind dies effiziente
SparseMatrix-Vector Produkte (SpMV)fr FE-gMG. Alle Komponenten der
oben beschriebenen Mehrgitteroperatoren konn-ten als Kette von SpMV
ausgedrckt werden. Diese grundlegende Operation wurdeim Hinblick
auf die Hardwareeffizienz (CPU/SSE und Multi-Core sowie
insbesondereGPGPU) auf den neuesten Stand der Technik gebracht
[3436].
Eingebettet werden die lokalen Mehrgittermethoden in das FEAST
-Paket ber denparallelen ScaRC (scalable recursive clustering)
Lser. Dieser parallele lineare Lsungs-prozess in FEAST, fr den die
weiter oben beschriebenen FE-gMG lokale Lser sindund der die
beschriebenen Datenstrukturen und Lastverteilungskomponenten
verwen-det, wurde ebenfalls weiterentwickelt [49, 50].
Zustzlich zu den alternativen numerischen Zugngen und den
zugehrigen Operatorenund Datenstrukturen ist ein wesentlicher Teil
der Projektarbeit in die Entwicklungvon Hardware-orientierten
Standard-LBM und Anwendungen fr komplexe gekoppelteSysteme
geflossen. Es wurde ein komplettes Framework fr Standard-LBM
entwickelt,auf alle betrachteten Hardwareplattformen portiert,
optimiert und evaluiert [33, 37,48]. Neben einfachen
Flachwassersimulationen ist dieses in ein Modul von
FEASTintegrierte Framework auch in der Lage, schwierige gekoppelte
Physiksimulationendurchzufhren.
Ebenfalls zentral fr FEAST sind die verschiedenen
Adaptivittsanstze, die im Rah-men von SKALB hinzugefgt und
evaluiert wurden. Hier wurden zwei verschiedeneAnstze umgesetzt. In
2D wurde die Gitterdeformation kombiniert mit konformen,lokalen
Verfeinerungen (h-Adaptivitt). In 3D verwenden wir reine
Gitterdeformationzur Konzentration der Gitterpunkte unter
Beibehaltung der logischen Struktur desGitters (r-Adaptivitt). Die
logische Struktur des Gitters (Nachbarschaften zwischenKnoten) wird
beibehalten, lediglich beispielsweise um die Hlle des Modells
werdendie Knoten zusammengezogen, um die Genauigkeit und die
Auflsung zu erhhen. Eswurden bei beiden eingesetzten Techniken
Gitterdeformation kombiniert mit konfor-men, lokalen Verfeinerungen
in 2D bzw. reine Gitterdeformation in 3D wesentlicheFortschritte
erzielt. Es konnte beispielsweise gezeigt werden, wie und bis zu
welchemGrad die numerischen Ergebnisse von Simulationen mit
konformen Verfeinerungen desGitters verbessert werden knnen. Es
konnte insbesondere gezeigt werden, dass beimanchen Problemen bei
nicht ausreichender Auflsung bzw. ohne adaptive Verfeine-rung der
Fehler signifikant steigt (beispielsweise durch Nachweis des
Ausbleibens vonDiffusion, vergleiche insbesondere Zwischenbericht
3).
22
-
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
Datenreduktion Die kontinuierlich steigende Leistungsfhigkeit
von Hochleistungs-rechnern ermglicht auch im Bereich numerischer
Strmungssimulationen immer gr-ere Systeme und bedingt damit
gleichzeitig ein stetiges Wachstum der Ergebnisda-tenstze. Schon
heute umfasst die Gre dieser Daten leicht mehrere TeraBytes undes
ist abzusehen, dass schon bald die PetaByte-Grenze berschritten
werden wird.Die Verarbeitung und Analyse dieser kontinuierlich
wachsenden Datenmengen stelltsowohl fr traditionelle, im
Post-Processing-Verfahren arbeitende Simulationssystemeals auch fr
interaktive Anstze eine zunehmend schwierigere Aufgabe dar. Ein
ty-pischer Ansatz zur Balancierung besteht darin, die Analyse des
Ergebnisraums aufeinen Ausschnitt zu begrenzen (Cropping) und/oder
die Ergebnisse zeitlich und rum-lich auszudnnen (Subsampling). Im
Rahmen des Projektes wurde vom iRMB einLsungsansatz verfolgt, der
in erster Linie eine gngige Limitierung sowohl frei verfg-barer als
auch kommerzieller Visualisierungsumgebungen adressiert. Viele der
durch-aus populren Post-Processing-Systeme wie beispielsweise
ParaView und AVS stoenbei der Verarbeitung von Massendaten schnell
an Ressourcengrenzen, da sie stets undausschlielich vollstndige
Datenstze einlesen und im Speicher vorhalten. Im Projekt-verlauf
wurde vom iRMB ein Format fr den Datenaustausch zwischen
Simulationund Visualisierungsumgebung auf Basis von HDF5
spezifiziert, mit dessen Hilfe einea priori-Datenreduktion
realisiert wurde, die nicht mehr alle Daten zum Beginn
derVisualisierung einliest.
2.1.4 AP4: Hardwarenahe Implementierung fr
Nicht-Standardprozessoren
In diesem Bereich wurden vorrangig GPGPU-Implementierungen
entwickelt. Dabeiunterschied sich der Fokus der beteiligten Gruppen
zum Teil erheblich. Whrend TU-Do vorrangig fr das Softwareprodukt
FEAST die FE-Kernel auf die GPGPU portiertund neue
FEM-LB-GPU-Kernel entwickelte, hat sich das RRZE auf die
Entwicklungvon hochoptimierten D3Q19-LBM-GPGPU-Kerneln konzentriert
[10]. Weiterhin wur-de der Einfluss des ECC auf Performance und
Datenstrukturen untersucht, da vorallem die LBM uert sensibel
darauf reagierte. Die RRZE Kernel wurdem dem LSSzur Verfgung
gestellt und in enger Zusammenarbeit in das Softwareprodukt
waLBerlaintegriert. Der LSS hat seinerseits diese Kernel fr die
Entwicklung massiv parallelerLB-Simulationen mit Hilfe von
pure-MPI, hybriden- und heterogenen Parallelisierungs-anstzen
benutzt. Diese wurden im weiteren Verlauf des Projektes fr
entsprechendeBenchmarks und Performance-Modellierungen von
Multi-GPGPU Simulationen aufuniformen Gittern verwendet [5]. Der
Fokus des iRMB lag weniger auf der reinenPerformance-Optimierung,
sondern strker auf der Weiterentwicklung der Methoden.So wurden
ergnzend zum D3Q19-Modell, welches von den Partnern favorisiert
wur-de, auch ein D2Q9-CLB (cascaded lattice Boltzmann) und ein
D3Q27-CLB-Modellentwickelt. Diese ermglichen Simulationen von
turbulenten Strmungen ohne expli-zite Turbulenzmodellierung, bei
denen die laminaren LB-Modelle der Partner nichtmehr eingesetzt
werden konnten. Abgesehen davon war es zu Beginn des Projektesbei
allen Partnern blich, zwei volle Verteilungsstze auf den GPGPUs zu
verwenden,um einen thread-sicheren Programmablauf zu gewhrleisten.
Das iRMB entwickelte im
23
-
Kapitel 2 Eingehende Darstellung des Projekts
CUDA OpenCL CUDA padded OpenCL padded0
50
100
150
200
250
300
350
400
per
form
ance
[M
FL
UP
/s] sp
dpTESLA C2070
Abbildung 2.9: Performancevergleich zwischen der CUDA- und
OpenCL-Implementierung in waLBerla auf einer NVIDIA Tesla
C2070GPU.
Projektverlauf eine neue Datenstruktur bzw. eine neue Form des
Speicherzugriffs mitdem Namen EsoTwist. Bei vergleichbarer
Performance ermglicht diese eine Halbie-rung des zu allokierenden
Speichers auf der GPGPU, da sie mit einem Satz an
Ver-teilungsfunktionen auskommt. Das RRZE hat diese neue Methode
mit einer bereitsverffentlichten Methode von Bailey [BMW+09] und
einigen anderen teilweise nur frCPUs geeigneten Methoden verglichen
[25]. Das iRMB hat fr Testflle mit dnn-bestzten Geometriematrizen
bzw. mit einem hohen Solid-Anteil eine Implementierungmit
indirekter Adressierung auf der GPGPU entwickelt. Diese
funktioniert im Vergleichzum Matrix-Code ohne signifikanten
Performanceverlust und erzielt (abhngig von derTestfallgeometrie
eine erhebliche Ersparnis bzgl. des erforderlichen
GPGPU-Speichers.Fr realittsnahe CFD-Testflle ist Gitterverfeinerung
in Ortsbereichen hoher Gra-dienten notwendig. Whrend der
Projektphase entwickelte das iRMB eine
kompakteInterpolationsmethode zweiter Ordnung, die auf GPGPUs mit
sehr guter Performanceund Ergebnisqualitt funktioniert. Diese
Eigenschaften waren der Grund, warum dieseMethode im weiteren
Verlauf sogar fr die CPU-Codelinie implementiert wurde.
Esentstanden Versionen fr das D2Q9-, D3Q19- und das D3Q27-Modell.
Selbstverstnd-lich funktioniert die Interpolation auch in
Kombination mit dem vorgestellten EsoTwistund der indirekten
Adressierung. Analog zu der performanceoptimierten
Multi-GPU-Implementierung des LSS wurde auch vom iRMB eine Version
mit dem Fokus aufturbulente Probleme implementiert und auf dem
whrend der Projektphase beschaff-ten Cluster Ludwig mit bis zu 96
GPGPUs validiert. Diese Multi-GPGPU-Versionwurde erfolgreich fr die
Simulation des BASF-Bechmarks verwendet.
Das RRZE hat OpenCL als alternative Programmierschnittstelle zum
CUDA-Framework getestet und konnte damit in waLBerla vergleichbare
Performanceergeb-nisse erzielen (Abb. 2.9).
24
-
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
Implementierungen auf Nicht-Standardprozessoren beschrnkten sich
im SKALB-Projekt aber nicht auf GPGPU-Entwicklungen. TUDo hat einen
FEM-LBM-Code ausFEAST sowohl fr die ARM-Architektur portiert als
auch fr den Cell-BE Prozessorimplementiert.
2.1.5 AP5: Benchmarking und Showcases
Benchmarks
In enger Zusammenarbeit mit TUDo wurden von IANUS zwei
Benchmarks erarbeitet,die gem der Vorgaben in AP5 zur Anwendung
kommen sollen. Die Anforderungen andie Benchmarks wurden aus zwei
unterschiedlichen Sichtweisen heraus definiert. Ausder akademischen
Sicht sollten prototypische Benchmarks bzgl. Geometrie und
mathe-matischer Modellierung einfach zu definieren aber komplex in
ihrer Ausprgung sein.Aus Sicht der Industrie mssen die aus den
Benchmarks erarbeiteten Resultate abermehr als nur akademische
Fragen beantworten und dabei helfen, technische Problemebesser zu
verstehen.
Flow around a cylinder in 3D Der flow around a cylinder
Benchmark stellt ein in-stationres Strmungsproblem in einer
vergleichsweise einfachen Geometrie dar. DieserBenchmark beschftigt
sich mit der Umstrmung eines zylindrischen Hindernisses ineinem
Strmungskanal mit rechteckigem Querschnitt. Das flieende Medium ist
ein-phasig und wird durch die inkompressiblen
Navier-Stokes-Gleichungen beschrieben.Die Umstrmung des
Hindernisses fhrt zu einer instationren Ausprgung der Str-mung.
Studiert werden kann in diesem Benchmark der Einfluss der
Reynoldszahl aufdie qualitative und quantitative Ausprgung der
Strmung. Als makroskopische Ver-gleichsgren eigenen sich z.B. die
zeitabhngige Ausprgung von drag und lift alsresultierende
Druckkraft auf den Zylinder. Whrend die Problemstellung fr den
2DFall als gelst gelten kann, ist die Berechnung des vollen
dreidimensionalen Falls im-mer noch eine Herausforderung. Mit Hilfe
von FEATFLOW wurden erst krzlich sehrhochaufgelste dreidimensionale
Berechnungen durchgefhrt und gegen Berechnun-gen mit CFX und
OpenFOAM verglichen [BMT11]. Die Ergebnisse des Benchmarkserlauben
einen Vergleich der LB-Codes untereinander als auch mit den
Ergebnissenkommerzieller Codes.
Die laminare Umstrmung eines Zylinders in 3D ist ein einfach zu
verstehender Bench-mark. Durch Arbeiten, die von TUDo durchgefhrt
wurden, stehen nun auch Ergeb-nisse zur Verfgung, die als
Referenzlsung angesehen werden knnen. Diese Berech-nungen wurden
mit der Q2/P1-Variante von FEATFLOW durchgefhrt. Berechnetwurden
die Beiwerte Cd und Cl (fr drag und lift) whrend der Umstrmung mit
va-riierender Reynoldszahl von 0 bis 100. Die Werte reagieren sehr
sensitiv auf z.B. zugeringe Auflsung in Ort und Zeit. Fr diesen
Benchmark wurden auch Vergleiche mitdem kommerziellen Code CFX und
zustzlich mit OpenFOAM durchgefhrt. Dabei
25
-
Kapitel 2 Eingehende Darstellung des Projekts
Abbildung 2.10: Instationre Entwicklung der Beiwerte. Vergleich
verschiedenerCodes.
wurden in allen drei Codes die gleichen Gitter verwendet, die in
verschiedenen Fein-heiten zur Verfgung standen. Der Benchmark ist
in Bezug auf die Geometrie undntigen physikalischen Parameter exakt
definiert. Die ntigen Informationen wurdenallen Projektpartnern zur
Verfgung gestellt. Die Diagramme in Abbildung 2.10 zeigendie
zeitliche Entwicklung der Beiwerte Cd und Cl fr die drei Codes.
Monodispers Droplets Der zweite Benchmark ist ebenfalls ein
instationres Pro-blem, welches jedoch zweiphasig ist. Die
Problemstellung des Monodispers DropletBenchmarks betrachtet die
Tropfenbildung zweier nicht-mischbarer Flssigkeiten. Ge-whlt wurde
die Tropfendbildung von Silikon-l, welches durch eine Dse in
Wassereingetragen wird. Das Silikon-l bildet nach Austritt aus der
Dse zunchst einenrecht stabilen Pfropfen, der stromabwrts instabil
wird, sich einschnrt und letztend-lich zu einer Tropfenbildung
fhrt. Die Stoffwerte (Dichte und Viskositt) der beidenFluide und
die Oberflchenspannung sind bekannt. Als gut berechenbare und
leichtverstndliche makroskopische Vergleichsgren eignen sich in
diesem Benchmark dieFrequenz der Tropfenbildung, die Gre der
Tropfen und die Lnge des Pfropfens biszur Einschnrung. Neben einer
numerisch berechneten Referenzlsung kann in die-sem Fall auch der
Vergleich mit experimentellen Werten herangezogen werden, die
unsvorliegen.
IANUS hat den Benchmark exakt definiert und den Projektpartnern
alle Informatio-nen zur Verfgung gestellt. Abbildung 2.11 zeigt den
grafischen Vergleich zwischenSimulation (FEM mit FEATFLOW ) und
Experiment, der eine sehr gute qualitativebereinstimmung zeigt. Die
Abbildungen 2.12 und 2.13 zeigen die bereinstimmungfr verschiedene
makroskopische Werte. Berechnet wurden dazu der Volumenanteil
derdispersen Phase, die Pfropfenlnge bei der Abschnrung und die
Abrissfrequenz frverschiedene Volumenstrme.
26
-
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
Abbildung 2.11: Instationre Tropfenabschnrung. Vergleich
zwischen FEM-Simulation (oben) und Experiment (unten) fr
verschiedeneSimulationszeiten.
Der Benchmark wurde auch mit einem LB-Code am iRMB gerechnet.
Abbildung 2.14zeigt fr einen ausgewhlten Fall eine qualitativ gute
bereinstimmung mit den FEM-Berechnungen und den experimentellen
Ergebnissen. Die Frequenz der Abschnrungund Tropfengre stimmen sehr
gut berein.
Die Ergebnisse zeigen sehr eindrucksvoll, dass LB-Codes sich
auch fr mehrphasigeProblemstellungen eignen. Die Ergebnisse werden
wissenschaftlich weiter verfolgt. DieGruppen in Braunschweig und
Dortmund wollen dazu weiterhin eng zusammenarbei-ten.
27
-
Kapitel 2 Eingehende Darstellung des Projekts
Abbildung 2.12: Berechnete und theoretische Vorhersage des
zeitabhngigen Volu-menanteils der dispersen Phase.
Abbildung 2.13: Gemessene und berechnete Pfropfenlnge (links)
und Abrissfre-quenz (rechts) fr verschiedene Volumenstrme.
Showcases
Die verschiedenen Showcases sollten im Gegensatz zu den
Benchmarks die Interessender Industrie besser bercksichtigen. Im
nchsten Abschnitt werden die wesentlichenErgebnisse insbesondere
anhand des BASF-Showcases aufgezeigt.
Strmung in einem Reaktionsrohr (BASF) Der Showcase Reaktionsrohr
wur-de in Zusammenarbeit mit dem assoziiertem Partner BASF
aufgebaut und definiert.Apparate dieses Typs sind in der chemischen
Verfahrenstechnik weit verbreitet. Die zu-verlssige Berechnung der
Durchstrmung insbesondere unter Betrachtung des Wrme-und
Stofftransports oder sogar Reaktionen stellt noch immer eine
Herausforderung frdie Industrie dar. Insbesondere die Vorhersage
von Hot-Spots ist dabei ein zentralerAspekt, da die
Temperaturspitzen zu einer Verringerung der Produktqualitt
fhrenknnen. Ziel ist es, durch Kombination von (einer reduzierten
Anzahl an) Experimen-ten mit genaueren Vorhersagen durch
Simulationen die Sicherheitsaufschlge in denProzessen verringern zu
knnen. Damit gelingt eine Erhhung der chemischen Um-stze und
Selektivitten bei einem geringeren Einsatz an Material und Energie.
Die
28
-
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
Abbildung 2.14: Vergleich der Ergebnisse des LB-Codes (links)
mit einem Experi-ment (Mitte) und FEM-Berechnung (rechts).
Optimierung der chemischen Prozesse in Richtung hheree
Produktqualitt bei gerin-gerem Ressourceneinsatz stellt fr die
deutschen Firmen der chemischen Industrie denSchlssel im Wettbewerb
mit insbesondere asiatischen Mitbewerbern dar.
Herr Dr. Winkler von der BASF hat verschiedene
Geometriebeschreibungen von demRohr und der darin enthaltenen
Schttung in Form von STL-Dateien bereitgestellt.IANUS hat diese
Dateien und alle ntigen Betriebsparameter und Stoffdaten ber
dieKommunikationsplattform an die einzelnen Partner verteilt. Der
gngige Zugang ist,die STL-Daten zu voxeln. Die BASF hat selbst
Simulationen mit (teilweise angepass-ten) kommerziellen Codes
durchgefhrt und kann die Berechnungen mit den Ergeb-nissen
umfangreicher Versuchsreihen im eigenen Technikum vergleichen. Die
BASFbesitzt auf Basis dieser Aktivitten Ergebnisse, die nach ihrer
Aussage Referenzcha-rakter haben. Diese Daten eigenen sich damit
sehr gut zum Vergleich der Genauigkeitund der Performance der
innerhalb von SKALB entwickelten Anstzen untereinan-der und mit den
BASF-Ergebnissen selbst. Die Daten wurden jedoch bewusst von
derBASF bis zum Ende des Projekts zurck gehalten, um einen mglichst
unbeeinflusstenEinstieg in diesen Showcase zu gewhrleisten.
Neben Berechnungen mit zwei Codes des iRBM und Codes von LSS und
RRZE lie-gen zustzlich auch Ergebnisse auf Basis von FEATFLOW vor,
die mit einer Q2/P1-Variante erzielt wurden. Die komplexe innere
Struktur der Geometrie wurde dabei mitHilfe der Fictitious Boundary
Methode (FBM) abgebildet und gegen die Ergebnisse
29
-
Kapitel 2 Eingehende Darstellung des Projekts
Abbildung 2.15: Das Festbett in dem Reaktionsrohr ist aus
zylindrischen Formkr-pern aufgebaut.
Abbildung 2.16: rtliche Auflsung durch den Fictitious Boundary
Ansatz imLngs- und Querschnitt.
der Voxelisierer getestet. Um die Rechenzeit zu minimieren,
wurden die stationrenGrenzwerte, die auf einem groben Gitter
berechnet werden konnten, auf ein feineresGitter interpoliert und
die Berechnung dort fortgesetzt. Diese Rechnungen wurdenauf drei
Knoten des LiDo (Linux Cluster der TU-Dortmund) mit insgesamt 48
CPUsgerechnet (Intel Xeon E7340). Die Arbeiten zu dem Benchmark
konzentrieren sichzu Anfang auf den Bereich kleinerer
Geschwindigkeiten (Leerrohrgeschwindigkeiten< 1,0m/s). Die
Berechnungen fr hhere Leerrohrgeschwindigkeiten bedrfen geeig-neter
Turbulenzmodelle, die nicht in allen Codes implementiert sind.
Abbildung 2.15zeigt die komplexe innere Struktur des Festbettes.
Die Geometrie liegt als STL-Dateivor. Aus der Abbildung 2.16 lsst
sich erkennen, wie diese Formkrper fr ein grberesund ein feineres
Gitter geometrisch aufgelst werden. In den Abbildungen 2.17 und2.18
sind die Geschwindigkeits- und Druckverlufe fr eine
Leerrohrgeschwindigkeitvon v=0,1m/s dargestellt.
30
-
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
Abbildung 2.17: Geschwindigkeitsverteilung im Festbett fr
v=0,1m/s.
Abbildung 2.18: Druckverteilung im Festbett fr v=0,1m/s.
Abbildung 2.19 zeigt das Ergebnis der Voxelisierung durch das
iRMB anhand vonSchnittdarstellungen. Vergleichbare und auch
identische Voxelgitter wurden bei denBerechnungen von LSS und RRZE
verwendet.
Die folgende Abbildung 2.20 zeigt, dass vergleichbare Auflsungen
bei der FBM undden LB-Anstzen verwendet wurden. Dargestellt ist
eine ausgewhlte Schnittebenedurch die Schttung mit klar erkennbaren
Strukturen der Fllkrper. Die FBM-Auflsung bildet die geometrischen
Details zwar etwas schlechter ab als die verwen-deten
Voxelabbildung, dafr wird bei FEATFLOW durch den Q2/P1 Ansatz
einehhere Approximationsgte erzielt als bei linearen FEM-Anstzen.
Insgesamt sind dieErgebnisse vergleichbar.
In Abbildung 2.21 wird anhand von Schnittdarstellungen der
Feldgre Geschwin-digkeit (dargestellt als VectorMagnitude)
verdeutlicht, dass die Berechnungen zu ver-gleichbar guten
Ergebnissen fhren. Zonen hoher und geringer Strmung werden
qua-litativ gleich berechnet. Die verschiedenen Grenordnungen der
dargestellten Werte-
31
-
Kapitel 2 Eingehende Darstellung des Projekts
Abbildung 2.19: Unterschiedlich feine Auflsungen beim
Voxelisieren.
bereiche stammen aus unterschiedlichen Lngeneinheiten (Meter,
Dezimeter etc.), diein den drei Codes angesetzt wurden.
Die BASF hat Leerrohrgeschwindigkeiten von mehr als 1m/s als
besonders industrie-relavant ausgewiesen. Bei zunehmenden
Leerrohrgeschwindigkeiten wird die Strmungjedoch zunchst instationr
und dann turbulent. Durch diesen Umstand bedingt wirdder Vergleich
der Codes untereinander und mit den Ergebnissen der BASF
schwieri-ger. Dies liegt vor allem daran, dass nicht alle Codes
implementierte Turbulenzmodelleaufweisen bzw. unterschiedliche
Turbulenzmodelle bieten. Fr die industrierelevantenBerechnungen mit
Leerrohrgeschwindigkeiten von mehr als 1m/s wurde ein iRMB-Code
verwendet, in dem auch ein Turbulenzmodell (Cascaded LBM,
Smagorinski LES)
Abbildung 2.20: Vergleich der Auflsung bei der FBM (links) und
der Voxelisierung(mitte und rechts).
32
-
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
Abbildung 2.21: Vergleich der Berechnungsergebnisse anhand von
drei Schnitten.Dargestellt ist die Geschwindigkeit als
VectorMagnitude (Reihen-folge wie in Abbildung 2.20).
Abbildung 2.22: Vergleich der Ergebnisse fr den Druckverlust bei
hherenLeerrohrgeschwindigkeiten.
implementiert ist. Auf 12 GPGPUs mit Infiniband-Netzwerk wurden
dabei ungefhr300MNUPs/GPU erzielt. Die Gitterauflsung lag bei
256x265x3900 Knoten und istdamit sehr fein. Abbildung 2.22 zeigt,
dass mit dem Code aus Braunschweig fr Leer-rohrgeschwindigkeiten
bis 5 m/s die Ergebnisse fast exakt abgebildet werden.
Auf Basis der Ergebnisse aus Braunschweig liegen die Kosten fr
eine Berechnung beica. nur 4 bis 5 Euro (Annahme 0,32 Euro pro
Knotenstunde und 3 Euro Fixkosten).Als Ergebnis kann festgehalten
werden, dass sich LB-Methoden fr industrierelevanteFragestellungen
eignen. Insgesamt lsst sich feststellen, dass die LB-Codes aus
SKALB(VirtualFluids, ILBDC und waLBerla) alle sehr gut skalieren.
Anhand des BASF-Showcases konnte nachgewiesen werden, dass die
hydrodynamische Berechnung in sehrkomplexen 3D-Geometrien schnell
und gnstig durchgefhrt werden kann.
33
-
Kapitel 2 Eingehende Darstellung des Projekts
Abbildung 2.23: Aufbau einer Brennstoffzelle mit
Gasdiffusionsschicht (GDS).
Simulation des Flssigwassers im Gasdiffusionsmedium der
Brennstoffzelle (DE-CODE) Der LSS hat Simulationen zum Verhalten
des Flssigwassers im Gasdiffu-sionsmedium der Brennstoffzelle
durchgefhrt. Diese Arbeiten wurden innerhalb desEU-Projekts DECODE
durchgefhrt (www.decode-project.eu). Durch den Verlust
vonHydrophobizitt in der Diffusions- und Reaktionsschicht sinkt die
elektrochemischeLeistung der Zelle. Es gibt zahlreiche
Anforderungen an derartige Simulationen. Diekomplexe Geometrie
erfordert eine feine Auflsung in Ort und Zeit. Simulationszeitenin
der Grenordnung von 10 Sekunden fhren schon zu
Simulationslaufzeiten vonvielen Tagen. Bisher skalierten die
Rechnungen nur bis 64 Prozessen (globale MPI-Kommunikation). Die
Parallelisierungsoptimierung in Bezug auf den Kernel und Re-start,
die in SKALB erarbeitet wurden, bringt einen Performance-Vorteil
von 5080%in Strong-Scaling-Experimenten fr die
Brennstoffzellengeometrien. Die Wassertrans-portsimulationen in der
Gasdiffusionsschicht (GDS) von Brennstoffzellen wird dadurchmglich.
In Abbildung 2.23 ist der beispielhafte schematische Aufbau einer
Brennstoff-zelle zu erkennen. In Abbildung 2.24 ist die
Wasserteilung auf Basis einer Wassertrans-portsimulation
dargestellt.
Strmung in einer Trennkolonne (SULZER) Dieser Showcase wurde mit
Sulzererarbeitet. In einer Trennkolonne mit Boden bildet sich eine
komplexe mehrphasigeStrmung aus. Ziel war die Vorhersage der
Grenzen sogenannter Strmungsregimes.Die Kenntnis darber, wann die
Bden z.B. leerlaufen oder die Gasstrmung in unge-wnschter Weise
Flssigkeit mitreit, sind wichtige Informationen bei der
Auslegungund dem Betrieb dieser Apparate.
Der Showcase der Trennkolonne ist nach Einschtzung aller
Projektpartner zur Zeitnicht befriedigend zu lsen. Dies hngt in
erster Linie aber damit zusammen, dass frderart komplexe
Strmungsregimes kaum zuverlssige Modelle zur Verfgung stehen.Dieser
Showcase wurde daher innerhalb des SKALB-Projekts nicht weiter
verfolgt.Sulzer wurde darber informiert.
34
-
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
Abbildung 2.24: Verteilung der Flssigkeit in einer GDS auf Basis
einerWassertransportsimulation.
2.1.6 Erzielte Fortschritte in den weiterentwickelten
LB-Codes
Fortschritt VirtualFluids
Untersttzung von Multi-Core- und Many-Core-(GPGPU)-Hardware
neue kompakte Interpolationsverfahren zweiter Ordnung fr
Gitterverfeinerungund Haftrandbedingungen
adaptive, dynamische, dezentralisierter Lastbalancierung
Implementierung des D3Q27-Modells und Weiterentwicklung sowie
Validierungdes Cascaded-Lattice-Boltzmann-Verfahrens fr turbulente
Strmungen
Fortschritt waLBerla
hardware-nahe effiziente Kernel
effiziente Kernel fr LBM und partikulre Strmungen auf CPUs
undGPGPUs
CPU-Kernel nutzt SSE und NT-Stores
Sowohl CPU als auch GPGPU-LB-Kernel erreichen ungefhr 75% der
vor-hergesagten Lightspeed-Performance
Restart
Untersttzung von Checkpoint-Restart fr Simulationen von freien
Ober-flchen und partikulren Strmungen
massiv parallele Simulation
35
-
Kapitel 2 Eingehende Darstellung des Projekts
massiv parallele Simulationen von partikulren Strmungen und
freienOberflchen mit bis zu ca. 300.000 Cores auf Jugene und ber
1.000 GPG-PUs auf Tsubame 2.0
Unterstrzung von heterogenen CPU-GPGPU-Clustern fr
LB-Simulationund partikulre Strmungen
pure-MPI, hybride, und heterogene Parallelisierungen
berlappen von Arbeit und Kommunikation
verbesserte Skalierbarkeit von waLBerla durch Optimierung des
parallelenI/O und weiteren Optimierungen mit Hilfe der Analyse des
parallelen Kom-munikationsaufwandes
statisch lastbalancierte heterogene Simulation auf CPU und
GPGPU
heterogene Simulationen von LB und partikulren Strmungen
statische Lastbalancierung durch nicht uniforme Blcke
Kapselung der Heterogenitt innerhalb eines MPI-Prozesses und
Beschrei-bung der Hardware pro Rechenknoten
Metainformationen
Beschreibung aller Kernel durch Metainformationen
Mit Hilfe der Metainformationen knnen spezifische Kernel zur
Laufzeitausgewhlt werden, um somit unterschiedliche Hardware,
physikalische Mo-delle, und dynamischer Simulationen zu
untersttzen
Software Qualitt
verbesserte Wartbarkeit und Erweiterbarkeit durch Minimierung
der physi-kalischen Abhngigkeit der einzelnen Komponenten von
waLBerla
erweiterte Simulationsanwendungen und Nutzerschaft
Die Erweiterungen an waLBerla ermglichen eine grere Anzahl an
Simu-lationsanwendungen fr einen erweiterten Nutzerkreis.
Simulationsanwendungen sind u.a. die Simulation von
Schmelzprozes-sen, Proteinschumen, Nano-Fluiden,
elektro-osmotischen Strmungen, Mi-kroschwimmer mit Eigenantreib,
Strmungen in porsen Medien und Flui-disierungen.
36
-
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
Fortschritt ILBDC
skalierbarer, lokalittsoptimierender Prprozessor und
Partitionierer
Die Zahl der Prozessoren, die fr das Prprocessing genutzt
werden, istunabhngig von der Zahl der Prozessoren, die fr die
anschlieende Str-mungssimulation genutzt werden.
Eine vom Prprozessor aufbereitete Geometriedatei
(Partitionierungsdatei)kann anschlieend zur Strmungssimulation auf
beliebig vielen Prozessorenverwendet werden.
Die Knoten des Strmungsgebiets werden so sortiert, dass sie fr
den Str-mungslser lokalittsoptimiert vorliegen, d.h. dass im
Strmungslser einegute Cache-Ausnutzung erfolgt.
Zur Aufbereitung und Sortierung der Knoten des Strmungslsers
knnenunterschiedliche raumfllende Kurven oder Blocking-Anstze
genutzt wer-den.
SSE-optimierte Zwei-Gitter-Implementierung des
TRT-Kollisionsmodells
Nutzung von NT-Stores ber algorithmische nderungen
(Pull-Scheme,Split-Loops) und Compiler-Direktiven, so dass auf
aktuellen Dual-Socket-Computekonoten mit Intel Westmere-Prozessoren
75% der theoretischdurch das Performancemodell vorhergesagten
Spitzenleistung erreicht wird.
Speicheroptimierte Ein-Gitter-Implementierung des
Propagationsschritts auf Ba-sis des AA-Patterns
Reduktion des Speicherbedarfs um 40%.
Elimination des Write-Allocates (RFO) durch Lesen und Schreiben
auf iden-tische Array-Elemente.
In Verbindung mit dem SSE-optimierten TRT-Kollisionsmodell
werdenauf aktuellen Dual-Socket-Computeknoten mit Intel
Westmere-Prozessoren90% der theoretisch durch das Performancemodell
vorhergesagten Spitzen-leistung erreicht.
MPI-IO basierter Checkpoint-Restart-Mechanismus
Optimale Ausnutzung der Bandbreite von parallelen
Dateisystemen.
Vermeidung von einzelnen Checkpoint-Dateien pro MPI-Prozess.
Restart-Mglichkeit mit einer unterschiedlichen
Prozessorzahl.
37
-
Kapitel 2 Eingehende Darstellung des Projekts
Fortschritt FEAST
Optimierung der ursprnglichen Implementierung des voll
impliziten Ansatzes(FEASTLBM )
Verbesserung der Stabilitt: Obwohl das Finite Differenzen
Upwinding vonzweiter Ordnung schon fr grobe Auflsung des
unstrukturierten, lokal ver-feinerten Gitters das Strmungsprofil in
den meisten Fllen akkurat wiedergeben kann, konnte die Stabilitt
des Verfahrens noch verbessert werdendurch den Einsatz des
MRT-Modells und des Crank-Nicholson-Verfahrens
Die linearen Systeme knnen mit dem alternativen generalized
equilibriumformulation Ansatz auch ohne Einsatz von
Mehrgitterverfahren gelst wer-den.
Entwicklung eines speziellen Transport-Vorkonditionierers der in
Kombina-tion mit dem BICG-Stab Verfahren bereits hohe Effizienz
erreicht.
Zeitdiskretisierung hoher Ordnung ist nun mglich
Direkt stationre Lsung ist nun mglich
Newton- und Fixpunktiterationen sind nun mglich
Die Implementierung des semi-impliziten Ansatzes war
erfolgreich
Weiterentwicklung mit Finiten Elementen hoher Ordnung und
DiscontinousGalerkin
Implementierung von Finite Elemente Mehrgittermethoden fr
unstrukturierteGitter
Der FE-gMG wurde an FEAST und ScarC erfolgreich
angeschlossen
Die Datenstrukturen wurden um neue Sparsematrix Formate (CSR,
COO,ELLPACK, ELLPACK-R und ELLR-T) fr verschiedene
Hardwarearchi-tekturen erweitert
Die SparseBandedBLAS von FEAST wurde um optimierte Kernel fr
dieSparseMatrix-Vector Multiplikation (SpMV) erweitert:
Insbesondere dieVektorisierung (SSE) und Multi-Core bzw.
GPGPU-Kernel wurden hierentworfen und optimiert
neue Glttungsoperatoren fr geometrische Mehrgittermethoden und
un-strukturierte Gitter basierend auf Sparse Approximate Inverse
Techniken(SPAI, SAINV) wurden hinzugefgt
Matrix-basierter Gittertransfer wurde hinzugefgt
(Assemblierung)
optimierte Assemblierungsroutinen fr GPGPUs wurden
hinzugefgt
Allgemeine Verbesserungen des Frameworks:
38
-
2.1 Verwendung der Zuwendung und erzielte Ergebnisse
Die ursprngliche Laufzeitumgebung wurde fr die
Speicherkonsistenzver-waltung bei hybrider Rechnung erweitert
Die ursprngliche Laufzeitumgebung wurde fr die
Multi-GPU-Berechnungen erweitert
Die Mehrgitterlser wurden um eine neue funktorbasierte
Zyklussteuerungzur Umgehung von Rekursionsoverhead whrend der
Rechnung erweitert
Die SparseBandedBLAS (SBBLAS) von FEAST wurde um ein Frontendmit
effizientem Operator- Overloading (basierend auf
Hardware-orientiertenExpression Templates) erweitert
Ein 3D Visualisierungstool auf Basis von OpenGL und Qt wurde
entwickeltund angebunden
Neue Datenformate fr parallele Gittergeneration /
-partitionierung wurdenentwickelt und angebunden
Gitter, Loadbalancing und parallele Lser
Die ursprnglichen Prototypen fr statisches / dynamisches
Loadbalancingwurden verbessert
Die numerischen Performancemodelle konnten durch Erkenntnisse im
Be-reich der starken Gltter verbessert werden, was sich
insbesondere auch aufdie Entwicklung der Loadbalancer-Logik
ausgewirkt hat
Der Top-level Lser (ScaRC) und zugehrige Datenstrukturen
konntendurch Verwendung neuer Kommunikationsroutinen stark
verbessert werden
Unstrukturierte (Teil-)Gittern sind verbessert worden und nun
auch aufGPGPUs mglich
Das Zusammenfassen von Gitterpatches fr gemeinsame
Matrixassemblie-rung wurde hinzugefgt
Neue Methoden Adaptiver Verfeinerung wurden hinzugefgt
Standard-LB-Lser
Eine Bibliothek mit effizienten 2D LB-Operatoren, die auf jeder
zu evalu-ierenden Hardware luft ((Multi-)GPU- (CUDA und OpenCL),
generischeCPU-, SSE-, Multi-Core PThreads-, Cell-Backends und
hybride Ausfh-rung) wurde entwickelt und hinzugefgt.
Einfache Operatoren wurden um komplexe (Multi-)Physik-Kernel und
de-ren hardwarenahe Optimierungen erweitert: Zentral hierbei sind
die folgen-den Features: Fluid-Struktur Interaktion, komplexe
Kraftterme und zuge-hrige Datenstrukturen, Kopplung verschiedener
Gleichungen (Flachwasser-gleichungen mit Konvektions-
Diffusionsgleichung), Momentum-Exchange,komplexe Gitter, dynamische
Gitter.
39
-
Kapitel 2 Eingehende Darstellung des Projekts
2.2 wichtigste Positionen des zahlenmigen Nachweises
Bei allen am Projekt beteiligten Gruppen sind die Personalkosten
fr die Projektmitar-beiter der mit Abstand grte Posten.
Darberhinaus standen den einzelnen Gruppennur noch Reisemittel zur
Verfgung. Die Projektbearbeiter und die wichtigsten
ausProjektmitteln finanzierten Konferenzteilnahmen sind im
Folgenden, nach Gruppenaufgeschlsselt, gelistet. Eine vollstndige
Liste der Verffentlichungen und gehaltenenVortrge findet sich in
Abschnitt 2.6.
2.2.1 FAU / RRZE
Projektbearbeiter (84 FTE)
J. Habich: 36 FTE (Entwicklung LB-Kernel, GPGPU-Implementierung
CUDA)
M. Wittmann: 30 FTE (skalierbare Partitionierung,
ILBDC-Solver)
J. Treibig: 10 FTE (Performancemodellierung)
M. Kreutzer: 4 FTE (GPGPU-Implementierung CUDA und OpenCL)
G. Schubert, F. Shazad, T. Zeiser: 5 FTE (Programmiermodelle,
ILBDC-Solver,Checkpoint-Restart)
Verwendung der Reisemittel (grte Posten)
International Conference on Parallel, Distributed and Grid
Computing for Engi-neering (PARENG); Pecs (Ungarn), 2009: Vortrag
Habich [84], [13]
Parallel Computational Fluid Dynamics (ParCFD); Moffett Field,
CA (USA),2009: Vortrag Wellein [81]
IEEE International Parallel and Distributed Processing Symposium
(IPDPS);Rom (Italien), 2009; Vortrag Zeiser [124], [28, 29]
International Conference for Mesoscopic Methods in Engineering
and Science(ICMMES); Guangzhou (China), 2009: Vortrag Zeiser [82,
116]
IEEE International Parallel and Distributed Processing Symposium
(IPDPS);Atlanta (USA), 2010: Vortrag Wittmann [113], [23, 24]
ECCOMAS CFD; Lisabon (Portugal), 2010: Vortrag Habich [90]
SIAM CSE; Reno (USA), 2011: Vortrge Habich und Wellein [76, 104,
106]
Parallel Computational Fluid Dynamics (ParCFD); Barcelona
(Spanien), 2011:Vortrge Habich, Wellein, Wittmann und Zeiser [89,
105, 115], [26]
International Conference for Mesoscopic Methods in Engineering
and Science(ICMMES); Lyon (Frankreich), 2011: Vortrag Zeiser [126],
[25]
40
-
2.2 wichtigste Positionen des zahlenmigen Nachweises
2.2.2 FAU / LSS
Projektbearbeiter (69 FTE)
C. Feichtinger: 21 FTE (waLBerla, Datenstrukturen,
Parallelisierung, GPGPU,Performance-Modellierung, Partikulre
Strmungen)
K. Pickl: 18 FTE (waLBerla, Datenstrukturen, Parallele
Auswertungen, Parti-kulre Strmungen, Datenreduktion)
D. Bartuschat: 11 FTE (waLBerla, Parallelisierung,
Datenreduktion, PartikulreStrmungen, Checkpoint-Restart)
F. Schornbaum: 9 FTE (Datenstrukturen, Dynamische
Lastbalancierung, Adap-tivitt, Checkpoint-Restart)
T. Preclik: 8 FTE (Partikulre Strmungen, Parallelisierung)
C. Mihoubi: 1 FTE (Komplexe Geometrien, Visualisierung)
Verwendung der Reisemittel (grte Posten)
ISC; Hamburg, 2009: Vortrag/Poster Iglberger
International Conference for Mesoscopic Methods in Engineering
and Science(ICMMES); Guangzhou (China), 2009: Vortrag Feichtinger
[70]
Vortrge auf einer Reise nach China/Australien, 2010: Rde [99,
100]
SIAM CSE; Reno (USA), 2011: Vortrag Feichtinger [68]
Parallel Computational Fluid Dynamics (ParCFD); Barcelona
(Spanien), 20