Bachelorarbeit

am Lehrstuhl fuumlr Angewandte Mathematik und Numerikder Fakultaumlt fuumlr Mathematik

an der TU Dortmund

Interaktive Stroumlmungssimulationauf Tablet-Computern

vorgelegt von

Niklas Borg und Patrick Westervoszlig

betreut durch

Jun-Prof Dr Dominik Goumlddeke

Oktober 2012

Inhaltsverzeichnis

1 Einleitung 1

2 Theoretische Grundlagen 321 Die Navier-Stokes Gleichungen 322 Anfangs- und Randbedingungen 523 Projektionsverfahren und die Helmholtz-Hodge-Zerlegung 624 Diskretisierung und numerische Loumlsung 8

3 Implementierung 1231 Loumlser 13

311 Kraft aufpraumlgen 13312 Advektion 14313 Diffusion 14314 Projektion 15

32 Visualisierung 1633 Interaktion 1934 Demonstration des Gesamtsystems 20

4 Tests 2241 Validierung 22

411 Numerische Stabilitaumlt 22412 Physikalisch richtiges Verhalten 23

42 Parametertests 26421 Viskositaumlt 27422 Zeitschrittweite 30423 Symmetrietest 33

43 Validierung der Interaktions-Komponente 38431 Physikalisch korrekte Umsetzung 38432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent 40

44 Zeitmessungen und Tuning 43441 Analyse des Loumlsers 43442 Analyse der Visualisierungs-Komponente 46443 Analyse der Interaktions-Komponente 50444 Zusammenfassung 52

5 Diskussion und Fazit 54

Kapitel 1

Einleitung

In dieser Bachelorarbeit stellen wir ein Verfahren zur Stroumlmungssimulation in Form einer App auf Tablet-Computern vor Aufgrund der massiven Hardwareverbesserung in der letzten Zeit ist es mittlerweile moumlg-lich solche Computer fuumlr anspruchsvolle Simulationen zu verwenden Insbesondere koumlnnen wir dadurchdie Echtzeit und Interaktion auf sehr natuumlrliche Weise realisieren Das Ziel dieser Arbeit ist es somiteine neue Hardwarearchitektur inklusive ihrer intuitiven Interaktionsmoumlglichkeiten auf die Eignung zurphysikalisch korrekten numerischen Stroumlmungssimulation zu evaluieren und dabei experimentell zu er-gruumlnden ob und in welchem Rahmen eine Echtzeit-Simulation erreicht werden kann Dazu betrachtenwir ein Fluid welches sich in dem zweidimensionalen Gebiet Ω = [minus1 1]2 sub R2 befindet Als ma-thematisches Modell verwenden wir die inkompressiblen Navier-Stokes Gleichungen denen wir uns inKapitel 2 widmen Patrick Westervoszlig erlaumlutert in Abschnitt 21 die physikalische Bedeutung dieser Glei-chungen und geht in Unterkapitel 22 auf Anfangs- und Randbedingungen die fuumlr die Wohlgestelltheitdes Problems notwendig sind ein Danach uumlberfuumlhrt er die Gleichungen in Abschnitt 23 in eine zurLoumlsung geeignetere Form Anschlieszligend entwickelt Niklas Borg in Abschnitt 24 ein numerisches Louml-sungsverfahren und geht zusaumltzlich auf die Diskretisierung dieses Verfahrens mittels finiter DifferenzeneinIn Kapitel 3 praumlsentieren wir die programmiertechnische Umsetzung des im vorherigen Kapitel vorge-stellten Verfahrens die wir aufgrund ihrer Komplexitaumlt gemeinsam durchgefuumlhrt haben und gehen aufeinige kompliziertere Strukturen ein Weiterhin stellen wir zwei fuumlr die Stroumlmungssimulation auf Tablet-Computern wesentliche Komponenten vor die Visualisierung des zuvor berechneten Geschwindigkeits-feldes und die Interaktion eines Anwenders Hierbei verwenden wir die OpenGL ES 20-Bibliothekdie uumlblicherweise zur Realisierung der beiden Elemente auf Tablet-Computern genutzt wirdIn Kapitel 4 fuumlhren wir verschiedene Tests durch um unsere Software auf ihre Richtigkeit zu pruumlfenDazu untersucht Niklas Borg in Abschnitt 41 die numerische Stabilitaumlt und physikalische Korrektheitunserer Simulation Damit ist gemeint dass sich die Simulation nicht verselbststaumlndigt sich also einstatisches Fluid nicht selbst anregt Daruumlber hinaus vergleicht er den gaumlngigen Testfall Driven Cavi-ty durchgefuumlhrt in unserer Simulationsumgebung mit einer Referenzloumlsung In Abschnitt 42 fuumlhrt erzudem einige Parametertests durch um die Auswirkungen der verschiedenen Variablen unseres Loumlsersauf die Simulation zu bewerten Dabei betrachtet er die kinematische Viskositaumlt ν des Fluids den imVerfahren verwendeten Zeitschritt ∆t und die Anzahl maxiter der durchzufuumlhrenden Iterationen imeingesetzten Jacobi-LoumlserIn Abschnitt 43 analysiert Patrick Westervoszlig die Umsetzung der Anwender-Interaktion anhand zwei-er verschiedener Testfaumllle die sich in ihrer Komplexitaumlt unterscheiden Danach erarbeitet er in Ab-schnitt 44 mit Hilfe von Zeitmessungen der einzelnen Implementierungs-Komponenten potentielle Ver-besserungsmoumlglichkeiten der Software um zu beurteilen in wie weit eine Echtzeit-Simulation auf Tablet-Computern erreicht werden kann Dazu vergleicht und interpretiert er die Laufzeiten des Loumlsers derVisualisierungs- sowie der Interaktions-Komponente fuumlr verschiedene Gitterschrittweiten h der Diskre-tisierung

1

KAPITEL 1 EINLEITUNG 2

Zum Schluss fassen wir in Kapitel 5 die wesentlichen Erkenntnisse zusammenEine genaue Uumlbersicht uumlber die Aufteilung der Bearbeitung dieser Bachelorarbeit geben wir in Ta-belle 11

Kapitel bearbeitet von21 Patrick Westervoszlig22 Patrick Westervoszlig23 Patrick Westervoszlig24 Niklas Borg3 Niklas Borg und Patrick Westervoszlig

41 Niklas Borg42 Niklas Borg43 Patrick Westervoszlig44 Patrick Westervoszlig

Tabelle 11 Aufteilung der Bearbeitung der Bachelorarbeit

Kapitel 2

Theoretische Grundlagen

Zur Simulation einer Stroumlmung in einem Fluid in einem bestimmten Zeitintervall benoumltigen wir einemathematische Beschreibung seines Verhaltens Ein gutes Modell dafuumlr sind die Navier-Stokes Glei-chungen da sie die fuumlr die Darstellung eines Fluids wesentliche Komponente die Entwicklung der Ge-schwindigkeit charakterisieren Auszligerdem bilden sie viele physikalische Effekte ab wie zum BeispielTurbulenzen und Grenzschichten innerhalb der Stroumlmung Deshalb wollen wir diese Gleichungen imFolgenden genauer betrachten Dabei orientieren wir uns an den Ausfuumlhrungen von [Stam] und [Harris]Das Ziel des im weiteren Verlauf dieser Arbeit entwickelten Loumlsungsverfahrens ist die Generierung ei-nes fluidartigen Verhaltens welches zwar auf den Navier-Stokes Gleichungen basiert dessen berechnetesGeschwindigkeitsfeld die Gleichungen jedoch nicht exakt erfuumlllt Die hier vorgestellte Methode wurdeurspruumlnglich fuumlr Computeranimationen entworfen und nicht fuumlr Anwendungen aus den Ingenieurswis-senschaften was unser leicht inexaktes Vorgehen zur Fluidsimulation rechtfertigt

21 Die Navier-Stokes Gleichungen

Zunaumlchst treffen wir einige in der Fluidsimulation durchaus uumlbliche Annahmen die auf eine vereinfach-te Form der Navier-Stokes Gleichungen fuumlhren und trotzdem die Qualitaumlt des mathematischen Modellserhalten Dazu nehmen wir die Dichte ρ des Fluids sowie seine Temperatur θ als konstant bezuumlglichOrt und Zeit an wodurch wir die Beschreibung eines inkompressiblen Fluids erhalten Aufgrund die-ser Annahmen muumlssen wir uns in der Simulation auf sogenannte bdquonewtonscheldquo Fluide beschraumlnken DieEntwicklung eines solchen Fluids in einem zweidimensionalen Gebiet Ω sub R2 uumlber einem ZeitintervallI = [0 T ] mit T isin R+ koumlnnen wir durch die inkompressiblen Navier-Stokes Gleichungen charakterisie-ren welche das Fluidverhalten mathematisch beschreiben

partu

partt= minus (u middot nabla)uminus 1

ρnablap+ νnabla middot nablau + f (21)

nabla middot u = 0 (22)

Dabei bezeichnen wir mit u = u (x t) die Geschwindigkeit mit p = p (x t) den Druck mit ν diekinematische Viskositaumlt und mit ρ die Dichte des Fluids Es ist dabei zu beachten dass wir in unsererSimulation nur den Druck innerhalb des Fluids beruumlcksichtigen und den Atmosphaumlrendruck vernachlaumls-sigen Durch die Groumlszlige f = f (x t) definieren wir eine externe Kraft im Punkt x isin Ω zur Zeit t isin I Hierbei treffen wir die Konvention dass die fett gedruckten Ausdruumlcke vektorwertige Groumlszligen in derRegel Vektorfelder und die kursiven skalare Groumlszligen repraumlsentieren Fuumlr Details zu den Navier-StokesGleichungen und deren Herleitung aus den allgemeinen Erhaltungsgleichungen der Kontinuumsmecha-nik verweisen wir auf [Anderson]Im Folgenden wollen wir uns kurz den einzelnen Bestandteilen von Gleichung (21) widmen und ihre

3

KAPITEL 2 THEORETISCHE GRUNDLAGEN 4

physikalische Bedeutung erlaumlutern wozu wir einige Begriffe definieren

AdvektionUumlblicherweise kann ein Fluid Objekte oder andere Substanzen transportieren In unserem Fall beschraumln-ken wir uns lediglich darauf dass es bdquosich selbstldquo transportiert Es wird also durch die eigene Ge-schwindigkeit fortbewegt Dieses Verhalten nennt sich Advektion und wird durch den Term minus (u middot nabla)ubeschrieben der den konvektiven Transport des Fluids darstellt Die Beruumlcksichtigung dieses Effekteszieht die Konsequenz nach sich dass die Navier-Stokes Gleichungen nichtlinear sind

DruckDie Teilchen in einem Fluid werden automatisch fortbewegt Dies fuumlhrt dazu dass sie sich gegenseitigan- und abstoszligen Wird eine Kraft auf das Fluid aufgepraumlgt so wird diese ebenfalls durch die Teilchenuumlbertragen Diese beiden Phaumlnomene fuumlhren zu einer Druckentwicklung im Fluid was letztendlich in ei-ner Beschleunigung der Teilchen resultiert Der Ausdruck minus1

ρnablap in Gleichung (21) repraumlsentiert diesenphysikalischen Sachverhalt in Abhaumlngigkeit von der Dichte ρ des Fluids und des auf das Fluid wirkendenDrucks p

DiffusionDieses physikalische Phaumlnomen haumlngt stark mit der Zaumlhfluumlssigkeit eines Fluids welche uumlber seine kine-matische Viskositaumlt ν beschrieben wird zusammen und hat einen groszligen Einfluss auf das FluidverhaltenZur Erlaumluterung geben wir zunaumlchst eine rein formale Definition der Viskositaumlt (vgl [Arlt])

Definition 211 (Viskositaumlt)Wir betrachten folgenden Versuchsaufbau

Abbildung 21 Versuchsaufbau zur Definition der Viskositaumlt

Im unteren Teil von Abbildung 21 befindet sich eine feststehende unbewegliche Wand M und im Ab-stand z zu dieser eine bewegliche Wand N mit der Oberflaumlche A Der Raum zwischen den Waumlnden istmit dem zu untersuchenden Fluid gefuumlllt Um die WandN mit der konstanten Geschwindigkeit v parallelzu M zu bewegen wird die Kraft benoumltigt die aus dem Newtonschen Gesetz

KAPITEL 2 THEORETISCHE GRUNDLAGEN 5

F = η middotA middot dv

dz

hervorgeht Somit ist die Kraft F proportional zu der Oberflaumlche A und dem Geschwindigkeits-gradienten dv

dz welcher der Beschleunigung der beweglichen Wand N entspricht Der Proportionali-taumltsfaktor η heiszligt dynamische Viskositaumlt und ist ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres Fluids Es gilthierbei je groumlszliger die Viskositaumlt desto zaumlhfluumlssiger das Fluid

Zu unterscheiden sind dabei zwei verschiedene Begriffe der Viskositaumlt Die dynamische Viskositaumlt η unddie kinematische Viskositaumlt ν welche wir in den Navier-Stokes Gleichungen (21) und (22) benoumltigenWir wollen nun beide Begriffe in Zusammenhang setzen Sei ρ die Dichte und η die dynamische Visko-sitaumlt unseres Fluids Dann ergibt sich die kinematische Viskositaumlt zu

ν =η

ρ (23)

Zaumlhe Fluumlssigkeiten also solche mit einer hohen Viskositaumlt reagieren traumlger auf Bewegungen als duumlnn-fluumlssige oder auch Fluide mit kleinerer Viskositaumlt wie etwa Olivenoumll im Vergleich zu Wasser DieserEffekt nennt sich Diffusion und geht durch den Term νnabla middotnablau in das mathematische Modell ein der dendiffusiven Transport des Fluids beruumlcksichtigt

KraumlfteWie bei der Beschreibung des Drucks bereits erwaumlhnt fuumlhrt das Aufpraumlgen von Kraumlften zur Beschleuni-gung der Fluidteilchen Moumlglich sind externe Kraumlfte also solche die bdquovon auszligenldquo auf das Fluid wirkenund Koumlrper- beziehungsweise Volumenkraumlfte die etwa durch die Erdbeschleunigung hervorgerufen wer-den An dieser Stelle sei schon einmal erwaumlhnt dass die externen Kraumlfte in der Simulation interaktivdurch den Anwender integriert werden koumlnnen (vgl Abschnitt 33)

Damit das Problem welches durch die Navier-Stokes Gleichungen formuliert wird wohlgestellt istmuumlssen wir zusaumltzlich sogenannte Anfangs- und Randbedingungen einfuumlhren auf die wir im folgendenAbschnitt eingehen

22 Anfangs- und Randbedingungen

Sowohl die Geschwindigkeit u als auch der Druck p treten in den Navier-Stokes Gleichungen als Un-bekannte auf und muumlssen in jedem Zeitschritt berechnet und aktualisiert werden Daher muumlssen wirgeeignete Anfangs- und Randbedingungen fuumlr beide Groumlszligen vorgebenDie Anfangsbedingung fuumlr das Druckfeld ist von Testfall zu Testfall unterschiedlich So nehmen wir ineinem Beispiel den initialen Druck als Null an womit p equiv 0 in Ω gilt Andererseits koumlnnen wir fuumlrden Druck sogenannte Druckspitzen vorschreiben wie wir sie in Kapitel 42 setzen Fuumlr das Geschwin-digkeitsfeld waumlhlen wir immer u equiv 0 als Anfangsbedingung und erzeugen Dynamik entweder durchexterne Kraumlfte wie etwa in Abschnitt 431 oder uumlber RandbedingungenIm Allgemeinen legen wir als Randbedingung fuumlr die Geschwindigkeit die sogenannte bdquono-slipldquo-Bedingung u|partΩ equiv 0 fest Wir setzen die Geschwindigkeit am Rand also auf Null was bedeutet dass dasFluid am Gebietsrand haften bleibt Wir koumlnnen aber auch wie beim Testfall Driven Cavity beschriebenan einer Kante des Rechengebiets einen von Null verschiedenen Wert vorschreiben Wir tragen somit ei-ne Tangentialgeschwindigkeit an und erzeugen mit ihrer Hilfe Dynamik im Fluid (vgl Abschnitt 412)Als Randbedingung fuumlr den Druck legen wir fest dass keine Aumlnderung in Normalenrichtung stattfindet

KAPITEL 2 THEORETISCHE GRUNDLAGEN 6

also partppartn |partΩ equiv 0 gilt wobei n den aumluszligeren Normalenvektor von Ω bezeichnet

Die verschiedenen Anfangs- und Randbedingungen sind miteinander und mit der Anwender-Interaktionder wir uns in Abschnitt 43 widmen kombinierbar Wir koumlnnen somit eine Vielzahl von Testfaumlllen kon-struieren von denen wir eine Auswahl in Kapitel 4 praumlsentieren

23 Projektionsverfahren und die Helmholtz-Hodge-Zerlegung

Nachdem wir zuvor alle Komponenten der Navier-Stokes Gleichungen aus physikalischer Sicht betrach-tet und Anfangs- sowie Randbedingungen eingefuumlhrt haben wollen wir sie nun in eine zum Loumlsen geeig-netere Form bringen und anschlieszligend ein Vorgehen zur Loumlsung dieser Gleichungen entwickeln Dabeiist die Art der Diskretisierung des von Raum- und Zeitvariablen abhaumlngigen Problems entscheidendZunaumlchst nehmen wir eine simple Zeitdiskretisierung vor indem wir das Zeitintervall I = [0 T ] inTeilintervalle zerlegen Anschlieszligend betrachten wir Gleichung (21) innerhalb eines Zeitschritts unddiskretisieren die auftretenden Operatoren im Ort (vgl Kapitel 24) Im Folgenden koumlnnen wir daherdie einzelnen Bestandteile dieser Gleichung als zeitunabhaumlngig ansehen da wir das Loumlsungsverfahreninnerhalb eines Zeitschritts entwickelnUm die Gleichungen in ein besser zu loumlsendes System zu uumlberfuumlhren betrachten wir als Hilfsmittelzunaumlchst die sogenannte Helmholtz-Hodge Zerlegung (vgl [Chorin])

Satz 231 Sei Ω sub R2 ein Gebiet mit glattem Rand partΩ Dann kann jedes Vektorfeld w zerlegt werdenin die Form

w = u +nablapwobei nabla middot u = 0 gilt das Vektorfeld u also divergenzfrei ist Auszligerdem ist u parallel zu partΩ das heiszligtu middot n = 0 mit dem aumluszligeren Normalenvektor n von Ω p bezeichnet ein Skalarfeld

In jedem Zeitschritt muumlssen wir Gleichung (21) loumlsen wobei wir gewaumlhrleisten muumlssen dass Glei-chung (22) gilt Wenn wir nun davon ausgehen durch das Loumlsen von Gleichung (21) ein Geschwindig-keitsfeld w erhalten zu haben so muss nicht zwangslaumlufig nabla middotw = 0 gelten Dies erreichen wir durchAnwenden von Satz 231 auf das Geschwindigkeitsfeld w Wir setzen somit am Ende des Zeitschrittsdas aktualisierte Geschwindigkeitsfeld analog zu obigem Satz als u = w minusnablapJetzt stellt sich die Frage wie das Skalarfeld p zu berechnen ist Wenden wir den Divergenz-Operatornablamiddot auf beide Seiten der Gleichung aus Satz 231 an so erhalten wir

nabla middotw = nabla middot u︸ ︷︷ ︸=0

+nabla middot nablap

hArr nabla middotw = nabla middot nablap (24)

Setzen wir also die Loumlsung von Gleichung (21) als bekannt voraus so koumlnnen wir durch Loumlsen derPoisson-Gleichung (24) den Druck p ermitteln mit dem wir das Geschwindigkeitsfeld w so modifizie-ren koumlnnen dass es Gleichung (22) erfuumlllt Als naumlchstes muumlssen wir uns damit beschaumlftigen wie wir dasvorlaumlufige Geschwindigkeitsfeld w berechnen koumlnnen

Zunaumlchst definieren wir hierzu mit Hilfe von Satz 231 einen linearen Operator P der ein Vektorfeld wauf seinen divergenzfreien Teil projiziert Fuumlr diesen Operator gilt dann

P (w) = P (u) + P (nablap) da P linear ist

P (w) = u wegen Satz 231 und (25)

P (u) = u nach Voraussetzung

KAPITEL 2 THEORETISCHE GRUNDLAGEN 7

woraus insgesamt

P (nablap) = 0 (26)

folgtAnhand von Gleichung (25) koumlnnen wir uns mit dem Schwarzschen Satz (vgl [Forster]) uumlberlegendass P

(partupartt

)= partu

partt gilt Der Satz von Schwarz besagt dass bei einer q-mal stetig partiell differen-zierbaren Funktion die ersten q Ableitungen vertauscht werden duumlrfen Bei uns gilt nach Voraussetzungu isin C2 (Ω)capC1 (I) da die Ausdruumlckenablamiddotnablau und partu

partt in Gleichung (21) eine entsprechende Glattheit desGeschwindigkeitsfeldes bezuumlglich der Variablen (x t) verlangen Dabei bezeichnet Ck (Ul) den Raumder k-mal stetig partiell differenzierbaren Funktionen uumlber U2 = Ω sub R2 beziehungsweise U1 = I sub Rmit k l isin 1 2 Somit folgt

nabla middot partupartt

=part

partt(nabla middot u) = 0

Wenden wir nun den Operator P auf Gleichung (21) an und nutzen seine Linearitaumlt undGleichung (26) aus so erhalten wir

partu

partt= P (minus (u middot nabla)u + νnabla middot nablau + f) (27)

Aus Gleichung (27) ergibt sich direkt der von uns verwendete Algorithmus zur Loumlsung der Navier-StokesGleichungen der sich in vier Schritte gliedert

u (middot t) = w0Kraft aufpraumlgenminusminusminusminusminusminusminusminusrarr w1

Advektionminusminusminusminusminusrarr w2Diffusionminusminusminusminusminusrarr w3

Projektionminusminusminusminusminusrarr w4 = u (middot t+ 1) (28)

Wir nehmen an dass uns das Geschwindigkeitsfeld u zum Zeitpunkt t bekannt ist und setzenw0 (x) = u (x t) Pro Zeitschritt loumlsen wir die Gleichung (21) durch sogenanntes bdquoOperator-Splittingldquosukzessiv numerisch Wie in allen Projektionsmethoden entsteht auch hier durch das Splitting ein nu-merischer Fehler wodurch wir Gleichung (21) nicht mehr exakt loumlsen Leider geht [Stam] in seinerOriginalarbeit nicht auf die Ordnung des Verfahrens ein aufgrund der Struktur des Verfahrens und derAumlhnlichkeit zu Chorinschen Projektionsmethoden (vgl [Anderson]) ist aber nicht von einer hohen Ord-nung auszugehen Schlieszliglich gewaumlhrleisten wir durch das Anwenden des oben definierten Projektions-operators P dass Gleichung (22) erfuumlllt ist was anschaulich aus Abbildung 22 hervorgeht

Abbildung 22 Sukzessive Berechnung der Geschwindigkeit in einem Punkt innerhalb eines Zeitschritts(vgl [Stam])

Am Ende eines jeden Zeitschritts setzen wir w0 = w4 Da wir wie oben beschrieben ausgehend vonw0 innerhalb eines Zeitschrittes operieren haumlngen die Geschwindigkeitsfelder wk k isin 0 1 2 3 4

KAPITEL 2 THEORETISCHE GRUNDLAGEN 8

waumlhrend der Berechnung nur von der Ortsvariablen x ab Das Vektorfeld w4 entspricht schlieszliglich demGeschwindigkeitsfeld u zum Zeitpunkt t+∆t also u (x t+ ∆t) mit der Zeitschrittweite ∆t isin R+ DieSimulation erhalten wir letztendlich durch Iteration der in Schema (28) beschriebenen Vorgehensweiseuumlber die Zeitschritte Daraus ergibt sich durch Diskretisierung der auftretenden Operatoren ein nume-risches Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen (21) und (22) worauf wir im naumlchstenAbschnitt eingehen

24 Diskretisierung und numerische Loumlsung

Wir erlaumlutern in diesem Abschnitt die in Schema (28) angefuumlhrten Schritte und stellen Diskretisierungs-beziehungsweise Loumlsungstechniken vor um abschlieszligend ein kompaktes Loumlsungsverfahren der Navier-Stokes Gleichungen aufzustellen Zur Diskretisierung aller auftretenden Operatoren verwenden wir indieser Arbeit meist finite Differenzen zweiter Ordnung Approximationen abweichender Ordnung sindbeispielsweise bei der Behandlung von Randbedingungen noumltig auf die wir in Abschnitt 314 naumlhereingehenWie in Abschnitt 23 bereits erwaumlhnt diskretisieren wir das durch die Navier-Stokes Gleichungen (21)und (22) und Anfangs- sowie Randbedingungen gestellte Problem zuerst in der Zeit und anschlieszligendim Ort Dazu waumlhlen wir eine aumlquidistante Zerlegung des Zeitintervalls in L Teilintervalle der Form

I = [0 T ] =

L⋃l=1

[t(lminus1) t(l)

]

wobei t(l) = l middot∆t und T = L middot∆t gilt Die folgenden Diskretisierungen im Ort fuumlhren wir nun jeweilszu einem festen Zeitpunkt t(l) durch weshalb die auftretenden Groumlszligen zeitunabhaumlngig sindFuumlr unsere Simulation betrachten wir das quadratische Rechengebiet Ω = [minus1 1]2 sub R2 in dem sichdas Fluid befinden soll Davon ausgehend definieren wir ein diskretes Gebiet Ωh mit Schrittweite h isin Rdie wir sowohl in x- als auch in y-Richtung zur Diskretisierung verwenden Dadurch ergibt sich Ωh alsein Gitter fuumlr das xij isin Ωh die Form xij = (minus1 + ihminus1 + jh) hat wobei i j isin 0 n minus 1gilt und n isin N die Anzahl der Gitterpunkte pro Zeile beziehungsweise Spalte im Gitter angibt ImFolgenden betrachten wir nur die Operationen innerhalb eines Zeitschrittes das heiszligt im Uumlbergang vont(l) nach t(l) + ∆t Dazu sei w0 wie oben als bekanntes Geschwindigkeitsfeld u

(x t(l)

)definiert und

wk k isin 1 2 3 4 bezeichnet die unterschiedlichen Geschwindigkeitsfelder innerhalb des ZeitschrittsNach diesen Vorbereitungen widmen wir uns nun Diskretisierungs- und Loumlsungsmethoden fuumlr die ein-zelnen Bestandteile von Gleichung (27) beziehungsweise Schema (28)

Kraft aufpraumlgenZuerst kann dem Fluid eine Kraft aufgepraumlgt werden Dies geschieht waumlhrend der Simulation durch denAnwender und soll nur ein Mal pro Zeitschritt erfolgen Deshalb koumlnnen wir die Annahme treffen dassdie Kraft uumlber den gesamten Zeitschritt konstant ist Somit ist eine Beruumlcksichtigung der Kraft zu Beginneines jeden Zeitschritts ausreichend Wir berechnen also im ersten Schritt unseres Loumlsers

w1 = w0 + ∆tf (29)

was eine gute Approximation der Wirkung der Kraft uumlber den Zeitschritt darstellt da wir ihren Einflussdurch die Multiplikation des Kraftfeldes f mit der Zeitschrittweite ∆t uumlber den ganzen Zeitschritt trans-portieren

KAPITEL 2 THEORETISCHE GRUNDLAGEN 9

AdvektionUm die Advektion des Fluids zu beruumlcksichtigen fassen wir die Gitterpunkte als die oben beschriebenenTeilchen beziehungsweise Fluidpartikel auf und muumlssen dann in jedem Zeitschritt die Geschwindigkeiteines solchen Partikels aktualisierenEine erste Idee waumlre es hierzu folgende explizite Methode zu betrachten Die Position r eines Partikelsveraumlndert sich mit der Geschwindigkeit also koumlnnen wir die Position so weit verschieben wie sich dasPartikel in der Zeit ∆t mit seiner Geschwindigkeit fortbewegt Also gilt

r(t(l) + ∆t

)= r

(t(l))

+ ∆tu(t(l))

was dem expliziten Eulerverfahren entspricht Allerdings ist diese Methode instabil fuumlr groszlige Zeitschritt-weitenWir betrachten deshalb die implizite Methode der Charakteristiken die die Stabilitaumlt des Verfahrens im-pliziert Zur genaueren Erlaumluterung dieses Verfahrens verweisen wir auf [Stam] und geben hier nur einegrobe Zusammenfassung Im Wesentlichen verfolgen wir jeden Punkt x isin Ω uumlber die Zeit ∆t entlangw1 zuruumlck Dadurch entsteht ein Pfad p (x t) von x zu einem Punkt x0 = p (xminus∆t) der auch alsStromlinie interpretiert werden kann Dies wird in Abbildung 23 verdeutlicht

Abbildung 23 Weg den ein Fluidpartikel in der Zeit zuruumlcklegt (vgl [Stam])

Wir setzen dann die neue Geschwindigkeit w2 im Punkt x als die Geschwindigkeit die im Punkt x0 zurvorherigen Zeit vorliegt also

w2 (x) = w1 (p (xminus∆t)) = w1 (xminus∆tw1 (x)) (210)

Durch das Verwenden der Methode der Charakteristiken liefert unser Vorgehen eine fuumlr beliebig groszligeZeitschrittweiten und Geschwindigkeiten unbedingt stabile numerische Loumlsung (vgl [Stam]) Das koumln-nen wir daran feststellen dass der maximale Wert des Geschwindigkeitsfeldes in diesem Schritt niegroumlszliger als im vorherigen Zeitschritt werden kann auszliger wir praumlgen eine externe Kraft auf Denn nachGleichung (210) gilt

max(w2

(l))le max

(w1

(l))

(29)= max

(w0

(l) + ∆tf (l))

f (l)equiv0= max

(w4

(lminus1))

wobei ()(l) die entsprechende Groumlszlige im l-ten Zeitschritt bezeichnet Es ist f (l) equiv 0 da wir hier keineAnwender-Interaktion beruumlcksichtigenFuumlr Details zur Implementierung der Methode der Charakteristiken verweisen wir auf Kapitel 31

KAPITEL 2 THEORETISCHE GRUNDLAGEN 10

DiffusionHier betrachten wir eine Gleichung der Form

partu

partt= νnabla middot nablau (211)

Um diese numerisch zu loumlsen diskretisieren wir zunaumlchst den Laplace-Operatornabla middotnabla mit finiten Diffe-renzen im Ort und wenden dann ein Zeitschrittverfahren an Die Anwendung vonnablamiddotnabla auf das Geschwin-digkeitsfeld u erfolgt komponentenweise in x- beziehungsweise y-Richtung weshalb wir vereinfachenddie Diskretisierung des Operators angewendet auf ein hinreichend glattes Skalarfeld s betrachten Wirstellen also die Diskretisierung vonnabla middot nablas = part2s

partx2+ part2s

party2im R2 auf Dann gilt

(nabla middot nablas)ij asympsi+1j minus 2sij + siminus1j

h2+sij+1 minus 2sij + sijminus1

h2(212)

mit sij = s (xij) und analog (nabla middot nablas)ij = nabla middot nablas (xij) fuumlr xij isin Ωh Betrachten wir das durchGleichung (212) diskretisierte Skalarfeld s in jedem Gitterpunkt koumlnnen wir den diskretisierten Laplace-Operator als Matrix auffassen welche die folgende Gestalt aufweist

1

h2

Bn In

In In

In Bn

mit Bn =

minus4 1

1 1

1 minus4

isin Rntimesn (213)

Hierbei bezeichnet In die Einheitsmatrix der Dimension ntimesn Wenden wir auf die im Ort diskretisierteGleichung (211) ein explizites Zeitschrittverfahren der Form

u (x t+ ∆t) = u (x t) + ν∆tnabla middot nablau (x t) (214)

an so tritt erneut das Problem der Instabilitaumlt fuumlr groszlige Zeitschrittweiten ∆t beziehungsweise groszligekinematische Viskositaumlten ν auf Diese Schwierigkeit taucht auf da die Methode einem expliziten Euler-Verfahren entspricht und daher aumlhnliche Eigenschaften bezuumlglich der Stabilitaumlt aufweist Um eine stabileLoumlsungsmethode zu konstruieren verwenden wir statt des in Gleichung (214) angefuumlhrten ein implizitesVerfahren was sich durch Uumlbertragen auf unsere Schreibweise innerhalb eines Zeitschrittes schreibenlaumlsst als

(Iminus ν∆tnabla middot nabla)w3 = w2 (215)

wobei I den Identitaumltsoperator darstellt Diese Gleichung entspricht einer Poisson-Gleichung fuumlr dasGeschwindigkeitsfeld w3 Setzen wir den diskretisierten Laplace-Operator aus Gleichung (213) in Glei-chung (215) ein so ergibt sich die Darstellung fuumlr die Systemmatrix des zu loumlsenden Gleichungssystemsals

ν∆t

h2

Bn minusInminusIn

minusInminusIn Bn

mit Bn =

4 + h2

ν∆t minus1

minus1 minus1

minus1 4 + h2

ν∆t

(216)

Das daraus resultierende Gleichungssystem muumlssen wir nun effizient loumlsen worauf wir in Kapitel 31eingehen

KAPITEL 2 THEORETISCHE GRUNDLAGEN 11

ProjektionIm Projektionsschritt betrachten wir Gleichung (24) und erhalten wie im Diffusionsschritt eine Poisson-Gleichung zur Berechnung des Druckfeldes p Auch hier ergibt sich durch die Diskretisierung vonnablamiddotnablaein duumlnn besetztes lineares Gleichungssystem mit rechter Seite nabla middot w3 welches wir loumlsen muumlssen umals Abschluss unseres Algorithmus die aktualisierte Geschwindigkeit uumlber die Gleichung

u (x t+ ∆t) = w4 = w3 minusnablap (217)

berechnen zu koumlnnen Dazu verwenden wir folgende Diskretisierungen der auftretenden Operatoren

(nablas)ij =

(parts

partxparts

party

)ij

asymp(si+1j minus siminus1j

2hsij+1 minus sijminus1

2h

)(218)

(nabla middot v)ij =

(partvx

partx+partvy

party

)ij

asymp

(vxi+1j minus vximinus1j

2h+vyij+1 minus v

yijminus1

2h

) (219)

wobei s erneut ein Skalarfeld und v = (vx vy) ein zweidimensionales Vektorfeld mit x- und y-Komponentebezeichnet Analog zu der Schreibweise in Gleichung (212) repraumlsentieren ()ij die entsprechendenGroumlszligen ausgewertet im Punkt xij isin Ωh

Nun sind wir in der Lage im naumlchsten Zeitschritt das Geschwindigkeitsfeld zu berechnen und schlieszligensomit die Diskretisierung der Navier-Stokes Gleichungen (21) und (22) ab Dazu fassen wir die wesent-lichen Ergebnisse dieses Unterkapitels in algorithmischer Form zusammen Wir orientieren uns dabei anden in Schema (28) angefuumlhrten Schritten und erhalten so ein kompaktes numerisches Loumlsungsverfahrender Navier-Stokes Gleichungen

Algorithmus 241 (bdquoStable Fluidsldquo Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen nach[Stam])Sei ein initiales Geschwindigkeitsfeld w0

(0) (x) = u (x 0) gegebenFuumlr l = 1 L

1 Kraft aufpraumlgen w1(l) (x) = w0

(lminus1) (x) + ∆tf (l) (x)

2 Advektion w2(l) (x) = w1

(l)(xminus∆tw1

(l) (x))

3 Diffusion bestimme w3(l) uumlber (Iminus ν∆tnabla middot nabla)w3

(l) = w2(l)

4 Projektion w4(l) = w3

(l) minusnablap(l) wobei sich p(l) ergibt aus nabla middot nablap(l) = nabla middotw3(l)

5 Aktualisierung w0(l) (x) = u (x l middot∆t) = w4

(l) (x)

Die Anzahl L + 1 der durchzufuumlhrenden Zeitschritte legen wir dadurch fest wie lange wir die Simu-lation ausfuumlhren Das Kraftfeld f (l) wird durch den Anwender von auszligen bestimmt und steht in jedemZeitschritt aktualisiert zur Verfuumlgung Die genaue Umsetzung der Schritte in Algorithmus 241 stellenwir in Kapitel 3 vor

Kapitel 3

Implementierung

Nachdem wir in Kapitel 2 auf die in unserer Simulation verwendete Theorie bezuumlglich Modell Dis-kretisierung und numerischer Loumlsung eingegangen sind wollen wir uns nun ihrer Umsetzung und derRealisierung der Visualisierung und Interaktion auf einem Tablet-Computer widmen Die Stroumlmungs-simulation fuumlhren wir auf dem Asus EeePad Transformer TF101 auf dem das Betriebssystem Android403 installiert ist in einer App aus Details zur Hardware des verwendeten Tablet-Computers findensich in Kapitel 44 Der Anwender hat waumlhrend der Simulation die Moumlglichkeit die Stroumlmung einesFluids durch Beruumlhren des Bildschirms zu beeinflussen Stroumlmungssimulationen wie sie etwa bei [Stam]oder [Harris] beschrieben werden koumlnnen vom Nutzer durch Interaktion mit der Maus beeinflusst wer-den auf einem Tablet-Computer besteht jedoch die Moumlglichkeit dies mit einem Finger auf dem Bild-schirm durchzufuumlhren Dadurch wirkt die Simulation fuumlr den Betrachter realer Die Moumlglichkeit solcheComputer zur Stroumlmungssimulation einzusetzen wird dadurch eroumlffnet dass Tablet-Computer hinsicht-lich ihrer Rechenleistung immer leistungsfaumlhiger werdenBevor wir auf die konkrete Implementierung des in Kapitel 2 vorgestellten Verfahrens eingehen wollenwir zunaumlchst das Vorgehen bei einer App-Programmierung in der Programmiersprache Java fuumlr das An-droid-Betriebssystem erlaumlutern wobei wir uns an [Android Developer] orientieren Zunaumlchst installierenwir eine Software-Entwicklungsumgebung wie etwa Eclipse1 in der wir die eigentliche Programmie-rung durchfuumlhren Ergaumlnzend benoumltigen wir das Android Software Development Kit sowie die AndroidDevelopment Tools die wir in die Entwicklungsumgebung einbinden muumlssen Anschlieszligend koumlnnen wirein neues Android App Project erstellen welches die App repraumlsentiert Dabei werden einige Dateienautomatisch erstellt wie etwa die Manifest-Datei die eine zentrale Rolle einnimmt da sie die funda-mentalen Charakteristiken der App beschreibt und jede ihrer Komponenten definiert Die Programmie-rung einer App unterscheidet sich vor allem dadurch von einer bdquogewoumlhnlichenldquo Java-Programmierungals dass zum korrekten Erstellen der App viele spezielle Funktionen vom System verlangt werden diewir implementieren muumlssen Auch die Umsetzung der Visualisierung mit Hilfe der OpenGL ES 20-Bibliothek verlangt ein gesondertes Vorgehen Wir muumlssen die Visualisierung in eine eigene Klasse aus-lagern diese entsprechend kennzeichnen und erneut vom System verlangte Funktionen integrieren Aumlhn-lich verhaumllt es sich bei der Beruumlcksichtigung der Anwender-InteraktionUm eine App schlieszliglich auszufuumlhren bestehen zwei Moumlglichkeiten Einerseits koumlnnen wir die App aufeinem externen Android-Geraumlt starten zum Beispiel einem Tablet-Computer andererseits den Emula-tor nutzen Dabei handelt es sich um eine sogenannte Android Virtual Device die auf dem Computerausgefuumlhrt wird auf dem sich die Entwicklungsumgebung befindet Die Virtual Device entspricht ei-nem externen Geraumlt welches auf dem Computer simuliert wird Es empfiehlt sich die App zunaumlchstim Emulator zu testen da bei eventuellen Programmierfehlern das externe Geraumlt durch Uumlberhitzungoder aumlhnliches beschaumldigt werden kann Bisher ist es nicht moumlglich Apps auf dem Emulator zu tes-ten die sich der Bibliothek OpenGL ES 20 zur Darstellung von Grafiken bedienen wie wir sie fuumlr

1Fuumlr naumlhere Informationen verweisen wir auf httpwwweclipseorg

12

Inhaltsverzeichnis

1 Einleitung 1

2 Theoretische Grundlagen 321 Die Navier-Stokes Gleichungen 322 Anfangs- und Randbedingungen 523 Projektionsverfahren und die Helmholtz-Hodge-Zerlegung 624 Diskretisierung und numerische Loumlsung 8

3 Implementierung 1231 Loumlser 13

311 Kraft aufpraumlgen 13312 Advektion 14313 Diffusion 14314 Projektion 15

32 Visualisierung 1633 Interaktion 1934 Demonstration des Gesamtsystems 20

4 Tests 2241 Validierung 22

411 Numerische Stabilitaumlt 22412 Physikalisch richtiges Verhalten 23

42 Parametertests 26421 Viskositaumlt 27422 Zeitschrittweite 30423 Symmetrietest 33

43 Validierung der Interaktions-Komponente 38431 Physikalisch korrekte Umsetzung 38432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent 40

44 Zeitmessungen und Tuning 43441 Analyse des Loumlsers 43442 Analyse der Visualisierungs-Komponente 46443 Analyse der Interaktions-Komponente 50444 Zusammenfassung 52

5 Diskussion und Fazit 54

Kapitel 1

Einleitung

In dieser Bachelorarbeit stellen wir ein Verfahren zur Stroumlmungssimulation in Form einer App auf Tablet-Computern vor Aufgrund der massiven Hardwareverbesserung in der letzten Zeit ist es mittlerweile moumlg-lich solche Computer fuumlr anspruchsvolle Simulationen zu verwenden Insbesondere koumlnnen wir dadurchdie Echtzeit und Interaktion auf sehr natuumlrliche Weise realisieren Das Ziel dieser Arbeit ist es somiteine neue Hardwarearchitektur inklusive ihrer intuitiven Interaktionsmoumlglichkeiten auf die Eignung zurphysikalisch korrekten numerischen Stroumlmungssimulation zu evaluieren und dabei experimentell zu er-gruumlnden ob und in welchem Rahmen eine Echtzeit-Simulation erreicht werden kann Dazu betrachtenwir ein Fluid welches sich in dem zweidimensionalen Gebiet Ω = [minus1 1]2 sub R2 befindet Als ma-thematisches Modell verwenden wir die inkompressiblen Navier-Stokes Gleichungen denen wir uns inKapitel 2 widmen Patrick Westervoszlig erlaumlutert in Abschnitt 21 die physikalische Bedeutung dieser Glei-chungen und geht in Unterkapitel 22 auf Anfangs- und Randbedingungen die fuumlr die Wohlgestelltheitdes Problems notwendig sind ein Danach uumlberfuumlhrt er die Gleichungen in Abschnitt 23 in eine zurLoumlsung geeignetere Form Anschlieszligend entwickelt Niklas Borg in Abschnitt 24 ein numerisches Louml-sungsverfahren und geht zusaumltzlich auf die Diskretisierung dieses Verfahrens mittels finiter DifferenzeneinIn Kapitel 3 praumlsentieren wir die programmiertechnische Umsetzung des im vorherigen Kapitel vorge-stellten Verfahrens die wir aufgrund ihrer Komplexitaumlt gemeinsam durchgefuumlhrt haben und gehen aufeinige kompliziertere Strukturen ein Weiterhin stellen wir zwei fuumlr die Stroumlmungssimulation auf Tablet-Computern wesentliche Komponenten vor die Visualisierung des zuvor berechneten Geschwindigkeits-feldes und die Interaktion eines Anwenders Hierbei verwenden wir die OpenGL ES 20-Bibliothekdie uumlblicherweise zur Realisierung der beiden Elemente auf Tablet-Computern genutzt wirdIn Kapitel 4 fuumlhren wir verschiedene Tests durch um unsere Software auf ihre Richtigkeit zu pruumlfenDazu untersucht Niklas Borg in Abschnitt 41 die numerische Stabilitaumlt und physikalische Korrektheitunserer Simulation Damit ist gemeint dass sich die Simulation nicht verselbststaumlndigt sich also einstatisches Fluid nicht selbst anregt Daruumlber hinaus vergleicht er den gaumlngigen Testfall Driven Cavi-ty durchgefuumlhrt in unserer Simulationsumgebung mit einer Referenzloumlsung In Abschnitt 42 fuumlhrt erzudem einige Parametertests durch um die Auswirkungen der verschiedenen Variablen unseres Loumlsersauf die Simulation zu bewerten Dabei betrachtet er die kinematische Viskositaumlt ν des Fluids den imVerfahren verwendeten Zeitschritt ∆t und die Anzahl maxiter der durchzufuumlhrenden Iterationen imeingesetzten Jacobi-LoumlserIn Abschnitt 43 analysiert Patrick Westervoszlig die Umsetzung der Anwender-Interaktion anhand zwei-er verschiedener Testfaumllle die sich in ihrer Komplexitaumlt unterscheiden Danach erarbeitet er in Ab-schnitt 44 mit Hilfe von Zeitmessungen der einzelnen Implementierungs-Komponenten potentielle Ver-besserungsmoumlglichkeiten der Software um zu beurteilen in wie weit eine Echtzeit-Simulation auf Tablet-Computern erreicht werden kann Dazu vergleicht und interpretiert er die Laufzeiten des Loumlsers derVisualisierungs- sowie der Interaktions-Komponente fuumlr verschiedene Gitterschrittweiten h der Diskre-tisierung

1

KAPITEL 1 EINLEITUNG 2

Zum Schluss fassen wir in Kapitel 5 die wesentlichen Erkenntnisse zusammenEine genaue Uumlbersicht uumlber die Aufteilung der Bearbeitung dieser Bachelorarbeit geben wir in Ta-belle 11

Kapitel bearbeitet von21 Patrick Westervoszlig22 Patrick Westervoszlig23 Patrick Westervoszlig24 Niklas Borg3 Niklas Borg und Patrick Westervoszlig

41 Niklas Borg42 Niklas Borg43 Patrick Westervoszlig44 Patrick Westervoszlig

Tabelle 11 Aufteilung der Bearbeitung der Bachelorarbeit

Kapitel 2

Theoretische Grundlagen

Zur Simulation einer Stroumlmung in einem Fluid in einem bestimmten Zeitintervall benoumltigen wir einemathematische Beschreibung seines Verhaltens Ein gutes Modell dafuumlr sind die Navier-Stokes Glei-chungen da sie die fuumlr die Darstellung eines Fluids wesentliche Komponente die Entwicklung der Ge-schwindigkeit charakterisieren Auszligerdem bilden sie viele physikalische Effekte ab wie zum BeispielTurbulenzen und Grenzschichten innerhalb der Stroumlmung Deshalb wollen wir diese Gleichungen imFolgenden genauer betrachten Dabei orientieren wir uns an den Ausfuumlhrungen von [Stam] und [Harris]Das Ziel des im weiteren Verlauf dieser Arbeit entwickelten Loumlsungsverfahrens ist die Generierung ei-nes fluidartigen Verhaltens welches zwar auf den Navier-Stokes Gleichungen basiert dessen berechnetesGeschwindigkeitsfeld die Gleichungen jedoch nicht exakt erfuumlllt Die hier vorgestellte Methode wurdeurspruumlnglich fuumlr Computeranimationen entworfen und nicht fuumlr Anwendungen aus den Ingenieurswis-senschaften was unser leicht inexaktes Vorgehen zur Fluidsimulation rechtfertigt

21 Die Navier-Stokes Gleichungen

Zunaumlchst treffen wir einige in der Fluidsimulation durchaus uumlbliche Annahmen die auf eine vereinfach-te Form der Navier-Stokes Gleichungen fuumlhren und trotzdem die Qualitaumlt des mathematischen Modellserhalten Dazu nehmen wir die Dichte ρ des Fluids sowie seine Temperatur θ als konstant bezuumlglichOrt und Zeit an wodurch wir die Beschreibung eines inkompressiblen Fluids erhalten Aufgrund die-ser Annahmen muumlssen wir uns in der Simulation auf sogenannte bdquonewtonscheldquo Fluide beschraumlnken DieEntwicklung eines solchen Fluids in einem zweidimensionalen Gebiet Ω sub R2 uumlber einem ZeitintervallI = [0 T ] mit T isin R+ koumlnnen wir durch die inkompressiblen Navier-Stokes Gleichungen charakterisie-ren welche das Fluidverhalten mathematisch beschreiben

partu

partt= minus (u middot nabla)uminus 1

ρnablap+ νnabla middot nablau + f (21)

nabla middot u = 0 (22)

Dabei bezeichnen wir mit u = u (x t) die Geschwindigkeit mit p = p (x t) den Druck mit ν diekinematische Viskositaumlt und mit ρ die Dichte des Fluids Es ist dabei zu beachten dass wir in unsererSimulation nur den Druck innerhalb des Fluids beruumlcksichtigen und den Atmosphaumlrendruck vernachlaumls-sigen Durch die Groumlszlige f = f (x t) definieren wir eine externe Kraft im Punkt x isin Ω zur Zeit t isin I Hierbei treffen wir die Konvention dass die fett gedruckten Ausdruumlcke vektorwertige Groumlszligen in derRegel Vektorfelder und die kursiven skalare Groumlszligen repraumlsentieren Fuumlr Details zu den Navier-StokesGleichungen und deren Herleitung aus den allgemeinen Erhaltungsgleichungen der Kontinuumsmecha-nik verweisen wir auf [Anderson]Im Folgenden wollen wir uns kurz den einzelnen Bestandteilen von Gleichung (21) widmen und ihre

3

KAPITEL 2 THEORETISCHE GRUNDLAGEN 4

physikalische Bedeutung erlaumlutern wozu wir einige Begriffe definieren

AdvektionUumlblicherweise kann ein Fluid Objekte oder andere Substanzen transportieren In unserem Fall beschraumln-ken wir uns lediglich darauf dass es bdquosich selbstldquo transportiert Es wird also durch die eigene Ge-schwindigkeit fortbewegt Dieses Verhalten nennt sich Advektion und wird durch den Term minus (u middot nabla)ubeschrieben der den konvektiven Transport des Fluids darstellt Die Beruumlcksichtigung dieses Effekteszieht die Konsequenz nach sich dass die Navier-Stokes Gleichungen nichtlinear sind

DruckDie Teilchen in einem Fluid werden automatisch fortbewegt Dies fuumlhrt dazu dass sie sich gegenseitigan- und abstoszligen Wird eine Kraft auf das Fluid aufgepraumlgt so wird diese ebenfalls durch die Teilchenuumlbertragen Diese beiden Phaumlnomene fuumlhren zu einer Druckentwicklung im Fluid was letztendlich in ei-ner Beschleunigung der Teilchen resultiert Der Ausdruck minus1

ρnablap in Gleichung (21) repraumlsentiert diesenphysikalischen Sachverhalt in Abhaumlngigkeit von der Dichte ρ des Fluids und des auf das Fluid wirkendenDrucks p

DiffusionDieses physikalische Phaumlnomen haumlngt stark mit der Zaumlhfluumlssigkeit eines Fluids welche uumlber seine kine-matische Viskositaumlt ν beschrieben wird zusammen und hat einen groszligen Einfluss auf das FluidverhaltenZur Erlaumluterung geben wir zunaumlchst eine rein formale Definition der Viskositaumlt (vgl [Arlt])

Definition 211 (Viskositaumlt)Wir betrachten folgenden Versuchsaufbau

Abbildung 21 Versuchsaufbau zur Definition der Viskositaumlt

Im unteren Teil von Abbildung 21 befindet sich eine feststehende unbewegliche Wand M und im Ab-stand z zu dieser eine bewegliche Wand N mit der Oberflaumlche A Der Raum zwischen den Waumlnden istmit dem zu untersuchenden Fluid gefuumlllt Um die WandN mit der konstanten Geschwindigkeit v parallelzu M zu bewegen wird die Kraft benoumltigt die aus dem Newtonschen Gesetz

KAPITEL 2 THEORETISCHE GRUNDLAGEN 5

F = η middotA middot dv

dz

hervorgeht Somit ist die Kraft F proportional zu der Oberflaumlche A und dem Geschwindigkeits-gradienten dv

dz welcher der Beschleunigung der beweglichen Wand N entspricht Der Proportionali-taumltsfaktor η heiszligt dynamische Viskositaumlt und ist ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres Fluids Es gilthierbei je groumlszliger die Viskositaumlt desto zaumlhfluumlssiger das Fluid

Zu unterscheiden sind dabei zwei verschiedene Begriffe der Viskositaumlt Die dynamische Viskositaumlt η unddie kinematische Viskositaumlt ν welche wir in den Navier-Stokes Gleichungen (21) und (22) benoumltigenWir wollen nun beide Begriffe in Zusammenhang setzen Sei ρ die Dichte und η die dynamische Visko-sitaumlt unseres Fluids Dann ergibt sich die kinematische Viskositaumlt zu

ν =η

ρ (23)

Zaumlhe Fluumlssigkeiten also solche mit einer hohen Viskositaumlt reagieren traumlger auf Bewegungen als duumlnn-fluumlssige oder auch Fluide mit kleinerer Viskositaumlt wie etwa Olivenoumll im Vergleich zu Wasser DieserEffekt nennt sich Diffusion und geht durch den Term νnabla middotnablau in das mathematische Modell ein der dendiffusiven Transport des Fluids beruumlcksichtigt

KraumlfteWie bei der Beschreibung des Drucks bereits erwaumlhnt fuumlhrt das Aufpraumlgen von Kraumlften zur Beschleuni-gung der Fluidteilchen Moumlglich sind externe Kraumlfte also solche die bdquovon auszligenldquo auf das Fluid wirkenund Koumlrper- beziehungsweise Volumenkraumlfte die etwa durch die Erdbeschleunigung hervorgerufen wer-den An dieser Stelle sei schon einmal erwaumlhnt dass die externen Kraumlfte in der Simulation interaktivdurch den Anwender integriert werden koumlnnen (vgl Abschnitt 33)

Damit das Problem welches durch die Navier-Stokes Gleichungen formuliert wird wohlgestellt istmuumlssen wir zusaumltzlich sogenannte Anfangs- und Randbedingungen einfuumlhren auf die wir im folgendenAbschnitt eingehen

22 Anfangs- und Randbedingungen

Sowohl die Geschwindigkeit u als auch der Druck p treten in den Navier-Stokes Gleichungen als Un-bekannte auf und muumlssen in jedem Zeitschritt berechnet und aktualisiert werden Daher muumlssen wirgeeignete Anfangs- und Randbedingungen fuumlr beide Groumlszligen vorgebenDie Anfangsbedingung fuumlr das Druckfeld ist von Testfall zu Testfall unterschiedlich So nehmen wir ineinem Beispiel den initialen Druck als Null an womit p equiv 0 in Ω gilt Andererseits koumlnnen wir fuumlrden Druck sogenannte Druckspitzen vorschreiben wie wir sie in Kapitel 42 setzen Fuumlr das Geschwin-digkeitsfeld waumlhlen wir immer u equiv 0 als Anfangsbedingung und erzeugen Dynamik entweder durchexterne Kraumlfte wie etwa in Abschnitt 431 oder uumlber RandbedingungenIm Allgemeinen legen wir als Randbedingung fuumlr die Geschwindigkeit die sogenannte bdquono-slipldquo-Bedingung u|partΩ equiv 0 fest Wir setzen die Geschwindigkeit am Rand also auf Null was bedeutet dass dasFluid am Gebietsrand haften bleibt Wir koumlnnen aber auch wie beim Testfall Driven Cavity beschriebenan einer Kante des Rechengebiets einen von Null verschiedenen Wert vorschreiben Wir tragen somit ei-ne Tangentialgeschwindigkeit an und erzeugen mit ihrer Hilfe Dynamik im Fluid (vgl Abschnitt 412)Als Randbedingung fuumlr den Druck legen wir fest dass keine Aumlnderung in Normalenrichtung stattfindet

KAPITEL 2 THEORETISCHE GRUNDLAGEN 6

also partppartn |partΩ equiv 0 gilt wobei n den aumluszligeren Normalenvektor von Ω bezeichnet

Die verschiedenen Anfangs- und Randbedingungen sind miteinander und mit der Anwender-Interaktionder wir uns in Abschnitt 43 widmen kombinierbar Wir koumlnnen somit eine Vielzahl von Testfaumlllen kon-struieren von denen wir eine Auswahl in Kapitel 4 praumlsentieren

23 Projektionsverfahren und die Helmholtz-Hodge-Zerlegung

Nachdem wir zuvor alle Komponenten der Navier-Stokes Gleichungen aus physikalischer Sicht betrach-tet und Anfangs- sowie Randbedingungen eingefuumlhrt haben wollen wir sie nun in eine zum Loumlsen geeig-netere Form bringen und anschlieszligend ein Vorgehen zur Loumlsung dieser Gleichungen entwickeln Dabeiist die Art der Diskretisierung des von Raum- und Zeitvariablen abhaumlngigen Problems entscheidendZunaumlchst nehmen wir eine simple Zeitdiskretisierung vor indem wir das Zeitintervall I = [0 T ] inTeilintervalle zerlegen Anschlieszligend betrachten wir Gleichung (21) innerhalb eines Zeitschritts unddiskretisieren die auftretenden Operatoren im Ort (vgl Kapitel 24) Im Folgenden koumlnnen wir daherdie einzelnen Bestandteile dieser Gleichung als zeitunabhaumlngig ansehen da wir das Loumlsungsverfahreninnerhalb eines Zeitschritts entwickelnUm die Gleichungen in ein besser zu loumlsendes System zu uumlberfuumlhren betrachten wir als Hilfsmittelzunaumlchst die sogenannte Helmholtz-Hodge Zerlegung (vgl [Chorin])

Satz 231 Sei Ω sub R2 ein Gebiet mit glattem Rand partΩ Dann kann jedes Vektorfeld w zerlegt werdenin die Form

w = u +nablapwobei nabla middot u = 0 gilt das Vektorfeld u also divergenzfrei ist Auszligerdem ist u parallel zu partΩ das heiszligtu middot n = 0 mit dem aumluszligeren Normalenvektor n von Ω p bezeichnet ein Skalarfeld

In jedem Zeitschritt muumlssen wir Gleichung (21) loumlsen wobei wir gewaumlhrleisten muumlssen dass Glei-chung (22) gilt Wenn wir nun davon ausgehen durch das Loumlsen von Gleichung (21) ein Geschwindig-keitsfeld w erhalten zu haben so muss nicht zwangslaumlufig nabla middotw = 0 gelten Dies erreichen wir durchAnwenden von Satz 231 auf das Geschwindigkeitsfeld w Wir setzen somit am Ende des Zeitschrittsdas aktualisierte Geschwindigkeitsfeld analog zu obigem Satz als u = w minusnablapJetzt stellt sich die Frage wie das Skalarfeld p zu berechnen ist Wenden wir den Divergenz-Operatornablamiddot auf beide Seiten der Gleichung aus Satz 231 an so erhalten wir

nabla middotw = nabla middot u︸ ︷︷ ︸=0

+nabla middot nablap

hArr nabla middotw = nabla middot nablap (24)

Setzen wir also die Loumlsung von Gleichung (21) als bekannt voraus so koumlnnen wir durch Loumlsen derPoisson-Gleichung (24) den Druck p ermitteln mit dem wir das Geschwindigkeitsfeld w so modifizie-ren koumlnnen dass es Gleichung (22) erfuumlllt Als naumlchstes muumlssen wir uns damit beschaumlftigen wie wir dasvorlaumlufige Geschwindigkeitsfeld w berechnen koumlnnen

Zunaumlchst definieren wir hierzu mit Hilfe von Satz 231 einen linearen Operator P der ein Vektorfeld wauf seinen divergenzfreien Teil projiziert Fuumlr diesen Operator gilt dann

P (w) = P (u) + P (nablap) da P linear ist

P (w) = u wegen Satz 231 und (25)

P (u) = u nach Voraussetzung

KAPITEL 2 THEORETISCHE GRUNDLAGEN 7

woraus insgesamt

P (nablap) = 0 (26)

folgtAnhand von Gleichung (25) koumlnnen wir uns mit dem Schwarzschen Satz (vgl [Forster]) uumlberlegendass P

(partupartt

)= partu

partt gilt Der Satz von Schwarz besagt dass bei einer q-mal stetig partiell differen-zierbaren Funktion die ersten q Ableitungen vertauscht werden duumlrfen Bei uns gilt nach Voraussetzungu isin C2 (Ω)capC1 (I) da die Ausdruumlckenablamiddotnablau und partu

partt in Gleichung (21) eine entsprechende Glattheit desGeschwindigkeitsfeldes bezuumlglich der Variablen (x t) verlangen Dabei bezeichnet Ck (Ul) den Raumder k-mal stetig partiell differenzierbaren Funktionen uumlber U2 = Ω sub R2 beziehungsweise U1 = I sub Rmit k l isin 1 2 Somit folgt

nabla middot partupartt

=part

partt(nabla middot u) = 0

Wenden wir nun den Operator P auf Gleichung (21) an und nutzen seine Linearitaumlt undGleichung (26) aus so erhalten wir

partu

partt= P (minus (u middot nabla)u + νnabla middot nablau + f) (27)

Aus Gleichung (27) ergibt sich direkt der von uns verwendete Algorithmus zur Loumlsung der Navier-StokesGleichungen der sich in vier Schritte gliedert

u (middot t) = w0Kraft aufpraumlgenminusminusminusminusminusminusminusminusrarr w1

Advektionminusminusminusminusminusrarr w2Diffusionminusminusminusminusminusrarr w3

Projektionminusminusminusminusminusrarr w4 = u (middot t+ 1) (28)

Wir nehmen an dass uns das Geschwindigkeitsfeld u zum Zeitpunkt t bekannt ist und setzenw0 (x) = u (x t) Pro Zeitschritt loumlsen wir die Gleichung (21) durch sogenanntes bdquoOperator-Splittingldquosukzessiv numerisch Wie in allen Projektionsmethoden entsteht auch hier durch das Splitting ein nu-merischer Fehler wodurch wir Gleichung (21) nicht mehr exakt loumlsen Leider geht [Stam] in seinerOriginalarbeit nicht auf die Ordnung des Verfahrens ein aufgrund der Struktur des Verfahrens und derAumlhnlichkeit zu Chorinschen Projektionsmethoden (vgl [Anderson]) ist aber nicht von einer hohen Ord-nung auszugehen Schlieszliglich gewaumlhrleisten wir durch das Anwenden des oben definierten Projektions-operators P dass Gleichung (22) erfuumlllt ist was anschaulich aus Abbildung 22 hervorgeht

Abbildung 22 Sukzessive Berechnung der Geschwindigkeit in einem Punkt innerhalb eines Zeitschritts(vgl [Stam])

Am Ende eines jeden Zeitschritts setzen wir w0 = w4 Da wir wie oben beschrieben ausgehend vonw0 innerhalb eines Zeitschrittes operieren haumlngen die Geschwindigkeitsfelder wk k isin 0 1 2 3 4

KAPITEL 2 THEORETISCHE GRUNDLAGEN 8

waumlhrend der Berechnung nur von der Ortsvariablen x ab Das Vektorfeld w4 entspricht schlieszliglich demGeschwindigkeitsfeld u zum Zeitpunkt t+∆t also u (x t+ ∆t) mit der Zeitschrittweite ∆t isin R+ DieSimulation erhalten wir letztendlich durch Iteration der in Schema (28) beschriebenen Vorgehensweiseuumlber die Zeitschritte Daraus ergibt sich durch Diskretisierung der auftretenden Operatoren ein nume-risches Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen (21) und (22) worauf wir im naumlchstenAbschnitt eingehen

24 Diskretisierung und numerische Loumlsung

Wir erlaumlutern in diesem Abschnitt die in Schema (28) angefuumlhrten Schritte und stellen Diskretisierungs-beziehungsweise Loumlsungstechniken vor um abschlieszligend ein kompaktes Loumlsungsverfahren der Navier-Stokes Gleichungen aufzustellen Zur Diskretisierung aller auftretenden Operatoren verwenden wir indieser Arbeit meist finite Differenzen zweiter Ordnung Approximationen abweichender Ordnung sindbeispielsweise bei der Behandlung von Randbedingungen noumltig auf die wir in Abschnitt 314 naumlhereingehenWie in Abschnitt 23 bereits erwaumlhnt diskretisieren wir das durch die Navier-Stokes Gleichungen (21)und (22) und Anfangs- sowie Randbedingungen gestellte Problem zuerst in der Zeit und anschlieszligendim Ort Dazu waumlhlen wir eine aumlquidistante Zerlegung des Zeitintervalls in L Teilintervalle der Form

I = [0 T ] =

L⋃l=1

[t(lminus1) t(l)

]

wobei t(l) = l middot∆t und T = L middot∆t gilt Die folgenden Diskretisierungen im Ort fuumlhren wir nun jeweilszu einem festen Zeitpunkt t(l) durch weshalb die auftretenden Groumlszligen zeitunabhaumlngig sindFuumlr unsere Simulation betrachten wir das quadratische Rechengebiet Ω = [minus1 1]2 sub R2 in dem sichdas Fluid befinden soll Davon ausgehend definieren wir ein diskretes Gebiet Ωh mit Schrittweite h isin Rdie wir sowohl in x- als auch in y-Richtung zur Diskretisierung verwenden Dadurch ergibt sich Ωh alsein Gitter fuumlr das xij isin Ωh die Form xij = (minus1 + ihminus1 + jh) hat wobei i j isin 0 n minus 1gilt und n isin N die Anzahl der Gitterpunkte pro Zeile beziehungsweise Spalte im Gitter angibt ImFolgenden betrachten wir nur die Operationen innerhalb eines Zeitschrittes das heiszligt im Uumlbergang vont(l) nach t(l) + ∆t Dazu sei w0 wie oben als bekanntes Geschwindigkeitsfeld u

(x t(l)

)definiert und

wk k isin 1 2 3 4 bezeichnet die unterschiedlichen Geschwindigkeitsfelder innerhalb des ZeitschrittsNach diesen Vorbereitungen widmen wir uns nun Diskretisierungs- und Loumlsungsmethoden fuumlr die ein-zelnen Bestandteile von Gleichung (27) beziehungsweise Schema (28)

Kraft aufpraumlgenZuerst kann dem Fluid eine Kraft aufgepraumlgt werden Dies geschieht waumlhrend der Simulation durch denAnwender und soll nur ein Mal pro Zeitschritt erfolgen Deshalb koumlnnen wir die Annahme treffen dassdie Kraft uumlber den gesamten Zeitschritt konstant ist Somit ist eine Beruumlcksichtigung der Kraft zu Beginneines jeden Zeitschritts ausreichend Wir berechnen also im ersten Schritt unseres Loumlsers

w1 = w0 + ∆tf (29)

was eine gute Approximation der Wirkung der Kraft uumlber den Zeitschritt darstellt da wir ihren Einflussdurch die Multiplikation des Kraftfeldes f mit der Zeitschrittweite ∆t uumlber den ganzen Zeitschritt trans-portieren

KAPITEL 2 THEORETISCHE GRUNDLAGEN 9

AdvektionUm die Advektion des Fluids zu beruumlcksichtigen fassen wir die Gitterpunkte als die oben beschriebenenTeilchen beziehungsweise Fluidpartikel auf und muumlssen dann in jedem Zeitschritt die Geschwindigkeiteines solchen Partikels aktualisierenEine erste Idee waumlre es hierzu folgende explizite Methode zu betrachten Die Position r eines Partikelsveraumlndert sich mit der Geschwindigkeit also koumlnnen wir die Position so weit verschieben wie sich dasPartikel in der Zeit ∆t mit seiner Geschwindigkeit fortbewegt Also gilt

r(t(l) + ∆t

)= r

(t(l))

+ ∆tu(t(l))

was dem expliziten Eulerverfahren entspricht Allerdings ist diese Methode instabil fuumlr groszlige Zeitschritt-weitenWir betrachten deshalb die implizite Methode der Charakteristiken die die Stabilitaumlt des Verfahrens im-pliziert Zur genaueren Erlaumluterung dieses Verfahrens verweisen wir auf [Stam] und geben hier nur einegrobe Zusammenfassung Im Wesentlichen verfolgen wir jeden Punkt x isin Ω uumlber die Zeit ∆t entlangw1 zuruumlck Dadurch entsteht ein Pfad p (x t) von x zu einem Punkt x0 = p (xminus∆t) der auch alsStromlinie interpretiert werden kann Dies wird in Abbildung 23 verdeutlicht

Abbildung 23 Weg den ein Fluidpartikel in der Zeit zuruumlcklegt (vgl [Stam])

Wir setzen dann die neue Geschwindigkeit w2 im Punkt x als die Geschwindigkeit die im Punkt x0 zurvorherigen Zeit vorliegt also

w2 (x) = w1 (p (xminus∆t)) = w1 (xminus∆tw1 (x)) (210)

Durch das Verwenden der Methode der Charakteristiken liefert unser Vorgehen eine fuumlr beliebig groszligeZeitschrittweiten und Geschwindigkeiten unbedingt stabile numerische Loumlsung (vgl [Stam]) Das koumln-nen wir daran feststellen dass der maximale Wert des Geschwindigkeitsfeldes in diesem Schritt niegroumlszliger als im vorherigen Zeitschritt werden kann auszliger wir praumlgen eine externe Kraft auf Denn nachGleichung (210) gilt

max(w2

(l))le max

(w1

(l))

(29)= max

(w0

(l) + ∆tf (l))

f (l)equiv0= max

(w4

(lminus1))

wobei ()(l) die entsprechende Groumlszlige im l-ten Zeitschritt bezeichnet Es ist f (l) equiv 0 da wir hier keineAnwender-Interaktion beruumlcksichtigenFuumlr Details zur Implementierung der Methode der Charakteristiken verweisen wir auf Kapitel 31

KAPITEL 2 THEORETISCHE GRUNDLAGEN 10

DiffusionHier betrachten wir eine Gleichung der Form

partu

partt= νnabla middot nablau (211)

Um diese numerisch zu loumlsen diskretisieren wir zunaumlchst den Laplace-Operatornabla middotnabla mit finiten Diffe-renzen im Ort und wenden dann ein Zeitschrittverfahren an Die Anwendung vonnablamiddotnabla auf das Geschwin-digkeitsfeld u erfolgt komponentenweise in x- beziehungsweise y-Richtung weshalb wir vereinfachenddie Diskretisierung des Operators angewendet auf ein hinreichend glattes Skalarfeld s betrachten Wirstellen also die Diskretisierung vonnabla middot nablas = part2s

partx2+ part2s

party2im R2 auf Dann gilt

(nabla middot nablas)ij asympsi+1j minus 2sij + siminus1j

h2+sij+1 minus 2sij + sijminus1

h2(212)

mit sij = s (xij) und analog (nabla middot nablas)ij = nabla middot nablas (xij) fuumlr xij isin Ωh Betrachten wir das durchGleichung (212) diskretisierte Skalarfeld s in jedem Gitterpunkt koumlnnen wir den diskretisierten Laplace-Operator als Matrix auffassen welche die folgende Gestalt aufweist

1

h2

Bn In

In In

In Bn

mit Bn =

minus4 1

1 1

1 minus4

isin Rntimesn (213)

Hierbei bezeichnet In die Einheitsmatrix der Dimension ntimesn Wenden wir auf die im Ort diskretisierteGleichung (211) ein explizites Zeitschrittverfahren der Form

u (x t+ ∆t) = u (x t) + ν∆tnabla middot nablau (x t) (214)

an so tritt erneut das Problem der Instabilitaumlt fuumlr groszlige Zeitschrittweiten ∆t beziehungsweise groszligekinematische Viskositaumlten ν auf Diese Schwierigkeit taucht auf da die Methode einem expliziten Euler-Verfahren entspricht und daher aumlhnliche Eigenschaften bezuumlglich der Stabilitaumlt aufweist Um eine stabileLoumlsungsmethode zu konstruieren verwenden wir statt des in Gleichung (214) angefuumlhrten ein implizitesVerfahren was sich durch Uumlbertragen auf unsere Schreibweise innerhalb eines Zeitschrittes schreibenlaumlsst als

(Iminus ν∆tnabla middot nabla)w3 = w2 (215)

wobei I den Identitaumltsoperator darstellt Diese Gleichung entspricht einer Poisson-Gleichung fuumlr dasGeschwindigkeitsfeld w3 Setzen wir den diskretisierten Laplace-Operator aus Gleichung (213) in Glei-chung (215) ein so ergibt sich die Darstellung fuumlr die Systemmatrix des zu loumlsenden Gleichungssystemsals

ν∆t

h2

Bn minusInminusIn

minusInminusIn Bn

mit Bn =

4 + h2

ν∆t minus1

minus1 minus1

minus1 4 + h2

ν∆t

(216)

Das daraus resultierende Gleichungssystem muumlssen wir nun effizient loumlsen worauf wir in Kapitel 31eingehen

KAPITEL 2 THEORETISCHE GRUNDLAGEN 11

ProjektionIm Projektionsschritt betrachten wir Gleichung (24) und erhalten wie im Diffusionsschritt eine Poisson-Gleichung zur Berechnung des Druckfeldes p Auch hier ergibt sich durch die Diskretisierung vonnablamiddotnablaein duumlnn besetztes lineares Gleichungssystem mit rechter Seite nabla middot w3 welches wir loumlsen muumlssen umals Abschluss unseres Algorithmus die aktualisierte Geschwindigkeit uumlber die Gleichung

u (x t+ ∆t) = w4 = w3 minusnablap (217)

berechnen zu koumlnnen Dazu verwenden wir folgende Diskretisierungen der auftretenden Operatoren

(nablas)ij =

(parts

partxparts

party

)ij

asymp(si+1j minus siminus1j

2hsij+1 minus sijminus1

2h

)(218)

(nabla middot v)ij =

(partvx

partx+partvy

party

)ij

asymp

(vxi+1j minus vximinus1j

2h+vyij+1 minus v

yijminus1

2h

) (219)

wobei s erneut ein Skalarfeld und v = (vx vy) ein zweidimensionales Vektorfeld mit x- und y-Komponentebezeichnet Analog zu der Schreibweise in Gleichung (212) repraumlsentieren ()ij die entsprechendenGroumlszligen ausgewertet im Punkt xij isin Ωh

Nun sind wir in der Lage im naumlchsten Zeitschritt das Geschwindigkeitsfeld zu berechnen und schlieszligensomit die Diskretisierung der Navier-Stokes Gleichungen (21) und (22) ab Dazu fassen wir die wesent-lichen Ergebnisse dieses Unterkapitels in algorithmischer Form zusammen Wir orientieren uns dabei anden in Schema (28) angefuumlhrten Schritten und erhalten so ein kompaktes numerisches Loumlsungsverfahrender Navier-Stokes Gleichungen

Algorithmus 241 (bdquoStable Fluidsldquo Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen nach[Stam])Sei ein initiales Geschwindigkeitsfeld w0

(0) (x) = u (x 0) gegebenFuumlr l = 1 L

1 Kraft aufpraumlgen w1(l) (x) = w0

(lminus1) (x) + ∆tf (l) (x)

2 Advektion w2(l) (x) = w1

(l)(xminus∆tw1

(l) (x))

3 Diffusion bestimme w3(l) uumlber (Iminus ν∆tnabla middot nabla)w3

(l) = w2(l)

4 Projektion w4(l) = w3

(l) minusnablap(l) wobei sich p(l) ergibt aus nabla middot nablap(l) = nabla middotw3(l)

5 Aktualisierung w0(l) (x) = u (x l middot∆t) = w4

(l) (x)

Die Anzahl L + 1 der durchzufuumlhrenden Zeitschritte legen wir dadurch fest wie lange wir die Simu-lation ausfuumlhren Das Kraftfeld f (l) wird durch den Anwender von auszligen bestimmt und steht in jedemZeitschritt aktualisiert zur Verfuumlgung Die genaue Umsetzung der Schritte in Algorithmus 241 stellenwir in Kapitel 3 vor

Kapitel 3

Implementierung

Nachdem wir in Kapitel 2 auf die in unserer Simulation verwendete Theorie bezuumlglich Modell Dis-kretisierung und numerischer Loumlsung eingegangen sind wollen wir uns nun ihrer Umsetzung und derRealisierung der Visualisierung und Interaktion auf einem Tablet-Computer widmen Die Stroumlmungs-simulation fuumlhren wir auf dem Asus EeePad Transformer TF101 auf dem das Betriebssystem Android403 installiert ist in einer App aus Details zur Hardware des verwendeten Tablet-Computers findensich in Kapitel 44 Der Anwender hat waumlhrend der Simulation die Moumlglichkeit die Stroumlmung einesFluids durch Beruumlhren des Bildschirms zu beeinflussen Stroumlmungssimulationen wie sie etwa bei [Stam]oder [Harris] beschrieben werden koumlnnen vom Nutzer durch Interaktion mit der Maus beeinflusst wer-den auf einem Tablet-Computer besteht jedoch die Moumlglichkeit dies mit einem Finger auf dem Bild-schirm durchzufuumlhren Dadurch wirkt die Simulation fuumlr den Betrachter realer Die Moumlglichkeit solcheComputer zur Stroumlmungssimulation einzusetzen wird dadurch eroumlffnet dass Tablet-Computer hinsicht-lich ihrer Rechenleistung immer leistungsfaumlhiger werdenBevor wir auf die konkrete Implementierung des in Kapitel 2 vorgestellten Verfahrens eingehen wollenwir zunaumlchst das Vorgehen bei einer App-Programmierung in der Programmiersprache Java fuumlr das An-droid-Betriebssystem erlaumlutern wobei wir uns an [Android Developer] orientieren Zunaumlchst installierenwir eine Software-Entwicklungsumgebung wie etwa Eclipse1 in der wir die eigentliche Programmie-rung durchfuumlhren Ergaumlnzend benoumltigen wir das Android Software Development Kit sowie die AndroidDevelopment Tools die wir in die Entwicklungsumgebung einbinden muumlssen Anschlieszligend koumlnnen wirein neues Android App Project erstellen welches die App repraumlsentiert Dabei werden einige Dateienautomatisch erstellt wie etwa die Manifest-Datei die eine zentrale Rolle einnimmt da sie die funda-mentalen Charakteristiken der App beschreibt und jede ihrer Komponenten definiert Die Programmie-rung einer App unterscheidet sich vor allem dadurch von einer bdquogewoumlhnlichenldquo Java-Programmierungals dass zum korrekten Erstellen der App viele spezielle Funktionen vom System verlangt werden diewir implementieren muumlssen Auch die Umsetzung der Visualisierung mit Hilfe der OpenGL ES 20-Bibliothek verlangt ein gesondertes Vorgehen Wir muumlssen die Visualisierung in eine eigene Klasse aus-lagern diese entsprechend kennzeichnen und erneut vom System verlangte Funktionen integrieren Aumlhn-lich verhaumllt es sich bei der Beruumlcksichtigung der Anwender-InteraktionUm eine App schlieszliglich auszufuumlhren bestehen zwei Moumlglichkeiten Einerseits koumlnnen wir die App aufeinem externen Android-Geraumlt starten zum Beispiel einem Tablet-Computer andererseits den Emula-tor nutzen Dabei handelt es sich um eine sogenannte Android Virtual Device die auf dem Computerausgefuumlhrt wird auf dem sich die Entwicklungsumgebung befindet Die Virtual Device entspricht ei-nem externen Geraumlt welches auf dem Computer simuliert wird Es empfiehlt sich die App zunaumlchstim Emulator zu testen da bei eventuellen Programmierfehlern das externe Geraumlt durch Uumlberhitzungoder aumlhnliches beschaumldigt werden kann Bisher ist es nicht moumlglich Apps auf dem Emulator zu tes-ten die sich der Bibliothek OpenGL ES 20 zur Darstellung von Grafiken bedienen wie wir sie fuumlr

1Fuumlr naumlhere Informationen verweisen wir auf httpwwweclipseorg

12

Kapitel 1

Einleitung

In dieser Bachelorarbeit stellen wir ein Verfahren zur Stroumlmungssimulation in Form einer App auf Tablet-Computern vor Aufgrund der massiven Hardwareverbesserung in der letzten Zeit ist es mittlerweile moumlg-lich solche Computer fuumlr anspruchsvolle Simulationen zu verwenden Insbesondere koumlnnen wir dadurchdie Echtzeit und Interaktion auf sehr natuumlrliche Weise realisieren Das Ziel dieser Arbeit ist es somiteine neue Hardwarearchitektur inklusive ihrer intuitiven Interaktionsmoumlglichkeiten auf die Eignung zurphysikalisch korrekten numerischen Stroumlmungssimulation zu evaluieren und dabei experimentell zu er-gruumlnden ob und in welchem Rahmen eine Echtzeit-Simulation erreicht werden kann Dazu betrachtenwir ein Fluid welches sich in dem zweidimensionalen Gebiet Ω = [minus1 1]2 sub R2 befindet Als ma-thematisches Modell verwenden wir die inkompressiblen Navier-Stokes Gleichungen denen wir uns inKapitel 2 widmen Patrick Westervoszlig erlaumlutert in Abschnitt 21 die physikalische Bedeutung dieser Glei-chungen und geht in Unterkapitel 22 auf Anfangs- und Randbedingungen die fuumlr die Wohlgestelltheitdes Problems notwendig sind ein Danach uumlberfuumlhrt er die Gleichungen in Abschnitt 23 in eine zurLoumlsung geeignetere Form Anschlieszligend entwickelt Niklas Borg in Abschnitt 24 ein numerisches Louml-sungsverfahren und geht zusaumltzlich auf die Diskretisierung dieses Verfahrens mittels finiter DifferenzeneinIn Kapitel 3 praumlsentieren wir die programmiertechnische Umsetzung des im vorherigen Kapitel vorge-stellten Verfahrens die wir aufgrund ihrer Komplexitaumlt gemeinsam durchgefuumlhrt haben und gehen aufeinige kompliziertere Strukturen ein Weiterhin stellen wir zwei fuumlr die Stroumlmungssimulation auf Tablet-Computern wesentliche Komponenten vor die Visualisierung des zuvor berechneten Geschwindigkeits-feldes und die Interaktion eines Anwenders Hierbei verwenden wir die OpenGL ES 20-Bibliothekdie uumlblicherweise zur Realisierung der beiden Elemente auf Tablet-Computern genutzt wirdIn Kapitel 4 fuumlhren wir verschiedene Tests durch um unsere Software auf ihre Richtigkeit zu pruumlfenDazu untersucht Niklas Borg in Abschnitt 41 die numerische Stabilitaumlt und physikalische Korrektheitunserer Simulation Damit ist gemeint dass sich die Simulation nicht verselbststaumlndigt sich also einstatisches Fluid nicht selbst anregt Daruumlber hinaus vergleicht er den gaumlngigen Testfall Driven Cavi-ty durchgefuumlhrt in unserer Simulationsumgebung mit einer Referenzloumlsung In Abschnitt 42 fuumlhrt erzudem einige Parametertests durch um die Auswirkungen der verschiedenen Variablen unseres Loumlsersauf die Simulation zu bewerten Dabei betrachtet er die kinematische Viskositaumlt ν des Fluids den imVerfahren verwendeten Zeitschritt ∆t und die Anzahl maxiter der durchzufuumlhrenden Iterationen imeingesetzten Jacobi-LoumlserIn Abschnitt 43 analysiert Patrick Westervoszlig die Umsetzung der Anwender-Interaktion anhand zwei-er verschiedener Testfaumllle die sich in ihrer Komplexitaumlt unterscheiden Danach erarbeitet er in Ab-schnitt 44 mit Hilfe von Zeitmessungen der einzelnen Implementierungs-Komponenten potentielle Ver-besserungsmoumlglichkeiten der Software um zu beurteilen in wie weit eine Echtzeit-Simulation auf Tablet-Computern erreicht werden kann Dazu vergleicht und interpretiert er die Laufzeiten des Loumlsers derVisualisierungs- sowie der Interaktions-Komponente fuumlr verschiedene Gitterschrittweiten h der Diskre-tisierung

1

KAPITEL 1 EINLEITUNG 2

Zum Schluss fassen wir in Kapitel 5 die wesentlichen Erkenntnisse zusammenEine genaue Uumlbersicht uumlber die Aufteilung der Bearbeitung dieser Bachelorarbeit geben wir in Ta-belle 11

Kapitel bearbeitet von21 Patrick Westervoszlig22 Patrick Westervoszlig23 Patrick Westervoszlig24 Niklas Borg3 Niklas Borg und Patrick Westervoszlig

41 Niklas Borg42 Niklas Borg43 Patrick Westervoszlig44 Patrick Westervoszlig

Tabelle 11 Aufteilung der Bearbeitung der Bachelorarbeit

Kapitel 2

Theoretische Grundlagen

Zur Simulation einer Stroumlmung in einem Fluid in einem bestimmten Zeitintervall benoumltigen wir einemathematische Beschreibung seines Verhaltens Ein gutes Modell dafuumlr sind die Navier-Stokes Glei-chungen da sie die fuumlr die Darstellung eines Fluids wesentliche Komponente die Entwicklung der Ge-schwindigkeit charakterisieren Auszligerdem bilden sie viele physikalische Effekte ab wie zum BeispielTurbulenzen und Grenzschichten innerhalb der Stroumlmung Deshalb wollen wir diese Gleichungen imFolgenden genauer betrachten Dabei orientieren wir uns an den Ausfuumlhrungen von [Stam] und [Harris]Das Ziel des im weiteren Verlauf dieser Arbeit entwickelten Loumlsungsverfahrens ist die Generierung ei-nes fluidartigen Verhaltens welches zwar auf den Navier-Stokes Gleichungen basiert dessen berechnetesGeschwindigkeitsfeld die Gleichungen jedoch nicht exakt erfuumlllt Die hier vorgestellte Methode wurdeurspruumlnglich fuumlr Computeranimationen entworfen und nicht fuumlr Anwendungen aus den Ingenieurswis-senschaften was unser leicht inexaktes Vorgehen zur Fluidsimulation rechtfertigt

21 Die Navier-Stokes Gleichungen

Zunaumlchst treffen wir einige in der Fluidsimulation durchaus uumlbliche Annahmen die auf eine vereinfach-te Form der Navier-Stokes Gleichungen fuumlhren und trotzdem die Qualitaumlt des mathematischen Modellserhalten Dazu nehmen wir die Dichte ρ des Fluids sowie seine Temperatur θ als konstant bezuumlglichOrt und Zeit an wodurch wir die Beschreibung eines inkompressiblen Fluids erhalten Aufgrund die-ser Annahmen muumlssen wir uns in der Simulation auf sogenannte bdquonewtonscheldquo Fluide beschraumlnken DieEntwicklung eines solchen Fluids in einem zweidimensionalen Gebiet Ω sub R2 uumlber einem ZeitintervallI = [0 T ] mit T isin R+ koumlnnen wir durch die inkompressiblen Navier-Stokes Gleichungen charakterisie-ren welche das Fluidverhalten mathematisch beschreiben

partu

partt= minus (u middot nabla)uminus 1

ρnablap+ νnabla middot nablau + f (21)

nabla middot u = 0 (22)

Dabei bezeichnen wir mit u = u (x t) die Geschwindigkeit mit p = p (x t) den Druck mit ν diekinematische Viskositaumlt und mit ρ die Dichte des Fluids Es ist dabei zu beachten dass wir in unsererSimulation nur den Druck innerhalb des Fluids beruumlcksichtigen und den Atmosphaumlrendruck vernachlaumls-sigen Durch die Groumlszlige f = f (x t) definieren wir eine externe Kraft im Punkt x isin Ω zur Zeit t isin I Hierbei treffen wir die Konvention dass die fett gedruckten Ausdruumlcke vektorwertige Groumlszligen in derRegel Vektorfelder und die kursiven skalare Groumlszligen repraumlsentieren Fuumlr Details zu den Navier-StokesGleichungen und deren Herleitung aus den allgemeinen Erhaltungsgleichungen der Kontinuumsmecha-nik verweisen wir auf [Anderson]Im Folgenden wollen wir uns kurz den einzelnen Bestandteilen von Gleichung (21) widmen und ihre

3

KAPITEL 2 THEORETISCHE GRUNDLAGEN 4

physikalische Bedeutung erlaumlutern wozu wir einige Begriffe definieren

AdvektionUumlblicherweise kann ein Fluid Objekte oder andere Substanzen transportieren In unserem Fall beschraumln-ken wir uns lediglich darauf dass es bdquosich selbstldquo transportiert Es wird also durch die eigene Ge-schwindigkeit fortbewegt Dieses Verhalten nennt sich Advektion und wird durch den Term minus (u middot nabla)ubeschrieben der den konvektiven Transport des Fluids darstellt Die Beruumlcksichtigung dieses Effekteszieht die Konsequenz nach sich dass die Navier-Stokes Gleichungen nichtlinear sind

DruckDie Teilchen in einem Fluid werden automatisch fortbewegt Dies fuumlhrt dazu dass sie sich gegenseitigan- und abstoszligen Wird eine Kraft auf das Fluid aufgepraumlgt so wird diese ebenfalls durch die Teilchenuumlbertragen Diese beiden Phaumlnomene fuumlhren zu einer Druckentwicklung im Fluid was letztendlich in ei-ner Beschleunigung der Teilchen resultiert Der Ausdruck minus1

ρnablap in Gleichung (21) repraumlsentiert diesenphysikalischen Sachverhalt in Abhaumlngigkeit von der Dichte ρ des Fluids und des auf das Fluid wirkendenDrucks p

DiffusionDieses physikalische Phaumlnomen haumlngt stark mit der Zaumlhfluumlssigkeit eines Fluids welche uumlber seine kine-matische Viskositaumlt ν beschrieben wird zusammen und hat einen groszligen Einfluss auf das FluidverhaltenZur Erlaumluterung geben wir zunaumlchst eine rein formale Definition der Viskositaumlt (vgl [Arlt])

Definition 211 (Viskositaumlt)Wir betrachten folgenden Versuchsaufbau

Abbildung 21 Versuchsaufbau zur Definition der Viskositaumlt

Im unteren Teil von Abbildung 21 befindet sich eine feststehende unbewegliche Wand M und im Ab-stand z zu dieser eine bewegliche Wand N mit der Oberflaumlche A Der Raum zwischen den Waumlnden istmit dem zu untersuchenden Fluid gefuumlllt Um die WandN mit der konstanten Geschwindigkeit v parallelzu M zu bewegen wird die Kraft benoumltigt die aus dem Newtonschen Gesetz

KAPITEL 2 THEORETISCHE GRUNDLAGEN 5

F = η middotA middot dv

dz

hervorgeht Somit ist die Kraft F proportional zu der Oberflaumlche A und dem Geschwindigkeits-gradienten dv

dz welcher der Beschleunigung der beweglichen Wand N entspricht Der Proportionali-taumltsfaktor η heiszligt dynamische Viskositaumlt und ist ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres Fluids Es gilthierbei je groumlszliger die Viskositaumlt desto zaumlhfluumlssiger das Fluid

Zu unterscheiden sind dabei zwei verschiedene Begriffe der Viskositaumlt Die dynamische Viskositaumlt η unddie kinematische Viskositaumlt ν welche wir in den Navier-Stokes Gleichungen (21) und (22) benoumltigenWir wollen nun beide Begriffe in Zusammenhang setzen Sei ρ die Dichte und η die dynamische Visko-sitaumlt unseres Fluids Dann ergibt sich die kinematische Viskositaumlt zu

ν =η

ρ (23)

Zaumlhe Fluumlssigkeiten also solche mit einer hohen Viskositaumlt reagieren traumlger auf Bewegungen als duumlnn-fluumlssige oder auch Fluide mit kleinerer Viskositaumlt wie etwa Olivenoumll im Vergleich zu Wasser DieserEffekt nennt sich Diffusion und geht durch den Term νnabla middotnablau in das mathematische Modell ein der dendiffusiven Transport des Fluids beruumlcksichtigt

KraumlfteWie bei der Beschreibung des Drucks bereits erwaumlhnt fuumlhrt das Aufpraumlgen von Kraumlften zur Beschleuni-gung der Fluidteilchen Moumlglich sind externe Kraumlfte also solche die bdquovon auszligenldquo auf das Fluid wirkenund Koumlrper- beziehungsweise Volumenkraumlfte die etwa durch die Erdbeschleunigung hervorgerufen wer-den An dieser Stelle sei schon einmal erwaumlhnt dass die externen Kraumlfte in der Simulation interaktivdurch den Anwender integriert werden koumlnnen (vgl Abschnitt 33)

Damit das Problem welches durch die Navier-Stokes Gleichungen formuliert wird wohlgestellt istmuumlssen wir zusaumltzlich sogenannte Anfangs- und Randbedingungen einfuumlhren auf die wir im folgendenAbschnitt eingehen

22 Anfangs- und Randbedingungen

Sowohl die Geschwindigkeit u als auch der Druck p treten in den Navier-Stokes Gleichungen als Un-bekannte auf und muumlssen in jedem Zeitschritt berechnet und aktualisiert werden Daher muumlssen wirgeeignete Anfangs- und Randbedingungen fuumlr beide Groumlszligen vorgebenDie Anfangsbedingung fuumlr das Druckfeld ist von Testfall zu Testfall unterschiedlich So nehmen wir ineinem Beispiel den initialen Druck als Null an womit p equiv 0 in Ω gilt Andererseits koumlnnen wir fuumlrden Druck sogenannte Druckspitzen vorschreiben wie wir sie in Kapitel 42 setzen Fuumlr das Geschwin-digkeitsfeld waumlhlen wir immer u equiv 0 als Anfangsbedingung und erzeugen Dynamik entweder durchexterne Kraumlfte wie etwa in Abschnitt 431 oder uumlber RandbedingungenIm Allgemeinen legen wir als Randbedingung fuumlr die Geschwindigkeit die sogenannte bdquono-slipldquo-Bedingung u|partΩ equiv 0 fest Wir setzen die Geschwindigkeit am Rand also auf Null was bedeutet dass dasFluid am Gebietsrand haften bleibt Wir koumlnnen aber auch wie beim Testfall Driven Cavity beschriebenan einer Kante des Rechengebiets einen von Null verschiedenen Wert vorschreiben Wir tragen somit ei-ne Tangentialgeschwindigkeit an und erzeugen mit ihrer Hilfe Dynamik im Fluid (vgl Abschnitt 412)Als Randbedingung fuumlr den Druck legen wir fest dass keine Aumlnderung in Normalenrichtung stattfindet

KAPITEL 2 THEORETISCHE GRUNDLAGEN 6

also partppartn |partΩ equiv 0 gilt wobei n den aumluszligeren Normalenvektor von Ω bezeichnet

Die verschiedenen Anfangs- und Randbedingungen sind miteinander und mit der Anwender-Interaktionder wir uns in Abschnitt 43 widmen kombinierbar Wir koumlnnen somit eine Vielzahl von Testfaumlllen kon-struieren von denen wir eine Auswahl in Kapitel 4 praumlsentieren

23 Projektionsverfahren und die Helmholtz-Hodge-Zerlegung

Nachdem wir zuvor alle Komponenten der Navier-Stokes Gleichungen aus physikalischer Sicht betrach-tet und Anfangs- sowie Randbedingungen eingefuumlhrt haben wollen wir sie nun in eine zum Loumlsen geeig-netere Form bringen und anschlieszligend ein Vorgehen zur Loumlsung dieser Gleichungen entwickeln Dabeiist die Art der Diskretisierung des von Raum- und Zeitvariablen abhaumlngigen Problems entscheidendZunaumlchst nehmen wir eine simple Zeitdiskretisierung vor indem wir das Zeitintervall I = [0 T ] inTeilintervalle zerlegen Anschlieszligend betrachten wir Gleichung (21) innerhalb eines Zeitschritts unddiskretisieren die auftretenden Operatoren im Ort (vgl Kapitel 24) Im Folgenden koumlnnen wir daherdie einzelnen Bestandteile dieser Gleichung als zeitunabhaumlngig ansehen da wir das Loumlsungsverfahreninnerhalb eines Zeitschritts entwickelnUm die Gleichungen in ein besser zu loumlsendes System zu uumlberfuumlhren betrachten wir als Hilfsmittelzunaumlchst die sogenannte Helmholtz-Hodge Zerlegung (vgl [Chorin])

Satz 231 Sei Ω sub R2 ein Gebiet mit glattem Rand partΩ Dann kann jedes Vektorfeld w zerlegt werdenin die Form

w = u +nablapwobei nabla middot u = 0 gilt das Vektorfeld u also divergenzfrei ist Auszligerdem ist u parallel zu partΩ das heiszligtu middot n = 0 mit dem aumluszligeren Normalenvektor n von Ω p bezeichnet ein Skalarfeld

In jedem Zeitschritt muumlssen wir Gleichung (21) loumlsen wobei wir gewaumlhrleisten muumlssen dass Glei-chung (22) gilt Wenn wir nun davon ausgehen durch das Loumlsen von Gleichung (21) ein Geschwindig-keitsfeld w erhalten zu haben so muss nicht zwangslaumlufig nabla middotw = 0 gelten Dies erreichen wir durchAnwenden von Satz 231 auf das Geschwindigkeitsfeld w Wir setzen somit am Ende des Zeitschrittsdas aktualisierte Geschwindigkeitsfeld analog zu obigem Satz als u = w minusnablapJetzt stellt sich die Frage wie das Skalarfeld p zu berechnen ist Wenden wir den Divergenz-Operatornablamiddot auf beide Seiten der Gleichung aus Satz 231 an so erhalten wir

nabla middotw = nabla middot u︸ ︷︷ ︸=0

+nabla middot nablap

hArr nabla middotw = nabla middot nablap (24)

Setzen wir also die Loumlsung von Gleichung (21) als bekannt voraus so koumlnnen wir durch Loumlsen derPoisson-Gleichung (24) den Druck p ermitteln mit dem wir das Geschwindigkeitsfeld w so modifizie-ren koumlnnen dass es Gleichung (22) erfuumlllt Als naumlchstes muumlssen wir uns damit beschaumlftigen wie wir dasvorlaumlufige Geschwindigkeitsfeld w berechnen koumlnnen

Zunaumlchst definieren wir hierzu mit Hilfe von Satz 231 einen linearen Operator P der ein Vektorfeld wauf seinen divergenzfreien Teil projiziert Fuumlr diesen Operator gilt dann

P (w) = P (u) + P (nablap) da P linear ist

P (w) = u wegen Satz 231 und (25)

P (u) = u nach Voraussetzung

KAPITEL 2 THEORETISCHE GRUNDLAGEN 7

woraus insgesamt

P (nablap) = 0 (26)

folgtAnhand von Gleichung (25) koumlnnen wir uns mit dem Schwarzschen Satz (vgl [Forster]) uumlberlegendass P

(partupartt

)= partu

partt gilt Der Satz von Schwarz besagt dass bei einer q-mal stetig partiell differen-zierbaren Funktion die ersten q Ableitungen vertauscht werden duumlrfen Bei uns gilt nach Voraussetzungu isin C2 (Ω)capC1 (I) da die Ausdruumlckenablamiddotnablau und partu

partt in Gleichung (21) eine entsprechende Glattheit desGeschwindigkeitsfeldes bezuumlglich der Variablen (x t) verlangen Dabei bezeichnet Ck (Ul) den Raumder k-mal stetig partiell differenzierbaren Funktionen uumlber U2 = Ω sub R2 beziehungsweise U1 = I sub Rmit k l isin 1 2 Somit folgt

nabla middot partupartt

=part

partt(nabla middot u) = 0

Wenden wir nun den Operator P auf Gleichung (21) an und nutzen seine Linearitaumlt undGleichung (26) aus so erhalten wir

partu

partt= P (minus (u middot nabla)u + νnabla middot nablau + f) (27)

Aus Gleichung (27) ergibt sich direkt der von uns verwendete Algorithmus zur Loumlsung der Navier-StokesGleichungen der sich in vier Schritte gliedert

u (middot t) = w0Kraft aufpraumlgenminusminusminusminusminusminusminusminusrarr w1

Advektionminusminusminusminusminusrarr w2Diffusionminusminusminusminusminusrarr w3

Projektionminusminusminusminusminusrarr w4 = u (middot t+ 1) (28)

Wir nehmen an dass uns das Geschwindigkeitsfeld u zum Zeitpunkt t bekannt ist und setzenw0 (x) = u (x t) Pro Zeitschritt loumlsen wir die Gleichung (21) durch sogenanntes bdquoOperator-Splittingldquosukzessiv numerisch Wie in allen Projektionsmethoden entsteht auch hier durch das Splitting ein nu-merischer Fehler wodurch wir Gleichung (21) nicht mehr exakt loumlsen Leider geht [Stam] in seinerOriginalarbeit nicht auf die Ordnung des Verfahrens ein aufgrund der Struktur des Verfahrens und derAumlhnlichkeit zu Chorinschen Projektionsmethoden (vgl [Anderson]) ist aber nicht von einer hohen Ord-nung auszugehen Schlieszliglich gewaumlhrleisten wir durch das Anwenden des oben definierten Projektions-operators P dass Gleichung (22) erfuumlllt ist was anschaulich aus Abbildung 22 hervorgeht

Abbildung 22 Sukzessive Berechnung der Geschwindigkeit in einem Punkt innerhalb eines Zeitschritts(vgl [Stam])

Am Ende eines jeden Zeitschritts setzen wir w0 = w4 Da wir wie oben beschrieben ausgehend vonw0 innerhalb eines Zeitschrittes operieren haumlngen die Geschwindigkeitsfelder wk k isin 0 1 2 3 4

KAPITEL 2 THEORETISCHE GRUNDLAGEN 8

waumlhrend der Berechnung nur von der Ortsvariablen x ab Das Vektorfeld w4 entspricht schlieszliglich demGeschwindigkeitsfeld u zum Zeitpunkt t+∆t also u (x t+ ∆t) mit der Zeitschrittweite ∆t isin R+ DieSimulation erhalten wir letztendlich durch Iteration der in Schema (28) beschriebenen Vorgehensweiseuumlber die Zeitschritte Daraus ergibt sich durch Diskretisierung der auftretenden Operatoren ein nume-risches Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen (21) und (22) worauf wir im naumlchstenAbschnitt eingehen

24 Diskretisierung und numerische Loumlsung

Wir erlaumlutern in diesem Abschnitt die in Schema (28) angefuumlhrten Schritte und stellen Diskretisierungs-beziehungsweise Loumlsungstechniken vor um abschlieszligend ein kompaktes Loumlsungsverfahren der Navier-Stokes Gleichungen aufzustellen Zur Diskretisierung aller auftretenden Operatoren verwenden wir indieser Arbeit meist finite Differenzen zweiter Ordnung Approximationen abweichender Ordnung sindbeispielsweise bei der Behandlung von Randbedingungen noumltig auf die wir in Abschnitt 314 naumlhereingehenWie in Abschnitt 23 bereits erwaumlhnt diskretisieren wir das durch die Navier-Stokes Gleichungen (21)und (22) und Anfangs- sowie Randbedingungen gestellte Problem zuerst in der Zeit und anschlieszligendim Ort Dazu waumlhlen wir eine aumlquidistante Zerlegung des Zeitintervalls in L Teilintervalle der Form

I = [0 T ] =

L⋃l=1

[t(lminus1) t(l)

]

wobei t(l) = l middot∆t und T = L middot∆t gilt Die folgenden Diskretisierungen im Ort fuumlhren wir nun jeweilszu einem festen Zeitpunkt t(l) durch weshalb die auftretenden Groumlszligen zeitunabhaumlngig sindFuumlr unsere Simulation betrachten wir das quadratische Rechengebiet Ω = [minus1 1]2 sub R2 in dem sichdas Fluid befinden soll Davon ausgehend definieren wir ein diskretes Gebiet Ωh mit Schrittweite h isin Rdie wir sowohl in x- als auch in y-Richtung zur Diskretisierung verwenden Dadurch ergibt sich Ωh alsein Gitter fuumlr das xij isin Ωh die Form xij = (minus1 + ihminus1 + jh) hat wobei i j isin 0 n minus 1gilt und n isin N die Anzahl der Gitterpunkte pro Zeile beziehungsweise Spalte im Gitter angibt ImFolgenden betrachten wir nur die Operationen innerhalb eines Zeitschrittes das heiszligt im Uumlbergang vont(l) nach t(l) + ∆t Dazu sei w0 wie oben als bekanntes Geschwindigkeitsfeld u

(x t(l)

)definiert und

wk k isin 1 2 3 4 bezeichnet die unterschiedlichen Geschwindigkeitsfelder innerhalb des ZeitschrittsNach diesen Vorbereitungen widmen wir uns nun Diskretisierungs- und Loumlsungsmethoden fuumlr die ein-zelnen Bestandteile von Gleichung (27) beziehungsweise Schema (28)

Kraft aufpraumlgenZuerst kann dem Fluid eine Kraft aufgepraumlgt werden Dies geschieht waumlhrend der Simulation durch denAnwender und soll nur ein Mal pro Zeitschritt erfolgen Deshalb koumlnnen wir die Annahme treffen dassdie Kraft uumlber den gesamten Zeitschritt konstant ist Somit ist eine Beruumlcksichtigung der Kraft zu Beginneines jeden Zeitschritts ausreichend Wir berechnen also im ersten Schritt unseres Loumlsers

w1 = w0 + ∆tf (29)

was eine gute Approximation der Wirkung der Kraft uumlber den Zeitschritt darstellt da wir ihren Einflussdurch die Multiplikation des Kraftfeldes f mit der Zeitschrittweite ∆t uumlber den ganzen Zeitschritt trans-portieren

KAPITEL 2 THEORETISCHE GRUNDLAGEN 9

AdvektionUm die Advektion des Fluids zu beruumlcksichtigen fassen wir die Gitterpunkte als die oben beschriebenenTeilchen beziehungsweise Fluidpartikel auf und muumlssen dann in jedem Zeitschritt die Geschwindigkeiteines solchen Partikels aktualisierenEine erste Idee waumlre es hierzu folgende explizite Methode zu betrachten Die Position r eines Partikelsveraumlndert sich mit der Geschwindigkeit also koumlnnen wir die Position so weit verschieben wie sich dasPartikel in der Zeit ∆t mit seiner Geschwindigkeit fortbewegt Also gilt

r(t(l) + ∆t

)= r

(t(l))

+ ∆tu(t(l))

was dem expliziten Eulerverfahren entspricht Allerdings ist diese Methode instabil fuumlr groszlige Zeitschritt-weitenWir betrachten deshalb die implizite Methode der Charakteristiken die die Stabilitaumlt des Verfahrens im-pliziert Zur genaueren Erlaumluterung dieses Verfahrens verweisen wir auf [Stam] und geben hier nur einegrobe Zusammenfassung Im Wesentlichen verfolgen wir jeden Punkt x isin Ω uumlber die Zeit ∆t entlangw1 zuruumlck Dadurch entsteht ein Pfad p (x t) von x zu einem Punkt x0 = p (xminus∆t) der auch alsStromlinie interpretiert werden kann Dies wird in Abbildung 23 verdeutlicht

Abbildung 23 Weg den ein Fluidpartikel in der Zeit zuruumlcklegt (vgl [Stam])

Wir setzen dann die neue Geschwindigkeit w2 im Punkt x als die Geschwindigkeit die im Punkt x0 zurvorherigen Zeit vorliegt also

w2 (x) = w1 (p (xminus∆t)) = w1 (xminus∆tw1 (x)) (210)

Durch das Verwenden der Methode der Charakteristiken liefert unser Vorgehen eine fuumlr beliebig groszligeZeitschrittweiten und Geschwindigkeiten unbedingt stabile numerische Loumlsung (vgl [Stam]) Das koumln-nen wir daran feststellen dass der maximale Wert des Geschwindigkeitsfeldes in diesem Schritt niegroumlszliger als im vorherigen Zeitschritt werden kann auszliger wir praumlgen eine externe Kraft auf Denn nachGleichung (210) gilt

max(w2

(l))le max

(w1

(l))

(29)= max

(w0

(l) + ∆tf (l))

f (l)equiv0= max

(w4

(lminus1))

wobei ()(l) die entsprechende Groumlszlige im l-ten Zeitschritt bezeichnet Es ist f (l) equiv 0 da wir hier keineAnwender-Interaktion beruumlcksichtigenFuumlr Details zur Implementierung der Methode der Charakteristiken verweisen wir auf Kapitel 31

KAPITEL 2 THEORETISCHE GRUNDLAGEN 10

DiffusionHier betrachten wir eine Gleichung der Form

partu

partt= νnabla middot nablau (211)

Um diese numerisch zu loumlsen diskretisieren wir zunaumlchst den Laplace-Operatornabla middotnabla mit finiten Diffe-renzen im Ort und wenden dann ein Zeitschrittverfahren an Die Anwendung vonnablamiddotnabla auf das Geschwin-digkeitsfeld u erfolgt komponentenweise in x- beziehungsweise y-Richtung weshalb wir vereinfachenddie Diskretisierung des Operators angewendet auf ein hinreichend glattes Skalarfeld s betrachten Wirstellen also die Diskretisierung vonnabla middot nablas = part2s

partx2+ part2s

party2im R2 auf Dann gilt

(nabla middot nablas)ij asympsi+1j minus 2sij + siminus1j

h2+sij+1 minus 2sij + sijminus1

h2(212)

mit sij = s (xij) und analog (nabla middot nablas)ij = nabla middot nablas (xij) fuumlr xij isin Ωh Betrachten wir das durchGleichung (212) diskretisierte Skalarfeld s in jedem Gitterpunkt koumlnnen wir den diskretisierten Laplace-Operator als Matrix auffassen welche die folgende Gestalt aufweist

1

h2

Bn In

In In

In Bn

mit Bn =

minus4 1

1 1

1 minus4

isin Rntimesn (213)

Hierbei bezeichnet In die Einheitsmatrix der Dimension ntimesn Wenden wir auf die im Ort diskretisierteGleichung (211) ein explizites Zeitschrittverfahren der Form

u (x t+ ∆t) = u (x t) + ν∆tnabla middot nablau (x t) (214)

an so tritt erneut das Problem der Instabilitaumlt fuumlr groszlige Zeitschrittweiten ∆t beziehungsweise groszligekinematische Viskositaumlten ν auf Diese Schwierigkeit taucht auf da die Methode einem expliziten Euler-Verfahren entspricht und daher aumlhnliche Eigenschaften bezuumlglich der Stabilitaumlt aufweist Um eine stabileLoumlsungsmethode zu konstruieren verwenden wir statt des in Gleichung (214) angefuumlhrten ein implizitesVerfahren was sich durch Uumlbertragen auf unsere Schreibweise innerhalb eines Zeitschrittes schreibenlaumlsst als

(Iminus ν∆tnabla middot nabla)w3 = w2 (215)

wobei I den Identitaumltsoperator darstellt Diese Gleichung entspricht einer Poisson-Gleichung fuumlr dasGeschwindigkeitsfeld w3 Setzen wir den diskretisierten Laplace-Operator aus Gleichung (213) in Glei-chung (215) ein so ergibt sich die Darstellung fuumlr die Systemmatrix des zu loumlsenden Gleichungssystemsals

ν∆t

h2

Bn minusInminusIn

minusInminusIn Bn

mit Bn =

4 + h2

ν∆t minus1

minus1 minus1

minus1 4 + h2

ν∆t

(216)

Das daraus resultierende Gleichungssystem muumlssen wir nun effizient loumlsen worauf wir in Kapitel 31eingehen

KAPITEL 2 THEORETISCHE GRUNDLAGEN 11

ProjektionIm Projektionsschritt betrachten wir Gleichung (24) und erhalten wie im Diffusionsschritt eine Poisson-Gleichung zur Berechnung des Druckfeldes p Auch hier ergibt sich durch die Diskretisierung vonnablamiddotnablaein duumlnn besetztes lineares Gleichungssystem mit rechter Seite nabla middot w3 welches wir loumlsen muumlssen umals Abschluss unseres Algorithmus die aktualisierte Geschwindigkeit uumlber die Gleichung

u (x t+ ∆t) = w4 = w3 minusnablap (217)

berechnen zu koumlnnen Dazu verwenden wir folgende Diskretisierungen der auftretenden Operatoren

(nablas)ij =

(parts

partxparts

party

)ij

asymp(si+1j minus siminus1j

2hsij+1 minus sijminus1

2h

)(218)

(nabla middot v)ij =

(partvx

partx+partvy

party

)ij

asymp

(vxi+1j minus vximinus1j

2h+vyij+1 minus v

yijminus1

2h

) (219)

wobei s erneut ein Skalarfeld und v = (vx vy) ein zweidimensionales Vektorfeld mit x- und y-Komponentebezeichnet Analog zu der Schreibweise in Gleichung (212) repraumlsentieren ()ij die entsprechendenGroumlszligen ausgewertet im Punkt xij isin Ωh

Nun sind wir in der Lage im naumlchsten Zeitschritt das Geschwindigkeitsfeld zu berechnen und schlieszligensomit die Diskretisierung der Navier-Stokes Gleichungen (21) und (22) ab Dazu fassen wir die wesent-lichen Ergebnisse dieses Unterkapitels in algorithmischer Form zusammen Wir orientieren uns dabei anden in Schema (28) angefuumlhrten Schritten und erhalten so ein kompaktes numerisches Loumlsungsverfahrender Navier-Stokes Gleichungen

Algorithmus 241 (bdquoStable Fluidsldquo Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen nach[Stam])Sei ein initiales Geschwindigkeitsfeld w0

(0) (x) = u (x 0) gegebenFuumlr l = 1 L

1 Kraft aufpraumlgen w1(l) (x) = w0

(lminus1) (x) + ∆tf (l) (x)

2 Advektion w2(l) (x) = w1

(l)(xminus∆tw1

(l) (x))

3 Diffusion bestimme w3(l) uumlber (Iminus ν∆tnabla middot nabla)w3

(l) = w2(l)

4 Projektion w4(l) = w3

(l) minusnablap(l) wobei sich p(l) ergibt aus nabla middot nablap(l) = nabla middotw3(l)

5 Aktualisierung w0(l) (x) = u (x l middot∆t) = w4

(l) (x)

Die Anzahl L + 1 der durchzufuumlhrenden Zeitschritte legen wir dadurch fest wie lange wir die Simu-lation ausfuumlhren Das Kraftfeld f (l) wird durch den Anwender von auszligen bestimmt und steht in jedemZeitschritt aktualisiert zur Verfuumlgung Die genaue Umsetzung der Schritte in Algorithmus 241 stellenwir in Kapitel 3 vor

Kapitel 3

Implementierung

Nachdem wir in Kapitel 2 auf die in unserer Simulation verwendete Theorie bezuumlglich Modell Dis-kretisierung und numerischer Loumlsung eingegangen sind wollen wir uns nun ihrer Umsetzung und derRealisierung der Visualisierung und Interaktion auf einem Tablet-Computer widmen Die Stroumlmungs-simulation fuumlhren wir auf dem Asus EeePad Transformer TF101 auf dem das Betriebssystem Android403 installiert ist in einer App aus Details zur Hardware des verwendeten Tablet-Computers findensich in Kapitel 44 Der Anwender hat waumlhrend der Simulation die Moumlglichkeit die Stroumlmung einesFluids durch Beruumlhren des Bildschirms zu beeinflussen Stroumlmungssimulationen wie sie etwa bei [Stam]oder [Harris] beschrieben werden koumlnnen vom Nutzer durch Interaktion mit der Maus beeinflusst wer-den auf einem Tablet-Computer besteht jedoch die Moumlglichkeit dies mit einem Finger auf dem Bild-schirm durchzufuumlhren Dadurch wirkt die Simulation fuumlr den Betrachter realer Die Moumlglichkeit solcheComputer zur Stroumlmungssimulation einzusetzen wird dadurch eroumlffnet dass Tablet-Computer hinsicht-lich ihrer Rechenleistung immer leistungsfaumlhiger werdenBevor wir auf die konkrete Implementierung des in Kapitel 2 vorgestellten Verfahrens eingehen wollenwir zunaumlchst das Vorgehen bei einer App-Programmierung in der Programmiersprache Java fuumlr das An-droid-Betriebssystem erlaumlutern wobei wir uns an [Android Developer] orientieren Zunaumlchst installierenwir eine Software-Entwicklungsumgebung wie etwa Eclipse1 in der wir die eigentliche Programmie-rung durchfuumlhren Ergaumlnzend benoumltigen wir das Android Software Development Kit sowie die AndroidDevelopment Tools die wir in die Entwicklungsumgebung einbinden muumlssen Anschlieszligend koumlnnen wirein neues Android App Project erstellen welches die App repraumlsentiert Dabei werden einige Dateienautomatisch erstellt wie etwa die Manifest-Datei die eine zentrale Rolle einnimmt da sie die funda-mentalen Charakteristiken der App beschreibt und jede ihrer Komponenten definiert Die Programmie-rung einer App unterscheidet sich vor allem dadurch von einer bdquogewoumlhnlichenldquo Java-Programmierungals dass zum korrekten Erstellen der App viele spezielle Funktionen vom System verlangt werden diewir implementieren muumlssen Auch die Umsetzung der Visualisierung mit Hilfe der OpenGL ES 20-Bibliothek verlangt ein gesondertes Vorgehen Wir muumlssen die Visualisierung in eine eigene Klasse aus-lagern diese entsprechend kennzeichnen und erneut vom System verlangte Funktionen integrieren Aumlhn-lich verhaumllt es sich bei der Beruumlcksichtigung der Anwender-InteraktionUm eine App schlieszliglich auszufuumlhren bestehen zwei Moumlglichkeiten Einerseits koumlnnen wir die App aufeinem externen Android-Geraumlt starten zum Beispiel einem Tablet-Computer andererseits den Emula-tor nutzen Dabei handelt es sich um eine sogenannte Android Virtual Device die auf dem Computerausgefuumlhrt wird auf dem sich die Entwicklungsumgebung befindet Die Virtual Device entspricht ei-nem externen Geraumlt welches auf dem Computer simuliert wird Es empfiehlt sich die App zunaumlchstim Emulator zu testen da bei eventuellen Programmierfehlern das externe Geraumlt durch Uumlberhitzungoder aumlhnliches beschaumldigt werden kann Bisher ist es nicht moumlglich Apps auf dem Emulator zu tes-ten die sich der Bibliothek OpenGL ES 20 zur Darstellung von Grafiken bedienen wie wir sie fuumlr

1Fuumlr naumlhere Informationen verweisen wir auf httpwwweclipseorg

12

KAPITEL 1 EINLEITUNG 2

Zum Schluss fassen wir in Kapitel 5 die wesentlichen Erkenntnisse zusammenEine genaue Uumlbersicht uumlber die Aufteilung der Bearbeitung dieser Bachelorarbeit geben wir in Ta-belle 11

Kapitel bearbeitet von21 Patrick Westervoszlig22 Patrick Westervoszlig23 Patrick Westervoszlig24 Niklas Borg3 Niklas Borg und Patrick Westervoszlig

41 Niklas Borg42 Niklas Borg43 Patrick Westervoszlig44 Patrick Westervoszlig

Tabelle 11 Aufteilung der Bearbeitung der Bachelorarbeit

Kapitel 2

Theoretische Grundlagen

Zur Simulation einer Stroumlmung in einem Fluid in einem bestimmten Zeitintervall benoumltigen wir einemathematische Beschreibung seines Verhaltens Ein gutes Modell dafuumlr sind die Navier-Stokes Glei-chungen da sie die fuumlr die Darstellung eines Fluids wesentliche Komponente die Entwicklung der Ge-schwindigkeit charakterisieren Auszligerdem bilden sie viele physikalische Effekte ab wie zum BeispielTurbulenzen und Grenzschichten innerhalb der Stroumlmung Deshalb wollen wir diese Gleichungen imFolgenden genauer betrachten Dabei orientieren wir uns an den Ausfuumlhrungen von [Stam] und [Harris]Das Ziel des im weiteren Verlauf dieser Arbeit entwickelten Loumlsungsverfahrens ist die Generierung ei-nes fluidartigen Verhaltens welches zwar auf den Navier-Stokes Gleichungen basiert dessen berechnetesGeschwindigkeitsfeld die Gleichungen jedoch nicht exakt erfuumlllt Die hier vorgestellte Methode wurdeurspruumlnglich fuumlr Computeranimationen entworfen und nicht fuumlr Anwendungen aus den Ingenieurswis-senschaften was unser leicht inexaktes Vorgehen zur Fluidsimulation rechtfertigt

21 Die Navier-Stokes Gleichungen

Zunaumlchst treffen wir einige in der Fluidsimulation durchaus uumlbliche Annahmen die auf eine vereinfach-te Form der Navier-Stokes Gleichungen fuumlhren und trotzdem die Qualitaumlt des mathematischen Modellserhalten Dazu nehmen wir die Dichte ρ des Fluids sowie seine Temperatur θ als konstant bezuumlglichOrt und Zeit an wodurch wir die Beschreibung eines inkompressiblen Fluids erhalten Aufgrund die-ser Annahmen muumlssen wir uns in der Simulation auf sogenannte bdquonewtonscheldquo Fluide beschraumlnken DieEntwicklung eines solchen Fluids in einem zweidimensionalen Gebiet Ω sub R2 uumlber einem ZeitintervallI = [0 T ] mit T isin R+ koumlnnen wir durch die inkompressiblen Navier-Stokes Gleichungen charakterisie-ren welche das Fluidverhalten mathematisch beschreiben

partu

partt= minus (u middot nabla)uminus 1

ρnablap+ νnabla middot nablau + f (21)

nabla middot u = 0 (22)

Dabei bezeichnen wir mit u = u (x t) die Geschwindigkeit mit p = p (x t) den Druck mit ν diekinematische Viskositaumlt und mit ρ die Dichte des Fluids Es ist dabei zu beachten dass wir in unsererSimulation nur den Druck innerhalb des Fluids beruumlcksichtigen und den Atmosphaumlrendruck vernachlaumls-sigen Durch die Groumlszlige f = f (x t) definieren wir eine externe Kraft im Punkt x isin Ω zur Zeit t isin I Hierbei treffen wir die Konvention dass die fett gedruckten Ausdruumlcke vektorwertige Groumlszligen in derRegel Vektorfelder und die kursiven skalare Groumlszligen repraumlsentieren Fuumlr Details zu den Navier-StokesGleichungen und deren Herleitung aus den allgemeinen Erhaltungsgleichungen der Kontinuumsmecha-nik verweisen wir auf [Anderson]Im Folgenden wollen wir uns kurz den einzelnen Bestandteilen von Gleichung (21) widmen und ihre

3

KAPITEL 2 THEORETISCHE GRUNDLAGEN 4

physikalische Bedeutung erlaumlutern wozu wir einige Begriffe definieren

AdvektionUumlblicherweise kann ein Fluid Objekte oder andere Substanzen transportieren In unserem Fall beschraumln-ken wir uns lediglich darauf dass es bdquosich selbstldquo transportiert Es wird also durch die eigene Ge-schwindigkeit fortbewegt Dieses Verhalten nennt sich Advektion und wird durch den Term minus (u middot nabla)ubeschrieben der den konvektiven Transport des Fluids darstellt Die Beruumlcksichtigung dieses Effekteszieht die Konsequenz nach sich dass die Navier-Stokes Gleichungen nichtlinear sind

DruckDie Teilchen in einem Fluid werden automatisch fortbewegt Dies fuumlhrt dazu dass sie sich gegenseitigan- und abstoszligen Wird eine Kraft auf das Fluid aufgepraumlgt so wird diese ebenfalls durch die Teilchenuumlbertragen Diese beiden Phaumlnomene fuumlhren zu einer Druckentwicklung im Fluid was letztendlich in ei-ner Beschleunigung der Teilchen resultiert Der Ausdruck minus1

ρnablap in Gleichung (21) repraumlsentiert diesenphysikalischen Sachverhalt in Abhaumlngigkeit von der Dichte ρ des Fluids und des auf das Fluid wirkendenDrucks p

DiffusionDieses physikalische Phaumlnomen haumlngt stark mit der Zaumlhfluumlssigkeit eines Fluids welche uumlber seine kine-matische Viskositaumlt ν beschrieben wird zusammen und hat einen groszligen Einfluss auf das FluidverhaltenZur Erlaumluterung geben wir zunaumlchst eine rein formale Definition der Viskositaumlt (vgl [Arlt])

Definition 211 (Viskositaumlt)Wir betrachten folgenden Versuchsaufbau

Abbildung 21 Versuchsaufbau zur Definition der Viskositaumlt

Im unteren Teil von Abbildung 21 befindet sich eine feststehende unbewegliche Wand M und im Ab-stand z zu dieser eine bewegliche Wand N mit der Oberflaumlche A Der Raum zwischen den Waumlnden istmit dem zu untersuchenden Fluid gefuumlllt Um die WandN mit der konstanten Geschwindigkeit v parallelzu M zu bewegen wird die Kraft benoumltigt die aus dem Newtonschen Gesetz

KAPITEL 2 THEORETISCHE GRUNDLAGEN 5

F = η middotA middot dv

dz

hervorgeht Somit ist die Kraft F proportional zu der Oberflaumlche A und dem Geschwindigkeits-gradienten dv

dz welcher der Beschleunigung der beweglichen Wand N entspricht Der Proportionali-taumltsfaktor η heiszligt dynamische Viskositaumlt und ist ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres Fluids Es gilthierbei je groumlszliger die Viskositaumlt desto zaumlhfluumlssiger das Fluid

Zu unterscheiden sind dabei zwei verschiedene Begriffe der Viskositaumlt Die dynamische Viskositaumlt η unddie kinematische Viskositaumlt ν welche wir in den Navier-Stokes Gleichungen (21) und (22) benoumltigenWir wollen nun beide Begriffe in Zusammenhang setzen Sei ρ die Dichte und η die dynamische Visko-sitaumlt unseres Fluids Dann ergibt sich die kinematische Viskositaumlt zu

ν =η

ρ (23)

Zaumlhe Fluumlssigkeiten also solche mit einer hohen Viskositaumlt reagieren traumlger auf Bewegungen als duumlnn-fluumlssige oder auch Fluide mit kleinerer Viskositaumlt wie etwa Olivenoumll im Vergleich zu Wasser DieserEffekt nennt sich Diffusion und geht durch den Term νnabla middotnablau in das mathematische Modell ein der dendiffusiven Transport des Fluids beruumlcksichtigt

KraumlfteWie bei der Beschreibung des Drucks bereits erwaumlhnt fuumlhrt das Aufpraumlgen von Kraumlften zur Beschleuni-gung der Fluidteilchen Moumlglich sind externe Kraumlfte also solche die bdquovon auszligenldquo auf das Fluid wirkenund Koumlrper- beziehungsweise Volumenkraumlfte die etwa durch die Erdbeschleunigung hervorgerufen wer-den An dieser Stelle sei schon einmal erwaumlhnt dass die externen Kraumlfte in der Simulation interaktivdurch den Anwender integriert werden koumlnnen (vgl Abschnitt 33)

Damit das Problem welches durch die Navier-Stokes Gleichungen formuliert wird wohlgestellt istmuumlssen wir zusaumltzlich sogenannte Anfangs- und Randbedingungen einfuumlhren auf die wir im folgendenAbschnitt eingehen

22 Anfangs- und Randbedingungen

Sowohl die Geschwindigkeit u als auch der Druck p treten in den Navier-Stokes Gleichungen als Un-bekannte auf und muumlssen in jedem Zeitschritt berechnet und aktualisiert werden Daher muumlssen wirgeeignete Anfangs- und Randbedingungen fuumlr beide Groumlszligen vorgebenDie Anfangsbedingung fuumlr das Druckfeld ist von Testfall zu Testfall unterschiedlich So nehmen wir ineinem Beispiel den initialen Druck als Null an womit p equiv 0 in Ω gilt Andererseits koumlnnen wir fuumlrden Druck sogenannte Druckspitzen vorschreiben wie wir sie in Kapitel 42 setzen Fuumlr das Geschwin-digkeitsfeld waumlhlen wir immer u equiv 0 als Anfangsbedingung und erzeugen Dynamik entweder durchexterne Kraumlfte wie etwa in Abschnitt 431 oder uumlber RandbedingungenIm Allgemeinen legen wir als Randbedingung fuumlr die Geschwindigkeit die sogenannte bdquono-slipldquo-Bedingung u|partΩ equiv 0 fest Wir setzen die Geschwindigkeit am Rand also auf Null was bedeutet dass dasFluid am Gebietsrand haften bleibt Wir koumlnnen aber auch wie beim Testfall Driven Cavity beschriebenan einer Kante des Rechengebiets einen von Null verschiedenen Wert vorschreiben Wir tragen somit ei-ne Tangentialgeschwindigkeit an und erzeugen mit ihrer Hilfe Dynamik im Fluid (vgl Abschnitt 412)Als Randbedingung fuumlr den Druck legen wir fest dass keine Aumlnderung in Normalenrichtung stattfindet

KAPITEL 2 THEORETISCHE GRUNDLAGEN 6

also partppartn |partΩ equiv 0 gilt wobei n den aumluszligeren Normalenvektor von Ω bezeichnet

Die verschiedenen Anfangs- und Randbedingungen sind miteinander und mit der Anwender-Interaktionder wir uns in Abschnitt 43 widmen kombinierbar Wir koumlnnen somit eine Vielzahl von Testfaumlllen kon-struieren von denen wir eine Auswahl in Kapitel 4 praumlsentieren

23 Projektionsverfahren und die Helmholtz-Hodge-Zerlegung

Nachdem wir zuvor alle Komponenten der Navier-Stokes Gleichungen aus physikalischer Sicht betrach-tet und Anfangs- sowie Randbedingungen eingefuumlhrt haben wollen wir sie nun in eine zum Loumlsen geeig-netere Form bringen und anschlieszligend ein Vorgehen zur Loumlsung dieser Gleichungen entwickeln Dabeiist die Art der Diskretisierung des von Raum- und Zeitvariablen abhaumlngigen Problems entscheidendZunaumlchst nehmen wir eine simple Zeitdiskretisierung vor indem wir das Zeitintervall I = [0 T ] inTeilintervalle zerlegen Anschlieszligend betrachten wir Gleichung (21) innerhalb eines Zeitschritts unddiskretisieren die auftretenden Operatoren im Ort (vgl Kapitel 24) Im Folgenden koumlnnen wir daherdie einzelnen Bestandteile dieser Gleichung als zeitunabhaumlngig ansehen da wir das Loumlsungsverfahreninnerhalb eines Zeitschritts entwickelnUm die Gleichungen in ein besser zu loumlsendes System zu uumlberfuumlhren betrachten wir als Hilfsmittelzunaumlchst die sogenannte Helmholtz-Hodge Zerlegung (vgl [Chorin])

Satz 231 Sei Ω sub R2 ein Gebiet mit glattem Rand partΩ Dann kann jedes Vektorfeld w zerlegt werdenin die Form

w = u +nablapwobei nabla middot u = 0 gilt das Vektorfeld u also divergenzfrei ist Auszligerdem ist u parallel zu partΩ das heiszligtu middot n = 0 mit dem aumluszligeren Normalenvektor n von Ω p bezeichnet ein Skalarfeld

In jedem Zeitschritt muumlssen wir Gleichung (21) loumlsen wobei wir gewaumlhrleisten muumlssen dass Glei-chung (22) gilt Wenn wir nun davon ausgehen durch das Loumlsen von Gleichung (21) ein Geschwindig-keitsfeld w erhalten zu haben so muss nicht zwangslaumlufig nabla middotw = 0 gelten Dies erreichen wir durchAnwenden von Satz 231 auf das Geschwindigkeitsfeld w Wir setzen somit am Ende des Zeitschrittsdas aktualisierte Geschwindigkeitsfeld analog zu obigem Satz als u = w minusnablapJetzt stellt sich die Frage wie das Skalarfeld p zu berechnen ist Wenden wir den Divergenz-Operatornablamiddot auf beide Seiten der Gleichung aus Satz 231 an so erhalten wir

nabla middotw = nabla middot u︸ ︷︷ ︸=0

+nabla middot nablap

hArr nabla middotw = nabla middot nablap (24)

Setzen wir also die Loumlsung von Gleichung (21) als bekannt voraus so koumlnnen wir durch Loumlsen derPoisson-Gleichung (24) den Druck p ermitteln mit dem wir das Geschwindigkeitsfeld w so modifizie-ren koumlnnen dass es Gleichung (22) erfuumlllt Als naumlchstes muumlssen wir uns damit beschaumlftigen wie wir dasvorlaumlufige Geschwindigkeitsfeld w berechnen koumlnnen

Zunaumlchst definieren wir hierzu mit Hilfe von Satz 231 einen linearen Operator P der ein Vektorfeld wauf seinen divergenzfreien Teil projiziert Fuumlr diesen Operator gilt dann

P (w) = P (u) + P (nablap) da P linear ist

P (w) = u wegen Satz 231 und (25)

P (u) = u nach Voraussetzung

KAPITEL 2 THEORETISCHE GRUNDLAGEN 7

woraus insgesamt

P (nablap) = 0 (26)

folgtAnhand von Gleichung (25) koumlnnen wir uns mit dem Schwarzschen Satz (vgl [Forster]) uumlberlegendass P

(partupartt

)= partu

partt gilt Der Satz von Schwarz besagt dass bei einer q-mal stetig partiell differen-zierbaren Funktion die ersten q Ableitungen vertauscht werden duumlrfen Bei uns gilt nach Voraussetzungu isin C2 (Ω)capC1 (I) da die Ausdruumlckenablamiddotnablau und partu

partt in Gleichung (21) eine entsprechende Glattheit desGeschwindigkeitsfeldes bezuumlglich der Variablen (x t) verlangen Dabei bezeichnet Ck (Ul) den Raumder k-mal stetig partiell differenzierbaren Funktionen uumlber U2 = Ω sub R2 beziehungsweise U1 = I sub Rmit k l isin 1 2 Somit folgt

nabla middot partupartt

=part

partt(nabla middot u) = 0

Wenden wir nun den Operator P auf Gleichung (21) an und nutzen seine Linearitaumlt undGleichung (26) aus so erhalten wir

partu

partt= P (minus (u middot nabla)u + νnabla middot nablau + f) (27)

Aus Gleichung (27) ergibt sich direkt der von uns verwendete Algorithmus zur Loumlsung der Navier-StokesGleichungen der sich in vier Schritte gliedert

u (middot t) = w0Kraft aufpraumlgenminusminusminusminusminusminusminusminusrarr w1

Advektionminusminusminusminusminusrarr w2Diffusionminusminusminusminusminusrarr w3

Projektionminusminusminusminusminusrarr w4 = u (middot t+ 1) (28)

Wir nehmen an dass uns das Geschwindigkeitsfeld u zum Zeitpunkt t bekannt ist und setzenw0 (x) = u (x t) Pro Zeitschritt loumlsen wir die Gleichung (21) durch sogenanntes bdquoOperator-Splittingldquosukzessiv numerisch Wie in allen Projektionsmethoden entsteht auch hier durch das Splitting ein nu-merischer Fehler wodurch wir Gleichung (21) nicht mehr exakt loumlsen Leider geht [Stam] in seinerOriginalarbeit nicht auf die Ordnung des Verfahrens ein aufgrund der Struktur des Verfahrens und derAumlhnlichkeit zu Chorinschen Projektionsmethoden (vgl [Anderson]) ist aber nicht von einer hohen Ord-nung auszugehen Schlieszliglich gewaumlhrleisten wir durch das Anwenden des oben definierten Projektions-operators P dass Gleichung (22) erfuumlllt ist was anschaulich aus Abbildung 22 hervorgeht

Abbildung 22 Sukzessive Berechnung der Geschwindigkeit in einem Punkt innerhalb eines Zeitschritts(vgl [Stam])

Am Ende eines jeden Zeitschritts setzen wir w0 = w4 Da wir wie oben beschrieben ausgehend vonw0 innerhalb eines Zeitschrittes operieren haumlngen die Geschwindigkeitsfelder wk k isin 0 1 2 3 4

KAPITEL 2 THEORETISCHE GRUNDLAGEN 8

waumlhrend der Berechnung nur von der Ortsvariablen x ab Das Vektorfeld w4 entspricht schlieszliglich demGeschwindigkeitsfeld u zum Zeitpunkt t+∆t also u (x t+ ∆t) mit der Zeitschrittweite ∆t isin R+ DieSimulation erhalten wir letztendlich durch Iteration der in Schema (28) beschriebenen Vorgehensweiseuumlber die Zeitschritte Daraus ergibt sich durch Diskretisierung der auftretenden Operatoren ein nume-risches Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen (21) und (22) worauf wir im naumlchstenAbschnitt eingehen

24 Diskretisierung und numerische Loumlsung

Wir erlaumlutern in diesem Abschnitt die in Schema (28) angefuumlhrten Schritte und stellen Diskretisierungs-beziehungsweise Loumlsungstechniken vor um abschlieszligend ein kompaktes Loumlsungsverfahren der Navier-Stokes Gleichungen aufzustellen Zur Diskretisierung aller auftretenden Operatoren verwenden wir indieser Arbeit meist finite Differenzen zweiter Ordnung Approximationen abweichender Ordnung sindbeispielsweise bei der Behandlung von Randbedingungen noumltig auf die wir in Abschnitt 314 naumlhereingehenWie in Abschnitt 23 bereits erwaumlhnt diskretisieren wir das durch die Navier-Stokes Gleichungen (21)und (22) und Anfangs- sowie Randbedingungen gestellte Problem zuerst in der Zeit und anschlieszligendim Ort Dazu waumlhlen wir eine aumlquidistante Zerlegung des Zeitintervalls in L Teilintervalle der Form

I = [0 T ] =

L⋃l=1

[t(lminus1) t(l)

]

wobei t(l) = l middot∆t und T = L middot∆t gilt Die folgenden Diskretisierungen im Ort fuumlhren wir nun jeweilszu einem festen Zeitpunkt t(l) durch weshalb die auftretenden Groumlszligen zeitunabhaumlngig sindFuumlr unsere Simulation betrachten wir das quadratische Rechengebiet Ω = [minus1 1]2 sub R2 in dem sichdas Fluid befinden soll Davon ausgehend definieren wir ein diskretes Gebiet Ωh mit Schrittweite h isin Rdie wir sowohl in x- als auch in y-Richtung zur Diskretisierung verwenden Dadurch ergibt sich Ωh alsein Gitter fuumlr das xij isin Ωh die Form xij = (minus1 + ihminus1 + jh) hat wobei i j isin 0 n minus 1gilt und n isin N die Anzahl der Gitterpunkte pro Zeile beziehungsweise Spalte im Gitter angibt ImFolgenden betrachten wir nur die Operationen innerhalb eines Zeitschrittes das heiszligt im Uumlbergang vont(l) nach t(l) + ∆t Dazu sei w0 wie oben als bekanntes Geschwindigkeitsfeld u

(x t(l)

)definiert und

wk k isin 1 2 3 4 bezeichnet die unterschiedlichen Geschwindigkeitsfelder innerhalb des ZeitschrittsNach diesen Vorbereitungen widmen wir uns nun Diskretisierungs- und Loumlsungsmethoden fuumlr die ein-zelnen Bestandteile von Gleichung (27) beziehungsweise Schema (28)

Kraft aufpraumlgenZuerst kann dem Fluid eine Kraft aufgepraumlgt werden Dies geschieht waumlhrend der Simulation durch denAnwender und soll nur ein Mal pro Zeitschritt erfolgen Deshalb koumlnnen wir die Annahme treffen dassdie Kraft uumlber den gesamten Zeitschritt konstant ist Somit ist eine Beruumlcksichtigung der Kraft zu Beginneines jeden Zeitschritts ausreichend Wir berechnen also im ersten Schritt unseres Loumlsers

w1 = w0 + ∆tf (29)

was eine gute Approximation der Wirkung der Kraft uumlber den Zeitschritt darstellt da wir ihren Einflussdurch die Multiplikation des Kraftfeldes f mit der Zeitschrittweite ∆t uumlber den ganzen Zeitschritt trans-portieren

KAPITEL 2 THEORETISCHE GRUNDLAGEN 9

AdvektionUm die Advektion des Fluids zu beruumlcksichtigen fassen wir die Gitterpunkte als die oben beschriebenenTeilchen beziehungsweise Fluidpartikel auf und muumlssen dann in jedem Zeitschritt die Geschwindigkeiteines solchen Partikels aktualisierenEine erste Idee waumlre es hierzu folgende explizite Methode zu betrachten Die Position r eines Partikelsveraumlndert sich mit der Geschwindigkeit also koumlnnen wir die Position so weit verschieben wie sich dasPartikel in der Zeit ∆t mit seiner Geschwindigkeit fortbewegt Also gilt

r(t(l) + ∆t

)= r

(t(l))

+ ∆tu(t(l))

was dem expliziten Eulerverfahren entspricht Allerdings ist diese Methode instabil fuumlr groszlige Zeitschritt-weitenWir betrachten deshalb die implizite Methode der Charakteristiken die die Stabilitaumlt des Verfahrens im-pliziert Zur genaueren Erlaumluterung dieses Verfahrens verweisen wir auf [Stam] und geben hier nur einegrobe Zusammenfassung Im Wesentlichen verfolgen wir jeden Punkt x isin Ω uumlber die Zeit ∆t entlangw1 zuruumlck Dadurch entsteht ein Pfad p (x t) von x zu einem Punkt x0 = p (xminus∆t) der auch alsStromlinie interpretiert werden kann Dies wird in Abbildung 23 verdeutlicht

Abbildung 23 Weg den ein Fluidpartikel in der Zeit zuruumlcklegt (vgl [Stam])

Wir setzen dann die neue Geschwindigkeit w2 im Punkt x als die Geschwindigkeit die im Punkt x0 zurvorherigen Zeit vorliegt also

w2 (x) = w1 (p (xminus∆t)) = w1 (xminus∆tw1 (x)) (210)

Durch das Verwenden der Methode der Charakteristiken liefert unser Vorgehen eine fuumlr beliebig groszligeZeitschrittweiten und Geschwindigkeiten unbedingt stabile numerische Loumlsung (vgl [Stam]) Das koumln-nen wir daran feststellen dass der maximale Wert des Geschwindigkeitsfeldes in diesem Schritt niegroumlszliger als im vorherigen Zeitschritt werden kann auszliger wir praumlgen eine externe Kraft auf Denn nachGleichung (210) gilt

max(w2

(l))le max

(w1

(l))

(29)= max

(w0

(l) + ∆tf (l))

f (l)equiv0= max

(w4

(lminus1))

wobei ()(l) die entsprechende Groumlszlige im l-ten Zeitschritt bezeichnet Es ist f (l) equiv 0 da wir hier keineAnwender-Interaktion beruumlcksichtigenFuumlr Details zur Implementierung der Methode der Charakteristiken verweisen wir auf Kapitel 31

KAPITEL 2 THEORETISCHE GRUNDLAGEN 10

DiffusionHier betrachten wir eine Gleichung der Form

partu

partt= νnabla middot nablau (211)

Um diese numerisch zu loumlsen diskretisieren wir zunaumlchst den Laplace-Operatornabla middotnabla mit finiten Diffe-renzen im Ort und wenden dann ein Zeitschrittverfahren an Die Anwendung vonnablamiddotnabla auf das Geschwin-digkeitsfeld u erfolgt komponentenweise in x- beziehungsweise y-Richtung weshalb wir vereinfachenddie Diskretisierung des Operators angewendet auf ein hinreichend glattes Skalarfeld s betrachten Wirstellen also die Diskretisierung vonnabla middot nablas = part2s

partx2+ part2s

party2im R2 auf Dann gilt

(nabla middot nablas)ij asympsi+1j minus 2sij + siminus1j

h2+sij+1 minus 2sij + sijminus1

h2(212)

mit sij = s (xij) und analog (nabla middot nablas)ij = nabla middot nablas (xij) fuumlr xij isin Ωh Betrachten wir das durchGleichung (212) diskretisierte Skalarfeld s in jedem Gitterpunkt koumlnnen wir den diskretisierten Laplace-Operator als Matrix auffassen welche die folgende Gestalt aufweist

1

h2

Bn In

In In

In Bn

mit Bn =

minus4 1

1 1

1 minus4

isin Rntimesn (213)

Hierbei bezeichnet In die Einheitsmatrix der Dimension ntimesn Wenden wir auf die im Ort diskretisierteGleichung (211) ein explizites Zeitschrittverfahren der Form

u (x t+ ∆t) = u (x t) + ν∆tnabla middot nablau (x t) (214)

an so tritt erneut das Problem der Instabilitaumlt fuumlr groszlige Zeitschrittweiten ∆t beziehungsweise groszligekinematische Viskositaumlten ν auf Diese Schwierigkeit taucht auf da die Methode einem expliziten Euler-Verfahren entspricht und daher aumlhnliche Eigenschaften bezuumlglich der Stabilitaumlt aufweist Um eine stabileLoumlsungsmethode zu konstruieren verwenden wir statt des in Gleichung (214) angefuumlhrten ein implizitesVerfahren was sich durch Uumlbertragen auf unsere Schreibweise innerhalb eines Zeitschrittes schreibenlaumlsst als

(Iminus ν∆tnabla middot nabla)w3 = w2 (215)

wobei I den Identitaumltsoperator darstellt Diese Gleichung entspricht einer Poisson-Gleichung fuumlr dasGeschwindigkeitsfeld w3 Setzen wir den diskretisierten Laplace-Operator aus Gleichung (213) in Glei-chung (215) ein so ergibt sich die Darstellung fuumlr die Systemmatrix des zu loumlsenden Gleichungssystemsals

ν∆t

h2

Bn minusInminusIn

minusInminusIn Bn

mit Bn =

4 + h2

ν∆t minus1

minus1 minus1

minus1 4 + h2

ν∆t

(216)

Das daraus resultierende Gleichungssystem muumlssen wir nun effizient loumlsen worauf wir in Kapitel 31eingehen

KAPITEL 2 THEORETISCHE GRUNDLAGEN 11

ProjektionIm Projektionsschritt betrachten wir Gleichung (24) und erhalten wie im Diffusionsschritt eine Poisson-Gleichung zur Berechnung des Druckfeldes p Auch hier ergibt sich durch die Diskretisierung vonnablamiddotnablaein duumlnn besetztes lineares Gleichungssystem mit rechter Seite nabla middot w3 welches wir loumlsen muumlssen umals Abschluss unseres Algorithmus die aktualisierte Geschwindigkeit uumlber die Gleichung

u (x t+ ∆t) = w4 = w3 minusnablap (217)

berechnen zu koumlnnen Dazu verwenden wir folgende Diskretisierungen der auftretenden Operatoren

(nablas)ij =

(parts

partxparts

party

)ij

asymp(si+1j minus siminus1j

2hsij+1 minus sijminus1

2h

)(218)

(nabla middot v)ij =

(partvx

partx+partvy

party

)ij

asymp

(vxi+1j minus vximinus1j

2h+vyij+1 minus v

yijminus1

2h

) (219)

wobei s erneut ein Skalarfeld und v = (vx vy) ein zweidimensionales Vektorfeld mit x- und y-Komponentebezeichnet Analog zu der Schreibweise in Gleichung (212) repraumlsentieren ()ij die entsprechendenGroumlszligen ausgewertet im Punkt xij isin Ωh

Nun sind wir in der Lage im naumlchsten Zeitschritt das Geschwindigkeitsfeld zu berechnen und schlieszligensomit die Diskretisierung der Navier-Stokes Gleichungen (21) und (22) ab Dazu fassen wir die wesent-lichen Ergebnisse dieses Unterkapitels in algorithmischer Form zusammen Wir orientieren uns dabei anden in Schema (28) angefuumlhrten Schritten und erhalten so ein kompaktes numerisches Loumlsungsverfahrender Navier-Stokes Gleichungen

Algorithmus 241 (bdquoStable Fluidsldquo Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen nach[Stam])Sei ein initiales Geschwindigkeitsfeld w0

(0) (x) = u (x 0) gegebenFuumlr l = 1 L

1 Kraft aufpraumlgen w1(l) (x) = w0

(lminus1) (x) + ∆tf (l) (x)

2 Advektion w2(l) (x) = w1

(l)(xminus∆tw1

(l) (x))

3 Diffusion bestimme w3(l) uumlber (Iminus ν∆tnabla middot nabla)w3

(l) = w2(l)

4 Projektion w4(l) = w3

(l) minusnablap(l) wobei sich p(l) ergibt aus nabla middot nablap(l) = nabla middotw3(l)

5 Aktualisierung w0(l) (x) = u (x l middot∆t) = w4

(l) (x)

Die Anzahl L + 1 der durchzufuumlhrenden Zeitschritte legen wir dadurch fest wie lange wir die Simu-lation ausfuumlhren Das Kraftfeld f (l) wird durch den Anwender von auszligen bestimmt und steht in jedemZeitschritt aktualisiert zur Verfuumlgung Die genaue Umsetzung der Schritte in Algorithmus 241 stellenwir in Kapitel 3 vor

Kapitel 3

Implementierung

Nachdem wir in Kapitel 2 auf die in unserer Simulation verwendete Theorie bezuumlglich Modell Dis-kretisierung und numerischer Loumlsung eingegangen sind wollen wir uns nun ihrer Umsetzung und derRealisierung der Visualisierung und Interaktion auf einem Tablet-Computer widmen Die Stroumlmungs-simulation fuumlhren wir auf dem Asus EeePad Transformer TF101 auf dem das Betriebssystem Android403 installiert ist in einer App aus Details zur Hardware des verwendeten Tablet-Computers findensich in Kapitel 44 Der Anwender hat waumlhrend der Simulation die Moumlglichkeit die Stroumlmung einesFluids durch Beruumlhren des Bildschirms zu beeinflussen Stroumlmungssimulationen wie sie etwa bei [Stam]oder [Harris] beschrieben werden koumlnnen vom Nutzer durch Interaktion mit der Maus beeinflusst wer-den auf einem Tablet-Computer besteht jedoch die Moumlglichkeit dies mit einem Finger auf dem Bild-schirm durchzufuumlhren Dadurch wirkt die Simulation fuumlr den Betrachter realer Die Moumlglichkeit solcheComputer zur Stroumlmungssimulation einzusetzen wird dadurch eroumlffnet dass Tablet-Computer hinsicht-lich ihrer Rechenleistung immer leistungsfaumlhiger werdenBevor wir auf die konkrete Implementierung des in Kapitel 2 vorgestellten Verfahrens eingehen wollenwir zunaumlchst das Vorgehen bei einer App-Programmierung in der Programmiersprache Java fuumlr das An-droid-Betriebssystem erlaumlutern wobei wir uns an [Android Developer] orientieren Zunaumlchst installierenwir eine Software-Entwicklungsumgebung wie etwa Eclipse1 in der wir die eigentliche Programmie-rung durchfuumlhren Ergaumlnzend benoumltigen wir das Android Software Development Kit sowie die AndroidDevelopment Tools die wir in die Entwicklungsumgebung einbinden muumlssen Anschlieszligend koumlnnen wirein neues Android App Project erstellen welches die App repraumlsentiert Dabei werden einige Dateienautomatisch erstellt wie etwa die Manifest-Datei die eine zentrale Rolle einnimmt da sie die funda-mentalen Charakteristiken der App beschreibt und jede ihrer Komponenten definiert Die Programmie-rung einer App unterscheidet sich vor allem dadurch von einer bdquogewoumlhnlichenldquo Java-Programmierungals dass zum korrekten Erstellen der App viele spezielle Funktionen vom System verlangt werden diewir implementieren muumlssen Auch die Umsetzung der Visualisierung mit Hilfe der OpenGL ES 20-Bibliothek verlangt ein gesondertes Vorgehen Wir muumlssen die Visualisierung in eine eigene Klasse aus-lagern diese entsprechend kennzeichnen und erneut vom System verlangte Funktionen integrieren Aumlhn-lich verhaumllt es sich bei der Beruumlcksichtigung der Anwender-InteraktionUm eine App schlieszliglich auszufuumlhren bestehen zwei Moumlglichkeiten Einerseits koumlnnen wir die App aufeinem externen Android-Geraumlt starten zum Beispiel einem Tablet-Computer andererseits den Emula-tor nutzen Dabei handelt es sich um eine sogenannte Android Virtual Device die auf dem Computerausgefuumlhrt wird auf dem sich die Entwicklungsumgebung befindet Die Virtual Device entspricht ei-nem externen Geraumlt welches auf dem Computer simuliert wird Es empfiehlt sich die App zunaumlchstim Emulator zu testen da bei eventuellen Programmierfehlern das externe Geraumlt durch Uumlberhitzungoder aumlhnliches beschaumldigt werden kann Bisher ist es nicht moumlglich Apps auf dem Emulator zu tes-ten die sich der Bibliothek OpenGL ES 20 zur Darstellung von Grafiken bedienen wie wir sie fuumlr

1Fuumlr naumlhere Informationen verweisen wir auf httpwwweclipseorg

12

Kapitel 2

Theoretische Grundlagen

Zur Simulation einer Stroumlmung in einem Fluid in einem bestimmten Zeitintervall benoumltigen wir einemathematische Beschreibung seines Verhaltens Ein gutes Modell dafuumlr sind die Navier-Stokes Glei-chungen da sie die fuumlr die Darstellung eines Fluids wesentliche Komponente die Entwicklung der Ge-schwindigkeit charakterisieren Auszligerdem bilden sie viele physikalische Effekte ab wie zum BeispielTurbulenzen und Grenzschichten innerhalb der Stroumlmung Deshalb wollen wir diese Gleichungen imFolgenden genauer betrachten Dabei orientieren wir uns an den Ausfuumlhrungen von [Stam] und [Harris]Das Ziel des im weiteren Verlauf dieser Arbeit entwickelten Loumlsungsverfahrens ist die Generierung ei-nes fluidartigen Verhaltens welches zwar auf den Navier-Stokes Gleichungen basiert dessen berechnetesGeschwindigkeitsfeld die Gleichungen jedoch nicht exakt erfuumlllt Die hier vorgestellte Methode wurdeurspruumlnglich fuumlr Computeranimationen entworfen und nicht fuumlr Anwendungen aus den Ingenieurswis-senschaften was unser leicht inexaktes Vorgehen zur Fluidsimulation rechtfertigt

21 Die Navier-Stokes Gleichungen

Zunaumlchst treffen wir einige in der Fluidsimulation durchaus uumlbliche Annahmen die auf eine vereinfach-te Form der Navier-Stokes Gleichungen fuumlhren und trotzdem die Qualitaumlt des mathematischen Modellserhalten Dazu nehmen wir die Dichte ρ des Fluids sowie seine Temperatur θ als konstant bezuumlglichOrt und Zeit an wodurch wir die Beschreibung eines inkompressiblen Fluids erhalten Aufgrund die-ser Annahmen muumlssen wir uns in der Simulation auf sogenannte bdquonewtonscheldquo Fluide beschraumlnken DieEntwicklung eines solchen Fluids in einem zweidimensionalen Gebiet Ω sub R2 uumlber einem ZeitintervallI = [0 T ] mit T isin R+ koumlnnen wir durch die inkompressiblen Navier-Stokes Gleichungen charakterisie-ren welche das Fluidverhalten mathematisch beschreiben

partu

partt= minus (u middot nabla)uminus 1

ρnablap+ νnabla middot nablau + f (21)

nabla middot u = 0 (22)

Dabei bezeichnen wir mit u = u (x t) die Geschwindigkeit mit p = p (x t) den Druck mit ν diekinematische Viskositaumlt und mit ρ die Dichte des Fluids Es ist dabei zu beachten dass wir in unsererSimulation nur den Druck innerhalb des Fluids beruumlcksichtigen und den Atmosphaumlrendruck vernachlaumls-sigen Durch die Groumlszlige f = f (x t) definieren wir eine externe Kraft im Punkt x isin Ω zur Zeit t isin I Hierbei treffen wir die Konvention dass die fett gedruckten Ausdruumlcke vektorwertige Groumlszligen in derRegel Vektorfelder und die kursiven skalare Groumlszligen repraumlsentieren Fuumlr Details zu den Navier-StokesGleichungen und deren Herleitung aus den allgemeinen Erhaltungsgleichungen der Kontinuumsmecha-nik verweisen wir auf [Anderson]Im Folgenden wollen wir uns kurz den einzelnen Bestandteilen von Gleichung (21) widmen und ihre

3

KAPITEL 2 THEORETISCHE GRUNDLAGEN 4

physikalische Bedeutung erlaumlutern wozu wir einige Begriffe definieren

AdvektionUumlblicherweise kann ein Fluid Objekte oder andere Substanzen transportieren In unserem Fall beschraumln-ken wir uns lediglich darauf dass es bdquosich selbstldquo transportiert Es wird also durch die eigene Ge-schwindigkeit fortbewegt Dieses Verhalten nennt sich Advektion und wird durch den Term minus (u middot nabla)ubeschrieben der den konvektiven Transport des Fluids darstellt Die Beruumlcksichtigung dieses Effekteszieht die Konsequenz nach sich dass die Navier-Stokes Gleichungen nichtlinear sind

DruckDie Teilchen in einem Fluid werden automatisch fortbewegt Dies fuumlhrt dazu dass sie sich gegenseitigan- und abstoszligen Wird eine Kraft auf das Fluid aufgepraumlgt so wird diese ebenfalls durch die Teilchenuumlbertragen Diese beiden Phaumlnomene fuumlhren zu einer Druckentwicklung im Fluid was letztendlich in ei-ner Beschleunigung der Teilchen resultiert Der Ausdruck minus1

ρnablap in Gleichung (21) repraumlsentiert diesenphysikalischen Sachverhalt in Abhaumlngigkeit von der Dichte ρ des Fluids und des auf das Fluid wirkendenDrucks p

DiffusionDieses physikalische Phaumlnomen haumlngt stark mit der Zaumlhfluumlssigkeit eines Fluids welche uumlber seine kine-matische Viskositaumlt ν beschrieben wird zusammen und hat einen groszligen Einfluss auf das FluidverhaltenZur Erlaumluterung geben wir zunaumlchst eine rein formale Definition der Viskositaumlt (vgl [Arlt])

Definition 211 (Viskositaumlt)Wir betrachten folgenden Versuchsaufbau

Abbildung 21 Versuchsaufbau zur Definition der Viskositaumlt

Im unteren Teil von Abbildung 21 befindet sich eine feststehende unbewegliche Wand M und im Ab-stand z zu dieser eine bewegliche Wand N mit der Oberflaumlche A Der Raum zwischen den Waumlnden istmit dem zu untersuchenden Fluid gefuumlllt Um die WandN mit der konstanten Geschwindigkeit v parallelzu M zu bewegen wird die Kraft benoumltigt die aus dem Newtonschen Gesetz

KAPITEL 2 THEORETISCHE GRUNDLAGEN 5

F = η middotA middot dv

dz

hervorgeht Somit ist die Kraft F proportional zu der Oberflaumlche A und dem Geschwindigkeits-gradienten dv

dz welcher der Beschleunigung der beweglichen Wand N entspricht Der Proportionali-taumltsfaktor η heiszligt dynamische Viskositaumlt und ist ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres Fluids Es gilthierbei je groumlszliger die Viskositaumlt desto zaumlhfluumlssiger das Fluid

Zu unterscheiden sind dabei zwei verschiedene Begriffe der Viskositaumlt Die dynamische Viskositaumlt η unddie kinematische Viskositaumlt ν welche wir in den Navier-Stokes Gleichungen (21) und (22) benoumltigenWir wollen nun beide Begriffe in Zusammenhang setzen Sei ρ die Dichte und η die dynamische Visko-sitaumlt unseres Fluids Dann ergibt sich die kinematische Viskositaumlt zu

ν =η

ρ (23)

Zaumlhe Fluumlssigkeiten also solche mit einer hohen Viskositaumlt reagieren traumlger auf Bewegungen als duumlnn-fluumlssige oder auch Fluide mit kleinerer Viskositaumlt wie etwa Olivenoumll im Vergleich zu Wasser DieserEffekt nennt sich Diffusion und geht durch den Term νnabla middotnablau in das mathematische Modell ein der dendiffusiven Transport des Fluids beruumlcksichtigt

KraumlfteWie bei der Beschreibung des Drucks bereits erwaumlhnt fuumlhrt das Aufpraumlgen von Kraumlften zur Beschleuni-gung der Fluidteilchen Moumlglich sind externe Kraumlfte also solche die bdquovon auszligenldquo auf das Fluid wirkenund Koumlrper- beziehungsweise Volumenkraumlfte die etwa durch die Erdbeschleunigung hervorgerufen wer-den An dieser Stelle sei schon einmal erwaumlhnt dass die externen Kraumlfte in der Simulation interaktivdurch den Anwender integriert werden koumlnnen (vgl Abschnitt 33)

Damit das Problem welches durch die Navier-Stokes Gleichungen formuliert wird wohlgestellt istmuumlssen wir zusaumltzlich sogenannte Anfangs- und Randbedingungen einfuumlhren auf die wir im folgendenAbschnitt eingehen

22 Anfangs- und Randbedingungen

Sowohl die Geschwindigkeit u als auch der Druck p treten in den Navier-Stokes Gleichungen als Un-bekannte auf und muumlssen in jedem Zeitschritt berechnet und aktualisiert werden Daher muumlssen wirgeeignete Anfangs- und Randbedingungen fuumlr beide Groumlszligen vorgebenDie Anfangsbedingung fuumlr das Druckfeld ist von Testfall zu Testfall unterschiedlich So nehmen wir ineinem Beispiel den initialen Druck als Null an womit p equiv 0 in Ω gilt Andererseits koumlnnen wir fuumlrden Druck sogenannte Druckspitzen vorschreiben wie wir sie in Kapitel 42 setzen Fuumlr das Geschwin-digkeitsfeld waumlhlen wir immer u equiv 0 als Anfangsbedingung und erzeugen Dynamik entweder durchexterne Kraumlfte wie etwa in Abschnitt 431 oder uumlber RandbedingungenIm Allgemeinen legen wir als Randbedingung fuumlr die Geschwindigkeit die sogenannte bdquono-slipldquo-Bedingung u|partΩ equiv 0 fest Wir setzen die Geschwindigkeit am Rand also auf Null was bedeutet dass dasFluid am Gebietsrand haften bleibt Wir koumlnnen aber auch wie beim Testfall Driven Cavity beschriebenan einer Kante des Rechengebiets einen von Null verschiedenen Wert vorschreiben Wir tragen somit ei-ne Tangentialgeschwindigkeit an und erzeugen mit ihrer Hilfe Dynamik im Fluid (vgl Abschnitt 412)Als Randbedingung fuumlr den Druck legen wir fest dass keine Aumlnderung in Normalenrichtung stattfindet

KAPITEL 2 THEORETISCHE GRUNDLAGEN 6

also partppartn |partΩ equiv 0 gilt wobei n den aumluszligeren Normalenvektor von Ω bezeichnet

Die verschiedenen Anfangs- und Randbedingungen sind miteinander und mit der Anwender-Interaktionder wir uns in Abschnitt 43 widmen kombinierbar Wir koumlnnen somit eine Vielzahl von Testfaumlllen kon-struieren von denen wir eine Auswahl in Kapitel 4 praumlsentieren

23 Projektionsverfahren und die Helmholtz-Hodge-Zerlegung

Nachdem wir zuvor alle Komponenten der Navier-Stokes Gleichungen aus physikalischer Sicht betrach-tet und Anfangs- sowie Randbedingungen eingefuumlhrt haben wollen wir sie nun in eine zum Loumlsen geeig-netere Form bringen und anschlieszligend ein Vorgehen zur Loumlsung dieser Gleichungen entwickeln Dabeiist die Art der Diskretisierung des von Raum- und Zeitvariablen abhaumlngigen Problems entscheidendZunaumlchst nehmen wir eine simple Zeitdiskretisierung vor indem wir das Zeitintervall I = [0 T ] inTeilintervalle zerlegen Anschlieszligend betrachten wir Gleichung (21) innerhalb eines Zeitschritts unddiskretisieren die auftretenden Operatoren im Ort (vgl Kapitel 24) Im Folgenden koumlnnen wir daherdie einzelnen Bestandteile dieser Gleichung als zeitunabhaumlngig ansehen da wir das Loumlsungsverfahreninnerhalb eines Zeitschritts entwickelnUm die Gleichungen in ein besser zu loumlsendes System zu uumlberfuumlhren betrachten wir als Hilfsmittelzunaumlchst die sogenannte Helmholtz-Hodge Zerlegung (vgl [Chorin])

Satz 231 Sei Ω sub R2 ein Gebiet mit glattem Rand partΩ Dann kann jedes Vektorfeld w zerlegt werdenin die Form

w = u +nablapwobei nabla middot u = 0 gilt das Vektorfeld u also divergenzfrei ist Auszligerdem ist u parallel zu partΩ das heiszligtu middot n = 0 mit dem aumluszligeren Normalenvektor n von Ω p bezeichnet ein Skalarfeld

In jedem Zeitschritt muumlssen wir Gleichung (21) loumlsen wobei wir gewaumlhrleisten muumlssen dass Glei-chung (22) gilt Wenn wir nun davon ausgehen durch das Loumlsen von Gleichung (21) ein Geschwindig-keitsfeld w erhalten zu haben so muss nicht zwangslaumlufig nabla middotw = 0 gelten Dies erreichen wir durchAnwenden von Satz 231 auf das Geschwindigkeitsfeld w Wir setzen somit am Ende des Zeitschrittsdas aktualisierte Geschwindigkeitsfeld analog zu obigem Satz als u = w minusnablapJetzt stellt sich die Frage wie das Skalarfeld p zu berechnen ist Wenden wir den Divergenz-Operatornablamiddot auf beide Seiten der Gleichung aus Satz 231 an so erhalten wir

nabla middotw = nabla middot u︸ ︷︷ ︸=0

+nabla middot nablap

hArr nabla middotw = nabla middot nablap (24)

Setzen wir also die Loumlsung von Gleichung (21) als bekannt voraus so koumlnnen wir durch Loumlsen derPoisson-Gleichung (24) den Druck p ermitteln mit dem wir das Geschwindigkeitsfeld w so modifizie-ren koumlnnen dass es Gleichung (22) erfuumlllt Als naumlchstes muumlssen wir uns damit beschaumlftigen wie wir dasvorlaumlufige Geschwindigkeitsfeld w berechnen koumlnnen

Zunaumlchst definieren wir hierzu mit Hilfe von Satz 231 einen linearen Operator P der ein Vektorfeld wauf seinen divergenzfreien Teil projiziert Fuumlr diesen Operator gilt dann

P (w) = P (u) + P (nablap) da P linear ist

P (w) = u wegen Satz 231 und (25)

P (u) = u nach Voraussetzung

KAPITEL 2 THEORETISCHE GRUNDLAGEN 7

woraus insgesamt

P (nablap) = 0 (26)

folgtAnhand von Gleichung (25) koumlnnen wir uns mit dem Schwarzschen Satz (vgl [Forster]) uumlberlegendass P

(partupartt

)= partu

partt gilt Der Satz von Schwarz besagt dass bei einer q-mal stetig partiell differen-zierbaren Funktion die ersten q Ableitungen vertauscht werden duumlrfen Bei uns gilt nach Voraussetzungu isin C2 (Ω)capC1 (I) da die Ausdruumlckenablamiddotnablau und partu

partt in Gleichung (21) eine entsprechende Glattheit desGeschwindigkeitsfeldes bezuumlglich der Variablen (x t) verlangen Dabei bezeichnet Ck (Ul) den Raumder k-mal stetig partiell differenzierbaren Funktionen uumlber U2 = Ω sub R2 beziehungsweise U1 = I sub Rmit k l isin 1 2 Somit folgt

nabla middot partupartt

=part

partt(nabla middot u) = 0

Wenden wir nun den Operator P auf Gleichung (21) an und nutzen seine Linearitaumlt undGleichung (26) aus so erhalten wir

partu

partt= P (minus (u middot nabla)u + νnabla middot nablau + f) (27)

Aus Gleichung (27) ergibt sich direkt der von uns verwendete Algorithmus zur Loumlsung der Navier-StokesGleichungen der sich in vier Schritte gliedert

u (middot t) = w0Kraft aufpraumlgenminusminusminusminusminusminusminusminusrarr w1

Advektionminusminusminusminusminusrarr w2Diffusionminusminusminusminusminusrarr w3

Projektionminusminusminusminusminusrarr w4 = u (middot t+ 1) (28)

Wir nehmen an dass uns das Geschwindigkeitsfeld u zum Zeitpunkt t bekannt ist und setzenw0 (x) = u (x t) Pro Zeitschritt loumlsen wir die Gleichung (21) durch sogenanntes bdquoOperator-Splittingldquosukzessiv numerisch Wie in allen Projektionsmethoden entsteht auch hier durch das Splitting ein nu-merischer Fehler wodurch wir Gleichung (21) nicht mehr exakt loumlsen Leider geht [Stam] in seinerOriginalarbeit nicht auf die Ordnung des Verfahrens ein aufgrund der Struktur des Verfahrens und derAumlhnlichkeit zu Chorinschen Projektionsmethoden (vgl [Anderson]) ist aber nicht von einer hohen Ord-nung auszugehen Schlieszliglich gewaumlhrleisten wir durch das Anwenden des oben definierten Projektions-operators P dass Gleichung (22) erfuumlllt ist was anschaulich aus Abbildung 22 hervorgeht

Abbildung 22 Sukzessive Berechnung der Geschwindigkeit in einem Punkt innerhalb eines Zeitschritts(vgl [Stam])

Am Ende eines jeden Zeitschritts setzen wir w0 = w4 Da wir wie oben beschrieben ausgehend vonw0 innerhalb eines Zeitschrittes operieren haumlngen die Geschwindigkeitsfelder wk k isin 0 1 2 3 4

KAPITEL 2 THEORETISCHE GRUNDLAGEN 8

waumlhrend der Berechnung nur von der Ortsvariablen x ab Das Vektorfeld w4 entspricht schlieszliglich demGeschwindigkeitsfeld u zum Zeitpunkt t+∆t also u (x t+ ∆t) mit der Zeitschrittweite ∆t isin R+ DieSimulation erhalten wir letztendlich durch Iteration der in Schema (28) beschriebenen Vorgehensweiseuumlber die Zeitschritte Daraus ergibt sich durch Diskretisierung der auftretenden Operatoren ein nume-risches Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen (21) und (22) worauf wir im naumlchstenAbschnitt eingehen

24 Diskretisierung und numerische Loumlsung

Wir erlaumlutern in diesem Abschnitt die in Schema (28) angefuumlhrten Schritte und stellen Diskretisierungs-beziehungsweise Loumlsungstechniken vor um abschlieszligend ein kompaktes Loumlsungsverfahren der Navier-Stokes Gleichungen aufzustellen Zur Diskretisierung aller auftretenden Operatoren verwenden wir indieser Arbeit meist finite Differenzen zweiter Ordnung Approximationen abweichender Ordnung sindbeispielsweise bei der Behandlung von Randbedingungen noumltig auf die wir in Abschnitt 314 naumlhereingehenWie in Abschnitt 23 bereits erwaumlhnt diskretisieren wir das durch die Navier-Stokes Gleichungen (21)und (22) und Anfangs- sowie Randbedingungen gestellte Problem zuerst in der Zeit und anschlieszligendim Ort Dazu waumlhlen wir eine aumlquidistante Zerlegung des Zeitintervalls in L Teilintervalle der Form

I = [0 T ] =

L⋃l=1

[t(lminus1) t(l)

]

wobei t(l) = l middot∆t und T = L middot∆t gilt Die folgenden Diskretisierungen im Ort fuumlhren wir nun jeweilszu einem festen Zeitpunkt t(l) durch weshalb die auftretenden Groumlszligen zeitunabhaumlngig sindFuumlr unsere Simulation betrachten wir das quadratische Rechengebiet Ω = [minus1 1]2 sub R2 in dem sichdas Fluid befinden soll Davon ausgehend definieren wir ein diskretes Gebiet Ωh mit Schrittweite h isin Rdie wir sowohl in x- als auch in y-Richtung zur Diskretisierung verwenden Dadurch ergibt sich Ωh alsein Gitter fuumlr das xij isin Ωh die Form xij = (minus1 + ihminus1 + jh) hat wobei i j isin 0 n minus 1gilt und n isin N die Anzahl der Gitterpunkte pro Zeile beziehungsweise Spalte im Gitter angibt ImFolgenden betrachten wir nur die Operationen innerhalb eines Zeitschrittes das heiszligt im Uumlbergang vont(l) nach t(l) + ∆t Dazu sei w0 wie oben als bekanntes Geschwindigkeitsfeld u

(x t(l)

)definiert und

wk k isin 1 2 3 4 bezeichnet die unterschiedlichen Geschwindigkeitsfelder innerhalb des ZeitschrittsNach diesen Vorbereitungen widmen wir uns nun Diskretisierungs- und Loumlsungsmethoden fuumlr die ein-zelnen Bestandteile von Gleichung (27) beziehungsweise Schema (28)

Kraft aufpraumlgenZuerst kann dem Fluid eine Kraft aufgepraumlgt werden Dies geschieht waumlhrend der Simulation durch denAnwender und soll nur ein Mal pro Zeitschritt erfolgen Deshalb koumlnnen wir die Annahme treffen dassdie Kraft uumlber den gesamten Zeitschritt konstant ist Somit ist eine Beruumlcksichtigung der Kraft zu Beginneines jeden Zeitschritts ausreichend Wir berechnen also im ersten Schritt unseres Loumlsers

w1 = w0 + ∆tf (29)

was eine gute Approximation der Wirkung der Kraft uumlber den Zeitschritt darstellt da wir ihren Einflussdurch die Multiplikation des Kraftfeldes f mit der Zeitschrittweite ∆t uumlber den ganzen Zeitschritt trans-portieren

KAPITEL 2 THEORETISCHE GRUNDLAGEN 9

AdvektionUm die Advektion des Fluids zu beruumlcksichtigen fassen wir die Gitterpunkte als die oben beschriebenenTeilchen beziehungsweise Fluidpartikel auf und muumlssen dann in jedem Zeitschritt die Geschwindigkeiteines solchen Partikels aktualisierenEine erste Idee waumlre es hierzu folgende explizite Methode zu betrachten Die Position r eines Partikelsveraumlndert sich mit der Geschwindigkeit also koumlnnen wir die Position so weit verschieben wie sich dasPartikel in der Zeit ∆t mit seiner Geschwindigkeit fortbewegt Also gilt

r(t(l) + ∆t

)= r

(t(l))

+ ∆tu(t(l))

was dem expliziten Eulerverfahren entspricht Allerdings ist diese Methode instabil fuumlr groszlige Zeitschritt-weitenWir betrachten deshalb die implizite Methode der Charakteristiken die die Stabilitaumlt des Verfahrens im-pliziert Zur genaueren Erlaumluterung dieses Verfahrens verweisen wir auf [Stam] und geben hier nur einegrobe Zusammenfassung Im Wesentlichen verfolgen wir jeden Punkt x isin Ω uumlber die Zeit ∆t entlangw1 zuruumlck Dadurch entsteht ein Pfad p (x t) von x zu einem Punkt x0 = p (xminus∆t) der auch alsStromlinie interpretiert werden kann Dies wird in Abbildung 23 verdeutlicht

Abbildung 23 Weg den ein Fluidpartikel in der Zeit zuruumlcklegt (vgl [Stam])

Wir setzen dann die neue Geschwindigkeit w2 im Punkt x als die Geschwindigkeit die im Punkt x0 zurvorherigen Zeit vorliegt also

w2 (x) = w1 (p (xminus∆t)) = w1 (xminus∆tw1 (x)) (210)

Durch das Verwenden der Methode der Charakteristiken liefert unser Vorgehen eine fuumlr beliebig groszligeZeitschrittweiten und Geschwindigkeiten unbedingt stabile numerische Loumlsung (vgl [Stam]) Das koumln-nen wir daran feststellen dass der maximale Wert des Geschwindigkeitsfeldes in diesem Schritt niegroumlszliger als im vorherigen Zeitschritt werden kann auszliger wir praumlgen eine externe Kraft auf Denn nachGleichung (210) gilt

max(w2

(l))le max

(w1

(l))

(29)= max

(w0

(l) + ∆tf (l))

f (l)equiv0= max

(w4

(lminus1))

wobei ()(l) die entsprechende Groumlszlige im l-ten Zeitschritt bezeichnet Es ist f (l) equiv 0 da wir hier keineAnwender-Interaktion beruumlcksichtigenFuumlr Details zur Implementierung der Methode der Charakteristiken verweisen wir auf Kapitel 31

KAPITEL 2 THEORETISCHE GRUNDLAGEN 10

DiffusionHier betrachten wir eine Gleichung der Form

partu

partt= νnabla middot nablau (211)

Um diese numerisch zu loumlsen diskretisieren wir zunaumlchst den Laplace-Operatornabla middotnabla mit finiten Diffe-renzen im Ort und wenden dann ein Zeitschrittverfahren an Die Anwendung vonnablamiddotnabla auf das Geschwin-digkeitsfeld u erfolgt komponentenweise in x- beziehungsweise y-Richtung weshalb wir vereinfachenddie Diskretisierung des Operators angewendet auf ein hinreichend glattes Skalarfeld s betrachten Wirstellen also die Diskretisierung vonnabla middot nablas = part2s

partx2+ part2s

party2im R2 auf Dann gilt

(nabla middot nablas)ij asympsi+1j minus 2sij + siminus1j

h2+sij+1 minus 2sij + sijminus1

h2(212)

mit sij = s (xij) und analog (nabla middot nablas)ij = nabla middot nablas (xij) fuumlr xij isin Ωh Betrachten wir das durchGleichung (212) diskretisierte Skalarfeld s in jedem Gitterpunkt koumlnnen wir den diskretisierten Laplace-Operator als Matrix auffassen welche die folgende Gestalt aufweist

1

h2

Bn In

In In

In Bn

mit Bn =

minus4 1

1 1

1 minus4

isin Rntimesn (213)

Hierbei bezeichnet In die Einheitsmatrix der Dimension ntimesn Wenden wir auf die im Ort diskretisierteGleichung (211) ein explizites Zeitschrittverfahren der Form

u (x t+ ∆t) = u (x t) + ν∆tnabla middot nablau (x t) (214)

an so tritt erneut das Problem der Instabilitaumlt fuumlr groszlige Zeitschrittweiten ∆t beziehungsweise groszligekinematische Viskositaumlten ν auf Diese Schwierigkeit taucht auf da die Methode einem expliziten Euler-Verfahren entspricht und daher aumlhnliche Eigenschaften bezuumlglich der Stabilitaumlt aufweist Um eine stabileLoumlsungsmethode zu konstruieren verwenden wir statt des in Gleichung (214) angefuumlhrten ein implizitesVerfahren was sich durch Uumlbertragen auf unsere Schreibweise innerhalb eines Zeitschrittes schreibenlaumlsst als

(Iminus ν∆tnabla middot nabla)w3 = w2 (215)

wobei I den Identitaumltsoperator darstellt Diese Gleichung entspricht einer Poisson-Gleichung fuumlr dasGeschwindigkeitsfeld w3 Setzen wir den diskretisierten Laplace-Operator aus Gleichung (213) in Glei-chung (215) ein so ergibt sich die Darstellung fuumlr die Systemmatrix des zu loumlsenden Gleichungssystemsals

ν∆t

h2

Bn minusInminusIn

minusInminusIn Bn

mit Bn =

4 + h2

ν∆t minus1

minus1 minus1

minus1 4 + h2

ν∆t

(216)

Das daraus resultierende Gleichungssystem muumlssen wir nun effizient loumlsen worauf wir in Kapitel 31eingehen

KAPITEL 2 THEORETISCHE GRUNDLAGEN 11

ProjektionIm Projektionsschritt betrachten wir Gleichung (24) und erhalten wie im Diffusionsschritt eine Poisson-Gleichung zur Berechnung des Druckfeldes p Auch hier ergibt sich durch die Diskretisierung vonnablamiddotnablaein duumlnn besetztes lineares Gleichungssystem mit rechter Seite nabla middot w3 welches wir loumlsen muumlssen umals Abschluss unseres Algorithmus die aktualisierte Geschwindigkeit uumlber die Gleichung

u (x t+ ∆t) = w4 = w3 minusnablap (217)

berechnen zu koumlnnen Dazu verwenden wir folgende Diskretisierungen der auftretenden Operatoren

(nablas)ij =

(parts

partxparts

party

)ij

asymp(si+1j minus siminus1j

2hsij+1 minus sijminus1

2h

)(218)

(nabla middot v)ij =

(partvx

partx+partvy

party

)ij

asymp

(vxi+1j minus vximinus1j

2h+vyij+1 minus v

yijminus1

2h

) (219)

wobei s erneut ein Skalarfeld und v = (vx vy) ein zweidimensionales Vektorfeld mit x- und y-Komponentebezeichnet Analog zu der Schreibweise in Gleichung (212) repraumlsentieren ()ij die entsprechendenGroumlszligen ausgewertet im Punkt xij isin Ωh

Nun sind wir in der Lage im naumlchsten Zeitschritt das Geschwindigkeitsfeld zu berechnen und schlieszligensomit die Diskretisierung der Navier-Stokes Gleichungen (21) und (22) ab Dazu fassen wir die wesent-lichen Ergebnisse dieses Unterkapitels in algorithmischer Form zusammen Wir orientieren uns dabei anden in Schema (28) angefuumlhrten Schritten und erhalten so ein kompaktes numerisches Loumlsungsverfahrender Navier-Stokes Gleichungen

Algorithmus 241 (bdquoStable Fluidsldquo Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen nach[Stam])Sei ein initiales Geschwindigkeitsfeld w0

(0) (x) = u (x 0) gegebenFuumlr l = 1 L

1 Kraft aufpraumlgen w1(l) (x) = w0

(lminus1) (x) + ∆tf (l) (x)

2 Advektion w2(l) (x) = w1

(l)(xminus∆tw1

(l) (x))

3 Diffusion bestimme w3(l) uumlber (Iminus ν∆tnabla middot nabla)w3

(l) = w2(l)

4 Projektion w4(l) = w3

(l) minusnablap(l) wobei sich p(l) ergibt aus nabla middot nablap(l) = nabla middotw3(l)

5 Aktualisierung w0(l) (x) = u (x l middot∆t) = w4

(l) (x)

Die Anzahl L + 1 der durchzufuumlhrenden Zeitschritte legen wir dadurch fest wie lange wir die Simu-lation ausfuumlhren Das Kraftfeld f (l) wird durch den Anwender von auszligen bestimmt und steht in jedemZeitschritt aktualisiert zur Verfuumlgung Die genaue Umsetzung der Schritte in Algorithmus 241 stellenwir in Kapitel 3 vor

Kapitel 3

Implementierung

Nachdem wir in Kapitel 2 auf die in unserer Simulation verwendete Theorie bezuumlglich Modell Dis-kretisierung und numerischer Loumlsung eingegangen sind wollen wir uns nun ihrer Umsetzung und derRealisierung der Visualisierung und Interaktion auf einem Tablet-Computer widmen Die Stroumlmungs-simulation fuumlhren wir auf dem Asus EeePad Transformer TF101 auf dem das Betriebssystem Android403 installiert ist in einer App aus Details zur Hardware des verwendeten Tablet-Computers findensich in Kapitel 44 Der Anwender hat waumlhrend der Simulation die Moumlglichkeit die Stroumlmung einesFluids durch Beruumlhren des Bildschirms zu beeinflussen Stroumlmungssimulationen wie sie etwa bei [Stam]oder [Harris] beschrieben werden koumlnnen vom Nutzer durch Interaktion mit der Maus beeinflusst wer-den auf einem Tablet-Computer besteht jedoch die Moumlglichkeit dies mit einem Finger auf dem Bild-schirm durchzufuumlhren Dadurch wirkt die Simulation fuumlr den Betrachter realer Die Moumlglichkeit solcheComputer zur Stroumlmungssimulation einzusetzen wird dadurch eroumlffnet dass Tablet-Computer hinsicht-lich ihrer Rechenleistung immer leistungsfaumlhiger werdenBevor wir auf die konkrete Implementierung des in Kapitel 2 vorgestellten Verfahrens eingehen wollenwir zunaumlchst das Vorgehen bei einer App-Programmierung in der Programmiersprache Java fuumlr das An-droid-Betriebssystem erlaumlutern wobei wir uns an [Android Developer] orientieren Zunaumlchst installierenwir eine Software-Entwicklungsumgebung wie etwa Eclipse1 in der wir die eigentliche Programmie-rung durchfuumlhren Ergaumlnzend benoumltigen wir das Android Software Development Kit sowie die AndroidDevelopment Tools die wir in die Entwicklungsumgebung einbinden muumlssen Anschlieszligend koumlnnen wirein neues Android App Project erstellen welches die App repraumlsentiert Dabei werden einige Dateienautomatisch erstellt wie etwa die Manifest-Datei die eine zentrale Rolle einnimmt da sie die funda-mentalen Charakteristiken der App beschreibt und jede ihrer Komponenten definiert Die Programmie-rung einer App unterscheidet sich vor allem dadurch von einer bdquogewoumlhnlichenldquo Java-Programmierungals dass zum korrekten Erstellen der App viele spezielle Funktionen vom System verlangt werden diewir implementieren muumlssen Auch die Umsetzung der Visualisierung mit Hilfe der OpenGL ES 20-Bibliothek verlangt ein gesondertes Vorgehen Wir muumlssen die Visualisierung in eine eigene Klasse aus-lagern diese entsprechend kennzeichnen und erneut vom System verlangte Funktionen integrieren Aumlhn-lich verhaumllt es sich bei der Beruumlcksichtigung der Anwender-InteraktionUm eine App schlieszliglich auszufuumlhren bestehen zwei Moumlglichkeiten Einerseits koumlnnen wir die App aufeinem externen Android-Geraumlt starten zum Beispiel einem Tablet-Computer andererseits den Emula-tor nutzen Dabei handelt es sich um eine sogenannte Android Virtual Device die auf dem Computerausgefuumlhrt wird auf dem sich die Entwicklungsumgebung befindet Die Virtual Device entspricht ei-nem externen Geraumlt welches auf dem Computer simuliert wird Es empfiehlt sich die App zunaumlchstim Emulator zu testen da bei eventuellen Programmierfehlern das externe Geraumlt durch Uumlberhitzungoder aumlhnliches beschaumldigt werden kann Bisher ist es nicht moumlglich Apps auf dem Emulator zu tes-ten die sich der Bibliothek OpenGL ES 20 zur Darstellung von Grafiken bedienen wie wir sie fuumlr

1Fuumlr naumlhere Informationen verweisen wir auf httpwwweclipseorg

12

KAPITEL 2 THEORETISCHE GRUNDLAGEN 4

physikalische Bedeutung erlaumlutern wozu wir einige Begriffe definieren

AdvektionUumlblicherweise kann ein Fluid Objekte oder andere Substanzen transportieren In unserem Fall beschraumln-ken wir uns lediglich darauf dass es bdquosich selbstldquo transportiert Es wird also durch die eigene Ge-schwindigkeit fortbewegt Dieses Verhalten nennt sich Advektion und wird durch den Term minus (u middot nabla)ubeschrieben der den konvektiven Transport des Fluids darstellt Die Beruumlcksichtigung dieses Effekteszieht die Konsequenz nach sich dass die Navier-Stokes Gleichungen nichtlinear sind

DruckDie Teilchen in einem Fluid werden automatisch fortbewegt Dies fuumlhrt dazu dass sie sich gegenseitigan- und abstoszligen Wird eine Kraft auf das Fluid aufgepraumlgt so wird diese ebenfalls durch die Teilchenuumlbertragen Diese beiden Phaumlnomene fuumlhren zu einer Druckentwicklung im Fluid was letztendlich in ei-ner Beschleunigung der Teilchen resultiert Der Ausdruck minus1

ρnablap in Gleichung (21) repraumlsentiert diesenphysikalischen Sachverhalt in Abhaumlngigkeit von der Dichte ρ des Fluids und des auf das Fluid wirkendenDrucks p

DiffusionDieses physikalische Phaumlnomen haumlngt stark mit der Zaumlhfluumlssigkeit eines Fluids welche uumlber seine kine-matische Viskositaumlt ν beschrieben wird zusammen und hat einen groszligen Einfluss auf das FluidverhaltenZur Erlaumluterung geben wir zunaumlchst eine rein formale Definition der Viskositaumlt (vgl [Arlt])

Definition 211 (Viskositaumlt)Wir betrachten folgenden Versuchsaufbau

Abbildung 21 Versuchsaufbau zur Definition der Viskositaumlt

Im unteren Teil von Abbildung 21 befindet sich eine feststehende unbewegliche Wand M und im Ab-stand z zu dieser eine bewegliche Wand N mit der Oberflaumlche A Der Raum zwischen den Waumlnden istmit dem zu untersuchenden Fluid gefuumlllt Um die WandN mit der konstanten Geschwindigkeit v parallelzu M zu bewegen wird die Kraft benoumltigt die aus dem Newtonschen Gesetz

KAPITEL 2 THEORETISCHE GRUNDLAGEN 5

F = η middotA middot dv

dz

hervorgeht Somit ist die Kraft F proportional zu der Oberflaumlche A und dem Geschwindigkeits-gradienten dv

dz welcher der Beschleunigung der beweglichen Wand N entspricht Der Proportionali-taumltsfaktor η heiszligt dynamische Viskositaumlt und ist ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres Fluids Es gilthierbei je groumlszliger die Viskositaumlt desto zaumlhfluumlssiger das Fluid

Zu unterscheiden sind dabei zwei verschiedene Begriffe der Viskositaumlt Die dynamische Viskositaumlt η unddie kinematische Viskositaumlt ν welche wir in den Navier-Stokes Gleichungen (21) und (22) benoumltigenWir wollen nun beide Begriffe in Zusammenhang setzen Sei ρ die Dichte und η die dynamische Visko-sitaumlt unseres Fluids Dann ergibt sich die kinematische Viskositaumlt zu

ν =η

ρ (23)

Zaumlhe Fluumlssigkeiten also solche mit einer hohen Viskositaumlt reagieren traumlger auf Bewegungen als duumlnn-fluumlssige oder auch Fluide mit kleinerer Viskositaumlt wie etwa Olivenoumll im Vergleich zu Wasser DieserEffekt nennt sich Diffusion und geht durch den Term νnabla middotnablau in das mathematische Modell ein der dendiffusiven Transport des Fluids beruumlcksichtigt

KraumlfteWie bei der Beschreibung des Drucks bereits erwaumlhnt fuumlhrt das Aufpraumlgen von Kraumlften zur Beschleuni-gung der Fluidteilchen Moumlglich sind externe Kraumlfte also solche die bdquovon auszligenldquo auf das Fluid wirkenund Koumlrper- beziehungsweise Volumenkraumlfte die etwa durch die Erdbeschleunigung hervorgerufen wer-den An dieser Stelle sei schon einmal erwaumlhnt dass die externen Kraumlfte in der Simulation interaktivdurch den Anwender integriert werden koumlnnen (vgl Abschnitt 33)

Damit das Problem welches durch die Navier-Stokes Gleichungen formuliert wird wohlgestellt istmuumlssen wir zusaumltzlich sogenannte Anfangs- und Randbedingungen einfuumlhren auf die wir im folgendenAbschnitt eingehen

22 Anfangs- und Randbedingungen

Sowohl die Geschwindigkeit u als auch der Druck p treten in den Navier-Stokes Gleichungen als Un-bekannte auf und muumlssen in jedem Zeitschritt berechnet und aktualisiert werden Daher muumlssen wirgeeignete Anfangs- und Randbedingungen fuumlr beide Groumlszligen vorgebenDie Anfangsbedingung fuumlr das Druckfeld ist von Testfall zu Testfall unterschiedlich So nehmen wir ineinem Beispiel den initialen Druck als Null an womit p equiv 0 in Ω gilt Andererseits koumlnnen wir fuumlrden Druck sogenannte Druckspitzen vorschreiben wie wir sie in Kapitel 42 setzen Fuumlr das Geschwin-digkeitsfeld waumlhlen wir immer u equiv 0 als Anfangsbedingung und erzeugen Dynamik entweder durchexterne Kraumlfte wie etwa in Abschnitt 431 oder uumlber RandbedingungenIm Allgemeinen legen wir als Randbedingung fuumlr die Geschwindigkeit die sogenannte bdquono-slipldquo-Bedingung u|partΩ equiv 0 fest Wir setzen die Geschwindigkeit am Rand also auf Null was bedeutet dass dasFluid am Gebietsrand haften bleibt Wir koumlnnen aber auch wie beim Testfall Driven Cavity beschriebenan einer Kante des Rechengebiets einen von Null verschiedenen Wert vorschreiben Wir tragen somit ei-ne Tangentialgeschwindigkeit an und erzeugen mit ihrer Hilfe Dynamik im Fluid (vgl Abschnitt 412)Als Randbedingung fuumlr den Druck legen wir fest dass keine Aumlnderung in Normalenrichtung stattfindet

KAPITEL 2 THEORETISCHE GRUNDLAGEN 6

also partppartn |partΩ equiv 0 gilt wobei n den aumluszligeren Normalenvektor von Ω bezeichnet

Die verschiedenen Anfangs- und Randbedingungen sind miteinander und mit der Anwender-Interaktionder wir uns in Abschnitt 43 widmen kombinierbar Wir koumlnnen somit eine Vielzahl von Testfaumlllen kon-struieren von denen wir eine Auswahl in Kapitel 4 praumlsentieren

23 Projektionsverfahren und die Helmholtz-Hodge-Zerlegung

Nachdem wir zuvor alle Komponenten der Navier-Stokes Gleichungen aus physikalischer Sicht betrach-tet und Anfangs- sowie Randbedingungen eingefuumlhrt haben wollen wir sie nun in eine zum Loumlsen geeig-netere Form bringen und anschlieszligend ein Vorgehen zur Loumlsung dieser Gleichungen entwickeln Dabeiist die Art der Diskretisierung des von Raum- und Zeitvariablen abhaumlngigen Problems entscheidendZunaumlchst nehmen wir eine simple Zeitdiskretisierung vor indem wir das Zeitintervall I = [0 T ] inTeilintervalle zerlegen Anschlieszligend betrachten wir Gleichung (21) innerhalb eines Zeitschritts unddiskretisieren die auftretenden Operatoren im Ort (vgl Kapitel 24) Im Folgenden koumlnnen wir daherdie einzelnen Bestandteile dieser Gleichung als zeitunabhaumlngig ansehen da wir das Loumlsungsverfahreninnerhalb eines Zeitschritts entwickelnUm die Gleichungen in ein besser zu loumlsendes System zu uumlberfuumlhren betrachten wir als Hilfsmittelzunaumlchst die sogenannte Helmholtz-Hodge Zerlegung (vgl [Chorin])

Satz 231 Sei Ω sub R2 ein Gebiet mit glattem Rand partΩ Dann kann jedes Vektorfeld w zerlegt werdenin die Form

w = u +nablapwobei nabla middot u = 0 gilt das Vektorfeld u also divergenzfrei ist Auszligerdem ist u parallel zu partΩ das heiszligtu middot n = 0 mit dem aumluszligeren Normalenvektor n von Ω p bezeichnet ein Skalarfeld

In jedem Zeitschritt muumlssen wir Gleichung (21) loumlsen wobei wir gewaumlhrleisten muumlssen dass Glei-chung (22) gilt Wenn wir nun davon ausgehen durch das Loumlsen von Gleichung (21) ein Geschwindig-keitsfeld w erhalten zu haben so muss nicht zwangslaumlufig nabla middotw = 0 gelten Dies erreichen wir durchAnwenden von Satz 231 auf das Geschwindigkeitsfeld w Wir setzen somit am Ende des Zeitschrittsdas aktualisierte Geschwindigkeitsfeld analog zu obigem Satz als u = w minusnablapJetzt stellt sich die Frage wie das Skalarfeld p zu berechnen ist Wenden wir den Divergenz-Operatornablamiddot auf beide Seiten der Gleichung aus Satz 231 an so erhalten wir

nabla middotw = nabla middot u︸ ︷︷ ︸=0

+nabla middot nablap

hArr nabla middotw = nabla middot nablap (24)

Setzen wir also die Loumlsung von Gleichung (21) als bekannt voraus so koumlnnen wir durch Loumlsen derPoisson-Gleichung (24) den Druck p ermitteln mit dem wir das Geschwindigkeitsfeld w so modifizie-ren koumlnnen dass es Gleichung (22) erfuumlllt Als naumlchstes muumlssen wir uns damit beschaumlftigen wie wir dasvorlaumlufige Geschwindigkeitsfeld w berechnen koumlnnen

Zunaumlchst definieren wir hierzu mit Hilfe von Satz 231 einen linearen Operator P der ein Vektorfeld wauf seinen divergenzfreien Teil projiziert Fuumlr diesen Operator gilt dann

P (w) = P (u) + P (nablap) da P linear ist

P (w) = u wegen Satz 231 und (25)

P (u) = u nach Voraussetzung

KAPITEL 2 THEORETISCHE GRUNDLAGEN 7

woraus insgesamt

P (nablap) = 0 (26)

folgtAnhand von Gleichung (25) koumlnnen wir uns mit dem Schwarzschen Satz (vgl [Forster]) uumlberlegendass P

(partupartt

)= partu

partt gilt Der Satz von Schwarz besagt dass bei einer q-mal stetig partiell differen-zierbaren Funktion die ersten q Ableitungen vertauscht werden duumlrfen Bei uns gilt nach Voraussetzungu isin C2 (Ω)capC1 (I) da die Ausdruumlckenablamiddotnablau und partu

partt in Gleichung (21) eine entsprechende Glattheit desGeschwindigkeitsfeldes bezuumlglich der Variablen (x t) verlangen Dabei bezeichnet Ck (Ul) den Raumder k-mal stetig partiell differenzierbaren Funktionen uumlber U2 = Ω sub R2 beziehungsweise U1 = I sub Rmit k l isin 1 2 Somit folgt

nabla middot partupartt

=part

partt(nabla middot u) = 0

Wenden wir nun den Operator P auf Gleichung (21) an und nutzen seine Linearitaumlt undGleichung (26) aus so erhalten wir

partu

partt= P (minus (u middot nabla)u + νnabla middot nablau + f) (27)

Aus Gleichung (27) ergibt sich direkt der von uns verwendete Algorithmus zur Loumlsung der Navier-StokesGleichungen der sich in vier Schritte gliedert

u (middot t) = w0Kraft aufpraumlgenminusminusminusminusminusminusminusminusrarr w1

Advektionminusminusminusminusminusrarr w2Diffusionminusminusminusminusminusrarr w3

Projektionminusminusminusminusminusrarr w4 = u (middot t+ 1) (28)

Wir nehmen an dass uns das Geschwindigkeitsfeld u zum Zeitpunkt t bekannt ist und setzenw0 (x) = u (x t) Pro Zeitschritt loumlsen wir die Gleichung (21) durch sogenanntes bdquoOperator-Splittingldquosukzessiv numerisch Wie in allen Projektionsmethoden entsteht auch hier durch das Splitting ein nu-merischer Fehler wodurch wir Gleichung (21) nicht mehr exakt loumlsen Leider geht [Stam] in seinerOriginalarbeit nicht auf die Ordnung des Verfahrens ein aufgrund der Struktur des Verfahrens und derAumlhnlichkeit zu Chorinschen Projektionsmethoden (vgl [Anderson]) ist aber nicht von einer hohen Ord-nung auszugehen Schlieszliglich gewaumlhrleisten wir durch das Anwenden des oben definierten Projektions-operators P dass Gleichung (22) erfuumlllt ist was anschaulich aus Abbildung 22 hervorgeht

Abbildung 22 Sukzessive Berechnung der Geschwindigkeit in einem Punkt innerhalb eines Zeitschritts(vgl [Stam])

Am Ende eines jeden Zeitschritts setzen wir w0 = w4 Da wir wie oben beschrieben ausgehend vonw0 innerhalb eines Zeitschrittes operieren haumlngen die Geschwindigkeitsfelder wk k isin 0 1 2 3 4

KAPITEL 2 THEORETISCHE GRUNDLAGEN 8

waumlhrend der Berechnung nur von der Ortsvariablen x ab Das Vektorfeld w4 entspricht schlieszliglich demGeschwindigkeitsfeld u zum Zeitpunkt t+∆t also u (x t+ ∆t) mit der Zeitschrittweite ∆t isin R+ DieSimulation erhalten wir letztendlich durch Iteration der in Schema (28) beschriebenen Vorgehensweiseuumlber die Zeitschritte Daraus ergibt sich durch Diskretisierung der auftretenden Operatoren ein nume-risches Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen (21) und (22) worauf wir im naumlchstenAbschnitt eingehen

24 Diskretisierung und numerische Loumlsung

Wir erlaumlutern in diesem Abschnitt die in Schema (28) angefuumlhrten Schritte und stellen Diskretisierungs-beziehungsweise Loumlsungstechniken vor um abschlieszligend ein kompaktes Loumlsungsverfahren der Navier-Stokes Gleichungen aufzustellen Zur Diskretisierung aller auftretenden Operatoren verwenden wir indieser Arbeit meist finite Differenzen zweiter Ordnung Approximationen abweichender Ordnung sindbeispielsweise bei der Behandlung von Randbedingungen noumltig auf die wir in Abschnitt 314 naumlhereingehenWie in Abschnitt 23 bereits erwaumlhnt diskretisieren wir das durch die Navier-Stokes Gleichungen (21)und (22) und Anfangs- sowie Randbedingungen gestellte Problem zuerst in der Zeit und anschlieszligendim Ort Dazu waumlhlen wir eine aumlquidistante Zerlegung des Zeitintervalls in L Teilintervalle der Form

I = [0 T ] =

L⋃l=1

[t(lminus1) t(l)

]

wobei t(l) = l middot∆t und T = L middot∆t gilt Die folgenden Diskretisierungen im Ort fuumlhren wir nun jeweilszu einem festen Zeitpunkt t(l) durch weshalb die auftretenden Groumlszligen zeitunabhaumlngig sindFuumlr unsere Simulation betrachten wir das quadratische Rechengebiet Ω = [minus1 1]2 sub R2 in dem sichdas Fluid befinden soll Davon ausgehend definieren wir ein diskretes Gebiet Ωh mit Schrittweite h isin Rdie wir sowohl in x- als auch in y-Richtung zur Diskretisierung verwenden Dadurch ergibt sich Ωh alsein Gitter fuumlr das xij isin Ωh die Form xij = (minus1 + ihminus1 + jh) hat wobei i j isin 0 n minus 1gilt und n isin N die Anzahl der Gitterpunkte pro Zeile beziehungsweise Spalte im Gitter angibt ImFolgenden betrachten wir nur die Operationen innerhalb eines Zeitschrittes das heiszligt im Uumlbergang vont(l) nach t(l) + ∆t Dazu sei w0 wie oben als bekanntes Geschwindigkeitsfeld u

(x t(l)

)definiert und

wk k isin 1 2 3 4 bezeichnet die unterschiedlichen Geschwindigkeitsfelder innerhalb des ZeitschrittsNach diesen Vorbereitungen widmen wir uns nun Diskretisierungs- und Loumlsungsmethoden fuumlr die ein-zelnen Bestandteile von Gleichung (27) beziehungsweise Schema (28)

Kraft aufpraumlgenZuerst kann dem Fluid eine Kraft aufgepraumlgt werden Dies geschieht waumlhrend der Simulation durch denAnwender und soll nur ein Mal pro Zeitschritt erfolgen Deshalb koumlnnen wir die Annahme treffen dassdie Kraft uumlber den gesamten Zeitschritt konstant ist Somit ist eine Beruumlcksichtigung der Kraft zu Beginneines jeden Zeitschritts ausreichend Wir berechnen also im ersten Schritt unseres Loumlsers

w1 = w0 + ∆tf (29)

was eine gute Approximation der Wirkung der Kraft uumlber den Zeitschritt darstellt da wir ihren Einflussdurch die Multiplikation des Kraftfeldes f mit der Zeitschrittweite ∆t uumlber den ganzen Zeitschritt trans-portieren

KAPITEL 2 THEORETISCHE GRUNDLAGEN 9

AdvektionUm die Advektion des Fluids zu beruumlcksichtigen fassen wir die Gitterpunkte als die oben beschriebenenTeilchen beziehungsweise Fluidpartikel auf und muumlssen dann in jedem Zeitschritt die Geschwindigkeiteines solchen Partikels aktualisierenEine erste Idee waumlre es hierzu folgende explizite Methode zu betrachten Die Position r eines Partikelsveraumlndert sich mit der Geschwindigkeit also koumlnnen wir die Position so weit verschieben wie sich dasPartikel in der Zeit ∆t mit seiner Geschwindigkeit fortbewegt Also gilt

r(t(l) + ∆t

)= r

(t(l))

+ ∆tu(t(l))

was dem expliziten Eulerverfahren entspricht Allerdings ist diese Methode instabil fuumlr groszlige Zeitschritt-weitenWir betrachten deshalb die implizite Methode der Charakteristiken die die Stabilitaumlt des Verfahrens im-pliziert Zur genaueren Erlaumluterung dieses Verfahrens verweisen wir auf [Stam] und geben hier nur einegrobe Zusammenfassung Im Wesentlichen verfolgen wir jeden Punkt x isin Ω uumlber die Zeit ∆t entlangw1 zuruumlck Dadurch entsteht ein Pfad p (x t) von x zu einem Punkt x0 = p (xminus∆t) der auch alsStromlinie interpretiert werden kann Dies wird in Abbildung 23 verdeutlicht

Abbildung 23 Weg den ein Fluidpartikel in der Zeit zuruumlcklegt (vgl [Stam])

Wir setzen dann die neue Geschwindigkeit w2 im Punkt x als die Geschwindigkeit die im Punkt x0 zurvorherigen Zeit vorliegt also

w2 (x) = w1 (p (xminus∆t)) = w1 (xminus∆tw1 (x)) (210)

Durch das Verwenden der Methode der Charakteristiken liefert unser Vorgehen eine fuumlr beliebig groszligeZeitschrittweiten und Geschwindigkeiten unbedingt stabile numerische Loumlsung (vgl [Stam]) Das koumln-nen wir daran feststellen dass der maximale Wert des Geschwindigkeitsfeldes in diesem Schritt niegroumlszliger als im vorherigen Zeitschritt werden kann auszliger wir praumlgen eine externe Kraft auf Denn nachGleichung (210) gilt

max(w2

(l))le max

(w1

(l))

(29)= max

(w0

(l) + ∆tf (l))

f (l)equiv0= max

(w4

(lminus1))

wobei ()(l) die entsprechende Groumlszlige im l-ten Zeitschritt bezeichnet Es ist f (l) equiv 0 da wir hier keineAnwender-Interaktion beruumlcksichtigenFuumlr Details zur Implementierung der Methode der Charakteristiken verweisen wir auf Kapitel 31

KAPITEL 2 THEORETISCHE GRUNDLAGEN 10

DiffusionHier betrachten wir eine Gleichung der Form

partu

partt= νnabla middot nablau (211)

Um diese numerisch zu loumlsen diskretisieren wir zunaumlchst den Laplace-Operatornabla middotnabla mit finiten Diffe-renzen im Ort und wenden dann ein Zeitschrittverfahren an Die Anwendung vonnablamiddotnabla auf das Geschwin-digkeitsfeld u erfolgt komponentenweise in x- beziehungsweise y-Richtung weshalb wir vereinfachenddie Diskretisierung des Operators angewendet auf ein hinreichend glattes Skalarfeld s betrachten Wirstellen also die Diskretisierung vonnabla middot nablas = part2s

partx2+ part2s

party2im R2 auf Dann gilt

(nabla middot nablas)ij asympsi+1j minus 2sij + siminus1j

h2+sij+1 minus 2sij + sijminus1

h2(212)

mit sij = s (xij) und analog (nabla middot nablas)ij = nabla middot nablas (xij) fuumlr xij isin Ωh Betrachten wir das durchGleichung (212) diskretisierte Skalarfeld s in jedem Gitterpunkt koumlnnen wir den diskretisierten Laplace-Operator als Matrix auffassen welche die folgende Gestalt aufweist

1

h2

Bn In

In In

In Bn

mit Bn =

minus4 1

1 1

1 minus4

isin Rntimesn (213)

Hierbei bezeichnet In die Einheitsmatrix der Dimension ntimesn Wenden wir auf die im Ort diskretisierteGleichung (211) ein explizites Zeitschrittverfahren der Form

u (x t+ ∆t) = u (x t) + ν∆tnabla middot nablau (x t) (214)

an so tritt erneut das Problem der Instabilitaumlt fuumlr groszlige Zeitschrittweiten ∆t beziehungsweise groszligekinematische Viskositaumlten ν auf Diese Schwierigkeit taucht auf da die Methode einem expliziten Euler-Verfahren entspricht und daher aumlhnliche Eigenschaften bezuumlglich der Stabilitaumlt aufweist Um eine stabileLoumlsungsmethode zu konstruieren verwenden wir statt des in Gleichung (214) angefuumlhrten ein implizitesVerfahren was sich durch Uumlbertragen auf unsere Schreibweise innerhalb eines Zeitschrittes schreibenlaumlsst als

(Iminus ν∆tnabla middot nabla)w3 = w2 (215)

wobei I den Identitaumltsoperator darstellt Diese Gleichung entspricht einer Poisson-Gleichung fuumlr dasGeschwindigkeitsfeld w3 Setzen wir den diskretisierten Laplace-Operator aus Gleichung (213) in Glei-chung (215) ein so ergibt sich die Darstellung fuumlr die Systemmatrix des zu loumlsenden Gleichungssystemsals

ν∆t

h2

Bn minusInminusIn

minusInminusIn Bn

mit Bn =

4 + h2

ν∆t minus1

minus1 minus1

minus1 4 + h2

ν∆t

(216)

Das daraus resultierende Gleichungssystem muumlssen wir nun effizient loumlsen worauf wir in Kapitel 31eingehen

KAPITEL 2 THEORETISCHE GRUNDLAGEN 11

ProjektionIm Projektionsschritt betrachten wir Gleichung (24) und erhalten wie im Diffusionsschritt eine Poisson-Gleichung zur Berechnung des Druckfeldes p Auch hier ergibt sich durch die Diskretisierung vonnablamiddotnablaein duumlnn besetztes lineares Gleichungssystem mit rechter Seite nabla middot w3 welches wir loumlsen muumlssen umals Abschluss unseres Algorithmus die aktualisierte Geschwindigkeit uumlber die Gleichung

u (x t+ ∆t) = w4 = w3 minusnablap (217)

berechnen zu koumlnnen Dazu verwenden wir folgende Diskretisierungen der auftretenden Operatoren

(nablas)ij =

(parts

partxparts

party

)ij

asymp(si+1j minus siminus1j

2hsij+1 minus sijminus1

2h

)(218)

(nabla middot v)ij =

(partvx

partx+partvy

party

)ij

asymp

(vxi+1j minus vximinus1j

2h+vyij+1 minus v

yijminus1

2h

) (219)

wobei s erneut ein Skalarfeld und v = (vx vy) ein zweidimensionales Vektorfeld mit x- und y-Komponentebezeichnet Analog zu der Schreibweise in Gleichung (212) repraumlsentieren ()ij die entsprechendenGroumlszligen ausgewertet im Punkt xij isin Ωh

Nun sind wir in der Lage im naumlchsten Zeitschritt das Geschwindigkeitsfeld zu berechnen und schlieszligensomit die Diskretisierung der Navier-Stokes Gleichungen (21) und (22) ab Dazu fassen wir die wesent-lichen Ergebnisse dieses Unterkapitels in algorithmischer Form zusammen Wir orientieren uns dabei anden in Schema (28) angefuumlhrten Schritten und erhalten so ein kompaktes numerisches Loumlsungsverfahrender Navier-Stokes Gleichungen

Algorithmus 241 (bdquoStable Fluidsldquo Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen nach[Stam])Sei ein initiales Geschwindigkeitsfeld w0

(0) (x) = u (x 0) gegebenFuumlr l = 1 L

1 Kraft aufpraumlgen w1(l) (x) = w0

(lminus1) (x) + ∆tf (l) (x)

2 Advektion w2(l) (x) = w1

(l)(xminus∆tw1

(l) (x))

3 Diffusion bestimme w3(l) uumlber (Iminus ν∆tnabla middot nabla)w3

(l) = w2(l)

4 Projektion w4(l) = w3

(l) minusnablap(l) wobei sich p(l) ergibt aus nabla middot nablap(l) = nabla middotw3(l)

5 Aktualisierung w0(l) (x) = u (x l middot∆t) = w4

(l) (x)

Die Anzahl L + 1 der durchzufuumlhrenden Zeitschritte legen wir dadurch fest wie lange wir die Simu-lation ausfuumlhren Das Kraftfeld f (l) wird durch den Anwender von auszligen bestimmt und steht in jedemZeitschritt aktualisiert zur Verfuumlgung Die genaue Umsetzung der Schritte in Algorithmus 241 stellenwir in Kapitel 3 vor

Kapitel 3

Implementierung

Nachdem wir in Kapitel 2 auf die in unserer Simulation verwendete Theorie bezuumlglich Modell Dis-kretisierung und numerischer Loumlsung eingegangen sind wollen wir uns nun ihrer Umsetzung und derRealisierung der Visualisierung und Interaktion auf einem Tablet-Computer widmen Die Stroumlmungs-simulation fuumlhren wir auf dem Asus EeePad Transformer TF101 auf dem das Betriebssystem Android403 installiert ist in einer App aus Details zur Hardware des verwendeten Tablet-Computers findensich in Kapitel 44 Der Anwender hat waumlhrend der Simulation die Moumlglichkeit die Stroumlmung einesFluids durch Beruumlhren des Bildschirms zu beeinflussen Stroumlmungssimulationen wie sie etwa bei [Stam]oder [Harris] beschrieben werden koumlnnen vom Nutzer durch Interaktion mit der Maus beeinflusst wer-den auf einem Tablet-Computer besteht jedoch die Moumlglichkeit dies mit einem Finger auf dem Bild-schirm durchzufuumlhren Dadurch wirkt die Simulation fuumlr den Betrachter realer Die Moumlglichkeit solcheComputer zur Stroumlmungssimulation einzusetzen wird dadurch eroumlffnet dass Tablet-Computer hinsicht-lich ihrer Rechenleistung immer leistungsfaumlhiger werdenBevor wir auf die konkrete Implementierung des in Kapitel 2 vorgestellten Verfahrens eingehen wollenwir zunaumlchst das Vorgehen bei einer App-Programmierung in der Programmiersprache Java fuumlr das An-droid-Betriebssystem erlaumlutern wobei wir uns an [Android Developer] orientieren Zunaumlchst installierenwir eine Software-Entwicklungsumgebung wie etwa Eclipse1 in der wir die eigentliche Programmie-rung durchfuumlhren Ergaumlnzend benoumltigen wir das Android Software Development Kit sowie die AndroidDevelopment Tools die wir in die Entwicklungsumgebung einbinden muumlssen Anschlieszligend koumlnnen wirein neues Android App Project erstellen welches die App repraumlsentiert Dabei werden einige Dateienautomatisch erstellt wie etwa die Manifest-Datei die eine zentrale Rolle einnimmt da sie die funda-mentalen Charakteristiken der App beschreibt und jede ihrer Komponenten definiert Die Programmie-rung einer App unterscheidet sich vor allem dadurch von einer bdquogewoumlhnlichenldquo Java-Programmierungals dass zum korrekten Erstellen der App viele spezielle Funktionen vom System verlangt werden diewir implementieren muumlssen Auch die Umsetzung der Visualisierung mit Hilfe der OpenGL ES 20-Bibliothek verlangt ein gesondertes Vorgehen Wir muumlssen die Visualisierung in eine eigene Klasse aus-lagern diese entsprechend kennzeichnen und erneut vom System verlangte Funktionen integrieren Aumlhn-lich verhaumllt es sich bei der Beruumlcksichtigung der Anwender-InteraktionUm eine App schlieszliglich auszufuumlhren bestehen zwei Moumlglichkeiten Einerseits koumlnnen wir die App aufeinem externen Android-Geraumlt starten zum Beispiel einem Tablet-Computer andererseits den Emula-tor nutzen Dabei handelt es sich um eine sogenannte Android Virtual Device die auf dem Computerausgefuumlhrt wird auf dem sich die Entwicklungsumgebung befindet Die Virtual Device entspricht ei-nem externen Geraumlt welches auf dem Computer simuliert wird Es empfiehlt sich die App zunaumlchstim Emulator zu testen da bei eventuellen Programmierfehlern das externe Geraumlt durch Uumlberhitzungoder aumlhnliches beschaumldigt werden kann Bisher ist es nicht moumlglich Apps auf dem Emulator zu tes-ten die sich der Bibliothek OpenGL ES 20 zur Darstellung von Grafiken bedienen wie wir sie fuumlr

1Fuumlr naumlhere Informationen verweisen wir auf httpwwweclipseorg

12

KAPITEL 2 THEORETISCHE GRUNDLAGEN 5

F = η middotA middot dv

dz

hervorgeht Somit ist die Kraft F proportional zu der Oberflaumlche A und dem Geschwindigkeits-gradienten dv

dz welcher der Beschleunigung der beweglichen Wand N entspricht Der Proportionali-taumltsfaktor η heiszligt dynamische Viskositaumlt und ist ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres Fluids Es gilthierbei je groumlszliger die Viskositaumlt desto zaumlhfluumlssiger das Fluid

Zu unterscheiden sind dabei zwei verschiedene Begriffe der Viskositaumlt Die dynamische Viskositaumlt η unddie kinematische Viskositaumlt ν welche wir in den Navier-Stokes Gleichungen (21) und (22) benoumltigenWir wollen nun beide Begriffe in Zusammenhang setzen Sei ρ die Dichte und η die dynamische Visko-sitaumlt unseres Fluids Dann ergibt sich die kinematische Viskositaumlt zu

ν =η

ρ (23)

Zaumlhe Fluumlssigkeiten also solche mit einer hohen Viskositaumlt reagieren traumlger auf Bewegungen als duumlnn-fluumlssige oder auch Fluide mit kleinerer Viskositaumlt wie etwa Olivenoumll im Vergleich zu Wasser DieserEffekt nennt sich Diffusion und geht durch den Term νnabla middotnablau in das mathematische Modell ein der dendiffusiven Transport des Fluids beruumlcksichtigt

KraumlfteWie bei der Beschreibung des Drucks bereits erwaumlhnt fuumlhrt das Aufpraumlgen von Kraumlften zur Beschleuni-gung der Fluidteilchen Moumlglich sind externe Kraumlfte also solche die bdquovon auszligenldquo auf das Fluid wirkenund Koumlrper- beziehungsweise Volumenkraumlfte die etwa durch die Erdbeschleunigung hervorgerufen wer-den An dieser Stelle sei schon einmal erwaumlhnt dass die externen Kraumlfte in der Simulation interaktivdurch den Anwender integriert werden koumlnnen (vgl Abschnitt 33)

Damit das Problem welches durch die Navier-Stokes Gleichungen formuliert wird wohlgestellt istmuumlssen wir zusaumltzlich sogenannte Anfangs- und Randbedingungen einfuumlhren auf die wir im folgendenAbschnitt eingehen

22 Anfangs- und Randbedingungen

Sowohl die Geschwindigkeit u als auch der Druck p treten in den Navier-Stokes Gleichungen als Un-bekannte auf und muumlssen in jedem Zeitschritt berechnet und aktualisiert werden Daher muumlssen wirgeeignete Anfangs- und Randbedingungen fuumlr beide Groumlszligen vorgebenDie Anfangsbedingung fuumlr das Druckfeld ist von Testfall zu Testfall unterschiedlich So nehmen wir ineinem Beispiel den initialen Druck als Null an womit p equiv 0 in Ω gilt Andererseits koumlnnen wir fuumlrden Druck sogenannte Druckspitzen vorschreiben wie wir sie in Kapitel 42 setzen Fuumlr das Geschwin-digkeitsfeld waumlhlen wir immer u equiv 0 als Anfangsbedingung und erzeugen Dynamik entweder durchexterne Kraumlfte wie etwa in Abschnitt 431 oder uumlber RandbedingungenIm Allgemeinen legen wir als Randbedingung fuumlr die Geschwindigkeit die sogenannte bdquono-slipldquo-Bedingung u|partΩ equiv 0 fest Wir setzen die Geschwindigkeit am Rand also auf Null was bedeutet dass dasFluid am Gebietsrand haften bleibt Wir koumlnnen aber auch wie beim Testfall Driven Cavity beschriebenan einer Kante des Rechengebiets einen von Null verschiedenen Wert vorschreiben Wir tragen somit ei-ne Tangentialgeschwindigkeit an und erzeugen mit ihrer Hilfe Dynamik im Fluid (vgl Abschnitt 412)Als Randbedingung fuumlr den Druck legen wir fest dass keine Aumlnderung in Normalenrichtung stattfindet

KAPITEL 2 THEORETISCHE GRUNDLAGEN 6

also partppartn |partΩ equiv 0 gilt wobei n den aumluszligeren Normalenvektor von Ω bezeichnet

Die verschiedenen Anfangs- und Randbedingungen sind miteinander und mit der Anwender-Interaktionder wir uns in Abschnitt 43 widmen kombinierbar Wir koumlnnen somit eine Vielzahl von Testfaumlllen kon-struieren von denen wir eine Auswahl in Kapitel 4 praumlsentieren

23 Projektionsverfahren und die Helmholtz-Hodge-Zerlegung

Nachdem wir zuvor alle Komponenten der Navier-Stokes Gleichungen aus physikalischer Sicht betrach-tet und Anfangs- sowie Randbedingungen eingefuumlhrt haben wollen wir sie nun in eine zum Loumlsen geeig-netere Form bringen und anschlieszligend ein Vorgehen zur Loumlsung dieser Gleichungen entwickeln Dabeiist die Art der Diskretisierung des von Raum- und Zeitvariablen abhaumlngigen Problems entscheidendZunaumlchst nehmen wir eine simple Zeitdiskretisierung vor indem wir das Zeitintervall I = [0 T ] inTeilintervalle zerlegen Anschlieszligend betrachten wir Gleichung (21) innerhalb eines Zeitschritts unddiskretisieren die auftretenden Operatoren im Ort (vgl Kapitel 24) Im Folgenden koumlnnen wir daherdie einzelnen Bestandteile dieser Gleichung als zeitunabhaumlngig ansehen da wir das Loumlsungsverfahreninnerhalb eines Zeitschritts entwickelnUm die Gleichungen in ein besser zu loumlsendes System zu uumlberfuumlhren betrachten wir als Hilfsmittelzunaumlchst die sogenannte Helmholtz-Hodge Zerlegung (vgl [Chorin])

Satz 231 Sei Ω sub R2 ein Gebiet mit glattem Rand partΩ Dann kann jedes Vektorfeld w zerlegt werdenin die Form

w = u +nablapwobei nabla middot u = 0 gilt das Vektorfeld u also divergenzfrei ist Auszligerdem ist u parallel zu partΩ das heiszligtu middot n = 0 mit dem aumluszligeren Normalenvektor n von Ω p bezeichnet ein Skalarfeld

In jedem Zeitschritt muumlssen wir Gleichung (21) loumlsen wobei wir gewaumlhrleisten muumlssen dass Glei-chung (22) gilt Wenn wir nun davon ausgehen durch das Loumlsen von Gleichung (21) ein Geschwindig-keitsfeld w erhalten zu haben so muss nicht zwangslaumlufig nabla middotw = 0 gelten Dies erreichen wir durchAnwenden von Satz 231 auf das Geschwindigkeitsfeld w Wir setzen somit am Ende des Zeitschrittsdas aktualisierte Geschwindigkeitsfeld analog zu obigem Satz als u = w minusnablapJetzt stellt sich die Frage wie das Skalarfeld p zu berechnen ist Wenden wir den Divergenz-Operatornablamiddot auf beide Seiten der Gleichung aus Satz 231 an so erhalten wir

nabla middotw = nabla middot u︸ ︷︷ ︸=0

+nabla middot nablap

hArr nabla middotw = nabla middot nablap (24)

Setzen wir also die Loumlsung von Gleichung (21) als bekannt voraus so koumlnnen wir durch Loumlsen derPoisson-Gleichung (24) den Druck p ermitteln mit dem wir das Geschwindigkeitsfeld w so modifizie-ren koumlnnen dass es Gleichung (22) erfuumlllt Als naumlchstes muumlssen wir uns damit beschaumlftigen wie wir dasvorlaumlufige Geschwindigkeitsfeld w berechnen koumlnnen

Zunaumlchst definieren wir hierzu mit Hilfe von Satz 231 einen linearen Operator P der ein Vektorfeld wauf seinen divergenzfreien Teil projiziert Fuumlr diesen Operator gilt dann

P (w) = P (u) + P (nablap) da P linear ist

P (w) = u wegen Satz 231 und (25)

P (u) = u nach Voraussetzung

KAPITEL 2 THEORETISCHE GRUNDLAGEN 7

woraus insgesamt

P (nablap) = 0 (26)

folgtAnhand von Gleichung (25) koumlnnen wir uns mit dem Schwarzschen Satz (vgl [Forster]) uumlberlegendass P

(partupartt

)= partu

partt gilt Der Satz von Schwarz besagt dass bei einer q-mal stetig partiell differen-zierbaren Funktion die ersten q Ableitungen vertauscht werden duumlrfen Bei uns gilt nach Voraussetzungu isin C2 (Ω)capC1 (I) da die Ausdruumlckenablamiddotnablau und partu

partt in Gleichung (21) eine entsprechende Glattheit desGeschwindigkeitsfeldes bezuumlglich der Variablen (x t) verlangen Dabei bezeichnet Ck (Ul) den Raumder k-mal stetig partiell differenzierbaren Funktionen uumlber U2 = Ω sub R2 beziehungsweise U1 = I sub Rmit k l isin 1 2 Somit folgt

nabla middot partupartt

=part

partt(nabla middot u) = 0

Wenden wir nun den Operator P auf Gleichung (21) an und nutzen seine Linearitaumlt undGleichung (26) aus so erhalten wir

partu

partt= P (minus (u middot nabla)u + νnabla middot nablau + f) (27)

Aus Gleichung (27) ergibt sich direkt der von uns verwendete Algorithmus zur Loumlsung der Navier-StokesGleichungen der sich in vier Schritte gliedert

u (middot t) = w0Kraft aufpraumlgenminusminusminusminusminusminusminusminusrarr w1

Advektionminusminusminusminusminusrarr w2Diffusionminusminusminusminusminusrarr w3

Projektionminusminusminusminusminusrarr w4 = u (middot t+ 1) (28)

Wir nehmen an dass uns das Geschwindigkeitsfeld u zum Zeitpunkt t bekannt ist und setzenw0 (x) = u (x t) Pro Zeitschritt loumlsen wir die Gleichung (21) durch sogenanntes bdquoOperator-Splittingldquosukzessiv numerisch Wie in allen Projektionsmethoden entsteht auch hier durch das Splitting ein nu-merischer Fehler wodurch wir Gleichung (21) nicht mehr exakt loumlsen Leider geht [Stam] in seinerOriginalarbeit nicht auf die Ordnung des Verfahrens ein aufgrund der Struktur des Verfahrens und derAumlhnlichkeit zu Chorinschen Projektionsmethoden (vgl [Anderson]) ist aber nicht von einer hohen Ord-nung auszugehen Schlieszliglich gewaumlhrleisten wir durch das Anwenden des oben definierten Projektions-operators P dass Gleichung (22) erfuumlllt ist was anschaulich aus Abbildung 22 hervorgeht

Abbildung 22 Sukzessive Berechnung der Geschwindigkeit in einem Punkt innerhalb eines Zeitschritts(vgl [Stam])

Am Ende eines jeden Zeitschritts setzen wir w0 = w4 Da wir wie oben beschrieben ausgehend vonw0 innerhalb eines Zeitschrittes operieren haumlngen die Geschwindigkeitsfelder wk k isin 0 1 2 3 4

KAPITEL 2 THEORETISCHE GRUNDLAGEN 8

waumlhrend der Berechnung nur von der Ortsvariablen x ab Das Vektorfeld w4 entspricht schlieszliglich demGeschwindigkeitsfeld u zum Zeitpunkt t+∆t also u (x t+ ∆t) mit der Zeitschrittweite ∆t isin R+ DieSimulation erhalten wir letztendlich durch Iteration der in Schema (28) beschriebenen Vorgehensweiseuumlber die Zeitschritte Daraus ergibt sich durch Diskretisierung der auftretenden Operatoren ein nume-risches Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen (21) und (22) worauf wir im naumlchstenAbschnitt eingehen

24 Diskretisierung und numerische Loumlsung

Wir erlaumlutern in diesem Abschnitt die in Schema (28) angefuumlhrten Schritte und stellen Diskretisierungs-beziehungsweise Loumlsungstechniken vor um abschlieszligend ein kompaktes Loumlsungsverfahren der Navier-Stokes Gleichungen aufzustellen Zur Diskretisierung aller auftretenden Operatoren verwenden wir indieser Arbeit meist finite Differenzen zweiter Ordnung Approximationen abweichender Ordnung sindbeispielsweise bei der Behandlung von Randbedingungen noumltig auf die wir in Abschnitt 314 naumlhereingehenWie in Abschnitt 23 bereits erwaumlhnt diskretisieren wir das durch die Navier-Stokes Gleichungen (21)und (22) und Anfangs- sowie Randbedingungen gestellte Problem zuerst in der Zeit und anschlieszligendim Ort Dazu waumlhlen wir eine aumlquidistante Zerlegung des Zeitintervalls in L Teilintervalle der Form

I = [0 T ] =

L⋃l=1

[t(lminus1) t(l)

]

wobei t(l) = l middot∆t und T = L middot∆t gilt Die folgenden Diskretisierungen im Ort fuumlhren wir nun jeweilszu einem festen Zeitpunkt t(l) durch weshalb die auftretenden Groumlszligen zeitunabhaumlngig sindFuumlr unsere Simulation betrachten wir das quadratische Rechengebiet Ω = [minus1 1]2 sub R2 in dem sichdas Fluid befinden soll Davon ausgehend definieren wir ein diskretes Gebiet Ωh mit Schrittweite h isin Rdie wir sowohl in x- als auch in y-Richtung zur Diskretisierung verwenden Dadurch ergibt sich Ωh alsein Gitter fuumlr das xij isin Ωh die Form xij = (minus1 + ihminus1 + jh) hat wobei i j isin 0 n minus 1gilt und n isin N die Anzahl der Gitterpunkte pro Zeile beziehungsweise Spalte im Gitter angibt ImFolgenden betrachten wir nur die Operationen innerhalb eines Zeitschrittes das heiszligt im Uumlbergang vont(l) nach t(l) + ∆t Dazu sei w0 wie oben als bekanntes Geschwindigkeitsfeld u

(x t(l)

)definiert und

wk k isin 1 2 3 4 bezeichnet die unterschiedlichen Geschwindigkeitsfelder innerhalb des ZeitschrittsNach diesen Vorbereitungen widmen wir uns nun Diskretisierungs- und Loumlsungsmethoden fuumlr die ein-zelnen Bestandteile von Gleichung (27) beziehungsweise Schema (28)

Kraft aufpraumlgenZuerst kann dem Fluid eine Kraft aufgepraumlgt werden Dies geschieht waumlhrend der Simulation durch denAnwender und soll nur ein Mal pro Zeitschritt erfolgen Deshalb koumlnnen wir die Annahme treffen dassdie Kraft uumlber den gesamten Zeitschritt konstant ist Somit ist eine Beruumlcksichtigung der Kraft zu Beginneines jeden Zeitschritts ausreichend Wir berechnen also im ersten Schritt unseres Loumlsers

w1 = w0 + ∆tf (29)

was eine gute Approximation der Wirkung der Kraft uumlber den Zeitschritt darstellt da wir ihren Einflussdurch die Multiplikation des Kraftfeldes f mit der Zeitschrittweite ∆t uumlber den ganzen Zeitschritt trans-portieren

KAPITEL 2 THEORETISCHE GRUNDLAGEN 9

AdvektionUm die Advektion des Fluids zu beruumlcksichtigen fassen wir die Gitterpunkte als die oben beschriebenenTeilchen beziehungsweise Fluidpartikel auf und muumlssen dann in jedem Zeitschritt die Geschwindigkeiteines solchen Partikels aktualisierenEine erste Idee waumlre es hierzu folgende explizite Methode zu betrachten Die Position r eines Partikelsveraumlndert sich mit der Geschwindigkeit also koumlnnen wir die Position so weit verschieben wie sich dasPartikel in der Zeit ∆t mit seiner Geschwindigkeit fortbewegt Also gilt

r(t(l) + ∆t

)= r

(t(l))

+ ∆tu(t(l))

was dem expliziten Eulerverfahren entspricht Allerdings ist diese Methode instabil fuumlr groszlige Zeitschritt-weitenWir betrachten deshalb die implizite Methode der Charakteristiken die die Stabilitaumlt des Verfahrens im-pliziert Zur genaueren Erlaumluterung dieses Verfahrens verweisen wir auf [Stam] und geben hier nur einegrobe Zusammenfassung Im Wesentlichen verfolgen wir jeden Punkt x isin Ω uumlber die Zeit ∆t entlangw1 zuruumlck Dadurch entsteht ein Pfad p (x t) von x zu einem Punkt x0 = p (xminus∆t) der auch alsStromlinie interpretiert werden kann Dies wird in Abbildung 23 verdeutlicht

Abbildung 23 Weg den ein Fluidpartikel in der Zeit zuruumlcklegt (vgl [Stam])

Wir setzen dann die neue Geschwindigkeit w2 im Punkt x als die Geschwindigkeit die im Punkt x0 zurvorherigen Zeit vorliegt also

w2 (x) = w1 (p (xminus∆t)) = w1 (xminus∆tw1 (x)) (210)

Durch das Verwenden der Methode der Charakteristiken liefert unser Vorgehen eine fuumlr beliebig groszligeZeitschrittweiten und Geschwindigkeiten unbedingt stabile numerische Loumlsung (vgl [Stam]) Das koumln-nen wir daran feststellen dass der maximale Wert des Geschwindigkeitsfeldes in diesem Schritt niegroumlszliger als im vorherigen Zeitschritt werden kann auszliger wir praumlgen eine externe Kraft auf Denn nachGleichung (210) gilt

max(w2

(l))le max

(w1

(l))

(29)= max

(w0

(l) + ∆tf (l))

f (l)equiv0= max

(w4

(lminus1))

wobei ()(l) die entsprechende Groumlszlige im l-ten Zeitschritt bezeichnet Es ist f (l) equiv 0 da wir hier keineAnwender-Interaktion beruumlcksichtigenFuumlr Details zur Implementierung der Methode der Charakteristiken verweisen wir auf Kapitel 31

KAPITEL 2 THEORETISCHE GRUNDLAGEN 10

DiffusionHier betrachten wir eine Gleichung der Form

partu

partt= νnabla middot nablau (211)

Um diese numerisch zu loumlsen diskretisieren wir zunaumlchst den Laplace-Operatornabla middotnabla mit finiten Diffe-renzen im Ort und wenden dann ein Zeitschrittverfahren an Die Anwendung vonnablamiddotnabla auf das Geschwin-digkeitsfeld u erfolgt komponentenweise in x- beziehungsweise y-Richtung weshalb wir vereinfachenddie Diskretisierung des Operators angewendet auf ein hinreichend glattes Skalarfeld s betrachten Wirstellen also die Diskretisierung vonnabla middot nablas = part2s

partx2+ part2s

party2im R2 auf Dann gilt

(nabla middot nablas)ij asympsi+1j minus 2sij + siminus1j

h2+sij+1 minus 2sij + sijminus1

h2(212)

mit sij = s (xij) und analog (nabla middot nablas)ij = nabla middot nablas (xij) fuumlr xij isin Ωh Betrachten wir das durchGleichung (212) diskretisierte Skalarfeld s in jedem Gitterpunkt koumlnnen wir den diskretisierten Laplace-Operator als Matrix auffassen welche die folgende Gestalt aufweist

1

h2

Bn In

In In

In Bn

mit Bn =

minus4 1

1 1

1 minus4

isin Rntimesn (213)

Hierbei bezeichnet In die Einheitsmatrix der Dimension ntimesn Wenden wir auf die im Ort diskretisierteGleichung (211) ein explizites Zeitschrittverfahren der Form

u (x t+ ∆t) = u (x t) + ν∆tnabla middot nablau (x t) (214)

an so tritt erneut das Problem der Instabilitaumlt fuumlr groszlige Zeitschrittweiten ∆t beziehungsweise groszligekinematische Viskositaumlten ν auf Diese Schwierigkeit taucht auf da die Methode einem expliziten Euler-Verfahren entspricht und daher aumlhnliche Eigenschaften bezuumlglich der Stabilitaumlt aufweist Um eine stabileLoumlsungsmethode zu konstruieren verwenden wir statt des in Gleichung (214) angefuumlhrten ein implizitesVerfahren was sich durch Uumlbertragen auf unsere Schreibweise innerhalb eines Zeitschrittes schreibenlaumlsst als

(Iminus ν∆tnabla middot nabla)w3 = w2 (215)

wobei I den Identitaumltsoperator darstellt Diese Gleichung entspricht einer Poisson-Gleichung fuumlr dasGeschwindigkeitsfeld w3 Setzen wir den diskretisierten Laplace-Operator aus Gleichung (213) in Glei-chung (215) ein so ergibt sich die Darstellung fuumlr die Systemmatrix des zu loumlsenden Gleichungssystemsals

ν∆t

h2

Bn minusInminusIn

minusInminusIn Bn

mit Bn =

4 + h2

ν∆t minus1

minus1 minus1

minus1 4 + h2

ν∆t

(216)

Das daraus resultierende Gleichungssystem muumlssen wir nun effizient loumlsen worauf wir in Kapitel 31eingehen

KAPITEL 2 THEORETISCHE GRUNDLAGEN 11

ProjektionIm Projektionsschritt betrachten wir Gleichung (24) und erhalten wie im Diffusionsschritt eine Poisson-Gleichung zur Berechnung des Druckfeldes p Auch hier ergibt sich durch die Diskretisierung vonnablamiddotnablaein duumlnn besetztes lineares Gleichungssystem mit rechter Seite nabla middot w3 welches wir loumlsen muumlssen umals Abschluss unseres Algorithmus die aktualisierte Geschwindigkeit uumlber die Gleichung

u (x t+ ∆t) = w4 = w3 minusnablap (217)

berechnen zu koumlnnen Dazu verwenden wir folgende Diskretisierungen der auftretenden Operatoren

(nablas)ij =

(parts

partxparts

party

)ij

asymp(si+1j minus siminus1j

2hsij+1 minus sijminus1

2h

)(218)

(nabla middot v)ij =

(partvx

partx+partvy

party

)ij

asymp

(vxi+1j minus vximinus1j

2h+vyij+1 minus v

yijminus1

2h

) (219)

wobei s erneut ein Skalarfeld und v = (vx vy) ein zweidimensionales Vektorfeld mit x- und y-Komponentebezeichnet Analog zu der Schreibweise in Gleichung (212) repraumlsentieren ()ij die entsprechendenGroumlszligen ausgewertet im Punkt xij isin Ωh

Nun sind wir in der Lage im naumlchsten Zeitschritt das Geschwindigkeitsfeld zu berechnen und schlieszligensomit die Diskretisierung der Navier-Stokes Gleichungen (21) und (22) ab Dazu fassen wir die wesent-lichen Ergebnisse dieses Unterkapitels in algorithmischer Form zusammen Wir orientieren uns dabei anden in Schema (28) angefuumlhrten Schritten und erhalten so ein kompaktes numerisches Loumlsungsverfahrender Navier-Stokes Gleichungen

Algorithmus 241 (bdquoStable Fluidsldquo Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen nach[Stam])Sei ein initiales Geschwindigkeitsfeld w0

(0) (x) = u (x 0) gegebenFuumlr l = 1 L

1 Kraft aufpraumlgen w1(l) (x) = w0

(lminus1) (x) + ∆tf (l) (x)

2 Advektion w2(l) (x) = w1

(l)(xminus∆tw1

(l) (x))

3 Diffusion bestimme w3(l) uumlber (Iminus ν∆tnabla middot nabla)w3

(l) = w2(l)

4 Projektion w4(l) = w3

(l) minusnablap(l) wobei sich p(l) ergibt aus nabla middot nablap(l) = nabla middotw3(l)

5 Aktualisierung w0(l) (x) = u (x l middot∆t) = w4

(l) (x)

Die Anzahl L + 1 der durchzufuumlhrenden Zeitschritte legen wir dadurch fest wie lange wir die Simu-lation ausfuumlhren Das Kraftfeld f (l) wird durch den Anwender von auszligen bestimmt und steht in jedemZeitschritt aktualisiert zur Verfuumlgung Die genaue Umsetzung der Schritte in Algorithmus 241 stellenwir in Kapitel 3 vor

Kapitel 3

Implementierung

Nachdem wir in Kapitel 2 auf die in unserer Simulation verwendete Theorie bezuumlglich Modell Dis-kretisierung und numerischer Loumlsung eingegangen sind wollen wir uns nun ihrer Umsetzung und derRealisierung der Visualisierung und Interaktion auf einem Tablet-Computer widmen Die Stroumlmungs-simulation fuumlhren wir auf dem Asus EeePad Transformer TF101 auf dem das Betriebssystem Android403 installiert ist in einer App aus Details zur Hardware des verwendeten Tablet-Computers findensich in Kapitel 44 Der Anwender hat waumlhrend der Simulation die Moumlglichkeit die Stroumlmung einesFluids durch Beruumlhren des Bildschirms zu beeinflussen Stroumlmungssimulationen wie sie etwa bei [Stam]oder [Harris] beschrieben werden koumlnnen vom Nutzer durch Interaktion mit der Maus beeinflusst wer-den auf einem Tablet-Computer besteht jedoch die Moumlglichkeit dies mit einem Finger auf dem Bild-schirm durchzufuumlhren Dadurch wirkt die Simulation fuumlr den Betrachter realer Die Moumlglichkeit solcheComputer zur Stroumlmungssimulation einzusetzen wird dadurch eroumlffnet dass Tablet-Computer hinsicht-lich ihrer Rechenleistung immer leistungsfaumlhiger werdenBevor wir auf die konkrete Implementierung des in Kapitel 2 vorgestellten Verfahrens eingehen wollenwir zunaumlchst das Vorgehen bei einer App-Programmierung in der Programmiersprache Java fuumlr das An-droid-Betriebssystem erlaumlutern wobei wir uns an [Android Developer] orientieren Zunaumlchst installierenwir eine Software-Entwicklungsumgebung wie etwa Eclipse1 in der wir die eigentliche Programmie-rung durchfuumlhren Ergaumlnzend benoumltigen wir das Android Software Development Kit sowie die AndroidDevelopment Tools die wir in die Entwicklungsumgebung einbinden muumlssen Anschlieszligend koumlnnen wirein neues Android App Project erstellen welches die App repraumlsentiert Dabei werden einige Dateienautomatisch erstellt wie etwa die Manifest-Datei die eine zentrale Rolle einnimmt da sie die funda-mentalen Charakteristiken der App beschreibt und jede ihrer Komponenten definiert Die Programmie-rung einer App unterscheidet sich vor allem dadurch von einer bdquogewoumlhnlichenldquo Java-Programmierungals dass zum korrekten Erstellen der App viele spezielle Funktionen vom System verlangt werden diewir implementieren muumlssen Auch die Umsetzung der Visualisierung mit Hilfe der OpenGL ES 20-Bibliothek verlangt ein gesondertes Vorgehen Wir muumlssen die Visualisierung in eine eigene Klasse aus-lagern diese entsprechend kennzeichnen und erneut vom System verlangte Funktionen integrieren Aumlhn-lich verhaumllt es sich bei der Beruumlcksichtigung der Anwender-InteraktionUm eine App schlieszliglich auszufuumlhren bestehen zwei Moumlglichkeiten Einerseits koumlnnen wir die App aufeinem externen Android-Geraumlt starten zum Beispiel einem Tablet-Computer andererseits den Emula-tor nutzen Dabei handelt es sich um eine sogenannte Android Virtual Device die auf dem Computerausgefuumlhrt wird auf dem sich die Entwicklungsumgebung befindet Die Virtual Device entspricht ei-nem externen Geraumlt welches auf dem Computer simuliert wird Es empfiehlt sich die App zunaumlchstim Emulator zu testen da bei eventuellen Programmierfehlern das externe Geraumlt durch Uumlberhitzungoder aumlhnliches beschaumldigt werden kann Bisher ist es nicht moumlglich Apps auf dem Emulator zu tes-ten die sich der Bibliothek OpenGL ES 20 zur Darstellung von Grafiken bedienen wie wir sie fuumlr

1Fuumlr naumlhere Informationen verweisen wir auf httpwwweclipseorg

12

KAPITEL 2 THEORETISCHE GRUNDLAGEN 6

also partppartn |partΩ equiv 0 gilt wobei n den aumluszligeren Normalenvektor von Ω bezeichnet

Die verschiedenen Anfangs- und Randbedingungen sind miteinander und mit der Anwender-Interaktionder wir uns in Abschnitt 43 widmen kombinierbar Wir koumlnnen somit eine Vielzahl von Testfaumlllen kon-struieren von denen wir eine Auswahl in Kapitel 4 praumlsentieren

23 Projektionsverfahren und die Helmholtz-Hodge-Zerlegung

Nachdem wir zuvor alle Komponenten der Navier-Stokes Gleichungen aus physikalischer Sicht betrach-tet und Anfangs- sowie Randbedingungen eingefuumlhrt haben wollen wir sie nun in eine zum Loumlsen geeig-netere Form bringen und anschlieszligend ein Vorgehen zur Loumlsung dieser Gleichungen entwickeln Dabeiist die Art der Diskretisierung des von Raum- und Zeitvariablen abhaumlngigen Problems entscheidendZunaumlchst nehmen wir eine simple Zeitdiskretisierung vor indem wir das Zeitintervall I = [0 T ] inTeilintervalle zerlegen Anschlieszligend betrachten wir Gleichung (21) innerhalb eines Zeitschritts unddiskretisieren die auftretenden Operatoren im Ort (vgl Kapitel 24) Im Folgenden koumlnnen wir daherdie einzelnen Bestandteile dieser Gleichung als zeitunabhaumlngig ansehen da wir das Loumlsungsverfahreninnerhalb eines Zeitschritts entwickelnUm die Gleichungen in ein besser zu loumlsendes System zu uumlberfuumlhren betrachten wir als Hilfsmittelzunaumlchst die sogenannte Helmholtz-Hodge Zerlegung (vgl [Chorin])

Satz 231 Sei Ω sub R2 ein Gebiet mit glattem Rand partΩ Dann kann jedes Vektorfeld w zerlegt werdenin die Form

w = u +nablapwobei nabla middot u = 0 gilt das Vektorfeld u also divergenzfrei ist Auszligerdem ist u parallel zu partΩ das heiszligtu middot n = 0 mit dem aumluszligeren Normalenvektor n von Ω p bezeichnet ein Skalarfeld

In jedem Zeitschritt muumlssen wir Gleichung (21) loumlsen wobei wir gewaumlhrleisten muumlssen dass Glei-chung (22) gilt Wenn wir nun davon ausgehen durch das Loumlsen von Gleichung (21) ein Geschwindig-keitsfeld w erhalten zu haben so muss nicht zwangslaumlufig nabla middotw = 0 gelten Dies erreichen wir durchAnwenden von Satz 231 auf das Geschwindigkeitsfeld w Wir setzen somit am Ende des Zeitschrittsdas aktualisierte Geschwindigkeitsfeld analog zu obigem Satz als u = w minusnablapJetzt stellt sich die Frage wie das Skalarfeld p zu berechnen ist Wenden wir den Divergenz-Operatornablamiddot auf beide Seiten der Gleichung aus Satz 231 an so erhalten wir

nabla middotw = nabla middot u︸ ︷︷ ︸=0

+nabla middot nablap

hArr nabla middotw = nabla middot nablap (24)

Setzen wir also die Loumlsung von Gleichung (21) als bekannt voraus so koumlnnen wir durch Loumlsen derPoisson-Gleichung (24) den Druck p ermitteln mit dem wir das Geschwindigkeitsfeld w so modifizie-ren koumlnnen dass es Gleichung (22) erfuumlllt Als naumlchstes muumlssen wir uns damit beschaumlftigen wie wir dasvorlaumlufige Geschwindigkeitsfeld w berechnen koumlnnen

Zunaumlchst definieren wir hierzu mit Hilfe von Satz 231 einen linearen Operator P der ein Vektorfeld wauf seinen divergenzfreien Teil projiziert Fuumlr diesen Operator gilt dann

P (w) = P (u) + P (nablap) da P linear ist

P (w) = u wegen Satz 231 und (25)

P (u) = u nach Voraussetzung

KAPITEL 2 THEORETISCHE GRUNDLAGEN 7

woraus insgesamt

P (nablap) = 0 (26)

folgtAnhand von Gleichung (25) koumlnnen wir uns mit dem Schwarzschen Satz (vgl [Forster]) uumlberlegendass P

(partupartt

)= partu

partt gilt Der Satz von Schwarz besagt dass bei einer q-mal stetig partiell differen-zierbaren Funktion die ersten q Ableitungen vertauscht werden duumlrfen Bei uns gilt nach Voraussetzungu isin C2 (Ω)capC1 (I) da die Ausdruumlckenablamiddotnablau und partu

partt in Gleichung (21) eine entsprechende Glattheit desGeschwindigkeitsfeldes bezuumlglich der Variablen (x t) verlangen Dabei bezeichnet Ck (Ul) den Raumder k-mal stetig partiell differenzierbaren Funktionen uumlber U2 = Ω sub R2 beziehungsweise U1 = I sub Rmit k l isin 1 2 Somit folgt

nabla middot partupartt

=part

partt(nabla middot u) = 0

Wenden wir nun den Operator P auf Gleichung (21) an und nutzen seine Linearitaumlt undGleichung (26) aus so erhalten wir

partu

partt= P (minus (u middot nabla)u + νnabla middot nablau + f) (27)

Aus Gleichung (27) ergibt sich direkt der von uns verwendete Algorithmus zur Loumlsung der Navier-StokesGleichungen der sich in vier Schritte gliedert

u (middot t) = w0Kraft aufpraumlgenminusminusminusminusminusminusminusminusrarr w1

Advektionminusminusminusminusminusrarr w2Diffusionminusminusminusminusminusrarr w3

Projektionminusminusminusminusminusrarr w4 = u (middot t+ 1) (28)

Wir nehmen an dass uns das Geschwindigkeitsfeld u zum Zeitpunkt t bekannt ist und setzenw0 (x) = u (x t) Pro Zeitschritt loumlsen wir die Gleichung (21) durch sogenanntes bdquoOperator-Splittingldquosukzessiv numerisch Wie in allen Projektionsmethoden entsteht auch hier durch das Splitting ein nu-merischer Fehler wodurch wir Gleichung (21) nicht mehr exakt loumlsen Leider geht [Stam] in seinerOriginalarbeit nicht auf die Ordnung des Verfahrens ein aufgrund der Struktur des Verfahrens und derAumlhnlichkeit zu Chorinschen Projektionsmethoden (vgl [Anderson]) ist aber nicht von einer hohen Ord-nung auszugehen Schlieszliglich gewaumlhrleisten wir durch das Anwenden des oben definierten Projektions-operators P dass Gleichung (22) erfuumlllt ist was anschaulich aus Abbildung 22 hervorgeht

Abbildung 22 Sukzessive Berechnung der Geschwindigkeit in einem Punkt innerhalb eines Zeitschritts(vgl [Stam])

Am Ende eines jeden Zeitschritts setzen wir w0 = w4 Da wir wie oben beschrieben ausgehend vonw0 innerhalb eines Zeitschrittes operieren haumlngen die Geschwindigkeitsfelder wk k isin 0 1 2 3 4

KAPITEL 2 THEORETISCHE GRUNDLAGEN 8

waumlhrend der Berechnung nur von der Ortsvariablen x ab Das Vektorfeld w4 entspricht schlieszliglich demGeschwindigkeitsfeld u zum Zeitpunkt t+∆t also u (x t+ ∆t) mit der Zeitschrittweite ∆t isin R+ DieSimulation erhalten wir letztendlich durch Iteration der in Schema (28) beschriebenen Vorgehensweiseuumlber die Zeitschritte Daraus ergibt sich durch Diskretisierung der auftretenden Operatoren ein nume-risches Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen (21) und (22) worauf wir im naumlchstenAbschnitt eingehen

24 Diskretisierung und numerische Loumlsung

Wir erlaumlutern in diesem Abschnitt die in Schema (28) angefuumlhrten Schritte und stellen Diskretisierungs-beziehungsweise Loumlsungstechniken vor um abschlieszligend ein kompaktes Loumlsungsverfahren der Navier-Stokes Gleichungen aufzustellen Zur Diskretisierung aller auftretenden Operatoren verwenden wir indieser Arbeit meist finite Differenzen zweiter Ordnung Approximationen abweichender Ordnung sindbeispielsweise bei der Behandlung von Randbedingungen noumltig auf die wir in Abschnitt 314 naumlhereingehenWie in Abschnitt 23 bereits erwaumlhnt diskretisieren wir das durch die Navier-Stokes Gleichungen (21)und (22) und Anfangs- sowie Randbedingungen gestellte Problem zuerst in der Zeit und anschlieszligendim Ort Dazu waumlhlen wir eine aumlquidistante Zerlegung des Zeitintervalls in L Teilintervalle der Form

I = [0 T ] =

L⋃l=1

[t(lminus1) t(l)

]

wobei t(l) = l middot∆t und T = L middot∆t gilt Die folgenden Diskretisierungen im Ort fuumlhren wir nun jeweilszu einem festen Zeitpunkt t(l) durch weshalb die auftretenden Groumlszligen zeitunabhaumlngig sindFuumlr unsere Simulation betrachten wir das quadratische Rechengebiet Ω = [minus1 1]2 sub R2 in dem sichdas Fluid befinden soll Davon ausgehend definieren wir ein diskretes Gebiet Ωh mit Schrittweite h isin Rdie wir sowohl in x- als auch in y-Richtung zur Diskretisierung verwenden Dadurch ergibt sich Ωh alsein Gitter fuumlr das xij isin Ωh die Form xij = (minus1 + ihminus1 + jh) hat wobei i j isin 0 n minus 1gilt und n isin N die Anzahl der Gitterpunkte pro Zeile beziehungsweise Spalte im Gitter angibt ImFolgenden betrachten wir nur die Operationen innerhalb eines Zeitschrittes das heiszligt im Uumlbergang vont(l) nach t(l) + ∆t Dazu sei w0 wie oben als bekanntes Geschwindigkeitsfeld u

(x t(l)

)definiert und

wk k isin 1 2 3 4 bezeichnet die unterschiedlichen Geschwindigkeitsfelder innerhalb des ZeitschrittsNach diesen Vorbereitungen widmen wir uns nun Diskretisierungs- und Loumlsungsmethoden fuumlr die ein-zelnen Bestandteile von Gleichung (27) beziehungsweise Schema (28)

Kraft aufpraumlgenZuerst kann dem Fluid eine Kraft aufgepraumlgt werden Dies geschieht waumlhrend der Simulation durch denAnwender und soll nur ein Mal pro Zeitschritt erfolgen Deshalb koumlnnen wir die Annahme treffen dassdie Kraft uumlber den gesamten Zeitschritt konstant ist Somit ist eine Beruumlcksichtigung der Kraft zu Beginneines jeden Zeitschritts ausreichend Wir berechnen also im ersten Schritt unseres Loumlsers

w1 = w0 + ∆tf (29)

was eine gute Approximation der Wirkung der Kraft uumlber den Zeitschritt darstellt da wir ihren Einflussdurch die Multiplikation des Kraftfeldes f mit der Zeitschrittweite ∆t uumlber den ganzen Zeitschritt trans-portieren

KAPITEL 2 THEORETISCHE GRUNDLAGEN 9

AdvektionUm die Advektion des Fluids zu beruumlcksichtigen fassen wir die Gitterpunkte als die oben beschriebenenTeilchen beziehungsweise Fluidpartikel auf und muumlssen dann in jedem Zeitschritt die Geschwindigkeiteines solchen Partikels aktualisierenEine erste Idee waumlre es hierzu folgende explizite Methode zu betrachten Die Position r eines Partikelsveraumlndert sich mit der Geschwindigkeit also koumlnnen wir die Position so weit verschieben wie sich dasPartikel in der Zeit ∆t mit seiner Geschwindigkeit fortbewegt Also gilt

r(t(l) + ∆t

)= r

(t(l))

+ ∆tu(t(l))

was dem expliziten Eulerverfahren entspricht Allerdings ist diese Methode instabil fuumlr groszlige Zeitschritt-weitenWir betrachten deshalb die implizite Methode der Charakteristiken die die Stabilitaumlt des Verfahrens im-pliziert Zur genaueren Erlaumluterung dieses Verfahrens verweisen wir auf [Stam] und geben hier nur einegrobe Zusammenfassung Im Wesentlichen verfolgen wir jeden Punkt x isin Ω uumlber die Zeit ∆t entlangw1 zuruumlck Dadurch entsteht ein Pfad p (x t) von x zu einem Punkt x0 = p (xminus∆t) der auch alsStromlinie interpretiert werden kann Dies wird in Abbildung 23 verdeutlicht

Abbildung 23 Weg den ein Fluidpartikel in der Zeit zuruumlcklegt (vgl [Stam])

Wir setzen dann die neue Geschwindigkeit w2 im Punkt x als die Geschwindigkeit die im Punkt x0 zurvorherigen Zeit vorliegt also

w2 (x) = w1 (p (xminus∆t)) = w1 (xminus∆tw1 (x)) (210)

Durch das Verwenden der Methode der Charakteristiken liefert unser Vorgehen eine fuumlr beliebig groszligeZeitschrittweiten und Geschwindigkeiten unbedingt stabile numerische Loumlsung (vgl [Stam]) Das koumln-nen wir daran feststellen dass der maximale Wert des Geschwindigkeitsfeldes in diesem Schritt niegroumlszliger als im vorherigen Zeitschritt werden kann auszliger wir praumlgen eine externe Kraft auf Denn nachGleichung (210) gilt

max(w2

(l))le max

(w1

(l))

(29)= max

(w0

(l) + ∆tf (l))

f (l)equiv0= max

(w4

(lminus1))

wobei ()(l) die entsprechende Groumlszlige im l-ten Zeitschritt bezeichnet Es ist f (l) equiv 0 da wir hier keineAnwender-Interaktion beruumlcksichtigenFuumlr Details zur Implementierung der Methode der Charakteristiken verweisen wir auf Kapitel 31

KAPITEL 2 THEORETISCHE GRUNDLAGEN 10

DiffusionHier betrachten wir eine Gleichung der Form

partu

partt= νnabla middot nablau (211)

Um diese numerisch zu loumlsen diskretisieren wir zunaumlchst den Laplace-Operatornabla middotnabla mit finiten Diffe-renzen im Ort und wenden dann ein Zeitschrittverfahren an Die Anwendung vonnablamiddotnabla auf das Geschwin-digkeitsfeld u erfolgt komponentenweise in x- beziehungsweise y-Richtung weshalb wir vereinfachenddie Diskretisierung des Operators angewendet auf ein hinreichend glattes Skalarfeld s betrachten Wirstellen also die Diskretisierung vonnabla middot nablas = part2s

partx2+ part2s

party2im R2 auf Dann gilt

(nabla middot nablas)ij asympsi+1j minus 2sij + siminus1j

h2+sij+1 minus 2sij + sijminus1

h2(212)

mit sij = s (xij) und analog (nabla middot nablas)ij = nabla middot nablas (xij) fuumlr xij isin Ωh Betrachten wir das durchGleichung (212) diskretisierte Skalarfeld s in jedem Gitterpunkt koumlnnen wir den diskretisierten Laplace-Operator als Matrix auffassen welche die folgende Gestalt aufweist

1

h2

Bn In

In In

In Bn

mit Bn =

minus4 1

1 1

1 minus4

isin Rntimesn (213)

Hierbei bezeichnet In die Einheitsmatrix der Dimension ntimesn Wenden wir auf die im Ort diskretisierteGleichung (211) ein explizites Zeitschrittverfahren der Form

u (x t+ ∆t) = u (x t) + ν∆tnabla middot nablau (x t) (214)

an so tritt erneut das Problem der Instabilitaumlt fuumlr groszlige Zeitschrittweiten ∆t beziehungsweise groszligekinematische Viskositaumlten ν auf Diese Schwierigkeit taucht auf da die Methode einem expliziten Euler-Verfahren entspricht und daher aumlhnliche Eigenschaften bezuumlglich der Stabilitaumlt aufweist Um eine stabileLoumlsungsmethode zu konstruieren verwenden wir statt des in Gleichung (214) angefuumlhrten ein implizitesVerfahren was sich durch Uumlbertragen auf unsere Schreibweise innerhalb eines Zeitschrittes schreibenlaumlsst als

(Iminus ν∆tnabla middot nabla)w3 = w2 (215)

wobei I den Identitaumltsoperator darstellt Diese Gleichung entspricht einer Poisson-Gleichung fuumlr dasGeschwindigkeitsfeld w3 Setzen wir den diskretisierten Laplace-Operator aus Gleichung (213) in Glei-chung (215) ein so ergibt sich die Darstellung fuumlr die Systemmatrix des zu loumlsenden Gleichungssystemsals

ν∆t

h2

Bn minusInminusIn

minusInminusIn Bn

mit Bn =

4 + h2

ν∆t minus1

minus1 minus1

minus1 4 + h2

ν∆t

(216)

Das daraus resultierende Gleichungssystem muumlssen wir nun effizient loumlsen worauf wir in Kapitel 31eingehen

KAPITEL 2 THEORETISCHE GRUNDLAGEN 11

ProjektionIm Projektionsschritt betrachten wir Gleichung (24) und erhalten wie im Diffusionsschritt eine Poisson-Gleichung zur Berechnung des Druckfeldes p Auch hier ergibt sich durch die Diskretisierung vonnablamiddotnablaein duumlnn besetztes lineares Gleichungssystem mit rechter Seite nabla middot w3 welches wir loumlsen muumlssen umals Abschluss unseres Algorithmus die aktualisierte Geschwindigkeit uumlber die Gleichung

u (x t+ ∆t) = w4 = w3 minusnablap (217)

berechnen zu koumlnnen Dazu verwenden wir folgende Diskretisierungen der auftretenden Operatoren

(nablas)ij =

(parts

partxparts

party

)ij

asymp(si+1j minus siminus1j

2hsij+1 minus sijminus1

2h

)(218)

(nabla middot v)ij =

(partvx

partx+partvy

party

)ij

asymp

(vxi+1j minus vximinus1j

2h+vyij+1 minus v

yijminus1

2h

) (219)

wobei s erneut ein Skalarfeld und v = (vx vy) ein zweidimensionales Vektorfeld mit x- und y-Komponentebezeichnet Analog zu der Schreibweise in Gleichung (212) repraumlsentieren ()ij die entsprechendenGroumlszligen ausgewertet im Punkt xij isin Ωh

Nun sind wir in der Lage im naumlchsten Zeitschritt das Geschwindigkeitsfeld zu berechnen und schlieszligensomit die Diskretisierung der Navier-Stokes Gleichungen (21) und (22) ab Dazu fassen wir die wesent-lichen Ergebnisse dieses Unterkapitels in algorithmischer Form zusammen Wir orientieren uns dabei anden in Schema (28) angefuumlhrten Schritten und erhalten so ein kompaktes numerisches Loumlsungsverfahrender Navier-Stokes Gleichungen

Algorithmus 241 (bdquoStable Fluidsldquo Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen nach[Stam])Sei ein initiales Geschwindigkeitsfeld w0

(0) (x) = u (x 0) gegebenFuumlr l = 1 L

1 Kraft aufpraumlgen w1(l) (x) = w0

(lminus1) (x) + ∆tf (l) (x)

2 Advektion w2(l) (x) = w1

(l)(xminus∆tw1

(l) (x))

3 Diffusion bestimme w3(l) uumlber (Iminus ν∆tnabla middot nabla)w3

(l) = w2(l)

4 Projektion w4(l) = w3

(l) minusnablap(l) wobei sich p(l) ergibt aus nabla middot nablap(l) = nabla middotw3(l)

5 Aktualisierung w0(l) (x) = u (x l middot∆t) = w4

(l) (x)

Die Anzahl L + 1 der durchzufuumlhrenden Zeitschritte legen wir dadurch fest wie lange wir die Simu-lation ausfuumlhren Das Kraftfeld f (l) wird durch den Anwender von auszligen bestimmt und steht in jedemZeitschritt aktualisiert zur Verfuumlgung Die genaue Umsetzung der Schritte in Algorithmus 241 stellenwir in Kapitel 3 vor

Kapitel 3

Implementierung

Nachdem wir in Kapitel 2 auf die in unserer Simulation verwendete Theorie bezuumlglich Modell Dis-kretisierung und numerischer Loumlsung eingegangen sind wollen wir uns nun ihrer Umsetzung und derRealisierung der Visualisierung und Interaktion auf einem Tablet-Computer widmen Die Stroumlmungs-simulation fuumlhren wir auf dem Asus EeePad Transformer TF101 auf dem das Betriebssystem Android403 installiert ist in einer App aus Details zur Hardware des verwendeten Tablet-Computers findensich in Kapitel 44 Der Anwender hat waumlhrend der Simulation die Moumlglichkeit die Stroumlmung einesFluids durch Beruumlhren des Bildschirms zu beeinflussen Stroumlmungssimulationen wie sie etwa bei [Stam]oder [Harris] beschrieben werden koumlnnen vom Nutzer durch Interaktion mit der Maus beeinflusst wer-den auf einem Tablet-Computer besteht jedoch die Moumlglichkeit dies mit einem Finger auf dem Bild-schirm durchzufuumlhren Dadurch wirkt die Simulation fuumlr den Betrachter realer Die Moumlglichkeit solcheComputer zur Stroumlmungssimulation einzusetzen wird dadurch eroumlffnet dass Tablet-Computer hinsicht-lich ihrer Rechenleistung immer leistungsfaumlhiger werdenBevor wir auf die konkrete Implementierung des in Kapitel 2 vorgestellten Verfahrens eingehen wollenwir zunaumlchst das Vorgehen bei einer App-Programmierung in der Programmiersprache Java fuumlr das An-droid-Betriebssystem erlaumlutern wobei wir uns an [Android Developer] orientieren Zunaumlchst installierenwir eine Software-Entwicklungsumgebung wie etwa Eclipse1 in der wir die eigentliche Programmie-rung durchfuumlhren Ergaumlnzend benoumltigen wir das Android Software Development Kit sowie die AndroidDevelopment Tools die wir in die Entwicklungsumgebung einbinden muumlssen Anschlieszligend koumlnnen wirein neues Android App Project erstellen welches die App repraumlsentiert Dabei werden einige Dateienautomatisch erstellt wie etwa die Manifest-Datei die eine zentrale Rolle einnimmt da sie die funda-mentalen Charakteristiken der App beschreibt und jede ihrer Komponenten definiert Die Programmie-rung einer App unterscheidet sich vor allem dadurch von einer bdquogewoumlhnlichenldquo Java-Programmierungals dass zum korrekten Erstellen der App viele spezielle Funktionen vom System verlangt werden diewir implementieren muumlssen Auch die Umsetzung der Visualisierung mit Hilfe der OpenGL ES 20-Bibliothek verlangt ein gesondertes Vorgehen Wir muumlssen die Visualisierung in eine eigene Klasse aus-lagern diese entsprechend kennzeichnen und erneut vom System verlangte Funktionen integrieren Aumlhn-lich verhaumllt es sich bei der Beruumlcksichtigung der Anwender-InteraktionUm eine App schlieszliglich auszufuumlhren bestehen zwei Moumlglichkeiten Einerseits koumlnnen wir die App aufeinem externen Android-Geraumlt starten zum Beispiel einem Tablet-Computer andererseits den Emula-tor nutzen Dabei handelt es sich um eine sogenannte Android Virtual Device die auf dem Computerausgefuumlhrt wird auf dem sich die Entwicklungsumgebung befindet Die Virtual Device entspricht ei-nem externen Geraumlt welches auf dem Computer simuliert wird Es empfiehlt sich die App zunaumlchstim Emulator zu testen da bei eventuellen Programmierfehlern das externe Geraumlt durch Uumlberhitzungoder aumlhnliches beschaumldigt werden kann Bisher ist es nicht moumlglich Apps auf dem Emulator zu tes-ten die sich der Bibliothek OpenGL ES 20 zur Darstellung von Grafiken bedienen wie wir sie fuumlr

1Fuumlr naumlhere Informationen verweisen wir auf httpwwweclipseorg

12

KAPITEL 2 THEORETISCHE GRUNDLAGEN 7

woraus insgesamt

P (nablap) = 0 (26)

folgtAnhand von Gleichung (25) koumlnnen wir uns mit dem Schwarzschen Satz (vgl [Forster]) uumlberlegendass P

(partupartt

)= partu

partt gilt Der Satz von Schwarz besagt dass bei einer q-mal stetig partiell differen-zierbaren Funktion die ersten q Ableitungen vertauscht werden duumlrfen Bei uns gilt nach Voraussetzungu isin C2 (Ω)capC1 (I) da die Ausdruumlckenablamiddotnablau und partu

partt in Gleichung (21) eine entsprechende Glattheit desGeschwindigkeitsfeldes bezuumlglich der Variablen (x t) verlangen Dabei bezeichnet Ck (Ul) den Raumder k-mal stetig partiell differenzierbaren Funktionen uumlber U2 = Ω sub R2 beziehungsweise U1 = I sub Rmit k l isin 1 2 Somit folgt

nabla middot partupartt

=part

partt(nabla middot u) = 0

Wenden wir nun den Operator P auf Gleichung (21) an und nutzen seine Linearitaumlt undGleichung (26) aus so erhalten wir

partu

partt= P (minus (u middot nabla)u + νnabla middot nablau + f) (27)

Aus Gleichung (27) ergibt sich direkt der von uns verwendete Algorithmus zur Loumlsung der Navier-StokesGleichungen der sich in vier Schritte gliedert

u (middot t) = w0Kraft aufpraumlgenminusminusminusminusminusminusminusminusrarr w1

Advektionminusminusminusminusminusrarr w2Diffusionminusminusminusminusminusrarr w3

Projektionminusminusminusminusminusrarr w4 = u (middot t+ 1) (28)

Wir nehmen an dass uns das Geschwindigkeitsfeld u zum Zeitpunkt t bekannt ist und setzenw0 (x) = u (x t) Pro Zeitschritt loumlsen wir die Gleichung (21) durch sogenanntes bdquoOperator-Splittingldquosukzessiv numerisch Wie in allen Projektionsmethoden entsteht auch hier durch das Splitting ein nu-merischer Fehler wodurch wir Gleichung (21) nicht mehr exakt loumlsen Leider geht [Stam] in seinerOriginalarbeit nicht auf die Ordnung des Verfahrens ein aufgrund der Struktur des Verfahrens und derAumlhnlichkeit zu Chorinschen Projektionsmethoden (vgl [Anderson]) ist aber nicht von einer hohen Ord-nung auszugehen Schlieszliglich gewaumlhrleisten wir durch das Anwenden des oben definierten Projektions-operators P dass Gleichung (22) erfuumlllt ist was anschaulich aus Abbildung 22 hervorgeht

Abbildung 22 Sukzessive Berechnung der Geschwindigkeit in einem Punkt innerhalb eines Zeitschritts(vgl [Stam])

Am Ende eines jeden Zeitschritts setzen wir w0 = w4 Da wir wie oben beschrieben ausgehend vonw0 innerhalb eines Zeitschrittes operieren haumlngen die Geschwindigkeitsfelder wk k isin 0 1 2 3 4

KAPITEL 2 THEORETISCHE GRUNDLAGEN 8

waumlhrend der Berechnung nur von der Ortsvariablen x ab Das Vektorfeld w4 entspricht schlieszliglich demGeschwindigkeitsfeld u zum Zeitpunkt t+∆t also u (x t+ ∆t) mit der Zeitschrittweite ∆t isin R+ DieSimulation erhalten wir letztendlich durch Iteration der in Schema (28) beschriebenen Vorgehensweiseuumlber die Zeitschritte Daraus ergibt sich durch Diskretisierung der auftretenden Operatoren ein nume-risches Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen (21) und (22) worauf wir im naumlchstenAbschnitt eingehen

24 Diskretisierung und numerische Loumlsung

Wir erlaumlutern in diesem Abschnitt die in Schema (28) angefuumlhrten Schritte und stellen Diskretisierungs-beziehungsweise Loumlsungstechniken vor um abschlieszligend ein kompaktes Loumlsungsverfahren der Navier-Stokes Gleichungen aufzustellen Zur Diskretisierung aller auftretenden Operatoren verwenden wir indieser Arbeit meist finite Differenzen zweiter Ordnung Approximationen abweichender Ordnung sindbeispielsweise bei der Behandlung von Randbedingungen noumltig auf die wir in Abschnitt 314 naumlhereingehenWie in Abschnitt 23 bereits erwaumlhnt diskretisieren wir das durch die Navier-Stokes Gleichungen (21)und (22) und Anfangs- sowie Randbedingungen gestellte Problem zuerst in der Zeit und anschlieszligendim Ort Dazu waumlhlen wir eine aumlquidistante Zerlegung des Zeitintervalls in L Teilintervalle der Form

I = [0 T ] =

L⋃l=1

[t(lminus1) t(l)

]

wobei t(l) = l middot∆t und T = L middot∆t gilt Die folgenden Diskretisierungen im Ort fuumlhren wir nun jeweilszu einem festen Zeitpunkt t(l) durch weshalb die auftretenden Groumlszligen zeitunabhaumlngig sindFuumlr unsere Simulation betrachten wir das quadratische Rechengebiet Ω = [minus1 1]2 sub R2 in dem sichdas Fluid befinden soll Davon ausgehend definieren wir ein diskretes Gebiet Ωh mit Schrittweite h isin Rdie wir sowohl in x- als auch in y-Richtung zur Diskretisierung verwenden Dadurch ergibt sich Ωh alsein Gitter fuumlr das xij isin Ωh die Form xij = (minus1 + ihminus1 + jh) hat wobei i j isin 0 n minus 1gilt und n isin N die Anzahl der Gitterpunkte pro Zeile beziehungsweise Spalte im Gitter angibt ImFolgenden betrachten wir nur die Operationen innerhalb eines Zeitschrittes das heiszligt im Uumlbergang vont(l) nach t(l) + ∆t Dazu sei w0 wie oben als bekanntes Geschwindigkeitsfeld u

(x t(l)

)definiert und

wk k isin 1 2 3 4 bezeichnet die unterschiedlichen Geschwindigkeitsfelder innerhalb des ZeitschrittsNach diesen Vorbereitungen widmen wir uns nun Diskretisierungs- und Loumlsungsmethoden fuumlr die ein-zelnen Bestandteile von Gleichung (27) beziehungsweise Schema (28)

Kraft aufpraumlgenZuerst kann dem Fluid eine Kraft aufgepraumlgt werden Dies geschieht waumlhrend der Simulation durch denAnwender und soll nur ein Mal pro Zeitschritt erfolgen Deshalb koumlnnen wir die Annahme treffen dassdie Kraft uumlber den gesamten Zeitschritt konstant ist Somit ist eine Beruumlcksichtigung der Kraft zu Beginneines jeden Zeitschritts ausreichend Wir berechnen also im ersten Schritt unseres Loumlsers

w1 = w0 + ∆tf (29)

was eine gute Approximation der Wirkung der Kraft uumlber den Zeitschritt darstellt da wir ihren Einflussdurch die Multiplikation des Kraftfeldes f mit der Zeitschrittweite ∆t uumlber den ganzen Zeitschritt trans-portieren

KAPITEL 2 THEORETISCHE GRUNDLAGEN 9

AdvektionUm die Advektion des Fluids zu beruumlcksichtigen fassen wir die Gitterpunkte als die oben beschriebenenTeilchen beziehungsweise Fluidpartikel auf und muumlssen dann in jedem Zeitschritt die Geschwindigkeiteines solchen Partikels aktualisierenEine erste Idee waumlre es hierzu folgende explizite Methode zu betrachten Die Position r eines Partikelsveraumlndert sich mit der Geschwindigkeit also koumlnnen wir die Position so weit verschieben wie sich dasPartikel in der Zeit ∆t mit seiner Geschwindigkeit fortbewegt Also gilt

r(t(l) + ∆t

)= r

(t(l))

+ ∆tu(t(l))

was dem expliziten Eulerverfahren entspricht Allerdings ist diese Methode instabil fuumlr groszlige Zeitschritt-weitenWir betrachten deshalb die implizite Methode der Charakteristiken die die Stabilitaumlt des Verfahrens im-pliziert Zur genaueren Erlaumluterung dieses Verfahrens verweisen wir auf [Stam] und geben hier nur einegrobe Zusammenfassung Im Wesentlichen verfolgen wir jeden Punkt x isin Ω uumlber die Zeit ∆t entlangw1 zuruumlck Dadurch entsteht ein Pfad p (x t) von x zu einem Punkt x0 = p (xminus∆t) der auch alsStromlinie interpretiert werden kann Dies wird in Abbildung 23 verdeutlicht

Abbildung 23 Weg den ein Fluidpartikel in der Zeit zuruumlcklegt (vgl [Stam])

Wir setzen dann die neue Geschwindigkeit w2 im Punkt x als die Geschwindigkeit die im Punkt x0 zurvorherigen Zeit vorliegt also

w2 (x) = w1 (p (xminus∆t)) = w1 (xminus∆tw1 (x)) (210)

Durch das Verwenden der Methode der Charakteristiken liefert unser Vorgehen eine fuumlr beliebig groszligeZeitschrittweiten und Geschwindigkeiten unbedingt stabile numerische Loumlsung (vgl [Stam]) Das koumln-nen wir daran feststellen dass der maximale Wert des Geschwindigkeitsfeldes in diesem Schritt niegroumlszliger als im vorherigen Zeitschritt werden kann auszliger wir praumlgen eine externe Kraft auf Denn nachGleichung (210) gilt

max(w2

(l))le max

(w1

(l))

(29)= max

(w0

(l) + ∆tf (l))

f (l)equiv0= max

(w4

(lminus1))

wobei ()(l) die entsprechende Groumlszlige im l-ten Zeitschritt bezeichnet Es ist f (l) equiv 0 da wir hier keineAnwender-Interaktion beruumlcksichtigenFuumlr Details zur Implementierung der Methode der Charakteristiken verweisen wir auf Kapitel 31

KAPITEL 2 THEORETISCHE GRUNDLAGEN 10

DiffusionHier betrachten wir eine Gleichung der Form

partu

partt= νnabla middot nablau (211)

Um diese numerisch zu loumlsen diskretisieren wir zunaumlchst den Laplace-Operatornabla middotnabla mit finiten Diffe-renzen im Ort und wenden dann ein Zeitschrittverfahren an Die Anwendung vonnablamiddotnabla auf das Geschwin-digkeitsfeld u erfolgt komponentenweise in x- beziehungsweise y-Richtung weshalb wir vereinfachenddie Diskretisierung des Operators angewendet auf ein hinreichend glattes Skalarfeld s betrachten Wirstellen also die Diskretisierung vonnabla middot nablas = part2s

partx2+ part2s

party2im R2 auf Dann gilt

(nabla middot nablas)ij asympsi+1j minus 2sij + siminus1j

h2+sij+1 minus 2sij + sijminus1

h2(212)

mit sij = s (xij) und analog (nabla middot nablas)ij = nabla middot nablas (xij) fuumlr xij isin Ωh Betrachten wir das durchGleichung (212) diskretisierte Skalarfeld s in jedem Gitterpunkt koumlnnen wir den diskretisierten Laplace-Operator als Matrix auffassen welche die folgende Gestalt aufweist

1

h2

Bn In

In In

In Bn

mit Bn =

minus4 1

1 1

1 minus4

isin Rntimesn (213)

Hierbei bezeichnet In die Einheitsmatrix der Dimension ntimesn Wenden wir auf die im Ort diskretisierteGleichung (211) ein explizites Zeitschrittverfahren der Form

u (x t+ ∆t) = u (x t) + ν∆tnabla middot nablau (x t) (214)

an so tritt erneut das Problem der Instabilitaumlt fuumlr groszlige Zeitschrittweiten ∆t beziehungsweise groszligekinematische Viskositaumlten ν auf Diese Schwierigkeit taucht auf da die Methode einem expliziten Euler-Verfahren entspricht und daher aumlhnliche Eigenschaften bezuumlglich der Stabilitaumlt aufweist Um eine stabileLoumlsungsmethode zu konstruieren verwenden wir statt des in Gleichung (214) angefuumlhrten ein implizitesVerfahren was sich durch Uumlbertragen auf unsere Schreibweise innerhalb eines Zeitschrittes schreibenlaumlsst als

(Iminus ν∆tnabla middot nabla)w3 = w2 (215)

wobei I den Identitaumltsoperator darstellt Diese Gleichung entspricht einer Poisson-Gleichung fuumlr dasGeschwindigkeitsfeld w3 Setzen wir den diskretisierten Laplace-Operator aus Gleichung (213) in Glei-chung (215) ein so ergibt sich die Darstellung fuumlr die Systemmatrix des zu loumlsenden Gleichungssystemsals

ν∆t

h2

Bn minusInminusIn

minusInminusIn Bn

mit Bn =

4 + h2

ν∆t minus1

minus1 minus1

minus1 4 + h2

ν∆t

(216)

Das daraus resultierende Gleichungssystem muumlssen wir nun effizient loumlsen worauf wir in Kapitel 31eingehen

KAPITEL 2 THEORETISCHE GRUNDLAGEN 11

ProjektionIm Projektionsschritt betrachten wir Gleichung (24) und erhalten wie im Diffusionsschritt eine Poisson-Gleichung zur Berechnung des Druckfeldes p Auch hier ergibt sich durch die Diskretisierung vonnablamiddotnablaein duumlnn besetztes lineares Gleichungssystem mit rechter Seite nabla middot w3 welches wir loumlsen muumlssen umals Abschluss unseres Algorithmus die aktualisierte Geschwindigkeit uumlber die Gleichung

u (x t+ ∆t) = w4 = w3 minusnablap (217)

berechnen zu koumlnnen Dazu verwenden wir folgende Diskretisierungen der auftretenden Operatoren

(nablas)ij =

(parts

partxparts

party

)ij

asymp(si+1j minus siminus1j

2hsij+1 minus sijminus1

2h

)(218)

(nabla middot v)ij =

(partvx

partx+partvy

party

)ij

asymp

(vxi+1j minus vximinus1j

2h+vyij+1 minus v

yijminus1

2h

) (219)

wobei s erneut ein Skalarfeld und v = (vx vy) ein zweidimensionales Vektorfeld mit x- und y-Komponentebezeichnet Analog zu der Schreibweise in Gleichung (212) repraumlsentieren ()ij die entsprechendenGroumlszligen ausgewertet im Punkt xij isin Ωh

Nun sind wir in der Lage im naumlchsten Zeitschritt das Geschwindigkeitsfeld zu berechnen und schlieszligensomit die Diskretisierung der Navier-Stokes Gleichungen (21) und (22) ab Dazu fassen wir die wesent-lichen Ergebnisse dieses Unterkapitels in algorithmischer Form zusammen Wir orientieren uns dabei anden in Schema (28) angefuumlhrten Schritten und erhalten so ein kompaktes numerisches Loumlsungsverfahrender Navier-Stokes Gleichungen

Algorithmus 241 (bdquoStable Fluidsldquo Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen nach[Stam])Sei ein initiales Geschwindigkeitsfeld w0

(0) (x) = u (x 0) gegebenFuumlr l = 1 L

1 Kraft aufpraumlgen w1(l) (x) = w0

(lminus1) (x) + ∆tf (l) (x)

2 Advektion w2(l) (x) = w1

(l)(xminus∆tw1

(l) (x))

3 Diffusion bestimme w3(l) uumlber (Iminus ν∆tnabla middot nabla)w3

(l) = w2(l)

4 Projektion w4(l) = w3

(l) minusnablap(l) wobei sich p(l) ergibt aus nabla middot nablap(l) = nabla middotw3(l)

5 Aktualisierung w0(l) (x) = u (x l middot∆t) = w4

(l) (x)

Die Anzahl L + 1 der durchzufuumlhrenden Zeitschritte legen wir dadurch fest wie lange wir die Simu-lation ausfuumlhren Das Kraftfeld f (l) wird durch den Anwender von auszligen bestimmt und steht in jedemZeitschritt aktualisiert zur Verfuumlgung Die genaue Umsetzung der Schritte in Algorithmus 241 stellenwir in Kapitel 3 vor

Kapitel 3

Implementierung

Nachdem wir in Kapitel 2 auf die in unserer Simulation verwendete Theorie bezuumlglich Modell Dis-kretisierung und numerischer Loumlsung eingegangen sind wollen wir uns nun ihrer Umsetzung und derRealisierung der Visualisierung und Interaktion auf einem Tablet-Computer widmen Die Stroumlmungs-simulation fuumlhren wir auf dem Asus EeePad Transformer TF101 auf dem das Betriebssystem Android403 installiert ist in einer App aus Details zur Hardware des verwendeten Tablet-Computers findensich in Kapitel 44 Der Anwender hat waumlhrend der Simulation die Moumlglichkeit die Stroumlmung einesFluids durch Beruumlhren des Bildschirms zu beeinflussen Stroumlmungssimulationen wie sie etwa bei [Stam]oder [Harris] beschrieben werden koumlnnen vom Nutzer durch Interaktion mit der Maus beeinflusst wer-den auf einem Tablet-Computer besteht jedoch die Moumlglichkeit dies mit einem Finger auf dem Bild-schirm durchzufuumlhren Dadurch wirkt die Simulation fuumlr den Betrachter realer Die Moumlglichkeit solcheComputer zur Stroumlmungssimulation einzusetzen wird dadurch eroumlffnet dass Tablet-Computer hinsicht-lich ihrer Rechenleistung immer leistungsfaumlhiger werdenBevor wir auf die konkrete Implementierung des in Kapitel 2 vorgestellten Verfahrens eingehen wollenwir zunaumlchst das Vorgehen bei einer App-Programmierung in der Programmiersprache Java fuumlr das An-droid-Betriebssystem erlaumlutern wobei wir uns an [Android Developer] orientieren Zunaumlchst installierenwir eine Software-Entwicklungsumgebung wie etwa Eclipse1 in der wir die eigentliche Programmie-rung durchfuumlhren Ergaumlnzend benoumltigen wir das Android Software Development Kit sowie die AndroidDevelopment Tools die wir in die Entwicklungsumgebung einbinden muumlssen Anschlieszligend koumlnnen wirein neues Android App Project erstellen welches die App repraumlsentiert Dabei werden einige Dateienautomatisch erstellt wie etwa die Manifest-Datei die eine zentrale Rolle einnimmt da sie die funda-mentalen Charakteristiken der App beschreibt und jede ihrer Komponenten definiert Die Programmie-rung einer App unterscheidet sich vor allem dadurch von einer bdquogewoumlhnlichenldquo Java-Programmierungals dass zum korrekten Erstellen der App viele spezielle Funktionen vom System verlangt werden diewir implementieren muumlssen Auch die Umsetzung der Visualisierung mit Hilfe der OpenGL ES 20-Bibliothek verlangt ein gesondertes Vorgehen Wir muumlssen die Visualisierung in eine eigene Klasse aus-lagern diese entsprechend kennzeichnen und erneut vom System verlangte Funktionen integrieren Aumlhn-lich verhaumllt es sich bei der Beruumlcksichtigung der Anwender-InteraktionUm eine App schlieszliglich auszufuumlhren bestehen zwei Moumlglichkeiten Einerseits koumlnnen wir die App aufeinem externen Android-Geraumlt starten zum Beispiel einem Tablet-Computer andererseits den Emula-tor nutzen Dabei handelt es sich um eine sogenannte Android Virtual Device die auf dem Computerausgefuumlhrt wird auf dem sich die Entwicklungsumgebung befindet Die Virtual Device entspricht ei-nem externen Geraumlt welches auf dem Computer simuliert wird Es empfiehlt sich die App zunaumlchstim Emulator zu testen da bei eventuellen Programmierfehlern das externe Geraumlt durch Uumlberhitzungoder aumlhnliches beschaumldigt werden kann Bisher ist es nicht moumlglich Apps auf dem Emulator zu tes-ten die sich der Bibliothek OpenGL ES 20 zur Darstellung von Grafiken bedienen wie wir sie fuumlr

1Fuumlr naumlhere Informationen verweisen wir auf httpwwweclipseorg

12

KAPITEL 2 THEORETISCHE GRUNDLAGEN 8

waumlhrend der Berechnung nur von der Ortsvariablen x ab Das Vektorfeld w4 entspricht schlieszliglich demGeschwindigkeitsfeld u zum Zeitpunkt t+∆t also u (x t+ ∆t) mit der Zeitschrittweite ∆t isin R+ DieSimulation erhalten wir letztendlich durch Iteration der in Schema (28) beschriebenen Vorgehensweiseuumlber die Zeitschritte Daraus ergibt sich durch Diskretisierung der auftretenden Operatoren ein nume-risches Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen (21) und (22) worauf wir im naumlchstenAbschnitt eingehen

24 Diskretisierung und numerische Loumlsung

Wir erlaumlutern in diesem Abschnitt die in Schema (28) angefuumlhrten Schritte und stellen Diskretisierungs-beziehungsweise Loumlsungstechniken vor um abschlieszligend ein kompaktes Loumlsungsverfahren der Navier-Stokes Gleichungen aufzustellen Zur Diskretisierung aller auftretenden Operatoren verwenden wir indieser Arbeit meist finite Differenzen zweiter Ordnung Approximationen abweichender Ordnung sindbeispielsweise bei der Behandlung von Randbedingungen noumltig auf die wir in Abschnitt 314 naumlhereingehenWie in Abschnitt 23 bereits erwaumlhnt diskretisieren wir das durch die Navier-Stokes Gleichungen (21)und (22) und Anfangs- sowie Randbedingungen gestellte Problem zuerst in der Zeit und anschlieszligendim Ort Dazu waumlhlen wir eine aumlquidistante Zerlegung des Zeitintervalls in L Teilintervalle der Form

I = [0 T ] =

L⋃l=1

[t(lminus1) t(l)

]

wobei t(l) = l middot∆t und T = L middot∆t gilt Die folgenden Diskretisierungen im Ort fuumlhren wir nun jeweilszu einem festen Zeitpunkt t(l) durch weshalb die auftretenden Groumlszligen zeitunabhaumlngig sindFuumlr unsere Simulation betrachten wir das quadratische Rechengebiet Ω = [minus1 1]2 sub R2 in dem sichdas Fluid befinden soll Davon ausgehend definieren wir ein diskretes Gebiet Ωh mit Schrittweite h isin Rdie wir sowohl in x- als auch in y-Richtung zur Diskretisierung verwenden Dadurch ergibt sich Ωh alsein Gitter fuumlr das xij isin Ωh die Form xij = (minus1 + ihminus1 + jh) hat wobei i j isin 0 n minus 1gilt und n isin N die Anzahl der Gitterpunkte pro Zeile beziehungsweise Spalte im Gitter angibt ImFolgenden betrachten wir nur die Operationen innerhalb eines Zeitschrittes das heiszligt im Uumlbergang vont(l) nach t(l) + ∆t Dazu sei w0 wie oben als bekanntes Geschwindigkeitsfeld u

(x t(l)

)definiert und

wk k isin 1 2 3 4 bezeichnet die unterschiedlichen Geschwindigkeitsfelder innerhalb des ZeitschrittsNach diesen Vorbereitungen widmen wir uns nun Diskretisierungs- und Loumlsungsmethoden fuumlr die ein-zelnen Bestandteile von Gleichung (27) beziehungsweise Schema (28)

Kraft aufpraumlgenZuerst kann dem Fluid eine Kraft aufgepraumlgt werden Dies geschieht waumlhrend der Simulation durch denAnwender und soll nur ein Mal pro Zeitschritt erfolgen Deshalb koumlnnen wir die Annahme treffen dassdie Kraft uumlber den gesamten Zeitschritt konstant ist Somit ist eine Beruumlcksichtigung der Kraft zu Beginneines jeden Zeitschritts ausreichend Wir berechnen also im ersten Schritt unseres Loumlsers

w1 = w0 + ∆tf (29)

was eine gute Approximation der Wirkung der Kraft uumlber den Zeitschritt darstellt da wir ihren Einflussdurch die Multiplikation des Kraftfeldes f mit der Zeitschrittweite ∆t uumlber den ganzen Zeitschritt trans-portieren

KAPITEL 2 THEORETISCHE GRUNDLAGEN 9

AdvektionUm die Advektion des Fluids zu beruumlcksichtigen fassen wir die Gitterpunkte als die oben beschriebenenTeilchen beziehungsweise Fluidpartikel auf und muumlssen dann in jedem Zeitschritt die Geschwindigkeiteines solchen Partikels aktualisierenEine erste Idee waumlre es hierzu folgende explizite Methode zu betrachten Die Position r eines Partikelsveraumlndert sich mit der Geschwindigkeit also koumlnnen wir die Position so weit verschieben wie sich dasPartikel in der Zeit ∆t mit seiner Geschwindigkeit fortbewegt Also gilt

r(t(l) + ∆t

)= r

(t(l))

+ ∆tu(t(l))

was dem expliziten Eulerverfahren entspricht Allerdings ist diese Methode instabil fuumlr groszlige Zeitschritt-weitenWir betrachten deshalb die implizite Methode der Charakteristiken die die Stabilitaumlt des Verfahrens im-pliziert Zur genaueren Erlaumluterung dieses Verfahrens verweisen wir auf [Stam] und geben hier nur einegrobe Zusammenfassung Im Wesentlichen verfolgen wir jeden Punkt x isin Ω uumlber die Zeit ∆t entlangw1 zuruumlck Dadurch entsteht ein Pfad p (x t) von x zu einem Punkt x0 = p (xminus∆t) der auch alsStromlinie interpretiert werden kann Dies wird in Abbildung 23 verdeutlicht

Abbildung 23 Weg den ein Fluidpartikel in der Zeit zuruumlcklegt (vgl [Stam])

Wir setzen dann die neue Geschwindigkeit w2 im Punkt x als die Geschwindigkeit die im Punkt x0 zurvorherigen Zeit vorliegt also

w2 (x) = w1 (p (xminus∆t)) = w1 (xminus∆tw1 (x)) (210)

Durch das Verwenden der Methode der Charakteristiken liefert unser Vorgehen eine fuumlr beliebig groszligeZeitschrittweiten und Geschwindigkeiten unbedingt stabile numerische Loumlsung (vgl [Stam]) Das koumln-nen wir daran feststellen dass der maximale Wert des Geschwindigkeitsfeldes in diesem Schritt niegroumlszliger als im vorherigen Zeitschritt werden kann auszliger wir praumlgen eine externe Kraft auf Denn nachGleichung (210) gilt

max(w2

(l))le max

(w1

(l))

(29)= max

(w0

(l) + ∆tf (l))

f (l)equiv0= max

(w4

(lminus1))

wobei ()(l) die entsprechende Groumlszlige im l-ten Zeitschritt bezeichnet Es ist f (l) equiv 0 da wir hier keineAnwender-Interaktion beruumlcksichtigenFuumlr Details zur Implementierung der Methode der Charakteristiken verweisen wir auf Kapitel 31

KAPITEL 2 THEORETISCHE GRUNDLAGEN 10

DiffusionHier betrachten wir eine Gleichung der Form

partu

partt= νnabla middot nablau (211)

Um diese numerisch zu loumlsen diskretisieren wir zunaumlchst den Laplace-Operatornabla middotnabla mit finiten Diffe-renzen im Ort und wenden dann ein Zeitschrittverfahren an Die Anwendung vonnablamiddotnabla auf das Geschwin-digkeitsfeld u erfolgt komponentenweise in x- beziehungsweise y-Richtung weshalb wir vereinfachenddie Diskretisierung des Operators angewendet auf ein hinreichend glattes Skalarfeld s betrachten Wirstellen also die Diskretisierung vonnabla middot nablas = part2s

partx2+ part2s

party2im R2 auf Dann gilt

(nabla middot nablas)ij asympsi+1j minus 2sij + siminus1j

h2+sij+1 minus 2sij + sijminus1

h2(212)

mit sij = s (xij) und analog (nabla middot nablas)ij = nabla middot nablas (xij) fuumlr xij isin Ωh Betrachten wir das durchGleichung (212) diskretisierte Skalarfeld s in jedem Gitterpunkt koumlnnen wir den diskretisierten Laplace-Operator als Matrix auffassen welche die folgende Gestalt aufweist

1

h2

Bn In

In In

In Bn

mit Bn =

minus4 1

1 1

1 minus4

isin Rntimesn (213)

Hierbei bezeichnet In die Einheitsmatrix der Dimension ntimesn Wenden wir auf die im Ort diskretisierteGleichung (211) ein explizites Zeitschrittverfahren der Form

u (x t+ ∆t) = u (x t) + ν∆tnabla middot nablau (x t) (214)

an so tritt erneut das Problem der Instabilitaumlt fuumlr groszlige Zeitschrittweiten ∆t beziehungsweise groszligekinematische Viskositaumlten ν auf Diese Schwierigkeit taucht auf da die Methode einem expliziten Euler-Verfahren entspricht und daher aumlhnliche Eigenschaften bezuumlglich der Stabilitaumlt aufweist Um eine stabileLoumlsungsmethode zu konstruieren verwenden wir statt des in Gleichung (214) angefuumlhrten ein implizitesVerfahren was sich durch Uumlbertragen auf unsere Schreibweise innerhalb eines Zeitschrittes schreibenlaumlsst als

(Iminus ν∆tnabla middot nabla)w3 = w2 (215)

wobei I den Identitaumltsoperator darstellt Diese Gleichung entspricht einer Poisson-Gleichung fuumlr dasGeschwindigkeitsfeld w3 Setzen wir den diskretisierten Laplace-Operator aus Gleichung (213) in Glei-chung (215) ein so ergibt sich die Darstellung fuumlr die Systemmatrix des zu loumlsenden Gleichungssystemsals

ν∆t

h2

Bn minusInminusIn

minusInminusIn Bn

mit Bn =

4 + h2

ν∆t minus1

minus1 minus1

minus1 4 + h2

ν∆t

(216)

Das daraus resultierende Gleichungssystem muumlssen wir nun effizient loumlsen worauf wir in Kapitel 31eingehen

KAPITEL 2 THEORETISCHE GRUNDLAGEN 11

ProjektionIm Projektionsschritt betrachten wir Gleichung (24) und erhalten wie im Diffusionsschritt eine Poisson-Gleichung zur Berechnung des Druckfeldes p Auch hier ergibt sich durch die Diskretisierung vonnablamiddotnablaein duumlnn besetztes lineares Gleichungssystem mit rechter Seite nabla middot w3 welches wir loumlsen muumlssen umals Abschluss unseres Algorithmus die aktualisierte Geschwindigkeit uumlber die Gleichung

u (x t+ ∆t) = w4 = w3 minusnablap (217)

berechnen zu koumlnnen Dazu verwenden wir folgende Diskretisierungen der auftretenden Operatoren

(nablas)ij =

(parts

partxparts

party

)ij

asymp(si+1j minus siminus1j

2hsij+1 minus sijminus1

2h

)(218)

(nabla middot v)ij =

(partvx

partx+partvy

party

)ij

asymp

(vxi+1j minus vximinus1j

2h+vyij+1 minus v

yijminus1

2h

) (219)

wobei s erneut ein Skalarfeld und v = (vx vy) ein zweidimensionales Vektorfeld mit x- und y-Komponentebezeichnet Analog zu der Schreibweise in Gleichung (212) repraumlsentieren ()ij die entsprechendenGroumlszligen ausgewertet im Punkt xij isin Ωh

Nun sind wir in der Lage im naumlchsten Zeitschritt das Geschwindigkeitsfeld zu berechnen und schlieszligensomit die Diskretisierung der Navier-Stokes Gleichungen (21) und (22) ab Dazu fassen wir die wesent-lichen Ergebnisse dieses Unterkapitels in algorithmischer Form zusammen Wir orientieren uns dabei anden in Schema (28) angefuumlhrten Schritten und erhalten so ein kompaktes numerisches Loumlsungsverfahrender Navier-Stokes Gleichungen

Algorithmus 241 (bdquoStable Fluidsldquo Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen nach[Stam])Sei ein initiales Geschwindigkeitsfeld w0

(0) (x) = u (x 0) gegebenFuumlr l = 1 L

1 Kraft aufpraumlgen w1(l) (x) = w0

(lminus1) (x) + ∆tf (l) (x)

2 Advektion w2(l) (x) = w1

(l)(xminus∆tw1

(l) (x))

3 Diffusion bestimme w3(l) uumlber (Iminus ν∆tnabla middot nabla)w3

(l) = w2(l)

4 Projektion w4(l) = w3

(l) minusnablap(l) wobei sich p(l) ergibt aus nabla middot nablap(l) = nabla middotw3(l)

5 Aktualisierung w0(l) (x) = u (x l middot∆t) = w4

(l) (x)

Die Anzahl L + 1 der durchzufuumlhrenden Zeitschritte legen wir dadurch fest wie lange wir die Simu-lation ausfuumlhren Das Kraftfeld f (l) wird durch den Anwender von auszligen bestimmt und steht in jedemZeitschritt aktualisiert zur Verfuumlgung Die genaue Umsetzung der Schritte in Algorithmus 241 stellenwir in Kapitel 3 vor

Kapitel 3

Implementierung

Nachdem wir in Kapitel 2 auf die in unserer Simulation verwendete Theorie bezuumlglich Modell Dis-kretisierung und numerischer Loumlsung eingegangen sind wollen wir uns nun ihrer Umsetzung und derRealisierung der Visualisierung und Interaktion auf einem Tablet-Computer widmen Die Stroumlmungs-simulation fuumlhren wir auf dem Asus EeePad Transformer TF101 auf dem das Betriebssystem Android403 installiert ist in einer App aus Details zur Hardware des verwendeten Tablet-Computers findensich in Kapitel 44 Der Anwender hat waumlhrend der Simulation die Moumlglichkeit die Stroumlmung einesFluids durch Beruumlhren des Bildschirms zu beeinflussen Stroumlmungssimulationen wie sie etwa bei [Stam]oder [Harris] beschrieben werden koumlnnen vom Nutzer durch Interaktion mit der Maus beeinflusst wer-den auf einem Tablet-Computer besteht jedoch die Moumlglichkeit dies mit einem Finger auf dem Bild-schirm durchzufuumlhren Dadurch wirkt die Simulation fuumlr den Betrachter realer Die Moumlglichkeit solcheComputer zur Stroumlmungssimulation einzusetzen wird dadurch eroumlffnet dass Tablet-Computer hinsicht-lich ihrer Rechenleistung immer leistungsfaumlhiger werdenBevor wir auf die konkrete Implementierung des in Kapitel 2 vorgestellten Verfahrens eingehen wollenwir zunaumlchst das Vorgehen bei einer App-Programmierung in der Programmiersprache Java fuumlr das An-droid-Betriebssystem erlaumlutern wobei wir uns an [Android Developer] orientieren Zunaumlchst installierenwir eine Software-Entwicklungsumgebung wie etwa Eclipse1 in der wir die eigentliche Programmie-rung durchfuumlhren Ergaumlnzend benoumltigen wir das Android Software Development Kit sowie die AndroidDevelopment Tools die wir in die Entwicklungsumgebung einbinden muumlssen Anschlieszligend koumlnnen wirein neues Android App Project erstellen welches die App repraumlsentiert Dabei werden einige Dateienautomatisch erstellt wie etwa die Manifest-Datei die eine zentrale Rolle einnimmt da sie die funda-mentalen Charakteristiken der App beschreibt und jede ihrer Komponenten definiert Die Programmie-rung einer App unterscheidet sich vor allem dadurch von einer bdquogewoumlhnlichenldquo Java-Programmierungals dass zum korrekten Erstellen der App viele spezielle Funktionen vom System verlangt werden diewir implementieren muumlssen Auch die Umsetzung der Visualisierung mit Hilfe der OpenGL ES 20-Bibliothek verlangt ein gesondertes Vorgehen Wir muumlssen die Visualisierung in eine eigene Klasse aus-lagern diese entsprechend kennzeichnen und erneut vom System verlangte Funktionen integrieren Aumlhn-lich verhaumllt es sich bei der Beruumlcksichtigung der Anwender-InteraktionUm eine App schlieszliglich auszufuumlhren bestehen zwei Moumlglichkeiten Einerseits koumlnnen wir die App aufeinem externen Android-Geraumlt starten zum Beispiel einem Tablet-Computer andererseits den Emula-tor nutzen Dabei handelt es sich um eine sogenannte Android Virtual Device die auf dem Computerausgefuumlhrt wird auf dem sich die Entwicklungsumgebung befindet Die Virtual Device entspricht ei-nem externen Geraumlt welches auf dem Computer simuliert wird Es empfiehlt sich die App zunaumlchstim Emulator zu testen da bei eventuellen Programmierfehlern das externe Geraumlt durch Uumlberhitzungoder aumlhnliches beschaumldigt werden kann Bisher ist es nicht moumlglich Apps auf dem Emulator zu tes-ten die sich der Bibliothek OpenGL ES 20 zur Darstellung von Grafiken bedienen wie wir sie fuumlr

1Fuumlr naumlhere Informationen verweisen wir auf httpwwweclipseorg

12

KAPITEL 2 THEORETISCHE GRUNDLAGEN 9

AdvektionUm die Advektion des Fluids zu beruumlcksichtigen fassen wir die Gitterpunkte als die oben beschriebenenTeilchen beziehungsweise Fluidpartikel auf und muumlssen dann in jedem Zeitschritt die Geschwindigkeiteines solchen Partikels aktualisierenEine erste Idee waumlre es hierzu folgende explizite Methode zu betrachten Die Position r eines Partikelsveraumlndert sich mit der Geschwindigkeit also koumlnnen wir die Position so weit verschieben wie sich dasPartikel in der Zeit ∆t mit seiner Geschwindigkeit fortbewegt Also gilt

r(t(l) + ∆t

)= r

(t(l))

+ ∆tu(t(l))

was dem expliziten Eulerverfahren entspricht Allerdings ist diese Methode instabil fuumlr groszlige Zeitschritt-weitenWir betrachten deshalb die implizite Methode der Charakteristiken die die Stabilitaumlt des Verfahrens im-pliziert Zur genaueren Erlaumluterung dieses Verfahrens verweisen wir auf [Stam] und geben hier nur einegrobe Zusammenfassung Im Wesentlichen verfolgen wir jeden Punkt x isin Ω uumlber die Zeit ∆t entlangw1 zuruumlck Dadurch entsteht ein Pfad p (x t) von x zu einem Punkt x0 = p (xminus∆t) der auch alsStromlinie interpretiert werden kann Dies wird in Abbildung 23 verdeutlicht

Abbildung 23 Weg den ein Fluidpartikel in der Zeit zuruumlcklegt (vgl [Stam])

Wir setzen dann die neue Geschwindigkeit w2 im Punkt x als die Geschwindigkeit die im Punkt x0 zurvorherigen Zeit vorliegt also

w2 (x) = w1 (p (xminus∆t)) = w1 (xminus∆tw1 (x)) (210)

Durch das Verwenden der Methode der Charakteristiken liefert unser Vorgehen eine fuumlr beliebig groszligeZeitschrittweiten und Geschwindigkeiten unbedingt stabile numerische Loumlsung (vgl [Stam]) Das koumln-nen wir daran feststellen dass der maximale Wert des Geschwindigkeitsfeldes in diesem Schritt niegroumlszliger als im vorherigen Zeitschritt werden kann auszliger wir praumlgen eine externe Kraft auf Denn nachGleichung (210) gilt

max(w2

(l))le max

(w1

(l))

(29)= max

(w0

(l) + ∆tf (l))

f (l)equiv0= max

(w4

(lminus1))

wobei ()(l) die entsprechende Groumlszlige im l-ten Zeitschritt bezeichnet Es ist f (l) equiv 0 da wir hier keineAnwender-Interaktion beruumlcksichtigenFuumlr Details zur Implementierung der Methode der Charakteristiken verweisen wir auf Kapitel 31

KAPITEL 2 THEORETISCHE GRUNDLAGEN 10

DiffusionHier betrachten wir eine Gleichung der Form

partu

partt= νnabla middot nablau (211)

Um diese numerisch zu loumlsen diskretisieren wir zunaumlchst den Laplace-Operatornabla middotnabla mit finiten Diffe-renzen im Ort und wenden dann ein Zeitschrittverfahren an Die Anwendung vonnablamiddotnabla auf das Geschwin-digkeitsfeld u erfolgt komponentenweise in x- beziehungsweise y-Richtung weshalb wir vereinfachenddie Diskretisierung des Operators angewendet auf ein hinreichend glattes Skalarfeld s betrachten Wirstellen also die Diskretisierung vonnabla middot nablas = part2s

partx2+ part2s

party2im R2 auf Dann gilt

(nabla middot nablas)ij asympsi+1j minus 2sij + siminus1j

h2+sij+1 minus 2sij + sijminus1

h2(212)

mit sij = s (xij) und analog (nabla middot nablas)ij = nabla middot nablas (xij) fuumlr xij isin Ωh Betrachten wir das durchGleichung (212) diskretisierte Skalarfeld s in jedem Gitterpunkt koumlnnen wir den diskretisierten Laplace-Operator als Matrix auffassen welche die folgende Gestalt aufweist

1

h2

Bn In

In In

In Bn

mit Bn =

minus4 1

1 1

1 minus4

isin Rntimesn (213)

Hierbei bezeichnet In die Einheitsmatrix der Dimension ntimesn Wenden wir auf die im Ort diskretisierteGleichung (211) ein explizites Zeitschrittverfahren der Form

u (x t+ ∆t) = u (x t) + ν∆tnabla middot nablau (x t) (214)

an so tritt erneut das Problem der Instabilitaumlt fuumlr groszlige Zeitschrittweiten ∆t beziehungsweise groszligekinematische Viskositaumlten ν auf Diese Schwierigkeit taucht auf da die Methode einem expliziten Euler-Verfahren entspricht und daher aumlhnliche Eigenschaften bezuumlglich der Stabilitaumlt aufweist Um eine stabileLoumlsungsmethode zu konstruieren verwenden wir statt des in Gleichung (214) angefuumlhrten ein implizitesVerfahren was sich durch Uumlbertragen auf unsere Schreibweise innerhalb eines Zeitschrittes schreibenlaumlsst als

(Iminus ν∆tnabla middot nabla)w3 = w2 (215)

wobei I den Identitaumltsoperator darstellt Diese Gleichung entspricht einer Poisson-Gleichung fuumlr dasGeschwindigkeitsfeld w3 Setzen wir den diskretisierten Laplace-Operator aus Gleichung (213) in Glei-chung (215) ein so ergibt sich die Darstellung fuumlr die Systemmatrix des zu loumlsenden Gleichungssystemsals

ν∆t

h2

Bn minusInminusIn

minusInminusIn Bn

mit Bn =

4 + h2

ν∆t minus1

minus1 minus1

minus1 4 + h2

ν∆t

(216)

Das daraus resultierende Gleichungssystem muumlssen wir nun effizient loumlsen worauf wir in Kapitel 31eingehen

KAPITEL 2 THEORETISCHE GRUNDLAGEN 11

ProjektionIm Projektionsschritt betrachten wir Gleichung (24) und erhalten wie im Diffusionsschritt eine Poisson-Gleichung zur Berechnung des Druckfeldes p Auch hier ergibt sich durch die Diskretisierung vonnablamiddotnablaein duumlnn besetztes lineares Gleichungssystem mit rechter Seite nabla middot w3 welches wir loumlsen muumlssen umals Abschluss unseres Algorithmus die aktualisierte Geschwindigkeit uumlber die Gleichung

u (x t+ ∆t) = w4 = w3 minusnablap (217)

berechnen zu koumlnnen Dazu verwenden wir folgende Diskretisierungen der auftretenden Operatoren

(nablas)ij =

(parts

partxparts

party

)ij

asymp(si+1j minus siminus1j

2hsij+1 minus sijminus1

2h

)(218)

(nabla middot v)ij =

(partvx

partx+partvy

party

)ij

asymp

(vxi+1j minus vximinus1j

2h+vyij+1 minus v

yijminus1

2h

) (219)

wobei s erneut ein Skalarfeld und v = (vx vy) ein zweidimensionales Vektorfeld mit x- und y-Komponentebezeichnet Analog zu der Schreibweise in Gleichung (212) repraumlsentieren ()ij die entsprechendenGroumlszligen ausgewertet im Punkt xij isin Ωh

Nun sind wir in der Lage im naumlchsten Zeitschritt das Geschwindigkeitsfeld zu berechnen und schlieszligensomit die Diskretisierung der Navier-Stokes Gleichungen (21) und (22) ab Dazu fassen wir die wesent-lichen Ergebnisse dieses Unterkapitels in algorithmischer Form zusammen Wir orientieren uns dabei anden in Schema (28) angefuumlhrten Schritten und erhalten so ein kompaktes numerisches Loumlsungsverfahrender Navier-Stokes Gleichungen

Algorithmus 241 (bdquoStable Fluidsldquo Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen nach[Stam])Sei ein initiales Geschwindigkeitsfeld w0

(0) (x) = u (x 0) gegebenFuumlr l = 1 L

1 Kraft aufpraumlgen w1(l) (x) = w0

(lminus1) (x) + ∆tf (l) (x)

2 Advektion w2(l) (x) = w1

(l)(xminus∆tw1

(l) (x))

3 Diffusion bestimme w3(l) uumlber (Iminus ν∆tnabla middot nabla)w3

(l) = w2(l)

4 Projektion w4(l) = w3

(l) minusnablap(l) wobei sich p(l) ergibt aus nabla middot nablap(l) = nabla middotw3(l)

5 Aktualisierung w0(l) (x) = u (x l middot∆t) = w4

(l) (x)

Die Anzahl L + 1 der durchzufuumlhrenden Zeitschritte legen wir dadurch fest wie lange wir die Simu-lation ausfuumlhren Das Kraftfeld f (l) wird durch den Anwender von auszligen bestimmt und steht in jedemZeitschritt aktualisiert zur Verfuumlgung Die genaue Umsetzung der Schritte in Algorithmus 241 stellenwir in Kapitel 3 vor

Kapitel 3

Implementierung

Nachdem wir in Kapitel 2 auf die in unserer Simulation verwendete Theorie bezuumlglich Modell Dis-kretisierung und numerischer Loumlsung eingegangen sind wollen wir uns nun ihrer Umsetzung und derRealisierung der Visualisierung und Interaktion auf einem Tablet-Computer widmen Die Stroumlmungs-simulation fuumlhren wir auf dem Asus EeePad Transformer TF101 auf dem das Betriebssystem Android403 installiert ist in einer App aus Details zur Hardware des verwendeten Tablet-Computers findensich in Kapitel 44 Der Anwender hat waumlhrend der Simulation die Moumlglichkeit die Stroumlmung einesFluids durch Beruumlhren des Bildschirms zu beeinflussen Stroumlmungssimulationen wie sie etwa bei [Stam]oder [Harris] beschrieben werden koumlnnen vom Nutzer durch Interaktion mit der Maus beeinflusst wer-den auf einem Tablet-Computer besteht jedoch die Moumlglichkeit dies mit einem Finger auf dem Bild-schirm durchzufuumlhren Dadurch wirkt die Simulation fuumlr den Betrachter realer Die Moumlglichkeit solcheComputer zur Stroumlmungssimulation einzusetzen wird dadurch eroumlffnet dass Tablet-Computer hinsicht-lich ihrer Rechenleistung immer leistungsfaumlhiger werdenBevor wir auf die konkrete Implementierung des in Kapitel 2 vorgestellten Verfahrens eingehen wollenwir zunaumlchst das Vorgehen bei einer App-Programmierung in der Programmiersprache Java fuumlr das An-droid-Betriebssystem erlaumlutern wobei wir uns an [Android Developer] orientieren Zunaumlchst installierenwir eine Software-Entwicklungsumgebung wie etwa Eclipse1 in der wir die eigentliche Programmie-rung durchfuumlhren Ergaumlnzend benoumltigen wir das Android Software Development Kit sowie die AndroidDevelopment Tools die wir in die Entwicklungsumgebung einbinden muumlssen Anschlieszligend koumlnnen wirein neues Android App Project erstellen welches die App repraumlsentiert Dabei werden einige Dateienautomatisch erstellt wie etwa die Manifest-Datei die eine zentrale Rolle einnimmt da sie die funda-mentalen Charakteristiken der App beschreibt und jede ihrer Komponenten definiert Die Programmie-rung einer App unterscheidet sich vor allem dadurch von einer bdquogewoumlhnlichenldquo Java-Programmierungals dass zum korrekten Erstellen der App viele spezielle Funktionen vom System verlangt werden diewir implementieren muumlssen Auch die Umsetzung der Visualisierung mit Hilfe der OpenGL ES 20-Bibliothek verlangt ein gesondertes Vorgehen Wir muumlssen die Visualisierung in eine eigene Klasse aus-lagern diese entsprechend kennzeichnen und erneut vom System verlangte Funktionen integrieren Aumlhn-lich verhaumllt es sich bei der Beruumlcksichtigung der Anwender-InteraktionUm eine App schlieszliglich auszufuumlhren bestehen zwei Moumlglichkeiten Einerseits koumlnnen wir die App aufeinem externen Android-Geraumlt starten zum Beispiel einem Tablet-Computer andererseits den Emula-tor nutzen Dabei handelt es sich um eine sogenannte Android Virtual Device die auf dem Computerausgefuumlhrt wird auf dem sich die Entwicklungsumgebung befindet Die Virtual Device entspricht ei-nem externen Geraumlt welches auf dem Computer simuliert wird Es empfiehlt sich die App zunaumlchstim Emulator zu testen da bei eventuellen Programmierfehlern das externe Geraumlt durch Uumlberhitzungoder aumlhnliches beschaumldigt werden kann Bisher ist es nicht moumlglich Apps auf dem Emulator zu tes-ten die sich der Bibliothek OpenGL ES 20 zur Darstellung von Grafiken bedienen wie wir sie fuumlr

1Fuumlr naumlhere Informationen verweisen wir auf httpwwweclipseorg

12

KAPITEL 2 THEORETISCHE GRUNDLAGEN 10

DiffusionHier betrachten wir eine Gleichung der Form

partu

partt= νnabla middot nablau (211)

Um diese numerisch zu loumlsen diskretisieren wir zunaumlchst den Laplace-Operatornabla middotnabla mit finiten Diffe-renzen im Ort und wenden dann ein Zeitschrittverfahren an Die Anwendung vonnablamiddotnabla auf das Geschwin-digkeitsfeld u erfolgt komponentenweise in x- beziehungsweise y-Richtung weshalb wir vereinfachenddie Diskretisierung des Operators angewendet auf ein hinreichend glattes Skalarfeld s betrachten Wirstellen also die Diskretisierung vonnabla middot nablas = part2s

partx2+ part2s

party2im R2 auf Dann gilt

(nabla middot nablas)ij asympsi+1j minus 2sij + siminus1j

h2+sij+1 minus 2sij + sijminus1

h2(212)

mit sij = s (xij) und analog (nabla middot nablas)ij = nabla middot nablas (xij) fuumlr xij isin Ωh Betrachten wir das durchGleichung (212) diskretisierte Skalarfeld s in jedem Gitterpunkt koumlnnen wir den diskretisierten Laplace-Operator als Matrix auffassen welche die folgende Gestalt aufweist

1

h2

Bn In

In In

In Bn

mit Bn =

minus4 1

1 1

1 minus4

isin Rntimesn (213)

Hierbei bezeichnet In die Einheitsmatrix der Dimension ntimesn Wenden wir auf die im Ort diskretisierteGleichung (211) ein explizites Zeitschrittverfahren der Form

u (x t+ ∆t) = u (x t) + ν∆tnabla middot nablau (x t) (214)

an so tritt erneut das Problem der Instabilitaumlt fuumlr groszlige Zeitschrittweiten ∆t beziehungsweise groszligekinematische Viskositaumlten ν auf Diese Schwierigkeit taucht auf da die Methode einem expliziten Euler-Verfahren entspricht und daher aumlhnliche Eigenschaften bezuumlglich der Stabilitaumlt aufweist Um eine stabileLoumlsungsmethode zu konstruieren verwenden wir statt des in Gleichung (214) angefuumlhrten ein implizitesVerfahren was sich durch Uumlbertragen auf unsere Schreibweise innerhalb eines Zeitschrittes schreibenlaumlsst als

(Iminus ν∆tnabla middot nabla)w3 = w2 (215)

wobei I den Identitaumltsoperator darstellt Diese Gleichung entspricht einer Poisson-Gleichung fuumlr dasGeschwindigkeitsfeld w3 Setzen wir den diskretisierten Laplace-Operator aus Gleichung (213) in Glei-chung (215) ein so ergibt sich die Darstellung fuumlr die Systemmatrix des zu loumlsenden Gleichungssystemsals

ν∆t

h2

Bn minusInminusIn

minusInminusIn Bn

mit Bn =

4 + h2

ν∆t minus1

minus1 minus1

minus1 4 + h2

ν∆t

(216)

Das daraus resultierende Gleichungssystem muumlssen wir nun effizient loumlsen worauf wir in Kapitel 31eingehen

KAPITEL 2 THEORETISCHE GRUNDLAGEN 11

ProjektionIm Projektionsschritt betrachten wir Gleichung (24) und erhalten wie im Diffusionsschritt eine Poisson-Gleichung zur Berechnung des Druckfeldes p Auch hier ergibt sich durch die Diskretisierung vonnablamiddotnablaein duumlnn besetztes lineares Gleichungssystem mit rechter Seite nabla middot w3 welches wir loumlsen muumlssen umals Abschluss unseres Algorithmus die aktualisierte Geschwindigkeit uumlber die Gleichung

u (x t+ ∆t) = w4 = w3 minusnablap (217)

berechnen zu koumlnnen Dazu verwenden wir folgende Diskretisierungen der auftretenden Operatoren

(nablas)ij =

(parts

partxparts

party

)ij

asymp(si+1j minus siminus1j

2hsij+1 minus sijminus1

2h

)(218)

(nabla middot v)ij =

(partvx

partx+partvy

party

)ij

asymp

(vxi+1j minus vximinus1j

2h+vyij+1 minus v

yijminus1

2h

) (219)

wobei s erneut ein Skalarfeld und v = (vx vy) ein zweidimensionales Vektorfeld mit x- und y-Komponentebezeichnet Analog zu der Schreibweise in Gleichung (212) repraumlsentieren ()ij die entsprechendenGroumlszligen ausgewertet im Punkt xij isin Ωh

Nun sind wir in der Lage im naumlchsten Zeitschritt das Geschwindigkeitsfeld zu berechnen und schlieszligensomit die Diskretisierung der Navier-Stokes Gleichungen (21) und (22) ab Dazu fassen wir die wesent-lichen Ergebnisse dieses Unterkapitels in algorithmischer Form zusammen Wir orientieren uns dabei anden in Schema (28) angefuumlhrten Schritten und erhalten so ein kompaktes numerisches Loumlsungsverfahrender Navier-Stokes Gleichungen

Algorithmus 241 (bdquoStable Fluidsldquo Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen nach[Stam])Sei ein initiales Geschwindigkeitsfeld w0

(0) (x) = u (x 0) gegebenFuumlr l = 1 L

1 Kraft aufpraumlgen w1(l) (x) = w0

(lminus1) (x) + ∆tf (l) (x)

2 Advektion w2(l) (x) = w1

(l)(xminus∆tw1

(l) (x))

3 Diffusion bestimme w3(l) uumlber (Iminus ν∆tnabla middot nabla)w3

(l) = w2(l)

4 Projektion w4(l) = w3

(l) minusnablap(l) wobei sich p(l) ergibt aus nabla middot nablap(l) = nabla middotw3(l)

5 Aktualisierung w0(l) (x) = u (x l middot∆t) = w4

(l) (x)

Die Anzahl L + 1 der durchzufuumlhrenden Zeitschritte legen wir dadurch fest wie lange wir die Simu-lation ausfuumlhren Das Kraftfeld f (l) wird durch den Anwender von auszligen bestimmt und steht in jedemZeitschritt aktualisiert zur Verfuumlgung Die genaue Umsetzung der Schritte in Algorithmus 241 stellenwir in Kapitel 3 vor

Kapitel 3

Implementierung

Nachdem wir in Kapitel 2 auf die in unserer Simulation verwendete Theorie bezuumlglich Modell Dis-kretisierung und numerischer Loumlsung eingegangen sind wollen wir uns nun ihrer Umsetzung und derRealisierung der Visualisierung und Interaktion auf einem Tablet-Computer widmen Die Stroumlmungs-simulation fuumlhren wir auf dem Asus EeePad Transformer TF101 auf dem das Betriebssystem Android403 installiert ist in einer App aus Details zur Hardware des verwendeten Tablet-Computers findensich in Kapitel 44 Der Anwender hat waumlhrend der Simulation die Moumlglichkeit die Stroumlmung einesFluids durch Beruumlhren des Bildschirms zu beeinflussen Stroumlmungssimulationen wie sie etwa bei [Stam]oder [Harris] beschrieben werden koumlnnen vom Nutzer durch Interaktion mit der Maus beeinflusst wer-den auf einem Tablet-Computer besteht jedoch die Moumlglichkeit dies mit einem Finger auf dem Bild-schirm durchzufuumlhren Dadurch wirkt die Simulation fuumlr den Betrachter realer Die Moumlglichkeit solcheComputer zur Stroumlmungssimulation einzusetzen wird dadurch eroumlffnet dass Tablet-Computer hinsicht-lich ihrer Rechenleistung immer leistungsfaumlhiger werdenBevor wir auf die konkrete Implementierung des in Kapitel 2 vorgestellten Verfahrens eingehen wollenwir zunaumlchst das Vorgehen bei einer App-Programmierung in der Programmiersprache Java fuumlr das An-droid-Betriebssystem erlaumlutern wobei wir uns an [Android Developer] orientieren Zunaumlchst installierenwir eine Software-Entwicklungsumgebung wie etwa Eclipse1 in der wir die eigentliche Programmie-rung durchfuumlhren Ergaumlnzend benoumltigen wir das Android Software Development Kit sowie die AndroidDevelopment Tools die wir in die Entwicklungsumgebung einbinden muumlssen Anschlieszligend koumlnnen wirein neues Android App Project erstellen welches die App repraumlsentiert Dabei werden einige Dateienautomatisch erstellt wie etwa die Manifest-Datei die eine zentrale Rolle einnimmt da sie die funda-mentalen Charakteristiken der App beschreibt und jede ihrer Komponenten definiert Die Programmie-rung einer App unterscheidet sich vor allem dadurch von einer bdquogewoumlhnlichenldquo Java-Programmierungals dass zum korrekten Erstellen der App viele spezielle Funktionen vom System verlangt werden diewir implementieren muumlssen Auch die Umsetzung der Visualisierung mit Hilfe der OpenGL ES 20-Bibliothek verlangt ein gesondertes Vorgehen Wir muumlssen die Visualisierung in eine eigene Klasse aus-lagern diese entsprechend kennzeichnen und erneut vom System verlangte Funktionen integrieren Aumlhn-lich verhaumllt es sich bei der Beruumlcksichtigung der Anwender-InteraktionUm eine App schlieszliglich auszufuumlhren bestehen zwei Moumlglichkeiten Einerseits koumlnnen wir die App aufeinem externen Android-Geraumlt starten zum Beispiel einem Tablet-Computer andererseits den Emula-tor nutzen Dabei handelt es sich um eine sogenannte Android Virtual Device die auf dem Computerausgefuumlhrt wird auf dem sich die Entwicklungsumgebung befindet Die Virtual Device entspricht ei-nem externen Geraumlt welches auf dem Computer simuliert wird Es empfiehlt sich die App zunaumlchstim Emulator zu testen da bei eventuellen Programmierfehlern das externe Geraumlt durch Uumlberhitzungoder aumlhnliches beschaumldigt werden kann Bisher ist es nicht moumlglich Apps auf dem Emulator zu tes-ten die sich der Bibliothek OpenGL ES 20 zur Darstellung von Grafiken bedienen wie wir sie fuumlr

1Fuumlr naumlhere Informationen verweisen wir auf httpwwweclipseorg

12

KAPITEL 2 THEORETISCHE GRUNDLAGEN 11

ProjektionIm Projektionsschritt betrachten wir Gleichung (24) und erhalten wie im Diffusionsschritt eine Poisson-Gleichung zur Berechnung des Druckfeldes p Auch hier ergibt sich durch die Diskretisierung vonnablamiddotnablaein duumlnn besetztes lineares Gleichungssystem mit rechter Seite nabla middot w3 welches wir loumlsen muumlssen umals Abschluss unseres Algorithmus die aktualisierte Geschwindigkeit uumlber die Gleichung

u (x t+ ∆t) = w4 = w3 minusnablap (217)

berechnen zu koumlnnen Dazu verwenden wir folgende Diskretisierungen der auftretenden Operatoren

(nablas)ij =

(parts

partxparts

party

)ij

asymp(si+1j minus siminus1j

2hsij+1 minus sijminus1

2h

)(218)

(nabla middot v)ij =

(partvx

partx+partvy

party

)ij

asymp

(vxi+1j minus vximinus1j

2h+vyij+1 minus v

yijminus1

2h

) (219)

wobei s erneut ein Skalarfeld und v = (vx vy) ein zweidimensionales Vektorfeld mit x- und y-Komponentebezeichnet Analog zu der Schreibweise in Gleichung (212) repraumlsentieren ()ij die entsprechendenGroumlszligen ausgewertet im Punkt xij isin Ωh

Nun sind wir in der Lage im naumlchsten Zeitschritt das Geschwindigkeitsfeld zu berechnen und schlieszligensomit die Diskretisierung der Navier-Stokes Gleichungen (21) und (22) ab Dazu fassen wir die wesent-lichen Ergebnisse dieses Unterkapitels in algorithmischer Form zusammen Wir orientieren uns dabei anden in Schema (28) angefuumlhrten Schritten und erhalten so ein kompaktes numerisches Loumlsungsverfahrender Navier-Stokes Gleichungen

Algorithmus 241 (bdquoStable Fluidsldquo Loumlsungsverfahren fuumlr die Navier-Stokes Gleichungen nach[Stam])Sei ein initiales Geschwindigkeitsfeld w0

(0) (x) = u (x 0) gegebenFuumlr l = 1 L

1 Kraft aufpraumlgen w1(l) (x) = w0

(lminus1) (x) + ∆tf (l) (x)

2 Advektion w2(l) (x) = w1

(l)(xminus∆tw1

(l) (x))

3 Diffusion bestimme w3(l) uumlber (Iminus ν∆tnabla middot nabla)w3

(l) = w2(l)

4 Projektion w4(l) = w3

(l) minusnablap(l) wobei sich p(l) ergibt aus nabla middot nablap(l) = nabla middotw3(l)

5 Aktualisierung w0(l) (x) = u (x l middot∆t) = w4

(l) (x)

Die Anzahl L + 1 der durchzufuumlhrenden Zeitschritte legen wir dadurch fest wie lange wir die Simu-lation ausfuumlhren Das Kraftfeld f (l) wird durch den Anwender von auszligen bestimmt und steht in jedemZeitschritt aktualisiert zur Verfuumlgung Die genaue Umsetzung der Schritte in Algorithmus 241 stellenwir in Kapitel 3 vor

Kapitel 3

Implementierung

Nachdem wir in Kapitel 2 auf die in unserer Simulation verwendete Theorie bezuumlglich Modell Dis-kretisierung und numerischer Loumlsung eingegangen sind wollen wir uns nun ihrer Umsetzung und derRealisierung der Visualisierung und Interaktion auf einem Tablet-Computer widmen Die Stroumlmungs-simulation fuumlhren wir auf dem Asus EeePad Transformer TF101 auf dem das Betriebssystem Android403 installiert ist in einer App aus Details zur Hardware des verwendeten Tablet-Computers findensich in Kapitel 44 Der Anwender hat waumlhrend der Simulation die Moumlglichkeit die Stroumlmung einesFluids durch Beruumlhren des Bildschirms zu beeinflussen Stroumlmungssimulationen wie sie etwa bei [Stam]oder [Harris] beschrieben werden koumlnnen vom Nutzer durch Interaktion mit der Maus beeinflusst wer-den auf einem Tablet-Computer besteht jedoch die Moumlglichkeit dies mit einem Finger auf dem Bild-schirm durchzufuumlhren Dadurch wirkt die Simulation fuumlr den Betrachter realer Die Moumlglichkeit solcheComputer zur Stroumlmungssimulation einzusetzen wird dadurch eroumlffnet dass Tablet-Computer hinsicht-lich ihrer Rechenleistung immer leistungsfaumlhiger werdenBevor wir auf die konkrete Implementierung des in Kapitel 2 vorgestellten Verfahrens eingehen wollenwir zunaumlchst das Vorgehen bei einer App-Programmierung in der Programmiersprache Java fuumlr das An-droid-Betriebssystem erlaumlutern wobei wir uns an [Android Developer] orientieren Zunaumlchst installierenwir eine Software-Entwicklungsumgebung wie etwa Eclipse1 in der wir die eigentliche Programmie-rung durchfuumlhren Ergaumlnzend benoumltigen wir das Android Software Development Kit sowie die AndroidDevelopment Tools die wir in die Entwicklungsumgebung einbinden muumlssen Anschlieszligend koumlnnen wirein neues Android App Project erstellen welches die App repraumlsentiert Dabei werden einige Dateienautomatisch erstellt wie etwa die Manifest-Datei die eine zentrale Rolle einnimmt da sie die funda-mentalen Charakteristiken der App beschreibt und jede ihrer Komponenten definiert Die Programmie-rung einer App unterscheidet sich vor allem dadurch von einer bdquogewoumlhnlichenldquo Java-Programmierungals dass zum korrekten Erstellen der App viele spezielle Funktionen vom System verlangt werden diewir implementieren muumlssen Auch die Umsetzung der Visualisierung mit Hilfe der OpenGL ES 20-Bibliothek verlangt ein gesondertes Vorgehen Wir muumlssen die Visualisierung in eine eigene Klasse aus-lagern diese entsprechend kennzeichnen und erneut vom System verlangte Funktionen integrieren Aumlhn-lich verhaumllt es sich bei der Beruumlcksichtigung der Anwender-InteraktionUm eine App schlieszliglich auszufuumlhren bestehen zwei Moumlglichkeiten Einerseits koumlnnen wir die App aufeinem externen Android-Geraumlt starten zum Beispiel einem Tablet-Computer andererseits den Emula-tor nutzen Dabei handelt es sich um eine sogenannte Android Virtual Device die auf dem Computerausgefuumlhrt wird auf dem sich die Entwicklungsumgebung befindet Die Virtual Device entspricht ei-nem externen Geraumlt welches auf dem Computer simuliert wird Es empfiehlt sich die App zunaumlchstim Emulator zu testen da bei eventuellen Programmierfehlern das externe Geraumlt durch Uumlberhitzungoder aumlhnliches beschaumldigt werden kann Bisher ist es nicht moumlglich Apps auf dem Emulator zu tes-ten die sich der Bibliothek OpenGL ES 20 zur Darstellung von Grafiken bedienen wie wir sie fuumlr

1Fuumlr naumlhere Informationen verweisen wir auf httpwwweclipseorg

12

Kapitel 3

Implementierung

Nachdem wir in Kapitel 2 auf die in unserer Simulation verwendete Theorie bezuumlglich Modell Dis-kretisierung und numerischer Loumlsung eingegangen sind wollen wir uns nun ihrer Umsetzung und derRealisierung der Visualisierung und Interaktion auf einem Tablet-Computer widmen Die Stroumlmungs-simulation fuumlhren wir auf dem Asus EeePad Transformer TF101 auf dem das Betriebssystem Android403 installiert ist in einer App aus Details zur Hardware des verwendeten Tablet-Computers findensich in Kapitel 44 Der Anwender hat waumlhrend der Simulation die Moumlglichkeit die Stroumlmung einesFluids durch Beruumlhren des Bildschirms zu beeinflussen Stroumlmungssimulationen wie sie etwa bei [Stam]oder [Harris] beschrieben werden koumlnnen vom Nutzer durch Interaktion mit der Maus beeinflusst wer-den auf einem Tablet-Computer besteht jedoch die Moumlglichkeit dies mit einem Finger auf dem Bild-schirm durchzufuumlhren Dadurch wirkt die Simulation fuumlr den Betrachter realer Die Moumlglichkeit solcheComputer zur Stroumlmungssimulation einzusetzen wird dadurch eroumlffnet dass Tablet-Computer hinsicht-lich ihrer Rechenleistung immer leistungsfaumlhiger werdenBevor wir auf die konkrete Implementierung des in Kapitel 2 vorgestellten Verfahrens eingehen wollenwir zunaumlchst das Vorgehen bei einer App-Programmierung in der Programmiersprache Java fuumlr das An-droid-Betriebssystem erlaumlutern wobei wir uns an [Android Developer] orientieren Zunaumlchst installierenwir eine Software-Entwicklungsumgebung wie etwa Eclipse1 in der wir die eigentliche Programmie-rung durchfuumlhren Ergaumlnzend benoumltigen wir das Android Software Development Kit sowie die AndroidDevelopment Tools die wir in die Entwicklungsumgebung einbinden muumlssen Anschlieszligend koumlnnen wirein neues Android App Project erstellen welches die App repraumlsentiert Dabei werden einige Dateienautomatisch erstellt wie etwa die Manifest-Datei die eine zentrale Rolle einnimmt da sie die funda-mentalen Charakteristiken der App beschreibt und jede ihrer Komponenten definiert Die Programmie-rung einer App unterscheidet sich vor allem dadurch von einer bdquogewoumlhnlichenldquo Java-Programmierungals dass zum korrekten Erstellen der App viele spezielle Funktionen vom System verlangt werden diewir implementieren muumlssen Auch die Umsetzung der Visualisierung mit Hilfe der OpenGL ES 20-Bibliothek verlangt ein gesondertes Vorgehen Wir muumlssen die Visualisierung in eine eigene Klasse aus-lagern diese entsprechend kennzeichnen und erneut vom System verlangte Funktionen integrieren Aumlhn-lich verhaumllt es sich bei der Beruumlcksichtigung der Anwender-InteraktionUm eine App schlieszliglich auszufuumlhren bestehen zwei Moumlglichkeiten Einerseits koumlnnen wir die App aufeinem externen Android-Geraumlt starten zum Beispiel einem Tablet-Computer andererseits den Emula-tor nutzen Dabei handelt es sich um eine sogenannte Android Virtual Device die auf dem Computerausgefuumlhrt wird auf dem sich die Entwicklungsumgebung befindet Die Virtual Device entspricht ei-nem externen Geraumlt welches auf dem Computer simuliert wird Es empfiehlt sich die App zunaumlchstim Emulator zu testen da bei eventuellen Programmierfehlern das externe Geraumlt durch Uumlberhitzungoder aumlhnliches beschaumldigt werden kann Bisher ist es nicht moumlglich Apps auf dem Emulator zu tes-ten die sich der Bibliothek OpenGL ES 20 zur Darstellung von Grafiken bedienen wie wir sie fuumlr

1Fuumlr naumlhere Informationen verweisen wir auf httpwwweclipseorg

12

KAPITEL 3 IMPLEMENTIERUNG 13

die Fluidsimulation nutzen So koumlnnen wir nur Apps ausfuumlhren die eine reine Textausgabe verwendenDennoch spielt der Emulator eine zentrale Rolle fuumlr die Erstellung einer apk-Datei welche dem kom-pilierten Programm entspricht Wir muumlssen diese Datei auf dem Tablet-Computer zur Ausfuumlhrung derApp installieren Sobald wir eine App uumlber den Emulator starten wird die zugehoumlrige apk-Datei er-stellt die wir via USB-Stick oder Email auf den Tablet-Computer transferieren und installieren koumlnnenAnschlieszligend koumlnnen wir die App ausfuumlhren Das hier beschriebene Vorgehen zur Entwicklung einerApp macht deutlich dass sich die App-Programmierung in einigen Punkten signifikant von der uumlblichenProgrammierung in Java (oder einer anderen Programmiersprache) unterscheidet was nicht zuletzt ander Verwendung von externen Geraumlten wie Smartphones oder Tablet-Computern liegtIm Folgenden stellen wir unsere Implementierung vor und betrachten ihre wesentlichen Punkte im Detailwelche sich in drei Bereiche gliedern lassen den Loumlser die Visualisierung und die Anwender-InteraktionDie Groumlszligen die in diesen Bereichen variabel sind teilen sich in numerische und physikalische Parameterauf die Gitterschrittweite h die Zeitschrittweite ∆t die Anzahl maxiter der im linearen Loumlser fuumlr diePoisson-Probleme durchzufuumlhrenden Iterationen auf der einen und die bdquoRichtgeschwindigkeitldquo v0 diefuumlr einige Testfaumllle die wir in Kapitel 4 untersuchen relevant ist sowie die Viskositaumlt ν auf der anderenSeiteBetrachten wir also zuerst den Teil der Implementierung der das numerische Loumlsen der Navier-StokesGleichungen enthaumllt

31 Loumlser

In Kapitel 2 haben wir die Navier-Stokes Gleichungen hergeleitet und einen Weg beschrieben wie wirdiese numerisch loumlsen koumlnnen Den hierbei entwickelten Algorithmus 241 setzen wir in unserer App inder Funktion velocity um die uns in jedem Zeitschritt das aktuelle Geschwindigkeits- und Druckfeldliefert Die Schritte in Algorithmus 241 repraumlsentieren auch die Gliederung des Quellcodes des LoumlsersAlle Berechnungen fuumlhren wir dabei mit doppelter Genauigkeit durchWie in Abschnitt 24 beschrieben loumlsen wir die Navier-Stokes Gleichungen (21) und (22) auf einemdiskreten Gebiet Ωh = [minus1 1]2 welches sich durch die Wahl einer Gitterschrittweite h isin R ergibt Da-durch liegen insgesamt N =

(1h + 1

)2 Gitterpunkte vor In jedem dieser Punkte berechnen wir nun mitHilfe unseres Algorithmus die Geschwindigkeit in x- und y-Richtung Zur Speicherung der Ergebnissebenoumltigen wir also Datenarrays der Laumlnge 2N wobei wir in den erstenN Eintraumlgen die Geschwindigkeitin x- und in den restlichen die in y-Richtung speichern In den Zeitschritten resultiert das anfaumlnglicheGeschwindigkeitsfeld aus Randbedingungen und dem aktualisierten Geschwindigkeitsfeld aus dem vor-herigen Zeitschritt Zu Beginn liegt uns das initiale Geschwindigkeitsfeld w0 des Fluids vor das sich ausAnfangs- und Randbedingungen ergibtAumlhnlich wie in Kapitel 2 widmen wir uns nun den einzelnen Bestandteilen von Algorithmus 241 underlaumlutern ihre genaue Umsetzung in unserer Implementierung

311 Kraft aufpraumlgen

In einem Zeitschritt praumlgen wir dem Fluid eine Kraft force auf was in dem Schritt add force derFunktion velocity geschieht und dem ersten Schritt in Algorithmus 241 entspricht Das Aufprauml-gen der Kraft realisieren wir wie in Gleichung (29) angefuumlhrt durch ein einfaches Vektorupdate wasin Quellcode 31 angefuumlhrt ist Daraus ergibt sich ein neues Geschwindigkeitsfeld w1 das wir in denweiteren Berechnungen des Zeitschritts betrachten

Quellcode 31 Aufpraumlgen der Kraft

f o r ( i =0 i lt 2N i ++)w1 [ i ] = w0 [ i ] + d t lowast f o r c e [ i ]

KAPITEL 3 IMPLEMENTIERUNG 14

Das Aufpraumlgen einer Kraft geschieht durch Beruumlhren des Bildschirms durch den Anwender was wir inKapitel 33 genauer erlaumlutern Sollte keine Interaktion vom Anwender ausgehen ist jeder Eintrag imforce-Array Null und es wird keine externe Kraft aufgepraumlgt

312 Advektion

Im anschlieszligenden Schritt advect der den Einfluss der Advektion in die Simulation integriert und demzweiten Schritt in Algorithmus 241 entspricht verwenden wir einen Tracer um ein neues Geschwin-digkeitsfeld zu berechnen wie es in Abbildung 23 dargestellt ist Der Aufbau des Tracers ist nichttrivial weshalb wir genauer auf seine konkrete Umsetzung eingehen Das Ziel des Tracers ist es mitHilfe von Gleichung (210) eine neue Geschwindigkeit aus bereits zuvor berechneten Geschwindigkei-ten zu ermitteln Dazu betrachten wir die aktuelle Geschwindigkeit beispielsweise im Punkt x und gehen∆t middotw1 (x) im Ort zuruumlck Wir erhalten einen neuen Punkt X der jedoch nicht zwingend auf unseremGitter liegt was in der Abbildung 31 dargestellt ist

Abbildung 31 Zweidimensionales Rechengebiet mit Gitterpunkten und Geschwindigkeitsfeld

Wie in Gleichung (210) beschrieben wollen wir die Geschwindigkeit im Punkt X als neue Geschwin-digkeit des Ausgangspunkts x setzen Dies ist jedoch nicht moumlglich wenn X keinen Punkt unseresGitters Ωh darstellt Daher ist es notwendig die Punkte in unserem Gitter zu bestimmen welche Xumgeben Diese bezeichnen wir mit P0 P1 P2 und P3 Aus den Geschwindigkeiten in diesen vierPunkten berechnen wir eine Approximation der Geschwindigkeit w2 im Punkt X Dazu verwenden wireine bilineare Interpolation der Werte w1 (P0) w1 (P1) w1 (P2) und w1 (P3) Wir muumlssen jedochbeachten dass wir moumlglicherweise auf Gitterpunkte zugreifen die auszligerhalb unseres Rechengebiets Ωliegen Dies kann auftreten wenn die Strecke ∆t middotw1 (x) zu groszlig ist und wir das Gitter verlassen Wennwir zur Veranschaulichung Abbildung 31 heranziehen so wuumlrde die gruumlne Strecke auszligerhalb des Gittersenden Wir uumlberpruumlfen daher in jedem Schritt ob X = x minus∆t middotw1 (x) noch innerhalb unseres Gittersliegt Falls dies nicht der Fall ist setzen wir P0 P1 P2 und P3 als die Ecken des Teilquadrates desGitters das den kleinsten Abstand zu dem Punkt X auszligerhalb des Gitters aufweist

313 Diffusion

Der naumlchste Schritt in Algorithmus 241 ist der Diffusionsschritt der in der Funktion velocity demAbschnitt diffuse entspricht Hier haben wir uns das Ziel gesetzt das aus Gleichung (215) resultie-rende duumlnn besetzte Gleichungssystem effizient zu loumlsen Zur Vereinfachung der Implementierung loumlsenwir das System fuumlr die x- und y-Richtung separat was durch die komponentenweise Anwendung des

KAPITEL 3 IMPLEMENTIERUNG 15

Laplace-Operators auf ein Vektorfeld moumlglich ist (vgl Abschnitt 24) Wir ziehen daraus den Vorteildass wir fuumlr beide Systeme den gleichen Quellcode verwenden koumlnnen Somit erhalten wir die folgendenzwei Gleichungssysteme der Dimension N timesN

(Iminus ν∆tnabla middot nabla)w3xy = w2

xy (31)

Um diese Gleichungssysteme hardwareeffizient auf dem gegebenen kartesischen Pixelgitter zu loumlsenverwenden wir die sogenannte Stencil-Methode die wir im Folgenden erlaumlutern Dazu betrachten wirdie Diskretisierung des Laplace-Operators wie wir sie in Gleichung (212) beschreiben Das Skalarfelds muumlssen wir dabei entweder durch w3

x oder w3y ersetzen je nachdem welches Gleichungssystem

wir loumlsen wollen Ein erster Schritt besteht darin eine allgemeine Rechenvorschrift fuumlr die Anwen-dung des Jacobi-Loumlsers auf ein lineares Gleichungssystem zu finden Dazu multiplizieren wir die Ma-trix (216) mit dem unbekannten Loumlsungsvektor w3

xy Anschlieszligend loumlsen wir in dem zugehoumlrigen Glei-chungssystem zeilenweise nach (w3

xy)ij auf und skalieren die rechte Seite des Gleichungssystems mitdem entsprechenden Diagonaleintrag Das Vorgehen fuumlr die Beruumlcksichtigung der x- beziehungsweisey-Komponenten ist das gleiche da es sich in beiden Faumlllen um die gleiche Systemmatrix handelt Soerhalten wir die in Gleichung (32) angegebene allgemeine Rechenvorschrift fuumlr die Anwendung desJacobi-Loumlsers

q(k+1)ij =

q(k)iminus1j + q

(k)i+1j + q

(k)ijminus1j + q

(k)ij+1 + αrij

β(32)

Wir geben hier die allgemeine Form dieses Loumlsungsverfahrens in Abhaumlngigkeit der Variablen (q)ijund (r)ij an weil wir es im Diffusions- und im Projektionsschritt anwenden (vgl Gleichungen (24)und (211)) Im Diffusionsschritt repraumlsentiert (q)ij das Geschwindigkeitsfeld (w3

xy)ij und (r)ijdie rechte Seite (w2

xy)ij des Gleichungssystems ausgewertet im Punkt xij isin Ωh Die Konstanten

α β isin R haumlngen vom konkreten Gleichungssystem ab Im Diffusionsschritt ergeben sie sich zu α = h2

ν∆tund β = 4 + α Der Index k isin 0 maxiter gibt den aktuellen Iterationsschritt im Jacobi-Loumlseran Mit der Berechnungsvorschrift (32) koumlnnen wir jedoch nur die aktualisierten Werte fuumlr die innerenGitterpunkte bestimmen da die Matrix fuumlr die Randwerte eine andere Gestalt aufweist Um diese zubestimmen muumlssen wir die Randbedingungen verwenden Wir schreiben fuumlr die Geschwindigkeit bdquono-slipldquo-Randbedingungen vor (vgl Abschnitt 22) was bedeutet dass (w3

xy)ij = 0 forall xij isin partΩh giltMit Hilfe der Stencil-Methode ergibt sich eine Moumlglichkeit die auftretenden Gleichungssysteme effizientzu loumlsen Da die Koeffizienten α und β der Komponenten des Loumlsungsvektors bekannt und oftmals sogargleich sind muumlssen wir diese nicht fuumlr jeden Eintrag des Vektors explizit speichern Wir muumlssen da-bei beachten dass wir dieses Vorgehen nur anwenden koumlnnen wenn konstante Koeffizienten vorliegenDurch die Anwendung der Stencil-Methode sparen wir das Speichern einer ganzen Matrix zur Loumlsungdes Gleichungssystems was es uns ermoumlglicht das Gleichungssystem hardwareeffizient zu loumlsen

314 Projektion

Der abschlieszligende Schritt in Algorithmus aus 241 ist der Projektionsschritt project Hier muumlssenwir unter anderemnabla middotw3 = partw3

x

partx + partw3y

party berechnen Zur Diskretisierung der dabei auftretenden erstenAbleitungen koumlnnen wir die in Gleichung (219) angefuumlhrte Approximation nutzen Die diskretisierteDivergenz des Geschwindigkeitsfeldes w3 koumlnnen wir berechnen da der Wert des Feldes in jedem Git-terpunkt aus dem Diffusionsschritt bekannt ist Um die Divergenz an den Raumlndern zu berechnen bedarfes einseitiger Differenzenquotienten zweiter Ordnung da wir fuumlr den zentralen Differenzenquotientenin Normalenrichtung auf Punkte zugreifen muumlssten die auszligerhalb des Gitters liegen In den Eckenverwenden wir fuumlr beide Terme einseitige Differenzenquotienten Wir muumlssen in diesem Schritt des

KAPITEL 3 IMPLEMENTIERUNG 16

Algorithmus 241 die Poissongleichung (24) fuumlr das Druckfeld pmit der durch Gleichung (219) berech-neten rechten Seite loumlsen Durch die Diskretisierung mit finiten Differenzen erhalten wir wie im Diffusi-onsschritt ein lineares Gleichungssystem Dieses koumlnnen wir nun mit Hilfe der inGleichung (32) hergeleiteten Stencil-Methode fuumlr das Jacobi-Verfahren loumlsen Die Konstanten muumlssenwir dabei als α = minush2 und β = 4 waumlhlen Auch in diesem Fall koumlnnen wir so nur die Werte im In-neren des Gitters berechnen Um Werte an den Raumlndern zu erhalten muumlssen wir die Randbedingungenfuumlr den Druck beruumlcksichtigen (vgl Abschnitt 22) Wir gehen in unserem Fall davon aus dass fuumlr denDruck Neumann-Null-Randbedingungen gelten was bedeutet dass die Ableitung in Normalenrichtungam Rand verschwindet Dazu betrachten wir den einseitigen Differenzenquotienten erster Ordnung fuumlrdie erste Ableitung beispielhaft an einem Punkt des linken Randes (vgl Abbildung 32(b)) Stellen wirihn nach pij um erhalten wir

pprimeij =pij minus pi+1j

h

= 0hArr pij = pi+1j (33)

Es ergibt sich dass wir die Druckwerte am Rand des Gebiets als den Wert des Drucks im naumlchst innerenPunkt in negativer Normalenrichtung setzen In den Ecken des Gebiets definieren wir zunaumlchst sowohldie Ableitung in x- als auch in y-Richtung als Normalenableitung Deshalb setzen wir den Druck in denEckpunkten als Mittel der Druckwerte in den benachbarten RandpunktenUm den Projektionsschritt abzuschlieszligen verwenden wir zur Diskretisierung des Druckgradienten nablapdie in Gleichung (218) angefuumlhrte Diskretisierung Anschlieszligend koumlnnen wirnablap berechnen indem wirwie bei der Berechnung der Divergenz vorgehen Aus Gleichung (33) folgt dass wir den Gradienten anden Gebietskanten in Normalenrichtung zu Null setzen koumlnnen anstatt ihn uumlber einseitige Differenzen-quotienten zu approximieren In den Ecken schreiben wir sowohl fuumlr die Ableitung in x- als auch die iny-Richtung Null vorNachdem wir uns in diesem Abschnitt mit der Umsetzung von Algorithmus 241 beschaumlftigt habengehen wir in den folgenden Unterkapiteln auf spezielle Elemente der App-Programmierung ein Dazubetrachten wir zunaumlchst die Visualisierung der Simulation und widmen uns spaumlter der Realisierung derInteraktion

32 Visualisierung

Die Stroumlmungssimulation die wir in dieser Arbeit vorstellen entsteht durch das unterschiedliche Faumlrbenvon Punkten in unserem diskreten Gitter Durch die Aumlnderung dieser Faumlrbung in jedem Zeitschritt wirdder Eindruck erweckt dass das Fluid was sich in dem diskretisierten Rechengebiet befinden soll stroumlmtZur Visualisierung der Simulation benoumltigen wir somit zwei Komponenten die Darstellung des Rechen-gebiets auf dem Bildschirm und die spezielle Faumlrbung der Gitterpunkte gemaumlszlig der Geschwindigkeits-beziehungsweise DruckwerteBei der Umsetzung der Visualisierung haben wir uns an [Learn OpenGL ES] und [Android Developer]orientiert Wir erlaumlutern zunaumlchst wie wir das zweidimensionale Rechengebiet aufbauen und gehen an-schlieszligend auf das Faumlrben der Gitterpunkte ein Das Ausgangsobjekt zur Bildung des zweidimensionalenquadratischen Rechengebiets ist ein Dreieck Setzen wir mehrere rechtwinklige Dreiecke mit Kathetender Laumlnge h isin R die der Gitterschrittweite entspricht passend aneinander so koumlnnen wir ein beliebigesRechengebiet erzeugenDa wir jedoch nicht das Einheitsquadrat [0 1]2 sondern das Quadrat [minus1 1]2 als Rechengebiet verwen-den muumlssen wir uns dem Aufbau dieses Gebiets genauer widmen da die Kantenlaumlnge des QuadratsAuswirkungen auf die Wahl der Gitterschrittweite h hat Dazu betrachten wir zunaumlchst Abbildung 32in der wir sowohl das Einheitsquadrat als auch unser Rechengebiet [minus1 1]2 darstellen Schreiben wir fuumlrdas Einheitsquadrat in Abbildung 32(a) die Anzahl n der Stuumltzstellen vor so ergibt sich als Gitterschritt-weite hlowast = 1

nminus1 Betrachten wir nun das groszlige Quadrat in Abbildung 32(b) mit einer Seitenlaumlnge von

KAPITEL 3 IMPLEMENTIERUNG 17

2 und schreiben hier ebenfalls n als Anzahl der Stuumltzstellen vor so erhalten wir die Schrittweite durchh = 2hlowast = 2

nminus1 also eine doppelt so groszlige Schrittweite wie im Fall des Einheitsquadrats

(a) Einheitsquadrat (b) Rechengebiet

Abbildung 32 Quadrate zum Aufbau des Rechengebiets

Da wir in unserer Implementierung aufgrund des mittig auf dem Bildschirm gelegenen Koordinatenur-sprungs das groszlige Quadrat zur Diskretisierung nutzen muumlssen wir auch in allen Teilproblemen eineSchrittweite von h = 2hlowast verwendenIm Folgenden erlaumlutern wir wie wir das Gitter auf dem Bildschirm darstellen Zum Zeichnen nutzen wireine Standardfunktion von OpenGL ES 20 welche die Dreiecke die zur Visualisierung des Rechen-gebiets auf dem Bildschirm noumltig sind darstellt Diese Methode traumlgt den Namen drawArrays undverlangt neben der Eingabe der Positionsdaten der Gitterpunkte auch die Farbwerte fuumlr jeden Punkt diewir jeweils in einem Array speichern Um die Positionen der Gitterpunkte zu bestimmen muumlssen wir fuumlrjeden Punkt eine x- y- und z-Komponente angeben Die Positionsdaten legen wir im Konstruktor derKlasse fest da sie nur ein Mal gesetzt werden muumlssen und sich dann nicht mehr aumlndern weil im Laufeder Simulation die Gitterweite nicht variiert Es genuumlgt fuumlr die Koordinaten der Gitterpunkte nur dieersten beiden Komponenten zu beruumlcksichtigen und die z-Koordinate auf Null zu setzen weil wir unsauf einem zweidimensionalen Gebiet befinden

Abbildung 33 Vorgehen der drawArrays-Methode fuumlr h = 13

KAPITEL 3 IMPLEMENTIERUNG 18

Die drawArrays-Routine zeichnet die Gitterpunkte beziehungsweise die Dreiecke danach in der Rei-henfolge wie sie im Positionsarray auftauchen Also muumlssen wir die Daten im Positionsarray so anord-nen dass drei aufeinander folgende Punkte ein Dreieck bilden Zur Veranschaulichung betrachten wirAbbildung 33 Stellen wir die Punkte im Positionsarray ihrer Reihenfolge nach auf dem Bildschirm darso geben wir die meisten Knoten des Gitters mehrfach wieder Die Nummern an den Knoten geben anin welchem Schritt des Zeichnens der entsprechende Punkt abgebildet wird Wir koumlnnen ihnen entneh-men wie oft ein Gitterpunkt im Laufe des Gitteraufbaus gezeichnet wird Im oberen rechten Quadrat inAbbildung 33 stellen wir das Vorgehen der drawArrays-Methode anhand der roten Pfeile dar MitHilfe dieser Zeichenroutine haben wir also die Moumlglichkeit jeden Punkt in unserem Gitter durch einenEckpunkt eines Dreiecks darzustellenDie eigentliche Simulation des Fluidverhaltens erfolgt wie oben beschrieben durch die Farben diewir den Gitterpunkten zuordnen Im Gegensatz zum Positionsarray muumlssen wir die Faumlrbung in jedemZeitschritt aktualisieren um die Simulation zu ermoumlglichen Diese entsteht schlieszliglich dadurch dass wirnach jedem Zeitschritt das neu gefaumlrbte Gitter den neuen Frame zeichnen Zur Definition der Farbe eineseinzelnen Gitterpunktes benoumltigen wir dabei vier double-Eintraumlge die den Rot- Blau und Gruumlnanteilsowie den Transparenzkoeffizienten angeben Durch die Funktion colourSet die in Quellcode 32angefuumlhrt ist weisen wir dem Wert value im i-ten Gitterpunkt seine entsprechenden Farbwerte zuDie Groumlszlige value repraumlsentiert dabei die Geschwindigkeit des Fluids oder den Druck der auf das Fluidwirkt Die Farbwerte speichern wir danach im Array colour und uumlbertragen diesen anschlieszligend inden globalen Farbvektor Colours der die Farbe eines jeden Gitterpunktes genau ein Mal enthaumllt

Quellcode 32 Codeausschnitt aus der drawGrid-Methode

f o r ( i =0 i lt 4N i +=4)c o l o u r S e t ( double va lue double [ ] c o l o u r ) C o l o u r s [ i ] = c o l o u r [ 0 ] C o l o u r s [ i +1] = c o l o u r [ 1 ] C o l o u r s [ i +2] = c o l o u r [ 2 ] C o l o u r s [ i +3] = c o l o u r [ 3 ]

Das Faumlrben der Gitterpunkte erfolgt genau in der gleichen Reihenfolge wie das Zeichnen des GittersWie im Positionsarray muumlssen wir die Farbdaten im ColourData-Array so anordnen dass drei auf-einander folgende Punkte ein Dreieck bilden Es ist moumlglich die Gitterpunkte von verschiedenen Seitenunterschiedlich zu faumlrben da die zugewiesene Faumlrbung immer nur innerhalb eines Dreiecks gilt In Abbil-dung 33 koumlnnen wir einen inneren Gitterpunkt von sechs Seiten faumlrben da er an sechs Dreiecke grenztUm eine sinnvolle Faumlrbung des Gitters zu erhalten und Spruumlnge in dieser zu vermeiden muumlssen wir dieGitterpunkte von jeder Seite gleich faumlrben Dies realisieren wir im Quellcode durch eine for-Schleifein der wir in dem Farbarray ColourData an jede Stelle die den selben Gitterpunkt repraumlsentiert diezugehoumlrigen vier Eintraumlge aus dem Colours-Array schreiben Um die Gitterpunkte mit einer Farbe zuversehen die dem Wert der vorliegenden Groumlszlige entspricht verwenden wir eine sogenannte Heat MapIn unserem Fall greifen wir auf ein Spektrum von 19 Farben zuruumlck wobei blau gefaumlrbte Punkte sehrkleine Geschwindigkeiten beziehungsweise Druumlcke repraumlsentieren und rot gefaumlrbte entsprechend groszligeDie Faumlrbung einer Dreiecksflaumlche resultiert aus der Interpolation der Farben seiner Eckpunkte Die Wahlder genauen Uumlbergaumlnge zwischen den einzelnen Farben variiert von Testfall zu Testfall In Abschnitt 42bedienen wir uns einer nicht-aumlquidistanten Zerlegung des Farbspektrums und unterscheiden im Bereichder kleinen Druumlcke genauer da der Maximaldruck nur fuumlr eine sehr kurze Zeitspanne angenommen wirdund anschlieszligend lediglich kleine bis mittelgroszlige Druumlcke auftreten In Unterkapitel 412 verwenden wirhingegen eine aumlquidistante Unterteilung des FarbspektrumsUm dieses Kapitel zur Implementierung abzuschlieszligen erlaumlutern wir im folgenden Abschnitt die Umset-zung der Interaktion in unserer Software die den wesentlichen Bestandteil der interaktiven Stroumlmungs-simulation ausmacht

KAPITEL 3 IMPLEMENTIERUNG 19

33 Interaktion

Der Schritt der die Stroumlmungssimulation interaktiv werden laumlsst ist das Aufpraumlgen einer Kraft durchdas Beruumlhren des Bildschirms durch den Anwender Zunaumlchst gehen wir darauf ein wie wir die Finger-position auf dem Bildschirm in unser Gitter uumlbertragen und erlaumlutern anschlieszligend wie wir die Kraftermitteln die durch die Interaktion auf das simulierte Fluid uumlbertragen wirdDas zentrale Problem dem wir bei der Anwender-Interaktion gegenuumlberstehen ergibt sich aus den ver-schiedenen Zeichenebenen die in OpenGL ES 20 zur Verfuumlgung stehen um dreidimensionale Ob-jekte darzustellen Zur Veranschaulichung betrachten wir Abbildung 34

Abbildung 34 Visualisierungsraum von OpenGL ES 20 (vgl [SongHo])

Alle Objekte die wir mit OpenGL ES 20 darstellen speichern wir zuerst im dreidimensionalenRaum der Objekt-Koordinaten Anschlieszligend projizieren wir diese auf die zweidimensionale Benutzer-oberflaumlche den Bildschirm was die Darstellung dreidimensionaler Koumlrper ermoumlglicht Wir koumlnnen unsleicht uumlberlegen dass die Bildschirmkoordinaten nicht den Objektkoordinaten entsprechen Die Bild-schirmkoordinaten der Fingerposition die wir zur Realisierung der Simulation registrieren muumlssen ge-ben also nicht die Position des Fingers in dem Gitter des Rechengebiets an Diese benoumltigen wir jedochum an der richtigen Stelle eine Kraft auf das simulierte Fluid aufzupraumlgen Wir sind somit auf eineTransformation angewiesen die die Bildschirmkoordinaten des Fingers welche wir mittels einer Stan-dardfunktion von OpenGL ES 20 leicht auslesen koumlnnen auf die entsprechenden Objektkoordinatenabbildet Eine solche Transformation stellt die Funktion worldCoords dar bei deren Implementierungwir uns an [Verdia] orientiert haben Fuumlr weiterfuumlhrende Informationen bezuumlglich Bildschirm- und Ob-jektkoordinaten verweisen wir auf [SongHo]Um auf die Anwender-Interaktion reagieren zu koumlnnen verwenden wir die Methode onTouchEventwelche von OpenGL ES 20 bereitgestellt wird Dabei handelt es sich um eine sogenannte bdquoCallbackldquo-Funktion was bedeutet dass sie vom System automatisch aufgerufen wird Dies geschieht genau dannwenn der Nutzer den Bildschirm beruumlhrt Wie wir in Kapitel 44 sehen erfolgt die Simulation nichtin Echtzeit was sich vor allem mit der langen Rechenzeit des Loumlsers erklaumlren laumlsst Auf dem vonuns verwendeten Geraumlt steht uns eine CPU mit zwei Kernen beziehungsweise Threads zur VerfuumlgungAuf dem einen fuumlhren wir die Berechnungen aus und auf dem anderen die Visualisierung inklusiveder TouchEvent-Abfragen Aufgrund der oben beschriebenen Verzoumlgerung ist es moumlglich mehrereAufrufe der onTouchEvent-Routine pro Zeitschritt durchzufuumlhren also Abfragen nach sogenanntenTouchEvents Wir uumlberpruumlfen dabei ob der Anwender den Bildschirm beruumlhrt oder nicht Die Kon-sequenzen die dieses Vorgehen auf die Laufzeit der Simulation hat untersuchen wir in Abschnitt 443Pro Zeitschritt beruumlcksichtigen wir nur die Ergebnisse des ersten TouchEventsDie Behandlung von TouchEvents geschieht wie folgt Sollte der Bildschirm beruumlhrt werden wirddie Funktion onTouchEvent aufgerufen Zuerst lesen wir die Position des Fingers in Bildschirm-

KAPITEL 3 IMPLEMENTIERUNG 20

koordinaten mit Hilfe der Funktion getX beziehungsweise getY aus Danach transformieren wir siein Objektkoordinaten Aus der Position des Fingers im vorherigen Zeitschritt koumlnnen wir die Streckeermitteln die der Finger von einem Zeitschritt zum naumlchsten zuruumlckgelegt hat Daraus ergeben sichdann die Positionsaumlnderungen dx in x- und dy in y-Richtung Hierbei setzen wir nicht voraus dassdie Position in Objektkoordinaten einem Gitterpunkt entspricht Da wir eine Kraft jedoch nur in einemsolchen Gitterpunkt aufpraumlgen koumlnnen ermitteln wir den Knoten der am naumlchsten zu den Objektkoor-dinaten der Fingerposition liegt In diesem Punkt setzen wir dann die Kraft in x-Richtung als dx unddie in y-Richtung als dy wodurch gewaumlhrleistet ist dass wir bei schnellerer Bewegung des Fingersdem Fluid eine groumlszligere Kraft aufpraumlgen Das Aufpraumlgen der Kraft erfolgt nun durch Aumlnderungen derEintraumlge im force-Array die zu dem Gitterpunkt gehoumlren in dem die Kraft angreifen soll Mit Hilfevon if-Abfragen in der onTouchEvent-Methode stellen wir sicher dass ein TouchEvent nur dannberuumlcksichtigt wird wenn die Objektkoordinaten der Fingerposition innerhalb des Rechengebiets liegenZur Vorbereitung des naumlchsten Zeitschritts setzen wir am Ende des Loumlsers die zuvor veraumlnderten Eintraumlgeim force-Array wieder zu Null da eine Kraft nur innerhalb eines Zeitschritts wirken soll

34 Demonstration des Gesamtsystems

In den vorherigen Kapiteln haben wir ein Verfahren zur numerischen Loumlsung der Navier-Stokes Glei-chungen hergeleitet und dessen Umsetzung auf Tablet-Computern erlaumlutert Bevor wir in Kapitel 4 einegenauere Analyse der Implementierung durchfuumlhren wollen wir vorab einen ersten Eindruck der Simu-lation vermitteln Dazu stellen wir in Abbildung 35 eine Absolutgeschwindigkeitsverteilung im Fluiddar Die angefuumlhrten Bilder sind einem Video entnommen welches dieser Arbeit beiliegt

(a) initiale Geschwindigkeitsverteilung (b) leicht beeinflusste Stroumlmung

(c) schnelle Anwender-Interaktion (d) langsame Anwender-Interaktion

Abbildung 35 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 3 IMPLEMENTIERUNG 21

Wir betrachten hier das Szenario in dem an der oberen Kante des Rechengebiets permanent eine vonNull verschiedene Geschwindigkeit angetragen ist In der unteren linken Ecke des Gebiets befindet sicheine Druckspitze Erlaumluterungen zu diesen Rand- beziehungsweise Anfangsbedingungen finden sich imfolgenden Kapitel Auszligerdem erfolgt im Laufe der Ausfuumlhrung der Simulation eine Interaktion durcheinen AnwenderIn Abbildung 35(a) sehen wir die initiale Verteilung des Geschwindigkeitsfeldes welches anschlieszligenddurch den Anwender leicht gestoumlrt wird was in Abbildung 35(b) zu beobachten ist In Abbildung 35(c)erkennen wir die Entwicklung der Geschwindigkeit im Fluid nach einer schnellen kreisfoumlrmigen Inter-aktion des Anwenders und zuletzt in Abbildung 35(d) das Verhalten des Fluids wenn der Anwendereine langsame Interaktion ausfuumlhrt Dabei koumlnnen wir sehr gut die Stroumlmung erkennen die durch dasAufpraumlgen der externen Kraumlfte ausgeloumlst wird

Kapitel 4

Tests

41 Validierung

In dem ersten Abschnitt dieses Kapitels untersuchen wir die numerische Stabilitaumlt und physikalischeKorrektheit unserer Simulation Wir wollen dies anhand von einfachen Testfaumlllen uumlberpruumlfen Zur Un-tersuchung werden wir sowohl visuelle Darstellungen nutzen als auch Diagramme von Druck- undoderGeschwindigkeitsverlaumlufen

411 Numerische Stabilitaumlt

Wir werden zunaumlchst am einfachsten Testfall Steady uumlberpruumlfen ob unsere Implementierung numerischstabil laumluft Dazu verwenden wir folgende Wahl der Parameter

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (41)

Als Erstes werden wir nun den Testfall Steady beschreiben und erlaumlutern warum sich dieser gut zuruumlberpruumlfung der numerischen Stabilitaumlt eignetIm Testfall Steady setzen wir alle initialen Werte auf Null Das heiszligt in jedem Punkt unseres Gittersherrscht ein Druck von Null die Geschwindigkeit betraumlgt Null und auch wirkt nirgends eine initial ge-setzte Kraft Wir haben also eine ruhige Simulationsumgebung gegeben welche im Folgenden nichtweiter beeinflusst wird da wir bei diesem Test keine Interaktion durch den Anwender erlauben moumlchtenZiel dieses Tests ist es unsere Simulation uumlber einen laumlngeren Zeitraum zu beobachten und zu unter-suchen ob sich trotz allgemeiner Null-Anfangsbedingung Geschwindigkeiten oder Druumlcke einstellenwelche nach unserer Auffassung nicht existieren duumlrften Da unsere farbige Visualisierung lediglich in19 Farben unterteilt wurde koumlnnte es jedoch sein dass beim Auftreten sehr kleiner Geschwindigkeitendiese visuell durch das Verwenden unserer Heat Map nicht in Erscheinung treten Um diesen Effektzu kompensieren werden wir die Druck- beziehungsweise die Geschwindigkeitsvektornorm numerischuntersuchen (vgl Abbildung 41)Wir berechnen somit in jedem Zeitschritt die Norm des Druck- und Geschwindigkeitsvektors und gebenden Verlauf uumlber unser Zeitintervall im nachfolgendem Diagramm 41 wieder Deutlich zu erkennen istdass sowohl die Norm des Druckvektors als auch die des Geschwindigkeitsvektors uumlber unser Zeitin-tervall konstant bei Null bleibt Es tritt also der intuitive Fall ein dass unsere Fluumlssigkeit im Modell beiallgemeinen Null-Anfangsbedinungen auch nach langer Zeit ruhig bleibt und keinerlei Bewegung auf-weistSomit haben wir in unserem ersten Test die Stabilitaumlt unseres Verfahren nachgewiesen koumlnnen je-doch noch keine Angaben dazu machen ob sich unsere Software physikalisch richtig verhaumllt (vgl Ab-schnitt 412)

22

KAPITEL 4 TESTS 23

0 20 40 60 80 100 120 140 160minus1

0

1x 10

minus4

Zeitschritt

Vek

torn

orm

GeschwindigkeitDruck

Abbildung 41 Vektornomen des Druck- und Geschwindigkeitsvektors uumlber mehrere Zeitschritte

412 Physikalisch richtiges Verhalten

Wie schon im vorherigen Kapitel 411 erwaumlhnt werden wir in diesem Abschnitt unsere Software aufdie Korrektheit ihrer Loumlsung untersuchen Wir werden also herausfinden ob sich unsere Simulationphysikalisch richtig verhaumllt Um dies zu erzielen greifen wir auf den gaumlngigen Testfall Driven Cavityzum Testen von Stroumlmungssimulationen zuruumlck

Abbildung 42 Konfiguration fuumlr den Testfall Driven Cavity

Driven Cavity ist ein einfacher Testfall an dem man jedoch viel uumlber die Richtigkeit unserer Imple-mentierung erfahren kann Wir wollen zunaumlchst erlaumlutern welche Testkonfiguration fuumlr Driven Cavitygewaumlhlt werden muss Der wichtigste Schritt ist die richtigen Anfangs- und Randbedingungen vorzu-

KAPITEL 4 TESTS 24

schreiben Ziel bei Driven Cavity ist es an einer Kante unseres Gitters in tangentialer Richtung mitkonstanter Geschwindigkeit v0 kontinuierlich das heiszligt waumlhrend des gesamten Zeitintervalls zu strouml-men wie in Abbildung 42 dargestellt An allen uumlbrigen Kanten wird uumlber das Zeitintervall hinweg Nullvorgeschrieben sowohl in x- als auch in y- Richtung In unserem Fall waumlhlen wir die obere Kante undstroumlmen in positive x-RichtungUm zu erreichen dass wir in jedem Zeitschritt erneut die Geschwindigkeit v0 an der oberen Kante in x-Richtung und Geschwindigkeit Null an den anderen Kanten aufpraumlgen muumlssen wir dies am Ende jedesZeitschritts in unserem Loumlser velocity und am Anfang des Tracer (vgl Kapitel 31) erneut setzenda hier die Randwerte uumlberschrieben werden und wir dies nicht zulassen wollen In den uumlbrigen Teilenunseres Loumlsers muumlssen wir dies nicht tun da hier lediglich die inneren Gitterpunkte behandelt werden(siehe Kapitel 31)Als naumlchstes legen wir nun unsere Parameter wie folgt fest

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (42)

Visuell wird die x-Komponente der Geschwindigkeit dargestellt und es ergibt sich folgendes initialesBild (Abbildung 43)

Abbildung 43 Initale Verteilung der x-Komponete der Geschwindigkeit

Man kann in Abbildung 43 deutlich eine Stroumlmung an der oberen Kannte unseres Gitters erkennengenauso wie wir es vorgegeben haben An allen uumlbrigen Punkten unseres Gitters betraumlgt die Geschwin-digkeit in x-Richtung NullWenn wir unsere Simulation uumlber einen laumlngeren Zeitraum laufen lassen stellen wir fest dass sich diein Abbildung 44 angefuumlhrte Verteilung der Geschwindigkeit einstellt und diese sich auch nach weiterenZeitschritten nicht weiter veraumlndert Um die Korrektheit unserer Loumlsung zu verifizieren vergleichen wirunsere visuelle Darstellung in Abbildung 44(a) mit bekannten richtigen Loumlsungen dieses Testfalls inAbbildung 44(b) Es ist gut zu erkennen dass unsere Darstellung die gleichen Merkmale aufweist wiedas Referenzbild 44(b)Am oberen Rand stellt sich ein Gebiet ein welches groszlige Geschwindigkeiten in x-Richtung aufweist dahier die kontinuierliche Geschwindigkeit v0 eingestellt wird welche jedoch zur Mitte hin immer weiterabnimmt Die Form dieses Gebietes ist bei beiden Bildern bis auf unterschiedliche Faumlrbungen zuruumlck-zufuumlhren auf das Verwenden verschiedener Heat Maps (vgl Kapitel 32) gleich In unserem Fall wirddas Farbspektrum in 19 Farben unterteilt und im Referenzfall in 26 (vgl Kapitel 32 und [CFD Online])In der Mitte schlieszliglich zieht sich ein nahezu stillstehendes Gebiet erkennbar durch die dunkelblaue

KAPITEL 4 TESTS 25

Faumlrbung in die obere rechte Ecke Da es eine sehr groszlige Aumlhnlichkeit zwischen unserem und dem Refe-renzbild gibt koumlnnen wir erwarten dass unsere Stroumlmungssimulation richtig implementiert wurde undeiner physikalisch realistischen Simulation entspricht

(a) Darstellung des Testfalls Driven Cavity nachvielen Zeitschritten

(b) Referenzbild zu Driven Cavity von [CFD Onli-ne]

Abbildung 44 Vergleich unserer Simulation durch ein Referenzbild am Testfall Driven Cavity

Wir gehen somit in den folgenden Kapiteln davon aus dass unsere Software einer physikalisch richtigenSimulation enspricht und numerisch stabil laumluft

KAPITEL 4 TESTS 26

42 Parametertests

In diesem Abschnitt wollen wir den Einfluss verschiedener Parameter auf unsere Simulation am TestfallHubbel (vgl Abbildung 45) untersuchen Als Erstes wollen wir den Einfluss der Viskositaumlt ν wel-ches ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres zugrunde liegenden Fluids darstellt untersuchen Anschlie-szligend befassen wir uns mit dem Zeitschritt ∆t welcher ausschlieszliglich im Tracer (siehe hierzu Kapitel 31) benoumltigt wird und hier ein Maszlig fuumlr die Genauigkeit darstellt Als Letztes werden wir den Ein-fluss der Anzahl der Jacobi-Schritte und damit die Genauigkeitsanforderungen des linearen Loumlsers (vglKapitel 31) untersuchen und anhand der visuellen Darstellung unserer Simulation analysieren wie ge-nau wir loumlsen muumlssen um Symmetrie zu erreichen Sollte unser Verfahren unter der Voraussetzung einessymmetrischen Testfalls symmetrische Ergebnisse liefern so koumlnnen wir von einer sehr guten numeri-schen Approximation einer realen Loumlsung sprechen was in unserem Fall aus einer hohen Genauigkeitdes Druck- und Geschwindigkeitsfeldes resultiertAls Standardkonfiguration waumlhlen wir folgende Werte fuumlr die in unserem Modell frei waumlhlbaren Para-meter

n = 129 h =1

128 ν = 00003 v0 = 000015 ∆t =

1

(nminus 1) middot v0 middot 200 maxiter = 32 (43)

In diesem Fall und anders als im vorherigen Testfall Driven Cavity (vgl Kapitel 412) benoumltigen wirv0 lediglich zur Bestimmung von ∆t da wir im folgenden keine initiale oder kontinuierliche Geschwin-digkeit auftragen wollen Waumlhrend jedes Tests wird ausschlieszliglich ein Parameter veraumlndert um seineAuswirkungen unabhaumlngig von den anderen Groumlszligen analysieren zu koumlnnenAls Ausgangssituation waumlhlen wir den Testfall Hubbel den wir als naumlchstes beschreiben werdenDie initiale Geschwindigkeit und Kraft in jedem Punkt unseres Gitters setzen wir als Null und schreibenfuumlr den Druck Werte so vor dass wir zwei Druckspitzen erhalten (siehe Abbildung 45) Dies realisierenwir mit Hilfe der Gauszligglockenkurve im Zweidimensionalen (siehe Gleichung (44)) da wir so auszliger-halb der Druckspitzen nahezu Null realisieren koumlnnen und wir einen stetigen Druckverlauf sogar Cinfinerzielen

f(x y) = exp(a (xminus x0)2 + a (y minus y0)2 + b

)(44)

Hierbei ist a ein Verzerrungsfaktor und b der Wert im Glockenmittelpunkt (x0 y0) Addieren wir nunzwei Glockenkurven mit a = minus50 b = 0 x1

0 = 05 und y10 = minus05 beziehungsweise x2

0 = minus05 undy2

0 = 05 erhalten wir die folgende initiale Druckverteilung

minus1 minus08 minus06 minus04 minus02 0 02 04 06 08 1minus1

minus050

0510

01

02

03

04

05

06

07

08

09

1

Abbildung 45 Initiale Druckverteilung des Testfalls Hubbel mit zwei Druckspitzen

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 3 IMPLEMENTIERUNG 14

Das Aufpraumlgen einer Kraft geschieht durch Beruumlhren des Bildschirms durch den Anwender was wir inKapitel 33 genauer erlaumlutern Sollte keine Interaktion vom Anwender ausgehen ist jeder Eintrag imforce-Array Null und es wird keine externe Kraft aufgepraumlgt

312 Advektion

Im anschlieszligenden Schritt advect der den Einfluss der Advektion in die Simulation integriert und demzweiten Schritt in Algorithmus 241 entspricht verwenden wir einen Tracer um ein neues Geschwin-digkeitsfeld zu berechnen wie es in Abbildung 23 dargestellt ist Der Aufbau des Tracers ist nichttrivial weshalb wir genauer auf seine konkrete Umsetzung eingehen Das Ziel des Tracers ist es mitHilfe von Gleichung (210) eine neue Geschwindigkeit aus bereits zuvor berechneten Geschwindigkei-ten zu ermitteln Dazu betrachten wir die aktuelle Geschwindigkeit beispielsweise im Punkt x und gehen∆t middotw1 (x) im Ort zuruumlck Wir erhalten einen neuen Punkt X der jedoch nicht zwingend auf unseremGitter liegt was in der Abbildung 31 dargestellt ist

Abbildung 31 Zweidimensionales Rechengebiet mit Gitterpunkten und Geschwindigkeitsfeld

Wie in Gleichung (210) beschrieben wollen wir die Geschwindigkeit im Punkt X als neue Geschwin-digkeit des Ausgangspunkts x setzen Dies ist jedoch nicht moumlglich wenn X keinen Punkt unseresGitters Ωh darstellt Daher ist es notwendig die Punkte in unserem Gitter zu bestimmen welche Xumgeben Diese bezeichnen wir mit P0 P1 P2 und P3 Aus den Geschwindigkeiten in diesen vierPunkten berechnen wir eine Approximation der Geschwindigkeit w2 im Punkt X Dazu verwenden wireine bilineare Interpolation der Werte w1 (P0) w1 (P1) w1 (P2) und w1 (P3) Wir muumlssen jedochbeachten dass wir moumlglicherweise auf Gitterpunkte zugreifen die auszligerhalb unseres Rechengebiets Ωliegen Dies kann auftreten wenn die Strecke ∆t middotw1 (x) zu groszlig ist und wir das Gitter verlassen Wennwir zur Veranschaulichung Abbildung 31 heranziehen so wuumlrde die gruumlne Strecke auszligerhalb des Gittersenden Wir uumlberpruumlfen daher in jedem Schritt ob X = x minus∆t middotw1 (x) noch innerhalb unseres Gittersliegt Falls dies nicht der Fall ist setzen wir P0 P1 P2 und P3 als die Ecken des Teilquadrates desGitters das den kleinsten Abstand zu dem Punkt X auszligerhalb des Gitters aufweist

313 Diffusion

Der naumlchste Schritt in Algorithmus 241 ist der Diffusionsschritt der in der Funktion velocity demAbschnitt diffuse entspricht Hier haben wir uns das Ziel gesetzt das aus Gleichung (215) resultie-rende duumlnn besetzte Gleichungssystem effizient zu loumlsen Zur Vereinfachung der Implementierung loumlsenwir das System fuumlr die x- und y-Richtung separat was durch die komponentenweise Anwendung des

KAPITEL 3 IMPLEMENTIERUNG 15

Laplace-Operators auf ein Vektorfeld moumlglich ist (vgl Abschnitt 24) Wir ziehen daraus den Vorteildass wir fuumlr beide Systeme den gleichen Quellcode verwenden koumlnnen Somit erhalten wir die folgendenzwei Gleichungssysteme der Dimension N timesN

(Iminus ν∆tnabla middot nabla)w3xy = w2

xy (31)

Um diese Gleichungssysteme hardwareeffizient auf dem gegebenen kartesischen Pixelgitter zu loumlsenverwenden wir die sogenannte Stencil-Methode die wir im Folgenden erlaumlutern Dazu betrachten wirdie Diskretisierung des Laplace-Operators wie wir sie in Gleichung (212) beschreiben Das Skalarfelds muumlssen wir dabei entweder durch w3

x oder w3y ersetzen je nachdem welches Gleichungssystem

wir loumlsen wollen Ein erster Schritt besteht darin eine allgemeine Rechenvorschrift fuumlr die Anwen-dung des Jacobi-Loumlsers auf ein lineares Gleichungssystem zu finden Dazu multiplizieren wir die Ma-trix (216) mit dem unbekannten Loumlsungsvektor w3

xy Anschlieszligend loumlsen wir in dem zugehoumlrigen Glei-chungssystem zeilenweise nach (w3

xy)ij auf und skalieren die rechte Seite des Gleichungssystems mitdem entsprechenden Diagonaleintrag Das Vorgehen fuumlr die Beruumlcksichtigung der x- beziehungsweisey-Komponenten ist das gleiche da es sich in beiden Faumlllen um die gleiche Systemmatrix handelt Soerhalten wir die in Gleichung (32) angegebene allgemeine Rechenvorschrift fuumlr die Anwendung desJacobi-Loumlsers

q(k+1)ij =

q(k)iminus1j + q

(k)i+1j + q

(k)ijminus1j + q

(k)ij+1 + αrij

β(32)

Wir geben hier die allgemeine Form dieses Loumlsungsverfahrens in Abhaumlngigkeit der Variablen (q)ijund (r)ij an weil wir es im Diffusions- und im Projektionsschritt anwenden (vgl Gleichungen (24)und (211)) Im Diffusionsschritt repraumlsentiert (q)ij das Geschwindigkeitsfeld (w3

xy)ij und (r)ijdie rechte Seite (w2

xy)ij des Gleichungssystems ausgewertet im Punkt xij isin Ωh Die Konstanten

α β isin R haumlngen vom konkreten Gleichungssystem ab Im Diffusionsschritt ergeben sie sich zu α = h2

ν∆tund β = 4 + α Der Index k isin 0 maxiter gibt den aktuellen Iterationsschritt im Jacobi-Loumlseran Mit der Berechnungsvorschrift (32) koumlnnen wir jedoch nur die aktualisierten Werte fuumlr die innerenGitterpunkte bestimmen da die Matrix fuumlr die Randwerte eine andere Gestalt aufweist Um diese zubestimmen muumlssen wir die Randbedingungen verwenden Wir schreiben fuumlr die Geschwindigkeit bdquono-slipldquo-Randbedingungen vor (vgl Abschnitt 22) was bedeutet dass (w3

xy)ij = 0 forall xij isin partΩh giltMit Hilfe der Stencil-Methode ergibt sich eine Moumlglichkeit die auftretenden Gleichungssysteme effizientzu loumlsen Da die Koeffizienten α und β der Komponenten des Loumlsungsvektors bekannt und oftmals sogargleich sind muumlssen wir diese nicht fuumlr jeden Eintrag des Vektors explizit speichern Wir muumlssen da-bei beachten dass wir dieses Vorgehen nur anwenden koumlnnen wenn konstante Koeffizienten vorliegenDurch die Anwendung der Stencil-Methode sparen wir das Speichern einer ganzen Matrix zur Loumlsungdes Gleichungssystems was es uns ermoumlglicht das Gleichungssystem hardwareeffizient zu loumlsen

314 Projektion

Der abschlieszligende Schritt in Algorithmus aus 241 ist der Projektionsschritt project Hier muumlssenwir unter anderemnabla middotw3 = partw3

x

partx + partw3y

party berechnen Zur Diskretisierung der dabei auftretenden erstenAbleitungen koumlnnen wir die in Gleichung (219) angefuumlhrte Approximation nutzen Die diskretisierteDivergenz des Geschwindigkeitsfeldes w3 koumlnnen wir berechnen da der Wert des Feldes in jedem Git-terpunkt aus dem Diffusionsschritt bekannt ist Um die Divergenz an den Raumlndern zu berechnen bedarfes einseitiger Differenzenquotienten zweiter Ordnung da wir fuumlr den zentralen Differenzenquotientenin Normalenrichtung auf Punkte zugreifen muumlssten die auszligerhalb des Gitters liegen In den Eckenverwenden wir fuumlr beide Terme einseitige Differenzenquotienten Wir muumlssen in diesem Schritt des

KAPITEL 3 IMPLEMENTIERUNG 16

Algorithmus 241 die Poissongleichung (24) fuumlr das Druckfeld pmit der durch Gleichung (219) berech-neten rechten Seite loumlsen Durch die Diskretisierung mit finiten Differenzen erhalten wir wie im Diffusi-onsschritt ein lineares Gleichungssystem Dieses koumlnnen wir nun mit Hilfe der inGleichung (32) hergeleiteten Stencil-Methode fuumlr das Jacobi-Verfahren loumlsen Die Konstanten muumlssenwir dabei als α = minush2 und β = 4 waumlhlen Auch in diesem Fall koumlnnen wir so nur die Werte im In-neren des Gitters berechnen Um Werte an den Raumlndern zu erhalten muumlssen wir die Randbedingungenfuumlr den Druck beruumlcksichtigen (vgl Abschnitt 22) Wir gehen in unserem Fall davon aus dass fuumlr denDruck Neumann-Null-Randbedingungen gelten was bedeutet dass die Ableitung in Normalenrichtungam Rand verschwindet Dazu betrachten wir den einseitigen Differenzenquotienten erster Ordnung fuumlrdie erste Ableitung beispielhaft an einem Punkt des linken Randes (vgl Abbildung 32(b)) Stellen wirihn nach pij um erhalten wir

pprimeij =pij minus pi+1j

h

= 0hArr pij = pi+1j (33)

Es ergibt sich dass wir die Druckwerte am Rand des Gebiets als den Wert des Drucks im naumlchst innerenPunkt in negativer Normalenrichtung setzen In den Ecken des Gebiets definieren wir zunaumlchst sowohldie Ableitung in x- als auch in y-Richtung als Normalenableitung Deshalb setzen wir den Druck in denEckpunkten als Mittel der Druckwerte in den benachbarten RandpunktenUm den Projektionsschritt abzuschlieszligen verwenden wir zur Diskretisierung des Druckgradienten nablapdie in Gleichung (218) angefuumlhrte Diskretisierung Anschlieszligend koumlnnen wirnablap berechnen indem wirwie bei der Berechnung der Divergenz vorgehen Aus Gleichung (33) folgt dass wir den Gradienten anden Gebietskanten in Normalenrichtung zu Null setzen koumlnnen anstatt ihn uumlber einseitige Differenzen-quotienten zu approximieren In den Ecken schreiben wir sowohl fuumlr die Ableitung in x- als auch die iny-Richtung Null vorNachdem wir uns in diesem Abschnitt mit der Umsetzung von Algorithmus 241 beschaumlftigt habengehen wir in den folgenden Unterkapiteln auf spezielle Elemente der App-Programmierung ein Dazubetrachten wir zunaumlchst die Visualisierung der Simulation und widmen uns spaumlter der Realisierung derInteraktion

32 Visualisierung

Die Stroumlmungssimulation die wir in dieser Arbeit vorstellen entsteht durch das unterschiedliche Faumlrbenvon Punkten in unserem diskreten Gitter Durch die Aumlnderung dieser Faumlrbung in jedem Zeitschritt wirdder Eindruck erweckt dass das Fluid was sich in dem diskretisierten Rechengebiet befinden soll stroumlmtZur Visualisierung der Simulation benoumltigen wir somit zwei Komponenten die Darstellung des Rechen-gebiets auf dem Bildschirm und die spezielle Faumlrbung der Gitterpunkte gemaumlszlig der Geschwindigkeits-beziehungsweise DruckwerteBei der Umsetzung der Visualisierung haben wir uns an [Learn OpenGL ES] und [Android Developer]orientiert Wir erlaumlutern zunaumlchst wie wir das zweidimensionale Rechengebiet aufbauen und gehen an-schlieszligend auf das Faumlrben der Gitterpunkte ein Das Ausgangsobjekt zur Bildung des zweidimensionalenquadratischen Rechengebiets ist ein Dreieck Setzen wir mehrere rechtwinklige Dreiecke mit Kathetender Laumlnge h isin R die der Gitterschrittweite entspricht passend aneinander so koumlnnen wir ein beliebigesRechengebiet erzeugenDa wir jedoch nicht das Einheitsquadrat [0 1]2 sondern das Quadrat [minus1 1]2 als Rechengebiet verwen-den muumlssen wir uns dem Aufbau dieses Gebiets genauer widmen da die Kantenlaumlnge des QuadratsAuswirkungen auf die Wahl der Gitterschrittweite h hat Dazu betrachten wir zunaumlchst Abbildung 32in der wir sowohl das Einheitsquadrat als auch unser Rechengebiet [minus1 1]2 darstellen Schreiben wir fuumlrdas Einheitsquadrat in Abbildung 32(a) die Anzahl n der Stuumltzstellen vor so ergibt sich als Gitterschritt-weite hlowast = 1

nminus1 Betrachten wir nun das groszlige Quadrat in Abbildung 32(b) mit einer Seitenlaumlnge von

KAPITEL 3 IMPLEMENTIERUNG 17

2 und schreiben hier ebenfalls n als Anzahl der Stuumltzstellen vor so erhalten wir die Schrittweite durchh = 2hlowast = 2

nminus1 also eine doppelt so groszlige Schrittweite wie im Fall des Einheitsquadrats

(a) Einheitsquadrat (b) Rechengebiet

Abbildung 32 Quadrate zum Aufbau des Rechengebiets

Da wir in unserer Implementierung aufgrund des mittig auf dem Bildschirm gelegenen Koordinatenur-sprungs das groszlige Quadrat zur Diskretisierung nutzen muumlssen wir auch in allen Teilproblemen eineSchrittweite von h = 2hlowast verwendenIm Folgenden erlaumlutern wir wie wir das Gitter auf dem Bildschirm darstellen Zum Zeichnen nutzen wireine Standardfunktion von OpenGL ES 20 welche die Dreiecke die zur Visualisierung des Rechen-gebiets auf dem Bildschirm noumltig sind darstellt Diese Methode traumlgt den Namen drawArrays undverlangt neben der Eingabe der Positionsdaten der Gitterpunkte auch die Farbwerte fuumlr jeden Punkt diewir jeweils in einem Array speichern Um die Positionen der Gitterpunkte zu bestimmen muumlssen wir fuumlrjeden Punkt eine x- y- und z-Komponente angeben Die Positionsdaten legen wir im Konstruktor derKlasse fest da sie nur ein Mal gesetzt werden muumlssen und sich dann nicht mehr aumlndern weil im Laufeder Simulation die Gitterweite nicht variiert Es genuumlgt fuumlr die Koordinaten der Gitterpunkte nur dieersten beiden Komponenten zu beruumlcksichtigen und die z-Koordinate auf Null zu setzen weil wir unsauf einem zweidimensionalen Gebiet befinden

Abbildung 33 Vorgehen der drawArrays-Methode fuumlr h = 13

KAPITEL 3 IMPLEMENTIERUNG 18

Die drawArrays-Routine zeichnet die Gitterpunkte beziehungsweise die Dreiecke danach in der Rei-henfolge wie sie im Positionsarray auftauchen Also muumlssen wir die Daten im Positionsarray so anord-nen dass drei aufeinander folgende Punkte ein Dreieck bilden Zur Veranschaulichung betrachten wirAbbildung 33 Stellen wir die Punkte im Positionsarray ihrer Reihenfolge nach auf dem Bildschirm darso geben wir die meisten Knoten des Gitters mehrfach wieder Die Nummern an den Knoten geben anin welchem Schritt des Zeichnens der entsprechende Punkt abgebildet wird Wir koumlnnen ihnen entneh-men wie oft ein Gitterpunkt im Laufe des Gitteraufbaus gezeichnet wird Im oberen rechten Quadrat inAbbildung 33 stellen wir das Vorgehen der drawArrays-Methode anhand der roten Pfeile dar MitHilfe dieser Zeichenroutine haben wir also die Moumlglichkeit jeden Punkt in unserem Gitter durch einenEckpunkt eines Dreiecks darzustellenDie eigentliche Simulation des Fluidverhaltens erfolgt wie oben beschrieben durch die Farben diewir den Gitterpunkten zuordnen Im Gegensatz zum Positionsarray muumlssen wir die Faumlrbung in jedemZeitschritt aktualisieren um die Simulation zu ermoumlglichen Diese entsteht schlieszliglich dadurch dass wirnach jedem Zeitschritt das neu gefaumlrbte Gitter den neuen Frame zeichnen Zur Definition der Farbe eineseinzelnen Gitterpunktes benoumltigen wir dabei vier double-Eintraumlge die den Rot- Blau und Gruumlnanteilsowie den Transparenzkoeffizienten angeben Durch die Funktion colourSet die in Quellcode 32angefuumlhrt ist weisen wir dem Wert value im i-ten Gitterpunkt seine entsprechenden Farbwerte zuDie Groumlszlige value repraumlsentiert dabei die Geschwindigkeit des Fluids oder den Druck der auf das Fluidwirkt Die Farbwerte speichern wir danach im Array colour und uumlbertragen diesen anschlieszligend inden globalen Farbvektor Colours der die Farbe eines jeden Gitterpunktes genau ein Mal enthaumllt

Quellcode 32 Codeausschnitt aus der drawGrid-Methode

f o r ( i =0 i lt 4N i +=4)c o l o u r S e t ( double va lue double [ ] c o l o u r ) C o l o u r s [ i ] = c o l o u r [ 0 ] C o l o u r s [ i +1] = c o l o u r [ 1 ] C o l o u r s [ i +2] = c o l o u r [ 2 ] C o l o u r s [ i +3] = c o l o u r [ 3 ]

Das Faumlrben der Gitterpunkte erfolgt genau in der gleichen Reihenfolge wie das Zeichnen des GittersWie im Positionsarray muumlssen wir die Farbdaten im ColourData-Array so anordnen dass drei auf-einander folgende Punkte ein Dreieck bilden Es ist moumlglich die Gitterpunkte von verschiedenen Seitenunterschiedlich zu faumlrben da die zugewiesene Faumlrbung immer nur innerhalb eines Dreiecks gilt In Abbil-dung 33 koumlnnen wir einen inneren Gitterpunkt von sechs Seiten faumlrben da er an sechs Dreiecke grenztUm eine sinnvolle Faumlrbung des Gitters zu erhalten und Spruumlnge in dieser zu vermeiden muumlssen wir dieGitterpunkte von jeder Seite gleich faumlrben Dies realisieren wir im Quellcode durch eine for-Schleifein der wir in dem Farbarray ColourData an jede Stelle die den selben Gitterpunkt repraumlsentiert diezugehoumlrigen vier Eintraumlge aus dem Colours-Array schreiben Um die Gitterpunkte mit einer Farbe zuversehen die dem Wert der vorliegenden Groumlszlige entspricht verwenden wir eine sogenannte Heat MapIn unserem Fall greifen wir auf ein Spektrum von 19 Farben zuruumlck wobei blau gefaumlrbte Punkte sehrkleine Geschwindigkeiten beziehungsweise Druumlcke repraumlsentieren und rot gefaumlrbte entsprechend groszligeDie Faumlrbung einer Dreiecksflaumlche resultiert aus der Interpolation der Farben seiner Eckpunkte Die Wahlder genauen Uumlbergaumlnge zwischen den einzelnen Farben variiert von Testfall zu Testfall In Abschnitt 42bedienen wir uns einer nicht-aumlquidistanten Zerlegung des Farbspektrums und unterscheiden im Bereichder kleinen Druumlcke genauer da der Maximaldruck nur fuumlr eine sehr kurze Zeitspanne angenommen wirdund anschlieszligend lediglich kleine bis mittelgroszlige Druumlcke auftreten In Unterkapitel 412 verwenden wirhingegen eine aumlquidistante Unterteilung des FarbspektrumsUm dieses Kapitel zur Implementierung abzuschlieszligen erlaumlutern wir im folgenden Abschnitt die Umset-zung der Interaktion in unserer Software die den wesentlichen Bestandteil der interaktiven Stroumlmungs-simulation ausmacht

KAPITEL 3 IMPLEMENTIERUNG 19

33 Interaktion

Der Schritt der die Stroumlmungssimulation interaktiv werden laumlsst ist das Aufpraumlgen einer Kraft durchdas Beruumlhren des Bildschirms durch den Anwender Zunaumlchst gehen wir darauf ein wie wir die Finger-position auf dem Bildschirm in unser Gitter uumlbertragen und erlaumlutern anschlieszligend wie wir die Kraftermitteln die durch die Interaktion auf das simulierte Fluid uumlbertragen wirdDas zentrale Problem dem wir bei der Anwender-Interaktion gegenuumlberstehen ergibt sich aus den ver-schiedenen Zeichenebenen die in OpenGL ES 20 zur Verfuumlgung stehen um dreidimensionale Ob-jekte darzustellen Zur Veranschaulichung betrachten wir Abbildung 34

Abbildung 34 Visualisierungsraum von OpenGL ES 20 (vgl [SongHo])

Alle Objekte die wir mit OpenGL ES 20 darstellen speichern wir zuerst im dreidimensionalenRaum der Objekt-Koordinaten Anschlieszligend projizieren wir diese auf die zweidimensionale Benutzer-oberflaumlche den Bildschirm was die Darstellung dreidimensionaler Koumlrper ermoumlglicht Wir koumlnnen unsleicht uumlberlegen dass die Bildschirmkoordinaten nicht den Objektkoordinaten entsprechen Die Bild-schirmkoordinaten der Fingerposition die wir zur Realisierung der Simulation registrieren muumlssen ge-ben also nicht die Position des Fingers in dem Gitter des Rechengebiets an Diese benoumltigen wir jedochum an der richtigen Stelle eine Kraft auf das simulierte Fluid aufzupraumlgen Wir sind somit auf eineTransformation angewiesen die die Bildschirmkoordinaten des Fingers welche wir mittels einer Stan-dardfunktion von OpenGL ES 20 leicht auslesen koumlnnen auf die entsprechenden Objektkoordinatenabbildet Eine solche Transformation stellt die Funktion worldCoords dar bei deren Implementierungwir uns an [Verdia] orientiert haben Fuumlr weiterfuumlhrende Informationen bezuumlglich Bildschirm- und Ob-jektkoordinaten verweisen wir auf [SongHo]Um auf die Anwender-Interaktion reagieren zu koumlnnen verwenden wir die Methode onTouchEventwelche von OpenGL ES 20 bereitgestellt wird Dabei handelt es sich um eine sogenannte bdquoCallbackldquo-Funktion was bedeutet dass sie vom System automatisch aufgerufen wird Dies geschieht genau dannwenn der Nutzer den Bildschirm beruumlhrt Wie wir in Kapitel 44 sehen erfolgt die Simulation nichtin Echtzeit was sich vor allem mit der langen Rechenzeit des Loumlsers erklaumlren laumlsst Auf dem vonuns verwendeten Geraumlt steht uns eine CPU mit zwei Kernen beziehungsweise Threads zur VerfuumlgungAuf dem einen fuumlhren wir die Berechnungen aus und auf dem anderen die Visualisierung inklusiveder TouchEvent-Abfragen Aufgrund der oben beschriebenen Verzoumlgerung ist es moumlglich mehrereAufrufe der onTouchEvent-Routine pro Zeitschritt durchzufuumlhren also Abfragen nach sogenanntenTouchEvents Wir uumlberpruumlfen dabei ob der Anwender den Bildschirm beruumlhrt oder nicht Die Kon-sequenzen die dieses Vorgehen auf die Laufzeit der Simulation hat untersuchen wir in Abschnitt 443Pro Zeitschritt beruumlcksichtigen wir nur die Ergebnisse des ersten TouchEventsDie Behandlung von TouchEvents geschieht wie folgt Sollte der Bildschirm beruumlhrt werden wirddie Funktion onTouchEvent aufgerufen Zuerst lesen wir die Position des Fingers in Bildschirm-

KAPITEL 3 IMPLEMENTIERUNG 20

koordinaten mit Hilfe der Funktion getX beziehungsweise getY aus Danach transformieren wir siein Objektkoordinaten Aus der Position des Fingers im vorherigen Zeitschritt koumlnnen wir die Streckeermitteln die der Finger von einem Zeitschritt zum naumlchsten zuruumlckgelegt hat Daraus ergeben sichdann die Positionsaumlnderungen dx in x- und dy in y-Richtung Hierbei setzen wir nicht voraus dassdie Position in Objektkoordinaten einem Gitterpunkt entspricht Da wir eine Kraft jedoch nur in einemsolchen Gitterpunkt aufpraumlgen koumlnnen ermitteln wir den Knoten der am naumlchsten zu den Objektkoor-dinaten der Fingerposition liegt In diesem Punkt setzen wir dann die Kraft in x-Richtung als dx unddie in y-Richtung als dy wodurch gewaumlhrleistet ist dass wir bei schnellerer Bewegung des Fingersdem Fluid eine groumlszligere Kraft aufpraumlgen Das Aufpraumlgen der Kraft erfolgt nun durch Aumlnderungen derEintraumlge im force-Array die zu dem Gitterpunkt gehoumlren in dem die Kraft angreifen soll Mit Hilfevon if-Abfragen in der onTouchEvent-Methode stellen wir sicher dass ein TouchEvent nur dannberuumlcksichtigt wird wenn die Objektkoordinaten der Fingerposition innerhalb des Rechengebiets liegenZur Vorbereitung des naumlchsten Zeitschritts setzen wir am Ende des Loumlsers die zuvor veraumlnderten Eintraumlgeim force-Array wieder zu Null da eine Kraft nur innerhalb eines Zeitschritts wirken soll

34 Demonstration des Gesamtsystems

In den vorherigen Kapiteln haben wir ein Verfahren zur numerischen Loumlsung der Navier-Stokes Glei-chungen hergeleitet und dessen Umsetzung auf Tablet-Computern erlaumlutert Bevor wir in Kapitel 4 einegenauere Analyse der Implementierung durchfuumlhren wollen wir vorab einen ersten Eindruck der Simu-lation vermitteln Dazu stellen wir in Abbildung 35 eine Absolutgeschwindigkeitsverteilung im Fluiddar Die angefuumlhrten Bilder sind einem Video entnommen welches dieser Arbeit beiliegt

(a) initiale Geschwindigkeitsverteilung (b) leicht beeinflusste Stroumlmung

(c) schnelle Anwender-Interaktion (d) langsame Anwender-Interaktion

Abbildung 35 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 3 IMPLEMENTIERUNG 21

Wir betrachten hier das Szenario in dem an der oberen Kante des Rechengebiets permanent eine vonNull verschiedene Geschwindigkeit angetragen ist In der unteren linken Ecke des Gebiets befindet sicheine Druckspitze Erlaumluterungen zu diesen Rand- beziehungsweise Anfangsbedingungen finden sich imfolgenden Kapitel Auszligerdem erfolgt im Laufe der Ausfuumlhrung der Simulation eine Interaktion durcheinen AnwenderIn Abbildung 35(a) sehen wir die initiale Verteilung des Geschwindigkeitsfeldes welches anschlieszligenddurch den Anwender leicht gestoumlrt wird was in Abbildung 35(b) zu beobachten ist In Abbildung 35(c)erkennen wir die Entwicklung der Geschwindigkeit im Fluid nach einer schnellen kreisfoumlrmigen Inter-aktion des Anwenders und zuletzt in Abbildung 35(d) das Verhalten des Fluids wenn der Anwendereine langsame Interaktion ausfuumlhrt Dabei koumlnnen wir sehr gut die Stroumlmung erkennen die durch dasAufpraumlgen der externen Kraumlfte ausgeloumlst wird

Kapitel 4

Tests

41 Validierung

In dem ersten Abschnitt dieses Kapitels untersuchen wir die numerische Stabilitaumlt und physikalischeKorrektheit unserer Simulation Wir wollen dies anhand von einfachen Testfaumlllen uumlberpruumlfen Zur Un-tersuchung werden wir sowohl visuelle Darstellungen nutzen als auch Diagramme von Druck- undoderGeschwindigkeitsverlaumlufen

411 Numerische Stabilitaumlt

Wir werden zunaumlchst am einfachsten Testfall Steady uumlberpruumlfen ob unsere Implementierung numerischstabil laumluft Dazu verwenden wir folgende Wahl der Parameter

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (41)

Als Erstes werden wir nun den Testfall Steady beschreiben und erlaumlutern warum sich dieser gut zuruumlberpruumlfung der numerischen Stabilitaumlt eignetIm Testfall Steady setzen wir alle initialen Werte auf Null Das heiszligt in jedem Punkt unseres Gittersherrscht ein Druck von Null die Geschwindigkeit betraumlgt Null und auch wirkt nirgends eine initial ge-setzte Kraft Wir haben also eine ruhige Simulationsumgebung gegeben welche im Folgenden nichtweiter beeinflusst wird da wir bei diesem Test keine Interaktion durch den Anwender erlauben moumlchtenZiel dieses Tests ist es unsere Simulation uumlber einen laumlngeren Zeitraum zu beobachten und zu unter-suchen ob sich trotz allgemeiner Null-Anfangsbedingung Geschwindigkeiten oder Druumlcke einstellenwelche nach unserer Auffassung nicht existieren duumlrften Da unsere farbige Visualisierung lediglich in19 Farben unterteilt wurde koumlnnte es jedoch sein dass beim Auftreten sehr kleiner Geschwindigkeitendiese visuell durch das Verwenden unserer Heat Map nicht in Erscheinung treten Um diesen Effektzu kompensieren werden wir die Druck- beziehungsweise die Geschwindigkeitsvektornorm numerischuntersuchen (vgl Abbildung 41)Wir berechnen somit in jedem Zeitschritt die Norm des Druck- und Geschwindigkeitsvektors und gebenden Verlauf uumlber unser Zeitintervall im nachfolgendem Diagramm 41 wieder Deutlich zu erkennen istdass sowohl die Norm des Druckvektors als auch die des Geschwindigkeitsvektors uumlber unser Zeitin-tervall konstant bei Null bleibt Es tritt also der intuitive Fall ein dass unsere Fluumlssigkeit im Modell beiallgemeinen Null-Anfangsbedinungen auch nach langer Zeit ruhig bleibt und keinerlei Bewegung auf-weistSomit haben wir in unserem ersten Test die Stabilitaumlt unseres Verfahren nachgewiesen koumlnnen je-doch noch keine Angaben dazu machen ob sich unsere Software physikalisch richtig verhaumllt (vgl Ab-schnitt 412)

22

KAPITEL 4 TESTS 23

0 20 40 60 80 100 120 140 160minus1

0

1x 10

minus4

Zeitschritt

Vek

torn

orm

GeschwindigkeitDruck

Abbildung 41 Vektornomen des Druck- und Geschwindigkeitsvektors uumlber mehrere Zeitschritte

412 Physikalisch richtiges Verhalten

Wie schon im vorherigen Kapitel 411 erwaumlhnt werden wir in diesem Abschnitt unsere Software aufdie Korrektheit ihrer Loumlsung untersuchen Wir werden also herausfinden ob sich unsere Simulationphysikalisch richtig verhaumllt Um dies zu erzielen greifen wir auf den gaumlngigen Testfall Driven Cavityzum Testen von Stroumlmungssimulationen zuruumlck

Abbildung 42 Konfiguration fuumlr den Testfall Driven Cavity

Driven Cavity ist ein einfacher Testfall an dem man jedoch viel uumlber die Richtigkeit unserer Imple-mentierung erfahren kann Wir wollen zunaumlchst erlaumlutern welche Testkonfiguration fuumlr Driven Cavitygewaumlhlt werden muss Der wichtigste Schritt ist die richtigen Anfangs- und Randbedingungen vorzu-

KAPITEL 4 TESTS 24

schreiben Ziel bei Driven Cavity ist es an einer Kante unseres Gitters in tangentialer Richtung mitkonstanter Geschwindigkeit v0 kontinuierlich das heiszligt waumlhrend des gesamten Zeitintervalls zu strouml-men wie in Abbildung 42 dargestellt An allen uumlbrigen Kanten wird uumlber das Zeitintervall hinweg Nullvorgeschrieben sowohl in x- als auch in y- Richtung In unserem Fall waumlhlen wir die obere Kante undstroumlmen in positive x-RichtungUm zu erreichen dass wir in jedem Zeitschritt erneut die Geschwindigkeit v0 an der oberen Kante in x-Richtung und Geschwindigkeit Null an den anderen Kanten aufpraumlgen muumlssen wir dies am Ende jedesZeitschritts in unserem Loumlser velocity und am Anfang des Tracer (vgl Kapitel 31) erneut setzenda hier die Randwerte uumlberschrieben werden und wir dies nicht zulassen wollen In den uumlbrigen Teilenunseres Loumlsers muumlssen wir dies nicht tun da hier lediglich die inneren Gitterpunkte behandelt werden(siehe Kapitel 31)Als naumlchstes legen wir nun unsere Parameter wie folgt fest

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (42)

Visuell wird die x-Komponente der Geschwindigkeit dargestellt und es ergibt sich folgendes initialesBild (Abbildung 43)

Abbildung 43 Initale Verteilung der x-Komponete der Geschwindigkeit

Man kann in Abbildung 43 deutlich eine Stroumlmung an der oberen Kannte unseres Gitters erkennengenauso wie wir es vorgegeben haben An allen uumlbrigen Punkten unseres Gitters betraumlgt die Geschwin-digkeit in x-Richtung NullWenn wir unsere Simulation uumlber einen laumlngeren Zeitraum laufen lassen stellen wir fest dass sich diein Abbildung 44 angefuumlhrte Verteilung der Geschwindigkeit einstellt und diese sich auch nach weiterenZeitschritten nicht weiter veraumlndert Um die Korrektheit unserer Loumlsung zu verifizieren vergleichen wirunsere visuelle Darstellung in Abbildung 44(a) mit bekannten richtigen Loumlsungen dieses Testfalls inAbbildung 44(b) Es ist gut zu erkennen dass unsere Darstellung die gleichen Merkmale aufweist wiedas Referenzbild 44(b)Am oberen Rand stellt sich ein Gebiet ein welches groszlige Geschwindigkeiten in x-Richtung aufweist dahier die kontinuierliche Geschwindigkeit v0 eingestellt wird welche jedoch zur Mitte hin immer weiterabnimmt Die Form dieses Gebietes ist bei beiden Bildern bis auf unterschiedliche Faumlrbungen zuruumlck-zufuumlhren auf das Verwenden verschiedener Heat Maps (vgl Kapitel 32) gleich In unserem Fall wirddas Farbspektrum in 19 Farben unterteilt und im Referenzfall in 26 (vgl Kapitel 32 und [CFD Online])In der Mitte schlieszliglich zieht sich ein nahezu stillstehendes Gebiet erkennbar durch die dunkelblaue

KAPITEL 4 TESTS 25

Faumlrbung in die obere rechte Ecke Da es eine sehr groszlige Aumlhnlichkeit zwischen unserem und dem Refe-renzbild gibt koumlnnen wir erwarten dass unsere Stroumlmungssimulation richtig implementiert wurde undeiner physikalisch realistischen Simulation entspricht

(a) Darstellung des Testfalls Driven Cavity nachvielen Zeitschritten

(b) Referenzbild zu Driven Cavity von [CFD Onli-ne]

Abbildung 44 Vergleich unserer Simulation durch ein Referenzbild am Testfall Driven Cavity

Wir gehen somit in den folgenden Kapiteln davon aus dass unsere Software einer physikalisch richtigenSimulation enspricht und numerisch stabil laumluft

KAPITEL 4 TESTS 26

42 Parametertests

In diesem Abschnitt wollen wir den Einfluss verschiedener Parameter auf unsere Simulation am TestfallHubbel (vgl Abbildung 45) untersuchen Als Erstes wollen wir den Einfluss der Viskositaumlt ν wel-ches ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres zugrunde liegenden Fluids darstellt untersuchen Anschlie-szligend befassen wir uns mit dem Zeitschritt ∆t welcher ausschlieszliglich im Tracer (siehe hierzu Kapitel 31) benoumltigt wird und hier ein Maszlig fuumlr die Genauigkeit darstellt Als Letztes werden wir den Ein-fluss der Anzahl der Jacobi-Schritte und damit die Genauigkeitsanforderungen des linearen Loumlsers (vglKapitel 31) untersuchen und anhand der visuellen Darstellung unserer Simulation analysieren wie ge-nau wir loumlsen muumlssen um Symmetrie zu erreichen Sollte unser Verfahren unter der Voraussetzung einessymmetrischen Testfalls symmetrische Ergebnisse liefern so koumlnnen wir von einer sehr guten numeri-schen Approximation einer realen Loumlsung sprechen was in unserem Fall aus einer hohen Genauigkeitdes Druck- und Geschwindigkeitsfeldes resultiertAls Standardkonfiguration waumlhlen wir folgende Werte fuumlr die in unserem Modell frei waumlhlbaren Para-meter

n = 129 h =1

128 ν = 00003 v0 = 000015 ∆t =

1

(nminus 1) middot v0 middot 200 maxiter = 32 (43)

In diesem Fall und anders als im vorherigen Testfall Driven Cavity (vgl Kapitel 412) benoumltigen wirv0 lediglich zur Bestimmung von ∆t da wir im folgenden keine initiale oder kontinuierliche Geschwin-digkeit auftragen wollen Waumlhrend jedes Tests wird ausschlieszliglich ein Parameter veraumlndert um seineAuswirkungen unabhaumlngig von den anderen Groumlszligen analysieren zu koumlnnenAls Ausgangssituation waumlhlen wir den Testfall Hubbel den wir als naumlchstes beschreiben werdenDie initiale Geschwindigkeit und Kraft in jedem Punkt unseres Gitters setzen wir als Null und schreibenfuumlr den Druck Werte so vor dass wir zwei Druckspitzen erhalten (siehe Abbildung 45) Dies realisierenwir mit Hilfe der Gauszligglockenkurve im Zweidimensionalen (siehe Gleichung (44)) da wir so auszliger-halb der Druckspitzen nahezu Null realisieren koumlnnen und wir einen stetigen Druckverlauf sogar Cinfinerzielen

f(x y) = exp(a (xminus x0)2 + a (y minus y0)2 + b

)(44)

Hierbei ist a ein Verzerrungsfaktor und b der Wert im Glockenmittelpunkt (x0 y0) Addieren wir nunzwei Glockenkurven mit a = minus50 b = 0 x1

0 = 05 und y10 = minus05 beziehungsweise x2

0 = minus05 undy2

0 = 05 erhalten wir die folgende initiale Druckverteilung

minus1 minus08 minus06 minus04 minus02 0 02 04 06 08 1minus1

minus050

0510

01

02

03

04

05

06

07

08

09

1

Abbildung 45 Initiale Druckverteilung des Testfalls Hubbel mit zwei Druckspitzen

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 3 IMPLEMENTIERUNG 15

Laplace-Operators auf ein Vektorfeld moumlglich ist (vgl Abschnitt 24) Wir ziehen daraus den Vorteildass wir fuumlr beide Systeme den gleichen Quellcode verwenden koumlnnen Somit erhalten wir die folgendenzwei Gleichungssysteme der Dimension N timesN

(Iminus ν∆tnabla middot nabla)w3xy = w2

xy (31)

Um diese Gleichungssysteme hardwareeffizient auf dem gegebenen kartesischen Pixelgitter zu loumlsenverwenden wir die sogenannte Stencil-Methode die wir im Folgenden erlaumlutern Dazu betrachten wirdie Diskretisierung des Laplace-Operators wie wir sie in Gleichung (212) beschreiben Das Skalarfelds muumlssen wir dabei entweder durch w3

x oder w3y ersetzen je nachdem welches Gleichungssystem

wir loumlsen wollen Ein erster Schritt besteht darin eine allgemeine Rechenvorschrift fuumlr die Anwen-dung des Jacobi-Loumlsers auf ein lineares Gleichungssystem zu finden Dazu multiplizieren wir die Ma-trix (216) mit dem unbekannten Loumlsungsvektor w3

xy Anschlieszligend loumlsen wir in dem zugehoumlrigen Glei-chungssystem zeilenweise nach (w3

xy)ij auf und skalieren die rechte Seite des Gleichungssystems mitdem entsprechenden Diagonaleintrag Das Vorgehen fuumlr die Beruumlcksichtigung der x- beziehungsweisey-Komponenten ist das gleiche da es sich in beiden Faumlllen um die gleiche Systemmatrix handelt Soerhalten wir die in Gleichung (32) angegebene allgemeine Rechenvorschrift fuumlr die Anwendung desJacobi-Loumlsers

q(k+1)ij =

q(k)iminus1j + q

(k)i+1j + q

(k)ijminus1j + q

(k)ij+1 + αrij

β(32)

Wir geben hier die allgemeine Form dieses Loumlsungsverfahrens in Abhaumlngigkeit der Variablen (q)ijund (r)ij an weil wir es im Diffusions- und im Projektionsschritt anwenden (vgl Gleichungen (24)und (211)) Im Diffusionsschritt repraumlsentiert (q)ij das Geschwindigkeitsfeld (w3

xy)ij und (r)ijdie rechte Seite (w2

xy)ij des Gleichungssystems ausgewertet im Punkt xij isin Ωh Die Konstanten

α β isin R haumlngen vom konkreten Gleichungssystem ab Im Diffusionsschritt ergeben sie sich zu α = h2

ν∆tund β = 4 + α Der Index k isin 0 maxiter gibt den aktuellen Iterationsschritt im Jacobi-Loumlseran Mit der Berechnungsvorschrift (32) koumlnnen wir jedoch nur die aktualisierten Werte fuumlr die innerenGitterpunkte bestimmen da die Matrix fuumlr die Randwerte eine andere Gestalt aufweist Um diese zubestimmen muumlssen wir die Randbedingungen verwenden Wir schreiben fuumlr die Geschwindigkeit bdquono-slipldquo-Randbedingungen vor (vgl Abschnitt 22) was bedeutet dass (w3

xy)ij = 0 forall xij isin partΩh giltMit Hilfe der Stencil-Methode ergibt sich eine Moumlglichkeit die auftretenden Gleichungssysteme effizientzu loumlsen Da die Koeffizienten α und β der Komponenten des Loumlsungsvektors bekannt und oftmals sogargleich sind muumlssen wir diese nicht fuumlr jeden Eintrag des Vektors explizit speichern Wir muumlssen da-bei beachten dass wir dieses Vorgehen nur anwenden koumlnnen wenn konstante Koeffizienten vorliegenDurch die Anwendung der Stencil-Methode sparen wir das Speichern einer ganzen Matrix zur Loumlsungdes Gleichungssystems was es uns ermoumlglicht das Gleichungssystem hardwareeffizient zu loumlsen

314 Projektion

Der abschlieszligende Schritt in Algorithmus aus 241 ist der Projektionsschritt project Hier muumlssenwir unter anderemnabla middotw3 = partw3

x

partx + partw3y

party berechnen Zur Diskretisierung der dabei auftretenden erstenAbleitungen koumlnnen wir die in Gleichung (219) angefuumlhrte Approximation nutzen Die diskretisierteDivergenz des Geschwindigkeitsfeldes w3 koumlnnen wir berechnen da der Wert des Feldes in jedem Git-terpunkt aus dem Diffusionsschritt bekannt ist Um die Divergenz an den Raumlndern zu berechnen bedarfes einseitiger Differenzenquotienten zweiter Ordnung da wir fuumlr den zentralen Differenzenquotientenin Normalenrichtung auf Punkte zugreifen muumlssten die auszligerhalb des Gitters liegen In den Eckenverwenden wir fuumlr beide Terme einseitige Differenzenquotienten Wir muumlssen in diesem Schritt des

KAPITEL 3 IMPLEMENTIERUNG 16

Algorithmus 241 die Poissongleichung (24) fuumlr das Druckfeld pmit der durch Gleichung (219) berech-neten rechten Seite loumlsen Durch die Diskretisierung mit finiten Differenzen erhalten wir wie im Diffusi-onsschritt ein lineares Gleichungssystem Dieses koumlnnen wir nun mit Hilfe der inGleichung (32) hergeleiteten Stencil-Methode fuumlr das Jacobi-Verfahren loumlsen Die Konstanten muumlssenwir dabei als α = minush2 und β = 4 waumlhlen Auch in diesem Fall koumlnnen wir so nur die Werte im In-neren des Gitters berechnen Um Werte an den Raumlndern zu erhalten muumlssen wir die Randbedingungenfuumlr den Druck beruumlcksichtigen (vgl Abschnitt 22) Wir gehen in unserem Fall davon aus dass fuumlr denDruck Neumann-Null-Randbedingungen gelten was bedeutet dass die Ableitung in Normalenrichtungam Rand verschwindet Dazu betrachten wir den einseitigen Differenzenquotienten erster Ordnung fuumlrdie erste Ableitung beispielhaft an einem Punkt des linken Randes (vgl Abbildung 32(b)) Stellen wirihn nach pij um erhalten wir

pprimeij =pij minus pi+1j

h

= 0hArr pij = pi+1j (33)

Es ergibt sich dass wir die Druckwerte am Rand des Gebiets als den Wert des Drucks im naumlchst innerenPunkt in negativer Normalenrichtung setzen In den Ecken des Gebiets definieren wir zunaumlchst sowohldie Ableitung in x- als auch in y-Richtung als Normalenableitung Deshalb setzen wir den Druck in denEckpunkten als Mittel der Druckwerte in den benachbarten RandpunktenUm den Projektionsschritt abzuschlieszligen verwenden wir zur Diskretisierung des Druckgradienten nablapdie in Gleichung (218) angefuumlhrte Diskretisierung Anschlieszligend koumlnnen wirnablap berechnen indem wirwie bei der Berechnung der Divergenz vorgehen Aus Gleichung (33) folgt dass wir den Gradienten anden Gebietskanten in Normalenrichtung zu Null setzen koumlnnen anstatt ihn uumlber einseitige Differenzen-quotienten zu approximieren In den Ecken schreiben wir sowohl fuumlr die Ableitung in x- als auch die iny-Richtung Null vorNachdem wir uns in diesem Abschnitt mit der Umsetzung von Algorithmus 241 beschaumlftigt habengehen wir in den folgenden Unterkapiteln auf spezielle Elemente der App-Programmierung ein Dazubetrachten wir zunaumlchst die Visualisierung der Simulation und widmen uns spaumlter der Realisierung derInteraktion

32 Visualisierung

Die Stroumlmungssimulation die wir in dieser Arbeit vorstellen entsteht durch das unterschiedliche Faumlrbenvon Punkten in unserem diskreten Gitter Durch die Aumlnderung dieser Faumlrbung in jedem Zeitschritt wirdder Eindruck erweckt dass das Fluid was sich in dem diskretisierten Rechengebiet befinden soll stroumlmtZur Visualisierung der Simulation benoumltigen wir somit zwei Komponenten die Darstellung des Rechen-gebiets auf dem Bildschirm und die spezielle Faumlrbung der Gitterpunkte gemaumlszlig der Geschwindigkeits-beziehungsweise DruckwerteBei der Umsetzung der Visualisierung haben wir uns an [Learn OpenGL ES] und [Android Developer]orientiert Wir erlaumlutern zunaumlchst wie wir das zweidimensionale Rechengebiet aufbauen und gehen an-schlieszligend auf das Faumlrben der Gitterpunkte ein Das Ausgangsobjekt zur Bildung des zweidimensionalenquadratischen Rechengebiets ist ein Dreieck Setzen wir mehrere rechtwinklige Dreiecke mit Kathetender Laumlnge h isin R die der Gitterschrittweite entspricht passend aneinander so koumlnnen wir ein beliebigesRechengebiet erzeugenDa wir jedoch nicht das Einheitsquadrat [0 1]2 sondern das Quadrat [minus1 1]2 als Rechengebiet verwen-den muumlssen wir uns dem Aufbau dieses Gebiets genauer widmen da die Kantenlaumlnge des QuadratsAuswirkungen auf die Wahl der Gitterschrittweite h hat Dazu betrachten wir zunaumlchst Abbildung 32in der wir sowohl das Einheitsquadrat als auch unser Rechengebiet [minus1 1]2 darstellen Schreiben wir fuumlrdas Einheitsquadrat in Abbildung 32(a) die Anzahl n der Stuumltzstellen vor so ergibt sich als Gitterschritt-weite hlowast = 1

nminus1 Betrachten wir nun das groszlige Quadrat in Abbildung 32(b) mit einer Seitenlaumlnge von

KAPITEL 3 IMPLEMENTIERUNG 17

2 und schreiben hier ebenfalls n als Anzahl der Stuumltzstellen vor so erhalten wir die Schrittweite durchh = 2hlowast = 2

nminus1 also eine doppelt so groszlige Schrittweite wie im Fall des Einheitsquadrats

(a) Einheitsquadrat (b) Rechengebiet

Abbildung 32 Quadrate zum Aufbau des Rechengebiets

Da wir in unserer Implementierung aufgrund des mittig auf dem Bildschirm gelegenen Koordinatenur-sprungs das groszlige Quadrat zur Diskretisierung nutzen muumlssen wir auch in allen Teilproblemen eineSchrittweite von h = 2hlowast verwendenIm Folgenden erlaumlutern wir wie wir das Gitter auf dem Bildschirm darstellen Zum Zeichnen nutzen wireine Standardfunktion von OpenGL ES 20 welche die Dreiecke die zur Visualisierung des Rechen-gebiets auf dem Bildschirm noumltig sind darstellt Diese Methode traumlgt den Namen drawArrays undverlangt neben der Eingabe der Positionsdaten der Gitterpunkte auch die Farbwerte fuumlr jeden Punkt diewir jeweils in einem Array speichern Um die Positionen der Gitterpunkte zu bestimmen muumlssen wir fuumlrjeden Punkt eine x- y- und z-Komponente angeben Die Positionsdaten legen wir im Konstruktor derKlasse fest da sie nur ein Mal gesetzt werden muumlssen und sich dann nicht mehr aumlndern weil im Laufeder Simulation die Gitterweite nicht variiert Es genuumlgt fuumlr die Koordinaten der Gitterpunkte nur dieersten beiden Komponenten zu beruumlcksichtigen und die z-Koordinate auf Null zu setzen weil wir unsauf einem zweidimensionalen Gebiet befinden

Abbildung 33 Vorgehen der drawArrays-Methode fuumlr h = 13

KAPITEL 3 IMPLEMENTIERUNG 18

Die drawArrays-Routine zeichnet die Gitterpunkte beziehungsweise die Dreiecke danach in der Rei-henfolge wie sie im Positionsarray auftauchen Also muumlssen wir die Daten im Positionsarray so anord-nen dass drei aufeinander folgende Punkte ein Dreieck bilden Zur Veranschaulichung betrachten wirAbbildung 33 Stellen wir die Punkte im Positionsarray ihrer Reihenfolge nach auf dem Bildschirm darso geben wir die meisten Knoten des Gitters mehrfach wieder Die Nummern an den Knoten geben anin welchem Schritt des Zeichnens der entsprechende Punkt abgebildet wird Wir koumlnnen ihnen entneh-men wie oft ein Gitterpunkt im Laufe des Gitteraufbaus gezeichnet wird Im oberen rechten Quadrat inAbbildung 33 stellen wir das Vorgehen der drawArrays-Methode anhand der roten Pfeile dar MitHilfe dieser Zeichenroutine haben wir also die Moumlglichkeit jeden Punkt in unserem Gitter durch einenEckpunkt eines Dreiecks darzustellenDie eigentliche Simulation des Fluidverhaltens erfolgt wie oben beschrieben durch die Farben diewir den Gitterpunkten zuordnen Im Gegensatz zum Positionsarray muumlssen wir die Faumlrbung in jedemZeitschritt aktualisieren um die Simulation zu ermoumlglichen Diese entsteht schlieszliglich dadurch dass wirnach jedem Zeitschritt das neu gefaumlrbte Gitter den neuen Frame zeichnen Zur Definition der Farbe eineseinzelnen Gitterpunktes benoumltigen wir dabei vier double-Eintraumlge die den Rot- Blau und Gruumlnanteilsowie den Transparenzkoeffizienten angeben Durch die Funktion colourSet die in Quellcode 32angefuumlhrt ist weisen wir dem Wert value im i-ten Gitterpunkt seine entsprechenden Farbwerte zuDie Groumlszlige value repraumlsentiert dabei die Geschwindigkeit des Fluids oder den Druck der auf das Fluidwirkt Die Farbwerte speichern wir danach im Array colour und uumlbertragen diesen anschlieszligend inden globalen Farbvektor Colours der die Farbe eines jeden Gitterpunktes genau ein Mal enthaumllt

Quellcode 32 Codeausschnitt aus der drawGrid-Methode

f o r ( i =0 i lt 4N i +=4)c o l o u r S e t ( double va lue double [ ] c o l o u r ) C o l o u r s [ i ] = c o l o u r [ 0 ] C o l o u r s [ i +1] = c o l o u r [ 1 ] C o l o u r s [ i +2] = c o l o u r [ 2 ] C o l o u r s [ i +3] = c o l o u r [ 3 ]

Das Faumlrben der Gitterpunkte erfolgt genau in der gleichen Reihenfolge wie das Zeichnen des GittersWie im Positionsarray muumlssen wir die Farbdaten im ColourData-Array so anordnen dass drei auf-einander folgende Punkte ein Dreieck bilden Es ist moumlglich die Gitterpunkte von verschiedenen Seitenunterschiedlich zu faumlrben da die zugewiesene Faumlrbung immer nur innerhalb eines Dreiecks gilt In Abbil-dung 33 koumlnnen wir einen inneren Gitterpunkt von sechs Seiten faumlrben da er an sechs Dreiecke grenztUm eine sinnvolle Faumlrbung des Gitters zu erhalten und Spruumlnge in dieser zu vermeiden muumlssen wir dieGitterpunkte von jeder Seite gleich faumlrben Dies realisieren wir im Quellcode durch eine for-Schleifein der wir in dem Farbarray ColourData an jede Stelle die den selben Gitterpunkt repraumlsentiert diezugehoumlrigen vier Eintraumlge aus dem Colours-Array schreiben Um die Gitterpunkte mit einer Farbe zuversehen die dem Wert der vorliegenden Groumlszlige entspricht verwenden wir eine sogenannte Heat MapIn unserem Fall greifen wir auf ein Spektrum von 19 Farben zuruumlck wobei blau gefaumlrbte Punkte sehrkleine Geschwindigkeiten beziehungsweise Druumlcke repraumlsentieren und rot gefaumlrbte entsprechend groszligeDie Faumlrbung einer Dreiecksflaumlche resultiert aus der Interpolation der Farben seiner Eckpunkte Die Wahlder genauen Uumlbergaumlnge zwischen den einzelnen Farben variiert von Testfall zu Testfall In Abschnitt 42bedienen wir uns einer nicht-aumlquidistanten Zerlegung des Farbspektrums und unterscheiden im Bereichder kleinen Druumlcke genauer da der Maximaldruck nur fuumlr eine sehr kurze Zeitspanne angenommen wirdund anschlieszligend lediglich kleine bis mittelgroszlige Druumlcke auftreten In Unterkapitel 412 verwenden wirhingegen eine aumlquidistante Unterteilung des FarbspektrumsUm dieses Kapitel zur Implementierung abzuschlieszligen erlaumlutern wir im folgenden Abschnitt die Umset-zung der Interaktion in unserer Software die den wesentlichen Bestandteil der interaktiven Stroumlmungs-simulation ausmacht

KAPITEL 3 IMPLEMENTIERUNG 19

33 Interaktion

Der Schritt der die Stroumlmungssimulation interaktiv werden laumlsst ist das Aufpraumlgen einer Kraft durchdas Beruumlhren des Bildschirms durch den Anwender Zunaumlchst gehen wir darauf ein wie wir die Finger-position auf dem Bildschirm in unser Gitter uumlbertragen und erlaumlutern anschlieszligend wie wir die Kraftermitteln die durch die Interaktion auf das simulierte Fluid uumlbertragen wirdDas zentrale Problem dem wir bei der Anwender-Interaktion gegenuumlberstehen ergibt sich aus den ver-schiedenen Zeichenebenen die in OpenGL ES 20 zur Verfuumlgung stehen um dreidimensionale Ob-jekte darzustellen Zur Veranschaulichung betrachten wir Abbildung 34

Abbildung 34 Visualisierungsraum von OpenGL ES 20 (vgl [SongHo])

Alle Objekte die wir mit OpenGL ES 20 darstellen speichern wir zuerst im dreidimensionalenRaum der Objekt-Koordinaten Anschlieszligend projizieren wir diese auf die zweidimensionale Benutzer-oberflaumlche den Bildschirm was die Darstellung dreidimensionaler Koumlrper ermoumlglicht Wir koumlnnen unsleicht uumlberlegen dass die Bildschirmkoordinaten nicht den Objektkoordinaten entsprechen Die Bild-schirmkoordinaten der Fingerposition die wir zur Realisierung der Simulation registrieren muumlssen ge-ben also nicht die Position des Fingers in dem Gitter des Rechengebiets an Diese benoumltigen wir jedochum an der richtigen Stelle eine Kraft auf das simulierte Fluid aufzupraumlgen Wir sind somit auf eineTransformation angewiesen die die Bildschirmkoordinaten des Fingers welche wir mittels einer Stan-dardfunktion von OpenGL ES 20 leicht auslesen koumlnnen auf die entsprechenden Objektkoordinatenabbildet Eine solche Transformation stellt die Funktion worldCoords dar bei deren Implementierungwir uns an [Verdia] orientiert haben Fuumlr weiterfuumlhrende Informationen bezuumlglich Bildschirm- und Ob-jektkoordinaten verweisen wir auf [SongHo]Um auf die Anwender-Interaktion reagieren zu koumlnnen verwenden wir die Methode onTouchEventwelche von OpenGL ES 20 bereitgestellt wird Dabei handelt es sich um eine sogenannte bdquoCallbackldquo-Funktion was bedeutet dass sie vom System automatisch aufgerufen wird Dies geschieht genau dannwenn der Nutzer den Bildschirm beruumlhrt Wie wir in Kapitel 44 sehen erfolgt die Simulation nichtin Echtzeit was sich vor allem mit der langen Rechenzeit des Loumlsers erklaumlren laumlsst Auf dem vonuns verwendeten Geraumlt steht uns eine CPU mit zwei Kernen beziehungsweise Threads zur VerfuumlgungAuf dem einen fuumlhren wir die Berechnungen aus und auf dem anderen die Visualisierung inklusiveder TouchEvent-Abfragen Aufgrund der oben beschriebenen Verzoumlgerung ist es moumlglich mehrereAufrufe der onTouchEvent-Routine pro Zeitschritt durchzufuumlhren also Abfragen nach sogenanntenTouchEvents Wir uumlberpruumlfen dabei ob der Anwender den Bildschirm beruumlhrt oder nicht Die Kon-sequenzen die dieses Vorgehen auf die Laufzeit der Simulation hat untersuchen wir in Abschnitt 443Pro Zeitschritt beruumlcksichtigen wir nur die Ergebnisse des ersten TouchEventsDie Behandlung von TouchEvents geschieht wie folgt Sollte der Bildschirm beruumlhrt werden wirddie Funktion onTouchEvent aufgerufen Zuerst lesen wir die Position des Fingers in Bildschirm-

KAPITEL 3 IMPLEMENTIERUNG 20

koordinaten mit Hilfe der Funktion getX beziehungsweise getY aus Danach transformieren wir siein Objektkoordinaten Aus der Position des Fingers im vorherigen Zeitschritt koumlnnen wir die Streckeermitteln die der Finger von einem Zeitschritt zum naumlchsten zuruumlckgelegt hat Daraus ergeben sichdann die Positionsaumlnderungen dx in x- und dy in y-Richtung Hierbei setzen wir nicht voraus dassdie Position in Objektkoordinaten einem Gitterpunkt entspricht Da wir eine Kraft jedoch nur in einemsolchen Gitterpunkt aufpraumlgen koumlnnen ermitteln wir den Knoten der am naumlchsten zu den Objektkoor-dinaten der Fingerposition liegt In diesem Punkt setzen wir dann die Kraft in x-Richtung als dx unddie in y-Richtung als dy wodurch gewaumlhrleistet ist dass wir bei schnellerer Bewegung des Fingersdem Fluid eine groumlszligere Kraft aufpraumlgen Das Aufpraumlgen der Kraft erfolgt nun durch Aumlnderungen derEintraumlge im force-Array die zu dem Gitterpunkt gehoumlren in dem die Kraft angreifen soll Mit Hilfevon if-Abfragen in der onTouchEvent-Methode stellen wir sicher dass ein TouchEvent nur dannberuumlcksichtigt wird wenn die Objektkoordinaten der Fingerposition innerhalb des Rechengebiets liegenZur Vorbereitung des naumlchsten Zeitschritts setzen wir am Ende des Loumlsers die zuvor veraumlnderten Eintraumlgeim force-Array wieder zu Null da eine Kraft nur innerhalb eines Zeitschritts wirken soll

34 Demonstration des Gesamtsystems

In den vorherigen Kapiteln haben wir ein Verfahren zur numerischen Loumlsung der Navier-Stokes Glei-chungen hergeleitet und dessen Umsetzung auf Tablet-Computern erlaumlutert Bevor wir in Kapitel 4 einegenauere Analyse der Implementierung durchfuumlhren wollen wir vorab einen ersten Eindruck der Simu-lation vermitteln Dazu stellen wir in Abbildung 35 eine Absolutgeschwindigkeitsverteilung im Fluiddar Die angefuumlhrten Bilder sind einem Video entnommen welches dieser Arbeit beiliegt

(a) initiale Geschwindigkeitsverteilung (b) leicht beeinflusste Stroumlmung

(c) schnelle Anwender-Interaktion (d) langsame Anwender-Interaktion

Abbildung 35 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 3 IMPLEMENTIERUNG 21

Wir betrachten hier das Szenario in dem an der oberen Kante des Rechengebiets permanent eine vonNull verschiedene Geschwindigkeit angetragen ist In der unteren linken Ecke des Gebiets befindet sicheine Druckspitze Erlaumluterungen zu diesen Rand- beziehungsweise Anfangsbedingungen finden sich imfolgenden Kapitel Auszligerdem erfolgt im Laufe der Ausfuumlhrung der Simulation eine Interaktion durcheinen AnwenderIn Abbildung 35(a) sehen wir die initiale Verteilung des Geschwindigkeitsfeldes welches anschlieszligenddurch den Anwender leicht gestoumlrt wird was in Abbildung 35(b) zu beobachten ist In Abbildung 35(c)erkennen wir die Entwicklung der Geschwindigkeit im Fluid nach einer schnellen kreisfoumlrmigen Inter-aktion des Anwenders und zuletzt in Abbildung 35(d) das Verhalten des Fluids wenn der Anwendereine langsame Interaktion ausfuumlhrt Dabei koumlnnen wir sehr gut die Stroumlmung erkennen die durch dasAufpraumlgen der externen Kraumlfte ausgeloumlst wird

Kapitel 4

Tests

41 Validierung

In dem ersten Abschnitt dieses Kapitels untersuchen wir die numerische Stabilitaumlt und physikalischeKorrektheit unserer Simulation Wir wollen dies anhand von einfachen Testfaumlllen uumlberpruumlfen Zur Un-tersuchung werden wir sowohl visuelle Darstellungen nutzen als auch Diagramme von Druck- undoderGeschwindigkeitsverlaumlufen

411 Numerische Stabilitaumlt

Wir werden zunaumlchst am einfachsten Testfall Steady uumlberpruumlfen ob unsere Implementierung numerischstabil laumluft Dazu verwenden wir folgende Wahl der Parameter

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (41)

Als Erstes werden wir nun den Testfall Steady beschreiben und erlaumlutern warum sich dieser gut zuruumlberpruumlfung der numerischen Stabilitaumlt eignetIm Testfall Steady setzen wir alle initialen Werte auf Null Das heiszligt in jedem Punkt unseres Gittersherrscht ein Druck von Null die Geschwindigkeit betraumlgt Null und auch wirkt nirgends eine initial ge-setzte Kraft Wir haben also eine ruhige Simulationsumgebung gegeben welche im Folgenden nichtweiter beeinflusst wird da wir bei diesem Test keine Interaktion durch den Anwender erlauben moumlchtenZiel dieses Tests ist es unsere Simulation uumlber einen laumlngeren Zeitraum zu beobachten und zu unter-suchen ob sich trotz allgemeiner Null-Anfangsbedingung Geschwindigkeiten oder Druumlcke einstellenwelche nach unserer Auffassung nicht existieren duumlrften Da unsere farbige Visualisierung lediglich in19 Farben unterteilt wurde koumlnnte es jedoch sein dass beim Auftreten sehr kleiner Geschwindigkeitendiese visuell durch das Verwenden unserer Heat Map nicht in Erscheinung treten Um diesen Effektzu kompensieren werden wir die Druck- beziehungsweise die Geschwindigkeitsvektornorm numerischuntersuchen (vgl Abbildung 41)Wir berechnen somit in jedem Zeitschritt die Norm des Druck- und Geschwindigkeitsvektors und gebenden Verlauf uumlber unser Zeitintervall im nachfolgendem Diagramm 41 wieder Deutlich zu erkennen istdass sowohl die Norm des Druckvektors als auch die des Geschwindigkeitsvektors uumlber unser Zeitin-tervall konstant bei Null bleibt Es tritt also der intuitive Fall ein dass unsere Fluumlssigkeit im Modell beiallgemeinen Null-Anfangsbedinungen auch nach langer Zeit ruhig bleibt und keinerlei Bewegung auf-weistSomit haben wir in unserem ersten Test die Stabilitaumlt unseres Verfahren nachgewiesen koumlnnen je-doch noch keine Angaben dazu machen ob sich unsere Software physikalisch richtig verhaumllt (vgl Ab-schnitt 412)

22

KAPITEL 4 TESTS 23

0 20 40 60 80 100 120 140 160minus1

0

1x 10

minus4

Zeitschritt

Vek

torn

orm

GeschwindigkeitDruck

Abbildung 41 Vektornomen des Druck- und Geschwindigkeitsvektors uumlber mehrere Zeitschritte

412 Physikalisch richtiges Verhalten

Wie schon im vorherigen Kapitel 411 erwaumlhnt werden wir in diesem Abschnitt unsere Software aufdie Korrektheit ihrer Loumlsung untersuchen Wir werden also herausfinden ob sich unsere Simulationphysikalisch richtig verhaumllt Um dies zu erzielen greifen wir auf den gaumlngigen Testfall Driven Cavityzum Testen von Stroumlmungssimulationen zuruumlck

Abbildung 42 Konfiguration fuumlr den Testfall Driven Cavity

Driven Cavity ist ein einfacher Testfall an dem man jedoch viel uumlber die Richtigkeit unserer Imple-mentierung erfahren kann Wir wollen zunaumlchst erlaumlutern welche Testkonfiguration fuumlr Driven Cavitygewaumlhlt werden muss Der wichtigste Schritt ist die richtigen Anfangs- und Randbedingungen vorzu-

KAPITEL 4 TESTS 24

schreiben Ziel bei Driven Cavity ist es an einer Kante unseres Gitters in tangentialer Richtung mitkonstanter Geschwindigkeit v0 kontinuierlich das heiszligt waumlhrend des gesamten Zeitintervalls zu strouml-men wie in Abbildung 42 dargestellt An allen uumlbrigen Kanten wird uumlber das Zeitintervall hinweg Nullvorgeschrieben sowohl in x- als auch in y- Richtung In unserem Fall waumlhlen wir die obere Kante undstroumlmen in positive x-RichtungUm zu erreichen dass wir in jedem Zeitschritt erneut die Geschwindigkeit v0 an der oberen Kante in x-Richtung und Geschwindigkeit Null an den anderen Kanten aufpraumlgen muumlssen wir dies am Ende jedesZeitschritts in unserem Loumlser velocity und am Anfang des Tracer (vgl Kapitel 31) erneut setzenda hier die Randwerte uumlberschrieben werden und wir dies nicht zulassen wollen In den uumlbrigen Teilenunseres Loumlsers muumlssen wir dies nicht tun da hier lediglich die inneren Gitterpunkte behandelt werden(siehe Kapitel 31)Als naumlchstes legen wir nun unsere Parameter wie folgt fest

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (42)

Visuell wird die x-Komponente der Geschwindigkeit dargestellt und es ergibt sich folgendes initialesBild (Abbildung 43)

Abbildung 43 Initale Verteilung der x-Komponete der Geschwindigkeit

Man kann in Abbildung 43 deutlich eine Stroumlmung an der oberen Kannte unseres Gitters erkennengenauso wie wir es vorgegeben haben An allen uumlbrigen Punkten unseres Gitters betraumlgt die Geschwin-digkeit in x-Richtung NullWenn wir unsere Simulation uumlber einen laumlngeren Zeitraum laufen lassen stellen wir fest dass sich diein Abbildung 44 angefuumlhrte Verteilung der Geschwindigkeit einstellt und diese sich auch nach weiterenZeitschritten nicht weiter veraumlndert Um die Korrektheit unserer Loumlsung zu verifizieren vergleichen wirunsere visuelle Darstellung in Abbildung 44(a) mit bekannten richtigen Loumlsungen dieses Testfalls inAbbildung 44(b) Es ist gut zu erkennen dass unsere Darstellung die gleichen Merkmale aufweist wiedas Referenzbild 44(b)Am oberen Rand stellt sich ein Gebiet ein welches groszlige Geschwindigkeiten in x-Richtung aufweist dahier die kontinuierliche Geschwindigkeit v0 eingestellt wird welche jedoch zur Mitte hin immer weiterabnimmt Die Form dieses Gebietes ist bei beiden Bildern bis auf unterschiedliche Faumlrbungen zuruumlck-zufuumlhren auf das Verwenden verschiedener Heat Maps (vgl Kapitel 32) gleich In unserem Fall wirddas Farbspektrum in 19 Farben unterteilt und im Referenzfall in 26 (vgl Kapitel 32 und [CFD Online])In der Mitte schlieszliglich zieht sich ein nahezu stillstehendes Gebiet erkennbar durch die dunkelblaue

KAPITEL 4 TESTS 25

Faumlrbung in die obere rechte Ecke Da es eine sehr groszlige Aumlhnlichkeit zwischen unserem und dem Refe-renzbild gibt koumlnnen wir erwarten dass unsere Stroumlmungssimulation richtig implementiert wurde undeiner physikalisch realistischen Simulation entspricht

(a) Darstellung des Testfalls Driven Cavity nachvielen Zeitschritten

(b) Referenzbild zu Driven Cavity von [CFD Onli-ne]

Abbildung 44 Vergleich unserer Simulation durch ein Referenzbild am Testfall Driven Cavity

Wir gehen somit in den folgenden Kapiteln davon aus dass unsere Software einer physikalisch richtigenSimulation enspricht und numerisch stabil laumluft

KAPITEL 4 TESTS 26

42 Parametertests

In diesem Abschnitt wollen wir den Einfluss verschiedener Parameter auf unsere Simulation am TestfallHubbel (vgl Abbildung 45) untersuchen Als Erstes wollen wir den Einfluss der Viskositaumlt ν wel-ches ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres zugrunde liegenden Fluids darstellt untersuchen Anschlie-szligend befassen wir uns mit dem Zeitschritt ∆t welcher ausschlieszliglich im Tracer (siehe hierzu Kapitel 31) benoumltigt wird und hier ein Maszlig fuumlr die Genauigkeit darstellt Als Letztes werden wir den Ein-fluss der Anzahl der Jacobi-Schritte und damit die Genauigkeitsanforderungen des linearen Loumlsers (vglKapitel 31) untersuchen und anhand der visuellen Darstellung unserer Simulation analysieren wie ge-nau wir loumlsen muumlssen um Symmetrie zu erreichen Sollte unser Verfahren unter der Voraussetzung einessymmetrischen Testfalls symmetrische Ergebnisse liefern so koumlnnen wir von einer sehr guten numeri-schen Approximation einer realen Loumlsung sprechen was in unserem Fall aus einer hohen Genauigkeitdes Druck- und Geschwindigkeitsfeldes resultiertAls Standardkonfiguration waumlhlen wir folgende Werte fuumlr die in unserem Modell frei waumlhlbaren Para-meter

n = 129 h =1

128 ν = 00003 v0 = 000015 ∆t =

1

(nminus 1) middot v0 middot 200 maxiter = 32 (43)

In diesem Fall und anders als im vorherigen Testfall Driven Cavity (vgl Kapitel 412) benoumltigen wirv0 lediglich zur Bestimmung von ∆t da wir im folgenden keine initiale oder kontinuierliche Geschwin-digkeit auftragen wollen Waumlhrend jedes Tests wird ausschlieszliglich ein Parameter veraumlndert um seineAuswirkungen unabhaumlngig von den anderen Groumlszligen analysieren zu koumlnnenAls Ausgangssituation waumlhlen wir den Testfall Hubbel den wir als naumlchstes beschreiben werdenDie initiale Geschwindigkeit und Kraft in jedem Punkt unseres Gitters setzen wir als Null und schreibenfuumlr den Druck Werte so vor dass wir zwei Druckspitzen erhalten (siehe Abbildung 45) Dies realisierenwir mit Hilfe der Gauszligglockenkurve im Zweidimensionalen (siehe Gleichung (44)) da wir so auszliger-halb der Druckspitzen nahezu Null realisieren koumlnnen und wir einen stetigen Druckverlauf sogar Cinfinerzielen

f(x y) = exp(a (xminus x0)2 + a (y minus y0)2 + b

)(44)

Hierbei ist a ein Verzerrungsfaktor und b der Wert im Glockenmittelpunkt (x0 y0) Addieren wir nunzwei Glockenkurven mit a = minus50 b = 0 x1

0 = 05 und y10 = minus05 beziehungsweise x2

0 = minus05 undy2

0 = 05 erhalten wir die folgende initiale Druckverteilung

minus1 minus08 minus06 minus04 minus02 0 02 04 06 08 1minus1

minus050

0510

01

02

03

04

05

06

07

08

09

1

Abbildung 45 Initiale Druckverteilung des Testfalls Hubbel mit zwei Druckspitzen

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 3 IMPLEMENTIERUNG 16

Algorithmus 241 die Poissongleichung (24) fuumlr das Druckfeld pmit der durch Gleichung (219) berech-neten rechten Seite loumlsen Durch die Diskretisierung mit finiten Differenzen erhalten wir wie im Diffusi-onsschritt ein lineares Gleichungssystem Dieses koumlnnen wir nun mit Hilfe der inGleichung (32) hergeleiteten Stencil-Methode fuumlr das Jacobi-Verfahren loumlsen Die Konstanten muumlssenwir dabei als α = minush2 und β = 4 waumlhlen Auch in diesem Fall koumlnnen wir so nur die Werte im In-neren des Gitters berechnen Um Werte an den Raumlndern zu erhalten muumlssen wir die Randbedingungenfuumlr den Druck beruumlcksichtigen (vgl Abschnitt 22) Wir gehen in unserem Fall davon aus dass fuumlr denDruck Neumann-Null-Randbedingungen gelten was bedeutet dass die Ableitung in Normalenrichtungam Rand verschwindet Dazu betrachten wir den einseitigen Differenzenquotienten erster Ordnung fuumlrdie erste Ableitung beispielhaft an einem Punkt des linken Randes (vgl Abbildung 32(b)) Stellen wirihn nach pij um erhalten wir

pprimeij =pij minus pi+1j

h

= 0hArr pij = pi+1j (33)

Es ergibt sich dass wir die Druckwerte am Rand des Gebiets als den Wert des Drucks im naumlchst innerenPunkt in negativer Normalenrichtung setzen In den Ecken des Gebiets definieren wir zunaumlchst sowohldie Ableitung in x- als auch in y-Richtung als Normalenableitung Deshalb setzen wir den Druck in denEckpunkten als Mittel der Druckwerte in den benachbarten RandpunktenUm den Projektionsschritt abzuschlieszligen verwenden wir zur Diskretisierung des Druckgradienten nablapdie in Gleichung (218) angefuumlhrte Diskretisierung Anschlieszligend koumlnnen wirnablap berechnen indem wirwie bei der Berechnung der Divergenz vorgehen Aus Gleichung (33) folgt dass wir den Gradienten anden Gebietskanten in Normalenrichtung zu Null setzen koumlnnen anstatt ihn uumlber einseitige Differenzen-quotienten zu approximieren In den Ecken schreiben wir sowohl fuumlr die Ableitung in x- als auch die iny-Richtung Null vorNachdem wir uns in diesem Abschnitt mit der Umsetzung von Algorithmus 241 beschaumlftigt habengehen wir in den folgenden Unterkapiteln auf spezielle Elemente der App-Programmierung ein Dazubetrachten wir zunaumlchst die Visualisierung der Simulation und widmen uns spaumlter der Realisierung derInteraktion

32 Visualisierung

Die Stroumlmungssimulation die wir in dieser Arbeit vorstellen entsteht durch das unterschiedliche Faumlrbenvon Punkten in unserem diskreten Gitter Durch die Aumlnderung dieser Faumlrbung in jedem Zeitschritt wirdder Eindruck erweckt dass das Fluid was sich in dem diskretisierten Rechengebiet befinden soll stroumlmtZur Visualisierung der Simulation benoumltigen wir somit zwei Komponenten die Darstellung des Rechen-gebiets auf dem Bildschirm und die spezielle Faumlrbung der Gitterpunkte gemaumlszlig der Geschwindigkeits-beziehungsweise DruckwerteBei der Umsetzung der Visualisierung haben wir uns an [Learn OpenGL ES] und [Android Developer]orientiert Wir erlaumlutern zunaumlchst wie wir das zweidimensionale Rechengebiet aufbauen und gehen an-schlieszligend auf das Faumlrben der Gitterpunkte ein Das Ausgangsobjekt zur Bildung des zweidimensionalenquadratischen Rechengebiets ist ein Dreieck Setzen wir mehrere rechtwinklige Dreiecke mit Kathetender Laumlnge h isin R die der Gitterschrittweite entspricht passend aneinander so koumlnnen wir ein beliebigesRechengebiet erzeugenDa wir jedoch nicht das Einheitsquadrat [0 1]2 sondern das Quadrat [minus1 1]2 als Rechengebiet verwen-den muumlssen wir uns dem Aufbau dieses Gebiets genauer widmen da die Kantenlaumlnge des QuadratsAuswirkungen auf die Wahl der Gitterschrittweite h hat Dazu betrachten wir zunaumlchst Abbildung 32in der wir sowohl das Einheitsquadrat als auch unser Rechengebiet [minus1 1]2 darstellen Schreiben wir fuumlrdas Einheitsquadrat in Abbildung 32(a) die Anzahl n der Stuumltzstellen vor so ergibt sich als Gitterschritt-weite hlowast = 1

nminus1 Betrachten wir nun das groszlige Quadrat in Abbildung 32(b) mit einer Seitenlaumlnge von

KAPITEL 3 IMPLEMENTIERUNG 17

2 und schreiben hier ebenfalls n als Anzahl der Stuumltzstellen vor so erhalten wir die Schrittweite durchh = 2hlowast = 2

nminus1 also eine doppelt so groszlige Schrittweite wie im Fall des Einheitsquadrats

(a) Einheitsquadrat (b) Rechengebiet

Abbildung 32 Quadrate zum Aufbau des Rechengebiets

Da wir in unserer Implementierung aufgrund des mittig auf dem Bildschirm gelegenen Koordinatenur-sprungs das groszlige Quadrat zur Diskretisierung nutzen muumlssen wir auch in allen Teilproblemen eineSchrittweite von h = 2hlowast verwendenIm Folgenden erlaumlutern wir wie wir das Gitter auf dem Bildschirm darstellen Zum Zeichnen nutzen wireine Standardfunktion von OpenGL ES 20 welche die Dreiecke die zur Visualisierung des Rechen-gebiets auf dem Bildschirm noumltig sind darstellt Diese Methode traumlgt den Namen drawArrays undverlangt neben der Eingabe der Positionsdaten der Gitterpunkte auch die Farbwerte fuumlr jeden Punkt diewir jeweils in einem Array speichern Um die Positionen der Gitterpunkte zu bestimmen muumlssen wir fuumlrjeden Punkt eine x- y- und z-Komponente angeben Die Positionsdaten legen wir im Konstruktor derKlasse fest da sie nur ein Mal gesetzt werden muumlssen und sich dann nicht mehr aumlndern weil im Laufeder Simulation die Gitterweite nicht variiert Es genuumlgt fuumlr die Koordinaten der Gitterpunkte nur dieersten beiden Komponenten zu beruumlcksichtigen und die z-Koordinate auf Null zu setzen weil wir unsauf einem zweidimensionalen Gebiet befinden

Abbildung 33 Vorgehen der drawArrays-Methode fuumlr h = 13

KAPITEL 3 IMPLEMENTIERUNG 18

Die drawArrays-Routine zeichnet die Gitterpunkte beziehungsweise die Dreiecke danach in der Rei-henfolge wie sie im Positionsarray auftauchen Also muumlssen wir die Daten im Positionsarray so anord-nen dass drei aufeinander folgende Punkte ein Dreieck bilden Zur Veranschaulichung betrachten wirAbbildung 33 Stellen wir die Punkte im Positionsarray ihrer Reihenfolge nach auf dem Bildschirm darso geben wir die meisten Knoten des Gitters mehrfach wieder Die Nummern an den Knoten geben anin welchem Schritt des Zeichnens der entsprechende Punkt abgebildet wird Wir koumlnnen ihnen entneh-men wie oft ein Gitterpunkt im Laufe des Gitteraufbaus gezeichnet wird Im oberen rechten Quadrat inAbbildung 33 stellen wir das Vorgehen der drawArrays-Methode anhand der roten Pfeile dar MitHilfe dieser Zeichenroutine haben wir also die Moumlglichkeit jeden Punkt in unserem Gitter durch einenEckpunkt eines Dreiecks darzustellenDie eigentliche Simulation des Fluidverhaltens erfolgt wie oben beschrieben durch die Farben diewir den Gitterpunkten zuordnen Im Gegensatz zum Positionsarray muumlssen wir die Faumlrbung in jedemZeitschritt aktualisieren um die Simulation zu ermoumlglichen Diese entsteht schlieszliglich dadurch dass wirnach jedem Zeitschritt das neu gefaumlrbte Gitter den neuen Frame zeichnen Zur Definition der Farbe eineseinzelnen Gitterpunktes benoumltigen wir dabei vier double-Eintraumlge die den Rot- Blau und Gruumlnanteilsowie den Transparenzkoeffizienten angeben Durch die Funktion colourSet die in Quellcode 32angefuumlhrt ist weisen wir dem Wert value im i-ten Gitterpunkt seine entsprechenden Farbwerte zuDie Groumlszlige value repraumlsentiert dabei die Geschwindigkeit des Fluids oder den Druck der auf das Fluidwirkt Die Farbwerte speichern wir danach im Array colour und uumlbertragen diesen anschlieszligend inden globalen Farbvektor Colours der die Farbe eines jeden Gitterpunktes genau ein Mal enthaumllt

Quellcode 32 Codeausschnitt aus der drawGrid-Methode

f o r ( i =0 i lt 4N i +=4)c o l o u r S e t ( double va lue double [ ] c o l o u r ) C o l o u r s [ i ] = c o l o u r [ 0 ] C o l o u r s [ i +1] = c o l o u r [ 1 ] C o l o u r s [ i +2] = c o l o u r [ 2 ] C o l o u r s [ i +3] = c o l o u r [ 3 ]

Das Faumlrben der Gitterpunkte erfolgt genau in der gleichen Reihenfolge wie das Zeichnen des GittersWie im Positionsarray muumlssen wir die Farbdaten im ColourData-Array so anordnen dass drei auf-einander folgende Punkte ein Dreieck bilden Es ist moumlglich die Gitterpunkte von verschiedenen Seitenunterschiedlich zu faumlrben da die zugewiesene Faumlrbung immer nur innerhalb eines Dreiecks gilt In Abbil-dung 33 koumlnnen wir einen inneren Gitterpunkt von sechs Seiten faumlrben da er an sechs Dreiecke grenztUm eine sinnvolle Faumlrbung des Gitters zu erhalten und Spruumlnge in dieser zu vermeiden muumlssen wir dieGitterpunkte von jeder Seite gleich faumlrben Dies realisieren wir im Quellcode durch eine for-Schleifein der wir in dem Farbarray ColourData an jede Stelle die den selben Gitterpunkt repraumlsentiert diezugehoumlrigen vier Eintraumlge aus dem Colours-Array schreiben Um die Gitterpunkte mit einer Farbe zuversehen die dem Wert der vorliegenden Groumlszlige entspricht verwenden wir eine sogenannte Heat MapIn unserem Fall greifen wir auf ein Spektrum von 19 Farben zuruumlck wobei blau gefaumlrbte Punkte sehrkleine Geschwindigkeiten beziehungsweise Druumlcke repraumlsentieren und rot gefaumlrbte entsprechend groszligeDie Faumlrbung einer Dreiecksflaumlche resultiert aus der Interpolation der Farben seiner Eckpunkte Die Wahlder genauen Uumlbergaumlnge zwischen den einzelnen Farben variiert von Testfall zu Testfall In Abschnitt 42bedienen wir uns einer nicht-aumlquidistanten Zerlegung des Farbspektrums und unterscheiden im Bereichder kleinen Druumlcke genauer da der Maximaldruck nur fuumlr eine sehr kurze Zeitspanne angenommen wirdund anschlieszligend lediglich kleine bis mittelgroszlige Druumlcke auftreten In Unterkapitel 412 verwenden wirhingegen eine aumlquidistante Unterteilung des FarbspektrumsUm dieses Kapitel zur Implementierung abzuschlieszligen erlaumlutern wir im folgenden Abschnitt die Umset-zung der Interaktion in unserer Software die den wesentlichen Bestandteil der interaktiven Stroumlmungs-simulation ausmacht

KAPITEL 3 IMPLEMENTIERUNG 19

33 Interaktion

Der Schritt der die Stroumlmungssimulation interaktiv werden laumlsst ist das Aufpraumlgen einer Kraft durchdas Beruumlhren des Bildschirms durch den Anwender Zunaumlchst gehen wir darauf ein wie wir die Finger-position auf dem Bildschirm in unser Gitter uumlbertragen und erlaumlutern anschlieszligend wie wir die Kraftermitteln die durch die Interaktion auf das simulierte Fluid uumlbertragen wirdDas zentrale Problem dem wir bei der Anwender-Interaktion gegenuumlberstehen ergibt sich aus den ver-schiedenen Zeichenebenen die in OpenGL ES 20 zur Verfuumlgung stehen um dreidimensionale Ob-jekte darzustellen Zur Veranschaulichung betrachten wir Abbildung 34

Abbildung 34 Visualisierungsraum von OpenGL ES 20 (vgl [SongHo])

Alle Objekte die wir mit OpenGL ES 20 darstellen speichern wir zuerst im dreidimensionalenRaum der Objekt-Koordinaten Anschlieszligend projizieren wir diese auf die zweidimensionale Benutzer-oberflaumlche den Bildschirm was die Darstellung dreidimensionaler Koumlrper ermoumlglicht Wir koumlnnen unsleicht uumlberlegen dass die Bildschirmkoordinaten nicht den Objektkoordinaten entsprechen Die Bild-schirmkoordinaten der Fingerposition die wir zur Realisierung der Simulation registrieren muumlssen ge-ben also nicht die Position des Fingers in dem Gitter des Rechengebiets an Diese benoumltigen wir jedochum an der richtigen Stelle eine Kraft auf das simulierte Fluid aufzupraumlgen Wir sind somit auf eineTransformation angewiesen die die Bildschirmkoordinaten des Fingers welche wir mittels einer Stan-dardfunktion von OpenGL ES 20 leicht auslesen koumlnnen auf die entsprechenden Objektkoordinatenabbildet Eine solche Transformation stellt die Funktion worldCoords dar bei deren Implementierungwir uns an [Verdia] orientiert haben Fuumlr weiterfuumlhrende Informationen bezuumlglich Bildschirm- und Ob-jektkoordinaten verweisen wir auf [SongHo]Um auf die Anwender-Interaktion reagieren zu koumlnnen verwenden wir die Methode onTouchEventwelche von OpenGL ES 20 bereitgestellt wird Dabei handelt es sich um eine sogenannte bdquoCallbackldquo-Funktion was bedeutet dass sie vom System automatisch aufgerufen wird Dies geschieht genau dannwenn der Nutzer den Bildschirm beruumlhrt Wie wir in Kapitel 44 sehen erfolgt die Simulation nichtin Echtzeit was sich vor allem mit der langen Rechenzeit des Loumlsers erklaumlren laumlsst Auf dem vonuns verwendeten Geraumlt steht uns eine CPU mit zwei Kernen beziehungsweise Threads zur VerfuumlgungAuf dem einen fuumlhren wir die Berechnungen aus und auf dem anderen die Visualisierung inklusiveder TouchEvent-Abfragen Aufgrund der oben beschriebenen Verzoumlgerung ist es moumlglich mehrereAufrufe der onTouchEvent-Routine pro Zeitschritt durchzufuumlhren also Abfragen nach sogenanntenTouchEvents Wir uumlberpruumlfen dabei ob der Anwender den Bildschirm beruumlhrt oder nicht Die Kon-sequenzen die dieses Vorgehen auf die Laufzeit der Simulation hat untersuchen wir in Abschnitt 443Pro Zeitschritt beruumlcksichtigen wir nur die Ergebnisse des ersten TouchEventsDie Behandlung von TouchEvents geschieht wie folgt Sollte der Bildschirm beruumlhrt werden wirddie Funktion onTouchEvent aufgerufen Zuerst lesen wir die Position des Fingers in Bildschirm-

KAPITEL 3 IMPLEMENTIERUNG 20

koordinaten mit Hilfe der Funktion getX beziehungsweise getY aus Danach transformieren wir siein Objektkoordinaten Aus der Position des Fingers im vorherigen Zeitschritt koumlnnen wir die Streckeermitteln die der Finger von einem Zeitschritt zum naumlchsten zuruumlckgelegt hat Daraus ergeben sichdann die Positionsaumlnderungen dx in x- und dy in y-Richtung Hierbei setzen wir nicht voraus dassdie Position in Objektkoordinaten einem Gitterpunkt entspricht Da wir eine Kraft jedoch nur in einemsolchen Gitterpunkt aufpraumlgen koumlnnen ermitteln wir den Knoten der am naumlchsten zu den Objektkoor-dinaten der Fingerposition liegt In diesem Punkt setzen wir dann die Kraft in x-Richtung als dx unddie in y-Richtung als dy wodurch gewaumlhrleistet ist dass wir bei schnellerer Bewegung des Fingersdem Fluid eine groumlszligere Kraft aufpraumlgen Das Aufpraumlgen der Kraft erfolgt nun durch Aumlnderungen derEintraumlge im force-Array die zu dem Gitterpunkt gehoumlren in dem die Kraft angreifen soll Mit Hilfevon if-Abfragen in der onTouchEvent-Methode stellen wir sicher dass ein TouchEvent nur dannberuumlcksichtigt wird wenn die Objektkoordinaten der Fingerposition innerhalb des Rechengebiets liegenZur Vorbereitung des naumlchsten Zeitschritts setzen wir am Ende des Loumlsers die zuvor veraumlnderten Eintraumlgeim force-Array wieder zu Null da eine Kraft nur innerhalb eines Zeitschritts wirken soll

34 Demonstration des Gesamtsystems

In den vorherigen Kapiteln haben wir ein Verfahren zur numerischen Loumlsung der Navier-Stokes Glei-chungen hergeleitet und dessen Umsetzung auf Tablet-Computern erlaumlutert Bevor wir in Kapitel 4 einegenauere Analyse der Implementierung durchfuumlhren wollen wir vorab einen ersten Eindruck der Simu-lation vermitteln Dazu stellen wir in Abbildung 35 eine Absolutgeschwindigkeitsverteilung im Fluiddar Die angefuumlhrten Bilder sind einem Video entnommen welches dieser Arbeit beiliegt

(a) initiale Geschwindigkeitsverteilung (b) leicht beeinflusste Stroumlmung

(c) schnelle Anwender-Interaktion (d) langsame Anwender-Interaktion

Abbildung 35 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 3 IMPLEMENTIERUNG 21

Wir betrachten hier das Szenario in dem an der oberen Kante des Rechengebiets permanent eine vonNull verschiedene Geschwindigkeit angetragen ist In der unteren linken Ecke des Gebiets befindet sicheine Druckspitze Erlaumluterungen zu diesen Rand- beziehungsweise Anfangsbedingungen finden sich imfolgenden Kapitel Auszligerdem erfolgt im Laufe der Ausfuumlhrung der Simulation eine Interaktion durcheinen AnwenderIn Abbildung 35(a) sehen wir die initiale Verteilung des Geschwindigkeitsfeldes welches anschlieszligenddurch den Anwender leicht gestoumlrt wird was in Abbildung 35(b) zu beobachten ist In Abbildung 35(c)erkennen wir die Entwicklung der Geschwindigkeit im Fluid nach einer schnellen kreisfoumlrmigen Inter-aktion des Anwenders und zuletzt in Abbildung 35(d) das Verhalten des Fluids wenn der Anwendereine langsame Interaktion ausfuumlhrt Dabei koumlnnen wir sehr gut die Stroumlmung erkennen die durch dasAufpraumlgen der externen Kraumlfte ausgeloumlst wird

Kapitel 4

Tests

41 Validierung

In dem ersten Abschnitt dieses Kapitels untersuchen wir die numerische Stabilitaumlt und physikalischeKorrektheit unserer Simulation Wir wollen dies anhand von einfachen Testfaumlllen uumlberpruumlfen Zur Un-tersuchung werden wir sowohl visuelle Darstellungen nutzen als auch Diagramme von Druck- undoderGeschwindigkeitsverlaumlufen

411 Numerische Stabilitaumlt

Wir werden zunaumlchst am einfachsten Testfall Steady uumlberpruumlfen ob unsere Implementierung numerischstabil laumluft Dazu verwenden wir folgende Wahl der Parameter

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (41)

Als Erstes werden wir nun den Testfall Steady beschreiben und erlaumlutern warum sich dieser gut zuruumlberpruumlfung der numerischen Stabilitaumlt eignetIm Testfall Steady setzen wir alle initialen Werte auf Null Das heiszligt in jedem Punkt unseres Gittersherrscht ein Druck von Null die Geschwindigkeit betraumlgt Null und auch wirkt nirgends eine initial ge-setzte Kraft Wir haben also eine ruhige Simulationsumgebung gegeben welche im Folgenden nichtweiter beeinflusst wird da wir bei diesem Test keine Interaktion durch den Anwender erlauben moumlchtenZiel dieses Tests ist es unsere Simulation uumlber einen laumlngeren Zeitraum zu beobachten und zu unter-suchen ob sich trotz allgemeiner Null-Anfangsbedingung Geschwindigkeiten oder Druumlcke einstellenwelche nach unserer Auffassung nicht existieren duumlrften Da unsere farbige Visualisierung lediglich in19 Farben unterteilt wurde koumlnnte es jedoch sein dass beim Auftreten sehr kleiner Geschwindigkeitendiese visuell durch das Verwenden unserer Heat Map nicht in Erscheinung treten Um diesen Effektzu kompensieren werden wir die Druck- beziehungsweise die Geschwindigkeitsvektornorm numerischuntersuchen (vgl Abbildung 41)Wir berechnen somit in jedem Zeitschritt die Norm des Druck- und Geschwindigkeitsvektors und gebenden Verlauf uumlber unser Zeitintervall im nachfolgendem Diagramm 41 wieder Deutlich zu erkennen istdass sowohl die Norm des Druckvektors als auch die des Geschwindigkeitsvektors uumlber unser Zeitin-tervall konstant bei Null bleibt Es tritt also der intuitive Fall ein dass unsere Fluumlssigkeit im Modell beiallgemeinen Null-Anfangsbedinungen auch nach langer Zeit ruhig bleibt und keinerlei Bewegung auf-weistSomit haben wir in unserem ersten Test die Stabilitaumlt unseres Verfahren nachgewiesen koumlnnen je-doch noch keine Angaben dazu machen ob sich unsere Software physikalisch richtig verhaumllt (vgl Ab-schnitt 412)

22

KAPITEL 4 TESTS 23

0 20 40 60 80 100 120 140 160minus1

0

1x 10

minus4

Zeitschritt

Vek

torn

orm

GeschwindigkeitDruck

Abbildung 41 Vektornomen des Druck- und Geschwindigkeitsvektors uumlber mehrere Zeitschritte

412 Physikalisch richtiges Verhalten

Wie schon im vorherigen Kapitel 411 erwaumlhnt werden wir in diesem Abschnitt unsere Software aufdie Korrektheit ihrer Loumlsung untersuchen Wir werden also herausfinden ob sich unsere Simulationphysikalisch richtig verhaumllt Um dies zu erzielen greifen wir auf den gaumlngigen Testfall Driven Cavityzum Testen von Stroumlmungssimulationen zuruumlck

Abbildung 42 Konfiguration fuumlr den Testfall Driven Cavity

Driven Cavity ist ein einfacher Testfall an dem man jedoch viel uumlber die Richtigkeit unserer Imple-mentierung erfahren kann Wir wollen zunaumlchst erlaumlutern welche Testkonfiguration fuumlr Driven Cavitygewaumlhlt werden muss Der wichtigste Schritt ist die richtigen Anfangs- und Randbedingungen vorzu-

KAPITEL 4 TESTS 24

schreiben Ziel bei Driven Cavity ist es an einer Kante unseres Gitters in tangentialer Richtung mitkonstanter Geschwindigkeit v0 kontinuierlich das heiszligt waumlhrend des gesamten Zeitintervalls zu strouml-men wie in Abbildung 42 dargestellt An allen uumlbrigen Kanten wird uumlber das Zeitintervall hinweg Nullvorgeschrieben sowohl in x- als auch in y- Richtung In unserem Fall waumlhlen wir die obere Kante undstroumlmen in positive x-RichtungUm zu erreichen dass wir in jedem Zeitschritt erneut die Geschwindigkeit v0 an der oberen Kante in x-Richtung und Geschwindigkeit Null an den anderen Kanten aufpraumlgen muumlssen wir dies am Ende jedesZeitschritts in unserem Loumlser velocity und am Anfang des Tracer (vgl Kapitel 31) erneut setzenda hier die Randwerte uumlberschrieben werden und wir dies nicht zulassen wollen In den uumlbrigen Teilenunseres Loumlsers muumlssen wir dies nicht tun da hier lediglich die inneren Gitterpunkte behandelt werden(siehe Kapitel 31)Als naumlchstes legen wir nun unsere Parameter wie folgt fest

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (42)

Visuell wird die x-Komponente der Geschwindigkeit dargestellt und es ergibt sich folgendes initialesBild (Abbildung 43)

Abbildung 43 Initale Verteilung der x-Komponete der Geschwindigkeit

Man kann in Abbildung 43 deutlich eine Stroumlmung an der oberen Kannte unseres Gitters erkennengenauso wie wir es vorgegeben haben An allen uumlbrigen Punkten unseres Gitters betraumlgt die Geschwin-digkeit in x-Richtung NullWenn wir unsere Simulation uumlber einen laumlngeren Zeitraum laufen lassen stellen wir fest dass sich diein Abbildung 44 angefuumlhrte Verteilung der Geschwindigkeit einstellt und diese sich auch nach weiterenZeitschritten nicht weiter veraumlndert Um die Korrektheit unserer Loumlsung zu verifizieren vergleichen wirunsere visuelle Darstellung in Abbildung 44(a) mit bekannten richtigen Loumlsungen dieses Testfalls inAbbildung 44(b) Es ist gut zu erkennen dass unsere Darstellung die gleichen Merkmale aufweist wiedas Referenzbild 44(b)Am oberen Rand stellt sich ein Gebiet ein welches groszlige Geschwindigkeiten in x-Richtung aufweist dahier die kontinuierliche Geschwindigkeit v0 eingestellt wird welche jedoch zur Mitte hin immer weiterabnimmt Die Form dieses Gebietes ist bei beiden Bildern bis auf unterschiedliche Faumlrbungen zuruumlck-zufuumlhren auf das Verwenden verschiedener Heat Maps (vgl Kapitel 32) gleich In unserem Fall wirddas Farbspektrum in 19 Farben unterteilt und im Referenzfall in 26 (vgl Kapitel 32 und [CFD Online])In der Mitte schlieszliglich zieht sich ein nahezu stillstehendes Gebiet erkennbar durch die dunkelblaue

KAPITEL 4 TESTS 25

Faumlrbung in die obere rechte Ecke Da es eine sehr groszlige Aumlhnlichkeit zwischen unserem und dem Refe-renzbild gibt koumlnnen wir erwarten dass unsere Stroumlmungssimulation richtig implementiert wurde undeiner physikalisch realistischen Simulation entspricht

(a) Darstellung des Testfalls Driven Cavity nachvielen Zeitschritten

(b) Referenzbild zu Driven Cavity von [CFD Onli-ne]

Abbildung 44 Vergleich unserer Simulation durch ein Referenzbild am Testfall Driven Cavity

Wir gehen somit in den folgenden Kapiteln davon aus dass unsere Software einer physikalisch richtigenSimulation enspricht und numerisch stabil laumluft

KAPITEL 4 TESTS 26

42 Parametertests

In diesem Abschnitt wollen wir den Einfluss verschiedener Parameter auf unsere Simulation am TestfallHubbel (vgl Abbildung 45) untersuchen Als Erstes wollen wir den Einfluss der Viskositaumlt ν wel-ches ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres zugrunde liegenden Fluids darstellt untersuchen Anschlie-szligend befassen wir uns mit dem Zeitschritt ∆t welcher ausschlieszliglich im Tracer (siehe hierzu Kapitel 31) benoumltigt wird und hier ein Maszlig fuumlr die Genauigkeit darstellt Als Letztes werden wir den Ein-fluss der Anzahl der Jacobi-Schritte und damit die Genauigkeitsanforderungen des linearen Loumlsers (vglKapitel 31) untersuchen und anhand der visuellen Darstellung unserer Simulation analysieren wie ge-nau wir loumlsen muumlssen um Symmetrie zu erreichen Sollte unser Verfahren unter der Voraussetzung einessymmetrischen Testfalls symmetrische Ergebnisse liefern so koumlnnen wir von einer sehr guten numeri-schen Approximation einer realen Loumlsung sprechen was in unserem Fall aus einer hohen Genauigkeitdes Druck- und Geschwindigkeitsfeldes resultiertAls Standardkonfiguration waumlhlen wir folgende Werte fuumlr die in unserem Modell frei waumlhlbaren Para-meter

n = 129 h =1

128 ν = 00003 v0 = 000015 ∆t =

1

(nminus 1) middot v0 middot 200 maxiter = 32 (43)

In diesem Fall und anders als im vorherigen Testfall Driven Cavity (vgl Kapitel 412) benoumltigen wirv0 lediglich zur Bestimmung von ∆t da wir im folgenden keine initiale oder kontinuierliche Geschwin-digkeit auftragen wollen Waumlhrend jedes Tests wird ausschlieszliglich ein Parameter veraumlndert um seineAuswirkungen unabhaumlngig von den anderen Groumlszligen analysieren zu koumlnnenAls Ausgangssituation waumlhlen wir den Testfall Hubbel den wir als naumlchstes beschreiben werdenDie initiale Geschwindigkeit und Kraft in jedem Punkt unseres Gitters setzen wir als Null und schreibenfuumlr den Druck Werte so vor dass wir zwei Druckspitzen erhalten (siehe Abbildung 45) Dies realisierenwir mit Hilfe der Gauszligglockenkurve im Zweidimensionalen (siehe Gleichung (44)) da wir so auszliger-halb der Druckspitzen nahezu Null realisieren koumlnnen und wir einen stetigen Druckverlauf sogar Cinfinerzielen

f(x y) = exp(a (xminus x0)2 + a (y minus y0)2 + b

)(44)

Hierbei ist a ein Verzerrungsfaktor und b der Wert im Glockenmittelpunkt (x0 y0) Addieren wir nunzwei Glockenkurven mit a = minus50 b = 0 x1

0 = 05 und y10 = minus05 beziehungsweise x2

0 = minus05 undy2

0 = 05 erhalten wir die folgende initiale Druckverteilung

minus1 minus08 minus06 minus04 minus02 0 02 04 06 08 1minus1

minus050

0510

01

02

03

04

05

06

07

08

09

1

Abbildung 45 Initiale Druckverteilung des Testfalls Hubbel mit zwei Druckspitzen

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 3 IMPLEMENTIERUNG 17

2 und schreiben hier ebenfalls n als Anzahl der Stuumltzstellen vor so erhalten wir die Schrittweite durchh = 2hlowast = 2

nminus1 also eine doppelt so groszlige Schrittweite wie im Fall des Einheitsquadrats

(a) Einheitsquadrat (b) Rechengebiet

Abbildung 32 Quadrate zum Aufbau des Rechengebiets

Da wir in unserer Implementierung aufgrund des mittig auf dem Bildschirm gelegenen Koordinatenur-sprungs das groszlige Quadrat zur Diskretisierung nutzen muumlssen wir auch in allen Teilproblemen eineSchrittweite von h = 2hlowast verwendenIm Folgenden erlaumlutern wir wie wir das Gitter auf dem Bildschirm darstellen Zum Zeichnen nutzen wireine Standardfunktion von OpenGL ES 20 welche die Dreiecke die zur Visualisierung des Rechen-gebiets auf dem Bildschirm noumltig sind darstellt Diese Methode traumlgt den Namen drawArrays undverlangt neben der Eingabe der Positionsdaten der Gitterpunkte auch die Farbwerte fuumlr jeden Punkt diewir jeweils in einem Array speichern Um die Positionen der Gitterpunkte zu bestimmen muumlssen wir fuumlrjeden Punkt eine x- y- und z-Komponente angeben Die Positionsdaten legen wir im Konstruktor derKlasse fest da sie nur ein Mal gesetzt werden muumlssen und sich dann nicht mehr aumlndern weil im Laufeder Simulation die Gitterweite nicht variiert Es genuumlgt fuumlr die Koordinaten der Gitterpunkte nur dieersten beiden Komponenten zu beruumlcksichtigen und die z-Koordinate auf Null zu setzen weil wir unsauf einem zweidimensionalen Gebiet befinden

Abbildung 33 Vorgehen der drawArrays-Methode fuumlr h = 13

KAPITEL 3 IMPLEMENTIERUNG 18

Die drawArrays-Routine zeichnet die Gitterpunkte beziehungsweise die Dreiecke danach in der Rei-henfolge wie sie im Positionsarray auftauchen Also muumlssen wir die Daten im Positionsarray so anord-nen dass drei aufeinander folgende Punkte ein Dreieck bilden Zur Veranschaulichung betrachten wirAbbildung 33 Stellen wir die Punkte im Positionsarray ihrer Reihenfolge nach auf dem Bildschirm darso geben wir die meisten Knoten des Gitters mehrfach wieder Die Nummern an den Knoten geben anin welchem Schritt des Zeichnens der entsprechende Punkt abgebildet wird Wir koumlnnen ihnen entneh-men wie oft ein Gitterpunkt im Laufe des Gitteraufbaus gezeichnet wird Im oberen rechten Quadrat inAbbildung 33 stellen wir das Vorgehen der drawArrays-Methode anhand der roten Pfeile dar MitHilfe dieser Zeichenroutine haben wir also die Moumlglichkeit jeden Punkt in unserem Gitter durch einenEckpunkt eines Dreiecks darzustellenDie eigentliche Simulation des Fluidverhaltens erfolgt wie oben beschrieben durch die Farben diewir den Gitterpunkten zuordnen Im Gegensatz zum Positionsarray muumlssen wir die Faumlrbung in jedemZeitschritt aktualisieren um die Simulation zu ermoumlglichen Diese entsteht schlieszliglich dadurch dass wirnach jedem Zeitschritt das neu gefaumlrbte Gitter den neuen Frame zeichnen Zur Definition der Farbe eineseinzelnen Gitterpunktes benoumltigen wir dabei vier double-Eintraumlge die den Rot- Blau und Gruumlnanteilsowie den Transparenzkoeffizienten angeben Durch die Funktion colourSet die in Quellcode 32angefuumlhrt ist weisen wir dem Wert value im i-ten Gitterpunkt seine entsprechenden Farbwerte zuDie Groumlszlige value repraumlsentiert dabei die Geschwindigkeit des Fluids oder den Druck der auf das Fluidwirkt Die Farbwerte speichern wir danach im Array colour und uumlbertragen diesen anschlieszligend inden globalen Farbvektor Colours der die Farbe eines jeden Gitterpunktes genau ein Mal enthaumllt

Quellcode 32 Codeausschnitt aus der drawGrid-Methode

f o r ( i =0 i lt 4N i +=4)c o l o u r S e t ( double va lue double [ ] c o l o u r ) C o l o u r s [ i ] = c o l o u r [ 0 ] C o l o u r s [ i +1] = c o l o u r [ 1 ] C o l o u r s [ i +2] = c o l o u r [ 2 ] C o l o u r s [ i +3] = c o l o u r [ 3 ]

Das Faumlrben der Gitterpunkte erfolgt genau in der gleichen Reihenfolge wie das Zeichnen des GittersWie im Positionsarray muumlssen wir die Farbdaten im ColourData-Array so anordnen dass drei auf-einander folgende Punkte ein Dreieck bilden Es ist moumlglich die Gitterpunkte von verschiedenen Seitenunterschiedlich zu faumlrben da die zugewiesene Faumlrbung immer nur innerhalb eines Dreiecks gilt In Abbil-dung 33 koumlnnen wir einen inneren Gitterpunkt von sechs Seiten faumlrben da er an sechs Dreiecke grenztUm eine sinnvolle Faumlrbung des Gitters zu erhalten und Spruumlnge in dieser zu vermeiden muumlssen wir dieGitterpunkte von jeder Seite gleich faumlrben Dies realisieren wir im Quellcode durch eine for-Schleifein der wir in dem Farbarray ColourData an jede Stelle die den selben Gitterpunkt repraumlsentiert diezugehoumlrigen vier Eintraumlge aus dem Colours-Array schreiben Um die Gitterpunkte mit einer Farbe zuversehen die dem Wert der vorliegenden Groumlszlige entspricht verwenden wir eine sogenannte Heat MapIn unserem Fall greifen wir auf ein Spektrum von 19 Farben zuruumlck wobei blau gefaumlrbte Punkte sehrkleine Geschwindigkeiten beziehungsweise Druumlcke repraumlsentieren und rot gefaumlrbte entsprechend groszligeDie Faumlrbung einer Dreiecksflaumlche resultiert aus der Interpolation der Farben seiner Eckpunkte Die Wahlder genauen Uumlbergaumlnge zwischen den einzelnen Farben variiert von Testfall zu Testfall In Abschnitt 42bedienen wir uns einer nicht-aumlquidistanten Zerlegung des Farbspektrums und unterscheiden im Bereichder kleinen Druumlcke genauer da der Maximaldruck nur fuumlr eine sehr kurze Zeitspanne angenommen wirdund anschlieszligend lediglich kleine bis mittelgroszlige Druumlcke auftreten In Unterkapitel 412 verwenden wirhingegen eine aumlquidistante Unterteilung des FarbspektrumsUm dieses Kapitel zur Implementierung abzuschlieszligen erlaumlutern wir im folgenden Abschnitt die Umset-zung der Interaktion in unserer Software die den wesentlichen Bestandteil der interaktiven Stroumlmungs-simulation ausmacht

KAPITEL 3 IMPLEMENTIERUNG 19

33 Interaktion

Der Schritt der die Stroumlmungssimulation interaktiv werden laumlsst ist das Aufpraumlgen einer Kraft durchdas Beruumlhren des Bildschirms durch den Anwender Zunaumlchst gehen wir darauf ein wie wir die Finger-position auf dem Bildschirm in unser Gitter uumlbertragen und erlaumlutern anschlieszligend wie wir die Kraftermitteln die durch die Interaktion auf das simulierte Fluid uumlbertragen wirdDas zentrale Problem dem wir bei der Anwender-Interaktion gegenuumlberstehen ergibt sich aus den ver-schiedenen Zeichenebenen die in OpenGL ES 20 zur Verfuumlgung stehen um dreidimensionale Ob-jekte darzustellen Zur Veranschaulichung betrachten wir Abbildung 34

Abbildung 34 Visualisierungsraum von OpenGL ES 20 (vgl [SongHo])

Alle Objekte die wir mit OpenGL ES 20 darstellen speichern wir zuerst im dreidimensionalenRaum der Objekt-Koordinaten Anschlieszligend projizieren wir diese auf die zweidimensionale Benutzer-oberflaumlche den Bildschirm was die Darstellung dreidimensionaler Koumlrper ermoumlglicht Wir koumlnnen unsleicht uumlberlegen dass die Bildschirmkoordinaten nicht den Objektkoordinaten entsprechen Die Bild-schirmkoordinaten der Fingerposition die wir zur Realisierung der Simulation registrieren muumlssen ge-ben also nicht die Position des Fingers in dem Gitter des Rechengebiets an Diese benoumltigen wir jedochum an der richtigen Stelle eine Kraft auf das simulierte Fluid aufzupraumlgen Wir sind somit auf eineTransformation angewiesen die die Bildschirmkoordinaten des Fingers welche wir mittels einer Stan-dardfunktion von OpenGL ES 20 leicht auslesen koumlnnen auf die entsprechenden Objektkoordinatenabbildet Eine solche Transformation stellt die Funktion worldCoords dar bei deren Implementierungwir uns an [Verdia] orientiert haben Fuumlr weiterfuumlhrende Informationen bezuumlglich Bildschirm- und Ob-jektkoordinaten verweisen wir auf [SongHo]Um auf die Anwender-Interaktion reagieren zu koumlnnen verwenden wir die Methode onTouchEventwelche von OpenGL ES 20 bereitgestellt wird Dabei handelt es sich um eine sogenannte bdquoCallbackldquo-Funktion was bedeutet dass sie vom System automatisch aufgerufen wird Dies geschieht genau dannwenn der Nutzer den Bildschirm beruumlhrt Wie wir in Kapitel 44 sehen erfolgt die Simulation nichtin Echtzeit was sich vor allem mit der langen Rechenzeit des Loumlsers erklaumlren laumlsst Auf dem vonuns verwendeten Geraumlt steht uns eine CPU mit zwei Kernen beziehungsweise Threads zur VerfuumlgungAuf dem einen fuumlhren wir die Berechnungen aus und auf dem anderen die Visualisierung inklusiveder TouchEvent-Abfragen Aufgrund der oben beschriebenen Verzoumlgerung ist es moumlglich mehrereAufrufe der onTouchEvent-Routine pro Zeitschritt durchzufuumlhren also Abfragen nach sogenanntenTouchEvents Wir uumlberpruumlfen dabei ob der Anwender den Bildschirm beruumlhrt oder nicht Die Kon-sequenzen die dieses Vorgehen auf die Laufzeit der Simulation hat untersuchen wir in Abschnitt 443Pro Zeitschritt beruumlcksichtigen wir nur die Ergebnisse des ersten TouchEventsDie Behandlung von TouchEvents geschieht wie folgt Sollte der Bildschirm beruumlhrt werden wirddie Funktion onTouchEvent aufgerufen Zuerst lesen wir die Position des Fingers in Bildschirm-

KAPITEL 3 IMPLEMENTIERUNG 20

koordinaten mit Hilfe der Funktion getX beziehungsweise getY aus Danach transformieren wir siein Objektkoordinaten Aus der Position des Fingers im vorherigen Zeitschritt koumlnnen wir die Streckeermitteln die der Finger von einem Zeitschritt zum naumlchsten zuruumlckgelegt hat Daraus ergeben sichdann die Positionsaumlnderungen dx in x- und dy in y-Richtung Hierbei setzen wir nicht voraus dassdie Position in Objektkoordinaten einem Gitterpunkt entspricht Da wir eine Kraft jedoch nur in einemsolchen Gitterpunkt aufpraumlgen koumlnnen ermitteln wir den Knoten der am naumlchsten zu den Objektkoor-dinaten der Fingerposition liegt In diesem Punkt setzen wir dann die Kraft in x-Richtung als dx unddie in y-Richtung als dy wodurch gewaumlhrleistet ist dass wir bei schnellerer Bewegung des Fingersdem Fluid eine groumlszligere Kraft aufpraumlgen Das Aufpraumlgen der Kraft erfolgt nun durch Aumlnderungen derEintraumlge im force-Array die zu dem Gitterpunkt gehoumlren in dem die Kraft angreifen soll Mit Hilfevon if-Abfragen in der onTouchEvent-Methode stellen wir sicher dass ein TouchEvent nur dannberuumlcksichtigt wird wenn die Objektkoordinaten der Fingerposition innerhalb des Rechengebiets liegenZur Vorbereitung des naumlchsten Zeitschritts setzen wir am Ende des Loumlsers die zuvor veraumlnderten Eintraumlgeim force-Array wieder zu Null da eine Kraft nur innerhalb eines Zeitschritts wirken soll

34 Demonstration des Gesamtsystems

In den vorherigen Kapiteln haben wir ein Verfahren zur numerischen Loumlsung der Navier-Stokes Glei-chungen hergeleitet und dessen Umsetzung auf Tablet-Computern erlaumlutert Bevor wir in Kapitel 4 einegenauere Analyse der Implementierung durchfuumlhren wollen wir vorab einen ersten Eindruck der Simu-lation vermitteln Dazu stellen wir in Abbildung 35 eine Absolutgeschwindigkeitsverteilung im Fluiddar Die angefuumlhrten Bilder sind einem Video entnommen welches dieser Arbeit beiliegt

(a) initiale Geschwindigkeitsverteilung (b) leicht beeinflusste Stroumlmung

(c) schnelle Anwender-Interaktion (d) langsame Anwender-Interaktion

Abbildung 35 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 3 IMPLEMENTIERUNG 21

Wir betrachten hier das Szenario in dem an der oberen Kante des Rechengebiets permanent eine vonNull verschiedene Geschwindigkeit angetragen ist In der unteren linken Ecke des Gebiets befindet sicheine Druckspitze Erlaumluterungen zu diesen Rand- beziehungsweise Anfangsbedingungen finden sich imfolgenden Kapitel Auszligerdem erfolgt im Laufe der Ausfuumlhrung der Simulation eine Interaktion durcheinen AnwenderIn Abbildung 35(a) sehen wir die initiale Verteilung des Geschwindigkeitsfeldes welches anschlieszligenddurch den Anwender leicht gestoumlrt wird was in Abbildung 35(b) zu beobachten ist In Abbildung 35(c)erkennen wir die Entwicklung der Geschwindigkeit im Fluid nach einer schnellen kreisfoumlrmigen Inter-aktion des Anwenders und zuletzt in Abbildung 35(d) das Verhalten des Fluids wenn der Anwendereine langsame Interaktion ausfuumlhrt Dabei koumlnnen wir sehr gut die Stroumlmung erkennen die durch dasAufpraumlgen der externen Kraumlfte ausgeloumlst wird

Kapitel 4

Tests

41 Validierung

In dem ersten Abschnitt dieses Kapitels untersuchen wir die numerische Stabilitaumlt und physikalischeKorrektheit unserer Simulation Wir wollen dies anhand von einfachen Testfaumlllen uumlberpruumlfen Zur Un-tersuchung werden wir sowohl visuelle Darstellungen nutzen als auch Diagramme von Druck- undoderGeschwindigkeitsverlaumlufen

411 Numerische Stabilitaumlt

Wir werden zunaumlchst am einfachsten Testfall Steady uumlberpruumlfen ob unsere Implementierung numerischstabil laumluft Dazu verwenden wir folgende Wahl der Parameter

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (41)

Als Erstes werden wir nun den Testfall Steady beschreiben und erlaumlutern warum sich dieser gut zuruumlberpruumlfung der numerischen Stabilitaumlt eignetIm Testfall Steady setzen wir alle initialen Werte auf Null Das heiszligt in jedem Punkt unseres Gittersherrscht ein Druck von Null die Geschwindigkeit betraumlgt Null und auch wirkt nirgends eine initial ge-setzte Kraft Wir haben also eine ruhige Simulationsumgebung gegeben welche im Folgenden nichtweiter beeinflusst wird da wir bei diesem Test keine Interaktion durch den Anwender erlauben moumlchtenZiel dieses Tests ist es unsere Simulation uumlber einen laumlngeren Zeitraum zu beobachten und zu unter-suchen ob sich trotz allgemeiner Null-Anfangsbedingung Geschwindigkeiten oder Druumlcke einstellenwelche nach unserer Auffassung nicht existieren duumlrften Da unsere farbige Visualisierung lediglich in19 Farben unterteilt wurde koumlnnte es jedoch sein dass beim Auftreten sehr kleiner Geschwindigkeitendiese visuell durch das Verwenden unserer Heat Map nicht in Erscheinung treten Um diesen Effektzu kompensieren werden wir die Druck- beziehungsweise die Geschwindigkeitsvektornorm numerischuntersuchen (vgl Abbildung 41)Wir berechnen somit in jedem Zeitschritt die Norm des Druck- und Geschwindigkeitsvektors und gebenden Verlauf uumlber unser Zeitintervall im nachfolgendem Diagramm 41 wieder Deutlich zu erkennen istdass sowohl die Norm des Druckvektors als auch die des Geschwindigkeitsvektors uumlber unser Zeitin-tervall konstant bei Null bleibt Es tritt also der intuitive Fall ein dass unsere Fluumlssigkeit im Modell beiallgemeinen Null-Anfangsbedinungen auch nach langer Zeit ruhig bleibt und keinerlei Bewegung auf-weistSomit haben wir in unserem ersten Test die Stabilitaumlt unseres Verfahren nachgewiesen koumlnnen je-doch noch keine Angaben dazu machen ob sich unsere Software physikalisch richtig verhaumllt (vgl Ab-schnitt 412)

22

KAPITEL 4 TESTS 23

0 20 40 60 80 100 120 140 160minus1

0

1x 10

minus4

Zeitschritt

Vek

torn

orm

GeschwindigkeitDruck

Abbildung 41 Vektornomen des Druck- und Geschwindigkeitsvektors uumlber mehrere Zeitschritte

412 Physikalisch richtiges Verhalten

Wie schon im vorherigen Kapitel 411 erwaumlhnt werden wir in diesem Abschnitt unsere Software aufdie Korrektheit ihrer Loumlsung untersuchen Wir werden also herausfinden ob sich unsere Simulationphysikalisch richtig verhaumllt Um dies zu erzielen greifen wir auf den gaumlngigen Testfall Driven Cavityzum Testen von Stroumlmungssimulationen zuruumlck

Abbildung 42 Konfiguration fuumlr den Testfall Driven Cavity

Driven Cavity ist ein einfacher Testfall an dem man jedoch viel uumlber die Richtigkeit unserer Imple-mentierung erfahren kann Wir wollen zunaumlchst erlaumlutern welche Testkonfiguration fuumlr Driven Cavitygewaumlhlt werden muss Der wichtigste Schritt ist die richtigen Anfangs- und Randbedingungen vorzu-

KAPITEL 4 TESTS 24

schreiben Ziel bei Driven Cavity ist es an einer Kante unseres Gitters in tangentialer Richtung mitkonstanter Geschwindigkeit v0 kontinuierlich das heiszligt waumlhrend des gesamten Zeitintervalls zu strouml-men wie in Abbildung 42 dargestellt An allen uumlbrigen Kanten wird uumlber das Zeitintervall hinweg Nullvorgeschrieben sowohl in x- als auch in y- Richtung In unserem Fall waumlhlen wir die obere Kante undstroumlmen in positive x-RichtungUm zu erreichen dass wir in jedem Zeitschritt erneut die Geschwindigkeit v0 an der oberen Kante in x-Richtung und Geschwindigkeit Null an den anderen Kanten aufpraumlgen muumlssen wir dies am Ende jedesZeitschritts in unserem Loumlser velocity und am Anfang des Tracer (vgl Kapitel 31) erneut setzenda hier die Randwerte uumlberschrieben werden und wir dies nicht zulassen wollen In den uumlbrigen Teilenunseres Loumlsers muumlssen wir dies nicht tun da hier lediglich die inneren Gitterpunkte behandelt werden(siehe Kapitel 31)Als naumlchstes legen wir nun unsere Parameter wie folgt fest

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (42)

Visuell wird die x-Komponente der Geschwindigkeit dargestellt und es ergibt sich folgendes initialesBild (Abbildung 43)

Abbildung 43 Initale Verteilung der x-Komponete der Geschwindigkeit

Man kann in Abbildung 43 deutlich eine Stroumlmung an der oberen Kannte unseres Gitters erkennengenauso wie wir es vorgegeben haben An allen uumlbrigen Punkten unseres Gitters betraumlgt die Geschwin-digkeit in x-Richtung NullWenn wir unsere Simulation uumlber einen laumlngeren Zeitraum laufen lassen stellen wir fest dass sich diein Abbildung 44 angefuumlhrte Verteilung der Geschwindigkeit einstellt und diese sich auch nach weiterenZeitschritten nicht weiter veraumlndert Um die Korrektheit unserer Loumlsung zu verifizieren vergleichen wirunsere visuelle Darstellung in Abbildung 44(a) mit bekannten richtigen Loumlsungen dieses Testfalls inAbbildung 44(b) Es ist gut zu erkennen dass unsere Darstellung die gleichen Merkmale aufweist wiedas Referenzbild 44(b)Am oberen Rand stellt sich ein Gebiet ein welches groszlige Geschwindigkeiten in x-Richtung aufweist dahier die kontinuierliche Geschwindigkeit v0 eingestellt wird welche jedoch zur Mitte hin immer weiterabnimmt Die Form dieses Gebietes ist bei beiden Bildern bis auf unterschiedliche Faumlrbungen zuruumlck-zufuumlhren auf das Verwenden verschiedener Heat Maps (vgl Kapitel 32) gleich In unserem Fall wirddas Farbspektrum in 19 Farben unterteilt und im Referenzfall in 26 (vgl Kapitel 32 und [CFD Online])In der Mitte schlieszliglich zieht sich ein nahezu stillstehendes Gebiet erkennbar durch die dunkelblaue

KAPITEL 4 TESTS 25

Faumlrbung in die obere rechte Ecke Da es eine sehr groszlige Aumlhnlichkeit zwischen unserem und dem Refe-renzbild gibt koumlnnen wir erwarten dass unsere Stroumlmungssimulation richtig implementiert wurde undeiner physikalisch realistischen Simulation entspricht

(a) Darstellung des Testfalls Driven Cavity nachvielen Zeitschritten

(b) Referenzbild zu Driven Cavity von [CFD Onli-ne]

Abbildung 44 Vergleich unserer Simulation durch ein Referenzbild am Testfall Driven Cavity

Wir gehen somit in den folgenden Kapiteln davon aus dass unsere Software einer physikalisch richtigenSimulation enspricht und numerisch stabil laumluft

KAPITEL 4 TESTS 26

42 Parametertests

In diesem Abschnitt wollen wir den Einfluss verschiedener Parameter auf unsere Simulation am TestfallHubbel (vgl Abbildung 45) untersuchen Als Erstes wollen wir den Einfluss der Viskositaumlt ν wel-ches ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres zugrunde liegenden Fluids darstellt untersuchen Anschlie-szligend befassen wir uns mit dem Zeitschritt ∆t welcher ausschlieszliglich im Tracer (siehe hierzu Kapitel 31) benoumltigt wird und hier ein Maszlig fuumlr die Genauigkeit darstellt Als Letztes werden wir den Ein-fluss der Anzahl der Jacobi-Schritte und damit die Genauigkeitsanforderungen des linearen Loumlsers (vglKapitel 31) untersuchen und anhand der visuellen Darstellung unserer Simulation analysieren wie ge-nau wir loumlsen muumlssen um Symmetrie zu erreichen Sollte unser Verfahren unter der Voraussetzung einessymmetrischen Testfalls symmetrische Ergebnisse liefern so koumlnnen wir von einer sehr guten numeri-schen Approximation einer realen Loumlsung sprechen was in unserem Fall aus einer hohen Genauigkeitdes Druck- und Geschwindigkeitsfeldes resultiertAls Standardkonfiguration waumlhlen wir folgende Werte fuumlr die in unserem Modell frei waumlhlbaren Para-meter

n = 129 h =1

128 ν = 00003 v0 = 000015 ∆t =

1

(nminus 1) middot v0 middot 200 maxiter = 32 (43)

In diesem Fall und anders als im vorherigen Testfall Driven Cavity (vgl Kapitel 412) benoumltigen wirv0 lediglich zur Bestimmung von ∆t da wir im folgenden keine initiale oder kontinuierliche Geschwin-digkeit auftragen wollen Waumlhrend jedes Tests wird ausschlieszliglich ein Parameter veraumlndert um seineAuswirkungen unabhaumlngig von den anderen Groumlszligen analysieren zu koumlnnenAls Ausgangssituation waumlhlen wir den Testfall Hubbel den wir als naumlchstes beschreiben werdenDie initiale Geschwindigkeit und Kraft in jedem Punkt unseres Gitters setzen wir als Null und schreibenfuumlr den Druck Werte so vor dass wir zwei Druckspitzen erhalten (siehe Abbildung 45) Dies realisierenwir mit Hilfe der Gauszligglockenkurve im Zweidimensionalen (siehe Gleichung (44)) da wir so auszliger-halb der Druckspitzen nahezu Null realisieren koumlnnen und wir einen stetigen Druckverlauf sogar Cinfinerzielen

f(x y) = exp(a (xminus x0)2 + a (y minus y0)2 + b

)(44)

Hierbei ist a ein Verzerrungsfaktor und b der Wert im Glockenmittelpunkt (x0 y0) Addieren wir nunzwei Glockenkurven mit a = minus50 b = 0 x1

0 = 05 und y10 = minus05 beziehungsweise x2

0 = minus05 undy2

0 = 05 erhalten wir die folgende initiale Druckverteilung

minus1 minus08 minus06 minus04 minus02 0 02 04 06 08 1minus1

minus050

0510

01

02

03

04

05

06

07

08

09

1

Abbildung 45 Initiale Druckverteilung des Testfalls Hubbel mit zwei Druckspitzen

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 3 IMPLEMENTIERUNG 18

Die drawArrays-Routine zeichnet die Gitterpunkte beziehungsweise die Dreiecke danach in der Rei-henfolge wie sie im Positionsarray auftauchen Also muumlssen wir die Daten im Positionsarray so anord-nen dass drei aufeinander folgende Punkte ein Dreieck bilden Zur Veranschaulichung betrachten wirAbbildung 33 Stellen wir die Punkte im Positionsarray ihrer Reihenfolge nach auf dem Bildschirm darso geben wir die meisten Knoten des Gitters mehrfach wieder Die Nummern an den Knoten geben anin welchem Schritt des Zeichnens der entsprechende Punkt abgebildet wird Wir koumlnnen ihnen entneh-men wie oft ein Gitterpunkt im Laufe des Gitteraufbaus gezeichnet wird Im oberen rechten Quadrat inAbbildung 33 stellen wir das Vorgehen der drawArrays-Methode anhand der roten Pfeile dar MitHilfe dieser Zeichenroutine haben wir also die Moumlglichkeit jeden Punkt in unserem Gitter durch einenEckpunkt eines Dreiecks darzustellenDie eigentliche Simulation des Fluidverhaltens erfolgt wie oben beschrieben durch die Farben diewir den Gitterpunkten zuordnen Im Gegensatz zum Positionsarray muumlssen wir die Faumlrbung in jedemZeitschritt aktualisieren um die Simulation zu ermoumlglichen Diese entsteht schlieszliglich dadurch dass wirnach jedem Zeitschritt das neu gefaumlrbte Gitter den neuen Frame zeichnen Zur Definition der Farbe eineseinzelnen Gitterpunktes benoumltigen wir dabei vier double-Eintraumlge die den Rot- Blau und Gruumlnanteilsowie den Transparenzkoeffizienten angeben Durch die Funktion colourSet die in Quellcode 32angefuumlhrt ist weisen wir dem Wert value im i-ten Gitterpunkt seine entsprechenden Farbwerte zuDie Groumlszlige value repraumlsentiert dabei die Geschwindigkeit des Fluids oder den Druck der auf das Fluidwirkt Die Farbwerte speichern wir danach im Array colour und uumlbertragen diesen anschlieszligend inden globalen Farbvektor Colours der die Farbe eines jeden Gitterpunktes genau ein Mal enthaumllt

Quellcode 32 Codeausschnitt aus der drawGrid-Methode

f o r ( i =0 i lt 4N i +=4)c o l o u r S e t ( double va lue double [ ] c o l o u r ) C o l o u r s [ i ] = c o l o u r [ 0 ] C o l o u r s [ i +1] = c o l o u r [ 1 ] C o l o u r s [ i +2] = c o l o u r [ 2 ] C o l o u r s [ i +3] = c o l o u r [ 3 ]

Das Faumlrben der Gitterpunkte erfolgt genau in der gleichen Reihenfolge wie das Zeichnen des GittersWie im Positionsarray muumlssen wir die Farbdaten im ColourData-Array so anordnen dass drei auf-einander folgende Punkte ein Dreieck bilden Es ist moumlglich die Gitterpunkte von verschiedenen Seitenunterschiedlich zu faumlrben da die zugewiesene Faumlrbung immer nur innerhalb eines Dreiecks gilt In Abbil-dung 33 koumlnnen wir einen inneren Gitterpunkt von sechs Seiten faumlrben da er an sechs Dreiecke grenztUm eine sinnvolle Faumlrbung des Gitters zu erhalten und Spruumlnge in dieser zu vermeiden muumlssen wir dieGitterpunkte von jeder Seite gleich faumlrben Dies realisieren wir im Quellcode durch eine for-Schleifein der wir in dem Farbarray ColourData an jede Stelle die den selben Gitterpunkt repraumlsentiert diezugehoumlrigen vier Eintraumlge aus dem Colours-Array schreiben Um die Gitterpunkte mit einer Farbe zuversehen die dem Wert der vorliegenden Groumlszlige entspricht verwenden wir eine sogenannte Heat MapIn unserem Fall greifen wir auf ein Spektrum von 19 Farben zuruumlck wobei blau gefaumlrbte Punkte sehrkleine Geschwindigkeiten beziehungsweise Druumlcke repraumlsentieren und rot gefaumlrbte entsprechend groszligeDie Faumlrbung einer Dreiecksflaumlche resultiert aus der Interpolation der Farben seiner Eckpunkte Die Wahlder genauen Uumlbergaumlnge zwischen den einzelnen Farben variiert von Testfall zu Testfall In Abschnitt 42bedienen wir uns einer nicht-aumlquidistanten Zerlegung des Farbspektrums und unterscheiden im Bereichder kleinen Druumlcke genauer da der Maximaldruck nur fuumlr eine sehr kurze Zeitspanne angenommen wirdund anschlieszligend lediglich kleine bis mittelgroszlige Druumlcke auftreten In Unterkapitel 412 verwenden wirhingegen eine aumlquidistante Unterteilung des FarbspektrumsUm dieses Kapitel zur Implementierung abzuschlieszligen erlaumlutern wir im folgenden Abschnitt die Umset-zung der Interaktion in unserer Software die den wesentlichen Bestandteil der interaktiven Stroumlmungs-simulation ausmacht

KAPITEL 3 IMPLEMENTIERUNG 19

33 Interaktion

Der Schritt der die Stroumlmungssimulation interaktiv werden laumlsst ist das Aufpraumlgen einer Kraft durchdas Beruumlhren des Bildschirms durch den Anwender Zunaumlchst gehen wir darauf ein wie wir die Finger-position auf dem Bildschirm in unser Gitter uumlbertragen und erlaumlutern anschlieszligend wie wir die Kraftermitteln die durch die Interaktion auf das simulierte Fluid uumlbertragen wirdDas zentrale Problem dem wir bei der Anwender-Interaktion gegenuumlberstehen ergibt sich aus den ver-schiedenen Zeichenebenen die in OpenGL ES 20 zur Verfuumlgung stehen um dreidimensionale Ob-jekte darzustellen Zur Veranschaulichung betrachten wir Abbildung 34

Abbildung 34 Visualisierungsraum von OpenGL ES 20 (vgl [SongHo])

Alle Objekte die wir mit OpenGL ES 20 darstellen speichern wir zuerst im dreidimensionalenRaum der Objekt-Koordinaten Anschlieszligend projizieren wir diese auf die zweidimensionale Benutzer-oberflaumlche den Bildschirm was die Darstellung dreidimensionaler Koumlrper ermoumlglicht Wir koumlnnen unsleicht uumlberlegen dass die Bildschirmkoordinaten nicht den Objektkoordinaten entsprechen Die Bild-schirmkoordinaten der Fingerposition die wir zur Realisierung der Simulation registrieren muumlssen ge-ben also nicht die Position des Fingers in dem Gitter des Rechengebiets an Diese benoumltigen wir jedochum an der richtigen Stelle eine Kraft auf das simulierte Fluid aufzupraumlgen Wir sind somit auf eineTransformation angewiesen die die Bildschirmkoordinaten des Fingers welche wir mittels einer Stan-dardfunktion von OpenGL ES 20 leicht auslesen koumlnnen auf die entsprechenden Objektkoordinatenabbildet Eine solche Transformation stellt die Funktion worldCoords dar bei deren Implementierungwir uns an [Verdia] orientiert haben Fuumlr weiterfuumlhrende Informationen bezuumlglich Bildschirm- und Ob-jektkoordinaten verweisen wir auf [SongHo]Um auf die Anwender-Interaktion reagieren zu koumlnnen verwenden wir die Methode onTouchEventwelche von OpenGL ES 20 bereitgestellt wird Dabei handelt es sich um eine sogenannte bdquoCallbackldquo-Funktion was bedeutet dass sie vom System automatisch aufgerufen wird Dies geschieht genau dannwenn der Nutzer den Bildschirm beruumlhrt Wie wir in Kapitel 44 sehen erfolgt die Simulation nichtin Echtzeit was sich vor allem mit der langen Rechenzeit des Loumlsers erklaumlren laumlsst Auf dem vonuns verwendeten Geraumlt steht uns eine CPU mit zwei Kernen beziehungsweise Threads zur VerfuumlgungAuf dem einen fuumlhren wir die Berechnungen aus und auf dem anderen die Visualisierung inklusiveder TouchEvent-Abfragen Aufgrund der oben beschriebenen Verzoumlgerung ist es moumlglich mehrereAufrufe der onTouchEvent-Routine pro Zeitschritt durchzufuumlhren also Abfragen nach sogenanntenTouchEvents Wir uumlberpruumlfen dabei ob der Anwender den Bildschirm beruumlhrt oder nicht Die Kon-sequenzen die dieses Vorgehen auf die Laufzeit der Simulation hat untersuchen wir in Abschnitt 443Pro Zeitschritt beruumlcksichtigen wir nur die Ergebnisse des ersten TouchEventsDie Behandlung von TouchEvents geschieht wie folgt Sollte der Bildschirm beruumlhrt werden wirddie Funktion onTouchEvent aufgerufen Zuerst lesen wir die Position des Fingers in Bildschirm-

KAPITEL 3 IMPLEMENTIERUNG 20

koordinaten mit Hilfe der Funktion getX beziehungsweise getY aus Danach transformieren wir siein Objektkoordinaten Aus der Position des Fingers im vorherigen Zeitschritt koumlnnen wir die Streckeermitteln die der Finger von einem Zeitschritt zum naumlchsten zuruumlckgelegt hat Daraus ergeben sichdann die Positionsaumlnderungen dx in x- und dy in y-Richtung Hierbei setzen wir nicht voraus dassdie Position in Objektkoordinaten einem Gitterpunkt entspricht Da wir eine Kraft jedoch nur in einemsolchen Gitterpunkt aufpraumlgen koumlnnen ermitteln wir den Knoten der am naumlchsten zu den Objektkoor-dinaten der Fingerposition liegt In diesem Punkt setzen wir dann die Kraft in x-Richtung als dx unddie in y-Richtung als dy wodurch gewaumlhrleistet ist dass wir bei schnellerer Bewegung des Fingersdem Fluid eine groumlszligere Kraft aufpraumlgen Das Aufpraumlgen der Kraft erfolgt nun durch Aumlnderungen derEintraumlge im force-Array die zu dem Gitterpunkt gehoumlren in dem die Kraft angreifen soll Mit Hilfevon if-Abfragen in der onTouchEvent-Methode stellen wir sicher dass ein TouchEvent nur dannberuumlcksichtigt wird wenn die Objektkoordinaten der Fingerposition innerhalb des Rechengebiets liegenZur Vorbereitung des naumlchsten Zeitschritts setzen wir am Ende des Loumlsers die zuvor veraumlnderten Eintraumlgeim force-Array wieder zu Null da eine Kraft nur innerhalb eines Zeitschritts wirken soll

34 Demonstration des Gesamtsystems

In den vorherigen Kapiteln haben wir ein Verfahren zur numerischen Loumlsung der Navier-Stokes Glei-chungen hergeleitet und dessen Umsetzung auf Tablet-Computern erlaumlutert Bevor wir in Kapitel 4 einegenauere Analyse der Implementierung durchfuumlhren wollen wir vorab einen ersten Eindruck der Simu-lation vermitteln Dazu stellen wir in Abbildung 35 eine Absolutgeschwindigkeitsverteilung im Fluiddar Die angefuumlhrten Bilder sind einem Video entnommen welches dieser Arbeit beiliegt

(a) initiale Geschwindigkeitsverteilung (b) leicht beeinflusste Stroumlmung

(c) schnelle Anwender-Interaktion (d) langsame Anwender-Interaktion

Abbildung 35 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 3 IMPLEMENTIERUNG 21

Wir betrachten hier das Szenario in dem an der oberen Kante des Rechengebiets permanent eine vonNull verschiedene Geschwindigkeit angetragen ist In der unteren linken Ecke des Gebiets befindet sicheine Druckspitze Erlaumluterungen zu diesen Rand- beziehungsweise Anfangsbedingungen finden sich imfolgenden Kapitel Auszligerdem erfolgt im Laufe der Ausfuumlhrung der Simulation eine Interaktion durcheinen AnwenderIn Abbildung 35(a) sehen wir die initiale Verteilung des Geschwindigkeitsfeldes welches anschlieszligenddurch den Anwender leicht gestoumlrt wird was in Abbildung 35(b) zu beobachten ist In Abbildung 35(c)erkennen wir die Entwicklung der Geschwindigkeit im Fluid nach einer schnellen kreisfoumlrmigen Inter-aktion des Anwenders und zuletzt in Abbildung 35(d) das Verhalten des Fluids wenn der Anwendereine langsame Interaktion ausfuumlhrt Dabei koumlnnen wir sehr gut die Stroumlmung erkennen die durch dasAufpraumlgen der externen Kraumlfte ausgeloumlst wird

Kapitel 4

Tests

41 Validierung

In dem ersten Abschnitt dieses Kapitels untersuchen wir die numerische Stabilitaumlt und physikalischeKorrektheit unserer Simulation Wir wollen dies anhand von einfachen Testfaumlllen uumlberpruumlfen Zur Un-tersuchung werden wir sowohl visuelle Darstellungen nutzen als auch Diagramme von Druck- undoderGeschwindigkeitsverlaumlufen

411 Numerische Stabilitaumlt

Wir werden zunaumlchst am einfachsten Testfall Steady uumlberpruumlfen ob unsere Implementierung numerischstabil laumluft Dazu verwenden wir folgende Wahl der Parameter

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (41)

Als Erstes werden wir nun den Testfall Steady beschreiben und erlaumlutern warum sich dieser gut zuruumlberpruumlfung der numerischen Stabilitaumlt eignetIm Testfall Steady setzen wir alle initialen Werte auf Null Das heiszligt in jedem Punkt unseres Gittersherrscht ein Druck von Null die Geschwindigkeit betraumlgt Null und auch wirkt nirgends eine initial ge-setzte Kraft Wir haben also eine ruhige Simulationsumgebung gegeben welche im Folgenden nichtweiter beeinflusst wird da wir bei diesem Test keine Interaktion durch den Anwender erlauben moumlchtenZiel dieses Tests ist es unsere Simulation uumlber einen laumlngeren Zeitraum zu beobachten und zu unter-suchen ob sich trotz allgemeiner Null-Anfangsbedingung Geschwindigkeiten oder Druumlcke einstellenwelche nach unserer Auffassung nicht existieren duumlrften Da unsere farbige Visualisierung lediglich in19 Farben unterteilt wurde koumlnnte es jedoch sein dass beim Auftreten sehr kleiner Geschwindigkeitendiese visuell durch das Verwenden unserer Heat Map nicht in Erscheinung treten Um diesen Effektzu kompensieren werden wir die Druck- beziehungsweise die Geschwindigkeitsvektornorm numerischuntersuchen (vgl Abbildung 41)Wir berechnen somit in jedem Zeitschritt die Norm des Druck- und Geschwindigkeitsvektors und gebenden Verlauf uumlber unser Zeitintervall im nachfolgendem Diagramm 41 wieder Deutlich zu erkennen istdass sowohl die Norm des Druckvektors als auch die des Geschwindigkeitsvektors uumlber unser Zeitin-tervall konstant bei Null bleibt Es tritt also der intuitive Fall ein dass unsere Fluumlssigkeit im Modell beiallgemeinen Null-Anfangsbedinungen auch nach langer Zeit ruhig bleibt und keinerlei Bewegung auf-weistSomit haben wir in unserem ersten Test die Stabilitaumlt unseres Verfahren nachgewiesen koumlnnen je-doch noch keine Angaben dazu machen ob sich unsere Software physikalisch richtig verhaumllt (vgl Ab-schnitt 412)

22

KAPITEL 4 TESTS 23

0 20 40 60 80 100 120 140 160minus1

0

1x 10

minus4

Zeitschritt

Vek

torn

orm

GeschwindigkeitDruck

Abbildung 41 Vektornomen des Druck- und Geschwindigkeitsvektors uumlber mehrere Zeitschritte

412 Physikalisch richtiges Verhalten

Wie schon im vorherigen Kapitel 411 erwaumlhnt werden wir in diesem Abschnitt unsere Software aufdie Korrektheit ihrer Loumlsung untersuchen Wir werden also herausfinden ob sich unsere Simulationphysikalisch richtig verhaumllt Um dies zu erzielen greifen wir auf den gaumlngigen Testfall Driven Cavityzum Testen von Stroumlmungssimulationen zuruumlck

Abbildung 42 Konfiguration fuumlr den Testfall Driven Cavity

Driven Cavity ist ein einfacher Testfall an dem man jedoch viel uumlber die Richtigkeit unserer Imple-mentierung erfahren kann Wir wollen zunaumlchst erlaumlutern welche Testkonfiguration fuumlr Driven Cavitygewaumlhlt werden muss Der wichtigste Schritt ist die richtigen Anfangs- und Randbedingungen vorzu-

KAPITEL 4 TESTS 24

schreiben Ziel bei Driven Cavity ist es an einer Kante unseres Gitters in tangentialer Richtung mitkonstanter Geschwindigkeit v0 kontinuierlich das heiszligt waumlhrend des gesamten Zeitintervalls zu strouml-men wie in Abbildung 42 dargestellt An allen uumlbrigen Kanten wird uumlber das Zeitintervall hinweg Nullvorgeschrieben sowohl in x- als auch in y- Richtung In unserem Fall waumlhlen wir die obere Kante undstroumlmen in positive x-RichtungUm zu erreichen dass wir in jedem Zeitschritt erneut die Geschwindigkeit v0 an der oberen Kante in x-Richtung und Geschwindigkeit Null an den anderen Kanten aufpraumlgen muumlssen wir dies am Ende jedesZeitschritts in unserem Loumlser velocity und am Anfang des Tracer (vgl Kapitel 31) erneut setzenda hier die Randwerte uumlberschrieben werden und wir dies nicht zulassen wollen In den uumlbrigen Teilenunseres Loumlsers muumlssen wir dies nicht tun da hier lediglich die inneren Gitterpunkte behandelt werden(siehe Kapitel 31)Als naumlchstes legen wir nun unsere Parameter wie folgt fest

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (42)

Visuell wird die x-Komponente der Geschwindigkeit dargestellt und es ergibt sich folgendes initialesBild (Abbildung 43)

Abbildung 43 Initale Verteilung der x-Komponete der Geschwindigkeit

Man kann in Abbildung 43 deutlich eine Stroumlmung an der oberen Kannte unseres Gitters erkennengenauso wie wir es vorgegeben haben An allen uumlbrigen Punkten unseres Gitters betraumlgt die Geschwin-digkeit in x-Richtung NullWenn wir unsere Simulation uumlber einen laumlngeren Zeitraum laufen lassen stellen wir fest dass sich diein Abbildung 44 angefuumlhrte Verteilung der Geschwindigkeit einstellt und diese sich auch nach weiterenZeitschritten nicht weiter veraumlndert Um die Korrektheit unserer Loumlsung zu verifizieren vergleichen wirunsere visuelle Darstellung in Abbildung 44(a) mit bekannten richtigen Loumlsungen dieses Testfalls inAbbildung 44(b) Es ist gut zu erkennen dass unsere Darstellung die gleichen Merkmale aufweist wiedas Referenzbild 44(b)Am oberen Rand stellt sich ein Gebiet ein welches groszlige Geschwindigkeiten in x-Richtung aufweist dahier die kontinuierliche Geschwindigkeit v0 eingestellt wird welche jedoch zur Mitte hin immer weiterabnimmt Die Form dieses Gebietes ist bei beiden Bildern bis auf unterschiedliche Faumlrbungen zuruumlck-zufuumlhren auf das Verwenden verschiedener Heat Maps (vgl Kapitel 32) gleich In unserem Fall wirddas Farbspektrum in 19 Farben unterteilt und im Referenzfall in 26 (vgl Kapitel 32 und [CFD Online])In der Mitte schlieszliglich zieht sich ein nahezu stillstehendes Gebiet erkennbar durch die dunkelblaue

KAPITEL 4 TESTS 25

Faumlrbung in die obere rechte Ecke Da es eine sehr groszlige Aumlhnlichkeit zwischen unserem und dem Refe-renzbild gibt koumlnnen wir erwarten dass unsere Stroumlmungssimulation richtig implementiert wurde undeiner physikalisch realistischen Simulation entspricht

(a) Darstellung des Testfalls Driven Cavity nachvielen Zeitschritten

(b) Referenzbild zu Driven Cavity von [CFD Onli-ne]

Abbildung 44 Vergleich unserer Simulation durch ein Referenzbild am Testfall Driven Cavity

Wir gehen somit in den folgenden Kapiteln davon aus dass unsere Software einer physikalisch richtigenSimulation enspricht und numerisch stabil laumluft

KAPITEL 4 TESTS 26

42 Parametertests

In diesem Abschnitt wollen wir den Einfluss verschiedener Parameter auf unsere Simulation am TestfallHubbel (vgl Abbildung 45) untersuchen Als Erstes wollen wir den Einfluss der Viskositaumlt ν wel-ches ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres zugrunde liegenden Fluids darstellt untersuchen Anschlie-szligend befassen wir uns mit dem Zeitschritt ∆t welcher ausschlieszliglich im Tracer (siehe hierzu Kapitel 31) benoumltigt wird und hier ein Maszlig fuumlr die Genauigkeit darstellt Als Letztes werden wir den Ein-fluss der Anzahl der Jacobi-Schritte und damit die Genauigkeitsanforderungen des linearen Loumlsers (vglKapitel 31) untersuchen und anhand der visuellen Darstellung unserer Simulation analysieren wie ge-nau wir loumlsen muumlssen um Symmetrie zu erreichen Sollte unser Verfahren unter der Voraussetzung einessymmetrischen Testfalls symmetrische Ergebnisse liefern so koumlnnen wir von einer sehr guten numeri-schen Approximation einer realen Loumlsung sprechen was in unserem Fall aus einer hohen Genauigkeitdes Druck- und Geschwindigkeitsfeldes resultiertAls Standardkonfiguration waumlhlen wir folgende Werte fuumlr die in unserem Modell frei waumlhlbaren Para-meter

n = 129 h =1

128 ν = 00003 v0 = 000015 ∆t =

1

(nminus 1) middot v0 middot 200 maxiter = 32 (43)

In diesem Fall und anders als im vorherigen Testfall Driven Cavity (vgl Kapitel 412) benoumltigen wirv0 lediglich zur Bestimmung von ∆t da wir im folgenden keine initiale oder kontinuierliche Geschwin-digkeit auftragen wollen Waumlhrend jedes Tests wird ausschlieszliglich ein Parameter veraumlndert um seineAuswirkungen unabhaumlngig von den anderen Groumlszligen analysieren zu koumlnnenAls Ausgangssituation waumlhlen wir den Testfall Hubbel den wir als naumlchstes beschreiben werdenDie initiale Geschwindigkeit und Kraft in jedem Punkt unseres Gitters setzen wir als Null und schreibenfuumlr den Druck Werte so vor dass wir zwei Druckspitzen erhalten (siehe Abbildung 45) Dies realisierenwir mit Hilfe der Gauszligglockenkurve im Zweidimensionalen (siehe Gleichung (44)) da wir so auszliger-halb der Druckspitzen nahezu Null realisieren koumlnnen und wir einen stetigen Druckverlauf sogar Cinfinerzielen

f(x y) = exp(a (xminus x0)2 + a (y minus y0)2 + b

)(44)

Hierbei ist a ein Verzerrungsfaktor und b der Wert im Glockenmittelpunkt (x0 y0) Addieren wir nunzwei Glockenkurven mit a = minus50 b = 0 x1

0 = 05 und y10 = minus05 beziehungsweise x2

0 = minus05 undy2

0 = 05 erhalten wir die folgende initiale Druckverteilung

minus1 minus08 minus06 minus04 minus02 0 02 04 06 08 1minus1

minus050

0510

01

02

03

04

05

06

07

08

09

1

Abbildung 45 Initiale Druckverteilung des Testfalls Hubbel mit zwei Druckspitzen

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 3 IMPLEMENTIERUNG 19

33 Interaktion

Der Schritt der die Stroumlmungssimulation interaktiv werden laumlsst ist das Aufpraumlgen einer Kraft durchdas Beruumlhren des Bildschirms durch den Anwender Zunaumlchst gehen wir darauf ein wie wir die Finger-position auf dem Bildschirm in unser Gitter uumlbertragen und erlaumlutern anschlieszligend wie wir die Kraftermitteln die durch die Interaktion auf das simulierte Fluid uumlbertragen wirdDas zentrale Problem dem wir bei der Anwender-Interaktion gegenuumlberstehen ergibt sich aus den ver-schiedenen Zeichenebenen die in OpenGL ES 20 zur Verfuumlgung stehen um dreidimensionale Ob-jekte darzustellen Zur Veranschaulichung betrachten wir Abbildung 34

Abbildung 34 Visualisierungsraum von OpenGL ES 20 (vgl [SongHo])

Alle Objekte die wir mit OpenGL ES 20 darstellen speichern wir zuerst im dreidimensionalenRaum der Objekt-Koordinaten Anschlieszligend projizieren wir diese auf die zweidimensionale Benutzer-oberflaumlche den Bildschirm was die Darstellung dreidimensionaler Koumlrper ermoumlglicht Wir koumlnnen unsleicht uumlberlegen dass die Bildschirmkoordinaten nicht den Objektkoordinaten entsprechen Die Bild-schirmkoordinaten der Fingerposition die wir zur Realisierung der Simulation registrieren muumlssen ge-ben also nicht die Position des Fingers in dem Gitter des Rechengebiets an Diese benoumltigen wir jedochum an der richtigen Stelle eine Kraft auf das simulierte Fluid aufzupraumlgen Wir sind somit auf eineTransformation angewiesen die die Bildschirmkoordinaten des Fingers welche wir mittels einer Stan-dardfunktion von OpenGL ES 20 leicht auslesen koumlnnen auf die entsprechenden Objektkoordinatenabbildet Eine solche Transformation stellt die Funktion worldCoords dar bei deren Implementierungwir uns an [Verdia] orientiert haben Fuumlr weiterfuumlhrende Informationen bezuumlglich Bildschirm- und Ob-jektkoordinaten verweisen wir auf [SongHo]Um auf die Anwender-Interaktion reagieren zu koumlnnen verwenden wir die Methode onTouchEventwelche von OpenGL ES 20 bereitgestellt wird Dabei handelt es sich um eine sogenannte bdquoCallbackldquo-Funktion was bedeutet dass sie vom System automatisch aufgerufen wird Dies geschieht genau dannwenn der Nutzer den Bildschirm beruumlhrt Wie wir in Kapitel 44 sehen erfolgt die Simulation nichtin Echtzeit was sich vor allem mit der langen Rechenzeit des Loumlsers erklaumlren laumlsst Auf dem vonuns verwendeten Geraumlt steht uns eine CPU mit zwei Kernen beziehungsweise Threads zur VerfuumlgungAuf dem einen fuumlhren wir die Berechnungen aus und auf dem anderen die Visualisierung inklusiveder TouchEvent-Abfragen Aufgrund der oben beschriebenen Verzoumlgerung ist es moumlglich mehrereAufrufe der onTouchEvent-Routine pro Zeitschritt durchzufuumlhren also Abfragen nach sogenanntenTouchEvents Wir uumlberpruumlfen dabei ob der Anwender den Bildschirm beruumlhrt oder nicht Die Kon-sequenzen die dieses Vorgehen auf die Laufzeit der Simulation hat untersuchen wir in Abschnitt 443Pro Zeitschritt beruumlcksichtigen wir nur die Ergebnisse des ersten TouchEventsDie Behandlung von TouchEvents geschieht wie folgt Sollte der Bildschirm beruumlhrt werden wirddie Funktion onTouchEvent aufgerufen Zuerst lesen wir die Position des Fingers in Bildschirm-

KAPITEL 3 IMPLEMENTIERUNG 20

koordinaten mit Hilfe der Funktion getX beziehungsweise getY aus Danach transformieren wir siein Objektkoordinaten Aus der Position des Fingers im vorherigen Zeitschritt koumlnnen wir die Streckeermitteln die der Finger von einem Zeitschritt zum naumlchsten zuruumlckgelegt hat Daraus ergeben sichdann die Positionsaumlnderungen dx in x- und dy in y-Richtung Hierbei setzen wir nicht voraus dassdie Position in Objektkoordinaten einem Gitterpunkt entspricht Da wir eine Kraft jedoch nur in einemsolchen Gitterpunkt aufpraumlgen koumlnnen ermitteln wir den Knoten der am naumlchsten zu den Objektkoor-dinaten der Fingerposition liegt In diesem Punkt setzen wir dann die Kraft in x-Richtung als dx unddie in y-Richtung als dy wodurch gewaumlhrleistet ist dass wir bei schnellerer Bewegung des Fingersdem Fluid eine groumlszligere Kraft aufpraumlgen Das Aufpraumlgen der Kraft erfolgt nun durch Aumlnderungen derEintraumlge im force-Array die zu dem Gitterpunkt gehoumlren in dem die Kraft angreifen soll Mit Hilfevon if-Abfragen in der onTouchEvent-Methode stellen wir sicher dass ein TouchEvent nur dannberuumlcksichtigt wird wenn die Objektkoordinaten der Fingerposition innerhalb des Rechengebiets liegenZur Vorbereitung des naumlchsten Zeitschritts setzen wir am Ende des Loumlsers die zuvor veraumlnderten Eintraumlgeim force-Array wieder zu Null da eine Kraft nur innerhalb eines Zeitschritts wirken soll

34 Demonstration des Gesamtsystems

In den vorherigen Kapiteln haben wir ein Verfahren zur numerischen Loumlsung der Navier-Stokes Glei-chungen hergeleitet und dessen Umsetzung auf Tablet-Computern erlaumlutert Bevor wir in Kapitel 4 einegenauere Analyse der Implementierung durchfuumlhren wollen wir vorab einen ersten Eindruck der Simu-lation vermitteln Dazu stellen wir in Abbildung 35 eine Absolutgeschwindigkeitsverteilung im Fluiddar Die angefuumlhrten Bilder sind einem Video entnommen welches dieser Arbeit beiliegt

(a) initiale Geschwindigkeitsverteilung (b) leicht beeinflusste Stroumlmung

(c) schnelle Anwender-Interaktion (d) langsame Anwender-Interaktion

Abbildung 35 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 3 IMPLEMENTIERUNG 21

Wir betrachten hier das Szenario in dem an der oberen Kante des Rechengebiets permanent eine vonNull verschiedene Geschwindigkeit angetragen ist In der unteren linken Ecke des Gebiets befindet sicheine Druckspitze Erlaumluterungen zu diesen Rand- beziehungsweise Anfangsbedingungen finden sich imfolgenden Kapitel Auszligerdem erfolgt im Laufe der Ausfuumlhrung der Simulation eine Interaktion durcheinen AnwenderIn Abbildung 35(a) sehen wir die initiale Verteilung des Geschwindigkeitsfeldes welches anschlieszligenddurch den Anwender leicht gestoumlrt wird was in Abbildung 35(b) zu beobachten ist In Abbildung 35(c)erkennen wir die Entwicklung der Geschwindigkeit im Fluid nach einer schnellen kreisfoumlrmigen Inter-aktion des Anwenders und zuletzt in Abbildung 35(d) das Verhalten des Fluids wenn der Anwendereine langsame Interaktion ausfuumlhrt Dabei koumlnnen wir sehr gut die Stroumlmung erkennen die durch dasAufpraumlgen der externen Kraumlfte ausgeloumlst wird

Kapitel 4

Tests

41 Validierung

In dem ersten Abschnitt dieses Kapitels untersuchen wir die numerische Stabilitaumlt und physikalischeKorrektheit unserer Simulation Wir wollen dies anhand von einfachen Testfaumlllen uumlberpruumlfen Zur Un-tersuchung werden wir sowohl visuelle Darstellungen nutzen als auch Diagramme von Druck- undoderGeschwindigkeitsverlaumlufen

411 Numerische Stabilitaumlt

Wir werden zunaumlchst am einfachsten Testfall Steady uumlberpruumlfen ob unsere Implementierung numerischstabil laumluft Dazu verwenden wir folgende Wahl der Parameter

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (41)

Als Erstes werden wir nun den Testfall Steady beschreiben und erlaumlutern warum sich dieser gut zuruumlberpruumlfung der numerischen Stabilitaumlt eignetIm Testfall Steady setzen wir alle initialen Werte auf Null Das heiszligt in jedem Punkt unseres Gittersherrscht ein Druck von Null die Geschwindigkeit betraumlgt Null und auch wirkt nirgends eine initial ge-setzte Kraft Wir haben also eine ruhige Simulationsumgebung gegeben welche im Folgenden nichtweiter beeinflusst wird da wir bei diesem Test keine Interaktion durch den Anwender erlauben moumlchtenZiel dieses Tests ist es unsere Simulation uumlber einen laumlngeren Zeitraum zu beobachten und zu unter-suchen ob sich trotz allgemeiner Null-Anfangsbedingung Geschwindigkeiten oder Druumlcke einstellenwelche nach unserer Auffassung nicht existieren duumlrften Da unsere farbige Visualisierung lediglich in19 Farben unterteilt wurde koumlnnte es jedoch sein dass beim Auftreten sehr kleiner Geschwindigkeitendiese visuell durch das Verwenden unserer Heat Map nicht in Erscheinung treten Um diesen Effektzu kompensieren werden wir die Druck- beziehungsweise die Geschwindigkeitsvektornorm numerischuntersuchen (vgl Abbildung 41)Wir berechnen somit in jedem Zeitschritt die Norm des Druck- und Geschwindigkeitsvektors und gebenden Verlauf uumlber unser Zeitintervall im nachfolgendem Diagramm 41 wieder Deutlich zu erkennen istdass sowohl die Norm des Druckvektors als auch die des Geschwindigkeitsvektors uumlber unser Zeitin-tervall konstant bei Null bleibt Es tritt also der intuitive Fall ein dass unsere Fluumlssigkeit im Modell beiallgemeinen Null-Anfangsbedinungen auch nach langer Zeit ruhig bleibt und keinerlei Bewegung auf-weistSomit haben wir in unserem ersten Test die Stabilitaumlt unseres Verfahren nachgewiesen koumlnnen je-doch noch keine Angaben dazu machen ob sich unsere Software physikalisch richtig verhaumllt (vgl Ab-schnitt 412)

22

KAPITEL 4 TESTS 23

0 20 40 60 80 100 120 140 160minus1

0

1x 10

minus4

Zeitschritt

Vek

torn

orm

GeschwindigkeitDruck

Abbildung 41 Vektornomen des Druck- und Geschwindigkeitsvektors uumlber mehrere Zeitschritte

412 Physikalisch richtiges Verhalten

Wie schon im vorherigen Kapitel 411 erwaumlhnt werden wir in diesem Abschnitt unsere Software aufdie Korrektheit ihrer Loumlsung untersuchen Wir werden also herausfinden ob sich unsere Simulationphysikalisch richtig verhaumllt Um dies zu erzielen greifen wir auf den gaumlngigen Testfall Driven Cavityzum Testen von Stroumlmungssimulationen zuruumlck

Abbildung 42 Konfiguration fuumlr den Testfall Driven Cavity

Driven Cavity ist ein einfacher Testfall an dem man jedoch viel uumlber die Richtigkeit unserer Imple-mentierung erfahren kann Wir wollen zunaumlchst erlaumlutern welche Testkonfiguration fuumlr Driven Cavitygewaumlhlt werden muss Der wichtigste Schritt ist die richtigen Anfangs- und Randbedingungen vorzu-

KAPITEL 4 TESTS 24

schreiben Ziel bei Driven Cavity ist es an einer Kante unseres Gitters in tangentialer Richtung mitkonstanter Geschwindigkeit v0 kontinuierlich das heiszligt waumlhrend des gesamten Zeitintervalls zu strouml-men wie in Abbildung 42 dargestellt An allen uumlbrigen Kanten wird uumlber das Zeitintervall hinweg Nullvorgeschrieben sowohl in x- als auch in y- Richtung In unserem Fall waumlhlen wir die obere Kante undstroumlmen in positive x-RichtungUm zu erreichen dass wir in jedem Zeitschritt erneut die Geschwindigkeit v0 an der oberen Kante in x-Richtung und Geschwindigkeit Null an den anderen Kanten aufpraumlgen muumlssen wir dies am Ende jedesZeitschritts in unserem Loumlser velocity und am Anfang des Tracer (vgl Kapitel 31) erneut setzenda hier die Randwerte uumlberschrieben werden und wir dies nicht zulassen wollen In den uumlbrigen Teilenunseres Loumlsers muumlssen wir dies nicht tun da hier lediglich die inneren Gitterpunkte behandelt werden(siehe Kapitel 31)Als naumlchstes legen wir nun unsere Parameter wie folgt fest

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (42)

Visuell wird die x-Komponente der Geschwindigkeit dargestellt und es ergibt sich folgendes initialesBild (Abbildung 43)

Abbildung 43 Initale Verteilung der x-Komponete der Geschwindigkeit

Man kann in Abbildung 43 deutlich eine Stroumlmung an der oberen Kannte unseres Gitters erkennengenauso wie wir es vorgegeben haben An allen uumlbrigen Punkten unseres Gitters betraumlgt die Geschwin-digkeit in x-Richtung NullWenn wir unsere Simulation uumlber einen laumlngeren Zeitraum laufen lassen stellen wir fest dass sich diein Abbildung 44 angefuumlhrte Verteilung der Geschwindigkeit einstellt und diese sich auch nach weiterenZeitschritten nicht weiter veraumlndert Um die Korrektheit unserer Loumlsung zu verifizieren vergleichen wirunsere visuelle Darstellung in Abbildung 44(a) mit bekannten richtigen Loumlsungen dieses Testfalls inAbbildung 44(b) Es ist gut zu erkennen dass unsere Darstellung die gleichen Merkmale aufweist wiedas Referenzbild 44(b)Am oberen Rand stellt sich ein Gebiet ein welches groszlige Geschwindigkeiten in x-Richtung aufweist dahier die kontinuierliche Geschwindigkeit v0 eingestellt wird welche jedoch zur Mitte hin immer weiterabnimmt Die Form dieses Gebietes ist bei beiden Bildern bis auf unterschiedliche Faumlrbungen zuruumlck-zufuumlhren auf das Verwenden verschiedener Heat Maps (vgl Kapitel 32) gleich In unserem Fall wirddas Farbspektrum in 19 Farben unterteilt und im Referenzfall in 26 (vgl Kapitel 32 und [CFD Online])In der Mitte schlieszliglich zieht sich ein nahezu stillstehendes Gebiet erkennbar durch die dunkelblaue

KAPITEL 4 TESTS 25

Faumlrbung in die obere rechte Ecke Da es eine sehr groszlige Aumlhnlichkeit zwischen unserem und dem Refe-renzbild gibt koumlnnen wir erwarten dass unsere Stroumlmungssimulation richtig implementiert wurde undeiner physikalisch realistischen Simulation entspricht

(a) Darstellung des Testfalls Driven Cavity nachvielen Zeitschritten

(b) Referenzbild zu Driven Cavity von [CFD Onli-ne]

Abbildung 44 Vergleich unserer Simulation durch ein Referenzbild am Testfall Driven Cavity

Wir gehen somit in den folgenden Kapiteln davon aus dass unsere Software einer physikalisch richtigenSimulation enspricht und numerisch stabil laumluft

KAPITEL 4 TESTS 26

42 Parametertests

In diesem Abschnitt wollen wir den Einfluss verschiedener Parameter auf unsere Simulation am TestfallHubbel (vgl Abbildung 45) untersuchen Als Erstes wollen wir den Einfluss der Viskositaumlt ν wel-ches ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres zugrunde liegenden Fluids darstellt untersuchen Anschlie-szligend befassen wir uns mit dem Zeitschritt ∆t welcher ausschlieszliglich im Tracer (siehe hierzu Kapitel 31) benoumltigt wird und hier ein Maszlig fuumlr die Genauigkeit darstellt Als Letztes werden wir den Ein-fluss der Anzahl der Jacobi-Schritte und damit die Genauigkeitsanforderungen des linearen Loumlsers (vglKapitel 31) untersuchen und anhand der visuellen Darstellung unserer Simulation analysieren wie ge-nau wir loumlsen muumlssen um Symmetrie zu erreichen Sollte unser Verfahren unter der Voraussetzung einessymmetrischen Testfalls symmetrische Ergebnisse liefern so koumlnnen wir von einer sehr guten numeri-schen Approximation einer realen Loumlsung sprechen was in unserem Fall aus einer hohen Genauigkeitdes Druck- und Geschwindigkeitsfeldes resultiertAls Standardkonfiguration waumlhlen wir folgende Werte fuumlr die in unserem Modell frei waumlhlbaren Para-meter

n = 129 h =1

128 ν = 00003 v0 = 000015 ∆t =

1

(nminus 1) middot v0 middot 200 maxiter = 32 (43)

In diesem Fall und anders als im vorherigen Testfall Driven Cavity (vgl Kapitel 412) benoumltigen wirv0 lediglich zur Bestimmung von ∆t da wir im folgenden keine initiale oder kontinuierliche Geschwin-digkeit auftragen wollen Waumlhrend jedes Tests wird ausschlieszliglich ein Parameter veraumlndert um seineAuswirkungen unabhaumlngig von den anderen Groumlszligen analysieren zu koumlnnenAls Ausgangssituation waumlhlen wir den Testfall Hubbel den wir als naumlchstes beschreiben werdenDie initiale Geschwindigkeit und Kraft in jedem Punkt unseres Gitters setzen wir als Null und schreibenfuumlr den Druck Werte so vor dass wir zwei Druckspitzen erhalten (siehe Abbildung 45) Dies realisierenwir mit Hilfe der Gauszligglockenkurve im Zweidimensionalen (siehe Gleichung (44)) da wir so auszliger-halb der Druckspitzen nahezu Null realisieren koumlnnen und wir einen stetigen Druckverlauf sogar Cinfinerzielen

f(x y) = exp(a (xminus x0)2 + a (y minus y0)2 + b

)(44)

Hierbei ist a ein Verzerrungsfaktor und b der Wert im Glockenmittelpunkt (x0 y0) Addieren wir nunzwei Glockenkurven mit a = minus50 b = 0 x1

0 = 05 und y10 = minus05 beziehungsweise x2

0 = minus05 undy2

0 = 05 erhalten wir die folgende initiale Druckverteilung

minus1 minus08 minus06 minus04 minus02 0 02 04 06 08 1minus1

minus050

0510

01

02

03

04

05

06

07

08

09

1

Abbildung 45 Initiale Druckverteilung des Testfalls Hubbel mit zwei Druckspitzen

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 3 IMPLEMENTIERUNG 20

koordinaten mit Hilfe der Funktion getX beziehungsweise getY aus Danach transformieren wir siein Objektkoordinaten Aus der Position des Fingers im vorherigen Zeitschritt koumlnnen wir die Streckeermitteln die der Finger von einem Zeitschritt zum naumlchsten zuruumlckgelegt hat Daraus ergeben sichdann die Positionsaumlnderungen dx in x- und dy in y-Richtung Hierbei setzen wir nicht voraus dassdie Position in Objektkoordinaten einem Gitterpunkt entspricht Da wir eine Kraft jedoch nur in einemsolchen Gitterpunkt aufpraumlgen koumlnnen ermitteln wir den Knoten der am naumlchsten zu den Objektkoor-dinaten der Fingerposition liegt In diesem Punkt setzen wir dann die Kraft in x-Richtung als dx unddie in y-Richtung als dy wodurch gewaumlhrleistet ist dass wir bei schnellerer Bewegung des Fingersdem Fluid eine groumlszligere Kraft aufpraumlgen Das Aufpraumlgen der Kraft erfolgt nun durch Aumlnderungen derEintraumlge im force-Array die zu dem Gitterpunkt gehoumlren in dem die Kraft angreifen soll Mit Hilfevon if-Abfragen in der onTouchEvent-Methode stellen wir sicher dass ein TouchEvent nur dannberuumlcksichtigt wird wenn die Objektkoordinaten der Fingerposition innerhalb des Rechengebiets liegenZur Vorbereitung des naumlchsten Zeitschritts setzen wir am Ende des Loumlsers die zuvor veraumlnderten Eintraumlgeim force-Array wieder zu Null da eine Kraft nur innerhalb eines Zeitschritts wirken soll

34 Demonstration des Gesamtsystems

In den vorherigen Kapiteln haben wir ein Verfahren zur numerischen Loumlsung der Navier-Stokes Glei-chungen hergeleitet und dessen Umsetzung auf Tablet-Computern erlaumlutert Bevor wir in Kapitel 4 einegenauere Analyse der Implementierung durchfuumlhren wollen wir vorab einen ersten Eindruck der Simu-lation vermitteln Dazu stellen wir in Abbildung 35 eine Absolutgeschwindigkeitsverteilung im Fluiddar Die angefuumlhrten Bilder sind einem Video entnommen welches dieser Arbeit beiliegt

(a) initiale Geschwindigkeitsverteilung (b) leicht beeinflusste Stroumlmung

(c) schnelle Anwender-Interaktion (d) langsame Anwender-Interaktion

Abbildung 35 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 3 IMPLEMENTIERUNG 21

Wir betrachten hier das Szenario in dem an der oberen Kante des Rechengebiets permanent eine vonNull verschiedene Geschwindigkeit angetragen ist In der unteren linken Ecke des Gebiets befindet sicheine Druckspitze Erlaumluterungen zu diesen Rand- beziehungsweise Anfangsbedingungen finden sich imfolgenden Kapitel Auszligerdem erfolgt im Laufe der Ausfuumlhrung der Simulation eine Interaktion durcheinen AnwenderIn Abbildung 35(a) sehen wir die initiale Verteilung des Geschwindigkeitsfeldes welches anschlieszligenddurch den Anwender leicht gestoumlrt wird was in Abbildung 35(b) zu beobachten ist In Abbildung 35(c)erkennen wir die Entwicklung der Geschwindigkeit im Fluid nach einer schnellen kreisfoumlrmigen Inter-aktion des Anwenders und zuletzt in Abbildung 35(d) das Verhalten des Fluids wenn der Anwendereine langsame Interaktion ausfuumlhrt Dabei koumlnnen wir sehr gut die Stroumlmung erkennen die durch dasAufpraumlgen der externen Kraumlfte ausgeloumlst wird

Kapitel 4

Tests

41 Validierung

In dem ersten Abschnitt dieses Kapitels untersuchen wir die numerische Stabilitaumlt und physikalischeKorrektheit unserer Simulation Wir wollen dies anhand von einfachen Testfaumlllen uumlberpruumlfen Zur Un-tersuchung werden wir sowohl visuelle Darstellungen nutzen als auch Diagramme von Druck- undoderGeschwindigkeitsverlaumlufen

411 Numerische Stabilitaumlt

Wir werden zunaumlchst am einfachsten Testfall Steady uumlberpruumlfen ob unsere Implementierung numerischstabil laumluft Dazu verwenden wir folgende Wahl der Parameter

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (41)

Als Erstes werden wir nun den Testfall Steady beschreiben und erlaumlutern warum sich dieser gut zuruumlberpruumlfung der numerischen Stabilitaumlt eignetIm Testfall Steady setzen wir alle initialen Werte auf Null Das heiszligt in jedem Punkt unseres Gittersherrscht ein Druck von Null die Geschwindigkeit betraumlgt Null und auch wirkt nirgends eine initial ge-setzte Kraft Wir haben also eine ruhige Simulationsumgebung gegeben welche im Folgenden nichtweiter beeinflusst wird da wir bei diesem Test keine Interaktion durch den Anwender erlauben moumlchtenZiel dieses Tests ist es unsere Simulation uumlber einen laumlngeren Zeitraum zu beobachten und zu unter-suchen ob sich trotz allgemeiner Null-Anfangsbedingung Geschwindigkeiten oder Druumlcke einstellenwelche nach unserer Auffassung nicht existieren duumlrften Da unsere farbige Visualisierung lediglich in19 Farben unterteilt wurde koumlnnte es jedoch sein dass beim Auftreten sehr kleiner Geschwindigkeitendiese visuell durch das Verwenden unserer Heat Map nicht in Erscheinung treten Um diesen Effektzu kompensieren werden wir die Druck- beziehungsweise die Geschwindigkeitsvektornorm numerischuntersuchen (vgl Abbildung 41)Wir berechnen somit in jedem Zeitschritt die Norm des Druck- und Geschwindigkeitsvektors und gebenden Verlauf uumlber unser Zeitintervall im nachfolgendem Diagramm 41 wieder Deutlich zu erkennen istdass sowohl die Norm des Druckvektors als auch die des Geschwindigkeitsvektors uumlber unser Zeitin-tervall konstant bei Null bleibt Es tritt also der intuitive Fall ein dass unsere Fluumlssigkeit im Modell beiallgemeinen Null-Anfangsbedinungen auch nach langer Zeit ruhig bleibt und keinerlei Bewegung auf-weistSomit haben wir in unserem ersten Test die Stabilitaumlt unseres Verfahren nachgewiesen koumlnnen je-doch noch keine Angaben dazu machen ob sich unsere Software physikalisch richtig verhaumllt (vgl Ab-schnitt 412)

22

KAPITEL 4 TESTS 23

0 20 40 60 80 100 120 140 160minus1

0

1x 10

minus4

Zeitschritt

Vek

torn

orm

GeschwindigkeitDruck

Abbildung 41 Vektornomen des Druck- und Geschwindigkeitsvektors uumlber mehrere Zeitschritte

412 Physikalisch richtiges Verhalten

Wie schon im vorherigen Kapitel 411 erwaumlhnt werden wir in diesem Abschnitt unsere Software aufdie Korrektheit ihrer Loumlsung untersuchen Wir werden also herausfinden ob sich unsere Simulationphysikalisch richtig verhaumllt Um dies zu erzielen greifen wir auf den gaumlngigen Testfall Driven Cavityzum Testen von Stroumlmungssimulationen zuruumlck

Abbildung 42 Konfiguration fuumlr den Testfall Driven Cavity

Driven Cavity ist ein einfacher Testfall an dem man jedoch viel uumlber die Richtigkeit unserer Imple-mentierung erfahren kann Wir wollen zunaumlchst erlaumlutern welche Testkonfiguration fuumlr Driven Cavitygewaumlhlt werden muss Der wichtigste Schritt ist die richtigen Anfangs- und Randbedingungen vorzu-

KAPITEL 4 TESTS 24

schreiben Ziel bei Driven Cavity ist es an einer Kante unseres Gitters in tangentialer Richtung mitkonstanter Geschwindigkeit v0 kontinuierlich das heiszligt waumlhrend des gesamten Zeitintervalls zu strouml-men wie in Abbildung 42 dargestellt An allen uumlbrigen Kanten wird uumlber das Zeitintervall hinweg Nullvorgeschrieben sowohl in x- als auch in y- Richtung In unserem Fall waumlhlen wir die obere Kante undstroumlmen in positive x-RichtungUm zu erreichen dass wir in jedem Zeitschritt erneut die Geschwindigkeit v0 an der oberen Kante in x-Richtung und Geschwindigkeit Null an den anderen Kanten aufpraumlgen muumlssen wir dies am Ende jedesZeitschritts in unserem Loumlser velocity und am Anfang des Tracer (vgl Kapitel 31) erneut setzenda hier die Randwerte uumlberschrieben werden und wir dies nicht zulassen wollen In den uumlbrigen Teilenunseres Loumlsers muumlssen wir dies nicht tun da hier lediglich die inneren Gitterpunkte behandelt werden(siehe Kapitel 31)Als naumlchstes legen wir nun unsere Parameter wie folgt fest

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (42)

Visuell wird die x-Komponente der Geschwindigkeit dargestellt und es ergibt sich folgendes initialesBild (Abbildung 43)

Abbildung 43 Initale Verteilung der x-Komponete der Geschwindigkeit

Man kann in Abbildung 43 deutlich eine Stroumlmung an der oberen Kannte unseres Gitters erkennengenauso wie wir es vorgegeben haben An allen uumlbrigen Punkten unseres Gitters betraumlgt die Geschwin-digkeit in x-Richtung NullWenn wir unsere Simulation uumlber einen laumlngeren Zeitraum laufen lassen stellen wir fest dass sich diein Abbildung 44 angefuumlhrte Verteilung der Geschwindigkeit einstellt und diese sich auch nach weiterenZeitschritten nicht weiter veraumlndert Um die Korrektheit unserer Loumlsung zu verifizieren vergleichen wirunsere visuelle Darstellung in Abbildung 44(a) mit bekannten richtigen Loumlsungen dieses Testfalls inAbbildung 44(b) Es ist gut zu erkennen dass unsere Darstellung die gleichen Merkmale aufweist wiedas Referenzbild 44(b)Am oberen Rand stellt sich ein Gebiet ein welches groszlige Geschwindigkeiten in x-Richtung aufweist dahier die kontinuierliche Geschwindigkeit v0 eingestellt wird welche jedoch zur Mitte hin immer weiterabnimmt Die Form dieses Gebietes ist bei beiden Bildern bis auf unterschiedliche Faumlrbungen zuruumlck-zufuumlhren auf das Verwenden verschiedener Heat Maps (vgl Kapitel 32) gleich In unserem Fall wirddas Farbspektrum in 19 Farben unterteilt und im Referenzfall in 26 (vgl Kapitel 32 und [CFD Online])In der Mitte schlieszliglich zieht sich ein nahezu stillstehendes Gebiet erkennbar durch die dunkelblaue

KAPITEL 4 TESTS 25

Faumlrbung in die obere rechte Ecke Da es eine sehr groszlige Aumlhnlichkeit zwischen unserem und dem Refe-renzbild gibt koumlnnen wir erwarten dass unsere Stroumlmungssimulation richtig implementiert wurde undeiner physikalisch realistischen Simulation entspricht

(a) Darstellung des Testfalls Driven Cavity nachvielen Zeitschritten

(b) Referenzbild zu Driven Cavity von [CFD Onli-ne]

Abbildung 44 Vergleich unserer Simulation durch ein Referenzbild am Testfall Driven Cavity

Wir gehen somit in den folgenden Kapiteln davon aus dass unsere Software einer physikalisch richtigenSimulation enspricht und numerisch stabil laumluft

KAPITEL 4 TESTS 26

42 Parametertests

In diesem Abschnitt wollen wir den Einfluss verschiedener Parameter auf unsere Simulation am TestfallHubbel (vgl Abbildung 45) untersuchen Als Erstes wollen wir den Einfluss der Viskositaumlt ν wel-ches ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres zugrunde liegenden Fluids darstellt untersuchen Anschlie-szligend befassen wir uns mit dem Zeitschritt ∆t welcher ausschlieszliglich im Tracer (siehe hierzu Kapitel 31) benoumltigt wird und hier ein Maszlig fuumlr die Genauigkeit darstellt Als Letztes werden wir den Ein-fluss der Anzahl der Jacobi-Schritte und damit die Genauigkeitsanforderungen des linearen Loumlsers (vglKapitel 31) untersuchen und anhand der visuellen Darstellung unserer Simulation analysieren wie ge-nau wir loumlsen muumlssen um Symmetrie zu erreichen Sollte unser Verfahren unter der Voraussetzung einessymmetrischen Testfalls symmetrische Ergebnisse liefern so koumlnnen wir von einer sehr guten numeri-schen Approximation einer realen Loumlsung sprechen was in unserem Fall aus einer hohen Genauigkeitdes Druck- und Geschwindigkeitsfeldes resultiertAls Standardkonfiguration waumlhlen wir folgende Werte fuumlr die in unserem Modell frei waumlhlbaren Para-meter

n = 129 h =1

128 ν = 00003 v0 = 000015 ∆t =

1

(nminus 1) middot v0 middot 200 maxiter = 32 (43)

In diesem Fall und anders als im vorherigen Testfall Driven Cavity (vgl Kapitel 412) benoumltigen wirv0 lediglich zur Bestimmung von ∆t da wir im folgenden keine initiale oder kontinuierliche Geschwin-digkeit auftragen wollen Waumlhrend jedes Tests wird ausschlieszliglich ein Parameter veraumlndert um seineAuswirkungen unabhaumlngig von den anderen Groumlszligen analysieren zu koumlnnenAls Ausgangssituation waumlhlen wir den Testfall Hubbel den wir als naumlchstes beschreiben werdenDie initiale Geschwindigkeit und Kraft in jedem Punkt unseres Gitters setzen wir als Null und schreibenfuumlr den Druck Werte so vor dass wir zwei Druckspitzen erhalten (siehe Abbildung 45) Dies realisierenwir mit Hilfe der Gauszligglockenkurve im Zweidimensionalen (siehe Gleichung (44)) da wir so auszliger-halb der Druckspitzen nahezu Null realisieren koumlnnen und wir einen stetigen Druckverlauf sogar Cinfinerzielen

f(x y) = exp(a (xminus x0)2 + a (y minus y0)2 + b

)(44)

Hierbei ist a ein Verzerrungsfaktor und b der Wert im Glockenmittelpunkt (x0 y0) Addieren wir nunzwei Glockenkurven mit a = minus50 b = 0 x1

0 = 05 und y10 = minus05 beziehungsweise x2

0 = minus05 undy2

0 = 05 erhalten wir die folgende initiale Druckverteilung

minus1 minus08 minus06 minus04 minus02 0 02 04 06 08 1minus1

minus050

0510

01

02

03

04

05

06

07

08

09

1

Abbildung 45 Initiale Druckverteilung des Testfalls Hubbel mit zwei Druckspitzen

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 3 IMPLEMENTIERUNG 21

Wir betrachten hier das Szenario in dem an der oberen Kante des Rechengebiets permanent eine vonNull verschiedene Geschwindigkeit angetragen ist In der unteren linken Ecke des Gebiets befindet sicheine Druckspitze Erlaumluterungen zu diesen Rand- beziehungsweise Anfangsbedingungen finden sich imfolgenden Kapitel Auszligerdem erfolgt im Laufe der Ausfuumlhrung der Simulation eine Interaktion durcheinen AnwenderIn Abbildung 35(a) sehen wir die initiale Verteilung des Geschwindigkeitsfeldes welches anschlieszligenddurch den Anwender leicht gestoumlrt wird was in Abbildung 35(b) zu beobachten ist In Abbildung 35(c)erkennen wir die Entwicklung der Geschwindigkeit im Fluid nach einer schnellen kreisfoumlrmigen Inter-aktion des Anwenders und zuletzt in Abbildung 35(d) das Verhalten des Fluids wenn der Anwendereine langsame Interaktion ausfuumlhrt Dabei koumlnnen wir sehr gut die Stroumlmung erkennen die durch dasAufpraumlgen der externen Kraumlfte ausgeloumlst wird

Kapitel 4

Tests

41 Validierung

In dem ersten Abschnitt dieses Kapitels untersuchen wir die numerische Stabilitaumlt und physikalischeKorrektheit unserer Simulation Wir wollen dies anhand von einfachen Testfaumlllen uumlberpruumlfen Zur Un-tersuchung werden wir sowohl visuelle Darstellungen nutzen als auch Diagramme von Druck- undoderGeschwindigkeitsverlaumlufen

411 Numerische Stabilitaumlt

Wir werden zunaumlchst am einfachsten Testfall Steady uumlberpruumlfen ob unsere Implementierung numerischstabil laumluft Dazu verwenden wir folgende Wahl der Parameter

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (41)

Als Erstes werden wir nun den Testfall Steady beschreiben und erlaumlutern warum sich dieser gut zuruumlberpruumlfung der numerischen Stabilitaumlt eignetIm Testfall Steady setzen wir alle initialen Werte auf Null Das heiszligt in jedem Punkt unseres Gittersherrscht ein Druck von Null die Geschwindigkeit betraumlgt Null und auch wirkt nirgends eine initial ge-setzte Kraft Wir haben also eine ruhige Simulationsumgebung gegeben welche im Folgenden nichtweiter beeinflusst wird da wir bei diesem Test keine Interaktion durch den Anwender erlauben moumlchtenZiel dieses Tests ist es unsere Simulation uumlber einen laumlngeren Zeitraum zu beobachten und zu unter-suchen ob sich trotz allgemeiner Null-Anfangsbedingung Geschwindigkeiten oder Druumlcke einstellenwelche nach unserer Auffassung nicht existieren duumlrften Da unsere farbige Visualisierung lediglich in19 Farben unterteilt wurde koumlnnte es jedoch sein dass beim Auftreten sehr kleiner Geschwindigkeitendiese visuell durch das Verwenden unserer Heat Map nicht in Erscheinung treten Um diesen Effektzu kompensieren werden wir die Druck- beziehungsweise die Geschwindigkeitsvektornorm numerischuntersuchen (vgl Abbildung 41)Wir berechnen somit in jedem Zeitschritt die Norm des Druck- und Geschwindigkeitsvektors und gebenden Verlauf uumlber unser Zeitintervall im nachfolgendem Diagramm 41 wieder Deutlich zu erkennen istdass sowohl die Norm des Druckvektors als auch die des Geschwindigkeitsvektors uumlber unser Zeitin-tervall konstant bei Null bleibt Es tritt also der intuitive Fall ein dass unsere Fluumlssigkeit im Modell beiallgemeinen Null-Anfangsbedinungen auch nach langer Zeit ruhig bleibt und keinerlei Bewegung auf-weistSomit haben wir in unserem ersten Test die Stabilitaumlt unseres Verfahren nachgewiesen koumlnnen je-doch noch keine Angaben dazu machen ob sich unsere Software physikalisch richtig verhaumllt (vgl Ab-schnitt 412)

22

KAPITEL 4 TESTS 23

0 20 40 60 80 100 120 140 160minus1

0

1x 10

minus4

Zeitschritt

Vek

torn

orm

GeschwindigkeitDruck

Abbildung 41 Vektornomen des Druck- und Geschwindigkeitsvektors uumlber mehrere Zeitschritte

412 Physikalisch richtiges Verhalten

Wie schon im vorherigen Kapitel 411 erwaumlhnt werden wir in diesem Abschnitt unsere Software aufdie Korrektheit ihrer Loumlsung untersuchen Wir werden also herausfinden ob sich unsere Simulationphysikalisch richtig verhaumllt Um dies zu erzielen greifen wir auf den gaumlngigen Testfall Driven Cavityzum Testen von Stroumlmungssimulationen zuruumlck

Abbildung 42 Konfiguration fuumlr den Testfall Driven Cavity

Driven Cavity ist ein einfacher Testfall an dem man jedoch viel uumlber die Richtigkeit unserer Imple-mentierung erfahren kann Wir wollen zunaumlchst erlaumlutern welche Testkonfiguration fuumlr Driven Cavitygewaumlhlt werden muss Der wichtigste Schritt ist die richtigen Anfangs- und Randbedingungen vorzu-

KAPITEL 4 TESTS 24

schreiben Ziel bei Driven Cavity ist es an einer Kante unseres Gitters in tangentialer Richtung mitkonstanter Geschwindigkeit v0 kontinuierlich das heiszligt waumlhrend des gesamten Zeitintervalls zu strouml-men wie in Abbildung 42 dargestellt An allen uumlbrigen Kanten wird uumlber das Zeitintervall hinweg Nullvorgeschrieben sowohl in x- als auch in y- Richtung In unserem Fall waumlhlen wir die obere Kante undstroumlmen in positive x-RichtungUm zu erreichen dass wir in jedem Zeitschritt erneut die Geschwindigkeit v0 an der oberen Kante in x-Richtung und Geschwindigkeit Null an den anderen Kanten aufpraumlgen muumlssen wir dies am Ende jedesZeitschritts in unserem Loumlser velocity und am Anfang des Tracer (vgl Kapitel 31) erneut setzenda hier die Randwerte uumlberschrieben werden und wir dies nicht zulassen wollen In den uumlbrigen Teilenunseres Loumlsers muumlssen wir dies nicht tun da hier lediglich die inneren Gitterpunkte behandelt werden(siehe Kapitel 31)Als naumlchstes legen wir nun unsere Parameter wie folgt fest

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (42)

Visuell wird die x-Komponente der Geschwindigkeit dargestellt und es ergibt sich folgendes initialesBild (Abbildung 43)

Abbildung 43 Initale Verteilung der x-Komponete der Geschwindigkeit

Man kann in Abbildung 43 deutlich eine Stroumlmung an der oberen Kannte unseres Gitters erkennengenauso wie wir es vorgegeben haben An allen uumlbrigen Punkten unseres Gitters betraumlgt die Geschwin-digkeit in x-Richtung NullWenn wir unsere Simulation uumlber einen laumlngeren Zeitraum laufen lassen stellen wir fest dass sich diein Abbildung 44 angefuumlhrte Verteilung der Geschwindigkeit einstellt und diese sich auch nach weiterenZeitschritten nicht weiter veraumlndert Um die Korrektheit unserer Loumlsung zu verifizieren vergleichen wirunsere visuelle Darstellung in Abbildung 44(a) mit bekannten richtigen Loumlsungen dieses Testfalls inAbbildung 44(b) Es ist gut zu erkennen dass unsere Darstellung die gleichen Merkmale aufweist wiedas Referenzbild 44(b)Am oberen Rand stellt sich ein Gebiet ein welches groszlige Geschwindigkeiten in x-Richtung aufweist dahier die kontinuierliche Geschwindigkeit v0 eingestellt wird welche jedoch zur Mitte hin immer weiterabnimmt Die Form dieses Gebietes ist bei beiden Bildern bis auf unterschiedliche Faumlrbungen zuruumlck-zufuumlhren auf das Verwenden verschiedener Heat Maps (vgl Kapitel 32) gleich In unserem Fall wirddas Farbspektrum in 19 Farben unterteilt und im Referenzfall in 26 (vgl Kapitel 32 und [CFD Online])In der Mitte schlieszliglich zieht sich ein nahezu stillstehendes Gebiet erkennbar durch die dunkelblaue

KAPITEL 4 TESTS 25

Faumlrbung in die obere rechte Ecke Da es eine sehr groszlige Aumlhnlichkeit zwischen unserem und dem Refe-renzbild gibt koumlnnen wir erwarten dass unsere Stroumlmungssimulation richtig implementiert wurde undeiner physikalisch realistischen Simulation entspricht

(a) Darstellung des Testfalls Driven Cavity nachvielen Zeitschritten

(b) Referenzbild zu Driven Cavity von [CFD Onli-ne]

Abbildung 44 Vergleich unserer Simulation durch ein Referenzbild am Testfall Driven Cavity

Wir gehen somit in den folgenden Kapiteln davon aus dass unsere Software einer physikalisch richtigenSimulation enspricht und numerisch stabil laumluft

KAPITEL 4 TESTS 26

42 Parametertests

In diesem Abschnitt wollen wir den Einfluss verschiedener Parameter auf unsere Simulation am TestfallHubbel (vgl Abbildung 45) untersuchen Als Erstes wollen wir den Einfluss der Viskositaumlt ν wel-ches ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres zugrunde liegenden Fluids darstellt untersuchen Anschlie-szligend befassen wir uns mit dem Zeitschritt ∆t welcher ausschlieszliglich im Tracer (siehe hierzu Kapitel 31) benoumltigt wird und hier ein Maszlig fuumlr die Genauigkeit darstellt Als Letztes werden wir den Ein-fluss der Anzahl der Jacobi-Schritte und damit die Genauigkeitsanforderungen des linearen Loumlsers (vglKapitel 31) untersuchen und anhand der visuellen Darstellung unserer Simulation analysieren wie ge-nau wir loumlsen muumlssen um Symmetrie zu erreichen Sollte unser Verfahren unter der Voraussetzung einessymmetrischen Testfalls symmetrische Ergebnisse liefern so koumlnnen wir von einer sehr guten numeri-schen Approximation einer realen Loumlsung sprechen was in unserem Fall aus einer hohen Genauigkeitdes Druck- und Geschwindigkeitsfeldes resultiertAls Standardkonfiguration waumlhlen wir folgende Werte fuumlr die in unserem Modell frei waumlhlbaren Para-meter

n = 129 h =1

128 ν = 00003 v0 = 000015 ∆t =

1

(nminus 1) middot v0 middot 200 maxiter = 32 (43)

In diesem Fall und anders als im vorherigen Testfall Driven Cavity (vgl Kapitel 412) benoumltigen wirv0 lediglich zur Bestimmung von ∆t da wir im folgenden keine initiale oder kontinuierliche Geschwin-digkeit auftragen wollen Waumlhrend jedes Tests wird ausschlieszliglich ein Parameter veraumlndert um seineAuswirkungen unabhaumlngig von den anderen Groumlszligen analysieren zu koumlnnenAls Ausgangssituation waumlhlen wir den Testfall Hubbel den wir als naumlchstes beschreiben werdenDie initiale Geschwindigkeit und Kraft in jedem Punkt unseres Gitters setzen wir als Null und schreibenfuumlr den Druck Werte so vor dass wir zwei Druckspitzen erhalten (siehe Abbildung 45) Dies realisierenwir mit Hilfe der Gauszligglockenkurve im Zweidimensionalen (siehe Gleichung (44)) da wir so auszliger-halb der Druckspitzen nahezu Null realisieren koumlnnen und wir einen stetigen Druckverlauf sogar Cinfinerzielen

f(x y) = exp(a (xminus x0)2 + a (y minus y0)2 + b

)(44)

Hierbei ist a ein Verzerrungsfaktor und b der Wert im Glockenmittelpunkt (x0 y0) Addieren wir nunzwei Glockenkurven mit a = minus50 b = 0 x1

0 = 05 und y10 = minus05 beziehungsweise x2

0 = minus05 undy2

0 = 05 erhalten wir die folgende initiale Druckverteilung

minus1 minus08 minus06 minus04 minus02 0 02 04 06 08 1minus1

minus050

0510

01

02

03

04

05

06

07

08

09

1

Abbildung 45 Initiale Druckverteilung des Testfalls Hubbel mit zwei Druckspitzen

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

Kapitel 4

Tests

41 Validierung

In dem ersten Abschnitt dieses Kapitels untersuchen wir die numerische Stabilitaumlt und physikalischeKorrektheit unserer Simulation Wir wollen dies anhand von einfachen Testfaumlllen uumlberpruumlfen Zur Un-tersuchung werden wir sowohl visuelle Darstellungen nutzen als auch Diagramme von Druck- undoderGeschwindigkeitsverlaumlufen

411 Numerische Stabilitaumlt

Wir werden zunaumlchst am einfachsten Testfall Steady uumlberpruumlfen ob unsere Implementierung numerischstabil laumluft Dazu verwenden wir folgende Wahl der Parameter

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (41)

Als Erstes werden wir nun den Testfall Steady beschreiben und erlaumlutern warum sich dieser gut zuruumlberpruumlfung der numerischen Stabilitaumlt eignetIm Testfall Steady setzen wir alle initialen Werte auf Null Das heiszligt in jedem Punkt unseres Gittersherrscht ein Druck von Null die Geschwindigkeit betraumlgt Null und auch wirkt nirgends eine initial ge-setzte Kraft Wir haben also eine ruhige Simulationsumgebung gegeben welche im Folgenden nichtweiter beeinflusst wird da wir bei diesem Test keine Interaktion durch den Anwender erlauben moumlchtenZiel dieses Tests ist es unsere Simulation uumlber einen laumlngeren Zeitraum zu beobachten und zu unter-suchen ob sich trotz allgemeiner Null-Anfangsbedingung Geschwindigkeiten oder Druumlcke einstellenwelche nach unserer Auffassung nicht existieren duumlrften Da unsere farbige Visualisierung lediglich in19 Farben unterteilt wurde koumlnnte es jedoch sein dass beim Auftreten sehr kleiner Geschwindigkeitendiese visuell durch das Verwenden unserer Heat Map nicht in Erscheinung treten Um diesen Effektzu kompensieren werden wir die Druck- beziehungsweise die Geschwindigkeitsvektornorm numerischuntersuchen (vgl Abbildung 41)Wir berechnen somit in jedem Zeitschritt die Norm des Druck- und Geschwindigkeitsvektors und gebenden Verlauf uumlber unser Zeitintervall im nachfolgendem Diagramm 41 wieder Deutlich zu erkennen istdass sowohl die Norm des Druckvektors als auch die des Geschwindigkeitsvektors uumlber unser Zeitin-tervall konstant bei Null bleibt Es tritt also der intuitive Fall ein dass unsere Fluumlssigkeit im Modell beiallgemeinen Null-Anfangsbedinungen auch nach langer Zeit ruhig bleibt und keinerlei Bewegung auf-weistSomit haben wir in unserem ersten Test die Stabilitaumlt unseres Verfahren nachgewiesen koumlnnen je-doch noch keine Angaben dazu machen ob sich unsere Software physikalisch richtig verhaumllt (vgl Ab-schnitt 412)

22

KAPITEL 4 TESTS 23

0 20 40 60 80 100 120 140 160minus1

0

1x 10

minus4

Zeitschritt

Vek

torn

orm

GeschwindigkeitDruck

Abbildung 41 Vektornomen des Druck- und Geschwindigkeitsvektors uumlber mehrere Zeitschritte

412 Physikalisch richtiges Verhalten

Wie schon im vorherigen Kapitel 411 erwaumlhnt werden wir in diesem Abschnitt unsere Software aufdie Korrektheit ihrer Loumlsung untersuchen Wir werden also herausfinden ob sich unsere Simulationphysikalisch richtig verhaumllt Um dies zu erzielen greifen wir auf den gaumlngigen Testfall Driven Cavityzum Testen von Stroumlmungssimulationen zuruumlck

Abbildung 42 Konfiguration fuumlr den Testfall Driven Cavity

Driven Cavity ist ein einfacher Testfall an dem man jedoch viel uumlber die Richtigkeit unserer Imple-mentierung erfahren kann Wir wollen zunaumlchst erlaumlutern welche Testkonfiguration fuumlr Driven Cavitygewaumlhlt werden muss Der wichtigste Schritt ist die richtigen Anfangs- und Randbedingungen vorzu-

KAPITEL 4 TESTS 24

schreiben Ziel bei Driven Cavity ist es an einer Kante unseres Gitters in tangentialer Richtung mitkonstanter Geschwindigkeit v0 kontinuierlich das heiszligt waumlhrend des gesamten Zeitintervalls zu strouml-men wie in Abbildung 42 dargestellt An allen uumlbrigen Kanten wird uumlber das Zeitintervall hinweg Nullvorgeschrieben sowohl in x- als auch in y- Richtung In unserem Fall waumlhlen wir die obere Kante undstroumlmen in positive x-RichtungUm zu erreichen dass wir in jedem Zeitschritt erneut die Geschwindigkeit v0 an der oberen Kante in x-Richtung und Geschwindigkeit Null an den anderen Kanten aufpraumlgen muumlssen wir dies am Ende jedesZeitschritts in unserem Loumlser velocity und am Anfang des Tracer (vgl Kapitel 31) erneut setzenda hier die Randwerte uumlberschrieben werden und wir dies nicht zulassen wollen In den uumlbrigen Teilenunseres Loumlsers muumlssen wir dies nicht tun da hier lediglich die inneren Gitterpunkte behandelt werden(siehe Kapitel 31)Als naumlchstes legen wir nun unsere Parameter wie folgt fest

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (42)

Visuell wird die x-Komponente der Geschwindigkeit dargestellt und es ergibt sich folgendes initialesBild (Abbildung 43)

Abbildung 43 Initale Verteilung der x-Komponete der Geschwindigkeit

Man kann in Abbildung 43 deutlich eine Stroumlmung an der oberen Kannte unseres Gitters erkennengenauso wie wir es vorgegeben haben An allen uumlbrigen Punkten unseres Gitters betraumlgt die Geschwin-digkeit in x-Richtung NullWenn wir unsere Simulation uumlber einen laumlngeren Zeitraum laufen lassen stellen wir fest dass sich diein Abbildung 44 angefuumlhrte Verteilung der Geschwindigkeit einstellt und diese sich auch nach weiterenZeitschritten nicht weiter veraumlndert Um die Korrektheit unserer Loumlsung zu verifizieren vergleichen wirunsere visuelle Darstellung in Abbildung 44(a) mit bekannten richtigen Loumlsungen dieses Testfalls inAbbildung 44(b) Es ist gut zu erkennen dass unsere Darstellung die gleichen Merkmale aufweist wiedas Referenzbild 44(b)Am oberen Rand stellt sich ein Gebiet ein welches groszlige Geschwindigkeiten in x-Richtung aufweist dahier die kontinuierliche Geschwindigkeit v0 eingestellt wird welche jedoch zur Mitte hin immer weiterabnimmt Die Form dieses Gebietes ist bei beiden Bildern bis auf unterschiedliche Faumlrbungen zuruumlck-zufuumlhren auf das Verwenden verschiedener Heat Maps (vgl Kapitel 32) gleich In unserem Fall wirddas Farbspektrum in 19 Farben unterteilt und im Referenzfall in 26 (vgl Kapitel 32 und [CFD Online])In der Mitte schlieszliglich zieht sich ein nahezu stillstehendes Gebiet erkennbar durch die dunkelblaue

KAPITEL 4 TESTS 25

Faumlrbung in die obere rechte Ecke Da es eine sehr groszlige Aumlhnlichkeit zwischen unserem und dem Refe-renzbild gibt koumlnnen wir erwarten dass unsere Stroumlmungssimulation richtig implementiert wurde undeiner physikalisch realistischen Simulation entspricht

(a) Darstellung des Testfalls Driven Cavity nachvielen Zeitschritten

(b) Referenzbild zu Driven Cavity von [CFD Onli-ne]

Abbildung 44 Vergleich unserer Simulation durch ein Referenzbild am Testfall Driven Cavity

Wir gehen somit in den folgenden Kapiteln davon aus dass unsere Software einer physikalisch richtigenSimulation enspricht und numerisch stabil laumluft

KAPITEL 4 TESTS 26

42 Parametertests

In diesem Abschnitt wollen wir den Einfluss verschiedener Parameter auf unsere Simulation am TestfallHubbel (vgl Abbildung 45) untersuchen Als Erstes wollen wir den Einfluss der Viskositaumlt ν wel-ches ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres zugrunde liegenden Fluids darstellt untersuchen Anschlie-szligend befassen wir uns mit dem Zeitschritt ∆t welcher ausschlieszliglich im Tracer (siehe hierzu Kapitel 31) benoumltigt wird und hier ein Maszlig fuumlr die Genauigkeit darstellt Als Letztes werden wir den Ein-fluss der Anzahl der Jacobi-Schritte und damit die Genauigkeitsanforderungen des linearen Loumlsers (vglKapitel 31) untersuchen und anhand der visuellen Darstellung unserer Simulation analysieren wie ge-nau wir loumlsen muumlssen um Symmetrie zu erreichen Sollte unser Verfahren unter der Voraussetzung einessymmetrischen Testfalls symmetrische Ergebnisse liefern so koumlnnen wir von einer sehr guten numeri-schen Approximation einer realen Loumlsung sprechen was in unserem Fall aus einer hohen Genauigkeitdes Druck- und Geschwindigkeitsfeldes resultiertAls Standardkonfiguration waumlhlen wir folgende Werte fuumlr die in unserem Modell frei waumlhlbaren Para-meter

n = 129 h =1

128 ν = 00003 v0 = 000015 ∆t =

1

(nminus 1) middot v0 middot 200 maxiter = 32 (43)

In diesem Fall und anders als im vorherigen Testfall Driven Cavity (vgl Kapitel 412) benoumltigen wirv0 lediglich zur Bestimmung von ∆t da wir im folgenden keine initiale oder kontinuierliche Geschwin-digkeit auftragen wollen Waumlhrend jedes Tests wird ausschlieszliglich ein Parameter veraumlndert um seineAuswirkungen unabhaumlngig von den anderen Groumlszligen analysieren zu koumlnnenAls Ausgangssituation waumlhlen wir den Testfall Hubbel den wir als naumlchstes beschreiben werdenDie initiale Geschwindigkeit und Kraft in jedem Punkt unseres Gitters setzen wir als Null und schreibenfuumlr den Druck Werte so vor dass wir zwei Druckspitzen erhalten (siehe Abbildung 45) Dies realisierenwir mit Hilfe der Gauszligglockenkurve im Zweidimensionalen (siehe Gleichung (44)) da wir so auszliger-halb der Druckspitzen nahezu Null realisieren koumlnnen und wir einen stetigen Druckverlauf sogar Cinfinerzielen

f(x y) = exp(a (xminus x0)2 + a (y minus y0)2 + b

)(44)

Hierbei ist a ein Verzerrungsfaktor und b der Wert im Glockenmittelpunkt (x0 y0) Addieren wir nunzwei Glockenkurven mit a = minus50 b = 0 x1

0 = 05 und y10 = minus05 beziehungsweise x2

0 = minus05 undy2

0 = 05 erhalten wir die folgende initiale Druckverteilung

minus1 minus08 minus06 minus04 minus02 0 02 04 06 08 1minus1

minus050

0510

01

02

03

04

05

06

07

08

09

1

Abbildung 45 Initiale Druckverteilung des Testfalls Hubbel mit zwei Druckspitzen

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 23

0 20 40 60 80 100 120 140 160minus1

0

1x 10

minus4

Zeitschritt

Vek

torn

orm

GeschwindigkeitDruck

Abbildung 41 Vektornomen des Druck- und Geschwindigkeitsvektors uumlber mehrere Zeitschritte

412 Physikalisch richtiges Verhalten

Wie schon im vorherigen Kapitel 411 erwaumlhnt werden wir in diesem Abschnitt unsere Software aufdie Korrektheit ihrer Loumlsung untersuchen Wir werden also herausfinden ob sich unsere Simulationphysikalisch richtig verhaumllt Um dies zu erzielen greifen wir auf den gaumlngigen Testfall Driven Cavityzum Testen von Stroumlmungssimulationen zuruumlck

Abbildung 42 Konfiguration fuumlr den Testfall Driven Cavity

Driven Cavity ist ein einfacher Testfall an dem man jedoch viel uumlber die Richtigkeit unserer Imple-mentierung erfahren kann Wir wollen zunaumlchst erlaumlutern welche Testkonfiguration fuumlr Driven Cavitygewaumlhlt werden muss Der wichtigste Schritt ist die richtigen Anfangs- und Randbedingungen vorzu-

KAPITEL 4 TESTS 24

schreiben Ziel bei Driven Cavity ist es an einer Kante unseres Gitters in tangentialer Richtung mitkonstanter Geschwindigkeit v0 kontinuierlich das heiszligt waumlhrend des gesamten Zeitintervalls zu strouml-men wie in Abbildung 42 dargestellt An allen uumlbrigen Kanten wird uumlber das Zeitintervall hinweg Nullvorgeschrieben sowohl in x- als auch in y- Richtung In unserem Fall waumlhlen wir die obere Kante undstroumlmen in positive x-RichtungUm zu erreichen dass wir in jedem Zeitschritt erneut die Geschwindigkeit v0 an der oberen Kante in x-Richtung und Geschwindigkeit Null an den anderen Kanten aufpraumlgen muumlssen wir dies am Ende jedesZeitschritts in unserem Loumlser velocity und am Anfang des Tracer (vgl Kapitel 31) erneut setzenda hier die Randwerte uumlberschrieben werden und wir dies nicht zulassen wollen In den uumlbrigen Teilenunseres Loumlsers muumlssen wir dies nicht tun da hier lediglich die inneren Gitterpunkte behandelt werden(siehe Kapitel 31)Als naumlchstes legen wir nun unsere Parameter wie folgt fest

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (42)

Visuell wird die x-Komponente der Geschwindigkeit dargestellt und es ergibt sich folgendes initialesBild (Abbildung 43)

Abbildung 43 Initale Verteilung der x-Komponete der Geschwindigkeit

Man kann in Abbildung 43 deutlich eine Stroumlmung an der oberen Kannte unseres Gitters erkennengenauso wie wir es vorgegeben haben An allen uumlbrigen Punkten unseres Gitters betraumlgt die Geschwin-digkeit in x-Richtung NullWenn wir unsere Simulation uumlber einen laumlngeren Zeitraum laufen lassen stellen wir fest dass sich diein Abbildung 44 angefuumlhrte Verteilung der Geschwindigkeit einstellt und diese sich auch nach weiterenZeitschritten nicht weiter veraumlndert Um die Korrektheit unserer Loumlsung zu verifizieren vergleichen wirunsere visuelle Darstellung in Abbildung 44(a) mit bekannten richtigen Loumlsungen dieses Testfalls inAbbildung 44(b) Es ist gut zu erkennen dass unsere Darstellung die gleichen Merkmale aufweist wiedas Referenzbild 44(b)Am oberen Rand stellt sich ein Gebiet ein welches groszlige Geschwindigkeiten in x-Richtung aufweist dahier die kontinuierliche Geschwindigkeit v0 eingestellt wird welche jedoch zur Mitte hin immer weiterabnimmt Die Form dieses Gebietes ist bei beiden Bildern bis auf unterschiedliche Faumlrbungen zuruumlck-zufuumlhren auf das Verwenden verschiedener Heat Maps (vgl Kapitel 32) gleich In unserem Fall wirddas Farbspektrum in 19 Farben unterteilt und im Referenzfall in 26 (vgl Kapitel 32 und [CFD Online])In der Mitte schlieszliglich zieht sich ein nahezu stillstehendes Gebiet erkennbar durch die dunkelblaue

KAPITEL 4 TESTS 25

Faumlrbung in die obere rechte Ecke Da es eine sehr groszlige Aumlhnlichkeit zwischen unserem und dem Refe-renzbild gibt koumlnnen wir erwarten dass unsere Stroumlmungssimulation richtig implementiert wurde undeiner physikalisch realistischen Simulation entspricht

(a) Darstellung des Testfalls Driven Cavity nachvielen Zeitschritten

(b) Referenzbild zu Driven Cavity von [CFD Onli-ne]

Abbildung 44 Vergleich unserer Simulation durch ein Referenzbild am Testfall Driven Cavity

Wir gehen somit in den folgenden Kapiteln davon aus dass unsere Software einer physikalisch richtigenSimulation enspricht und numerisch stabil laumluft

KAPITEL 4 TESTS 26

42 Parametertests

In diesem Abschnitt wollen wir den Einfluss verschiedener Parameter auf unsere Simulation am TestfallHubbel (vgl Abbildung 45) untersuchen Als Erstes wollen wir den Einfluss der Viskositaumlt ν wel-ches ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres zugrunde liegenden Fluids darstellt untersuchen Anschlie-szligend befassen wir uns mit dem Zeitschritt ∆t welcher ausschlieszliglich im Tracer (siehe hierzu Kapitel 31) benoumltigt wird und hier ein Maszlig fuumlr die Genauigkeit darstellt Als Letztes werden wir den Ein-fluss der Anzahl der Jacobi-Schritte und damit die Genauigkeitsanforderungen des linearen Loumlsers (vglKapitel 31) untersuchen und anhand der visuellen Darstellung unserer Simulation analysieren wie ge-nau wir loumlsen muumlssen um Symmetrie zu erreichen Sollte unser Verfahren unter der Voraussetzung einessymmetrischen Testfalls symmetrische Ergebnisse liefern so koumlnnen wir von einer sehr guten numeri-schen Approximation einer realen Loumlsung sprechen was in unserem Fall aus einer hohen Genauigkeitdes Druck- und Geschwindigkeitsfeldes resultiertAls Standardkonfiguration waumlhlen wir folgende Werte fuumlr die in unserem Modell frei waumlhlbaren Para-meter

n = 129 h =1

128 ν = 00003 v0 = 000015 ∆t =

1

(nminus 1) middot v0 middot 200 maxiter = 32 (43)

In diesem Fall und anders als im vorherigen Testfall Driven Cavity (vgl Kapitel 412) benoumltigen wirv0 lediglich zur Bestimmung von ∆t da wir im folgenden keine initiale oder kontinuierliche Geschwin-digkeit auftragen wollen Waumlhrend jedes Tests wird ausschlieszliglich ein Parameter veraumlndert um seineAuswirkungen unabhaumlngig von den anderen Groumlszligen analysieren zu koumlnnenAls Ausgangssituation waumlhlen wir den Testfall Hubbel den wir als naumlchstes beschreiben werdenDie initiale Geschwindigkeit und Kraft in jedem Punkt unseres Gitters setzen wir als Null und schreibenfuumlr den Druck Werte so vor dass wir zwei Druckspitzen erhalten (siehe Abbildung 45) Dies realisierenwir mit Hilfe der Gauszligglockenkurve im Zweidimensionalen (siehe Gleichung (44)) da wir so auszliger-halb der Druckspitzen nahezu Null realisieren koumlnnen und wir einen stetigen Druckverlauf sogar Cinfinerzielen

f(x y) = exp(a (xminus x0)2 + a (y minus y0)2 + b

)(44)

Hierbei ist a ein Verzerrungsfaktor und b der Wert im Glockenmittelpunkt (x0 y0) Addieren wir nunzwei Glockenkurven mit a = minus50 b = 0 x1

0 = 05 und y10 = minus05 beziehungsweise x2

0 = minus05 undy2

0 = 05 erhalten wir die folgende initiale Druckverteilung

minus1 minus08 minus06 minus04 minus02 0 02 04 06 08 1minus1

minus050

0510

01

02

03

04

05

06

07

08

09

1

Abbildung 45 Initiale Druckverteilung des Testfalls Hubbel mit zwei Druckspitzen

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 24

schreiben Ziel bei Driven Cavity ist es an einer Kante unseres Gitters in tangentialer Richtung mitkonstanter Geschwindigkeit v0 kontinuierlich das heiszligt waumlhrend des gesamten Zeitintervalls zu strouml-men wie in Abbildung 42 dargestellt An allen uumlbrigen Kanten wird uumlber das Zeitintervall hinweg Nullvorgeschrieben sowohl in x- als auch in y- Richtung In unserem Fall waumlhlen wir die obere Kante undstroumlmen in positive x-RichtungUm zu erreichen dass wir in jedem Zeitschritt erneut die Geschwindigkeit v0 an der oberen Kante in x-Richtung und Geschwindigkeit Null an den anderen Kanten aufpraumlgen muumlssen wir dies am Ende jedesZeitschritts in unserem Loumlser velocity und am Anfang des Tracer (vgl Kapitel 31) erneut setzenda hier die Randwerte uumlberschrieben werden und wir dies nicht zulassen wollen In den uumlbrigen Teilenunseres Loumlsers muumlssen wir dies nicht tun da hier lediglich die inneren Gitterpunkte behandelt werden(siehe Kapitel 31)Als naumlchstes legen wir nun unsere Parameter wie folgt fest

h =1

128 ν = 00003 maxiter = 32 ∆t =

h

200v0 v0 = 000015 (42)

Visuell wird die x-Komponente der Geschwindigkeit dargestellt und es ergibt sich folgendes initialesBild (Abbildung 43)

Abbildung 43 Initale Verteilung der x-Komponete der Geschwindigkeit

Man kann in Abbildung 43 deutlich eine Stroumlmung an der oberen Kannte unseres Gitters erkennengenauso wie wir es vorgegeben haben An allen uumlbrigen Punkten unseres Gitters betraumlgt die Geschwin-digkeit in x-Richtung NullWenn wir unsere Simulation uumlber einen laumlngeren Zeitraum laufen lassen stellen wir fest dass sich diein Abbildung 44 angefuumlhrte Verteilung der Geschwindigkeit einstellt und diese sich auch nach weiterenZeitschritten nicht weiter veraumlndert Um die Korrektheit unserer Loumlsung zu verifizieren vergleichen wirunsere visuelle Darstellung in Abbildung 44(a) mit bekannten richtigen Loumlsungen dieses Testfalls inAbbildung 44(b) Es ist gut zu erkennen dass unsere Darstellung die gleichen Merkmale aufweist wiedas Referenzbild 44(b)Am oberen Rand stellt sich ein Gebiet ein welches groszlige Geschwindigkeiten in x-Richtung aufweist dahier die kontinuierliche Geschwindigkeit v0 eingestellt wird welche jedoch zur Mitte hin immer weiterabnimmt Die Form dieses Gebietes ist bei beiden Bildern bis auf unterschiedliche Faumlrbungen zuruumlck-zufuumlhren auf das Verwenden verschiedener Heat Maps (vgl Kapitel 32) gleich In unserem Fall wirddas Farbspektrum in 19 Farben unterteilt und im Referenzfall in 26 (vgl Kapitel 32 und [CFD Online])In der Mitte schlieszliglich zieht sich ein nahezu stillstehendes Gebiet erkennbar durch die dunkelblaue

KAPITEL 4 TESTS 25

Faumlrbung in die obere rechte Ecke Da es eine sehr groszlige Aumlhnlichkeit zwischen unserem und dem Refe-renzbild gibt koumlnnen wir erwarten dass unsere Stroumlmungssimulation richtig implementiert wurde undeiner physikalisch realistischen Simulation entspricht

(a) Darstellung des Testfalls Driven Cavity nachvielen Zeitschritten

(b) Referenzbild zu Driven Cavity von [CFD Onli-ne]

Abbildung 44 Vergleich unserer Simulation durch ein Referenzbild am Testfall Driven Cavity

Wir gehen somit in den folgenden Kapiteln davon aus dass unsere Software einer physikalisch richtigenSimulation enspricht und numerisch stabil laumluft

KAPITEL 4 TESTS 26

42 Parametertests

In diesem Abschnitt wollen wir den Einfluss verschiedener Parameter auf unsere Simulation am TestfallHubbel (vgl Abbildung 45) untersuchen Als Erstes wollen wir den Einfluss der Viskositaumlt ν wel-ches ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres zugrunde liegenden Fluids darstellt untersuchen Anschlie-szligend befassen wir uns mit dem Zeitschritt ∆t welcher ausschlieszliglich im Tracer (siehe hierzu Kapitel 31) benoumltigt wird und hier ein Maszlig fuumlr die Genauigkeit darstellt Als Letztes werden wir den Ein-fluss der Anzahl der Jacobi-Schritte und damit die Genauigkeitsanforderungen des linearen Loumlsers (vglKapitel 31) untersuchen und anhand der visuellen Darstellung unserer Simulation analysieren wie ge-nau wir loumlsen muumlssen um Symmetrie zu erreichen Sollte unser Verfahren unter der Voraussetzung einessymmetrischen Testfalls symmetrische Ergebnisse liefern so koumlnnen wir von einer sehr guten numeri-schen Approximation einer realen Loumlsung sprechen was in unserem Fall aus einer hohen Genauigkeitdes Druck- und Geschwindigkeitsfeldes resultiertAls Standardkonfiguration waumlhlen wir folgende Werte fuumlr die in unserem Modell frei waumlhlbaren Para-meter

n = 129 h =1

128 ν = 00003 v0 = 000015 ∆t =

1

(nminus 1) middot v0 middot 200 maxiter = 32 (43)

In diesem Fall und anders als im vorherigen Testfall Driven Cavity (vgl Kapitel 412) benoumltigen wirv0 lediglich zur Bestimmung von ∆t da wir im folgenden keine initiale oder kontinuierliche Geschwin-digkeit auftragen wollen Waumlhrend jedes Tests wird ausschlieszliglich ein Parameter veraumlndert um seineAuswirkungen unabhaumlngig von den anderen Groumlszligen analysieren zu koumlnnenAls Ausgangssituation waumlhlen wir den Testfall Hubbel den wir als naumlchstes beschreiben werdenDie initiale Geschwindigkeit und Kraft in jedem Punkt unseres Gitters setzen wir als Null und schreibenfuumlr den Druck Werte so vor dass wir zwei Druckspitzen erhalten (siehe Abbildung 45) Dies realisierenwir mit Hilfe der Gauszligglockenkurve im Zweidimensionalen (siehe Gleichung (44)) da wir so auszliger-halb der Druckspitzen nahezu Null realisieren koumlnnen und wir einen stetigen Druckverlauf sogar Cinfinerzielen

f(x y) = exp(a (xminus x0)2 + a (y minus y0)2 + b

)(44)

Hierbei ist a ein Verzerrungsfaktor und b der Wert im Glockenmittelpunkt (x0 y0) Addieren wir nunzwei Glockenkurven mit a = minus50 b = 0 x1

0 = 05 und y10 = minus05 beziehungsweise x2

0 = minus05 undy2

0 = 05 erhalten wir die folgende initiale Druckverteilung

minus1 minus08 minus06 minus04 minus02 0 02 04 06 08 1minus1

minus050

0510

01

02

03

04

05

06

07

08

09

1

Abbildung 45 Initiale Druckverteilung des Testfalls Hubbel mit zwei Druckspitzen

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 25

Faumlrbung in die obere rechte Ecke Da es eine sehr groszlige Aumlhnlichkeit zwischen unserem und dem Refe-renzbild gibt koumlnnen wir erwarten dass unsere Stroumlmungssimulation richtig implementiert wurde undeiner physikalisch realistischen Simulation entspricht

(a) Darstellung des Testfalls Driven Cavity nachvielen Zeitschritten

(b) Referenzbild zu Driven Cavity von [CFD Onli-ne]

Abbildung 44 Vergleich unserer Simulation durch ein Referenzbild am Testfall Driven Cavity

Wir gehen somit in den folgenden Kapiteln davon aus dass unsere Software einer physikalisch richtigenSimulation enspricht und numerisch stabil laumluft

KAPITEL 4 TESTS 26

42 Parametertests

In diesem Abschnitt wollen wir den Einfluss verschiedener Parameter auf unsere Simulation am TestfallHubbel (vgl Abbildung 45) untersuchen Als Erstes wollen wir den Einfluss der Viskositaumlt ν wel-ches ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres zugrunde liegenden Fluids darstellt untersuchen Anschlie-szligend befassen wir uns mit dem Zeitschritt ∆t welcher ausschlieszliglich im Tracer (siehe hierzu Kapitel 31) benoumltigt wird und hier ein Maszlig fuumlr die Genauigkeit darstellt Als Letztes werden wir den Ein-fluss der Anzahl der Jacobi-Schritte und damit die Genauigkeitsanforderungen des linearen Loumlsers (vglKapitel 31) untersuchen und anhand der visuellen Darstellung unserer Simulation analysieren wie ge-nau wir loumlsen muumlssen um Symmetrie zu erreichen Sollte unser Verfahren unter der Voraussetzung einessymmetrischen Testfalls symmetrische Ergebnisse liefern so koumlnnen wir von einer sehr guten numeri-schen Approximation einer realen Loumlsung sprechen was in unserem Fall aus einer hohen Genauigkeitdes Druck- und Geschwindigkeitsfeldes resultiertAls Standardkonfiguration waumlhlen wir folgende Werte fuumlr die in unserem Modell frei waumlhlbaren Para-meter

n = 129 h =1

128 ν = 00003 v0 = 000015 ∆t =

1

(nminus 1) middot v0 middot 200 maxiter = 32 (43)

In diesem Fall und anders als im vorherigen Testfall Driven Cavity (vgl Kapitel 412) benoumltigen wirv0 lediglich zur Bestimmung von ∆t da wir im folgenden keine initiale oder kontinuierliche Geschwin-digkeit auftragen wollen Waumlhrend jedes Tests wird ausschlieszliglich ein Parameter veraumlndert um seineAuswirkungen unabhaumlngig von den anderen Groumlszligen analysieren zu koumlnnenAls Ausgangssituation waumlhlen wir den Testfall Hubbel den wir als naumlchstes beschreiben werdenDie initiale Geschwindigkeit und Kraft in jedem Punkt unseres Gitters setzen wir als Null und schreibenfuumlr den Druck Werte so vor dass wir zwei Druckspitzen erhalten (siehe Abbildung 45) Dies realisierenwir mit Hilfe der Gauszligglockenkurve im Zweidimensionalen (siehe Gleichung (44)) da wir so auszliger-halb der Druckspitzen nahezu Null realisieren koumlnnen und wir einen stetigen Druckverlauf sogar Cinfinerzielen

f(x y) = exp(a (xminus x0)2 + a (y minus y0)2 + b

)(44)

Hierbei ist a ein Verzerrungsfaktor und b der Wert im Glockenmittelpunkt (x0 y0) Addieren wir nunzwei Glockenkurven mit a = minus50 b = 0 x1

0 = 05 und y10 = minus05 beziehungsweise x2

0 = minus05 undy2

0 = 05 erhalten wir die folgende initiale Druckverteilung

minus1 minus08 minus06 minus04 minus02 0 02 04 06 08 1minus1

minus050

0510

01

02

03

04

05

06

07

08

09

1

Abbildung 45 Initiale Druckverteilung des Testfalls Hubbel mit zwei Druckspitzen

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 26

42 Parametertests

In diesem Abschnitt wollen wir den Einfluss verschiedener Parameter auf unsere Simulation am TestfallHubbel (vgl Abbildung 45) untersuchen Als Erstes wollen wir den Einfluss der Viskositaumlt ν wel-ches ein Maszlig fuumlr die Zaumlhfluumlssigkeit unseres zugrunde liegenden Fluids darstellt untersuchen Anschlie-szligend befassen wir uns mit dem Zeitschritt ∆t welcher ausschlieszliglich im Tracer (siehe hierzu Kapitel 31) benoumltigt wird und hier ein Maszlig fuumlr die Genauigkeit darstellt Als Letztes werden wir den Ein-fluss der Anzahl der Jacobi-Schritte und damit die Genauigkeitsanforderungen des linearen Loumlsers (vglKapitel 31) untersuchen und anhand der visuellen Darstellung unserer Simulation analysieren wie ge-nau wir loumlsen muumlssen um Symmetrie zu erreichen Sollte unser Verfahren unter der Voraussetzung einessymmetrischen Testfalls symmetrische Ergebnisse liefern so koumlnnen wir von einer sehr guten numeri-schen Approximation einer realen Loumlsung sprechen was in unserem Fall aus einer hohen Genauigkeitdes Druck- und Geschwindigkeitsfeldes resultiertAls Standardkonfiguration waumlhlen wir folgende Werte fuumlr die in unserem Modell frei waumlhlbaren Para-meter

n = 129 h =1

128 ν = 00003 v0 = 000015 ∆t =

1

(nminus 1) middot v0 middot 200 maxiter = 32 (43)

In diesem Fall und anders als im vorherigen Testfall Driven Cavity (vgl Kapitel 412) benoumltigen wirv0 lediglich zur Bestimmung von ∆t da wir im folgenden keine initiale oder kontinuierliche Geschwin-digkeit auftragen wollen Waumlhrend jedes Tests wird ausschlieszliglich ein Parameter veraumlndert um seineAuswirkungen unabhaumlngig von den anderen Groumlszligen analysieren zu koumlnnenAls Ausgangssituation waumlhlen wir den Testfall Hubbel den wir als naumlchstes beschreiben werdenDie initiale Geschwindigkeit und Kraft in jedem Punkt unseres Gitters setzen wir als Null und schreibenfuumlr den Druck Werte so vor dass wir zwei Druckspitzen erhalten (siehe Abbildung 45) Dies realisierenwir mit Hilfe der Gauszligglockenkurve im Zweidimensionalen (siehe Gleichung (44)) da wir so auszliger-halb der Druckspitzen nahezu Null realisieren koumlnnen und wir einen stetigen Druckverlauf sogar Cinfinerzielen

f(x y) = exp(a (xminus x0)2 + a (y minus y0)2 + b

)(44)

Hierbei ist a ein Verzerrungsfaktor und b der Wert im Glockenmittelpunkt (x0 y0) Addieren wir nunzwei Glockenkurven mit a = minus50 b = 0 x1

0 = 05 und y10 = minus05 beziehungsweise x2

0 = minus05 undy2

0 = 05 erhalten wir die folgende initiale Druckverteilung

minus1 minus08 minus06 minus04 minus02 0 02 04 06 08 1minus1

minus050

0510

01

02

03

04

05

06

07

08

09

1

Abbildung 45 Initiale Druckverteilung des Testfalls Hubbel mit zwei Druckspitzen

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 27

Da wir die Druckverteilung lediglich anfaumlnglich setzen fallen im Laufe der Zeit die Druckspitzen zu-sammen und es entstehen Wellen Dabei kann man mit Hilfe der Addition mehrerer Gauszligkurven beliebigviele Druckspitzen erzeugen

421 Viskositaumlt

Die Viskositaumlt ist der einzige freie Parameter unseres Modells zur Simulation von Stroumlmungen welcherunser betrachetes Fluid beschreibt und daher von entscheidener Bedeutung bei der Untersuchung unsererImplementierung Im Folgenden wollen wir den Einfluss der kinematischen Viskositaumlt ν auf unsere Si-mulation untersuchen indem wir verschiedene Werte fuumlr ν vorschreiben und das Flieszligverhalten und dieDruckverlaumlufe unserer Fluumlssigkeit untersuchen Dazu betrachten wir die in der Tabelle 41 aufgelistetenStoffe wobei die Dichte in [ρ] = kg

m3 die dynamische Viskositaumlt in [η] = Nsm2 und die kinematische

Viskositaumlt in [ν] = m2

s angeben wird

Dichte dynamische Viskositaumlt kinematische ViskositaumltQuecksilber 13546 155 00001Wasser bei 20C 1000 100 0001Motoroumll 878 1054 0012Olivenoumll 915 100 0109

Tabelle 41 Stoffspezifische Groumlszligen

Zur Untersuchung analysieren wir den Druck im Mittelpunkt unseres Gebiets entlang eines Zeitintervallsfuumlr unterschiedliche Werte von ν Wir waumlhlen den Mittelpunkt unseres Gebiets als Referenzpunkt da hierdurch die Gauszligkurven ein Druck von nahezu Null herrscht und wir mit Sicherheit keinen Punkt am Randbetrachten an dem besondere Randbedingungen gelten und wir dies ausschlieszligen moumlchten (vgl Kapitel 22) Zu erwarten ist dass Fluide mit houmlherer Viskositaumlt kleinere Druckamplituden entwickeln unddie Amplitudenlaumlnge geringer ist als bei Fluiden geringerer Viskositaumlt

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

Zeitschritt

Dru

ck

MotoroelOlivenoel

Abbildung 46 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Olivenoumll und Motoroumll

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 28

Als Erstes vergleichen wir die Fluumlssigkeiten Olivenoumll mit Motoroumll aus Tabelle 41 und erhalten die inAbbildung 46 dargestellten Druckverlaumlufe Wir koumlnnen deutlich erkennen dass der Druckverlauf vonMotoroumll welches eine geringere kinematische Viskositaumlt besitzt als Olivenoumll groumlszligere Amplituden auf-weist als der von Olivenoumll Weiter laumlsst sich beobachten dass das Fluid mit der houmlheren Viskositaumlt hierOlivenoumll schneller zur Ruhe kommt nach circa 60 Zeitschritten wohingegen Motoroumll 80 Zeitschrittebenoumltigt Bei beiden Stoffen zeigt sich auszligerdem dass der anfaumlngliche Druck im betrachteten Mittel-punkt am Ende des Zeitintervalls nicht mehr vorliegt Wir koumlnnen hier einen Druckanstieg bei beidenStoffen beobachten Dies ist darauf zuruumlckzufuumlhren dass sich das Volumen der Fluumlssigkeitspitzen desinitialen Druckverlaufs uumlber das gesamte Rechengebiet verteilt hat und somit nach dem Zusammenfallder Spitzen an jedem Gitterpunkt ein erhoumlhter Druck herrscht Der unterschiedlich starke Druckanstieglaumlsst sich hier durch die verschiedenen Viskositaumlten erklaumlrenWir wollen nun das Flieszligverhalten der Fluumlssigkeiten Motoroumll und Wasser untersuchen und erhalten diein Abbildung 47 dargestellten Druckverlaumlufe

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

MotoroelWasser

Abbildung 47 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Motoroumll und Wasser

Wie schon bei dem zuvor betrachteten Testfall lassen sich auch hier sowohl deutlich groumlszligere Amplitudenbei dem Stoff der kleineren Viskositaumlt ausmachen als auch eine laumlngere Lebensdauer der AmplitudenDie Tatsache dass nach dem Drucktiefpunkt bei etwa 18-20 Schritten die Kurve von Motoroumll eine schein-bar groumlszligere Amplitude besitzt als die von Wasser hat die Ursache darin dass das neue Nullniveau desMotoroumlls das heiszligt der sich einstellende Enddruck oberhalb des von Wasser liegt Somit ist der Druckzwar ab diesem Zeitschritt groumlszliger als der von Wasser jedoch besitzt die Kurve fuumlr den Druckverlauf vonWasser weiterhin eine groumlszligere Amplitude Auch hier laumlsst sich wie eben erwaumlhnt ein unterschiedlichhoher Druck am Ende des Tests feststellenAls letzten Testfall wollen wir Quecksilber mit Wasser vergleichen und erhalten die in Abbildung 48dargestellten Druckverlaumlufe In dieser Konfiguration besitzen beide Stoffe sehr kleine Viskositaumlten (vglTabelle 41) und es lassen sich nicht mehr so starke Amplitudenunterschiede erkennen wie bei den Test-faumlllen zuvor Dies ist darauf zuruumlckzufuumlhren dass durch die sehr kleinen Viskositaumlten die Stoffe so bdquofluumls-sigldquo geworden sind dass sie sich fuumlr unser Modell kaum noch unterscheiden Trotz der geringen Vis-kositaumlten verhalten sich die Stoffe passend zu den Tests zuvor Wir erhalten wieder bei der Fluumlssigkeitder geringeren Viskositaumlt einen geringern Druck am Ende unseres betrachteten Zeitintervalls und koumlnnen

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 29

hier mehr Oszillationen erkennen

0 20 40 60 80 100 120 140 160minus001

0

001

002

003

004

005

006

007

008

Zeitschritt

Dru

ck

WasserQuecksilber

Abbildung 48 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr die Stoffe Wasser und Quecksilber

Abschlieszligend halten wir fest dass die Werte der Viskositaumlt starken Einfluss auf unsere Simulationenhaben und sich diese der Realitaumlt entsprechend verhaumllt Wir erhalten bei Stoffen geringerer Viskositaumltalso Stoffe die weniger zaumlhfluumlssig sind groumlszligere Druckamplituden mehr Oszilationen und eine laumlngereLebensdauer der entstanden Wellen als bei Stoffen houmlherer Viskositaumlt Diese erreichen zwar fruumlher einenkonstanten Druck jedoch liegt er oberhalb des von Stoffen geringer Viskositaumlt Dies liegt daran dass fuumlrunser Modell die kinematische Viskositaumlt ν verwendet wird also der Quotient aus dynamischer Viskosi-taumlt η und der Dichte ρ Es liegt uns also lediglich ein Wert fuumlr die Eigenschaften eines Stoffes vor Somithaben wir da der Parameter ρ nicht explizit in unserem Modell vorkommt nicht die Moumlglichkeit zwi-schen bdquoleichtenldquo und bdquoschwerenldquo Fluiden das heiszligt Fluide mit einer geringen Dichte beziehungsweisehoher Dichte zu unterscheiden Wir haben beispielsweise in dem Test zwischen Wasser und Quecksilver(vgl Abbildung 48) einen erhoumlhten Enddruck bei Wasser als bei Quecksilber Dies ist jedoch aus dennachfolgenden Gruumlnden physikalisch unrealistischDruck ist definiert uumlber bdquoKraft pro Flaumlcheldquo und da in unserem Fall die Kraft ausschlieszliglich aus dereigenen Gewichtskraft des Fluids resultiert und nach dem zweiten Newtonschen Gesetz bdquoKraft gleichMasse mal Beschleunigungldquo ist koumlnnen wir also einen proportionalen Zusammenhang zwischen Druckund Masse erkennen da sowohl die Flaumlche als auch die Beschleunigung hier die Erdbeschleunigungkonstant sind Weiter gilt fuumlr die Masse der Zusammenhang bdquoMasse gleich Dichte mal Volumenldquo Wirkoumlnnen also folgende drei Gesetze festhalten

P =F

A F = m middot g und m = ρ middot V

Schlieszliglich erhalten wir durch ineinander Einsetzen der drei Gesetze

P =ρ middot g middot VA

(45)

Da die Erdbeschleunigung g die Flaumlche A auf die die Druckkraft wirkt und unser Volumen V wie obenbeschrieben als konstant angenommen werden koumlnnen ergibt sich so der proportionale Zusammenhang

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 30

zwischen dem Druck P und der Dichte ρ Hieraus folgt jedoch dass bei Fluiden mit houmlherer Dichteauch ein houmlherer Druck am Ende unseres Tests festzustellen sein sollte Dies ist wie man anhand vonTabelle 41 und Abbildung 48 erkennen kann bei uns nicht der FallUnser Modell ist also nicht geeignet um das Verhalten verschiedener Stoffe genauer zu untersuchen dahierfuumlr die Anzahl der stoffabhaumlngigen Parameter zu gering ist Wir koumlnnen lediglich Einfluss auf dasFlieszligverhalten nehmen was in unserem Fall auch ausreichend ist

422 Zeitschrittweite

In diesem Abschnitt wollen wir den Einfluss des Parameters ∆t auf unsere Simulation untersuchenDer Parameter ∆t wird im Tracer unseres Loumlsers (vgl Kapitel 31) benoumltigt und ist ein Maszlig fuumlr dieGenauigkeit des Tracers Hier nimmt ∆t Einfluss darauf wie weit wir in der Zeit zuruumlckgreifen um neueGeschwindigkeiten zu berechnen Das heiszligt um so kleiner wir ∆t waumlhlen um so genauer sollte unsereLoumlsung berechnet werden Dies wollen wir nun anhand verschiedener Werte untersuchenDazu betrachten wir zuerst unsere allgemeine Form zur Wahl von ∆t

∆t (h v0 a) =h

v0 middot a(46)

mit h als Schrittweite unseres Gitters a als frei waumlhlbaren Parameter und v0 = 000015 als unseremaximal auftretende Geschwindigkeit Mit dem Parameter a koumlnnen wir nun ∆t beliebig groszlig bezie-hungsweise klein machenAls Ausgangskonfiguration fuumlr diesen Test waumlhlen wir folgende Werte fuumlr die restlichen Parameter

n = 257 h =1

256 ν = 00003 maxiter = 32 (47)

Waumlhrend des Test wird nur a veraumlndert alle anderen Werte bleiben unveraumlndertAls Anfangsbedingung waumlhlen wir den Testfall Hubbel mit einer Druckspitze an den Koordinaten(x0 y0) = (025 025) (vgl Abbildung 45 und Gleichung (44)) Wir betrachten folgende Wahlvon a

a = 1 a = 100 a = 500 a = 1000 a = 2000

∆t 2594033 025940 005188 002594 001297

Tabelle 42 Wertetabelle fuumlr den Parameter ∆t

0 10 20 30 40 50 60 70 80 900

005

01

015

02

025

03

035

Zeitschritt

Dru

ck

a=1a=100a=500a=1000a=2000

Abbildung 49 Druckverlaumlufe am Gitterpunkt (0 0) fuumlr verschiedene Werte von ∆t = 1(nminus1)middotv0middota

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 31

Um die Qualitaumlt unserer Loumlsung zu untersuchen das heiszligt den Einfluss von ∆t auf unsere Simulationwollen wir den Druckverlauf im Mittelpunkt fuumlr verschiedene Werte von a uumlber ein bestimmtes Zeitin-tervall analysieren Wir erhalten die in Abbildung 49 dargestellten DruckverlaumlufeWir koumlnnen deutlich erkennen dass fuumlr kleine Werte von a also groszlige Werte von ∆t kein wellenartigesAusbreiten zu beobachten ist In diesen Faumlllen liegt ein nahezu linearer beziehungsweise ein unglat-ter Druckverlauf vor Dies entspricht nicht der Realitaumlt und ist fuumlr unsere Simulation nicht geeignet Esstellt sich nun die Frage ob unser Modell bei diesen Werten von ∆t stabil ist wie es die Theorie (vglKapitel 24) besagt Hierzu betrachten wir als naumlchstes die Zweinorm des Druckvektors um anhanddieser Werte Aussagen zur Stabilitaumlt unserer Implementierung treffen zu koumlnnen Wir erhalten uumlber einZeitintervall betrachtet folgendes Diagramm

0 50 100 15020

25

30

35

40

45

50

55

60

Zeitschritt

Nor

m

a=1a=100

Abbildung 410 Normwerte des Druckvektors fuumlr verschiedene Werte von ∆t uumlber ein Zeitintervall

Die Normwerte in beiden Testfaumlllen zeigen monoton fallendes Verhalten und scheinen gegen zwei festeWerte zu konvergieren Dies bedeutet dass unser Verfahren zwar ungenau loumlst aber immer noch stabilist Somit bestaumltigt sich in diesem Fall die Theorie die besagt dass unser Verfahren fuumlr alle Werte von∆t stabil istBetrachten wir nun die uumlbrigen Druckverlaumlufe aus Abbildung 49 so koumlnnen wir anhand der ersten Zeit-schritte feststellen dass fuumlr immer kleiner werdende Werte von ∆t ein immer realistisches Verhalten zubeobachten ist Bei a = 500 besitzt die Druckkurve anfaumlnglich noch einen recht kantigen stuumlckweiselinearen Verlauf wohingegen die Kurve von a = 2000 glatt wirkt und einer wellenartigen Ausbreitungsehr nahe kommt

Als Naumlchstes wollen wir untersuchen wie sich die unterschiedlichen Werte von ∆t auf die visuelleDarstellung auswirken und ob wir unsere Uumlberlegungen die wir anhand der Normverlaumlufe getroffen ha-ben untermauern koumlnnen Dazu haben wir zu verschiedenen Zeitpunkten Momentaufnahmen gemachtund wollen diese nun naumlher untersuchen Unsere Druckverlaumlufe in Abbildung 49 zeigen dass wir beiunterschiedlicher Wahl von ∆t auch unterschiedliche Werte fuumlr den maximalen beziehungsweise mini-malen Wert der Druumlcke erhalten Daher passen wir die Farbwahl in unserer Simulation fuumlr jeden Testfalleinzeln an um eine moumlglichst genaue visuelle Darstellung zu erzielen Dies erklaumlrt die verschiedene Faumlr-bung zwischen den Testfaumlllen Wir erhalten so die folgenden Aufnahmen

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 32

(a) Initiale Druckverteilung (b) Nach 30 Zeitschritten

Abbildung 411 Druckverteilungen fuumlr a = 1

Wir koumlnnen in Abbildung 411 fuumlr a = 1 deutlich erkennen dass sich nach wenigen Schritte eine sehrunrealistische nicht mehr kreisfoumlrmige Ausbreitung ergibt Dies spiegelt also Erwartung nach der Ana-lyse der Druckverlaumlufe aus Abbildung 49 wider

(a) Initiale Druckverteilung (b) Nach 9 Zeitschritten

Abbildung 412 Druckverteilungen fuumlr a = 100

Auch im Testfall aus Abbildung 412 erhalten wir das zu erwartende Ergebniss nach der Analyse desDruckes (vgl Abbildung 49) Die Ausbreitung erfolgt nicht kreisfoumlrmig und auch die entstehenden Ver-wirbelungen entsprechen nicht der Realitaumlt jedoch dem Druckverlauf aus Abbildung 49

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 33

(a) Initiale Druckverteilung (b) Nach 8 Zeitschritten

Abbildung 413 Druckverteilungen fuumlr a = 500

In Abbildung 413 erkennen wir erstmals eine realische Simulation unserer Stroumlmung Es entstehen kreis-foumlrmige Wellen um die Druckspitze und dies bestaumltigt erneut unsere anfaumlnglichen Resultate der Analyseder Druckverlaumlufe aus Abbildung 49 Ein aumlhnliches Verhalten zeigt sich bei den zwei verbleibendenTestfaumlllen fuumlr a = 1000 und a = 2000 wir verzichten hier auf die Abbildungen

Wir koumlnnen nun festhalten dass durch Veraumlndern des Parameters ∆t groszliger Einfluss auf die Genauigkeitunserer Simulation genommen werden kann So erhalten wir fuumlr groszlige Werte von ∆t ein sehr ungenauesund unrealistisches Simulationsmodell wohingegen sich bei kleiner werdenden Werten eine realistischeSimulationsumgebung ergibt Als gute Wahl empfiehlt sich ∆t le h

v0middot500 je nachdem welche Genauigkeiterwuumlnscht ist

423 Symmetrietest

In den bisherigen Parametertests in Kapitel 421 fuumlr die kinematische Viskositaumlt ν und Kapitel 422fuumlr den Zeitschritt ∆t haben wir Parameter untersucht welche lediglich Einfluss auf unsere visuelleDarstellung nehmen beziehungsweise auf die Genauigkeit unserer Druck- und Geschwindigkeitsfel-der Wir wollen nun den Einfluss des Parameters maxiter welcher die Anzahl der Jacobi-Schrittezum Loumlsen unserer Gleichungssysteme angibt auf unsere Visualisierung analysieren Der wie in Ka-pitel 44 untersucht und anders als ν und ∆t groszligen Einfluss auf die Laufzeit unseres Loumlsers nimmt unddaher fuumlr unser Ziel einer bdquoEchtzeit-Stroumlmungssimulationldquo von groszliger Bedeutung ist Da unser Loumlserausschlieszliglich aus symmetrischen Operatoren wie Divergenz Gradient und Tracer besteht bildet dasLoumlsen der Gleichungssysteme mit dem Jacobi-Verfahren die einzige Moumlglichkeit Unsymmetrien durchungenaues Loumlsen zu erreichen Wir wollen somit einen Wert fuumlr den Parameter maxiter finden deruns Symmetrie verspricht und moumlglichst klein ist um die Laufzeit unseres Loumlsers so gering wie moumlglichzu haltenDazu betrachten wir erneut unseren Testfall Hubbel (vgl Abbildung 45 und Gleichung (44)) die-ses Mal jedoch mit vier Druckspitzen welche wir symmetrisch in unserem Rechengebiet (vgl Ab-bildung 32(b)) anordnen Wir waumlhlen hierzu a = minus100 b = 1 sowie x1

0 = minus05 y10 = 05 x2

0 = 05y2

0 = minus05 x30 = minus05 y3

0 = minus05 und x40 = 05 y2

0 = 05 fuumlr unsere Druckspitzenmittelpunkte Es

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 34

stellt sich nachfolgende initiale Druckverteilung ein (vgl Abbildung 414)

minus1minus05

005

1

minus1

minus05

0

05

10

05

1

15

2

25

3

Abbildung 414 Initiale symmetrische Druckverteilung fuumlr den Symmetrietestfall mit vier Druckspitzen

Wir erhalten eine Druckverteilung die nicht nur symmetrisch zur x- und y-Achse ist sondern auchsymmetrisch zur positiven wie negativen Winkelhalbierenden ist Ausgehend von verschiedenen Wertenfuumlr maxiter werden wir nun unsere visuelle Darstellung auf symmetrisches Verhalten untersuchen undunsymmetrisches Verhalten durch Kreise markieren Die an den Kreisen angebrachten Ziffern sollenverdeutlichen dass nur Kreise gleicher Nummer miteinander verglichen werden

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 415 Druckverteilungen fuumlr maxiter = 32

Betrachten wir zuerst unsere Simulation mit maxiter = 32 in Abbildung 415 so ergeben sich die dar-gestellten Druckverteilungen nach einigen Zeitschritten Der Abbildung 415(a) ist zu entnehmen dassschon sehr fruumlh die Achsensymmetrie verloren geht gekennzeichnet durch die roten Kreise um die Un-symmetrien Jedoch verhaumllt es sich anders bei der Symmetrie der positiven Winkelhalbierenden da diesenoch bleibt erhalten Auch nach 28 Zeitschritten siehe Abbildung 415(b) in der die Achsensymmetrie

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 35

nahzu vollstaumlndig verschwunden ist bleibt die Symmetrie zur Winkelhalbierenden erkennbar gekenn-zeichnet durch die schwarzen KreiseWir wollen uumlberpruumlfen ob sich dieses Verhalten auch in den anderen Testfaumlllen wiederfindet Betrachtenwir dazu Abbildungen 416(a) und 416(b) welche verschiedene Druckverteilungen fuumlr maxiter = 48darstellen

(a) Druckverteilung nach 14 Zeitschritten (b) Druckverteilung nach 28 Zeitschritten

Abbildung 416 Druckverteilungen fuumlr maxiter = 48

Auch hier ist nach wenigen Zeitschritten die Achsensymmetrie verloren wie in Abbildung 416(a) durchdie roten Kreise markiert und wie schon in Testfall in Abbildung 415 bleibt die Symmetrie zur Diagona-len welche von (minus1minus1) nach (1 1) verlaumluft auch nach 28 Zeitschritten erhalten Somit bestaumltigt sichhier ebenfalls das anfaumlnglich beobachtete Verhalten Es stellt sich nun die Frage ab welcher Anzahl derJacobi-Schritte wir auch Achsensymmetrie erzielen Um diese Frage zu klaumlren wollen wir nun weitereWerte von maxiter untersuchen

(a) Druckverteilung nach 16 Zeitschritten (b) Druckverteilung nach 42 Zeitschritten

Abbildung 417 Druckverteilungen fuumlr maxiter = 52

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 36

Sei im folgenden Testfall maxiter = 52 Es ergeben sich die in Abbildung 417 dargestellten Druckver-teilungen Wir koumlnnen deutlich erkennen dass der gleiche Fall auftritt wie in den bereits beschriebenenTestfaumlllen in Abbildungen 415 und 416 Selbst nach vielen Zeitschritten koumlnnen wir die Symmetrie zurDiagonalen noch erkennen wohingegen die Achsensymmetrie nur noch in Ansaumltzen zu erkennen ist So-mit sind wir gezwungen den Parameter maxiter noch groumlszliger zu waumlhlen um auch Achsensymmetriezu erreichen falls dies uumlberhaupt moumlglich istBetrachten wir dazu die Druckverteilungen fuumlr maxiter = 56 nach 38 Zeitschritten

Abbildung 418 Druckverteilung nach 38 Zeitschritten bei 56 Jacobi-Schritten

Wir haben mit maxiter = 56 nun eine Anzahl an Jacobi-Schritten gefunden mit welcher wir selbstnach vielen Zeitschritten wie in Abbildung 418 dargestellt nicht nur Symmetrie zur Diagonalen errei-chen sondern auch AchsensymmetrieDie Frage ist nun jedoch ob die Diagonalsymmetrie uumlberhaupt durch den Parameter maxiter beein-flusst wird da wir bei bereits 32 Jacobi-Schritten diese erreicht hatten Um diese Frage zu klaumlren wer-den wir die Druckverteilung fuumlr einen kleinen Wert von maxiter analysieren Es ergibt sich folgendeDruckverteilung

(a) Initial (b) Nach 28 Zeitschritten

Abbildung 419 Druckverteilungen fuumlr maxiter = 16

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 37

Wir koumlnnen sehr gut erkennen dass obwohl jegliche realistische Simulation verloren ist erkennbar durchkein wellenartiges Ausbreiten die Diagonalsymmetrie erhalten geblieben ist Dies bedeutet dass unserParameter maxiter lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie hierunbeeinflusst bleibt Diese Erkenntnis ist sehr uumlberraschend und zeigt uns dass unsere Implementierungeine sehr gute physikalisch richtige Simulation liefert da auch in der Realitaumlt in diesem Testfall dieDiagonalsymmetrie vorhanden waumlre

Wir koumlnnen also festhalten dass wir ab einem maxiter Wert von 56 Achsensymmetrie erreichen unddie Diagonalsymmetrie durch anderen Faktoren in unserer Implementierung verursacht wird Es liegtnahe dass hier der Grund darin liegt dass die uumlbrigen Funktionen in unserer Software symmetrischaufgebaut sind Zum Beispiel das Berechnen der Divergenz des Gradienten oder die Nutzung des Tracers(vgl Kapitel 31)

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 38

43 Validierung der Interaktions-Komponente

In diesem Kapitel wollen wir die Anwender-Interaktion im Hinblick auf ihre physikalische Korrektheitanhand der beiden Testfaumllle Steady und Hubbel pruumlfen Um dies zu beurteilen stuumltzen wir uns nicht nurauf visuelle Kriterien sondern auch auf numerische insbesondere die Normen des Geschwindigkeits-und Druckfeldes

431 Physikalisch korrekte Umsetzung

Zunaumlchst betrachten wir den Testfall Steady bei dem wir das Fluid nur durch Interagieren anregenkoumlnnen wie wir es in Kapitel 33 beschreiben Fuumlr diesen speziellen Testfall gilt dass das Fluid oh-ne Anwender-Interaktion ruht Wir waumlhlen Dirichlet-Nullrandbedingungen fuumlr die Geschwindigkeit undsetzen sowohl das Geschwindigkeits- als auch das Druckfeld initial zu Null In der Testkonfigurationverwenden wir die folgenden Parameter die Gitterschrittweite h = 1

128 die Viskositaumlt ν = 00003 diedurchzufuumlhrenden Iterationen im Jacobi-Loumlser maxiter = 32 und die Zeitschrittweite ∆t = h

200v0

wobei wir v0 = 000015 waumlhlen Bei der Groumlszlige v0 handelt es sich um den Wert der im Testfall DrivenCavity die Geschwindigkeit an der oberen Gebietskante angibt (vgl Abschnitt 412) den wir in allenTestfaumlllen zur Bestimmung des Zeitschritts nutzen

(a) langsame Interaktion (b) schnelle Interaktion

(c) abklingendes Geschwindigkeitsfeld (d) sehr schnelle diagonale Interaktion

Abbildung 420 Darstellung des Betrags des Geschwindigkeitsfeldes fuumlr verschiedene Interaktionen

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 39

Im Gegensatz zu den vorherigen Tests stellen wir hier den Betrag des Geschwindigkeitsfeldes in jedemGitterpunkt dar Die Resultate einiger Interaktionen finden sich in Abbildung 420 Wir weichen von derVisualisierung in Kapitel 412 und Abschnitt 42 ab da wir so verwirrende Faumlrbungen des Gitters ver-meiden Diese koumlnnten auftreten da blaue Faumlrbungen nicht betragsmaumlszligig kleine sondern absolut kleineGeschwindigkeiten darstellen und wir somit die natuumlrliche Wahrnehmung der Stroumlmungsentwicklungnicht wiedergeben wuumlrdenWir koumlnnen feststellen dass eine Anwender-Interaktion die visuell korrekten Resultate liefert Die Ge-schwindigkeit aumlndert sich wenn wir unseren Finger uumlber den Bildschirm bewegen (420(a)) und sie wirdgroumlszliger je schneller wir diese Bewegung ausfuumlhren was wir an der Faumlrbung der Gitterpunkte in Abbil-dung 420(b) erkennen koumlnnen Auszligerdem klingt die Geschwindigkeit ab sobald wir mit der Interaktionaussetzen was wir in Abbildung 420(c) sehen koumlnnen An diesem Verhalten koumlnnen wir erkennen dassdie Interaktion die vom Nutzer ausgefuumlhrt wird visuell physikalisch korrekt von der Simulation verar-beitet wird da wir ein solches Verhalten auch von bdquorealenldquo Fluiden erwartenDiese Beobachtungen wollen wir nun anhand der Normen des Geschwindigkeits- beziehungsweise Druck-feldes deren Verlaumlufe in Abbildung 421 dargestellt sind verifizieren

0 50 100 150 200 250 300 350 400 450 500 5500

005

01

015

02

025

Zeitschritt

No

rm

(a) Geschwindigkeitsverlauf

0 50 100 150 200 250 300 350 400 450 500 5500

02

04

06

08

1

12

14

16

18

2x 10

minus3

Zeitschritt

No

rm

(b) Druckverlauf

Abbildung 421 Verlaumlufe des Geschwindigkeits- und Druckfeldes bei der oben beschriebenen Interaktion

Zur Erstellung der Diagramme in Abbildung 421 fuumlhren wir zuerst mehrere langsame Bewegungen ausdie wir anschlieszligend wieder abklingen lassen Zuletzt fuumlhren wir schnelle Bewegungen wie sie sich in

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 40

Abbildung 420(b) wiederfinden aus und beenden das Programm wenn das Rechengebiet wieder eineeinheitliche Farbe angenommen hat Aus dieser Vorgehensweise erklaumlren sich die kleinen Ausschlaumlgeinnerhalb der ersten 300 Zeitschritte in Abbildung 421Eine erste Beobachtung ist dass die beiden Graphen in Abbildung 421 das Verhalten aufweisen wel-ches wir aufgrund der Abbildungen 420(a) 420(b) und 420(c) erwarten Die Geschwindigkeit und derDruck des Fluids steigen mit zunehmender Geschwindigkeit der Interaktion an und klingen ab sobaldwir keine Kraft mehr aufpraumlgenDie beiden Kurven in Abbildung 421 verlaufen aumlhnlich unterscheiden sich aber in zwei wesentlichenAspekten auf der einen Seite durch die Groumlszlige der angenommenen Werte und auf der anderen Seitedurch ihr Abklingverhalten nach dem Hochpunkt in Zeitschritt 340 Bei der Geschwindigkeit (vgl Ab-bildung 421(a)) stellt sich ein gleichmaumlszligiges Abklingverhalten ein wobei der Druck wie wir in Abbil-dung 421(b) sehen koumlnnen ein sehr unregelmaumlszligiges Verhalten aufweist Dies laumlsst sich dadurch erklauml-ren dass sich der Druck aus der Houmlhe des Fluids ergibt Wenn wir uns vorstellen dass sich das Fluidin einem wuumlrfelfoumlrmigen Becken befindet so koumlnnen wir der Wasseroberflaumlche eine gewisse Houmlhe zu-ordnen Daraus resultiert der Druck der in jedem Punkt der Oberflaumlche herrscht da unterschiedlicheHoumlhen einen unterschiedlichen Druck aufweisen Dies folgt aus der Formel fuumlr den statischen DruckEs gilt p = ρgh wobei p den Druck des Fluids ρ dessen Dichte g die Erdbeschleunigung und h dieHoumlhe des Fluids bezeichnet Wenn wir eine externe Kraft auf die Oberflaumlche des Fluids aufpraumlgen dieunserem Rechengebiet entspricht so entstehen Wellen die den vorherrschenden Druck beeinflussen dasie lokal die Houmlhe des Fluids aumlndern Deshalb ergibt sich bei gleichmaumlszligig abklingender Geschwindigkeitein wellenartig abklingender Druck Die Geschwindigkeit verhaumllt sich nicht wellenartig da wir sie amRand zu Null setzen und somit Reflexionen unterdruumlcken Diese koumlnnten ein aumlhnliches Verhalten wie beider Druckkurve hervorrufen Der Verlauf der Normen nach den kleinen Ausschlaumlgen verhaumllt sich dabeiaumlhnlich wie der nach dem groszligen Ausschlag welchen wir durch schnelle Interaktion hervorrufenInsgesamt koumlnnen wir festhalten dass unsere App auch bei Interaktion ein physikalisch korrektes Ver-halten des Fluids simuliert Das Fluid ist ohne das Aufpraumlgen einer Kraft durch Interaktion statisch weistjedoch waumlhrend beziehungsweise nach der Interaktion ein zu erwartendes Verhalten auf

432 Uumlberlagerung einer vorgegebenen Kraft mit einem TouchEvent

Nachdem wir in Abschnitt 431 die Anwender-Interaktion anhand des denkbar einfachsten Testfallsuntersucht haben wollen wir sie nun anhand eines etwas komplizierteren untersuchen

minus1minus08

minus06minus04

minus020

0204

0608

1

minus1

minus05

0

05

1

0

05

1

15

2

x 10minus3

xminusAchse

yminusAchse

Dru

ck

Abbildung 422 Druckspitze uumlber dem Rechengebiet

Dazu betrachten wir den Testfall aus Kapitel 42 mit der Konfiguration der Parameter die wir in Ab-

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 41

schnitt 431 verwendet haben Zusaumltzlich geben wir eine Druckspitze in der unteren linken Ecke desRechengebiets vor wie es in Abbildung 422 dargestellt ist Wir wollen im Folgenden untersuchen obund wie wir die Stroumlmung welche von der Druckspitze hervorgerufen wird durch Interaktion stoumlrenkoumlnnen Dazu betrachten wir die Interaktionen die wir in Abbildung 423 sehen Wir weisen darauf hindass wir erneut die Absolutgeschwindigkeiten auf dem Bildschirm anzeigen lassen und nicht den Druckwie wir es bei der Untersuchung eines aumlhnlichen Testfalls in Kapitel 42 durchfuumlhren

(a) initiale Geschwindigkeitsverteilung (b) Stoumlrung von oben rechts

(c) Stoumlrung von unten rechts

Abbildung 423 Geschwindigkeitsverteilung fuumlr verschiedene Interaktionen

Neben der initialen Geschwindigkeitsverteilung in Abbildung 423(a) koumlnnen wir in den Ab-bildungen 423(b) und 423(c) eine Stoumlrung der Stroumlmung duch Anwender-Interaktion ausmachen Wirbeobachten dass die Geschwindigkeit an den Stellen an der wir die kreisfoumlrmige Ausbreitung der Druck-spitze durch das Aufpraumlgen einer externen Kraft stoumlren sehr klein ist Dies ist physikalisch korrekt dawir von auszligen in den Kreis eindringen und somit der Stroumlmung entgegenwirken Die Stroumlmungen inder Eintrittsstelle heben sich nahezu auf und es liegt eine sehr geringe Geschwindigkeit vor In Ab-bildung 423(c) koumlnnen wir ein Ausbeulen des Stroumlmungskreises erkennen die dadurch entsteht dasswir eine Bewegung durch den Kreis von unten rechts nach oben links durchfuumlhren Am oberen linkenRand des Stroumlmungskreises wird die Geschwindigkeit des Fluids durch das Aufpraumlgen der Kraft erhoumlhtAuch dies entspricht einem physikalisch korrekten VerhaltenZuletzt wollen wir noch den Einfluss der Interaktion auf das Druckfeld untersuchen Dazu betrach-ten wir Abbildung 424 in der wir den Druckverlauf im mittleren Gitterpunkt einmal mit und ein-

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 42

mal ohne Interaktion darstellen Im Gegensatz zu den Ausfuumlhrungen in Abschnitt 431 stellen wir inAbbildung 424 nicht die Norm des Druckfeldes also den Druck in allen Gitterpunkten sondern dentatsaumlchlichen Wert in einem Gitterpunkt dar

0 5 10 15 20 25 30 35 40 45 50minus1

minus08

minus06

minus04

minus02

0

02

04

06

08

1x 10

minus5

Zeitschritt

Dru

ck

mit Interaktion

ohne Interaktion

Abbildung 424 Druckverlauf im mittleren Gitterpunkt

Wir beobachten fuumlr den Druck ohne Interaktion einen Verlauf den wir nach den Untersuchungen in Ka-pitel 42 erwarten Fuumlr den anderen Druckverlauf registrieren wir einen Druckabfall waumlhrend wir dieInteraktion ausfuumlhren die wir in Abbildung 423(b) sehen Durch das Aufpraumlgen der Kraft reduzierenwir den Druck in dem Punkt an dem die Kraft angreift Dies ist ein Verhalten welches unsere Erwar-tungen die wir anhand der Ausfuumlhrungen in Abschnitt 431 getroffen haben bestaumltigt da sich durchdas Kraftaufpraumlgen die Houmlhe der Fluidoberflaumlche aumlndert Ab dem 15 Zeitschritt weisen beide Kurvenin Abbildung 424 ein aumlhnliches Verhalten auf was darauf hindeutet dass die Stoumlrung der Stroumlmungmit der Zeit wieder ausgeglichen wird Dieses Phaumlnomen laumlsst sich auch bei realen Fluiden vermutenda die Druckspitze zum Zeitpunkt der Stoumlrung der Stroumlmung durch Interaktion noch nicht vollstaumlndigzusammengefallen ist und sich somit das ungestoumlrte Verhalten wieder einstellen kann Wir meinen hierdass ein Teil der Druckspitze immer noch vorhanden ist und die Stroumlmung des Fluids beeinflusst Diesgeschieht nicht in dem Maszlige wie zu Beginn des Testfalls aber die Wirkung bleibt dennoch die gleicheAnhand dieses Testfalls koumlnnen wir festhalten dass die Interaktion eines Anwenders physikalisch korrektin die Simulation einbezogen wird Hierbei haben wir eine externe vom Anwender aufgepraumlgte Kraftmit einer vorgegebenen uumlberlagert was in Abschnitt 431 nicht der Fall ist und trotzdem vergleichba-re Erkenntnisse liefert Wir koumlnnen somit davon ausgehen dass die Simulation physikalisch korrekteErgebnisse bezuumlglich einer Anwender-Interaktion erzielt

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 43

44 Zeitmessungen und Tuning

In diesem Abschnitt wollen wir uns mit den genauen Laufzeiten unserer Simulationsumgebung ausein-andersetzen um darauf aufbauend Verbesserungsmoumlglichkeiten im Hinblick auf eine Beurteilung be-zuumlglich des Erreichens von bdquoEchtzeit-Simulationldquo herauszuarbeiten Die Zeitmessungen fuumlhren wir aufeinem Tablet-Computer aus der uumlber ein TegraTM-2 bdquoSystem-on-a-Chipldquo mit einer ARM Cortex-A9-CPU wobei es sich um einen 10GHz Dual-Core-Prozessor handelt und eine speziell fuumlr minimalenEnergieverbrauch angepasste NVIDIA Rcopy GeForce GPU verfuumlgt Auszligerdem ist der Tablet-Computer miteinem Hauptspeicher von 1GB und einem Datenspeicher von 16GB ausgestattet (vgl [Asus]) Die inder Praxis erreichbare Rechenleistung betraumlgt 081 GFlops und die Speicherbandbreite 10396 GBs ge-messen mit [RGBenchMM] fuumlr die beiden Standardbenchmarks Multiplikation zweier dicht besetzterMatrizen und STREAM (Updates groszliger Vektoren wie zum Beispiel das Kopieren eines Vektors oderkomponentenweise Addition zweier Vektoren) Der L1-Cache ist je 32kB bezuumlglich Instruktionen bezie-hungsweise Daten pro Kern und der L2-Cache der zwischen den beiden Kernen geteilt ist 1MB groszlig(vgl [NVIDIA])Zur Analyse der Laufzeiten betrachten wir in diesem Unterkapitel den schon oben angefuumlhrten TestfallDriven Cavity welchen wir auch in Abschnitt 412 verwenden Wir variieren dabei die Schrittweitedes Gitters indem wir h isin 1

64 1

128 1

256 waumlhlen und untersuchen den Einfluss der unterschiedlichenKomponenten auf die Gesamtlaufzeit Weiterhin betrachten wir fuumlr die feste Schrittweite h = 1

128 dieLaufzeitaumlnderungen unterschiedlicher Anzahlen von Iterationen im Jacobi-Loumlser (vgl Erlaumluterungen inAbschnitt 31) Dazu waumlhlen wir die verschiedenen Werte von maxiter isin 16 32 64 128 Die an-deren in unserer Software variablen Groumlszligen also die Viskositaumlt ν die Zeitschrittweite ∆t und die Ge-schwindigkeit v0 die an der oberen Kante in positive x-Richtung permanent angesetzt wird lassen wirunveraumlndert Tests zur Wahl dieser Parameter mit Ausnahme der Geschwindigkeit v0 finden sich in Ab-schnitt 42Wir untersuchen also die Laufzeiten des kompletten Loumlsers seiner Bestandteile die im Wesentlichenden in Algorithmus 241 aufgefuumlhrten Schritten entsprechen sowie die zur Visualisierung zaumlhlendenFunktionen die wir sowohl als Ganzes als auch in kleinschrittiger Gliederung betrachten Zusaumltzlich be-urteilen wir noch den Einfluss der Interaktivitaumlt die einen sehr wichtigen Teil unserer Software darstelltWir weisen darauf hin dass wir in der Regel gerundete Durchschnittszeiten angeben die sich aus den ers-ten 50 Zeitschritten ergeben Auszligerdem muumlssen wir zur Einordnung der Zeiten beruumlcksichtigen dass wirdie Berechnungen mit doppelter Genauigkeit durchfuumlhren Funktionen die nur einmal pro Programm-aufruf ausgefuumlhrt werden wie zum Beispiel der Konstruktor der Render-Klasse beruumlcksichtigen wirin den Zeitmessungen nicht da sie keinen dauerhaften Einfluss auf die Laufzeit der Software haben

441 Analyse des Loumlsers

Zunaumlchst wollen wir uns mit der Analyse des Loumlsers beschaumlftigen Dieser besteht insgesamt aus sechsVektorupdates drei Anwendungen des Jacobi-Loumlsers sowie je einer Anwendung des Tracers der Diver-genz und des Gradienten was sich wie folgt in unserem Loumlser wiederfindet Das Aufpraumlgen der Krafterfolgt lediglich durch ein Vektorupdate die Laufzeit im Advektionsschritt wird durch das Ausfuumlhren desbdquoTracersldquo dominiert und im Prozess der Diffusion konzentrieren wir uns auf die Laufzeit einer Anwen-dung des Jacobi-Loumlsers obwohl wir diesen zwar im Diffusionsschritt wie in Kapitel 31 beschriebenzweimal und bei der Projektion erneut verwenden Dabei handelt es sich allerdings um die selbe Imple-mentierung nur mit anderen Zahlenwerten Im Projektionsschritt beschraumlnken wir uns auf das Messender Laufzeit zur Bestimmung des Druckgradienten und der Divergenz des Geschwindigkeitsfeldes (vglAbschnitt 2) Vektorupdates die zusaumltzlich auftreten wie zum Beispiel im Diffusionsschritt sind fuumlrunsere Betrachtung nicht weiter relevant da sie bezuumlglich ihrer Laufzeit durch das Kraftaufpraumlgen reprauml-sentiert werdenDie Tabelle 43 gibt die Laufzeit der gesamten Berechnung sowie die ihrer einzelnen Bestandteile fuumlr

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 44

unterschiedliche Schrittweiten h in jedem Zeitschritt an

h Gesamt Vektorupdate Tracer Jacobi Gradient und Divergenz164 0118 0001 0014 0034 00021

128 0474 0004 0056 0137 00081

256 1922 0013 0213 0565 0026

Tabelle 43 Laufzeiten der einzelnen Loumlser-Komponenten in Sekunden fuumlr unterschiedliche Schrittwei-ten

Alle Angaben gelten dabei fuumlr eine feste Anzahl von maxiter = 32 Iterationen im Jacobi-Loumlser ImGegensatz zu den in Abbildung 425 angebenen Anteilen handelt es sich bei den Werten in Tabelle 43nicht um gewichtete Werte Wir koumlnnen direkt festhalten dass wir in diesem Status der Implementie-rung fuumlr kein h bei 25 fps (Frames per Second) Echtzeit-Simulation erreichen Der ersten Spalte von Ta-belle 43 koumlnnen wir entnehmen dass bei einer Halbierung der Schrittweite die Laufzeit des Loumlsers umeinen Faktor vier zunimmt Eine Erklaumlrung dafuumlr ist dass die meisten der im Quellcode verwendetenArrays die Groumlszlige 2N = 2

(1h + 1

)2 haben also N sim 1h2

fuumlr kleine Schrittweiten h gilt Das heiszligtdass bei Halbierung der Schrittweite die zu berechnenden Vektoren um einen Faktor vier groumlszliger werdenNatuumlrlich sind dann entsprechend mehr Rechnungen im Loumlser durchzufuumlhren Wie wir aus den uumlbrigenSpalten erkennen koumlnnen schlaumlgt sich dieser Faktor auf jede einzelne Komponente des Loumlsers niederwas bedeutet dass jeder Teil auch gleichmaumlszligig von einer Schrittweitenhalbierung betroffen istNun wollen wir uns den einzelnen Bestandteilen des Loumlsers widmen und dazu die in Tabelle 43 an-gefuumlhrten Laufzeiten genauer analysieren Um die Anteile der einzelnen Komponenten bezuumlglich derGesamtlaufzeit besser einschaumltzen zu koumlnnen stellen wir die Laufzeiten zusaumltzlich in einem Kreisdia-gramm (vgl Abbildung 425) dar Dabei ist zu beachten dass fuumlr alle Schrittweiten die Anteile derLaufzeiten der einzelnen Komponenten unveraumlndert bleiben was die obige These der gleichmaumlszligigenAuswirkung der Schrittweite auf alle Komponenten des Loumlsers untermauert Auszligerdem haben wir dieZeiten von Operationen die mehr als einmal verwendet werden entsprechend gewichtet also die Zeitenfuumlr Vektorupdates mit den Faktor sechs die fuumlr den Jacobi-Loumlser mit dem Faktor drei und alle anderenZeiten einfach

25

11

82

GradDivVektorupdatesTracerJacobi

Abbildung 425 Laufzeitenanteile fuumlr beliebige Schrittweiten h isin 164

1128

1256 fuumlr maxiter= 32

Iterationen im Jacobi-Loumlser

Es wird deutlich dass der Jacobi-Loumlser mit Abstand den groumlszligten Anteil der Gesamtlaufzeit der Berech-nungen in Anspruch nimmt Wie in Kapitel 31 bereits beschrieben verwenden wir eine Stencil-Methode

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 45

um den Jacobi-Loumlser zu realisieren Diese ist offensichtlich schon sehr effizient da wir bereits das Auf-stellen eines kompletten Gleichungssystems sparen und bdquonurldquo jeden inneren Gitterpunkt durch eine rela-tiv simple Berechnungsvorschrift aktualisieren Wie wir uns anhand des zur Diskretisierung verwendetenbdquoFuumlnf-Punkte-Sternsldquo leicht uumlberlegen koumlnnen kommt es dabei zu Speicherzugriffen auf nicht kontinu-ierlich abgelegte Daten was einen langsameren Zugriff und damit eine Verzoumlgerung der Berechnung zurFolge hat Das Umgehen dieses Phaumlnomens ist nicht trivial eine Moumlglichkeit dazu findet sich jedoch un-ter anderem bei [Strzodka] Dort wird ein Verfahren vorgestellt das das Anwenden der Stencil-Methodeim Jacobi-Loumlser bezuumlglich der Laufzeit verbessert Dies geschieht dadurch dass temporaumlre Datenlokali-taumlt uumlber mehrere Iterationen erhoumlht wird Dazu werden die Arrays der verwendeten Daten bdquogekacheltldquoum die Berechnung des Stencils auf diesen Kacheln im Cache durchfuumlhren zu koumlnnen Dieses Vorgehenist sehr effizient da weniger Zugriffe auf den Datenspeicher erfolgen und der verhaumlltnismaumlszligig kleineCache im Prozessor besser ausgenutzt wird als bei der von uns verwendeten bdquonaivenldquo ImplementierungEine zusaumltzliche Verbesserung der Laufzeit koumlnnen wir erzielen wenn wir die Kachelung der Datenar-rays auf die zur Verfuumlgung stehende Cachegroumlszlige anpassenDie Aktualisierung der Gitterpunkte erfolgt in beiden Faumlllen uumlber mehrere for-Schleifen was die Ideenahelegt diesen Vorgang zu parallelisieren Auf dem von uns verwendetem Geraumlt stehen zwei Kernezur Verfuumlgung wobei das Betriebssystem bereits einen fuumlr die Visualisierung und den anderen fuumlr Be-rechnungen und Aumlhnliches verwendet Somit koumlnnen wir wenn uumlberhaupt nur eine Verbesserung derLaufzeiten um einen Faktor zwei erreichen Da wir auch in allen anderen Loumlser-Komponenten solchefor-Schleifen verwenden wird der Effekt der Reduktion der Laufzeit durch Parallelisierung verstaumlrktdie Dominanz des Jacobi-Loumlsers jedoch nicht beeinflusst Insgesamt laumlsst sich also als Konzept zur Lauf-zeitverbesserung konkret fuumlr den Jacobi-Loumlser und auch im Allgemeinen das Parallelisieren der for-Schleifen anfuumlhrenDie Vektorupdates und die Berechnung von Gradient und Divergenz im Diffusionsschritt welche wirim Wesentlichen auch als Vektorupdate auffassen koumlnnen bestehen ebenfalls hauptsaumlchlich aus for-Schleifen was daher erneut eine Parallelisierung nahelegt Desweiteren haben wir die Moumlglichkeit dieSchleifen auszurollen was zu wesentlich mehr Quellcode fuumlhrt Wie sehr sich dieses Vorgehen etwa imHinblick auf die Laufzeit auszahlen wuumlrde bleibt zu untersuchen jedoch ist davon auszugehen dass esgegenuumlber der Parallelisierung den geringeren Effekt hatBeim Aufpraumlgen der Kraft veraumlndern wir wie in Abschnitt 33 beschrieben nur die Komponente desKraftvektors die zu dem Knotenpunkt gehoumlrt den der Anwender auf dem Bildschirm beruumlhrt Am Endedes Loumlsers fuumlllen wir dennoch den kompletten Kraftvektor mit Nullen Diese Aktualisierung laumlsst sichin der Form reduzieren als dass wir nur den zuvor veraumlnderten Eintrag auf Null setzen Wenn wir unsjedoch die Zeiten in Tabelle 43 anschauen so stellen wir fest dass der hier durch erzielte Gewinn anLaufzeit eher unbedeutsam istAbschlieszligend wollen wir uns mit der Laufzeit des Tracers beschaumlftigen die immerhin den zweitgroumlszligtenwenn auch den im Vergleich zum Jacobi-Loumlser deutlich kleineren Teil der Gesamtdauer des Loumlsers aus-macht Hier treten neben for-Schleifen vor allem if-Abfragen auf welche jeweils zwei Bedingungenuumlberpruumlfen Diese Abfragen sind verhaumlltnismaumlszligig teuer und beanspruchen deshalb einen relativ groszligenTeil der Laufzeit des Tracers Hier gewaumlhrleisten wir dass wir ein Fluidpartikel wie in Abschnitt 24 be-ziehungsweise 31 beschrieben nicht so lange zuruumlckverfolgen bis es an einem Punkt auszligerhalb des Re-chengebiets angekommen ist Falls diese Gefahr besteht so waumlhlen wir den entsprechenden Randpunktals Endpunkt des Pfades durch den der Stromfaden verlaumluft Es ist also klar dass diese if-Abfragen ab-solut noumltig sind und nicht weggelassen werden koumlnnen Eine Verbesserungsmoumlglichkeit bietet wie obendas Parallelisieren der for-Schleifen

Nachdem wir uns zuvor mit der Variation der Schrittweite h beschaumlftigt haben wollen wir nun dierein laufzeitorientierten Auswirkungen von unterschiedlichen Iterationsanzahlen im Jacobi-Loumlser be-trachten Im Folgenden werden wir also die Laufzeiten des Jacobi-Loumlsers fuumlr verschiedene Werte von

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 46

maxiter isin 16 32 64 128 analysieren Wir untersuchen nur die Laufzeit des Jacobi-Loumlsers und ver-nachlaumlssigen die uumlbrigen Komponenten weil diese nicht von maxiter beeinflusst werden koumlnnen unddeshalb keine Laufzeitvariationen festzustellen sindAls feste Schrittweite waumlhlen wir h = 1

128 um die Laufzeitveraumlnderungen unabhaumlngig von der Gitter-weite beurteilen zu koumlnnen In der folgenden Tabelle 44 finden sich die entsprechenden Laufzeiten

maxiter Laufzeit16 006832 013764 0273128 0539

Tabelle 44 Laufzeiten des Jacobi-Loumlsers in Sekunden fuumlr verschiedene Werte von maxiter

Wir koumlnnen feststellen dass das zu erwartende Ergebnis eintritt Bei einer Verdopplung der Anzahldurchzufuumlhrender Iterationen benoumltigt der Jacobi-Loumlser doppelt so viel Zeit wie zuvor Wir muumlssen al-so besonders darauf achten wie wir maxiter waumlhlen da wir dadurch viel Zeit einsparen koumlnnenzumal diese Komponente des Loumlsers wie oben gesehen den mit Abstand groumlszligten Teil der Laufzeit aus-macht (vgl Abbildung 425) Es bietet sich also an die Anzahl der Iterationen im Jacobi-Loumlser problem-abhaumlngig zu waumlhlen um nicht unnoumltig lange Laufzeiten zu erhalten Wir verweisen hier auf Ab-schnitt 423 wo wir eine Untersuchung der visuellen Auswirkungen der Wahl von maxiter durch-fuumlhren Anhand der Ergebnisse welche dort erzielt werden koumlnnen wir die Wahl der maximalen Iterati-onszahl vereinfachen

442 Analyse der Visualisierungs-Komponente

Nachdem wir uns im vorherigen Abschnitt 441 mit den Laufzeiten des Loumlsers und seiner einzelnen Be-standteile beschaumlftigt haben wollen wir eine aumlhnliche Analyse auch fuumlr die Visualisierungs-Komponentedurchfuumlhren Diese werden in der Funktion drawGrid zusammengefasst die im Wesentlichen aus zweiElementen besteht Zunaumlchst weisen wir jedem Knotenpunkt im Gitter eine Farbe zu die den Wert einerbestimmten Groumlszlige in diesem Gitterpunkt repraumlsentiert Bei uns werden je nach Testfall Geschwindig-keiten oder Druumlcke dargestellt Dann lassen wir das Gitter mittels der Funktion drawArrays auf denBildschirm zeichnen wobei die Farbgebung zwischen zwei Gitterpunkten durch lineare Interpolation derjeweiligen Farben erfolgt was von einer Standardfunktion von OpenGL ES 20 unterstuumltzt wird DieGesamtlaufzeit der Visualisierung sowie die Laufzeiten der einzelnen Komponenten fuumlr verschiedeneSchrittweiten h werden in Tabelle 45 zusammengefasst

h Gesamt Farbe setzen drawArrays164 0025 0006 00191

128 0048 0019 00301

256 0163 0074 0091

Tabelle 45 Laufzeiten der einzelnen Visualisierungs-Komponenten in Sekunden fuumlr unterschiedlicheSchrittweiten

Aumlhnlich wie im vorherigen Abschnitt wollen wir analysieren welche Komponente fuumlr verschiedene Git-terweiten wie stark bezuumlglich ihrer Laufzeit beeinflusst wird Um die Entwicklung der Laufzeiten besserbeurteilen zu koumlnnen stellen wir die Anteile der beiden Komponenten erneut in einem Kreisdiagramm(vgl Abbildung 426) dar

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 47

(a) Anteile fuumlr h = 164

(b) Anteile fuumlr h = 1128

45

55

Farbe setzendrawArrays

(c) Anteile fuumlr h = 1256

Abbildung 426 Anteile der Laufzeiten der einzelnen Visualisierungs-Komponenten an der Gesamtlauf-zeit fuumlr unterschiedliche Schrittweiten h

Wir erkennen deutlich dass sich mit kleiner werdender Schrittweite die Anteile der beiden Komponentenannaumlhern Die Zeiten selbst wachsen trotzdem weiter an wie Tabelle 45 zu entnehmen ist Wir koumlnnenalso festhalten dass das Setzen der Farben staumlrker von einer Schrittweitenvariation beeinflusst wird alsdas Zeichnen selbst Der Grund hierfuumlr ist dass das OpenGL ES-Rendern also das Zeichnen einesFrames in den Tegra-Chips die in unserem Geraumlt verwendet werden in der dafuumlr besser geeignetenGPU-Komponente durchgefuumlhrt wird und somit hardwarebeschleunigt im Vergleich zu der allgemeinenBerechnung auf der CPU-Komponente istDie Farben setzen wir mittels for-Schleifen das Zeichnen wird hingegen von einer Standardfunkti-on von OpenGL ES 20 ausgefuumlhrt Wie im Implementierungskapitel 32 beschrieben entsteht unserSimulationsgebiet auf dem Bildschirm durch Zeichnen vieler kleiner Quadrate welche sich wiederumaus zwei Dreiecken ergeben Ein Gitterpunkt wird dabei unter Umstaumlnden bis zu sechsmal gezeichnetobwohl wir ihn zum Aufbau des Gitters nur einmal benoumltigen Dies koumlnnen wir den Nummern an denKnoten in Abbildung 33 entnehmen Statt vorgegebenen N =

(1h + 1

)2= n2 Gitterpunkten lassen wir

effektiv 2(nminus1)(nminus1)3 Gitterpunkte zeichnen da wir fuumlr die Darstellung von n2 Gitterpunkten (nminus1)2

Quadrate benoumltigen Die Groumlszlige h gibt dabei die Schrittweite im Gitter und n die Anzahl der Gitterpunktein einer Zeile beziehungsweise Spalte an Die Zeichenroutine bietet somit ebenfalls Ansatzpunkte umeine Laufzeitverbesserung zu erreichen da wir deutlich mehr Punkte als noumltig zeichnen lassenAumlhnliche Konsequenzen ergeben sich fuumlr den Array in dem wir die Farben der Gitterpunkte zum Zeich-nen speichern Der Farbarray der alle Gitterpunkte beruumlcksichtigt hat die Laumlnge 4(nminus1)(nminus1)6 = 24

h2

da wir fuumlr jeden Gitterpunkt die in Abschnitt 32 genannten vier Werte setzen muumlssen den Rot- Blau-Gruumln- und Transparenzwert Bei einer Halbierung der Gitterschrittweite erhalten wir also einen vier malso groszligen Farbarray Dieser Faktor spiegelt sich jedoch nicht in den Zeiten aus Tabelle 45 wider Dieslaumlsst sich erklaumlren wenn wir uns den Quellcode 32 genauer anschauen In der Funktion colourSettreten sehr viele if-Abfragen auf durch die wir den eingegebenen Wert in eine geeignete Farbskala ein-ordnen Der Faktor um den die verschiedenen Farbarrays bei Halbierung der Gitterschrittweite groumlszliger

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 48

werden muss sich nicht zwangslaumlufig auf die Laufzeit niederschlagen da wir nicht nur einfache for-Schleifen ausfuumlhren sondern auch if-Abfragen die nicht schrittweitenabhaumlngig sind Dadurch geht dieUumlbertragung des Faktors der aus der Schrittweitenhalbierung resultiert auf die Laufzeit verloren Auszliger-dem kann es zu Spruumlngen beim Speicherzugriff kommen wodurch sich kein optimales Cacheverhalteneinstellt Die Laufzeit der Visualisierungs-Komponente wird also bei einer Halbierung der Schrittweitedeutlich houmlher jedoch nicht in dem Maszlige wie man es anhand der zunehmenden Groumlszlige der Vektorenerwarten wuumlrdeStatt die Simulation wie in Kapitel 32 beschrieben uumlber eine Heat Map zu realisieren bei der wir je-dem Gitterpunkt eine Farbe zuordnen koumlnnen wir auch einen alternativen Zugang waumlhlen den wir imFolgenden beschreiben und analysieren wollen Bisher sind wir immer von einem zweidimensionalenRechengebiet ausgegangen das wir auf dem Bildschirm darstellen lassen Natuumlrlich bietet OpenGL ES20 auch die Moumlglichkeit dreidimensionale Objekte darzustellen Genau diese Eigenschaft werden wiruns nun zu Nutze machen Dabei werden die zuvor unerlaumlsslichen Farbarrays irrelevant dafuumlr weisenwir jedoch dem Positionsarray der bisher nur ein einziges Mal im Konstruktor aufgerufen wurde eineentscheidendere Rolle zuWie weiter oben bereits angefuumlhrt benoumltigen wir fuumlr die Ausfuumlhrung der drawArrays-Methode alsEingabe sowohl einen Positionsarray als auch einen Farbarray Letzteren fuumlllen wir im Konstruktor in je-dem Eintrag mit dem gleichen Werten was heiszligt dass wir unser gesamtes Gebiet einheitlich faumlrben DenPositionsarray veraumlndern wir nun in jedem Zeitschritt in der Weise als dass wir in die z-Komponentedie wir bisher immer als Null gesetzt haben einen skalierten Wert des Drucks an dem jeweiligen Git-terpunkt eintragen Dadurch loumlsen wir uns von unserem zweidimensionalen Gebiet und erhalten ein ingewisser Weise gewelltes Gebiet Durch die Skalierung des Drucks koumlnnen wir beeinflussen in welcherGroumlszligenordnung sich die Amplituden der bdquoWellenldquo befinden Die Blickrichtung des Anwenders aumlndernwir dabei nicht wir betrachten das Gebiet also immer noch von oben Die Idee ist es dass wir uns nuneiner Option von OpenGL ES 20 eine Lichtquelle zu simulieren bedienen die wir bisher noch nichtverwendet haben Setzen wir also eine solche Lichtquelle ein so entstehen aufgrund des gewellten Ge-biets Schattierungen welche abhaumlngig von der Houmlhe des jeweiligen Gitterpunktes fuumlr unterschiedlichhelle Faumlrbungen sorgen Zur Veranschaulichung betrachten wir die Umsetzung der oben beschriebenenIdee mittels Paraview1 anhand des in diesem Kapitel verwendeten Testfalls Driven Cavity den wirin Kapitel 412 beschreiben mit Gitterschrittweite h = 1

32 Als Testkonfiguration haben wir auszligerdemv0 = 000015 maxiter= 50 ν = 00003 und ∆t = 1

500(nminus1)v0gewaumlhlt wobei durch die festgelegte

Gitterschrittweite h fuumlr die Anzahl der Knoten pro Zeile beziehungsweise Spalte n = 33 gilt

(a) Ansicht von oben (b) Ansicht von schraumlg oben

Abbildung 427 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach zehn Zeit-

schritten

1Wie am Ende von Abschnitt 442 erwaumlhnt verzichten wir auf eine Implementierung dieses Ansatzes in unserer Softwareund bedienen uns deshalb einer geeigneten Visualisierungsumgebung

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 49

(a) Ansicht von oben nach 30 Zeit-schritten

(b) Ansicht von oben nach 50 Zeit-schritten

Abbildung 428 Druckfeld uumlber dem bdquodreidimensionalenldquo Rechengebiet fuumlr h = 132 nach verschiedenen

Zeitschritten

Die Entwicklung des Fluids uumlber mehrere Zeitschritte sehen wir in Abbildung 427 und 428 wobeiwir den Druck mit dem Faktor 104 skaliert haben um eine ausreichende visuelle Bewertung durchfuumlh-ren zu koumlnnen Anhand der beiden Abbildungen koumlnnen wir feststellen dass wir trotz einheitlicher Faumlr-bung des Rechengebiets das Fluidverhalten beobachten koumlnnen was in den Abbildungen 427(a) 428(a)und 428(b) dargestellt wird In Abbildung 427(b) sehen wir auszligerdem dass es sich tatsaumlchlich um eingewelltes Gebiet handeltNun wollen wir uns uumlberlegen wie wir den zuvor dargestellten Ansatz zur Visualisierung der Ergeb-nisse des Loumlsers umsetzen Fuumlr Details bezuumlglich der Mathematik von bdquoLichtsimulationldquo und der Im-plementierung selbiger verweisen wir auf [Learn OpenGL ES] und beschreiben hier nur die in unseremQuellcode wesentlichen Aumlnderungen Wie oben bereits erwaumlhnt muumlssen wir im Positionsarray fuumlr jedenGitterpunkt die z-Komponente veraumlndern Da wir in dem Positionsarray auch zuvor drei Eintraumlge pro Git-terpunkt vorgesehen haben muumlssen wir dessen Groumlszlige nicht variieren Aus diesem Grund benoumltigen wirkeine gravierenden Umstrukturierungen im Quellcode sondern koumlnnen das Setzen der z-Komponentedurch eine einfache for-Schleife realisieren Dies muumlssen wir jetzt in die drawGrid-Methode ein-bauen in der wir den Quellcode 32 und die nachfolgenden Schleifen durch die Schleifen zum Aumlnderndes Positionsvektors ersetzen Dadurch reduzieren wir den Aufwand bereits erheblich da wir die zahl-reichen Aufrufe der Funktion colourSet vermeiden Zusaumltzlich zu den for-Schleifen benoumltigen wirden Normalenvektor in jedem Gitterpunkt wie es in [Learn OpenGL ES] beschrieben wird um OpenGLES 20 zur Visualisierung einsetzen zu koumlnnen Dies koumlnnen wir jedoch relativ einfach realisierenZunaumlchst berechnen wir die Normalenvektoren eines jeden Dreiecks in unserem Gebiet indem wir dasKreuzprodukt von zwei Schenkeln des Dreiecks bilden Dies ist moumlglich da die Koordinaten aller Punk-te bekannt sind Den Normalenvektor eines Gitterpunktes bestimmen wir anschieszligend als Mittelung derNormalenvektoren der benachbarten Dreiecke Bei Randpunkten verfahren wir analog nur dass wenigerNachbardreiecke vorliegen als im Innern des Gebiets Diese Berechnungen koumlnnen wir auch uumlber for-Schleifen durchfuumlhren wobei wir die Bestimmung der Normalen eines jeden Punktes als eigenstaumlndigeFunktion auslagern koumlnnenDurch Verwenden dieser alternativen Variante koumlnnen wir die komplette Visualisierungs-Komponenteunserer Simulationssoftware optimieren da wir pro Gitterpunkt einen Funktionenaufruf sparen und statt-dessen bdquonurldquo einen Eintrag im Positionsarray aumlndern muumlssen Wir verzichten allerdings auf eine Imple-mentierung dieser Visualisierungsmoumlglichkeit da sie mit einem relativ groszligen Aufwand verbunden istZwar ist der visuelle Gewinn enorm da wir durch die Schattierungen wesentlich glattere Farbuumlbergaumlngeerzielen allerdings sind die Auswirkungen auf die Gesamtlaufzeit der Software viel zu gering

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 50

443 Analyse der Interaktions-Komponente

Nun wollen wir uns mit dem verbleibenden Element unserer Software beschaumlftigen der InteraktivitaumltDazu messen wir die Laufzeit der onTouchEvent-Routine was sich als relativ schwierig herausstelltda es sich um eine sogenannte bdquoCallbackldquo-Routine handelt Sie wird also vom System automatisch auf-gerufen In diesem Fall geschieht das nur dann wenn der Anwender die Stroumlmung interaktiv durchBeruumlhren des Bildschirms beeinflusst Fuumlr technische Details verweisen wir auf Kapitel 33 So koumlnnenwir zwar die Laufzeit ermitteln wenn ein solches TouchEvent stattfindet jedoch nicht wenn keineInteraktivitaumlt auftritt da die Routine in diesem Fall nicht aufgerufen wird Um trotzdem den Einfluss deronTouchEvent-Funktion auf die Gesamtlaufzeit beurteilen zu koumlnnen haben wir erneut die Laufzeitder drawGrid-Methode die wir bereits in Abschnitt 442 genauer untersucht haben einmal mit undeinmal ohne Einfluss von Nutzer-Interaktivitaumlt bestimmt (vgl Abbildung 429) Anhand dieser Zeitenkoumlnnen wir nun beurteilen wie stark sich ein TouchEvent auf die Gesamtlaufzeit der Software aus-wirkt Als Testkonfiguration waumlhlen wir dazu als Gitterschrittweite h = 1

128 Die uumlbrigen Parameter sindnicht relevant da wir hier den Loumlser nicht betrachten In Abbildung 429 sind sowohl die Laufzeiten derdrawGrid-Routine bei einer Nutzerinteraktion als auch die ohne Interaktivitaumlt zu sehenWaumlhrend des ersten Zeitschritts koumlnnen wir den gleichen Verlauf der Laufzeiten beobachten danachliegt die Zeit bei der keine Interaktion stattfindet jedoch deutlich unter der interaktionsbehafteten ZeitZu Beginn koumlnnen wir bei beiden Laufzeitverlaumlufen den mit Abstand groumlszligten und nahezu gleichen Wertablesen weshalb wir den ersten Zeitschritt als eine Art Initialisierungsphase interpretieren koumlnnen Zwarallokieren wir alle fuumlr die Simulation benoumltigten Groumlszligen bereits im Konstruktor der Klasse allerdingsfuumlllen wir waumlhrend des ersten Zeitschritts den Groszligteil der Arrays zum ersten Mal beziehungsweisegreifen zum ersten Mal auf sie zu was die relativ hohe Laufzeit erklaumlrt

5 10 15 20 25 30 350045

005

0055

006

0065

007

0075

008

0085

Zeitschritt

Ze

it in

Se

ku

nd

en

mit Interaktion

ohne Interaktion

Abbildung 429 Laufzeiten der drawGrid-Methode mit beziehungsweise ohne Interaktion des Anwen-ders

Die Laufzeit fuumlr den Fall dass keine Interaktion vom Anwender ausgeht verhaumllt sich im weiteren Ver-lauf nahezu konstant in einer Groumlszligenordnung von 0047 Sekunden Es laumlsst sich leicht erkennen dassdie Laufzeiten wesentlich houmlher sind sobald der Anwender ein TouchEvent ausfuumlhrt was wir demin rot gezeichneten Graphen in Abbildung 429 entnehmen koumlnnen Genauer gesagt betraumlgt der Un-terschied zwischen der Laufzeit mit beziehungsweise ohne Interaktion in der Spitze 00285 SekundenWenn wir nun die Laufzeit ohne Interaktion betrachten stellen wir einen Zuwachs von 50 Prozent festDie tatsaumlchliche Laufzeit der onTouchEvent-Methode ergibt sich nun als Differenz der beiden soebengemessenen Laufzeiten und ist in Abbildung 430 dargestellt

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 51

5 10 15 20 25 30 350

0005

001

0015

002

0025

003

Zeitschritt

Ze

it in

Se

ku

nd

en

Abbildung 430 Laufzeit der onTouchEvent-Methode

Der dortige Verlauf aumlhnelt dem der Zeiten an denen Interaktivitaumlt stattfindet was kein Zufall ist Einer-seits verhalten sich die Laufzeiten nahezu konstant wenn keine Interaktion erfolgt andererseits wird dieonTouchEvent-Methode nur aufgerufen wenn ein TouchEvent stattfindet Wir verzichten hier aufeine genauere Analyse des in rot gezeichneten Graphen aus Abbildung 429 da er vom Verlauf her imWesentlichen dem aus Abbildung 430 entspricht und sich die Laufzeiten nur um den Wert der interakti-onsfreien Zeiten unterscheidenWir koumlnnen beobachten dass sich die Laufzeiten der onTouchEvent-Routine in ihrer Groumlszligenordnungsehr unregelmaumlszligig verhalten (vgl Abbildung 430) Die Ursache dafuumlr wollen wir im Folgenden genaueruntersuchen Wie bereits im Abschnitt 33 beschrieben stehen auf dem von uns verwendeten Geraumlt zweiKerne zur Verfuumlgung Auf einem fuumlhren wir die Visualisierung und auf dem anderen die Berechnungaus Auf dem Visualisierungsthread fragen wir jedoch zusaumltzlich die TouchEvents ab Wenn wir diezu Beginn des Abschnitts verworfene Idee eine Zeitmessung in der onTouchEvent-Methode selbstdurchzufuumlhren trotzdem verfolgen und uns zusaumltzlich die Anzahl der Zeitschritte der Simulation ausge-ben lassen so stellen wir fest dass pro Zeitschritt mehrere Aufrufe dieser Methode erfolgen Dies ergibtsich dadurch dass die Simulation nicht in Echtzeit stattfindet und somit innerhalb eines Zeitschritts meh-rere TouchEvents stattfinden koumlnnen da wir eine Abfrage nach solchen Events unabhaumlngig von derrestlichen Simulation ausfuumlhren Je langsamer die Simulation laumluft zum Beispiel bei Verkleinerung derGitterschrittweite h koumlnnen potentiell immer mehr TouchEvents pro Zeitschritt erfolgen Fuumlr die Si-mulation ist dennoch nur ein Wert relevant da wir nur zu Beginn eines jeden Zeitschritts eine externeKraft auf das Fluid aufpraumlgen Somit beruumlcksichtigen wir nur den Wert der aktuell vorliegt und nichtetwa eine Mittelung aller waumlhrend des Zeitschritts auftretenden Werte Die unregelmaumlszligigen Ausschlaumlgedie wir in Abbildung 430 ablesen koumlnnen deuten somit auf eine unterschiedlich schnelle Interaktion desAnwenders hin Je schneller der Finger vom Nutzer uumlber den Bildschirm bewegt wird desto mehr Aufru-fe der onTouchEvent-Methode erfolgen Der hohe Ausschlag in Zeitschritt 19 deutet auf eine schnel-lere Bewegung hin als die uumlbrigen kleineren Ausschlaumlge Die onTouchEvent-Funktion wird dort alsohaumlufiger aufgerufen als sonst Nun koumlnnen wir die Vermutung anstellen dass durch die TouchEventsein unendlich langer Zeitschritt erzwungen werden kann Sowohl die Visualisierung als auch der Aufrufder onTouchEvent-Routine laufen auf dem selben Thread der nur eine Aktion ausfuumlhren kann undsomit warten muss bis keine TouchEvents mehr auftreten um einen neuen Frame zu zeichnen DieseVermutung ist allerdings falsch Zwar bearbeiten wir sowohl Visualisierung als auch TouchEvents aufdem selben Thread allerdings findet eine Abfrage nach TouchEvents nicht permanent statt sodasswir die Visualisierung immer im nahezu gleichen Rhythmus ausfuumlhren koumlnnenEine Laufzeit-Verbesserung der Interaktions-Komponente koumlnnen wir also erreichen indem wir nureinen Aufruf der onTouchEvent-Methode pro Zeitschritt zulassen Damit vermeiden wir groszlige Aus-schlaumlge wie sie etwa in Abbildung 430 zu finden sind Wie wir im folgenden Abschnitt 444 sehen

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 52

liefert dies allerdings nur eine geringfuumlgige Verbesserung der Gesamtlaufzeit der Simulation

444 Zusammenfassung

Abschlieszligend wollen wir die Gesamtlaufzeiten der einzelnen Bestandteile unserer Simulationssoftwarevergleichen um besser einschaumltzen zu koumlnnen wie stark sich die Laufzeiten des Loumlsers der Visualisie-rung beziehungsweise die der Abfrage nach TouchEvents auf die Gesamtlaufzeit auswirken Dazustellen wir in Tablle 46 nochmal die Laufzeiten der verschiedenen Komponenten fuumlr den Testfall Dri-ven Cavity mit der Gitterschrittweite h = 1

128 fuumlr maxiter= 32 Iterationen im Jacobi-Loumlser und derStandard-Testkonfiguration die wir zu Beginn von Kapitel 44 verwenden dar Dabei handelt es sich umdie Zeiten die sich im Laufe eines Zeitschritts ergeben

Loumlser Visualisierung TouchEventZeit in Sekunden 0474 0048 0014

Tabelle 46 Gesamtlaufzeiten der einzelnen Simulations-Komponenten in Sekunden fuumlr h = 1128 und

maxiter = 32

Wir koumlnnen leicht erkennen dass der Loumlser die fuumlr die Laufzeit unserer Software maszliggeblich verantwort-liche Komponente darstellt Um die Laufzeit zu optimieren muumlssen wir diesen also effizienter gestaltenUntersuchungen dazu finden sich in Abschnitt 441 Als zentrales Mittel steht dabei die Parallelisierungim Vordergrund da wir in vielen unserer Funktionen und Routinen im Loumlser for-Schleifen verwendenDurch die uns zur Verfuumlgung stehenden zwei Kerne koumlnnen wir naumlherungsweise einen Faktor zwei inder Laufzeitverbesserung erreichen Zusaumltzlich besteht die Moumlglichkeit die Berechnungen innerhalb desLoumlsers mit einfacher statt doppelter Genauigkeit durchfuumlhren Dadurch koumlnnten wir die Laufzeit auf-grund der doppelten Bandbreite was bedeutet dass die Daten schneller im Chip zur Verfuumlgung stehenasymptotisch auch um einen Faktor zwei reduzieren Unterteilen wir den Loumlser nicht in seine program-miertechnischen Details wie if-Abfragen oder for-Schleifen sondern in seine mathematischen sostellen wir fest dass der Jacobi-Loumlser einen groszligen Anteil an der Gesamtlaufzeit des Loumlsers hat (vglAbbildung 425) Das Jacobi-Verfahren wird hinsichtlich der benoumltigten Zeit von der Anzahl der durch-zufuumlhrenden Iterationen dominiert welche wir vom jeweiligen Testfall abhaumlngig waumlhlen und so unterUmstaumlnden Zeit einsparen koumlnnenDie beiden uumlbrigen Komponenten der Simulation haben im Vergleich zum Loumlser einen sehr geringenEinfluss auf die Laufzeit Die der Visualisierung ist zehn mal so klein wie die des Loumlsers und bietetdennoch viel Optimierungspotential So koumlnnen wir zum einen die drawArrays-Methode verbesserndie wir zur Darstellung des Rechengebiets verwenden da wir hier viele Gitterpunkte mehrfach zeichnenlassen (vgl Abbildung 33) Auszligerdem steht uns neben der von uns verwendeten Methode der Heat Mapein weiteres schnelleres Verfahren zur Visualisierung zur Verfuumlgung Bedienen wir uns der Heat Mapfaumlrben wir jeden Gitterpunkt gemaumlszlig des Wertes der Geschwindigkeit beziehungsweise des Drucks der indem entsprechenden Knoten vorliegt Dazu verwenden wir erneut for-Schleifen und if-Abfragen Aufder anderen Seite koumlnnen wir auf eine bdquomanuelleldquo Faumlrbung verzichten und mit Schattierungen arbeiten(vgl Abbildungen 427 und 428) Bei dieser Vorgehensweise verwenden wir eine Lichtquelle die wirmittels OpenGL ES 20 simulieren koumlnnen und betrachten ein gewelltes zweidimensionales Gitterindem wir einen skalierten Wert des Drucks in jedem Gitterpunkt als Houmlhe vorschreiben Durch das Ein-setzen der Lichtquelle ist es uns dann moumlglich anhand von Schatten das Fluidverhalten zu beobachtenStatt wie zuvor den Farbarray zu aktualisieren muumlssen wir nun fuumlr jeden Knoten in jedem Zeitschritt diez-Komponente aumlndern Dadurch verwenden wir deutlich kleinere for-Schleifen was sich positiv aufdie Laufzeit auswirktZuletzt koumlnnen wir die Abfrage nach TouchEvents die den mit Abstand geringsten Anteil an der Ge-samtlaufzeit ausmacht modifizieren sodass wir nur noch eine Abfrage pro Zeitschritt durchfuumlhren

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 4 TESTS 53

Wir koumlnnen zusammenfassend festhalten dass fuumlr eine Verbesserung der Laufzeit der Simulation genuuml-gend Potential vorhanden ist Wir muumlssen jedoch davon ausgehen dass die Rechenleistung des TegraTM-2 noch nicht fuumlr eine Echtzeit-Simulation ausreichend ist da wir fuumlr visuell ansprechende Resultate einehinreichend kleine Gitterschrittweite h verwenden muumlssen wodurch sich der Rechenaufwand und damitdie Laufzeit der einzelnen Komponenten stark erhoumlht

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

Kapitel 5

Diskussion und Fazit

In diesem Kapitel fassen wir die wesentlichen Ergebnisse der Arbeit zusammen und geben abschlieszligendeine Bewertung der SimulationsumgebungIn Kapitel 41 haben wir die numerische Stabilitaumlt unserer Implementierung und physikalische Kor-rektheit unserer Stroumlmungssimulation die auf der Stable-Fluids-Methode von Stam basiert untersuchtAnhand des Testfalls Steady haben wir die numerische Stabilitaumlt unserer Loumlsung uumlberpruumlft und anschlie-szligend verifiziert ob sich unsere Stoumlrmungssimulation physikalisch korrekt verhaumllt Dazu haben wir dengaumlngigen Testfall Driven Cavity uumlber einen laumlngeren Zeitraum betrachtet Hierbei haben wir festgestelltdass sich letztendlich eine Stroumlmungssituation einstellt welche sich ab einem gewissen Zeitpunkt kaummehr veraumlndert Die Visualisierung der Stroumlmung haben wir genutzt um sie mit einem Referenzbild einerkorrekten Loumlsung zu vergleichen Wir sind hier zu dem Ergebnis gekommen dass unsere Stroumlmungssi-tuation der Referenzloumlsung sehr aumlhnelt und die selben Strukturen aufweist An dieser Stelle halten wirfest dass wir von einer numerisch richtigen Implementierung und physikalisch realistischem Verhaltenunseres Simulationsmodells ausgehen koumlnnenIn Kapitel 42 haben wir den Einfluss verschiedener Parameter auf unsere Stroumlmungssimulation analy-siert um anhand dieser Tests weitere Aussagen zur Korrektheit und zum dynamischen Verhalten unsererStroumlmungssimulation treffen zu koumlnnen Hierbei haben wir zunaumlchst den Einfluss der Viskositaumlt ν anhanddes Testfalls Hubbel mit zwei Druckspitzen untersucht Wir haben dabei festgestellt dass sich unser Mo-dell genau so verhaumllt wie wir es intuitiv annehmen Nimmt die Viskositaumlt kleinere Werte an erhalten wirein duumlnnfluumlssigeres Flieszligverhalten als bei groszligen Werten der ViskositaumltAnschlieszligend haben wir den Einfluss des Parameters ∆t welcher ein Maszlig fuumlr die Genauigkeit unsererLoumlsung ist anhand des Testfalls Hubbel mit einer Druckspitze ermittelt Hierzu haben wir sowohl nume-rische als auch visuelle Komponenten verwendet Wir koumlnnen festhalten dass fuumlr verschiedene Werte von∆t unterschiedliche Ausbreitungsmuster entstehen und dass einige ein unrealistisches Simulationsmo-dell zur Folge haben So entstehen fuumlr zu groszlige Werte unnatuumlrliche Verwirbelungen und AusbreitungenErst bei kleinen Werten erhalten wir eine physikalisch sinnvolle Simulation Weiter bestaumltigt sich hierdie in Kapitel 2 vorhergesagte Stabilitaumlt unserer Loumlsung fuumlr alle Werte von ∆t Diese Aussage zeigt unserneut dass wir unsere Software der Theorie gemaumlszlig richtig implementiert habenAls letzten Aspekt in diesem Kapitel haben wir den Einfluss der Anzahl an Iterationen unseres Jacobi-Loumlsers auf die Symmetrieeigenschaften unserer Software anhand des Testfalls Hubbel mit vier symme-trisch angeordneten Druckspitzen analysiert Wir haben hier festgestellt dass wir zwischen zwei ver-schiedenen Symmetrien unterscheiden muumlssen Einmal die Symmetrie zur x- beziehungsweise y-Achsewelche in unserem Testfall erst ab einer sehr hohen Anzahl an Iterationen noch uumlber einen laumlngeren Zeit-raum hin auszumachen ist und einmal die Diagonalsymmetrie welche schon bei sehr wenigen Jacobi-Schritten gut erkennbar bleibt Dies bedeutet dass die Anzahl der Jacobi-Iterationen im Bezug auf dievisuellen Resultate lediglich Einfluss auf die Achsensymmetrie hat und die Diagonalsymmetrie durchdie symmetrische Struktur der Implementierung erreicht wirdIn Kapitel 43 haben wir die Umsetzung der Anwender-Interaktion anhand zweier Testfaumllle gepruumlft Zu-

54

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 5 DISKUSSION UND FAZIT 55

naumlchst haben wir in Abschnitt 431 den Testfall Steady betrachtet und die Verarbeitung vonTouchEvents analysiert Wir sind zu dem Ergebnis gekommen dass eine realistische Stroumlmung auf-tritt Zum einen wird die Stroumlmung bei schnelleren Bewegungen uumlber den Bildschirm staumlrker und zumanderen klingt die Stroumlmung ab wenn der Anwender mit der Interaktion aussetzt Ob wir die Resultatedie wir zuvor getroffen haben auch fuumlr einen komplexeren Testfall erreichen haben wir anschlieszligendmit Hilfe des Testfalls Hubbel mit einer Druckspitze beurteilt Wir haben dabei festgestellt dass die Strouml-mung die durch die Druckspitze erzeugt wird korrekt vom Anwender gestoumlrt wird Nach Stoppen derInteraktion stellt sich ein bdquonatuumlrlichesldquo Verhalten ein was den Eindruck bestaumlrkt dass TouchEventsalso das Aufpraumlgen einer Kraft durch den Anwender physikalisch korrekt umgesetzt werdenIm abschlieszligenden Kapitel 44 haben wir die Laufzeiten unserer Software beziehungsweise die ih-rer einzelnen Bestandteile gemessen um moumlgliches Optimierungspotential im Hinblick auf Echtzeit-Simulation auszumachen Es ist dabei zu beachten dass wir eine Unterscheidung zwischen bdquoEchtzeitldquound bdquoInteraktionldquo treffen Interaktion ist moumlglich obwohl die Simulation nicht in Echtzeit stattfindet unddie Visualisierung somit verzoumlgert auf ein Interagieren des Anwenders reagiert Wir haben zur Laufzeit-Analyse die drei wesentlichen Bestandteile unserer Implementierung betrachtet den Loumlser die Visuali-sierungs- und die Interaktions-Komponente In Abschnitt 441 haben wir demnach zuerst die Implemen-tierung des Verfahrens zur numerischen Loumlsung der Navier-Stokes Gleichungen analysiert Dabei habenwir beobachtet dass die Laufzeit des numerischen Loumlsungsverfahrens im Wesentlichen von der Laufzeitdes Jacobi-Loumlsers dominiert wird Diesen koumlnnen wir primaumlr dadurch optimieren dass wir die auftreten-den for-Schleifen parallelisieren Wir koumlnnen maximal einen Faktor zwei in der Laufzeitverbesserungerzielen da uns zwei Kerne zur Verfuumlgung stehen Die anderen Funktionen wie etwa Vektorupdatesoder der Tracer spielen zwar bezuumlglich ihrer Laufzeit eine untergeordnete Rolle wir koumlnnen diese abertrotzdem durch Parallelisierung optimieren Zudem koumlnnen wir die Gesamtlaufzeit des Loumlsers durch dieAnpassung der durchgefuumlhrten Iterationen im Jacobi-Loumlser beeinflussen Wir haben anhand von Zeitmes-sungen des Jacobi-Verfahrens fuumlr unterschiedliche Werte von maxiter festgestellt dass das Verfahrenbei einer Verdopplung der Iterationszahlen auch eine doppelt so groszlige Laufzeit aufweist Da wir denJacobi-Loumlser drei Mal in unserer Implementierung verwenden koumlnnen wir an dieser Stelle stark auf dieGesamtlaufzeit eines Zeitschritts einwirken Dabei muumlssen wir beachten dass wir maxiter testfallab-haumlngig waumlhlen koumlnnen da wir bei einigen Testfaumlllen auch fuumlr wenige Iterationen im Jacobi-Loumlser optischgute Resultate erhalten (vgl Kapitel 42)Anschlieszligend haben wir die Laufzeiten der Visualisierungs-Komponente untersucht wobei wir festge-stellt haben dass ihre Laufzeit deutlich geringer ist als die des Loumlsers Den groumlszligten Anteil an der Lauf-zeit dieser Komponente hat dabei das Zeichnen des Gitters welches wir von einer Standardfunktion vonOpenGL ES 20 ausfuumlhren lassen Diese koumlnnen wir in der Form optimieren dass wir jeden Gitter-punkt nur ein Mal zeichnen lassen und nicht bis zu sechs Mal wie es unoptimiert der Fall ist Das Setzender Farben naumlhert sich bezuumlglich der Laufzeit fuumlr kleinere Schrittweiten der Laufzeit der drawArrays-Methode an ist aber potentiell deutlich schneller Auch hier koumlnnen wir die Laufzeit durch Parallelisie-rung der auftretenden for-Schleifen optimieren Uns steht theoretisch eine andere Moumlglichkeit als dieHeat Map zur Visualisierung zur Verfuumlgung die zu deutlich weniger Aufwand bei der Visualisierungfuumlhren wuumlrde allerdings waumlre der Laufzeitgewinn so gering dass wir auf eine Implementierung verzich-tenZuletzt haben wir in Abschnitt 443 die Implementierung der Interaktions-Komponente betrachtet wo-bei wir erneut Standardfunktionen von OpenGL ES 20 verwenden Wir haben dabei festgestellt dassAbfragen nach TouchEvents mehrmals pro Iteration ausgefuumlhrt werden obwohl wir nur eine zumAufpraumlgen einer Kraft nutzen Somit finden viele unnoumltige Aufrufe dieser Funktion statt was enormesOptimierungspotential bietet Jeodch koumlnnen wir auch hier nur einen eher geringen Ertrag an der Lauf-zeitverbesserung der Simulation erwarten da die Laufzeit der Interaktions-Komponente viel kleiner istals die des LoumlsersInsgesamt koumlnnen wir festhalten dass der Loumlser die Laufzeit der Simulation dominiert und sich weitereModifizierungen bezuumlglich der Optimierung auf diesen Teil der Implementierung konzentrieren muumlssen

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

KAPITEL 5 DISKUSSION UND FAZIT 56

Es sei noch erwaumlhnt dass sich der Parameter ∆t neben dem Einfluss auf das Symmetrieverhalten desFluids auch auf die Echtzeit der Simulation auswirkt Waumlhlen wir den Parameter unpassend koumlnnenwir unter Umstaumlnden keine Echtzeit-Simulation erreichen selbst wenn die Laufzeiten der Software einesolche erlauben Daher muumlssen wir bei der Wahl der Zeitschrittweite auch die Gesamtlaufzeit der Simu-lation beachten

Wir koumlnnen anhand der durchgefuumlhrten Tests zusammenfassend formulieren dass es sich bei dem inKapitel 2 hergeleiteten Verfahren um ein zur Stroumlmungssimulation geeignetes handelt Zusaumltzlich liefertdie im Implementierungskapitel 3 vorgestellte Umsetzung der Theorie physikalisch sinnvolle ErgebnisseVor allem ist dabei die Realisierung der Anwender-Interaktion zu betonen Weiterhin koumlnnen wir hervor-heben dass wir die Anwender-Interaktion sehr intuitiv umsetzen und das simulierte Fluid physikalischkorrekt reagiert Auszligerdem haben wir verschiedene Optimierungsmoumlglichkeiten herausgearbeitet umeine weitere Beschleunigung der Simulation zu erzielenDer von uns verwendete Tablet-Computer (basierend auf einem Tegra-2 Chip der Firma NVIDIA Rcopy)stellt noch nicht die Rechenkapazitaumlten zur Verfuumlgung die fuumlr Echtzeit-Simulationen mit sehr kleinenZeit- und Gitterschrittweiten noumltig sind Dennoch ziehen wir das Fazit dass sich Tablet-Computer fuumlrdie physikalisch korrekte numerische Stroumlmungssimulation eignen zumal die intuitive Integration derAnwender-Interaktion sehr gut umgesetzt werden kann

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57

Literaturverzeichnis

[Stam] Jos Stam Stable Fluids In SIGGRAPH 99 Conference Proceedings Annual Conference Series121-128 1999

[Harris] Mark J Harris Fast Fluid Dynamics Simulation on the GPU In Randima Fernando editorGPU Gems Kapitel 38 Addison-Wesley 1 Auflage 2004

[Anderson] John D Anderson Computational Fluid Dynamics McGraw-Hill 1995

[Arlt] Bastian Arlt Elektroviskositaumlt httpwwwitpphysiktu-berlinde~bastidownload10Protokoll-elektroviskositaetpdf

[Chorin] Alexandre J Chorin Jerrold E Marsden A Mathematical Introduction to Fluid MechanicsSpringer-Verlag New York 1993

[Forster] Otto Forster Analysis 2 Springer-Verlag Wiesbaden Vieweg+Teubner Verlag Springer Fach-medien Wiesbaden GmbH Wiesbaden 2010

[Learn OpenGL ES] httpwwwlearnopenglescom

[Android Developer] httpwwwdeveloperandroidcom

[SongHo] httpwwwsonghocaopenglgl_transformhtml

[Verdia] httpmagicscrollsofcodeblogspotde2010103d-picking-in-androidhtml

[CFD Online] httpwwwcfd-onlinecomWikiLid-driven_cavity_problem

[Asus] httpwwwasusdeEeeEee_PadEee_Pad_Transformer_TF101specifications

[RGBenchMM] httpwwwrgbenchcom

[NVIDIA] httpwwwnvidiadeobjecttegra-2-dehtml

[Strzodka] Robert Strzodka Mohammed Shaheen Dawid Pajak und Hans-Peter Seidel Cache obliviousparallelograms in iterative stencil computations Proceedings of the 24th ACM International Con-ference on Supercomputing (ICS rsquo10) 2010

57