Gemeinsamer Abschlussbericht des BMBF-Verbundprojekts SKALB ...

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


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


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


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


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


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


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


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


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


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


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


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/


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/


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

Gemeinsamer Abschlussbericht des BMBF-Verbundprojekts SKALB ...

Documents

Transcript of Gemeinsamer Abschlussbericht des BMBF-Verbundprojekts SKALB ...