design und implementierung eines computational steering ... · ich versichere, dass ich diese...

Technische Universitat Munchen

Fakultat fur Informatik

Diplomarbeit in Informatik

Design und Implementierung einesComputational Steering Frameworks fur

CFD-Simulationen

Atanas Atanasov

Technische Universitat Munchen

Fakultat fur Informatik

Diplomarbeit in Informatik

Design und Implementierung einesComputational Steering Frameworks fur

CFD-Simulationen

Design and Implementation of aComputational Steering Framework for

CFD-Simulations

Bearbeiter: Atanas AtanasovAufgabensteller: Univ.–Prof. Dr. Hans-Joachim BungartzBetreuer: Dipl.–Tech. Math. Tobias NeckelAbgabedatum: 17.8.2009

Ich versichere, dass ich diese Diplomarbeit selbstandig verfasst und nur die angege-benen Quellen und Hilfsmittel verwendet habe.

I assure the single handed composition of this diploma thesis only supported bydeclared resources.

17.8.2009

Datum Atanas Atanasov

ii

Inhaltsverzeichnis

1 Zusammenfassung 2

2 Abstract 3

3 Grundlagen 43.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2 Begriffe der Fluiddynamik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.3 Die Navier-Stokes Gleichungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.3.1 Die substantielle Ableitung . . . . . . . . . . . . . . . . . . . . . . . . . 53.3.2 Das Prinzip der Massenerhaltung . . . . . . . . . . . . . . . . . . . . . . 63.3.3 Der Impulserhaltungssatz . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3.4 Randbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3.5 Raumliche und zeitliche Diskretisierung . . . . . . . . . . . . . . . . . . 8

3.4 Das Peano Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.4.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.4.2 Gitterstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.4.3 Traversierung der Gitterstrukturen . . . . . . . . . . . . . . . . . . . . . 12

3.5 Visualisierung von Stromungsdaten . . . . . . . . . . . . . . . . . . . . . . . . . 133.5.1 Wissenschaftliche Visualisierung . . . . . . . . . . . . . . . . . . . . . . 143.5.2 Das Visualisierungsreferenzmodell . . . . . . . . . . . . . . . . . . . . . 143.5.3 Die Renderingpipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.5.4 Grundlagen der Stromungsvisualisierung . . . . . . . . . . . . . . . . . . 183.5.5 Skalar-Visualisierungsalgorithmen . . . . . . . . . . . . . . . . . . . . . 183.5.6 Visualisierungstechniken fur Vektorfelder . . . . . . . . . . . . . . . . . 21

3.6 Parallelisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.6.1 Einteilung zu den parallelen Rechenarchitekturen . . . . . . . . . . . . . 243.6.2 Parallelisierungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.7 Computational Steering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.8 Verwendete Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Anforderungen 304.1 Simulationsanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.2 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.3 Steering Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Konzept 345.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1.1 Nachrichtenaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.1.2 Das Client-Server Modell . . . . . . . . . . . . . . . . . . . . . . . . . . 355.1.3 Remote Procedure Call und Remote Method Invocation . . . . . . . . . 36

iii

5.1.4 Die Steering-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2 Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.3 Manipulation von Geometrien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.4 Die graphische Oberflache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.5 Visualisierungskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.5.1 Realisierung grundlegender Visualisierungsverfahren . . . . . . . . . . . 485.5.2 Remote Rendering und parallele Visualisierung . . . . . . . . . . . . . . 49

6 Implementierung 546.1 Die Kommunikationskomponenten . . . . . . . . . . . . . . . . . . . . . . . . . 546.2 Serialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.3 Implementierung der Uberwachungskomponente-Peano . . . . . . . . . . . . . . 576.4 Implementierung der Steeringkomponente-Peano . . . . . . . . . . . . . . . . . 586.5 Implementierung der Steering Applikation . . . . . . . . . . . . . . . . . . . . . 59

6.5.1 QT und VTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606.5.2 Gitter-Aufbau und Streaming in VTK . . . . . . . . . . . . . . . . . . . 606.5.3 3D Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.5.4 Implementierung der Visualisierungsalgorithmen . . . . . . . . . . . . . 636.5.5 Die Geometrien und Szenarien . . . . . . . . . . . . . . . . . . . . . . . 66

6.6 Parallelisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.6.1 Parallelisierung in Peano . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.6.2 Parallelisierung der Visualisierung . . . . . . . . . . . . . . . . . . . . . 68

6.7 Desktop Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.7.1 VirtualGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.7.2 Desktop Delivery in VTK . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7 Auswertung 787.1 Funktionaler Vergleich mit anderen Steering-Ansatzen . . . . . . . . . . . . . . 787.2 Visualisierunsergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.2.1 Color Mapping und Konturengenerierung . . . . . . . . . . . . . . . . . 827.2.2 Schnittebenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.2.3 Bahnalgorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.3 Steering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.4 Parallelisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

8 Erweiterungsmoglichkeiten 908.1 Erweiterungen in Peano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

8.1.1 Checkpointing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908.1.2 Bewegliche Geometrien-Teil II . . . . . . . . . . . . . . . . . . . . . . . 908.1.3 Implizite Losungsverfahren und Lattice-Bolzmann . . . . . . . . . . . . 91

8.2 Erweiterungsmoglichkeiten fur die Visualisierung . . . . . . . . . . . . . . . . . 918.3 Steering und Virtual Reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

9 Ausblick 95

Literaturverzeichnis 96

Abbildungsverzeichnis 98

iv

Tabellenverzeichnis 99

Seite 2 1 Zusammenfassung

1 Zusammenfassung

Mit der rasanten Entwicklung der Rechenleistung in den letzten Jahren steigt die Bedeutungvon parallelen Simulationen in vielen wissenschaftlichen Bereichen. Der sich erhohende Anzahlder Anwendungen verlangt kontinuierlich steigende Flexibilitat und Nutzen von dem gesamtenSimulationslauf. Das Gebiet des Computational Steerings nimmt diese Herausforderungen imAnspruch, indem es dem Wissenschaftler die Gelegenheit gibt verschiedener Parameter derlaufenden Simulation zu verandern und deren Verhalten zu beobachten. Die heutige Graphik-Hardware und Algorithmen bieten ein großes Spektrum fur die Visualisierung von komplexenSimulationsvorgangen an.

Diese Arbeit beschaftigt sich mit der Implementierung und der Integration eines SteeringSystems in dem bereits vorhandenen CFD-Simulationsframework des Lehrstuhls fur wissen-schaftlichen Rechnen in der Informatik. Im Verlauf der Arbeit wurden Verfahren fur die Dar-stellung der Stromungsdaten und die Interaktion mit der Simulation auf kartesischen Gitterentwickelt.

Zunachst werden die theoretischen Grundlagen der Fluidsimulation und die Basisalgorith-men fur die Visualisierung von Stromungsdaten vorgestellt. Im Weiteren werden die not-wendigen Verfahren zur Umsetzung eines Konzeptes eingefuhrt, die die Interaktion zwischenBenutzer und Simulation ermoglichen. In dem zweiten Teil der Arbeit werden Techniken zurUberwachung und Steuerung sowie fur die Parallelisierung und Verteilung der Steering Inter-face konzipiert und bezuglich deren Nutzlichkeit bewertet. Abschließend werden die moglichenErweiterungen der skizzierten Ansatze vorgestellt.

Seite 3

2 Abstract

With the growing computing power development in the last years, rises the importance ofparallel simulations in many scientific areas. The elevating numbers of applications requirecontinuously growing flexibility and utility from the simulation run. The area of computationalsteering engages this requirements through giving the possibility to scientist to change andmonitor parameters of running simulations.

The topic of this work is the design, implementation and integration of one steering sys-tem in the existing CFD Simulation Framework of the chair of scientific computing. Duringconceptualization process of this work, methods for the visualization and interaction with thesimulation on Cartesian Grids were developed.

The first part of this document describes the motivation behind this work. After thatfollows an introduction of the theoretical basics of fluid simulation and the visualization ofCFD-Data. The essential algorthims for the realization of a concept, which allow the real timeinteraction between user and simulation, are then introduced. The second part of the workdescribes and evaluates techniques for remote visualization, remote interaction, parallelizationand distribution of the steering interface. Finally, possibilities for further development of theproject are discussed.

Seite 4 3 Grundlagen

3 Grundlagen

In diesem Kapitel werden die theoretischen Grundlagen der Fluid Simulation in Peano, dieverwendeten Visualisierungstechiken fur die Darstellung der Stromungsdaten und das Gebietdes Computational Steerings vorgestellt. Dabei werden Begriffe aus der Stromungslehre ein-gefuhrt. Mit deren Hilfe werden die Navier-Stokes Gleichungen abgeleitet. Im Weiteren erfolgtkurze Zusammenfassung der verwendeten externen Bibliotheken und deren Funktionsmodule,die die Umsetzung der gewahlten Techniken ermoglichen.

3.1 Motivation

Die parallelen Applikationen spielen eine wichtige Rolle in dem heutigen Welt des wissen-schaftliches Rechnens. Mit der Vergroßerung der Bereichen, die von solchen Applikation be-handelt werden, steigt auch die Komplexitat der Anwendungen und Bedarf fur mehr Flexibili-tat und Nutzen fur den Endbenutzer. Die bis jetzt verwendeten Techniken fur Batch Analyseder Simulation sind nicht gut geeignet fur die heutigen zeitkritischen HPC-Anwendungenund Architekturen. Ein Weg zum Erreichen von Interaktivitat bei dem Umgang mit solcherAnwendungen ist das Computational Steering. Die Kombination von Computaional Steeringund verschieden virtuelle Umgebungen stellen sehr realistische und machtige Tools zu demWissenschaftler bei der Exploration einer Simulationsumgebeng zur Verfugung . Mit solchenTools konnen die Explorationszeiten einer Simulation um das Wesentliche verringert werden.

Die Computational Steering Applikationen unterstutzten den Wissenschaftler durch Anbie-ten der Moglichkeit fur Interaktion mit der Simulationsdaten. Die Erhohung der Rechenleis-tung der heutigen Prozessoren und graphischen Rendering-Systeme motiviert die Entwick-lung von Applikationen mit großen Visualisierungskomponenten und funktionsreichen Be-nutzerschnittstellen. Ein Ziel dieser Arbeit ist die Erstellung einer Computational SteereingUmgebung fur CFD-Simulationen.

In den letzten Jahren kann einen rasanten Sprung des Bedarfs solcher Umgebungen be-trachtet werden. Das hat zum Entstehen verschieden Software Produkte fur ComputationalSteering gefuhrt. In [MvWvL98] wird einen Ubersicht solcher Umgebungen vorgestellt. Einigeder bekanntesten Systeme sind Falcon entwickelt vom Georgia Tech, SCIRun vom ScientificComputing and Imaging research group der Universitat von Utah, CUMULVS der Oak RidgeNational Labratory und viele andere Applikation.

3.2 Begriffe der Fluiddynamik

Dieser Kapitel fuhrt die grundlegenden Begriffe notwendig fur die mathematische Beschrei-bung von Stromungen ein. Unter der Bezeichnung Fluid werden Flussigkeiten und gasformigeNaturerscheinungen zusammengefasst. Man unterscheidet zwei Hauptmodelle : das laminare

3.3 Die Navier-Stokes Gleichungen Seite 5

und das turbulente Flussigkeitsmodell. Ein laminarer Fluss besteht aus individuellen Schich-ten, die ubereinander gleiten. In dem turbulenten Modell konnen die Partikel wegen dergeringen Reibungskrafte keinen Schicht aus dem Fluss zugeordnet werden. Eine weitere Un-terteilung der Stromungen ist die in kompressiblen und inkompressiblen Flussen. Bei denkompressiblen konnen Veranderungen in dem Gesamtvolumen auftauchen im Gegensatz zudem inkompressiblen Fall, wo das betrachtete Volumen konstant bleibt. Im Verlauf dieserArbeit werden schweigend inkompressiblen Stromungen vorausgesetzt.

Fur die Beschreibung der Fluiddynamik werden zwei Ansatze benutzt: der Eulerian undder Langrage Ansatz. Der Euler Ansatz fokussiert an bestimmten Punkte in dem Volumen,die von der Stromung besetzt sind. Die Fluideigenschaften werden innerhalb eines stationarenVolumens betrachtet und gemessen. Bei dem Langrange Ansatz werden die Partikel auf de-ren Pfad in der Stromung verfolgt und beobachtet. Es erfolgt eine Aufnahme des Zustandesentlang des Pfades.

Wichtig fur die Beschreibung der Stromung ist die so genannte Reynoldsnummer 3.1 .Hierbei bezeichnet � die Dichte, D die charachteristische Lange des Fluidvolumens, V dieFluidgeschwidigkeit und � die Reibung. Stromungen mit einer Reynoldsnummer unter 2300fallen in der Gruppe der laminaren Flusse. Zwischen 2300 und 4000 befindet sich die Gruppender transienten Stromungen und uber 4000 die Gruppe der turbulenten.

Re = �DV/� (3.1)

3.3 Die Navier-Stokes Gleichungen

Ein grundlegender Konzept fur die mathematische Beschreibung von Stromungen sind diePartiellen Differentialgleichungen von Henri Navier und George Gabriel Stokes (vgl. TheNavier-Stokes Equations [Gri97]).Diese Gleichungen beruhen sich auf drei Hauptprinzipiender Physik: die Masserhaltung, der zweite Newtonsche Gesetz 3.2 (die Beschleunigung einesKorpers ist proportional zu der angewendeten Kraft und inverse-proportional zu der Masse)und die Energieerhaltung.

F = ma (3.2)

Typische Großen der Fluidsimualtion sind die Dichte, die Geschwidigkeit der Partikel undDruck im Zentrum der Zellen. Im Weiteren werden die Gleichungen fur den inkopressiblenFall mit dem Euklidian Ansatz beschrieben.

3.3.1 Die substantielle Ableitung

Ein wichtiger Begriff fur die spatere Ableitung der Gleichungen ist der Begriff der substanti-elle Ableitung. Die beschreibt die zeitliche Anderung bestimmter Fluideigenschaften fur sichbewegende Elemente. Zu beachten ist der Unterschied zu der lokalen Ableitung, die die zeit-liche Veranderung fur einen fixierten Punkt darstellt. Um die Arbeitsweise der substantiellenAbleitung zu demonstrieren, wird im Folgenden die zeitliche Anderung der Dichte bei einerBewegung eines Partikels von Punkt 1 nach Punkt 2 beispielhaft gezeigt. Unter der Annah-me der Kontinuitat der Dichte kann man den Wert auf dem zweiten Punkt durch Taylor


Expansion wie folgt bestimmen:

�2 = �1 +

(∂�

∂x

)1

(x2−x1)+

(∂�

∂y

)1

(y2−y1)+

(∂�

∂z

)1

(z2−z1)+

(∂�

∂t

)1

(t2− t1)+ ... (3.3)

Die substantielle Ableitung der DichteD�

Dtist definiert als:

limt2→t1

�2 − �1t2 − t1

= u∂�

∂x+v

∂�

∂y+w

∂�

∂z+∂�

∂t, mit der Geschwindigkeit V = ui+vj+wk und i, j, k

Einheitsvektoren. Sei ▽ = i∂�

∂x+ j

∂�

∂y+ k

∂�

∂z, dann ist die substantielle Ableitung allgemein

durch die Gleichung 3.4 gegeben.

D

Dt=

∂

∂t+ (▽V ) (3.4)

3.3.2 Das Prinzip der Massenerhaltung

Eines der Hauptprinzipien der Fluiddynamik ist das physikalische Prinzip der Masserhaltung(Gl.3.7). Es besagt, dass im gegebenen Volumen die Masse bei Veranderung der Fluidei-genschaften konstant bleibt, oder in anderen Worter, dass der ausgehender Massenfluss ausGleichung 3.5 gleich die Rate der Massenabnahme(Gl.3.6) innerhalb des Kontrollvolumensseien muss. Bei inkompressiblen Fluiden verschwindet die Ableitung der Dichte gegenuberder Zeit und die Gleichung erhaltet die Form aus 3.8.

Ma =

(∂�u∂x

+∂�v∂y

+∂�w∂z

)dxdydz (3.5)

Mra = −∂�∂tdxdydz (3.6)

∂�

∂t+∂�u∂x

+∂�v∂y

+∂�w∂z

=∂�

∂t+▽(�V ) = 0 (3.7)

▽ V = 0 (3.8)

3.3.3 Der Impulserhaltungssatz

Der zweite physikalische Gesetz ist in der Gleichung 3.2 beschriebene Impulserhaltungssatz.Die linke Seite der Gleichung stellt Summe der externen und der Volumenkrafte dar. Dieexterne Krafte wirken aus Distanz auf alle Elemente der Stromung und besitzen Impuls�f(dxdydz). Typische Beispiele sind die Gravitation, die elektrische und magnetische Kraf-te. Die Volumenkrafte wirken auf die Oberflache der Stromung und werden in Druck- undReibungskrafte unterteilt. Die Druckkrafte werden von Fluid außerhalb des betrachteten Vo-lumens verursacht. Die haben eine Wirkung nach innen und sind normal zu der Flache. DieReibungskrafte fuhren zu Normal- und Schubspannugen.

In Abbildung 3.1 werden die Volumenkrafte in der x Richtung kurz dargestellt. Auf der

Flache 0145 wirkt die Spannung (−�yx)dxdz und auf 2367 (�yx +∂�yx∂y

dy)dxdz. Fur �zx wird

in ahnlicher Art und Weise auf 0246 und auf 1357 dargestellt. Auf der Flache 0123 ist die

Spannung gleich (�xx+∂�xx∂x

dx)dydz und die Druckkrafte gleich −(p+∂p

∂xdx)dydz. Die Ebene

4567 hat Spannung (−�xx)dydz und Druckkrafte (p)dydz. Die gesamten Krafte in x Richtungwerden in Gleichung 3.9 zusammengefasst.

3.3 Die Navier-Stokes Gleichungen Seite 7

Abbildung 3.1: Skizze der wirkenden Volumenkrafte

FV ol = [p− (p+∂p

∂xdx)]dydz + [(�xx +

∂�xx∂x

dx)− �xy]dydz

+[(�yx +∂�yx∂y

dy)− �yx]dxdy

+[(�zx +∂�zx∂z

dz)− �zx]dxdy

Fx = [−∂p∂x

+∂�xx∂x

+∂�yx∂y

+∂�zx∂z

]dxdydz + �fxdxdydz (3.9)

Durch Einsetzen von �dxdydz undDu

Dtfur die Masse und die Beschleunigung in Gleichung

3.2 erhalt man die Impulserhaltungsgleichung 3.10. In viele Domane gibt es Unterschiede inder einzelnen Dimensionen, die zur Instabilitaten bei der Losung fuhren konnen. Deshalb wirdhaufig in der Literatur eine dimensionslose Form der Gleichungen angegeben (3.11 , 3.12).

�(∂u

∂t+ V ▽ u) = −∂p

∂x+∂�xx∂x

+∂�yx∂y

+∂�zx∂z

+ �fx (3.10)

�v

�t=

1

Re▽2 v − V ▽ v + fy −

�p

�y(3.11)

Div(V ) = 0 (3.12)

Hierbei haben die einzelnen Terme die folgende Bedeutung : Der Difusionsterm(1

Re▽2 v)-

beschreibt, wie schnell die Veranderungen der Geschwindigkeiten verschwinden werden(hangt


von der Viskositat des Fluids ab), der Advektionsterm(−V ▽ v)-beschreibt die Richtung, indie das Fluid in u von einem benachbarten Bereich gepuscht wird, die externe Krafte fy und

die Druckkrafte�p

�ydie die Richtung, in die das Fluid in u gepuscht wird, um einen Bereich mit

niedrigen Druck zu erreichen. Fur die Ableitung dieser Form und die ausfuhrliche Erklarungder Navier-Stokes Gleichungen wird es hier auf die Literatur verwiesen.

3.3.4 Randbedingungen

Ein wichtiger Punkt fur die Losung der Navier-Stokes Gleichungen sind die gestellten Rand-bedingungen. Im Weiteren werden nur ein Teil der Bedingungen, die von Bedeutung fur dieseArbeit sind, vorgestellt.

Charakteristisch fur viele Domane ist das Vorhandensein von Wande. Teil davon beschrei-ben die außeren Grenzen der Domain, andere werden fur die Darstellung von statischen undbeweglichen Geometrien benutzt. Durch Spezifikation der Geschwidigkeitskompenenten amRand konnen Haftungsbedingungen festgelegt werden. In der Literatur diese Art von Rand-bedingungen sind bekannt als Dirichlet Randbedingungen. Dabei wird es zwischen no-splipund velocity-inlet Bedingungen unterschieden. Die no-slip Bedingungen legen fest, dass dasFluid sich neben den Rand nicht bewegen muss. Dabei werden die Komponenten der Gesch-widigkeitsvektoren am Rand auf Null gesetzt. Bei der velocity-inlet Bedingungen wird dievollstandige Spezifikation der Vektoren am Einflussbereich gefordert. In anderen Falle sindhaftungsfreie Wande gewunscht(Neumann-Randbedingungen). Hierfur werden alle Geschwin-digkeitskomponenten senkrecht zur Wand auf Null gesetzt.

Weitere Randbedingungen sind die Energierandbedingungen und die periodischen Randbe-dingungen. Die Energierandbedingungen dienen zur Festlegung der Komponenten bestimm-ter Krafte. Die Spezifikation der Druckkrafte an bestimmten Stellen aus dem Domain ist einBeispiel fur so eine Bedingung. Die periodischen Randbedingungen werden verwendet, umendlose Domane zu konstruieren. Dafur werden die Wande ignoriert und deren Zellen alsinnere interpretiert.

3.3.5 Raumliche und zeitliche Diskretisierung

In der Praxis existieren unterschiedlichen Methoden und Kombinationen aus mehreren Ver-fahren fur die Durchfuhrung einer raumlichen und zeitlichen Diskretisierung der Navier-StokesGleichungen. In Peano werden zwei Methoden fur die raumliche Diskretisierung implemen-tiert: die Finite Elementen Methode (vgl. [Lı¿01] ) und die interpolierten Differential Ope-ratoren. Die zweite Methode ist eine Technik hoherer Ordnung zum Losen von PDEs. Einedetaillierte Beschreibung kann in [Aok97], und [Nec09, 51–66] gefunden werden.

Die Finite Elemente Methode(FEM) ist eine weit verbreitetes Verfahren fur das Losen vonPDEs. Die Methode unterteilt die gegebene Domain in finite Nummer von kleineren Elemen-te. Beispiel Reprasentationen solcher Elemente sind Dreiecke, Rechtecke, Tetraeder, Hexaederu.a. . Fur jedes dieser Elementen werden Ansatzfunktionen(Shapefunctions 0) fur die Berech-nung der unbekannten Großen (wie Geschwindigkeit, Druck u.w.) angegeben. Im nachstenSchritt werden die gegeben Gleichungen in eine relaxierte Form gebracht. Die Losung wird

3.4 Das Peano Framework Seite 9

durch Berechnung der Integral1 uber alle Elementen und deren Ansatzfunktionen berechnet.Dieses Verfahren ist sehr gut geeiegnet fur komplexere und dynamische Geometrien und liefertsehr gute Ergebnisse wegen der eingebauten Interpolation in Definition der Shape-Funktionen.

Die Verfahren fur zeitliche Diskretisierung der Navier-Stokes Gleichungen werden in zweiGruppen unterteilt: explizite und implizite Verfahren. Die expliziten Methoden benutzen dasWissen aus dem zuletzt-berechnet Schritt fur die Losung des neuen Schrittes bei der Integra-tion der Differentialgleichung. Die impliziten Verfahren verwenden die Information aus meh-reren Zeitschritten als Unbekannten eines nicht-linearen Gleichungssystems. Eine raumlicheDiskretisierung hoherer Ordnung setzt die Verwendung von genaueren Zeitintegration voraus.Beispiele fur explizite Integrationsverfahren sind das Euler Verfahren und die Runge-KuttaMethoden. Zwei impliziten Verfahren sind die Crank-Nicolson Schema und das NewtonscheVerfahren. Die detaillierte Beschreibung der FEM Methoden geht uber die Grenzen dieserArbeit.

3.4 Das Peano Framework

In diesem Abschnitt werden die grundlegende Funktionalitat und Aufbau des zu erweiterndenPDE Framework Peano vorgestellt. Am Anfang wird die grobe Architektur der Applikationerortert. Im Weiteren werden die unterstutzen Gittertypen und deren Realisierung kurz ein-gefuhrt.

Der Peano Framework ist ein Software Paket, implementiert in C++, geeignet fur das Losenvon verschiedenen Differentialgleichungen. In dem Framework werden unterschiedlichen Pa-radigmen aus der Welt der Software Engineering erfolgreich verwendet. Die Applikation nutztdie positiven Eigenschaften der Objekt-orientierte Programmierung : wie z.B Generalisierung,Abstraktion, Polymorphismus , Information Hidding und andere Techniken. Zusatzlich wer-den zahlreiche Design Schablonen in dem Programmcode integriert und die Korrektheit derwichtigsten Programmteile mit Unit- und Integrationstests sichergestellt.

3.4.1 Architektur

Im Folgenden wird die Architektur von Peano in Abbildung 3.2 dargestellt. Dabei kann dieAufbau der Architektur wie folgt beschrieben werden : die technischen Betriebsmittel fur dasReinlesen der Konfigurationsdateien, die Verifikationskomponenten und die Logging-Utilitieswerden als T-Arch Komponenten bezeichnet. In der Mitte der Abbildung befindet sich der klardefinierten Kern von Peano. Der beinhaltet die Klassen notwendig fur die Traversierung undErzeugung der Gitterdatenstrukturen und die Komponente verantwortlich fur die paralleleAusfurung dieser Traversierungen. In dem oberen dunkelblauren Teil befinden sich die Appli-kationskomponenten. Hier werden die Klassen der eigentlichen Anwedugen wie die Fluid Kom-ponente , Poisson Komponente und andere implementiert. Den unteren hellgraueren Teil der

0Die Ansatzfuktionen sind Interpolationsverfahren linearer oder hoherer Ordnung wie z.B die baryzentrischeInterpolation.

1Typisch bei der Diskretisierung des Integrals wird eine endliche Summe verwendet.


T−

Arc

h

low

mem

stacks

vtk

tecplot

ADOL−C

cppAD

equation

conti−

equation

heat−

grid

trivialgrid

para

llel

plotter

ODE

preCICE

AD

PETSc

fluid poisson

geometry

Abbildung 3.2: Architekturaufbau von Peano

3.4 Das Peano Framework Seite 11

Abbildung zeigt die Extensionskomponenten. In dieser Gruppe fallen die Klassen zum Raus-schreiben von VTK und Tecplot Dateien, die ODE Komponente, die fur die Durchfuhrungvon numerischen Zeitintergration verwendet werden, die Geometrie-Manipulationsklassen undSchnittstellen zum PreCICE1,ADOL-C2 und PETSc3

3.4.2 Gitterstrukturen

Abbildung 3.3: Visualisierung von verschiedenen Gitterreprasentationen der Drift-RachetGeometrie in 3D:(a) regulare kartesische Gitter (b) adaptive kartesische Gitter

Wie bereits erwahnt werden die Stromungsdaten nur an diskreten Messpunkten berech-net und in unterschiedlichen Gitterstrukturen gespeichert. Die einzelnen Gitterarten habenunterschiedliche Charakteristik bezuglich Speicherbedarf, Performanz der Interpolation undGenauigkeit. In Peano werden zwei Arten von Gitter unterstutzt: die regularen kartesischenGitter und die adaptiven kartesischen Gitter. In der Literatur werden noch die unregelmaßigenGitter eingefuhrt.

∙ Regulare kartesische Gitter: Die regularen kartesischen Gitter dargestellt in Abb.3.3sind von Zellen gleicher Große aufgebaut. In Peano werden als Bauelemente Quaderin 2D und Hexaeders in 3D verwendet. Nachteile dieser Gitterart ist der relativ hoheSpeicherbedarf wegen der Tatsache, dass alle Stomunsgbereiche mit der gleichen Genau-igkeit dargestellt sind. Vorteil ist die effiziente Realisierung der Interpolation, die sichanhand von einfachen Index-Operationen implementieren lasst.

1PreCICE : Applikation fur die Simulation komplexerer triangulierten Geometrien.2ADOL-C : Evaluiert erste und hohere Ableitungen von Vektorfunktionen in C++.3PETSc : Externe Bibiliothek zum Losen von Differentialgleichungen.


∙ Unregelmaßige Gitter: Die unregelmaßigen kartesichen Gitter konnen von unterschied-lichen Elementen(Beispielweise konnen Dreiecke) aufgebaut werden. Das ermoglicht diebessere Kompression der Datenmenge. Nachteile der Darstellung sind die hohen Kostenbei der Berechnung Darstellung und der Interpolation der Datensturktur. In diesemFall kann keine lineare Interpolation wegen der komplexeren Anordnung der Elementenverwendet werdet.

∙ Adaptiven kartesischen Gitter Die adaptiven kartesischen Gitter in Peano (Abb.3.3(b))werden durch die so genanneten Spacetrees realisiert. Die Spacetrees sind Verall-gemeinerung der aus der Computer Graphik bekannten Octrees. Bei den letzten werdenbei jedem rekursiven Verfeinerungsschritt k = 2 Kinder in jeder Richtung erzeugt. DieSpacetrees erlauben beliebige Werte fur k. In Peano wird k = 3 benutzt. Das Anstoßender Verfeinerungsoperationen wird anhand der Geometrie oder der Wande gesteuert.Dieses Verfahren gewahrleistet einen hoheren Kompressionsgrad. Das fuhrt zur besse-ren Ausnutzung des Speicherplatzes. Das benutzte Modell liefert ahnliche Ergebnisse zuder AMR(Adaptive mesh refinement)-Ansatze.

3.4.3 Traversierung der Gitterstrukturen

Abbildung 3.4: Traversierung von adaptiven Gitter anhand der Peano-Kurve

In Peano existieren keine globale Pointer-Datenstrukturen, die den Zugriff auf die Gitterin-formation erlauben sollen. Diese Aktion wird anhand von Cache-effizienteren Traversierungs-algorithmen realisiert.

Mit großen Bedeutung fur die Serialisierung der Daten sind die raumfullenden Kurven.Diese Kurven sind Funktionen , die sehr haufig in dem Gebiet der Datenkomprimierungverwendent werden. Eine der Eigenschaften dieser Kurver ist, dass die durch alle gegebenenPunkten aus einem 2d oder 3d Bereich durchgehen konnen (vgl. [Sal07]). Wie der Name desFrameworks verrat wird an der Stelle die selbstahnliche raumfullende Peano-Kurve fur die

3.5 Visualisierung von Stromungsdaten Seite 13

Event Aktion

*createPersistentVertex() diese Aktion wird bei Veranderung des Gitters getriggert

beginTraversal() Start der aktuellen Iteration

touchVertexFirstTime() erste Verwendung einer Zelle in Nachbarschaftzu einem gegebenen Vertex

*createTemoporaryNode() Erstellung eines hangenden Knotens(touchFirst)

enterElement()∣handleElement Alle Vertices der Zelle sind geladen

*loadSubElement() Sprung zur nachsten Verfeinerungsstuffe+ Triggern der Interpolation

*storeSubElement() Sprung zur groberen Verfenerungsstuffe+Triggern der Restringierung

leaveElement die Bearbeitung des Elements undseiner Kinder ist abgeschlossen

touchVertexLastTime() die letzte Zelle im Nachbarschaftzu dem Vertex wurde bearbeitet

*destroyPersistentVertex() diese Aktion wird bei Vergroberung getriggert

*destroyTemoporaryNode() Vernichten eines hangenden Knotens(touchLast)

endTraversal() Ende der aktuellen Iteration

Tabelle 3.1: Beschreibung der Ereignisse und die Ursachen fur die beiden Gitterarten in Peano.Die mit * gekennzeichneten Zeilen sind nur fur adaptiven Gitter definiert.

Implementierung der Gittertraversierung verwendet. Die Abbildung 3.4 zeigt Traversierungmittels der Peano Curve. Dabei werden Stucke der Kurve immer durch das S-Motiv ersetzt,wenn es eine Verfeinerung passiert.

Der Datenaustausch zwischen Gitter und Applikationskomponenten wird anhand des Adapter-Entwurfsmusters realisiert und funktioniert wie folgt : jede Applikationskomponente ver-fugt mit gewissen Anzahl von Adapterklassen. Diese Klassen spezifizieren unterschiedlichenCallback-Funktionen, die auf bestimmte Aufrufe (Events) der Gitterkomponente reagierensollen. In der Tabelle 3.1 werden die moglichen Event-Aktion Paare fur die vorgestelltenGitterstrukturen skizziert. Die mit * gekennzeichneten Events sind nur bei adaptiven Gittervorhanden.Das Event-Adapter Konzept gewahrleistet die strikte Trennung zwischen Gitter und Appli-

kationskomponenten. Zusatzlich wird so die Redundanz der beiden Gitterimplementierungenum wesentlichen verringert.

3.5 Visualisierung von Stromungsdaten

Dieser Abschnitt stellt die Grundlagen der Visualisierung von wissenschaftlichen Daten, so-wie Algorithmen und Methoden aus dem Gebiet der Stromungsvisualisierung im Speziellenvor. Als Erstes werden die Begriffe der wissenschaftlichen Visualisierung und der RenderingPipeline eingefuhrt. Im nachsten Teil des Abschnittes werden die verwendeten Algorithmenfur die Darstellung von Stromungsinformationen erortert.


3.5.1 Wissenschaftliche Visualisierung

Die rasante Steigerung der Rechenleistung in den letzten Jahren ermoglicht fur viele Berei-che die Speicherung von großeren Datenmengen. Die sich erhohende Komplexitat der Datenverlangt die Erforschung neuer Techniken fur die sinnvolle Analyse der Informationen. Diewissenschaftliche Visualisierung bietet moderne Werkzeuge und Modelle als Losung dieserProbleme an. Der Begriff Visualisierung wird in der wissenschaftlichen Arbeit von [B.M87]wie folgt definiert:

“Visualization is a method of computing. It transforms the symbolic into the geometric,enabling researchers to observe their simulations and computations. Visualization offers amethod for seeing the unseen. It enriches the process of scientific discovery and fosters pro-found and unexpected insights. In many fields it is already revolutionizing the way scientistsdo science.”

Es wird zwischen Information- und Wissenschaftlichenvisualisierung unterschieden. Die ers-te stellt verschiedene nicht-raumliche Zusammenhange der Daten dar. Die wissenschaftlicheVisualisierung ist konzipiert fur die Darstellung von Objekten, die innerhalb verschiedenenraumlichen Domanen definiert sind. Die außeren Objekteigenschaften lassen sich direkt vi-sualisieren. Bei der Beschreibung des Verhaltens dagegen, muss zuerst eine intuitiv klareDarstellung gefunden werden.

3.5.2 Das Visualisierungsreferenzmodell

Abbildung 3.5: Das Visualisierungsreferenzmodell nach [Rob94]

Das Visualisierungsreferenzmodell beschreibt eine Sequenz von Bearbeitungsschritte undderen Zusammenhange. Das in Abbildung 3.5 dargestellte Referenzmodell besteht aus einemSource-Prozess zustandig fur die Generierung oder Reinlesen von Rohdaten. In dieser Arbeitwird dieser Prozess durch die Simulation substituiert.

Der Filterprozess wird fur die Selektion und Korrektur der Daten, sowie fur die Abschaffungunwichtiger Informationen verwendet.

Im Kern der Visualisierungspipeline steht das Mapping. In diesem Schritt werden die Datenzur einer abstrakten Visualisierung gemappt. Das Ergebnis dieses Prozesses ist eine Liste


aus geometrischen Primitiven (z.B Linien, Polygone, Dreiecke..). Im Weiteren erfolgt eineIntegration mit anderen Informationen, wie Texturen und Materialeigenschaften.

In dem Rendering Prozess werden die Informationen aus der Szenenbeschreibung zusam-men mit der Kammeraposition und den Lichteigenschaften fur die Generierung eines Framesbenutzt.

Je nach Voraussetzungen existieren Ruckkopplungen vom Benutzer zu den verschiedenenProzessen. In Fallen von Benutzer, die nicht mit der Pipeline und der Simulation vertrautsind, werden die Ruckkopplungsverbindungen abgeschafft.

3.5.3 Die Renderingpipeline

Dieser Kapitel beschaftigt sich mit dem Wurzel der heutigen graphischen Industrie, nam-lich die Renderingpipeline. Die Renderingpipeline hat als Hauptaufgabe die Erstellung von2D Bilder aus gegebenen Kamera Informationen, Objekten in dem dreidimensionalen Raum,Lichtquellen, Texturen und anderen. Dabei wird die Position und die Form der einzelnenObjekten durch ihren Geometrieeigenschaften bestimmt und das Aussehen durch die spezifi-zierten Texturen, Farben und Lichtquellen.

Im Folgenden werden die Phasen der Renderingpipeline erortert. Haufig werden Teile dieserPhasen in der Graphikhardware implementiert. Die Geschwindigkeit der Pipeline wird durchden langsamsten Prozess limitiert. Trotz der Moglichkeit fur parallelen Abarbeitung der ein-zelnen Schritten kann die globale Ausfuhrung erst dann beendet werden, wenn alle Prozesseabgeschlossen sind. Oft wird der langsamste Prozess als Flashenhals der Pipeline bezeichnet.

Abbildung 3.6: Die Renderingpipeline(vgl.[AMH02]) ist in drei konzeptuellen Phasen aufge-teilt : Applikationsphase, Geometrie-Phase und die Rasterungssphase. JedePhase kann selbst auch eine Pipeline sein.

Wie die Abbildung 3.6 zeigt, besteht die Renderingpipeline aus drei konzeptuellen Phasen:die Applikationsphase, die Geometrie-Phase und die Rasterungsphase. Jede Phase kann selb-standig auch als Pipeline betrachtet werden. Im Weiteren wird es zwischen konzeptuellen,funktionalen und Pipeline-Phasen unterschieden. Die funktionalen Phasen mussen spezielleAufgaben losen aber die spezifizieren nicht wie das gemacht werden soll. Die Pipeline-Phasewird gleichzeitig mit allen anderen Pipeline-Phasen ausgefuhrt. Eine Moglichkeit zum Messen


der Geschwindigkeit einer Pipeline sind die gerendenderten Bilder pro Sekunde(Frames persecond-FPS).

Die Applikationsphase wird typischerweise in Software entwickelt. Beispielsweise werdenhier Methoden wie Kollisionsauffindung, Animation, Krafte Bestimmung u.a. implementiert.Die Implementierung in Software erlaubt den leichten Austausch von Komponenten. DiesePhase besteht aus keinen Subprozesse. Eine Moglichkeit fur die schnellere Ausfuhrung istVerwendung von CPU-Parallelisierungsmethoden.

Die Geometrie-Phase wird oft im Gegensatz zu der Applikationsphase in Hardware imple-mentiert. Die beschaftigt sich mit der Transformationen, Projektionen und die Berechnung derBeleuchtung fur die aktuellen Objekte in der 3D-Szene. Am Ende der Phase wird das Ergeb-nis auf Fensterkoordinaten projiziert. Diese Operationen werden per Polygon und per Vertexausgefuhrt. Die Phase besteht aus funf funktionalen Etappen: Modell und View Transforma-tionen, Berechnung der Beleuchtungsmodelle, Projektion, Clipping und Screen Mapping.

∙ Modell und View Transformationen: Diese funktionale Phase hat die Aufgabe, das Mo-dell in verschiedenen Koordinatensystemen umzuwandeln. Ursprunglich befindet sichdas Modell in einem lokalen Koordinatensystem(Modellraum). Durch die Anwendungder Modell-Transformationen wird die Position und die Orientierung gegenuber eineneinheitlichen Koordinatensystem bestimmt. Hier spricht man noch von Weltkoordinatendes Modells.

Abbildung 3.7: View Tranformationen nach [AMH02]. Das linke Bild stellt die Benutzer de-finierte Position und Orientierung der Kamera. Nach der Anwendung derSichtstransformation steht die Kamera im Ursprung des Koordinatensystemsund ist entlang der negativen z-Achse ausgerichtet.

Beim Rendering werden nur von der Kamera sichtbaren Objekten dargestellt. Die Ka-mera besitzt eine Position und Orientierung. Diese Parameter werden fur die Platzierungund das Ausrichten der Kamera verwendet. Fur die Erleichterung der Projektions- undClippingphasen wird die Sicht Transformation angewendet. Die setzt die Kamera imUrsprung des Koordinatensystems und die wird entlang der negativen z-Achse ausge-richtet. Ein Beispiel fur die Durchfuhrung der Transformation wird in Abbildung 3.7dargestellt. Die Modell-Transformationen und die Sicht-Transformationen konnen als


Matrizen reprasentiert werden. In der Praxis wird eine Gesamtmatrix fur die beidenTransformationen aus Effizienzgrunden gebildet.

∙ Beleuchtung: Fur das realistische Aussehen der Modelle wird die Szene um Lichtquellenerweitert. Fur die Bestimmung der Endfarben der Objekte , die vom Licht beeinflusstsind, wird in dieser Phase die Lichtgleichung ausgerechnet. Die so erhaltene Werte wer-den an den Vertices gespeichert. Typischerweise werden die Objekte durch Dreieckereprasentiert. Fur die Berechnung der Farbwerten der anderen Punkten innerhalb desDreiecks wird Interpolation verwendet(Gouraund Shading-[Gou71]).

∙ Projektion: Nach der Berechnung des Beleuchtungsmodells wird eine Projektion desVolumens auf einen Einheitswurfel(canonical view volume) durchgefuhrt. Zwei Artenvon Projektionen werden unterstutzt : die orthographische(parallele Projektion) undPerspektivenprojektion. Die Haupt Charakteristik der orthographischen Projektion istdie Erhaltung der parallelen Linien als solchen nach der Projektion(vgl. Abbildung 3.8).Das Sichtbarkeitsvolumen hat die Form einer rechteckigen Box. Die Projektion wirddurch Translation und Skalierung erhalten. Bei der Perspektivenprojektion werden die

Abbildung 3.8: Links-orthographische Projektion,Rechts-Perspektivenprojektion

einzelnen Objekten je nach Entfernung von der Kamera kleiner erscheinen. Das Sich-barkeitsvolumen ist eine abgeschnittene Pyramide mit rechteckigen Basis. Diese Trans-formationen konnen auch durch 4x4 Matrizen dargestellt werden.

∙ Clipping: In dieser Phase werden die Objekte, die außerhalb des berechneten Sicht-barkeitsvolumens liegen, nicht weiter betrachtet. Die Objekte, die nur teilweise in demVolumen liegen, werden abgeschnitten.

∙ Screen Mapping: Die letzte Phase ist verantwortlich fur die Umwandlung der 3D-Koordinatender Objekten nach der Beendigung des Clippings in 2D-Screen Koordinaten. Die ScreenKoordinaten zusammen mit den z-Werten der Objekten werden auch Fensterkoordina-ten genannt. Die Transformation zur Fensterkoordinaten besteht aus eine Translationund Skalierung. Die z-Werten bleiben unberucksichtigt in dieser Phase.

Die Rasterungsphase kriegt als Eingabe die transformierten und projektierten Vertices derObjekten plus die Farben und die Texturen. Die Hauptaufgabe der Phase besteht darin, denrichtigen Farbwert fur einen Pixel zu bestimmen. Der Prozess wird noch Scan Conversiongenannt. Die 2D-Screen Koordinaten werden eine bis zu zwei Farben oder Texturkoordinaten


zugeordnet. Die Operationen werden hier im Unterschied zu der per Vertex und per PolygonOperationen der Geometrie-Phase per Pixel durchgefuhrt. Die Information fur jeden Pixelwird in einem Color-Puffer gespeichert.

Andere Aufgabe der Rasterung ist die Behandlung der Sichtbarkeit. Beim Rendering derSzene muss den Color-Puffer nur mit Werten der sichtbaren Objekten belegt sein. Eine klas-sische Losung dieses Problems auf dem heutigen Hardware ist das Z-Puffer Algorithmus. DerZ-Puffer hat die gleiche Große als der Color-Puffer. Er speichert fur jeden Pixel den Z-Wertder Geometrie, die am nachsten liegt. Bei Rendering eines Objektes wird sein Z-Wert mitdem aktuellen Wert des Puffers verglichen. Ist der Wert kleiner, dann handelt es sich umeine Geometrie die naher zu der Kamera als das Objekt, was vorher am nachsten war, ist.In diesem Fall mussen den Z-Puffer und den Color-Puffer aktualisiert werden. Ist der Z-Wertgroßer als der Wert in den Z-Puffer, dann bleibt den Puffer erhalten. Dieses Algorithmusist ziemlich einfach und effizient. Es funktioniert fur beliebigen Sortierung der Objekten beinicht transparenten Korper. Bei der Verwendung von Alpha-Werte muss das Rendering dertransparenten Objekten nach dem Rendering der undurchsichtigen passieren und die mussenin einem Back-To-Front Art und Weise sortiert werden.

3.5.4 Grundlagen der Stromungsvisualisierung

In der Literatur werden zahlreiche Techniken fur die sinnvolle Darstellung der Stromungs-daten vorgestellt. Die unterscheiden sich nach der Art der Input-Daten und werden in zweiGruppen unterteilt: Algorithmen fur die Darstellung von Eigenschaften der Skalardaten undVisualiserungsalgorithemen fur Vektorfelder. Die Vektordaten lassen sich leicht zu Skalarda-ten0 umwandeln und so konnen auch die Techniken fur die Darstellung der Skalaren verwendetwerden.

3.5.5 Skalar-Visualisierungsalgorithmen

∙ Color Mapping: Eine zentrale Technik fur die Abbildung von Skalarwerten auf Far-ben ist das Color Mapping. In diesem Verfahren werden die moglichen Farben in einerLookup-Tabelle gespeichert. Diese Tabelle ist direkt mit der Abgrenzung der Skalarda-ten gekoppelt. Der Skalarwert wird als Index fur das Lookup verwendet.

∙ Konturfindung: Eine Erweiterung des Color Mappings ist das Verfahren fur Konturen-generierung. Durch das Anwenden von Color Mapping werden Ahlichkeistsbereiche inden Volumendaten deutlich. Der Prozess der Erzeugung der Grenzen zwischen diesenBereichen ist bekannt als Konturengenerierung.

Die Konturlinien sind die Linien, die aus Punkten der betrachteten Domain mit dengleichen Datenwert bestehen. Formal werden die durch die Funktion 3.13 beschrieben.Diese Funktion ordnet jedem Punkt aus der Domain einen Wert zu. Die Erzeugung derKonturlinien beginnt mit der Eingabe des Konturwertes. Wegen der Diskretisierung der

0Beispielsweise kann an der Stelle den Betrag des Vektors berechnet werden oder bestimmte Vektorkompo-nente ausgewalt werden.


Domain muss die Position der Linie interpoliert werden. Im Weiteren werden zwei Ver-fahren fur die Verbindung der Gefundenen Konturpunkten vorgestellt: Curve SequnceContouring und Grid Sequence Contouring.

f(x, y) = const (3.13)

Die Konturfindung in Kurvenfolge (Curve Sequence Contouring) funktioniert wiefolgt: Im ersten Schritt werden einen Schnittpunkt zwischen der Konturlinie und denKanten der Zelle bestimmt. Nachfolgend wird die Kurve in den Nachbarnzellen ver-folgt. Dieser Prozess wird bis zum Erreichen des Anfangpunktes oder der Gittergrenzenweiterverfolgt.

Bei der Konturfindung in Gitterfolge (Grid Sequence Contouring) wird es uber dieZellen des Gitters iteriert, um die Konturkurven zu bestimmen. Ein solches Verfahrenist das Marching Squares Algoritmus. Es nutzt den Fakt, dass es fur eine Konturlinieendlich viele moglichen Durchgange uber eine Zelle existieren. Das Verfahren verwendeteine Fallunterscheidungstabelle mit den moglichen topologischen Relationen fur die ein-zelnen Vertices. Es wird zwischen innere und außere Vertices unterschieden. Vertices mitSkalarwerten kleiner als der Konturwert werden als außere bezeichnet. Die Große derTabelle ist abhangig von der Anzahl der Vertices. In 2D gibt es insgesamt 24 Eintrage. In Abbildung 3.9 werden die moglichen Falle durchgelistet. Das Algorithmus geht fol-

Abbildung 3.9: Die 24 Marching Squeres Falle fur 2D :die dunklen Punkten bezeichnen Ver-tices mit Skalarwert uber den Konturwert (vgl. [SML04] )

gendermaßen vor: am Anfang wird der Index fur die aktuelle Zelle als die Bitsequenz derVertices gebildet. Jedes Bit stellt den Zustand des Vertex dar(innen oder außen). Der soerstellte Index wird fur den Look-Up in der Fallunterscheidungstabelle benutzt. Fur denausgewahlten topologischen Fall wird die Konturposition durch Interpolation berechnet.Das Verfahren generiert unabhangigen geometrischen Primitiven fur jede Zelle. So kannes passieren, dass bestimmte Punkte am Rand dupliziert sind. Diese Redundanz wirddurch Point-Merging eliminiert. In 3D wird analog zum Marching Squares Ansatz dasMarching Cubes mit 28 Falle benutzt.


Die so vorgestellten Algorithmen fur Konturfindung leiden an das Problem der Mehr-deutigkeit verschiedener Falle(wie z.B Fall 5 und 10 fur Marching Squares und dieFalle 3,6,7,10,12 und 13 fur Marching Cubes). Solche Falle konnen leicht durch dieBestimmung der Zellen mit benachbarten Vertices mit unterschiedlichen Werten undden gleichen Werten an den Diagonalen ,identifiziert werden. In 2D sind die unabhan-gig von einander und konnen wirkurlich kombiniert werden. Eine bessere Methode istdie adaptive Unterteilung solcher Zellen anhand von St.Andrews-Zellen(laut [SM00]).Wie die Abbildung 3.10 zeigt, konnen die Kombinationen der mehrdeutigen Falle in3D zu unerwunschten Ergebnissen fuhren. Es existieren unterschiedliche Methoden zurLosung dieses Problems. Eine davon ist das in [GH95] beschriebene Verfahren MarchingTetrahedra.

Abbildung 3.10: Zufalliger Auswahl von mehrdeutigen Fallen kann zur Erzeugung von Locherin der ISO-Flachen fuhren.

∙ Schnittebenen: Ein weiteres Prinzip fur die Darstellung von Skalardaten in einem Stro-mungsfeld ist das Prinzip der Cutting-Slices. Dieses Vorgehensmodell kann man wiefolgt beschreiben: eine implizit beschriebene Ebene wird in dem gegeben Volumen ein-gefugt. Anhand ihrer Beschreibung wird eine Flache aus dem Volumen abgeschnitten.Die so erhaltene Ebene und die Information darauf wird mittels Color Mapping undKonturengenerierung visualisiert.

∙ Volumerendering: Eine andere Technik benutzt fur die Visualisierung globaler Eigen-schaften des Stromungfeldes ist das Volumerendering. Das Fluid wird anhand eines teil-transparentes Volumen dargestellt. Typischerweise werden Schwellenwerte eingefuhrt,um interessante Bereiche aus der Datenmenge zu indentifizieren. Die Verfahren fur Vo-lumerendering werden in zwei Gruppen unterteilt : Image Order und Object OrderAlgorithmen.

Das Image-Order Volumerendering wird oft als Ray-Casting bezeichnet. Es werdenStrahle uber alle Pixel abhangig von der aktuellen Kameraposition gesendet. Die Wer-


(a) Pfeildarstellung (b) Stromlinien (c) Stromflachen

Abbildung 3.11: Visualisierungstechniken fur Vektorfelder vgl. [SML04]

ten auf dem Weg werden anhand einer speziellen Funktion (die Ray-Funktion) auf ak-kumuliert und so wird den neuen Wert des Pixels berechnet. Typische Beispiele furRay-Funktionen sind die Maximum-Intensity Projektion, Avarage-Intesity Projektion,die Distanz Funktion und andere komplexere Funktionen und Kombinationen davon.Die Anwendung dieses Verfahrens wird in Abbildung 3.13(c) illustriert

Die Object Order-Algorithmen funktionieren in ahnlicher Art und Weise. Die kleins-ten Traversierungselementen sind die Voxels. Je nach gewunschten Ergebnissen mussdie Richtung der Traversierung(back-to-front oder front-to-back ) spezifiziert werden.

3.5.6 Visualisierungstechniken fur Vektorfelder

Die Verfahren fur die Visualisierung von Vektorfelder werden in drei Gruppen angeordnet :die elementare, die lokale und die globale Methoden.

Die elementaren Verfahren stellen die Eigenschaften ausgewahlten Punkten dar. Einige derbekanntesten Ansatze sind die Pfeildarstellung, die Liniendarstellungsalgorithmen(Stromlinien,Bahnlinien, Streichlinien u.a.), Stromflachen u.w.

∙ Die Pfeildarstellung: Bei dieser Methoden werden die Richtungen und die Betrage derVektoren fur jeden Punkt des Gitters anhand von einfachen Pfeilen dargestellt. Die Be-trage werden an der Stelle mittels der Große der Pfeilen reprasentiert. Vorteile dieserDarstellung ist die einfache Realisierung und die intuitive Form. Nachteil des Verfahrensist Abhangigkeit der Genauigkeit von der Anzahl der Gitterpunkten und die Mehrdeutig-keit der Reprasentation. Die Abbildung 3.11(a) zeigt Beispielanwedung dieser Methode.

∙ Linienalgorithmen: unter diese Gruppe werden die Verfahren zusammengefasst, die dieBahnlinie eines Partikels anhand von elementaren Operationen darstellen.

Die Stromlinien zeigen die Bahn ausgewahlter Partikel zur einem festen Zeitpunkt.Nach Definition muss jeder Punkt aus der Kurve tangential zu dem gegeben Geschwi-digkeitsvektor sein. Die Berechnung der Linie beruht sich auf dem Prinzip der Zeitani-mation von einem sich bewegenden Partikel. Aus der Definition der Geschwindigkeit in


3.14 kann die Absetzung des Partikels 3.15 abgeleitet werden. Um die Gleichung 3.15zu Losen wird eine andere Form 3.16, die die Geliche Losung besitzt, verwendet. DieKurve, die diese Losung erfuhlt, wird als Stromlinie bezeichnet. Eine Beispieldarstellungder Stromlinie wird in Abbildung 3.11(b) vorgestellt.

−→V =

dx

dt(3.14)

dx =−→V dt (3.15)

−→x (t) =

∫t

−→V dt (3.16)

Fur die letzte Gleichung existieren keine analytische Losungen, deshalb wird die mittelsnumerischen Integration approximiert. Eine einfache Methode fur numerische Integra-tion ist die Euler Methode. Fur die letzte Gleichung sieht den Euler Schritt wie folgtaus:

−→x i+1 = −→x i +−→V iΔt (3.17)

Die neue Position des Partikels wird anhand der alten Position und der momentanenGeschwindigkeit berechnet. Durch Verwendung von Verfahren hoherer Ordnung kannunter Umstande die numerische Fehler verkleinert werden. Beispielsweise kann die Fehlerdurch Anwendung der Runge-Kutta der zweiten Ordnung von O(t2) auf O(t3) verringertwerden. Die Anwendung von Runge-Kutta wird in Gleichung 3.18 beschrieben. Hierbei

wird die Geschwindigkeit−→V i+1 durch Euler Integration berechnet.

−→x i+1 = −→x i +Δt

2(−→V i +

−→V i+1) (3.18)

∙ Bahnlinien: Diese Technik stellt die Bewegung ausgewahlter Partikel uber mehrerenZeitschritten. In einem stationaren Stromungsfeld sind die Bahnlinien und die Stromli-nien gleich.

∙ Steichlinien(Streaklines): Die Streichlinien sind die Menge der Partikelspuren zur be-stimmten Zeitpunkt, die in einem vergangenen Zeitpunkt uber gegebenen Punkt passierthaben.

∙ Stromflachen: Eine Erweiterung der Stromlinien sind die Stromflachen. An der Stelle vonden Linien Primitiven werden komplexere Oberflachen benutzt. Immer noch mussen dieFlachen tangential zu dem Stromungsfeld sein. Beispielsweise wird in Abbildung 3.11(c)eine Rohre als Geometrie verwendet.

Es existieren noch weitere einfache Ansatze (wie z.B Zeitlinien, Partikelspuren undweitere) fur die Visualisierung von Stromungsfelder. Eine ausfuhrliche Beschreibung derMethoden wird in [SM00, 318–326] angegeben

Bei den lokalen Verfahren werden Informationen aus der Nachbarschaft der ausgewahltenPunkten in der Rechnung aufgenommen. Zwei der wichtigsten Verfahren sind die Darstellungvon kritischen Punkten und von Flußbander.


∙ Darstellung von kritischen Punkten: Nach Definition ist ein Punkt P ∈ E3 mit E3 denEuklidischen Raum ein kritischer Punkt , wenn V (P ) der Nullvektor ist. Das Verhaltender Stromlinien neben den kritischen Punkten ist eine interessante Fragestellung derFluiddynamik. Durch Auswertung der partiellen Ableitung des Stromungsfeldes lasstsich dieses Verhalten analysieren. Anhand dieser Information kann die Stromung um denkritischen Punkten wie folgt klassifiziert werden : laut [HH91] definieren die Eigenwerteder Jakobimatrix bestimmte Verhaltungsmusster der Tangentenkurven mit Anfangs-punkt gleich den kritischen Punkt. Den Realteil der Eigenwerte bestimmt, ob die Kurveabgestoßen oder angezogen wird und den imaginaren Teil beschreibt eine Rotation umden kritischen Punkt. Die Klassifikkationsmuster fur 2D werden in der Abbildung 3.12zusammengefasst. Eine Erweiterung der Methode fur 3D wird in [CPC90] vorgestellt.

Abbildung 3.12: Klassifikation von kritischen Punkten nach [HH91]

∙ Flußbander(Flow Ribbons): Eine andere Erweiterung der Stromlinien-Darstellung bie-ten die Flußbander an. Vorteil dieses Verfahrens ist die Integration lokaler Informationfur die Stromung als Rotation und Divergenz des Vektorfeldes.

Eine einfache Moglichkeit fur die Konstruktion der Ribbons wird durch Verbindenzweier Stromlinien mit triangulierten Flachen(Band) angegeben. Die Flußbander be-schaffen zusatzliche Information fur die Verwirbelung des Stromungfeldes. Die Verwir-belung(vorticity) −→! ist eine Vektorgroße, die die Geschwindigkeit der Rotation des Vek-torfeldes darstellt. Die

”streamwise“ Verwirbelung ist die Rotation des Vektorfeldes um

eine Stromlinie(Projektion der Verwirbelung auf dem aktuellen Geschwidigkeitsvektor)und wird in Gleichung 3.19 definiert.

Ω =−→v .−→!∣−→v ∣∣−→! ∣

(3.19)

Im Weiteren lasst sich das Wissen fur die Divergenz des Vektorfeldes gewinnen. DiesesWissen wird anhand der Breite des Bandes reprasentiert. In Abbildung 3.13(a) wirddiese Technik vorgestellt.


(a) Flußbander (b) LIC in einem zirkularen Sce-nario aus [CL93]

(c) Volume Rendering

Abbildung 3.13: Visualisierung von Vektorfelder mit lokalen und globalen Methode vgl.[SML04]

Durch Benutzung der globalen Visualisierungstechniken werden Informationen fur die Ge-samtstruktur des Stromungsfeldes gewonnen. Ein Beispielansatz aus dieser Gruppe ist dieLinienintegralfaltung.

∙ Linienintegralfaltung(Line Integral Convolution-LIC): Diese Methode wurde erst vonCabral und Leedom eingefuhrt (vgl. [CL93]). Die grobe Vorgehensweise kann wie folgtbeschrieben werden : das Algorithmus fangt mit zwei Input Texturen an - eine wirkurlichgenerierte Textur(Rauschentextur) und eine mit den Eigenschaften des Vektorfeldes.Die beiden Eingabeparameter werden kombiniert und das Ergebnis wird als Kernelfur die Lineintegrationfaltung verwendet. Die Ausgabe stellt die globale Struktur desStromungfeldes dar (Abb.3.13(b)).

Die so vorgestellten Methoden ermoglichen die komplexere Analyse der Stromungsdaten.Durch deren Anwedung konnen spezifische Eigenschaften der Stromung entdeckt werden. Eineweiterfuhrende Ubersicht komplexerer Verfahren wird in [SM00] vorgestellt.

3.6 Parallelisierung

Die Parallelisierung ist allgemeine Strategie fur die schnellere Ausfuhrung komplexeren Auf-gaben aus dem Bereich des wissenschaftlichen Rechnens. Solche Aufgaben konnen seriell odergleichzeitig berechnet werden. Bei der gleichzeitigen Berechnung redet man von parallel aus-gefuhrten Tasks. In so eine Ausfuhrung werden mehrere Rechner oder Prozesse benutzt, umein gemeinsames Problem zu losen.

3.6.1 Einteilung zu den parallelen Rechenarchitekturen

Als Grundlage der Einteilung der parallelen Rechenarchitekturen wird das Modell von [Fly72]verwendet. In diesem Modell werden die einzelnen Architekturen nach Daten- und Instrukti-onsstromen unterschieden. Mit dem Begriff Strom werden Sequenzen von Instruktionen oderDaten bezeichnet. Dabei werden vier Architekturtypen spezifiziert (vgl. 3.14).

3.6 Parallelisierung Seite 25

Abbildung 3.14: Klassifikation nach Flynn

∙ Single Instruction Single Data(SISD): diese Gruppe fasst die konventionellen von Neu-mann Architekturen zusammen. Dabei verfugt jeden Prozessor mit einem Strom vonInstruktionen und einen von Daten. Befehle werden sequentiell abgearbeitet. HeutigeSISD-Systeme erlauben die Uberlappung von Befehle mittels Pipelining.

∙ Single Instruction Multiple Data(SIMD): Die Architektur dieser Gruppe besteht ausmehreren Prozessoren, die mit einander verbunden sind und mit einer gemeinsamenSteuereinheit verfugen. Die Steuereinheit transportiert die gleichen Befehle zu allenProzessoren. Jeder Prozessor arbeitet auf Daten aus dem eigenen Speicher. Erst nachder Ausfuhrung des aktuellen Befehl auf allen Beteiligten wird die nachste Instruktiongeholt. Man spricht von

”lock-steppped“ oder synchrone Ausfuhrung.

∙ Multiple Instruction single Data (MISD): Die MISD-Architekturen haben mehrere Pro-zessoreinheiten. Die fuhren unabhangigen Instruktionen auf den gleichen Daten aus. Esbestehen zwei Moglichkeiten fur die Verteilung der Daten zwischen den Prozessoren: dieDaten werden auf alle Beteiligten kopiert und jeder fuhrt seine Instruktionen darauf ausoder die Ergebnisse der Bearbeitung eines Prozessors werden als Inputdaten fur einenanderen benutzt und so wird eine Pipeline von Prozessoren gebildet.

∙ Multiple instrunction multiple Data (MIMD): Ein MIMD-Architekturen besitzen mehre-ren verbundenen Prozessoren. Jeder Prozessor verfugt uber eigene Steuereinheit und ar-beitet auf seinen eigenen Daten. Die einzelnen Ausfuhrungen sind voneinander unabhan-gig oder asynchron. Je nach Speicherorganisataion werden die MIMD-Architekturen inSystemen mit Shared oder verteilten Speicherverwaltung weiter eingeteilt. Diese Grup-pierung wird Abbildung 3.15 gezeigt.

Unter der Gruppe der Prozessen mit gemeinsamen Speicher fallen die SMP-Architekturen(Symteric Multi-Processing), die NAMP-Architekturen(None-uniform Memory Access) undDSM-Architekturen(Distributed Shared Memory).


Abbildung 3.15: Aufteilung der MIMD-Architekturen nach Speicherverwaltung

Die SMP-Systeme verfugen uber gemeinsamen physikalischen Speicher. Die Zugriffszeitenauf den Speicher sind fur alle Recheneinheiten gleich. Die Systeme aus der Gruppe der NUMA-Architekturen besitzen auch einen gemeinsamen Speicher aber die Zugriffszeiten darauf sindunterschiedlich(nicht uniform). In DSM wird den Speicher zwischen den einzelnen Prozessorenverteilt. Den Zugriff darauf wird auf Systemebene abstrahiert. Das schafft die Illusion fur einengemeinsamen Speicher fur alle beteiligten Prozessoren.

Die verteilten Speicherarchitekturen werden bzg. der Netzverbindung in den folgenden dreiGruppen unterteilt:

∙ Fixierte Speichersysteme: Bei den fixierten Speichersystemen ist die Anzahl der Verbin-dungen festgelegt und bleibt konstant nach Einfugen von neuen Prozessoren.

∙ Lineare Speichersysteme: In diesen Systemen wachst die Anzahl der Verbindungen linearmit dem Zuwachs der Anzahl der Knoten.

∙ Skalierbare Speichersysteme: In den skalierbaren Systemen kann das Wachstum derAnzahl der Verdingen mit der Funktion P logP abgeschatzt werden. Hierbei sei P dieAnzahl der Prozessoren.

3.6.2 Parallelisierungsstrategien

Bei der Parallelisierung verschiedenen Aufgaben wird zwischen zwei Hauptvorgehensweisenunterschieden: die funktionale und die Domain Dekomposition.

Die funktionale Dekomposition zerlegt die Aufgabe in kleineren Teilchen, die parallel aus-gefuhrt werden konnen. Diese Dekomposition wird haufig fur Aufgaben aus dem Gebiet derMultidisziplin Design Optimierung benutzt. Solche Aufgaben beinhalten Probleme aus ver-schiedenen physikalischen Disziplinen, die in unabhangigen Tasks aufgeteilt werden konnen.

3.7 Computational Steering Seite 27

Die Domain Dekomposition zerlegt und verteilt die Daten zwischen den einzelnen Prozes-sen. Die Prozesse arbeiten dann auf diese Daten mit ahnlichen Instruktionen. Die Dekompos-tion findet auf Problemebene statt im Unterschied zu der SIMD Architekturen, wo die aufloop-Ebene stattfindet. Typisch fur diese Dekompostion ist die Master-Slave Unterteilung dervorhandenen Prozessoren. Dabei wird ein Prozess als Master ausgewahlt. Der ist zustandigfur das Aufsammeln und Zusammenstellen der Daten, die von den anderen Slave-Prozessengeneriert werden. Fur den Austausch von Daten zwischen den einzelnen Beteiligten werdenspezielle Kommunikationsparadigmen wie Nachrichten Austausch benutzt.

Es existieren zahlreiche Grunde fur den Auswahl von parallelen Methoden und Systeme ge-genuber serielle Rechensysteme. Die letzten besitzen eine limitierte Menge von Arbeitsspeicherund die werden zusatzlich von den Gegebenheiten ihres Prozessors begrenzt. Durch parallelesRechnen konnen komplexere Probleme, die durch die Nachteilen der seriellen Systeme limi-tiert sind, gelost werden. Außerdem werden die Losungen solcher Probleme in kurzeren Zeitenberechnet.

3.7 Computational Steering

Dieser Abschnitt behandelt die Grundlagen des Computational Steerings . Am Anfang wirdkurz die Begrifflichkeit und die grundlegenden Eigenschaften eines Steering Frameworks ein-gefuhrt. Als nachstes erfolgt die Beschreibung der Eigenschaften einer Steering-Umgebungund der einzelnen Operierungsphasen so einer Umgebung.

Die herkomlichen Methoden zur Uberwachung durch Ausgabe anhand von Programman-weisungen und die Batch-Analyse der Ergebnissdateien des Simulationslaufes zeigen sich alsunpraktikabel bei dem heutigen Simulationsapplikationen, die auf Hochleistungsgridarchitek-turen ausgefuhrt werden sollen. Die Steigung der Rechenleistung(Einfuhrung der Multicore-Prozessor Architekturen in dem Gridcomputing) erhoht den Bedarf von neuen Techniken furInteraktion und Uberwachung der laufenden Simulationen. Durch diese Entwicklung hat sichdie Bedeutung der Computation Steering fur das Gebiet des wissenschaftlichen Rechnen wei-ter erhoht. In dem Artikel von [MvWvL98] wird das Begriff Computational Steering wie folgtdefiniert:

“Computational steering can be defined as the interactive control over a computationalprocess during execution. In an interactive computational process, a sequence of specifica-tion, computation, and analysis is performed. For each adaption that is to be made to thecomputational model, this process has to repeated. Computational steering closes the loopsuch that scientists can respond to results as they occur by interactively manipulating theinput parameters. Computational steering enhances productivity by greatly reducing the timebetween changes to parameters and the viewing of the results , it enables the user to explorea what-if analysis, and as changes in parameters become more instantaneous, the cause-effectrelationships become more evident.“

Drei Arten von Steering werden unterschieden: die Modellexploration, die Veranderung undAuswahl bestimmten algorithmischen Vorgange der Simulation(Algorithmusexploration) unddie Optimierung der Simulation bzg. Performanz.


∙ Modellexploration: die Modellexploration erlaubt die online Untersuchung des Param-terraumes der Simulation durch geeigneter Uberwachungs- und Steurungstechniken. DerBenutzer ist in der Lage bestimme Parameter zu betrachten und zu modifizieren. Bei derAusfuhrung dieser Aufgaben wird er typischerweise durch eine graphische Oberflacheunterstutzt.

∙ Algorithmusexploration: Dieser Einsatzbereich stellt die Moglichkeit dar, das Verhaltender Simulation durch Veranderung oder Auswahl der benutzten Algorithmen im Laufzeitder Simulation zu beeinflussen. Ein Beispiel fur Algorithmenexploartion ist den Auswahldes numerischen Verfahren zum Losen eines Problems.

∙ Performanzoptimierung: Das Steering kann fur die Steigerung der Effizienz der Simula-tion verwendet werden. Beispiele dafur sind die interaktive Lastbalansierung und Steue-rung der Verfeinerungsdatensturkturen wie Octrees .

Die Hauptkomponenten einer Steering Umgebung sind die graphische Oberflache, die Si-mulationsapplikation und die Artefakte notwendig fur die Kommunikation und die Daten-ubertragung zwischen den beiden. In Abbildung 3.16 wird die Aufbau des Steering Prozessdargestellt. Die Computation Steering Umgebungen operieren in drei Phasen:

∙ Die Instrumentierungsphase: in dieser Phase wird das Applikationskode um Synchroni-sationselementen erweitert. Verschiedene Parameter werden fur Uberwachung und furSteuerung registriert.

∙ Die Uberwachungsphase: Die Uberwachungsphase beschreibt den Prozess von Sammelnverschiedener Informationen aus der laufenden Applikation. Durch zusatzliche Analyseder Daten lasst sich Wissen fur das Verhalten der Simulation gewinnen.

∙ Die Modifikationsphase: Mit Hilfe der Informationen aus der Uberwachungsphase unddie vorhandenen Schnittstellen fur Durchfuhrung von Veranderung bestimmten Para-meter wird die Exploration des Systems gesteuert.

Abbildung 3.16: Der Steering Prozess

3.8 Verwendete Bibliotheken Seite 29

Die Interaktion ist ein wichtiger Teil des Computational Steerings, deshalb spielt die gra-phische Oberflache eine zentrale Rolle in dem Steering Prozess. Die ist zustandig fur dieDarstellung der uberwachten Parameter sowie fur die Behandlung der Steering Kommandosdes Benutzers. Die beobachteten Parameter werden durch einfachen GUI-Elementen (z.B.Knopfe, Scrollbars, Textfelder und weitere ) oder durch komplexere 3D Widgets dargestellt.

Die Komponente fur Kommunkation und Datenubertragung hat die Aufgabe verschiede-ner Daten zwischen der Simulationsapplikation und der Benutzerschnittstelle zu transportie-ren. Die verschieden Komponenten konnen uber das Netz verteilt werden. Deshalb muss dieKomponente zusatzlich alle beteiligten Prozesse kennen und deren Kommunikationsvorgangsteuern.

3.8 Verwendete Bibliotheken

In diesem Abschnitt werden die externen Bibliotheken, die im Laufe dieser Arbeit verwendetwerden, kurz vorgestellt.

∙ Visualization Toolkit: Das Visualization Toolkit ist eine Open Source Bibliothek, ent-wickelt von der Firma Kitware. In der Bibliothek werden unterschiedlichen Methodenfur die Visualisierung von Daten angeboten. Durch die Objekt-Orientierte Gestaltungder Algorithmen und die Verwendung der Programmierspache C++ wird den leichterenund schnelleren Umgang mit dem Software gewahrleistet.

Im Rahmen dieser Arbeit werden einigen der angebotenen Methoden fur die Darstel-lung von CFD-Daten benutzt. Eine ausfuhrliche Beschreibung dieser Methoden wird indem Buch [SML04] durchgefuhrt.

∙ Boost-Serialization: Fur die Kommunikation verschiedener Prozessen wird oft das Ver-schicken von komplexeren Daten und Datenstrukturen benotigt. Im Weiteren wird dieBoost Bibliothek und ihre Serialiserungskomponenten fur die Umwandlung der C++Datenstrukturen in Bytesequenzen verwendet.

∙ QT Framework und IDE: Ein wichtiger Teil einer Steering-Applikation ist die Benutzer-schnittstelle. Hierfur wird das umfangreiche UI Framework QT verwendet. Die einzelnenKomponenten fur die Steuerung der Simulation und der Visualisierung werden anhandvon den QT UI-Bedienelement implementiert. Zusatzlich wird die Moglichkeit zum Ein-betten von VTK-Kontext durch den qVTKWidgetPlugin innerhalb der User Interfaceausgenutzt. Fur die Entwicklung der graphischen Oberflache wurde das QT-CreatorIDE eingesetzt.

∙ Mpich2: Mpich2 ist eine Implemetierung der MPI(Message Passingng interface). DoeBibliothek wird von vielen Applikation bei einer parallelen Ausfuhrung fur die Kommu-nikationsverwalung zwischen den einzelnen Prozessen verwendet. Es werden der MPI1und MPI2 Standarte implementiert. Die Bibliothek wird fur die Parallelisierung derSimulation und der Visualisierung verwendet.

Seite 30 4 Anforderungen

4 Anforderungen

Dieser Abschnitt beschaftigt sich mit den gestellten Anforderungen an das aktuelle SteeringFramework. Um die tagliche Arbeit des Wissenschaftlers zu erleichtern muss ein modernesSystem mit den folgenden Aufgaben auseinandersetzen: eine Online-Darstellung der aus derSimulation berechneten Daten, sowie die interaktive Steuerung des Prozesses.

Im Weiteren werden die gestellten Anforderungen in drei Gruppen eingeteilt: Anforderun-gen an die Simulation, an die Kommunikation zwischen der Simulationskomponente und derSteering Interface und an die User Interface.

4.1 Simulationsanforderungen

Ein Teil eines Steering-Frameworks ist die Simulationsapplikation. Die hat die Aufgaben einbestimmtes physikalisches Phanomen zu modellieren und anhand dieses Modells eine Simu-lation zu einem bestimmten Szenario durchzufuhren. Die Simulation kann sowohl als eigen-standiger Prozess als auch eine parallele Multiprozess-Applikation implementiert sein.

Um die modulare Struktur der Simulation zu erhalten und die zukunftigen Anderungen inder Applikation zu erleichtern wird einen moglichst großen Unabhangigkeitsgrad des SteeringFrameworks (die Applikation und die Benutzerschnittstelle) vorausgesetzt. Eine Verteilung derbeiden Komponenten auf einem Netzwerk ist nicht ausgeschlossen und muss mitberucksichtigtwerden.

Aus den oberen Punkten resultieren die folgenden allgemeinen Anforderungen fur die Si-mulationskomponente:

∙ Uberwachungsanforderungen: Die Uberwachung einer Applikation stellt eine Sicht desProgrammsverhaltens dar. Durch Modellexploration kann zusatzliche Information furdas Verhalten des Systems wahrend der Ausfuhrung gewonnen werden.

Eine Laufzeit fahige Betrachtung des Parametersraumes wird den Umgang des Wis-senschaftlers mit der Simulation erleichtern und beschleunigen. So konnen Fehler oderwichtigen Eigenschaften schnell entdeckt werden und durch dieses Wissen kann dasProgramm weiter gesteuert werden. Deshalb ist die Moglichkeit bestimmten Parameterfur Uberwachung registrieren zu konnen, eine wichtige Voraussetzung die die Simula-tionsapplikation erfullen muss. Die betrachteten Paramter bilden einen Snapshot desProzesses.

4.2 Kommunikation Seite 31

Die Konsistenz der erhaltenen Daten ist von großer Bedeutung fur die Evaluierung derphysikalischen Experimenten. Um diese Konsistenz zu gewahrleisten muss die richtigeStelle fur die Erweiterung des Codes um Uberwachungsfahigkeiten gefunden werden.Hierfur sollen Techniken fur die Betrachtung von wichtigen Paramter wie z.B. Druck undGeschwindigkeiten entwickelt werden. Im Weiteren muss die Uberwachung der Zustandeverschiedener Hindernisse moglich sein.

∙ Steering: Ein weiterer Punkt ist die Veranderung von Parameter der Simulation im Lauf-zeit. Dieser Vorgang ermoglicht die effizientere Navigierung der Simulation zu Bereichen,die vom besonderen Interesse fur den Wissenschaftler seien konnen. In dem Gebiet derCFD-Simulationen sind die Manipulation von Hindernissen innerhalb der Stromung unddie Veranderung bestimmter Randbedingungen typische Anwendungsfalle fur Steering.Um die Divergenzfreiheit des Systems sicherzustellen, muss zusatzlich die Bewegung vonGeometrien bestimmte Kriterien erfullen, wie z.B., dass die Veranderung der Positioneiner Geometrie in einem Zeitschritt in den Grenzen einer Zelle bleiben soll. Bei Be-wegung uber eine Zelle kann die Information nicht schnell genug weitergeleitet werdenund das resultiert in die Divergenz der Gleichungen. Hierfur muss ein geeignetes Mecha-nismus fur die Durchfuhrung dieser Operationen entwickelt werden. Im Weiteren mussdas Einfugen und Loschen von geometrischen Objekten von dem System unterstutztwerden.

Die Berechnung der Stomungsdaten auf adaptiven Gitter in verschiedenen LoD Stufenermoglicht die Realisierungen Speicher effizienteren Simulationsverfahren. Im Weiterensollen diese Datenstrukturen im Bezug auf Performanzoptiemierung des Simulations-laufs erforscht werden. Durch geeigneter Auswahl der Verfeinerungsstufe bei Interaktiondes Benutzers kann die Exploration des Experimentes beeinflusst werden. Das ermog-licht die breitere und effizientere Exploration des Parameterraumes.

4.2 Kommunikation

Die physikalische Verteilung des Steering Prozesses uber ein Netzwerk resultiert in der Not-wendigkeit des Vorhandenseins einer Kommunikationskomponente, die die Datenaustauschzwischen der Simulation und der Steering-Interface regeln muss. Es werden zusatzliche Me-chanismen zur Steuerung und Konfiguration dieser Komponente benotigt. Techniken fur diebessere Auslastung der Kommunikationslink mussen mitberucksichtigt werden. Wichtig dabeiist die Komprimierung der ausgehenden Daten, die sehr haufig durch redundate Werte aufge-baut sind. Der laufende Datenaustausch muss moglichst geringen Einfluss auf der Performanzder Simulation haben.

4.3 Steering Interface

Die Steering Schnittstelle ist zustandig fur die Darstellung der aus der Simulation produziertenErgebnissen sowie fur die Steuerung bestimmter Parameter.

Die Schnittstelle muss eine graphische Benutzeroberfache fur das Bedienen der Simulation,sowie eine Visualisierungskomponente fur die 3D-Darstellung der Simuationsdaten anbieten.

Seite 32 4 Anforderungen

Um den Interaktionsvorgang mit der Visualisierung zu erleichtern wird die Gelegenheit zumdirekten Einbau der Visualisierung in dem GUI gebraucht. Im Folgenden konnen die Anfor-derungen an die Steering Interface in zwei Gruppen unterteilt werden: Anforderungen an dieGUI und Anforderungen an die Visualisierung.

∙ Anforderungen an die GUI:Das Computational Steering ist ein interaktionslastiger Prozess und deshalb spielt dieBenutzerschnittstelle eine zentrale Rolle dabei. Die graphische Oberflache hat die fol-genden zwei Hauptaufgaben : die Darstellung der aus der Simulation gelieferten Datenund das Anbieten von verschieden Werkzeugen, die die Modifikation bestimmter Si-mulationsparameter erlauben sollen. Zusatzlich mussen Methoden zur Steuerung derVisualisierung unterstutzt werden. Fur die Darstellung der Daten und die Steuerungkonnen textuelle und graphische Elemente verwendet werden. Eine direkte Manipulati-on der Objekten aus der 3D-Szene ware vom Vorteil bei dem interaktiven Umgang mitder Umgebung. Hierfur sollen GUI Elementen fur den Auswahl geeigneter 3D-Widgetseingebaut werden.

∙ Anforderungen an der Visualisierung:Die heutige Industriestandarten stellen zahlreiche Anforderungen an die Visualisierung.Unter Anderem die Korrektheit, die Qualitat und die Echtzeitfahigkeit der Algorithmenmuss sichergestellt werden.

1. Korrektheit: Durch das Mapping der erhaltenen Rohdaten auf verschiedenen Vi-sualisierungstechniken entstehen bestimmte Informationsverluste. Die zu imple-mentierenden Verfahren mussen diese Verluste moglichst gering halten.

2. Qualitat: Die komplexe Natur der Inputdaten setzt den Auswahl geeigneter Visua-lisierungstechniken voraus, die vernunftigen und leicht erfassbaren Ergebnisse furden Benutzer liefern sollen.

3. Echtzeitfahigkeit: Die aktuellen Visualisierungsalgorithmen mussen in Echtzeit aus-fuhrbar sein. Eine gute Parallelisierung der Algorithmen muss hierfur im Betrachtgenommen werden.

An dem Computational Steering sind unterschiedlichen Benutzergruppen aus unter-schiedlichen wissenschaftlichen Bereichen beteiligt. Das setzt die Notwendigkeit von ver-schiedenen Visualisierungstechniken voraus, um die Anforderungen aller dieser Gruppenzu erfullen. Im Weiteren werden die Eigenschaften, die von den ausgewahlten Metho-den erfullt seien mussen, eingefuhrt. Eine Beschreibung der einzelnen Methoden wurdebereits im Abschnitt 3.5.4 durchgefuhrt.

1. Visualisierung von Skalar Werten: Wichtig fur die allgemeine Verstandnis der er-zeugten Daten sind die Methoden fur die Darstellung von Skalarewerten. In Rah-men der CFD Simulation sollen die Druckwerte durch geeignete Techniken visua-lisiert werden. Hier bietet sich die Verwendung von den vorgestellten Color Map-ping Techniken sowie von komplizierteren Verfahren fur Konturengenerierung undSchnittebenen an.

Bei der Exploration des Volumens anhand von Schnittebenen mussen die folgen-den Use-Cases abgedeckt werden : Einfugen von Schnittebenen, Loschen, manuel-

4.3 Steering Interface Seite 33

le Positionierung und Ausrichtung entlang der Achsen. Diese Operationen sollendurch das Verwenden von geeigneten 3D Werkzeuge unterstutzt werden.

2. Visualisierung von Vektorfelder: Bei der Visualisierungstechniken fur Vektorfeldersind alle drei Arten von Verfahren(elementare Verfahren, lokale und globale) inter-essant fur die Erforschung der erstellten Daten. Besonders vom Interesse fur dieseArbeit sind die Darstellungsmethoden von Stomlinien, Vektorfelder durch Pfeileund Strombander. Diese Verfahren benotigen ein Mechanismus fur den Auswahlder Anfangspunkten (Seeding Points). Dieser Prozess soll durch Verwenden von3D Widgets unterstutzt werden.

3. Geometrie Visualisierung und Interaktion: In vielen Szenarien der Stromungssimu-lation sind Geometrien involviert. Hierfur muss die Visualisierungskomponente inder Lage sein einfache implizit beschrieben und komplexeren triangulierten Geo-metrien darzustellen. Zusatzlich mussen diese Objekte gesteuert werden konnen.Die Bewegung, Skalierung oder Rotation der Korper muss direkt aus der 3D Szeneanwendbar sein.

Oft bestehen die erhaltenen Simulationsdaten aus Millionen von Voxels. Dieses großes Vo-lumen von Daten macht deren Darstellung auf konventionellen Rechner unmoglich. Deshalbwerden die auf spezialisierten Clusters fur Visualisierung dargestellt. Die erhaltenen Datenwerden auf einem Bild gepackt und zum Client uber geschickt. Das erlaubt die massive Ver-ringerung der Daten auf der Seite des Benutzers. So kann Hardware mit geringen Rendering-Fahigkeiten fur die Darstellung verwendet. Das gewahrleistet auch die bessere Ausnutzungder Netzwerkkapazitat zwischen Benutzer und Visualiserungsserver.

Nachteil dieser Methode ist das verlorene Wissen fur den Zustand aktuellen Rohdaten. Diedirekte Interaktion mit diesen Daten aus dem Client ist deshalb unmoglich. Das erfordert dieImplementierung von Techniken die verteilte Interaktion mit diesen Daten erlauben sollen.

Seite 34 5 Konzept

5 Konzept

Dieses Kapitel beschaftigt sich mit den realisierten Konzepte. Die Konzepte haben das Ziel dieim Abschnitt 4 eingefuhrten Anforderungen moglichst genau zu erfullen. Als Erstes wird eindetailliertes Architekturbild des Gesamtsystems abgeleitet. Im Weiteren erfolgt die Erklarungder verwendeten Datensynchronizationsmechanismen zwischen Simulation und Steering Inter-face sowie der benutzten Techniken zur Manipulation von Randbedingungen und Geometrieninnerhalb von Peano. Im zweiten Teil des Abschnittes werden die Aspekte fur die Realisie-rung der Visualisierung der Benutzerschnittstelle vorgestellt. Hierfur werden die wichtigstenPunkten beim Entwurf ein leicht erweiterbares System im Bezug auf neue Algorithmen fur dieVisualisierung im Betracht genommen. Am Ende werden Paradigmen fur die Parallelisierungfur so eine Umgebung zusammen mit Verfahren fur die Ubertragung von der VisualisiertenDaten auf Desktop-Architekturen, mit weniger Hardware-Fahigkeiten.

5.1 Architektur

Wie bereits vorgestellt kann die Steering Pipeline verteilt ausgefuhrt werden. Eine moglicheVerteilung ware die getrennte Ausfuhrung der Simulation, Steering Applikation und Benut-zerschnittstelle. Fur die Realisierung so einer Aufteilung wird in dieser Arbeit das klassischeClient-Server Modell und die Nachrichten Austausch-Paradigmen als Grundlagen verwendet.Anhand dieser Modelle konnen komplexere Kommunikationsvorgange wie Aufruf entfernterProzeduren und Aufruf entfernter Methoden realisiert werden.

5.1.1 Nachrichtenaustausch

Eine Moglichkeit, Daten zwischen Prozesse auszutauschen, wird durch die Methode fur Kom-munikation anhand von Nachrichten angeboten.

An dem Nachrichtenaustausch sind zwei Prozesse beteiligt: der Sender und der Empfanger.Die Realisierung der Kommunikation baut sich auf zwei Hauptroutinen auf:

send(E:Empfaner,N:Nachricht);recieve(S:Sender,B:Puffer);

Je nach Bearbeitung dieser Routinen wird zwischen synchronen und asynchronen Nachrich-tenaustausch unterschieden.

∙ Asynchrone Kommunikation: Bei der asynchronen Kommunikation uber Nachrichtenkann der Sender seine Bearbeitung gleich fortsetzen, nachdem die Nachricht in denAusgangspuffer eingefugt wird. Dieses Mechanismus ist sehr Vorteilhaft zum Nutzen in-nerhalb von Echtzeitumgebungen. Die Nachteile der Methode sind das komplexere Ma-nagement des Nachrichtenpuffers beim Uberlauf und die entstehenden Probleme beim

5.1 Architektur Seite 35

Fehlschlag der Ubertragung. In diesem Fall kann die Notifizierung des Senders, der schondie nachfolgende Operation ausfuhrt, komplex werden.

∙ Synchrone Kommunikation: Bei dieser Kommunikation wird der Sender solange blo-ckiert, bis die Nachricht zum Empfanger vollstandig angekommen ist und die Bestati-gung dafur erhalten wird. In ahnlicher Art und Weise wird der Empfanger solange blo-ckiert, bis die Ubertragung der Nachricht beendet ist und die auf den Nachrichtenpuffergespeichert wird. Die Send- und Receive-Operationen werden oft mit Zeituberschrei-tungsroutinen versehen, um unendliche Wartezeiten zu vermeiden.

5.1.2 Das Client-Server Modell

Das in Abbildung 5.1 vorgestellten Client-Server Modell implementiert eine Art von Handshaking-Algorithmus.

Der Client ruft bestimmte Dienste des Servers auf. In den meisten Implementierungen wirdder Client bis zur Erfullung des Aufrufs blockiert. Die Client Prozesse sind a-priori unbekanntfur den Server.

Der Server Prozess bietet bestimmte Dienste zu den a-priori unbekannten Clients an. DieAusfuhrung dieser Dienste passiert auf einem Server Rechner. Dabei konnen mehrere unab-hangige Server-Prozesse auf dem gleichen Server Rechner ausgefuhrt werden.

Abbildung 5.1: Das Client-Server Modell

Es ist oft praktisch, dass der Server mit mehr als ein Client Daten austauschen kann. EineMoglichkeit besteht in der Generierung von neuen Threads oder Prozessen fur die Abwicklungder Kommunikation mit den einzelnen Clients. Die werden noch Daemonen genannt.

Eine Realisierung des Client-Server Modells fur bidirektionale Kommunikation wird vonder Socket-Schnittstelle angeboten. Es wird zwischen TCP- und UDP-Sockets unterschieden.Die ersten bieten zuverlassige Datenubertragung an, im Sinne von Verlust und Sequenz derNachrichten gegenuber die unsichere Datagram-Ubertragung der UDP-Sockets. Der Umgang

Seite 36 5 Konzept

(a) RPC-Kontrollfluss (b) Die Architektur von RPC-Anwendungen

Abbildung 5.2: Remote Procedure Call

mit den Sockets ahnelt den Umgang mit Dateien. Die konnen erzeugt und geoffnet werden.Auf die geoffneten Sockets werden dann Lese- und Schreibeoperationen durchgefuhrt. AmEnde wird der Socket geschlossen.

5.1.3 Remote Procedure Call und Remote Method Invocation

Ein wichtiger Aspekt fur die Implementierung der geforderten entfernten Visualisierung (vgl.Kapitel 4.3) sind die Techniken fur Aufruf entfernter Methoden und Prozeduren.

Der Aufruf entfernter Prozeduren(RPC-Remote Procedure Call) ist ein Schema zur Steue-rung oder Datenubertragung zwischen mehreren Prozessen durch Aufrufe entfernter Proze-duren. Wie die Abbildung 5.2(a) zeigt, wird der Aufrufer bis zum Empfang des Ergebnissesblockiert. Das Format des RPC-Aufrufs ist durch die Signatur der aufgerufene Prozedur ge-geben. Der Aufrufer-Prozess und der Prozess, der die Prozedur beinhaltet, befinden sich inunterschiedlichen Adressraumen und haben unter Umstanden unterschiedlichen Laufzeitum-gebungen.

Eine der wichtigsten Aufgaben von RPC ist die Gewahrleistung der Netzwerktransparenzfur Aufrufer und Empfanger. Das ermoglicht die Verknupfung zwischen heterogenen Plattfor-men. Diese Transparenz wird anhand von Stubs erreicht. Die Stubs sind zusatzliche Proxy-Komponente zustandig fur die Kommunikationsverwaltung. Im Folgenden werden die Aufga-ben der Client und Server Stubs genau vorgestellt:

∙ Client Stubs: Die Client Stubs haben die Aufgaben die entfernten Prozeduren genau zuspezifizieren und den richtigen Kommunikationspartner(Server) zu finden. Als Definitioneiner Prozedur wird die Signatur verwendet. Weitere Aufgaben der Client Stubs sinddie Umwandlung der Aufrufparameter in das Ubertragungsformat und das Entpackender erhaltenen Ergebnisse.

∙ Server Stubs: Die Server Stubs sind zustandig fur die Dekodierung der Aufrufparamter,die Bestimmung der Adresse der aufgerufenen Prozedur0 und ihre Ausfuhrung. Am Ende


(a) RPC-Architektur (b) RMI-Architektur

Abbildung 5.3: Zuordnung der RPC und RMI Komponenten in das ISO-OSI Referenzmodell

muss das Ergebnis in das Ubertragunsformat umgewandelt werden und zum Aufruferweitergeleitet werden.Die Abbildung 5.2(b) fasst die Architektur einer verteilten RPC-Anwendung zusammen.

Eine Erweiterung des RPC-Modells ist das Modell fur Aufruf von Methoden entfernterObjekte(Remote Method Invocation). Diese Methode erlaubt die Objekt zu Objekt Kom-munikation zwischen zwei Prozesse in unterschiedlichen Adressraumen. Die funktioniert wiefolgt:

1. Die Server Seite registriert ein Objekt in das RMI-Pool als Remote Objekt.

2. Client sucht sich ein entferntes Objekt aus dem RMI-Pool.

3. Fur das gefundene Remote Objekt wird ein Stub zur Verwaltung der Kommunikationzuruckgeliefert.

4. Durch die Abstraktion des Netzwerks kann der Aufruf des entfernten Objektes als einlokaler ausgefuhrt werden.

Die Architektur der Anwendungen , die RMI verwenden, unterscheidet sich von der Archi-tektur der RPC-Anwendungen durch eine zusatzliche Schicht(Remote Reference Layer-RRL).Die RRL-Schicht ist zustandig fur die Verwaltung und das Durchsuchen des RMI-Pools. Diebeiden Schichten-Architekturen werden in Abbildung 5.3 im Rahmen des ISO-OSI Referenz-modells dargestellt.

5.1.4 Die Steering-Architektur

Aufbauend auf den Architekturen aus der letzten Kapitel wurden in dieser Arbeit zwei Modelleentwickelt. Dabei werden die Vorteile der Schichtenarchitekturen, wie Abstraktion der dar-unter liegenden Schichten und klare Definition der Schnittstellen, ausgenutzt. In dem erstenModell werden die Visualisierung und die graphische Oberflache in einem Prozess realisiert.Die zweite Architektur bietet eine getrennte Realisierung eines Remote Renderers an. Im Ver-lauf der Arbeit hat sich das zweite Modell wegen der Unterstutzung einer Parallelisierung

0Typischerweise werden Lookup-Tabellen mit den vorhandenen entfernten Prozeduren auf der Seite des Emp-fanger erstellt. Durch einen Index Zugriff wird dann den Zeiger zu einer Prozedur gefunden und zuruckge-geben.

Seite 38 5 Konzept

(a) Schichtenarchitektur der Steering Appliktion (b) Multi-Client Anwedungsfall

Abbildung 5.4: Architektur der Single Process-Steering Applikation und ihre Anwendung.

der Visualisierung als besser geeignet erwiesen und deshalb wurde diese Architektur fur dienachfolgende Implementierung verwendet.

Folglich Abbildung 5.4(a) besteht die Architektur aus der Client-seitigen Komponenten derSimulation und die Server-seitige Steering Applikation. Die graphische Oberflache und dieVisualisierung werden hier in dem gleichen Prozessraum implementiert. Dabei werden diefolgenden Schichten von unten nach oben skizziert:

∙ Transportschicht: Die Transportschicht ist zustandig fur die Ubertragung der Datenzwischen Simulation und Steering Applikation. Um die Zuverlassigkeit gewahrleisten zukonnen, wird hier eine Implementierung aufbauend auf das TCP/IP Protokoll verwen-det.

∙ Prasentationsschicht: Hier passiert die Serialisierung/Deserialiserung der Objekten. Esentstehen dabei leicht ubertragbare Bytesequenzen. Die werden dann zu der Transport-schicht weitergeleitet. In der anderen Richtung(eingehende Daten) werden die Bytese-quezen zuerst deserialisiert und zu der Simulation weitergeleitet.

∙ Receiver/Sender-Schicht: Diese Schicht ist zustandig fur die Pufferung der eingehendenund ausgehenden Daten. Das erlaubt die unabhangige Ausfuhrung der Simulation undder Visualisierung. Die Puffer werden zur konsistenten Zeitpunkten stuckweise eingele-sen. Auf der Seite der Simulation passiert diese Aktion am Ende jedes Zeitschrittes undauf der Seite der Steering Applikation vor Rendering eines Frames.

∙ Anwendungsschicht: Auf dieser Ebene befinden sich die eigentlichen Simulationsnawe-dung und die graphische Oberflache mit der eingebauten Visualisierung. Ein Teil derAnwedungsschicht des Steering-Servers ist die Controller-Komponente. Die ist verant-wortlich fur die Behandlung der Ereignisse die von den graphischen Bedienelementenund den Visualisierungswerkzeugen erzeugt werden.

Die so vorgestellte Architektur bietet die Moglichkeit der parallelen Ausfuhrung mehrerenSimulation-Clients (vgl. Abb.5.4(b)). Dabei muss die Steering-Schnittstelle in der Lage sein,


Daten aus mehr als einem Client zu erhalten. Fur die Steuerung der Simulation wird jedeSimulationsinstanz mittels Broadcasting erreicht. Ein Prozess wird als Master gewahlt undist zustandig fur die korrekte Synchronisation der Clients. Die Steering-Schnittstelle lasstsich durch Verwendung von Software fur die entfernte Ausfuhrung von Applikation zu einemNotebook oder Desktop-Rechner ubertragen. Die meisten Werkzeuge zum Remote Rende-ring von Applikationen reagieren auf Befehle der aktuellen APIs des OS. Dabei verfugensolche Applikationen mit einem virtuellen Puffer fur die Visualisierung. Bei Festellung einesRendering-Befehls wird den Puffer aktualisiert. Aus dem Puffer wird dann ein Bild erzeugtund zum Client weitergelietet. Ein Nachteil dieser Architektur ist die fehlende Unterstutzungfur Parallelisierung (außer Threads) der Visualisierung.

Abbildung 5.5: Steering-Architektur mit Remote-Visualisierung

Folglich dieser Uberlegungen wird die ursprungliche Architektur um einen Visualisierungs-server erweitert(Abb.5.5). Dabei wird die Steering-Applikation in eine Visualiserungskompo-nente und eine GUI-Komponente zerlegt. Der Visualiserungsserver ist in der Lage getrenntvon der GUI und parallel ausgefuhrt werden zu sein. Die Simulation behalt ihren Kompo-nentenaufbau. Ausgehend aus der Simulation werden zwei Verbindungen aufgebaut: eine zumVisualiserungsserver(notwendig fur die Ubertragung der Rohdaten, die visualisiert werdenmussen, und fur das Monitoring und Manipulation der Geometrien anhand von 3D-Wigdets)und eine zu der graphischen Oberflache fur die Darstellung und Steuerung anhand von Be-dienelementen. Der Visualisierungsserver und die GUI beinhalten noch die Steuerungsschichtfur die Behandlung der Interaktionserreignisse.

Seite 40 5 Konzept

Das Rendering und Interaktionsvorgange der Visualisierungsserver werden anhand vonRMI-Aufrufe angestoßen. Dabei wird die Schichtenarchitektur der Steering-Prozessen umdie notwendigen Client und Server Stubs erweitert. Fur die Referenzierung der verteiltenObjekten wird die eingefuhrte Referenzschicht auf den dargestellten Kommunikationsseitenimplementiert.

Abbildung 5.6: Steering mittels mehreren Visualisierungsservers

Wie die Abbildung 5.6 zeigt, erlaubt die letzte Architektur die Verwendung von mehrerenVisualisierungsserver fur die Darstellung der Simulationsdaten. Die entstehende Bilder werdenvon einem Master-Prozess verknupft und zum End-Client(Desktop-Rechner) geschickt. Furdie Verteilung der Rohdaten wird die in Peano (vgl. [Wei09]) definierte Domain Dekompositionverwendet. Es handelt sich um eine SIMD Architektur der Visualisierung.

5.2 Synchronisation

Fur die Veranderung von Parameter der Simulation wird eine Art von Synchronisation zwi-schen den Daten der Steering-Applikation und der Simulation verwendet. Die veranderbareObjekte (wie Geometrien und Randbedingungen innerhalb bestimmten Szenarien) werdenhierzu um Synchronisationsschnittstellen erweitert. Die bekommen als Eingabe eine Kopiedes Objektes von der Seite der Steering-Applkation. Aus der Kopie konnen die Informatio-nen fur die gewunschten Anderungen geholt werden. Im Fall von unzulassigen Anderungenwerden Vorbearbeitungsaktionen durchgefuhrt oder die Anderungen ignoriert(z.B GeometrieBewegung großer als eine Zelle).

5.3 Manipulation von Geometrien

Ein wichtiger Fall fur die aktuelle Steering-Umgebung ist die Manipulation von Geometri-en. Innerhalb dieser Arbeit wurden drei Operationen realisiert: das Einfugen und Loschenvon Hindernisse, sowie die Bewegung der Geometrien in dem gegeben Stromungsfeld. Fur die

5.3 Manipulation von Geometrien Seite 41

Implementierung dieser drei Operationen wird eine Komponente fur Manipulation von Geo-metrien auf der Seite der Simulation benotigt. Eine Realisierung von so einer Komponentewird in [Unt09] beschrieben und in diese Arbeit verwendet. Im Folgenden werden die grund-legenden Konzepte dieser Komponente vorgestellt. Danach werden die notwendigen Schrittefur die Verwendung der Funktionalitat skizziert.

Fur die Simulation der Bewegung eines Korpers mussen die an dem Korper wirkendenKrafte bekannt sein. Sei die F (t) die an einem Korper wirkenden Gesamtkraft zur Zeitpunktt. Die Funktion F (t) ist die Summe aller wirkenden Krafte(Gravitation,elastische Krafte u.a.).Ferner sei X(t) der Zustand des Korpers wie in 5.1 definiert. Die Anderung des Zustandes istdurch die Formel 5.2 gegeben. Im Folgenden wird die Berechnung nur fur Verschiebungen derGeometrie skizziert.

X(t) =

(x(t)v(t)

)(5.1)

dX(t)

dt=

d

dt

(x(t)v(t)

)=

(v(t)F (t)m

)(5.2)

Die letzte Gleichung beschreibt ein Anfangswertproblem fur gegebenen X(0). Eine appro-ximative Losung lasst sich durch numerische Integration gewinnen. Durch die Anwendungder expliziten Euler Integration konnen die Gleichungen 5.3 und 5.4 abgeleitet werden. Diestellen die notwendigen Veranderungen der Position und der Geschwindigkeiten der zu derGeometrie benachbarten Fluid-Zellen dar.

v(t+ dt) = v(t) +F

mdt (5.3)

x(t+ dt) = x(t) + v(t)dt+1

2

F

mdt2 = x(t) +

1

1(v(t) + v(t+ dt)dt) (5.4)

Ausgehend von der implizite Darstellung der Geometrien in Peano wird zwischen Zellen au-ßerhalb der Geometrie(Fluid-Cells) und Zellen innerhalb der Geometrie(Geometry-Cells) un-terschieden. Bei der Bewegung eines Hindernisses werden zwei Falle betrachtet. Der ersteFall wird bei kleineren Geschwindigkeiten der Geometrien oder niedrige Auflosung der Do-main ersichtlich. Das resultiert nur in kleineren Veranderungen der Randgeschwindigkeitender Stromung. Dabei bleibt die Gitterstruktur erhalten. Im zweiten Fall werden die Fluid-Zellen von den Geometrie-Zellen durchgeschnitten. Bei dieser Aktion konnen Fluid-Zellen inGeometrie-Zellen umgewandelt werden und umgekehrt. Zusatzlich konnen Geschwindigkei-ten aufakkumuliert oder verloren werden. Die beschriebenen Falle werden durch ein Adapterbehandelt.

Die benutzte Version von Peano verwendet eine explizite Aufstellung der Druck-Matrix Q, notwendig fur die Berechnung der Navier-Stokes-Gleichugen 3.3. Nach einer topologischenVeranderung des Gitters muss die zusatzlich neu konstruiert werden.

Seite 42 5 Konzept

Die Veranderungen der Geschwindigkeiten innerhalb der Stromung oder an den Wandenaufgrund der Bewegung von Geometrien verursacht die Verletzung der Kontinuitatsgleichung3.7. Das resultiert in die falsche Berechnung des Drucks und der Krafte in den nachfolgendenZeitschritten. Eine Verbesserung dieses Verhalten wird in [Unt09] durch die Methode furDivergenz Korrektur vorgestellt.

Um die Geometrie in Bewegung zu setzen, mussen die Geschwindigkeiten an dem Objektgesetzt werden. Dabei werden die Klassen um Synchronizationsschnittstellen erweitert. Ausder GUI wird den neuen Offset des Hindernisses geliefert. Die Geschwindigkeit des Objekteskann anhand der aktuellen Zeitschrittweite � berechnet (vgl. Gleichung 5.5).

−→vi =−−→onew −−→oold

�(5.5)

Unter Umstanden kann die Interaktion des Benutzers Bewegungen großer als die maximalerlaubten erzeugen. In diesem Fall kann die Bewegung von dem alten bis zum neuen Offsetwie folgt dargestellt werden:

onewx = ((vix ÷ umaxx)umaxx + vix mod umaxx)� (5.6)

Dabei stellen −−−→umax die maximal erlaubte Geschwindigkeit der Stromung auf jeder Achse und÷ die Division ohne Rest dar. Aus der Gleichung 5.6 wird es klar, dass die Position −−→onew durchwiederholtes Anwenden der Geschwindigkeit −−−→umax erreicht werden kann.

Abbildung 5.7: Zusammenhang zwischen Traversierung und Verfeinerungszustande eines Ver-texes vgl. [Wei09]

Die Bewegung von Hindernisse in adaptiven Gitter funktioniert in analoger Art und Weise.Wichtig dafur sind die folgenden zwei Vertex-Operationen : refine und coarse. Die Bewegungdes Objektes verursacht Aufrufe dieser zwei Funktionen fur die Zellen die von inneren zumaußeren und umgerkehrt gewechselt werden mussen. Die coarse-Operation wird auf verfeiner-ten Vertices aufgerufen. Die Subvertices werden zum Loschen markiert. Fur die Existierenden

5.4 Die graphische Oberflache Seite 43

verfeinerten Kindbaume wird der coarse-Flag vererbt. Am Ende des Zeitschrittes wird den Zu-stand des Vertex auf nicht verfeinert gesetzt. Die refine-Operation eines Vertex ist zustandigfur die Verfeinerung aller benachbarten Elementen auf allen Achsen. Die schon verfeinertenVertices werden ignoriert. In Abbildung 5.7 werden die mogliche Zustande und Ubergange furein Vertex und den Zusammenhang der coarse- und refine-Operationen mit der Traversierungdes Gitters skizziert.

Um die speichereffizientere Darstellung des Spacetree zu gewahrleisten, werden die Frei-heitsinformationen fur verfeinerten Knoten nicht gespeichert. Aus diesem Grund werden zu-satzlichen Operationen verwendet, um diese Daten zu holen. Beim Vergrobern mussen dieWerte durch Restriktion zu den verfeinerten Knoten ubertragen werden. Analog beim Ver-feinern werden die neu eingefugten Knoten standardmaßig initialisiert. Eine bessere Methodeist die Initialisierung mit interpolierten Werten aus der darunterliegenden Schicht.

Durch geschicktes Umgehen mit den beiden Methoden, gesteuert durch die Geometrie undihre implizite Darstellung, kann die topologische Struktur des adaptiven Gitters bei einerBewegung leicht modifiziert werden. Im Weiteren konnen die beiden Aktionen als Basis furdie Implementierung eines Interaktion-basiertes Level Of Detail(LoD) Auswahlmechanismusdienen. Hierfur wird bei Benutzerinteraktion mit der Szene(Bewegung eines Objektes) dasGitter auf eine auswahlbare Detailstufe vergrobert, die bis zum Ende der Interaktion oderbis zur Auswahl einer anderen LoD erhalten bleibt. Die niedrige Auflosung erlaubt die effi-zientere Berechnung der Zeitschritten wahrend der Bewegung. Am Ende wird die LoD-Stufezuruckgesetzt.

Beim Loschen oder Einfugen von Objekten in die Szene muss den aktuellen Schnitt derGeometrien zuerst angepasst werden. Im nachsten Schritt werden die Prozeduren fur Aktua-lisierung des Gitters und Aufbau der Druckmatrix Q analog zu dem Fall einer Bewegungdurchgefuhrt.

5.4 Die graphische Oberflache

In diesem Abschnitt werden die Benutzerschnittstelle und ihre Aufbau vorgestellt. Dabei wirddie Funktionalitat der einzelnen Komponenten erotertert.

Die Benutzerschnittstelle hat die Aufgabe den Benutzer wahrend des Steering-Prozesszu unterstutzen. Die besteht aus einer Visualisirungskomponente und unterschiedlichen Be-dienelementen fur die Steuerung der Visualisierung oder der Simulation. In Abbildung 5.8wird die Struktur der Oberflache dargestellt. Die besteht aus den folgenden Elementen: 3D-Viewer, Geometrie Catalogue, Geometrie Browser und Control Panel fur die Steuerung derglobale 3D-Szene , der 3D-Widgets , des Konturengenerierungsprozesses.

Seite 44 5 Konzept

Abbildung 5.8: Die Aufbau der graphische Oberflache


Die Visualisierungskomponente(Abb. 5.9) wird

Abbildung 5.9: Die Visualisierungskompo-nentein der GUI

mittels der offentlichen Bibliothek VTK reali-siert. Hierfur wurde ein spezielles Plugin vonVTK verwendet, das das Einbauen des VTK-Fensters innerhalb einer graphischen Oberfla-che erlaubt.

Die Bedienflache 5.10 bietet die Moglichkeit

Abbildung 5.10: Skalar-Vektor Data Switch

an, zwischen Skalar und Vektor Daten um-zuschalten. Dabei werden im Hintergrund dierichtigen Datenquellen rausgesucht und visua-lisiert. Bei Vektordaten konnen Komponentender Vektoren oder deren Betrag als Farbkodie-rung angezeigt werden .

Die Bedienflache 5.11 hilft fur den Auswahl

Abbildung 5.11: Mapper-Box

des Visualisierungsalgorithmus. Dabei werdenzwischen drei Darstellungsweisen unterschie-den: die Color Mapping , die Konturendarstel-lung und die Glyphed-Darstellung. Die letztezeigt neben den Color Mapping auch die Ge-schwindigkeiten an jedem Gitterpunkt anhandvon Pfeilen.

Seite 46 5 Konzept

Wichtig fur die Wahrnehmung der Daten

Abbildung 5.12: Reprasentationsauswahl

ist globale Reprasentation der Stromungsda-ten. Um die zu verbessern werden uterschied-lichen Darstellungsforme angeboten. Im wei-teren kann deren Durchsichtigkeit durch Set-zen des Alpha-Werts gesetzt werden.

Die Maske 5.13 wird fur die Erzeugung von

Abbildung 5.13: Eingabemaske fur dieKonturengenerierung

Iso-Linien und Iso-Flachen verwendet. Es be-stehen zwei Moglichkeiten fur die Eingabe :Eingabe einzelner Konturwerten und die Ein-gabe anhand eines Intervalls und der Anzahlder gewunschten Konturwerten. Die erzeugtenWerten werden in eine Liste dargestellt.

Zusatzlich werden Werkzeuge zum Setzen

Abbildung 5.14: Eigenschaften : Pfeilenska-lierung, LoD,Geometrie-Widget

des Skalierungsfaktor der Pfeile beim Verwen-den der Glyphing-Technik eingesetz. Ein wei-teres Feld ist zustandig fur Steuerung der Le-vel Of Detail fur die adaptiven Gitter der Si-mulation. Das Kontrollkastchen fur die Geo-metrie schaltet den Widget, zustandig fur dieManipulation von Hindernissen.


Die Veranderung von Parameter der aktu-

Abbildung 5.15: Scenario-Maske

ellen Szenario wird in der Szenario-Maske(Abb.5.15) gemacht. Momentan konnen nurDirichlet- Randbedingungen gesetzt werden(wiez.B LID-velocity fur Driven Cavity und Mean-Velocity fur Obstacle-in-Channel Szenarien).

Fur den Umgang mit Linienalgorithmen wird

Abbildung 5.16: Die Bahnlinien-Maske

auch eigene Maske entwickelt. Die beinhaltetdas Kontrollkastchen zum Auswahl der ver-schiedenen Verfahren sowie Felder fur die Ein-gabe der Position des Line-Widgets, zustandigfur das Seeding. Im Weiteren werden Kompo-nenten fur die Steuerung der Auflosung derSeeding-Linie und der Schrittweite der Inte-gration(Anzahl Schritte und Schrittweite) an-geboten.

Die Schnittebenen-Maske ist verantwortlich

Abbildung 5.17: Die Schnittebenen-Maske

fur das Ein- und Ausschalten der Schnittebe-nen und fur das Anstoßen von unterschiedli-chen Operation wie Insert,Delete,Select undAlign auf der Flachen.

Seite 48 5 Konzept

Die Geometrien die in der aktuelle Szene

Abbildung 5.18: Browser der aktuallenGeomterie-Instanzen

geladen sind werden in einem Browser(Abb.5.18)angezeigt. Fur das selektierte Objekt werdendie aktuellen Daten wie z.B. Position und Ra-dius in einer Eigenschaften-Sicht(Abb.5.19) an-gezeigt. Durch Verwendung der rechte Maustas-te auf der Liste mit Geometrien konnen diebestimmte Objekte geloscht werden.

Zusatzlich sind einige der Daten in Eigen-

Abbildung 5.19: Eigenschaften derausgewahlten Geometrie

schaften direkt editierbar(z.B Position). Furdie editierbaren Parameter wird zwischen Soll-und Ist-Wert unterschieden. Nach der Einga-be in das Soll-Feld wird ein Steuerung-Kommandoan der Simulation geschickt. Die Aktualisie-rung des Ist-Felds passiert bei jedem Zeitschritt.

5.5 Visualisierungskonzept

In dem nachfolgenden Kapitel werden die wichtigsten Punkten bei dem Entwurf einer Visua-lisierung fur die Steering Applikation eingefuhrt. Im ersten Teil werden die verwendeten Me-chanismen fur den Entwurf eine Online-Darstellung der Stromungsdaten von Peano erortert.Diese Konzepte werden um Komponenten fur die Unterstutzung einer parallelen Ausfuhrungauf Grund der von Peano erstellten Domain Dekomposition erweitert.

5.5.1 Realisierung grundlegender Visualisierungsverfahren

Eine der Aufgaben dieser Arbeit ist die Umsetzung geeigneter Verfahren zur Uberwachungund Analyse bestimmter Eigenschaften von Stromungsdaten. Hierfur werden die Verfahrenaus Kapitel 3.5 fur die Zwecke dieses Steering-Frameworks angepasst. Fur die prototypischeEntwicklung wurden die folgenden Methoden ausgewahlt:

∙ Color Mapping: Diese Technik erlaubt die Darstellung wichtiger Skalaren durch Zuord-nung zur bestimmten Farben. Dabei wird den Druck auf den Mittelpunkten der Zellenbetrachtet. Eine weitere Option erlaubt die Visualisierung des Drucks an den Vertices.Bei der verwendeten Implementierung von Peano sind die Druck-Informationen nur imZentrum der Zellen gegeben, deshalb werden die Werte durch Interpolation berechnet.Im Weiteren wird die Unterstutzung der Darstellung verschiedener Komponenten derGeschwidigkeitsvektoren oder den Betrag des Vektors eingebaut.

∙ ISO-Linien und ISO-Flachen: Eine weitere Technik ist die Darstellung der Iso-Linienund der Iso-Flachen fur den aktuellen Zeitschritt. Wichtig fur deren Berechnung istden Auswahl eines Konturwertes. Diese Aktion wird durch zusatzlichen Bedienelemen-ten unterstutzt. Zwei Eingabemoglichkeiten werden angeboten: Setzen jedes einzelnes

5.5 Visualisierungskonzept Seite 49

Konturwertes oder die Generierung bestimmter Anzahl von Werten innerhalb eines Be-reiches.

Die 3D-Widgets werden bei den folgenden Verfahren verwendet: Visualisierung von Schnit-tebenen, Linienalgorithmen und Geometrien. Fur die Instanzierung von dieser Visualisie-rungstechniken und Widgets werden Factories verwendet. Die Factories sind zustandig furdie eigentliche Initialiserung der Widgets und der Algorithmen, sowie fur die Erzeugung derSteuerkomponenten, die die Benutzerinteraktion behandeln mussen.

∙ Schnittebenen: Die Schnittebenen sind ein wichtiges Hilfsmittel fur die Exploration der3D-Visualisierungsdaten. Die Erlauben das Durchschneiden des aktuellen Volumen undBeobachtung bestimmter Eigenschaften auf der geschnittenen Ebene. Es konnen maxi-mal bis zu 10 Ebenen eingefugt werden. Die Auswahl einer Ebene wird GUI-seitig durchein Stepper realisiert. Die Verschiebung und Rotation der Flachen wird auch unterstutzt.

∙ Streamers: Fur die Darstellung der Bahn eines Partikels innerhalb des Stromungsfeldeswerden drei Methoden verwendet: die Stromlinien, die Dashed-Stromlinien mit Pfeilen-Glyphing und die Strombander. Alle drei Methoden benutzten einen Line-Widget furdie Festlegung der Seeding-Punkten. Dabei kann die Anzahl der Punkte auf der Linie ge-steuert werden. Fur die Integration konnen die Anzahl der Schritte und die Schrittweiteverandert werden.

∙ Geometrien: Die Geometrien in der 3D-Szene bestehen aus einer triangulierten Darstel-lung und einen BoundingBox-Widget. Der 3D-Werkzeug erlaubt die Durchfuhrung vonSkalierung , Verschiebung und Rotationen0 mit den vorhandenen Objekten.

5.5.2 Remote Rendering und parallele Visualisierung

In dem Umfeld der explorativen Visualisierung bieten sich verschieden Ansatze fur die Par-titionierung der im Abschnitt 3.5.2 vorgestellten Visualisierungspipeline. In Abbildung 5.20werden verschiedene Moglichkeiten dieser Partitionierung angezeigt. In dem ersten Beispiel Awird die Simulation auf einem parallelen Rechner ausgefuhrt und die berechneten Rohdatenauf einem anderen Rechner gefiltert, gemappt und gerendert. Die Nachteile dieser Metho-de ist den hohen Speicherbedarf auf der Visualisierungsseite und die hohe Belastung desKommunikationslinks zwischen Simulation und Visualisierung. Bei Verfahren aus der Gruppevon B und C werden die Simulation, die Filterung der Daten und das Mappung(nur fur C)auf Massiv-parallele Rechnerarchitekturen(MPR) ausgefuhrt. Die deutlich kleineren Datenwerden auf einem Rechner gerendert und angezeigt. So konnen relativ große Datenmengeneffizient visualisiert werden. Die Nachteile hier sind , das die 3D-Szene bei der Veranderungverschiedener Visualiserungsparamter neu berechnet werden soll. In dem letzten Ansatz wirddie Durchfuhrung der Simulation zusammen mit dem Rendering-Prozess auf den MPR aus-gefuhrt. Als Ausgabe werden Bilder produziert. Die werden eventuell komprimiert und zumClient geschickt. Vorteile dieser Methode sind die geringeren Anspruche an das Endgeratund die kleinere Belastung des Netzes bei der Ubertragung zwischen Client und MPR. DeImplementierung in dieser Arbeit baut sich auf der Partitionierung aus D .

0Aktuell wird nur die Verschiebung als Transformation auf der Seite der Simulation unterstutzt.

Seite 50 5 Konzept

Abbildung 5.20: Partitionierung der Visualisirungspipeline aus [OH01]

Im Folgenden werden die drei moglichen Arten von Parallelisierung einer Visualisierunginnerhalb von dem Visualisation Toolkit vorgestellt. Dabei wird es zwischen Task, Pipelineund Daten Parallelisierung unterschieden.

∙ Task-Parallelisierung: Die Task-Parallelisierung stellt die Ausfuhrung von unabhangi-gen Visualisierungsaufgaben auf unterschiedlichen Rechner dar. Zum Beispiel kann dieverteilte Ausfuhrung der Visualiserung von Stromlinien und Konturen als Taskparalleli-sierung bezeichnet werden. Diese Ausfuhrung ahnelt der in Abschnitt 3.6.1 vorgestelltenMISD Architekturen.

∙ Daten-Parallelisierung: Die Daten-Parallelisierung ist nutzlich fur die Exploration vongroßen Datenmengen. Dabei wird die ursprungliche Datenmenge in unabhangigen Blo-cke partitioniert und dann werden die gleichen Visualisierungsverfahren auf die parti-tionierten Daten angewendet. Am Ende werden die Ergebnisse der einzelnen Prozessezusammengebaut. Dieses Modell entspricht der Single Instruction Multiple Data Para-digma.

∙ Pipeline-Parallelisierung: Eine Visualisierungspipeline wird von kleineren funktionalenTeilen aufgebaut. Dabei konnen einige der Teile parallel berechnet werden. Bei derPipeline-Parallelisierung wird eine partielle Ordnung dieser Teilen fur die eigentlicheparallele Ausfuhrung verwendet.

Die aktuelle Implemetierung ist ein Beispiel der Daten-Parallelisierung, wobei fur die Partitionder Daten die schon vorhandenen Dekomposition von Peano verwendet wird.

Ein wichtiger Teil der parallelen Visualisierung ist die Dekomposition der 3D-Szene unddie Last-balancierte Verteilung der Daten zwischen den einzelnenen Prozessoren. Dafur wer-den neue Algorithmen fur das parallele Rendering von großen Datenmengen gebraucht. DieHauptidee der Methoden zum paralleles Rendering besteht darin, mehrere Ergebnisse gleich-zeitig zu berechnen und die am Ende zusammenzusetzen. Die Abbildung 5.21 zeigt die ge-nerelle Architektur fur graphische HPC-Anwendungen. Dabei wird die aufgeteilte 3D-Szene


Abbildung 5.21: Die allgemeine Architektur von graphischen HPC-Anwendungen nach[EIH00]

zum mehreren graphischen Einheiten(G’s) geschickt und parallel abgearbeitet. Die erhalteneErgebnisse werden zu den Rasterungseinheiten(R’s) weitergeleitet. Nach der Rasterungsphasewird das ganze gemergt und angezeigt.

Die Berechnung von mehreren Ergebnissen parallel fordert die Verwendung einer Sortie-rung, um die richtige Darstellung des Gesamtbildes zu gewahrleisten. In [Mol94] wurde eineAufteilung der parallelen Architekturen, je nachdem wo in der Parallel Rendering Pipelinedie Sortierung der Objekten(Objekt-Space Parallelismus) oder der Pixel(Screen-Space Paral-lelismus) stattfindet, vorgeschlagen. Dabei unterschiedet man vier Typen : sort-last Image,sort-last Fragment, sort-middle und sort-first Algorithmen zum parallelen Rendering. Bei derSort-First Algorithmen(Abb.5.22(a)) werden die geometrischen Primitiven vor der Bestim-mung deren Bildschirm-Parameter(vor Bearbeitung der geometrischen Eingeiten) sortiert. InSort-Middle Ansatze(Abb.5.22(b)) findet die Sortierung zwischen die geometrischen Einheitenund die Rasterung. Der Rasterungsphase besteht aus zwei Teilphasen : die Fragmentgenerie-rung(FG) und das Fragmentmischung(FM).Die FG-Einheiten generieren die Position einesFragmentes in dem Primitive und leitet die zu den FM-Einheiten weiter. Die FM-Einheitenhaben die Aufgabe die aktuelle Ergebnisse mit den Z-Puffer zu mergen. Die Sort-Last Frag-ment Architekturen(Abb.5.22(c)) sortieren die Fragmente nach der Fragmentgenerierung undvor der Fragmentmischung. Die Sort-Last Image(Abb.5.22(d)) Architekturen sortieren nachder kompletten Rasterugsphase(FG+FM).

Seite 52 5 Konzept

(a) SortFirst

(b) SortMiddle

(c) Sort LastFragment

(d) Sort LastImage

Abbildung 5.22: Taxonomie der graphischen HPC-Anwendungen nach [EIH00].

In der aktuellen Implementierung wird fur die parallele Berechnung der Visualisierung einenSort-Last Image Ansatz, basiert auf Tree Komposition der Bilder, verwendet. Dabei wird imersten Schritt das Volumen partitioniert und an den verschiedenen Rechner weitergeleitet.So entstehen mehrere unabhangigen Pipelines. Im Weiteren werden die einzelnen Pipelineszu einem Bild gerendert und am Ende in der Kompositionsphase werden die einzelnen Bildergemischt. Die Rendering Phase wird unabhangig auf jedem Rechner durchgefuhrt. Vorteil die-ser Architektur ist die Gewahrleistung eines hohen Parallelisierungsgrades in der Rendering-Phase. Hier wird es deutlich, dass die Komposition der Bilder den Flaschenhals darstellt. DerAufwand fur die Komposition steigt linear mit der Anzahlt der Prozessoren. Deshalb sollenan der Stelle effizientere Algorithmen zur Komposition der Bilder verwendet werden.

In dieser Arbeit wird das einfache Binary-Tree Kompositionsalgorthmus verwendet. DieserAlgorithmus bassiert sich auf der Binary Space Partition Tree(BSP-Tree). In der Literaturtauchen zwei Varianten der BSP-Trees: die Achsen-gerichteten und die Polygon-gerichteten.Durch Verwendung einer Ebene wird das Volumen in zwei aufgeteilt und die Geometrien injedem Teil sortiert. Die unterschiedlichen Traversierungen des Baumes generieren Sortierungender Geometrien von alle unterschiedlichen Sichtspunkten.

∙ Axis-Aligned BSP Tree: Am Anfang wird eine Axis-Aligned Bounding Box fur die kom-plette Szene bestimmt. Im nachsten Schritt wird die rekursiv in kleineren Boxen auf-geteilt. Die Aufteilung einer Box auf beliebige Rekursionstiefe funktioniert wie folgt:es wird eine Achse ausgewahlt und eine neue senkrechte Ebene angelegt. Diese Ebeneteilt die Box in weiteren zwei Boxen. Der Auswahl der Position der Ebene unterschei-det sich je nach Implementierung. Die Objekte, die die Ebene durchschneiden, werdenaufgeteilt oder in den beiden Boxen gespeichert. Die Operation wird dann fur die neuenBoxen wiederholt bis zum Erreichen einer bestimmten Tiefe. In Abbildung 5.23 wirdein Beispiel fur eine Aufteilung anhand Axis-Aligned BSP-Tree gezeigt.

∙ Polygon-Aligned BSP Tree: Die Polygon-Aligned Methode funktioniert in analoger Artund Weise. Dabei wird statt einer Achse einen Polygon als Teiler ausgewahlt. Die Ebene,auf der sich das Polygon befindet, wird fur die Aufteilung verwendet. Dieses Prozesswird rekursiv fur die entstehenden Kinder ausgefuhrt. Die Generierung eines Polygon-gerichteten Baumes ist zeitintensiv und deshalb wird es am Meisten einmal berechnet


(a) Raumliche Aufteilung mit BSP-Baum (b) Die BSP-Datenstruktur fur die Szene

Abbildung 5.23: Achsen-gerichtete BSP-Baum

und gespeichert.

Wichtig fur die Parallelisierung der Visualisierung ist Lastbalansierung, deshalb sind diebalancierten BSP-Baume von Vorteil fur ein paralleles Rendering. Eine spezielle Form derBSP-Baume sind die K-D Trees. Dabei werden die einzelnen Achsen pro Rekursionsaufrufnacheinander umgelaufen. Zum Beispiel wird die Root-Box entlang der X Achse gesplittet.Die Kinder werden entlang der Y-Achse gesplittet und die nachste Rekursionsstufe entlang Zund so wiederholt sich das ganze bis zum Erreichen der gewunschten Tiefe. Fur die gute Balan-cierung wird das Median der Primitiven verwendet. Bei den Polygon-gerichteten BSP-Baumenwerden verschiedene Heuristiken angeboten. Eine davon ist das least-crossed-criterion. Dabeiwerden zufallig einige Polygone ausgewahlt(typisch funf). Den Polygon mit der Ebene, dievon wenigsten andere Polygonen geschnitten wird, wird als Splitter verwendet.

Der konstruierte Baum wird spater in der Komposition Bottom-Up durchgelaufen. Da-bei werden die benachbarten Knoten zusammengefasst und nach oben propagiert. Am Endeenthalt den Root des Baumes das komplette Bild.

In den meisten Fallen haben die Wissenschaftler keinen direkten Zugriff zu dem Visua-lisierungsserver. Deshalb ist die Verwendung eines Desktop-Delivery Systems notwendig. Indie aktuelle Implementierung wird ein Prozess aus der Menge der Visualisierungsprozessenals Desktop-Delivery Server ausgewahlt. Seine Aufgabe ist die Verwaltung der Kommuni-kation mit der Desktop-Delivery Client und die Weiterlietung von Befehle zu den anderenVisualisierungsprozesse(wie Z.B. Rendering Befehle oder Interaktionsbefehle). Dabei werdendie eingefuhrten RMI-Konzepte fur diese Aufgabe verwendet. Nach der Berechnung des Fra-mes in dem parallelen Pipeline wird ein Bild generiert und zum Client ubergetragen. DerEinbau des Clients in einer Benutzerschnittstelle setzt die Verwendung von Sockets fur dieKommunikation zwischen Desktop-Delivery Server und Client voraus.

Seite 54 6 Implementierung

6 Implementierung

Dieser Kapitel beschaftigt sich mit der Beschreibung der wichtigsten Schnittstellen und Kom-ponenten des implementierten Steering Frameworks. Im ersten Teil des Abschnittes werdendie Kommunikationskomponenten der Simulation und der Steering Applikation vorgestellt.Im Weiteren erfolgt die Beschreibung der Schnittstellen fur Monitoring und Steuerung vonParameter. Am Ende erfolgt die Erlauterung der implementierten Visualisierung im Hinblickder Parallelisierung und das Desktop Delivery.

6.1 Die Kommunikationskomponenten

Die Kommunikation zwischen der Simulation und der Steering-Applikation baut sich auf demim Abschnitt 5.1.2 vorgestellten Client-Server Modell. Hierfur wird die BSD-Socketschnittstellefur Implementierung dieses Vorgangs verwendet. Bei einer parallelen Ausfuhrung der Simula-tion besitzt jede Instanz eine Client Komponente. Die Steering-Applikation besteht dement-sprechend aus bestimmten Anzahl von Steering-Servers. Es wurde die Annahme getroffen,dass eine Simulation nur einen Steering-Server zugeordnet werden kann. Ein Server kann da-bei mehr als ein Client bedienen. Hierfur werden Daemonen fur die einzelnen Clients erstelltund verwaltet. Die weitere Kommunikation mit dem Client wird durch den Daemon geleitet.Fur die Implemetierung der Daemonen werden die Posix-Threads0 verwendet.

Im Folgenden werden die molichen Zustande des Simulationsclients und des Steering-Serversskizziert. Wie die Abbildung 6.1 zeigt, wartet der Client am Anfang bis zu der Initialisierungder Verbindung mit dem Server. Danach werden zwei Threads erzeugt : ein Thread zumEmpfangen und einen zum Verschicken von Daten. Durch die Threads wird einen nicht blo-ckierenden Betrieb der Simulation gewahrleistet. Hierfur werden zwei FIFO Puffer fur dieSpeicherung von Daten die nicht rechtzeitig bearbeitet werden konnen, verwendet.

Der Server funktioniert auf ahnlicher Art und Weise(vgl.Abb.6.2). Am Anfang wartet erbis zum Aufbau einer Verbindung mit einem Simulationsclient. Gleich nach der Aufbau wer-den die Empfanger und Sender-Threads(Daemonen) erzeugt. Nach diesem Schritt wiederholtder Server seine letzten Aktionen fur andere Clients (Auf Verbindung warten und Threadserzeugen).

Die Kommunikationskomponente der Simulationsclient besteht aus der folgenden Klassen:DataClientManager, DataConcurrentQueue, SteeringClientConfiguration und SteeringPacka-ge. Die DataClientManager Klasse bietet die grundlegenden Methoden fur die Verwaltung derSocket-Kommunikation(Verbindung Aufbauen,Verschicken und Empfangen von Daten). DieDataConcurrentQueue beinhaltet die Funktionalitat fur die Implementierung einen Thread-sicheren FIFO Puffer. Bei einem schnelleren Produzent als Verbraucher muss sichergestellt

0Portable Operating System Interface standard

6.1 Die Kommunikationskomponenten Seite 55

Abbildung 6.1: Zustandsdiagramm des Simulation-Clients

Abbildung 6.2: Zustandsdiagramm des Steering-Server


werden, dass Information(Veranderungen oder Monitoring Daten) nicht verloren geht. Des-halb werden die Dienste solcher Puffers gebraucht

Abbildung 6.3: Pakete fur die Kommunikation zwischen Client und Steering Server

Vor dem Verschicken werden die ausgehenden Daten in Paketen(SteeringPackage- Abb.6.3)eingefugt. Man unterscheidet zwischen zwei Arten von Pakten: Uberwachungspakete undSteering-Pakete. Die ersten stellen Uberwachungsparameter dar(Daten aus der Simulation)und die zweiten die Steering-Kommandos und die Steering-Parameter. Wichtige Großen furdas Uberwachen sind die Positionen und die Geschwindigkeiten der einzelnen Vertices, dietopologische Beschreibung der Zellen(Connectivity Lists)und den Druck in der Mitte der Zel-le. Die Steering-Pakete dienen fur die Steuerung der Simulation und bestimmter Parameter.Die Geometrien und der simulierten Szenarien konnen in Uberwachungspakete als auch inStreering-Pakete verwendet werden. Ein anderes Beispiel fur Steering-Paket ist das LoD-Paketfur die Steuerung der Detailstufe von adaptiven Gitter. In den Geomtrie- und Szenarien-Paketewerden die fur Steerung und Uberwachung annotierten Variablen dargestellt(Beispielsweise:Position einer Geometrie oder eine Dirichlet-Randbedingung fur ein Szenario).

6.2 Serialisierung

Das umkehrbare Mapping der Paketen auf Bytesequenzen wird durch die Serialisierungs-APIvon der Bibliothek Boost implemetiert. Die Implementierung erlaubt die Serialisierung voneinfachen Datentypen bis zur komplexeren Pointer-Strukturen. Die Daten werden dabei inArchiven(IO-Strome) gespeichert. Fur die Serialisierung in Peano werden die gewunschtenKlassen mit einer serialize-Methode erweitert. Diese Methode beschreibt die Variablen dieserialisiert werden mussen. Bei der Deserialisierung(Sequenz zum Objekt) wird die gleicheBeschreibung verwendet. Eine solche Erweiterung sieht wie folgt aus:

6.3 Implementierung derUberwachungskomponente-Peano Seite 57

6.1: Erweiterung von Klassen um seriailize Schnittstelle

1 friend class boost::serialization::access;2 template<class Archive>3 void serialize(Archive &ar,const unsigned int version)4 {5 ar & _id;6 ar &_dimension;7 .8 .9 }

Die friend Definition erlaubt den Zugriff auf privaten Variablen fur die Boost-Serialization-Bibliothek. Eine Kompriermierung der verwendeten Archiven kann leicht hinzugefugt werden.

Die Beschreibung der Geometrien und der Szenarien in Peano baut sich auf dem Prin-zip der Generalisierung auf. Fur die richtige Serialisierung von vererbten Daten mussen dieVater-Kind Beziehungen registriert werden und die serialize Methode in der Basisklasse auchimplemetiert werden . In 6.2 wird beispielhaft die Serialisierungsmethode der Kugels ange-zeigt.

6.2: Serialisierung und Generalisierung

1 friend class boost::serialization::access;2 template<class Archive>3 void serialize(Archive &ar,const unsigned int version)4 {5 boost::serialize::void_cast_register<Sphere,

Geometry>(static_cast<Sphere*>(0),static_cast<Geometry*>(0));

6 ar & boost::serialization:base_object<Geometry>(*this);

7 ar & _radius;8 }

Die so serialisierten Daten werden auf den Socket-Puffer gelegt und verschickt. Bei der De-serialisierung wird die serialize Methode des entsprechenden Objektes mit der geschicktenSequenz als Eingabe aufgerufen und die entsprechenden Variablen des Objektes gesetzt.

6.3 Implementierung der Uberwachungskomponente-Peano

Fur die Uberwachung der Stromungsparamter innerhalb von Peano wird in dem Abschnitt3.4.3 vorgestellten Traversierungs-Konzept mit Hilfe von Adaptoren verwendet. Die Fluid-Applikation wurde dafur um die Klassen TrivialEventHandle2VTKClientAdapter und Gri-dEventHandle2VTKClientAdapter erweitert. Die beiden Klassen implementieren die Adap-terschnittstellen fur regularen und adaptiver Gitter. Dabei wird am Ende jedes Zeitschritteseine Traversierung mit den beiden Adaptoren angestoßen. Die Klassen bekommen einen Zeigerzu dem Outgoing-Puffer, um die gesammelten Paketen fur die Kommunikationskomponente


Event Aktion

touchVertexFirstTime() Aufsammeln der Positionen und Geschwindigkeitender persistenten Vertices

*createTemoporaryNode() Einschalten der Interpolation von hangenden Knoten

enterElement()∣handleElement Aufsammeln von Druckwerte der Zellen

*destroyTemoporaryNode() Sammeln der interpoliertenGeschwindigkeiten der hangenden Knoten

endIteration() Einfugen der gesammelten Daten in den Outgoing-Puffer

Tabelle 6.1: Die Event-Aktion Tabelle der VTKClient Adaptoren

verfugbar zu machen. Die Tabelle 6.1 fasst die einzelnen Schritten der Adaptoren zusammen.

Die Uberwachung der Parameter von Geometrien und Szenarien(wie z.B. aktuelle Position,Rotation, Radius der Objekten oder die Dirichlet-Randbedingungen der Szenarien) wird durchVerwendung des Serialisierungsmechanismus der Boost-Biobliothek gewahrleistet. Am Endedes aktuellen Zeitschrittes werden die entsprechen Paketen gebildet, auf den Outgoing-Puffergelegt und zu einem Steering-Server geschickt.

6.4 Implementierung der Steeringkomponente-Peano

Fur die Veranderung von Parameter der Geometrien oder der Szenarien werden die entspre-chenden Klassen um die Methode synchronize erweitert. Die Methode bekommt als Eingabedas erhaltene Objekt des Steering-Servers. Die Eingaben dieses Objekt werden benutzt furdie Berechnung des neuen Zustands der aktuellen Instanzen.

6.3: Signatur der Synchronizationspunkten fur Geometrien und Szenarien

1 void synchronize(Object steering_instance)

Die synchronize-Methoden werden beim Eingang eines Steering-Pakets fur die entsprechen-de Instanz am Ende des aktuellen Zeischrittes ausgefuhrt. Die Ausfuhrung einer Veranderungkann abstrakt in den folgenden Schritten aufgeteilt werden:

1. Aufruf der synchronize Methode des zu veranderten Objektes. Hier wird den neuenZustand der Instanz berechnet und gesetzt.

2. Aktualisierung von Parameter und Topologie(wenn notwendig) der Gitterdatenstruktu-ren.

3. Die Aufbau der Q-Matrix(wenn notwendig).

4. Nachkorrektur(optional)-Divergezbehandlung.

6.5 Implementierung der Steering Appli-kation Seite 59

Fur die Veranderung von Dirichlet-Randbedingungen der verschieden Szenarien wird kon-kret am Anfang die synchronize Methode des Szeario aufgerufen. Bei dem Aufruf werdeninterne Parameter fur die aktuelle Szenario aktualisiert(z.B lid-velocity oder mean-velocity).Zu diesem Zeitpunkt ist die Veranderung noch unbekannt fur das Gitter. Fur die Aktualisie-rung wird den vorhandenen Adapter fur die Berechnung des Druckgradients (GridEventHand-le2UpdateVelocitiesAdapter und TrivialgridEventHandle2UpdateVelocitiesAdapter ) verwen-det. Dabei werden die Geschwidigkeiten der entsprechenden Dirichlet-Knoten aktualisiert.Diese Veranderung ziehen keine Veranderungen der Topologie des Gitters hinter sich unddeshalb ist die Aktualisierung der Q-Matrix nicht notwendig.

Die Veranderung der Geometrieparameter passiert in den folgenden Schritten : nach derErhaltung des Pakets wird seinen Delete-Flag uberpruft. Ist der Flag gesetzt wird die Geo-metrie aus dem Schnitt-Kollektion der Geometrien entfernt. In dem anderen Fall handelt essich um eine Modifikation oder Insert-Operation. Dabei wird zuerst die synchronize Metho-de der vorhandenen Geometrien aufgerufen. Wurde keine Geometrie synchronisiert, musstesich um eine Insert-Operation handeln. Der neue Offset des Objekten wird in Geschwin-digkeiten umgerechnet. Nach diesem Schritt erfolgt die Berechnung der wirkenden Kraftean der Geometrie. Diese Information wird fur die Aktualisierung der Geschwindigkeitender benachbarten Knoten(benachbart zu der Geometrie) der Stromung verwendet. Zustan-dig dafur sind TrivialgridEventHandle2GeometryFluidStructureIteractionAdapter und Gri-dEventHandle2GeometryFluidStructureIteractionAdapter Klassen. Zusatzlich wird die neuePosition der Geometrie berechnet. Als nachstes erfolgt eine Aktualisierung der topologi-schen Struktur des Gitters. Zustandig fur diese Aufgaben je nach Gittertyp sind die bei-den Adapters TrivialgridEventHandle2GeometryUpdateGridAdapter und GridEventHand-le2GeometryUpdateGridAdapter. In dem Fall eines Wechsels der Typen der Zellen von Fluid-Zellen zur Geometrie-Zellen und umgekehrt muss die Q-Matrix neu aufgebaut werden.

Bei der Bewegung der Geometrien auf adaptiven Gitter wird die eingefuhrten LoD-Relaxitiondurchgefuhrt. Hierfur wird die GridEventHandle2GeometryUpdateGridAdapter Klasse umeinen Attribut fur die Steuerung der LoD erweitert. Bei einer Bewegung werden die entspre-chenden coarse und refine Operation durch dieses Attribut begrenzt. Nach der Beendigungder Aktion wird das Gitter auf die ursprungliche Detailstufe zuruckgesetzt.

6.5 Implementierung der Steering Applikation

Im Laufe dieser Arbeite wurden zwei Architekturen (vgl. Abschnitt 5.1.4) evaluiert. Die ersteArchitektur besteht aus einem oder mehreren Simulationsclients und einem Steering-Server.Dabei werden die GUI und der Steering-Server in einem Prozess ausgefuhrt. Wegen der Ein-bau der Visualisierung in der GUI wird die parallele Visualisierung fur diese Architekturnicht unterstutzt. Der zweite Ansatz reduziert den Inhalt der Visualisierung, die in der GUIeingebaut ist, auf ein Bild. Das Bild wird durch Desktop-Delivery Techniken von einem Vi-sualisierugserver ermittelt. Der Visualisierungsserver unterstutzt die parallele Ausfuhrung derRendering-Pipeline. Die aktuelle Implementierung nutzt vollstandig die zweite Architektur.

In den nachfolgenden Kapitel werden die Details fur die Implementierung der SteeringInterface erortert. Am Anfang wird die Implementierung der Basis-Visualiserungstechniken


und deren Verwendung in der graphischen Schnittstelle kurz vorgestellt. Im Weiteren wer-den die Komponenten fur Desktop-Delivery und fur parallele Ausfuhrung der Visualisierungeingefuhrt.

6.5.1 QT und VTK

Fur den Zweck der flexibleren, erweiterbaren und gut strukturierten Visualisierung der Datenaus der Simulation wurde den Visualization Toolkit von Kitware[SML04] verwendet. Fur dieseApplikation waren die Filters fur die Generierung von Konturen, Skalar Mapping, Stromlinienund Pfeile besonders interessant. Außer der Algorithmen fur die Darstellung von Stomungs-daten sind die Ansatze fur Desktop-Delivery und paralleles Rendering von VTK von großenBedeutung fur das entwickelte Steering-Systems.

Fur die bessere Verwendung der Visualisierung und fur die Steuerung von Simulationspa-rameter wurde zusatzlich eine Benutzerschnittstelle gebraucht. Die große Funktionalitat, diepraktischen Bedienelementen, die Leistung und die saubere Integration von VTK sind eini-ge der Vorteile der verwendeten QT-GUI Framework gegenuber andere Frameworks fur dieImplementierung von Benutzerschnittstellen.

Abbildung 6.4: Aufbau der QVTKWidget

Fur diese Integration wird den offentlichen Plugin QVTKWidget verwendet. In dem Pluginwerden Wrapper-Klassen fur die Hauptkomponenten einer VTK Applikation-die vtkRender-Window Klasse und vtkRenderWindowInteractor angeboten. Die erste wird immer verwendet,um ein VTK Fenster zu erzeugen. Die zweite Klasse fasst die Funktionalitat fur die Interak-tion(Manipulation der Szene und Widget Interaktion) mit dem Fenster zusammen.

6.5.2 Gitter-Aufbau und Streaming in VTK

In VTK werden funf Arten von grundlegenden Datensatze unterstutzt: vtkImageData (im-plizite Representation der Punkten und der Zellen-sehr kompakte Darstellung), vtkStructu-redGrid, vtkRectlinearGrid (fur regulare strukturierte Gitter), vtkPolyData und vtkUnstruc-turedGrid(fur unstrukturierten Gitter). Die unterscheiden sich nach Speicher Bedarf, Repra-sentation und Performanz.


Um eine generische Behandlung der aus der Simulation generierten Daten gewahrleistenzu konnen, wurde fur die Reprasentation der Daten die vtkUnsturcturedGrid Datenstrukturausgewahlt. Die erlaubt die identische Behandlung der regularen und der adaptiven Gitter. DiePunkten und die Zellen werden hier explizit dargestellt (stimmt mit den aus der Simulationraus geschriebenen Daten uberein). Die Zellentypen werden auch explizit spezifiziert. Dieaktuelle Implementierung benutzt Quaders(vtkQuad) und Voxels(vtkVoxel) als Zellentypen.

Die Datenattributen werden direkt mit den Zellen oder mit den Punkten assoziiert. DieAttributen von Kanten oder Seitenflachen werden nicht unterstutzt. Nach der Eingang derDaten des aktuellen Schrittes wird den Gitter neu aufgebaut. Es werden unterschiedlichenKollektionen fur die Zellen und Punkten erstellt(points- hat die Große n, polys-Große m).Zusatzlich werden Listen fur die Vektor Daten an den Vertices sowie fur die Skalar Datenalloziert. Dieser Vorgang kann in den folgenden Schritten aufgeteilt werden:

1. Einfugen der eikommenden Positionen der Vertices in die Points-Liste .

1 vtkIdType InsertNextPoint(const double x[3])

2. Einfugen der Konnektivitatsinformation in die Polys-Liste

1 vtkIdType InsertNextCell(vtkIdList *pts)

3. Einfugen von n Geschwidigkeitsvektoren in die Vektor-Data Liste

1 vtkIdType InsertNextTuple3(const double vv[3])

4. Einfugen von m Skalaren in die Skalar-Liste

1 vtkIdType InsertNextTuplel(const double s)

5. Setzen der Punkten, Zellen und Daten in das Gitter - hier werden die einzelnen Listenin die Datenstruktur kopiert.

6. Loschen der verwendeten Listen.

Die Schritte 1 bis 4 werden von einem Thread der Visualisierung ausgefuhrt. Die entspre-chenden Listen werden dann in eine Thread-sichere FIFO-Datenstruktur gespeichert und vorder Ausfuhrung des Rendering-Vorgangs fur das Gitter aktualisiert. Die letzten zwei Schrit-ten werden von dem Main-Thread ausgefuhrt. So wird das Thread-sichere nicht blockierendeStreaming der Simulationsdaten sichergestellt.

6.5.3 3D Widgets

Ein sehr machtiges Konzept fur die Interaktion innerhalb von VTK sind die 3D Widgets. Die3D-Widgets sind Kapselung von Geometrie und Funktionalitat , verwendet fur die Manipulati-on der Objekten in der Szene. Die 3D-Widgets unterscheiden sich von 2D-Interaktionseinrictungenwie die Maus in den Anzahl der Freiheitsgrade. Zum Beispiel hat die einfache Rechner-Mausnur zwei Freiheitsgrade(die x und y Achse). Ein 3D-Widget besitzt dagegen 6-DoF(Verschiebungund Rotation entlang jeder Achse). Aus diesen Grunden sind diese Werkzeuge sehr gut geeig-net fur die Interaktion mit der 3D-Szene.


Abbildung 6.5: Vererbungsdiagram der verwendeten 3D Widgets

Die 3D-Widgets sind direkt mit dem vtkRenderWindowInteractor gekoppelt. Jeder Werk-zeug ist registriert als Observer des Interaktors und reagiert auf Interaktionsereignisse (z.BBewegung der Maus oder Click). Dabei werden interne Aktionen(Markieren der Griffe desWidgets, Rotation, Verschiebung u.a.) und Benutzer definierten Callbacks aufgerufen. Bei-spielsweise kann in so einer Aktion die implizite Darstellung eines Widgets geholt werden undals Eingabe eines Filters verwendet werden. In 6.4 wird die typische Aufbau eines Callbacksgezeigt. Die eigentliche Aktion wird in der Execute Methode beschrieben

6.4: Ein benutzerdefiniertes Callback

1 class CustomWidgetCallback:public vtkCommand{2 protected:3 .4 .5 public:6 .7 .8 void Execute(vtkObject *caller, unsigned long, void*)9 {

10 some action11 }12 }

Die Exploration der Visualisierung in dieser Arbeit wird grundsatzzlich durch drei Wid-gets unterstutzt:der Line Widget, der Implicit Plane Widget und der BoundingBox Wid-get(Abb.6.5). Mit dem Line Widget werden Seed Punkten fur die Generierung von Strom-linien ausgewahlt. Der Implicite Plane Widgit wird fur die Manipulation von Schnittebenenverwendet. Die Selektion einer konkreten Ebene wird mittels der GUI gemacht. Die selektier-te Ebene kann rotiert und verschoben werden. Der letzte Werkzeug bietet Schnittstellen furdie Modifikation der Geometrie-Objekten an. Wahrend dieser Arbeit wurde nur die Verschie-bung der Objekten untersucht. Die vorhandene Funktionalitat kann leicht fur die Rotationund Skalierung der Geometrien angepasst werden.


6.5.4 Implementierung der Visualisierungsalgorithmen

In diesem Abschnitt werden die Details der Implementierung der grundlegenden Visualisie-rungstechniken aus Kapitel 3.5.4 vorgestellt.Zuerst werden die Techniken fur Skalar Datenvorgestellt und dann die Implemetirung der Algorithmen fur Vektordaten .

∙ Color Mapping: Das Color Mapping stellt eine sehr haufig verwendete, einfache undanschauliche Technik fur die Darstellung von Skalaren dar. Dabei werden die SkalarWerten des Gitters auf Farben gemappt. Dieses Mapping kann durch eine Farben-Lookup Tabelle gesteuert werden. Dabei kann die Tabelle automatisch oder manuelldurch die vtkLookupTable erzeugt werden. Die definierte Tabelle zusammen mit denSkalar Weren werden von einer vtkMapper Instanz fur die Berechnung der End-Farbenverwendet. Wichtig fur die automatische Erzeugung der Tabelle ist das Setzen der Grenz-bereichen durch die Methode SetScalarRange des Mappers. Im Weiteren wird der Map-per fur Steuerung des Auswahls des relevanten Attributs fur das Color Mapping ver-wendet. Die Methoden SetScalarModeToUsePointData, SetScalarModeToUseCellData,SetScalarModeToUsePointFieldData und SetScalarModeToUseCellFieldData erlaubendie Verwendung von Skalar Werten auf den Punkten , und auf den Zellen. Zusatzlichwird den Zugriff auf FieldData erlaubt.

∙ Konturengenerierung: Eine andere weit verbreitete Technik ist die Visualisierung durchKonturen. Die Konturen stellen Linien oder Flachen mit konstanten Skalar Großen. Furdie Anzeige solcher Linien wird das vtkContourFilter angeboten. Die Spezifikation derKonturwerten wird durch die folgenden Methoden durchgefuhrt:

1 void SetValue(int index,double value)2 void GenerateValues(int numOfContours,double range[2])

Die erste Methode erlaubt das Einfugen von einzelnen Konturwerten. Die zweite Funk-tion bekommt als Eingabe die Anzahl der zu generierenden Konturen und das Intervall,was bei der Generierung verwendet werden soll. Je nach Dimension der Daten wirdimplizit zwischen vtkMarchingSquares und vtkMarchingCubes Filters ausgewahlt.

∙ Generierung von Schnittebenen: Das Durchschneiden des Datenvolumen mit implizitbeschriebenen Funktionen (z.B Ebenen ) erlaubt die leichte Generierung von Schnittender Daten. In VTK wird diese Operation durch den vtkCutter Filter implementiert. DerFilter bekommt als Eingabe die implizite Beschreibung der Geometrie die geschnittenwerden soll. Nach der Beendigung der Operation konnen Konturengenerierungstechni-ken und Color Mapping angewendet werden. Der Vtk-Pipeline fur die Visualisierungmit Schnittebenen wird in Abb. 6.6 angezeigt.

∙ Glyphing

Das Glyphing(Abb.6.7) ist eine Technik fur die Darstellung von Daten durch Symbolen.Bei der Visualisierung von Stomungsfelder bietet sich die Moglichkeit, die Geschwin-digkeitsvektoren an bestimmten Punkten des Gitters mit Pfeilen zu reprasentieren. DieKlasse vtkGlyph3D ermoglicht die Erstellung von Glyphs. Die konnen skaliert, einge-farbt und rotiert werden. Der Filter besitzt dabei zwei Eingabeparameter: die Quelleund die Symboldarstellung.


Abbildung 6.6: Pipeline fur die Erstellung von Schnittebenen

Abbildung 6.7: Pipeline fur die Generierung von Glyphs


∙ Stromlinien

Abbildung 6.8: Pipelines fur die Generierung von Bahnlinien

Die Stromlinien reprasentieren die Bahn eines Partikel aus dem Stromungsfeld. Fur diebessere Exploration der Eigenschaften des Feldes werden mehrere Stromlinien erzeugt.Fur deren Erstellung muss zusatzlich eine Menge der Startpunkten ausgewahlt werden.Hierfur wird das beschriebene Line Widget verwendet. Fur die Integration wird dasRunge Kutta Verfahren der vierte Ordnung benutzt(vtkRungeKutta4). Zwei Implemen-tierung der Stomlinien wurden wahrend dieser Arbeit getestet: die vtkStreamTracer unddie vtkStreamLine(fur Glyphed Streamlines). Dabei wurden unterschiedliche Ergebnis-se bezuglich Performanz und Stabilitat betrachtet. In Abbildung 6.8 werden die beidenPipelines fur die Generierung von Bahnlinien angezeigt. Die Erzeugung der Stromlini-en und der Strombader geschieht anhand der vtkStreamTracer Klasse. Hier wird diegrundlegende Darstellung nur einmal innerhalb der vtkStreamTracer Klasse berechnetund die Ausgabe verzweigt.

Haufig ist die Visualisierung des kompletten Gitter mit Glyphs wegen der großenAuflosung zu aufwandig. Hierfur wird eine Mischung zwischen Stromlinien und Glyphsverwendet. Die Klasse vtkDashedStreamLine generiert gestrichelten Stromlinien. In ei-nem zweiten Schritt werden die durch die Anwendung des vtkGlyph3D Filter in Pfeilenumgewandelt.

∙ Strombander Fur die Visualisierung von Strombander wird die beschriebe Klasse furStromlinien(vtkStreamTracer) verwendet. Dabei wird zusatzlich die Verwirbelung mit-berucksichtigt. Fur die Einschaltung dieser Berechnung muss die Methode Compute-VorticityOn() aufgerufen werden. Die Ergebnisse werden als Eingabe fur das vtkRib-bonFilter, zustandig fur die Generierung von Bander, verwendet.

Fur die Algorithmen die durch 3D Widgets gesteuert sind, werden Factories erzeugt. Dieeigentliche Instanzierung geschieht durch den Aufruf der Methode GetExtendedWidget().Innerhalb der Methode werden die notwendigen Filters und Werkzeuge erstellt. Zusatzlich


werden die Controller-Klassen verantwortlich fur die Behandlung und das Mapping der GUIOperationen auf Methoden der Visualisierungsalgortihmen. Im Weiteren wird ein EventHand-ler fur jeden Widget instanziert. Als Ausgabe wird der eigentliche Widget zuruckgeliefert. Derwird dann in die Liste der Observers der Interactors eingefugt.

6.5.5 Die Geometrien und Szenarien

Abbildung 6.9: Aufbau der Geometrie-Klassen

Die Beschreibung der Geometrien geschieht in Klassen die von der abstrakten Geometrie-Klasse vererben. Jedes Geometrie-Objekt besteht aus zwei Darstellungen in der 3D-Szene: einefur den aktuellen Zustand des Objektes und eine fur den zukunftigen. Die zweite Darstellungwird als Drahtmodell angezeigt. Fur die Steuerung des zweiten Modells dient der eingefuhrtenBounding-Box Widget. Die aktuelle Implementierung unterstutzt die Darstellung von Kugeln.

Ahnlich wie bei den anderen Verfahren wird hier auch das Factory-Design Pattern verwen-det. Wichtig fur die Instanzierung sind die Methoden initializeVTK auf der Seite der Visua-lisierung und initializeQT auf der Seite der User Interface. Diese Methoden werden fur dieerzeugten Instanzen aufgerufen. Hier werden die einzelnen VTK(vtkSphere) und QT(Eintragin der Instanzliste und Erstellung der Properties fur die aktuelle Geometrie) Objekten ge-bildet und initialisiert. Die Hindernisse werden zusatzlich in einer Liste gesammelt, um diespater synchronisieren zu konnen.

Bei einer Aktualiserung der Geometrie durch die Bewegung des Box Widgets wird diegetInstance Methode des Objektes aufgerufen. Dabei wird ein Synronisationsobjekt zusam-mengebaut. Der 3D-Widget zustandig fur die Manipulation der Geometrien halt eine Referenzzu dem Outgoing-Puffer. Die Ausgabe der getInstance Methode wird auf den Puffer gelegt.Die Schlange wird von dem Sender-Thread abgearbeitet(serialisiert und geschickt). Diese Ab-arbeitungsequenz wird in Abbildung 6.10 dargestellt. Beim Eingang eines Geometrie-Paketeswird den aktuellen Zustand der Darstellung aktualisiert.

Die zukunftigen Erweiterungen der Geometrie-Klassen mussen die vorgestellten Interfacesimplementieren, um die richtige Darstellung und Funktionsweise der eingefuhrten Modelle zugewahrleisten.


Abbildung 6.10: Aufrufsequenz bei der Aktualisierung einer Geometrie

Bei den Szenarien wird das gleiche Modell verfolgt. Hierfur werden die Daten aus der Sima-lation durch Stubs-Klassen reprasentiert. Zustandig fur die Instanzierung der Stubs und derenControllers fur die GUI-Ereignisse ist die ScenarioFactory-Klasse. Hierfur wird die MethodeinitializeScenario aufgerufen. Jede Szenarion-Klasse besitzt Interfaces fur die Initialisierungder relevanten QT-Werkzeuge. Ahnlich wie bei den Geometrien wird beim Parameterwechseluber einen Werkzeug den entsprechenden Controller aufgerufen, einen Paket gebildet und aufden Puffer gelegt.


Nach Voraussetzung konnen die beiden Seiten des Steering Pipelines parallelisiert werden. InRahmen dieser Arbeit wird die MPICH2 Implementierung der Message Passing Interface furdiese Aufgabe verwendet. Dabei wird den parallelen Ablauf der Simulation und der Visualisie-rung unterstutzt. Die graphische Oberflache wird an der Stelle von der Visualisierung getrenntund als selbstandiger Prozess realisiert. Hierfur wird am Ende eines Rendering Schrittes einBild produziert und zu der GUI ubergetragen.

Ziel der Arbeit ist die Entwicklung einer geeigneten Methode fur die Realisierung einer N:1Beziehung zwischen Simulation und Visualisierung(vgl.Abb.6.11). Hier wird es angenommen,dass ein Visualisierungsserver die Betriebsmittel besitzt, um die Visualisierung von mehr alsein Simulationsclient zu unterstutzen.


Abbildung 6.11: Beziehung zwischen Simulationsclients und Visualisierungsserver

6.6.1 Parallelisierung in Peano

Bei der Parallelisierung des Simulationscodes handelt es sich um eine Datendekomposition.Hier wird eine Zerlegung des Volumens gesucht die eine lasttbalansierte Bearbeitung derDaten moglicht macht. Wichtig fur diese Zerlegung ist die Oberflache-Volumen Rate. Dabeibeschreibt die Oberflache die zu kommunizierenden Daten und das Volumen den eigentlichenBerechnungsaufwand jedes Prozesses.

Die aktuelle Methode beschrieben in [Wei09] ist ein Top-Down Ansatz. Dabei wird die De-komposition anhand der groberen Daten auf dem Gitter gemacht. Durch spezielle Kriterienwird es dann fur die Kinder entschieden, zur welchen Partition die gehoren sollen. Nach demAblauf dieser Iteration erfolgt eine Bottom-Up Lastbalansierung. Fur die dynamische Lastba-lansierung wird hier ein Master-Worker Konzept angewendet. Hierfur werden grundsatzlichzwei Operationen erlaubt: die Aufsplittung einer Partition(fork) und das Zusammenfassenmehrere Partitionnen(join). Als Synchronisationspunkten fur die einzelne Prozesse werdenden Anfang und das Ende eines Simulationsschrittes verwendet.

Jeder Peano-Prozess besitzt bei der Ausfuhrung eine Kopie der Geometrie und des aktuellenSzenarios. Bei einer Modifikation werden die Anderungen auf allen Prozessen propagiert.

6.6.2 Parallelisierung der Visualisierung

Durch die Zusammenarbeit zwischen Kitware, Los Alamos National Laboratory und Argon-ne National Laboratory entstandene Erweiterung der Standart API von VTK erlaubt dieparallele Ausfuhrung der Visualisierung auf Cluster Architekturen. In [ALS+00] werden dieunterschiedlichen Moglichkeiten fur die Verwendung der Parallelisierung in VTK beschrieben.Die Methode, die in dieser Arbeit behandelt wird, ist die Daten Parallelisierung. Dabei werdendie Daten zwischen den beteiligten Prozessen aufgeteilt. Auf die entstandenen unabhangigenPartitionen werden die Visualisierungsalgorithmen verwendet und die Ergebnisse unabhangig


gerendert. Im letzten Schritt werden die gerenderten Partitionen als Bilder exportiert undzusammengesetzt.

Das parallele Rendering in VTK wird anhand der Klasse vtkParallelRenderManager be-handelt. Die Klasse hort auf die Rendering Ereignisse eines Fensters. Bei dem Renderingwerden zwei Events ausgelost : Start Render Event und End Render Event. Nach dem Ein-gang des Start Render Ereignises werden RMI-Aufrufe zu den anderen Prozessen geschicktund deren Rendering Pipeline gestartet. Im nachsten Schritt holen sich die einzelne ProzesseInformationen fur die Szene aus dem Hauptfenster. Relevant hier sind die Kameraposition,Lichtquellen und Große des Fensters. Als nachstes startet die PreRendering-Phase. Hier kon-nen Vorbereitungsschritte vor dem Rendering ausgefuhrt werden. Beispielsweise wird an derStelle die Aktualisierung des Gitters durchgefuhrt. Nach diesem Schritt wird die Kontrollezu den vtkRenderWindow zuruckgegeben und die Bildsynthese ausgefuhrt.Am Ende wird dasEnd Render Event des Parallel Managers aufgerufen und so wird die Post-Rendering Pha-se gestartet. Hier finden die Nachbearbeitungsschritte statt, wie das Zusammenstellen desEndbildes. Der Gesamtprozess wird in Abbildung 6.12 dargestellt.


Abbildung 6.12: Interaktionen des parallelen Managers wahrend Rendering vgl.[MT03]


Fur die Realisierung der N:1 Beziehung zwischen Simulationsclients und Visualisierungsser-ver wird das Daemonen-Prinzip fur Sockets verwendet. Nach dem Binden des Sockets an einemPort wird einen Listen-Socket fur N Verbindungen aufgebaut. Danach erfolgt das Abwarteneiner Verbindung mit einem Client durch Aufruf der accept Funktion. Nach der Eingang soeiner Verbindung wird ein Clientsocket notwendig fur die Weiterfuhrung der Kommunikationmit diesem Client erzeugt. Zusatzlich wird ein Gitter fur diese Verbindung angelegt und indem vtkAppendFilter eingefugt Der folgende Pseudocode zeigt diese Funktionsweise:

6.5: Pseudocode fur die Erstellung der Daemonen

1 //Binden an einem bestimmten Port2 bind(socket,port);3 //Aufbau eines Listen Socket für N Verbindungen4 lsocket=listen(socket,N);5 while(Bedingung)6 {7 clientsocket=accep(lsocket);8 erstelle Gitter und verknüpfe es mit einem Input Port der

vtkAppendFilter Instanz9 starte sender und receiver Thread für clientsocket

10 }11 //Schließe alle Verbindungen12 close();

Bei dem Eingang von neuen Daten fur den aktuellen Zeitschritt aus der Simulation wird denentsprechenden Gitter aktualisiert. Vor dem Rendering-Prozess wird eine Modify Operationauf der vtkAppendFilter Instanz aufgerufen. Dabei werden die aktuellen Daten aus allenInputports gemergt und zum Mapper weitergeleitet.

Fur die Verwaltung der Puffer fur die einzelnen Clients auf einem Server werden Singleton-Klassen verwendet. Die ermoglichen das Broadcasting von Paketen auf alle Puffer.

Wie schon erwahnt werden die Geometrien redundant auf jedem Visualisierungsprozessdargestellt. Die Manipulation anhand des 3D-Bounding Box Widgets wird nur auf dem RootProzess durchgefuhrt. In dem Callbackhandler des Widgets wird die Darstellung zu der an-deren Prozesse durch RMI Aufrufe weitergeleitet. Bei jedem Aufruf wird zusatzlich einenModifikationsevent ausgelost. Das verursacht die Erstellung und das Pushen(Einfugen in dieensprechende Sending Queue) von einem Modifikationspaket auf alle Prozesse. So wird jedesProzess der Simulation aktuell gehalten.

Außer fur die Behandlung der Rendering Events und fur die Komposition der einzelnenBilder besitzt der beschriebene Manager eine Reihe von zusatzlichen Funktionalitat:

∙ Factory Methoden Es werden Methoden fur die konsistente Erstellung des Fensters unddes Renderers angeboten. Die Objekte die anders erstellt werden, sind fur das paralleleRendering nicht geeignet.

∙ Bildabbau Hier werden Filter fur die verlustlose Komprimierung und Dekomprimierungder Bilder verwendet.


∙ Bild-Caching In der Kompositionsphase(Post-Rendering) kann passieren, dass ein Bildmehrfach gelesen werden soll. Das Bild wird fur die Verwendung von mehreren Managersgecacht.

Die meisten der ausgewahlten Visualisierungsmethoden sind gut parallelisierbar. Dabeifunktionieren die auf lokalen Datenmengen. Bei der Berechnung der Bahnlinienalgortihmenmuss die Integration des Vektorfeldes uber die Grenzen der Domain eines Prozesses ausgehen.Diese Modifikation wurde in dieser Arbeit nicht weiter betrachtet. Fur die Steuerung der Pa-rameter der einzelnen Verfahren wird das eingefuhrte RMI Konzept wie folgt weiterentwickelt:

∙ Synchronisation der impliziten Darstellungen von Widgets: ahnlich wie bei den Widgetsfur Geometrie werden die Line Widget und die Implicit Plane Widget fur den parallelenBetrieb der Visualisierung angepasst. Hierfur wird der Widget nur in dem Root Prozessdargestellt und bei den anderen Prozessen nur die implizite Beschreibung davon uberge-tragen. Nach der Interaktion mit dem Widget erfolgt die Synchronisation der einzelnenDarstellungen.

∙ Globale Steuerung von Mappers,Actors und Widgets: Fur das Setzen der Sichtbar-keit bestimmter Elemente aus der Szene oder fur den Auswahl der relevanten Datenfur Color-Mapping(Cell Data, Vector Data) werden bestimmte Funktionen der entspre-chenden Mappers und Actors aufgerufen. Hierfur wurde ein Pool-Mechanismus fur dieSynchronisation dieser Elementen wegen der redundanten Darstellung auf jedem Teil-nehemer an der Visualisierung entwickelt. Dabei verwaltet jeder Prozess einen Pool vondiesen Objekten. Bei der Veranderung eines Parameters in dem Root-Prozesses wirdeinen RMI-Aufruf zu den anderen Prozessen ausgelost. Dabei erfolgt die Ubertragungeiner Identifikation0 des geanderten Elementes sowie der gesteuerten Parameter. In Ab-bildung 6.13 wird ein Beispielszenario fur den Wechsel der Sichtbarkeit eines Actorsgezeigt.

∙ Steuerung von erweiterbare Widgets: Bei den Klassen fur die Darstellung von Schnit-tebenen werden zusatzlich RMIs fur die Ausrichtung, Einfugen und Loschen von Ebeneneingerichtet. Dabei ruft der i’te Prozess die entfernte Methode des i + 1 Prozesses miti < N − 1

6.7 Desktop Delivery

Die raumliche Trennung zwischen Wissenschaftler und die Visualisierungsscluster setzt dasVerwenden von Desktop-Delivery Techniken voraus. Im Laufe der Arbeit wurden zwei Tech-niken evaluiert. Die erste verwendet das offentliche Software VirtualGL. VirtualGL gibt dieMoglichkeit fur die entfernte Ausfuhrung von OpenGL Anwendungen. Dabei wird die 3D-Szene zusammen mit den Bedienelementen der GUI als ein Bild zum Client ubergetragen.Die zweite Losung erlaubt die Trennung zwischen GUI und Visualisierung und damit auchdie parallele Ausfuhrung der Visualisierung. Diese Losung baut sich auf den Desktop-DeliveryKlassen von VTK. Die erlauben die Erstellung einer Sicht der von Visualisierungscluster dar-gestellten Daten.

0Fur das Auffinden von Elementen in den Prozess-Pool werden IDs verwendet.

6.7 Desktop Delivery Seite 73

Abbildung 6.13: Interaktionen zwischen einzelnen Prozessen bei Steuerung der Sichtbarkeiteines Actors

6.7.1 VirtualGL

Ein großer Teil der Anwendungen fur Remote Rendering ubertragen die Befehle der Biblio-thek, die fur die Visualisierung verwendet werden(z.B. OpenGL), zusammen mit den 3D-Daten zu den Client. Die Befehle werden dann auf dem Client-Rechner ausgefuhrt. Nachteildieser Methode ist der hohe Netzlast, der wegen der Große der Daten produziert wird unddie schlechte Ausnutzung der Rendering-Betriebsmittel des Servers.

In VirtualGL werden die Befehle zu den Grafikhardware des Servers umgeleitet. Die ver-wendete Technik dabei wird noch Split-Rendering genannt. Die auf dem Server laufende Ap-plikation wird um ein Dynamic Shared Object(DSO) erweitert. Dieses Objekt ist zustandigfur die Behandlung und Weiterleitung der Rendering Befehle. Am Anfang wird einen PixelPuffer auf die Grafikhardware angelegt. Bei der Erstellung von dem 3D-Inhalt wird eine Kopiedieses Inhaltes in den Puffer angelegt. Bei dem Aufruf des Austausch-Befehls der Puffer wirdein Bild generiert und zum Client weitergeleitet.

Drei Modi werden fur die Ubertragung des Bildes unterstutzt:

∙ VGL Image Transport-Direkt Modus: Dieses Modus wird verwendet, wenn der 2D X-Server durch Netzwerk von der Applikationsserver getrennt ist.


Abbildung 6.14: VGL Image Transport mit Remote 2D X Server

Dabei wird ein eigenes Protokoll fur TCP bei der Ubertragung der kodierten Bilder ver-wendet. Eine Echtzeit-Komprimierung und Dekomprimierung ist moglich(z.B. Turbo-JPEG). Die Bilder werden dann von dem VGL-Client dekodiert.

∙ VGL X11 Image Transport: In diesem Mode werden die Bilder auf X-Proxys auf demServer gemalt. Die X-Proxys sind virtuelle X-Server, die einen entfernten Server repra-sentieren. Dabei werden die als normale X-Server wahrgenommen. Der Haupt Unter-schied zu der direkten Ubertragung der Befehle zusammen mit Daten besteht darin,dass das Rendering auf einem Puffer des Serversspeichers passiert. Die Komprimierungder Bilder wird hier von den X-Proxies ubernommen.

Abbildung 6.15: X11 Image Transport mit X Proxy

∙ Sun Ray Image Transport: Das letzte Modus ist speziell fur die Sunray thin ClientUmgebungen entwickelt. Der Ansatz ahnelt dabei die X11 Image Trasport Methode.Dabei werden die X-Proxies durch Sun Ray Server ersetzt. Problem bei den Sun RayClients sind die relative begrenzten Hardware Betriebsmittel. Deshalb wird eine zweiteUbertragungsmoglichkeit direkt von VirtualGL zum Sun Ray Client unterstutzt.


Abbildung 6.16: Sun Ray Image Transport

6.7.2 Desktop Delivery in VTK

Fur die Realisierung der Desktop Delivery in VTK wird ein Client/Server Modell verwendet.Die zustandigen Klassen dafur sind die vtkPVDesktopDeliveryClient und vtkPVDesktopDeli-veryServer. Um diese Schema verwenden zu konnen, muss der Root Prozess fur die Visualisie-rung uber zwei Managers verfugen: der vtkCompositeRenderManager und der vtkPVDesktop-DeliveryServer. Der erste ist zustandig fur die Durchfuhrung des parallelen Renderings undder zweite fur die Bereitstellung des Endbildes fur den Client.

Fur die Durchfuhrung der Kommunikation zwischen den einzelnen parallelen Prozessen,sowie zwischen Client und Server werden Kommunikationscontrollers gebraucht. Hierfur wirdein MPI Controller fur die Visualisierungsprozesse verwendet(vtkMPIController). Die Client-Server Kommunikation wird anhand eines Socket-Controllers gesteuert(vtkSocketController).Die beiden Klassen gewahrleisten die Transparenz der Transportschicht. Wegen der Integra-tion des Clients in der User Interface ist die MPI Ausfuhrung nicht sinnvoll.

Der Delivery-Client hat die Aufgabe die Benutzereingabe zu erhalten und die zum Serverweiterzuleiten. Er ist noch zustandig fur die Darstellung des Endbildes. Der Server kummertsich um die Durchfuhrung der Renderingpipeline. Bei eine vorhandene Parallelisierung derVisualisierung muss er die einzelnen Rendervorgange der anderen Prozessen anstoßen. EinRendering-Vorgang zwischen Client und Server wird in Abbildung 6.17 angezeigt. Der Cli-ent wird als Oberserver der Rendering-Ereignisse des Fensters registriert. Bei dem Auslosendes Renderingvorgangs wird eine Anforderung zur Durchfuhrung der Renderingpipeline anden Server geschickt. Nachfolgend werden gewisse Beschreibungsparamter fur die KameraPosition und fur die Konfiguration des Fensters ubergetragen. Auf der Server-Seite wird derAufruf zu den Kinder-Prozesse(im Fall von einer parallelen Ausfuhrung der Visualisierung)weitergeleitet. Erst nach der Beendigung der einzelnen Pipelines und die Komposition dereinzelnen Bilder in einem Gesamtbild wird das Ergebnis zum Client zuruckgeliefert. An derStelle wird die Aufmerksamkeit des Lesers an die Ahnlichkeit der beiden Modelle fur dieDesktop-Delivery und das Modell fur die parallele Ausfuhrung der Visualisierung 6.12 ge-wendet. Die Client/Server-Klassen und die vtkCompositeRenderManager Klasse sind Ablei-tungen der vtkParallelRenderingManager Klasse. Diese Eigenschaft erlaubt das Nutzen beim


Dekstop-Delivery von zusatzlichen Funktionen wie Bildreduktion, Bildcaching und Objekter-stellung.

Abbildung 6.17: Ablauf des Renderingvorgangs bei der Verwendung von Desktop-Deliveryvgl.[MT03]


Die so eingefuhrten Klassen sind nur fur die Betrachtung einer schon definierten 3D-Szenegut geeignet. Die Interaktion mit 3D-Widgets aus dem Client-Applikation ist mit der ak-tuellen Klassen unmoglich. Im Weiteren wird eine Erweiterung der Klassen um Remote-Interaktionselementen vorgestellt.

Durch die Verwendung der Dekstop-Delivery wird das Wissen des Clients uber die 3D-Szene verringert. Dabei ist nur das aktuelle 2D-Bild bekannt. Um die Interaktion mit denWidgets aus der Server-Szene zu erlauben mussen die Input-Controller Aktionen zum Serverubergetragen werden. Die grundlegenden Input-Cotroller Routinen werden in VTK als Stylesdes Interaktors definiert. Durch Uberschreiben der Funktionen konnen neue Interaktionsmo-delle spezifiziert werden. In der aktuelle Implementierung wird das Trackball Interaktions-modell(vtkInteractorStyleTrackballCamera) verwendet. Dieses Modus erlaubt die Rotation,Schwenken und andere Operationen mit der Kamera. In dem definierten Style werden dierechte Maustaste fur die Kameraoperationen(ursprunglich durch die Linke Maustaste) undlinke fur die Interaktion mit verschiedenen Widgets verwendet. Die Knopfe Shift und Steue-rung erlauben die Verschiebung entlang einer Achse und das Schwenken. In der folgendenAuflistung werden die uberschriebenen Signaturen gezeigt:

1 virtual void OnMouseMove()2 virtual void OnLeftButtonDown()3 virtual void OnLeftButtonUp()4 virtual void OnMiddleButtonDown()5 virtual void OnMiddleButtonUp()6 virtual void OnRightButtonDown()7 virtual void OnRightButtonUp()

Bei jeden der uberschriebenen Methoden wird am Anfang die Information fur das Interak-tionsereignis gesammelt. Als nachstes wird die entsprechende entfernte Methode des Serversaufgerufen und das Ereignis dort ausgelost. Bei bestimmten Events wie z.B. OnLeftButton-Down, OnLeftButtonUp oder OnMouseMove kann der Fall auftreten, dass das Ereignis eineninternen Rendering-Vorgang verursacht hat(Beispielsweise bei der Bewegung der Maus uberden Griffpunkt eines Widgets) und das fuhrt den Client in einen inkonsistenten Zustand. Esist zu beachten, dass die Renderingvorgange nur von dem Client angestoßen werden konnen.Um dieses Problem zu losen wird bei der Bearbeitung der drei Ereignisse uberpruft, ob eineninternen Renderingvorgang stattgefunden hat. In diesem Fall wird vom Client ein Renderingangestoßen.

Im Weiteren werden in 6.6.2 vorgestellten Pool-Mechanismen fur die Steuerung von Map-pers, Actors und Widgets auch in dem Fall der Cliet/Server Desktop-Delivery angewendet.

Seite 78 7 Auswertung

7 Auswertung

Die heutigen Umgebungen fur Computational Steering unterscheiden sich in vielen Aspektenbezuglich Ansatz, Performanz, Kommunikation und anderen Punkten. Viele der entwickeltenSysteme sind speziell fur die Exploration von bestimmten Simulationen erstellt und andereAnsatze konzentrieren sich auf die generischen Implementierung fur beliebigen Simulation.In diesem Kapitel wird einen Vergleich bezuglich zwischen dem aktuellen Ansatz und zweianderen Steering Systeme der Funktionalitat durchgefuhrt. Im Weiteren wird die Integrationder in 5 vorgestellten Visualisierungskonzepte und die Moglichkeiten zur Steuerungsschnitt-stellen bewertet. Im letzten Teil erfolgt die Speedup-Analyse der entwickelten Paralleliserungdes Steering-Prozesses auf moderne Linux-Cluster Systeme.

7.1 Funktionaler Vergleich mit anderen Steering-Ansatzen

Der Aufbau einer generellen Klassifizierung von verschieden Steering Anwedungen hat sich alskomplizierte Aufgabe erwiesen. Einige der Grunden dafur sind die unterschiedlichen Ausrich-tungen der einzelnen Systeme(generische Ansatze vs. simulationsspezifische ). Der nachfolgen-de Vergleich basiert sich auf das in [MvWvL98] vorgestellte Schema. Die einzelnen Systemewerden bezuglich verschieden Aspekten verglichen. Die werden in drei Gruppen zusammen-gefasst: Anwendungsbereich, Architektur und User Interface.

Unter dem Anwendungsbereich eines Steering-Framework werden die folgenden Punktenzusammengefasst:

∙ Exploration: Welche Explorationsarten werden von der Applikation unterstutzt? Dabeiwird zwischen Modellexploration, Alogithmen-Exploration und Performanz Explorationunterschieden. Die Bedeutung der drei Arten wurde in Kapitel 3.7 eingefuhrt.

∙ Kompabilitat des Steering Frameworks mit bereits vorhandenen Simulationsapplioka-tionen und zukunftigen Simulators

∙ Verteilung: Hier wird es geklart, welche Teile des Steering-Prozesses verteilt ausgefuhrtwerden konnen.

∙ Colloborative Exploration: Ist die Verwendung des Softwares von mehr als einen Benut-zer gleichzeitig moglich.

Die Architektur wird bezuglich der folgenden Punkten bewertet:

∙ Annotierung der Applikation: Wie werden die einzelnen Parameter, die uberwacht wer-den sollen, registriert.

∙ Daten Zugriff: Wie werden die relevanten Daten aus der Simulationsgitterstrukturengesammelt.

7.1 Funktionaler Vergleich mit anderenSteering-Ansatzen Seite 79

∙ Steering der Parameter

∙ Synchronisationskonzepte

Graphische Oberflache:

∙ Daten Reprasentation: Was fur Modelle und Verfahren werden fur die Darstellung deruberwachten Parameter verwendet.

∙ User Interaktion: Welche Werkzeuge und Konzepte unterstutzen den Benutzer bei derInteraktion mit der Szene.

Im Folgenden werden zwei andere Frameworks fur Steering vorgestellt und mit aktuellenAnsatz bezuglich des vorgestellten Modell verglichen. Hier handelt es sich um die folgendenzwei Applikationen: Progress und CUMULVS

Progress([VS95]) ist ein Steering-Framework entwickelt in Georgia Institute of Technology.Die Abkurkzung Progress steht fur Programm und Resource Steering System. Im folgendenwerden die drei Punkten fur die Klassifizierung fur die Applikation naher betrachtet:

∙ Anwendungsbereich: Progress unterstutzt Modell- und Performanzexploration. Die An-notation des Simulationscodes wird von einem Entwickler durchgefuhrt und erlaubt dieUberwachung von relevanten Daten der Simulation. Der Simulationsprozess kann vondem Steering-Schnittstelle durch ein Netzwerk getrennt sein. Die colloborative Verwen-dung wird nicht unterstutzt.

∙ Architektur: Progress ist eine Implementierung des Client/Server-Modells. Fur die An-notation des Codes werden Steering Objekten erstellt. Diese Objekte unterstutzen diefolgenden Operationen: probe(fur asynchrones Lesen und Schreiben des Objektes), sen-se(synchrones Snapshot des Objektes) und actuate(fur synchrone Veranderungen). DurchDefinition von Synchronisationspunkten konnen Stellen in dem Code festgelget wer-den fur das Stoppen der Simulation . Zusatzlich wird die Ausfuhrung von Funktionenund Skripten auf den Objekten unterstutzt. Die Funktionen sind dabei vordefiniertenMethoden der Simulation und werden verwendet fur die Modifikation von spezifischenDatenstrukturen. Die Skripten fassen Gruppen von Steering-Befehle zusammen.

Im Laufzeit besteht die Applikation aus einem Server und einem Client. Der Server vonProgress lauft in dem selben Prozessraum wie die Simulation und ist zustandig fur dasSammeln der uberwachten Daten, die Kommunikation mit den Client und die Steuerungder Simulation. Der Client hat die Aufgaben die Benutzerinteraktion zu realisieren, dieKommunikation mit dem Server zu behandeln und die Verwaltung.

∙ GUI: Der Client stellt eine Konsole und eine graphische Oberflache fur die Steuerungdes Steering-Servers zur Verfugung. Die Befehle zur Uberwachung und Modifikation vonParameter werden an Knopfe und Textfelder gemappt. Kompliziertere Befehle konnenin die Konsole eingegeben werden. Fur eine 3D-Darstellung mussen Schnittstellen zuexternen Applikationen definiert werden.


Das zweite Software Paket betrachtet in diesem Vergleich ist CUMULVS(Collaborative UserMigration, User Library for Visualization and Steering-[GKP97]), entwickelt bei Oak RidgeNational Laboratory.

∙ Bereich: CUMULVS bietet Funktionalitat fur Modell- und Performanzexploration. Eswird als Erweiterung von existierenden Simulationsapplikationen verwendet. Eine collo-borative Verwendung wird unterstutzt. Im Weiteren wird einen Recovery-Mechanismusangeboten. Das erlaubt das erleichterte Zurucksetzten zu einem konsistenten Zustandbei Auftritt einer Fehler.

∙ Architektur: CUMULVS besteht aus zwei Teilen : einen Teil fur die Simulationsappli-kation und einen fur die Visualisierungs- und Benutzerschnittstellen. Die beiden Tei-le beinhalten die Funktionalitat notwendig fur die Verknupfung einer Applikation mitmehreren unabhangigen Visualisierungen und User Interfaces. Eine Benutzer-gesteuerteDekomposition der Daten auf mehrere Prozesse wird unterstutzt. Die Annotation dersteuerbaren und uberwachbaren Parameter wird auch vom Benutzer gemacht. DieseDaten werden fur das Benutzer-definierte Checkpointing und Recovery verwendet.

Fur die Steuerung wird eine synchrone Verbindung mit der Applikation aufgebaut.Die garantiert die Ausfuhrung aller Anderungen auf der Seite Simulation. Fur die Ver-meidung von Veranderungen gleicher Parameter aus unterschiedlichen Benutzer werdenSperren fur die Variablen vergeben.

Fur das Checkpointing wird ein eigenes Prozess verwendet. Die Fehlertoleranz-Logikund Variablen werden dabei vom Entwickler bestimmt. Beim Auftreten eines Fehlerswird das Rollback automatisch von dem CUMULVS-System durchgefuhrt.

∙ User Interface: CUMULVS bietet eine textuelle Schnittstelle und eine GUI, implemetiertmittels Tcl/Tk, an. Fur die Darstellung der 3D-Daten wird ein AVS-Sicht verwendet.Die Manipulation der Parameter wird anhand der textuellen Schnittstelle und der GUIdurchgefuhrt.

Die aktuelle Implementierung unterscheidet sich in einigen Punkten von den vorgestelltenzwei Software-Systeme. Im folgenden werden die Punkten der vorgestellten Bewertungsschemaeines Steering-Frameworks bezuglich die in dieser Arbeit beschriebene Losung betrachtet.

∙ Bereich: Ahnlich wie bei den vogestellten Systemen bietet der aktuelle Ansatz Funktio-nalitat fur Modellexploration und Performanz-Optimierung(Steuerung der LoD-Datenstrukturen). Das System wurde fur die Erweiterung einesvorhandenen Simluationsframeworks verwendet. Die verteilte Ausfuhrung der einzelnenProzesse wird unterstutzt. Die aktuelle Implementierung ist Single-User Betrieb fahig.Es wird zwischen Benutzer und Entwickler unterschieden.

∙ Architektur: Das System besteht aus dem Simulationsclient und zweiServer: Visualisierungsserver und UI-Server. Die getrennte Implementierung der GUIund der Visualisierung erlaubt die Verwendung von Parallelisierungsschemata fur dieVisualisierung. Ein Dekstop-Delivery Client-Server Modell wird fur die Integration von

7.1 Funktionaler Vergleich mit anderenSteering-Ansatzen Seite 81

GUI und Visualisierung verwendet. Fur die Annotierung der Paramter fur Uberwa-chung und Steering werden Mechanismen wie Serialisierung und synchrone Paketver-waltung durch Pufferung verwendet. Die Annotierung wird vom Entwickler durchge-fuhrt. Schnittstellen in den entsprechenden Klassen definieren die relevanten Parameter.Der Simulationsablauf wird durch die Kommunikation zwischen Simulationsclient undSteering-Applikation nicht blockiert.

∙ Benutzerschnittstelle: Fur die Implementierung der Benutzerschnittstelle werden die QTund VTK Bibliotheken verwendet. Dabei werden die Visualisierung und eigentliche UIgetrennt implementiert und in einem Client-Server Modus ausgefuhrt. Die Verknupfungder beiden passiert durch Desktop-Delivery Komponenten. Dabei werden auf der UInur Bilder der 3D-Szene angezeigt. Das erlaubt die Verwendung von Rechner mit weni-gen Betriebsmittel fur die Darstellung der UI. Die verwendete Bibliothek VTK fur dieVisualisierung eroffnet die Moglichkeiten fur zahlreiche Visualisierungsalgorithmen unddie Parallelisierung der entstehenden Berechnungen. Die Steuerung von Parameter wirdanhand von der UI und durch spezielle 3D-Werkzeuge 6.5.3 aus VTK realisiert.

Die nachfolgende Tabelle 7.1 fasst die vorgestellten Steering-Systeme zusammen. Keiner derdrei Systeme bietet alle Explorationsarten. Alle verwenden fur die Kommunikation und Daten-austausch eine Variante des Client/Server-Modells. In CUMULVS und dem aktuellen Ansatzwerden Mechanismen fur die Dekomposition der Daten eingefuhrt.

Abbildung 7.1: Zusammenfassung der Eigenschaften von Progress, CUMULVS und der aktu-ellen Arbeit(PeanoFE)


(a) Color Mapping mit Werten an den Zellen (b) Color Mapping mit den interpolierten Wertenan den Vertices

Abbildung 7.2: Visualiserung von Skalaren mit Hilfe von Color Mapping(Obsticle in ChannelScenario): a) Color Mapping-Zellen, b) Color Mapping Vertex

7.2 Visualisierunsergebnisse

Die im Abschnitt 3.5 vorgestellten Algorithmen wurden mit Hilfe der offentlichen BibliothekVTK implementiert. Es handelt es sich um eine CPU Implementierung der Methoden. Ei-nige der Verfahren wurden mit speziellen Widgets unterstutzt(Streamlines, Cutting-Planes)um deren Utility fur den Benutzer zu erhohen. Die Implementierung aller Methoden fur diesinnvolle Visualisierung von Stromdaten geht außerhalb der Grenzen dieser Arbeit. Hierfurwerden Verfahren die vom Bedeutung fur die Uberwachung und Steuerung von CFD-Dateninnerhalb eines Steering-Frameworks seien konnen prototypisch implementiert und bewertet.Deshalb wurde den Auswahl fur klassischen und gut parallelisierbaren Methoden getroffen.

7.2.1 Color Mapping und Konturengenerierung

Abbildung 7.3: Konturengenerierung : 20 Werte fur den Druck zwischen 0 und 0.1

Die verwendeten Techniken fur die Darstellung der Skalar und Vektordaten anhand vonFarbwerten haben sich als eine praktische, effiziente und intuitive Methode erwiesen

7.2 Visualisierunsergebnisse Seite 83

(Abbildungen:7.2(a),7.2(b)). Die Visualisierung von Daten der Zellen und der Vertices wirdunterstutzt.

Die fallenden Skalaren auf den Vertizes machen die Verwendung eines Interpolationsverfah-rens fur deren Approximation notwendig und das resultiert in dem Verlust der Genauigkeitder Darstellung (Abbildung 7.2(b)).

Die Konturengenerierung erlaubt die anschaulische Darstellung von Bereiche der spezifi-zierten Skalar Werten. Die Technik (7.3) kann auch als Volume-Rendering Technik verwendetwerden. Die steigende Anzahl von Konturwerten erhoht den Approximationswert des Volu-mens. Nachteil dabei ist der steigende Aufwand fur die Berechnung.

7.2.2 Schnittebenen

Abbildung 7.4: Schnittebenen : Darstellung von vier Schnittebenen. Fur die Anzeige der se-lektierten Ebene werden Konturen verwendet.

Eine andere Technik fur die anschauliche Darstellung der vorhandenen Daten ist die Ge-nerierung von Schnittebenen. Die Schnittebenengenerierung wird durch die GUI angestoßen.Die Manipulation der einzelnen Ebenen passiert innerhalb der 3D-Szene mit Hilfe eines Wid-gets. Zwei Darstellungsmodi werden unterstutzt: Color Mapping undKoturengenerierung(Abb.7.4 )


7.2.3 Bahnalgorithmen

Abbildung 7.5: Strombander in Obstacle in Channel 3D

In der aktuellen Implementierung wurden drei Methoden fur die Darstellung von Vektorfel-der anhand von Bahnlinien bezuglich deren Nutzwert fur das Steering evaluiert : die Strom-linien, die Strombander und die Glyphed-Stromlinien. Das Seeding bei alle drei wird durchdas Line Widget durchgefuhrt. Die Ergebnisse sind in Abbildungen 7.5,7.6(a),7.6(b) ange-zeigt. Der Unterschied zwischen den einfachen Methoden fur die Berechnung der Stromlinienund den lokalen Methoden fur die Strombander wird durch die in Abbildung 7.5 angezeigteVerwirbelung deutlich.

(a) Streamlines (b) Dashed Streamlines mit Glyphs

Abbildung 7.6: Visualiserung von Vektorfelder: a) Stromlinien b) Glyphed-Stromlinien

7.3 Steering Seite 85

7.3 Steering

Die Veranderbarkeit von Parameter ist ein wichtiger Teil eines Steering Frameworks. Im fol-genden werden die implementierten Ansatze fur Manipulation von Objekten in der Szeneevaluiert. Hierfur wurde ein Obstacle-in-Channel Szenario in 3D mit regularen Gitter und in2D mit adaptiven Gitter getestet. In dem regularen Fall wurde eine Auflosung von 100x41x41Zellen verwendet.

Abbildung 7.7: Das dargestellte Szenario ist Obstacle in channel mit einer Kugel. Die zweiteKugel wurde zum Laufzeit eingefugt. Rechts unten werden die Eigenschaftender selektierten Geometrie angezeigt.


(a) Anfang der Bewegung eines Kugels (b) Wahrend der Bewegung eines Kugels

Abbildung 7.8: Durchfuhrung einer Bewegung durch das Bounding Box Widget

In der heutigen Techniken fur CFD spielen die Verfahren fur Fluid Structure Interakti-on eine wichtige Rolle. Ein Hauptpunkt dieser Arbeit war die Entwicklung von passendenSchnittstellen zu dem in [Unt09] vorgestellten Ansatz fur Manipulation der Objekten in derSzene. Im Konkreten wurde dieses Verfahren fur die Verschiebung, Loschen und Einfugen vonObjekten verwendet. Fur die Verschiebung wurde ein Boundig-Box Widget eingesetzt. Zu-satzliche GUI-Viewers (eine Liste der instanzierten Geometrien und die Eigenschaften diesesObjektes-Abb.7.7) erlauben das Monitoring des aktuellen Zustands eines Hindernisses. Wiedie Abbildung 7.8 zeigt werden zwei Objekten fur die Durchfuhrung einer Bewegung ange-zeigt. Die Abbildung 7.8(a) stellt den aktuellen Zustand der Geometrie dar und 7.8(b) denzukunftigen. Das erhoht das Verstandnis bei einer langsameren Simulationsdurchfuhrung.

Abbildung 7.9: Bewegung einer Kugel in adaptiven Gitter mit LoD Prunning


Abbildung 7.10: Vergleich der Laufzeit der Simulation bei Bewegung mit und ohne LoDPruning

In dem Fall von adaptiven Gitter konnte die implementierte Schnittstelle nur fur 2D evalu-iert werden . Das in 5.3 eingefuhrte Mechanismus fur Vergroberung wahrend der Bewegunghat zu den erwarteten Verbesserungen der Laufzeit des Algorithmus gefuhrt. In Abbildung7.9 wird die Durchfuhrung einer Bewegung in adaptive Gitter angezeigt. Bei der Interaktionwird eine LoD Pruning um zwei Stufen verwendet. Die Unterschieden in der Laufzeit wahrendder Bewegung mit und ohne LoD Prunning werden in 7.10 dargestellt. Es ist zu beachten,dass im letzten Schritt die ursprungliche Verfeinerung wiederherstellt werden muss.


Ein weiterer Aspekt dieser Arbeit war die Erforschung der Moglichkeiten fur die paralleleAusfuhrung der Visualisierung auf Gridarchitekturen. Das verwendete Verfahren beruhen sichauf den Klassen fur die Sort-Last paralleles Rendering der VTK und auf den Konzepten furRMI-Kommunikation.

Die aktuelle Implementierung verwendet das SIMD(Single Instruction Multiple Data) Mo-dell als haupt Baustein fur die Parallelisierung. Dabei handelt es sich um eine Daten Paralle-lisierung. Zwei Methoden wurden im Laufe der Arbeit getestet. Die erste Methode verwendetdie schon vorhandene Domain Dekompostion, die von Peano erzeugt wurde, und wendet dieInstruktionen fur die Visualisierung auf den einzelnen Blocke an. Die zweite Methode mergtdie Daten auf einem Prozessor und dann werden die raumlich zerlegt und an den Worker CPUsweitergeleitet(Kd-Tree Dekomposition -D3:Distributed data decomposition). Der Zerlegungs-schritt und die Verteilung der Daten haben sich als zeitraubend erwiesen und deshalb wurdedie schon berechnete Dekomposition von Peano in der Implementierung weiterverwendet.

Die Implementierung wurde an das LRZ Linux Cluster getestet. Das LRZ-Linux Cluster istein HPC System fur die bayerischen Hochschulen und Forschungsinstitute. Das Cluster bietetPools mit unterschiedlichen 64-Bit Prozessoren, unterschiedlichen Interkoniktevitat und Sha-red Memory Kapazitat. Die verwendeten Prozessoren fur die parallele Ausfuhrung von Peanosind 8-Wege AMD Opteron getaktet auf 2.6 GHz mit 32 GByte Speicher pro Knoten. Fur


die Visualisierung wurde ein Sun X4600 Server mit 8 quad-core Opterons, 256 GB Speicherpro Prozessor und vier Nvidia Quadro FX5800 als Grafikkarten verwendet. Es wurde einen1:1 Test (Ein Simulationsclient wird einen Visualisierungsserver zugeordnet) durchgefuhrt.Die aktuelle Implementierung fur die Manipulationen der Geometrien wird nur fur seriellenDurchlaufe unterstutzt, deshalb konnte die Parallelisierung nur fur die vorgestellten Monito-ring Konzepte getestet werden.

Als Testszenario wurde das Obstacle in Channel in 3D mit einem Kugel als Hindernis ver-wendet. Die nachfolgenden Expermiente wurden auf 1,2,4,6 und 8 CPUs getestet. Großer Teilder vorgestellten Visualisierungsalgorithmen haben sich als gut geeignet fur die Darstellungvon verteilten Daten erwiesen(Color-Mapping, Konturengenerirung, Glyphs und Cutting Pla-nes). Die Gewinnfaktoren bei der Schnittebenen hangt von der Dekomposition des Domainsauf der Seite der Simulation. Werden die einzelnen Partitionen parallel zu der Ebenen definiert,so kann die Berechnung der einzelnen Ebenen in unterschiedlichen Prozessoren passieren. Dasgleiche Schema kann auch bei Stromlinien verwendet werden. In Abbidlung 7.11 wird diesesSchema fur Strombander auf vier Prozessoren angezeigt. Jede Partition wird in einem eigenenFenster gerendert. Rechts unten in der Abbidung ist die Komposition der einzelnen Teilen.Auf dem linken oberen Bild(der Root-Prozess) sieht man den Widget fur die Steuerung desSeedings.Auf den anderen drei Prozesse wird nur die implizite Darstellung der Linie kopiertund an den Streaming Filters weitergeleitet.

Abbildung 7.11: Parallele Darstellung von Strombander auf vier Prozessoren


(a) Speedup bei der Ausfuhrung von Color Map-ping, Konturengenerierung und Glyphing in Par-allel

(b) Dauer der Komposition von Bildern

Abbildung 7.12: Evaluierung des Speedups und des Aufwands der Komposition

Die Darstellung von transparenten Objekten wird in der aktuelle Implementierung nichtunterstutzt. Wichtig fur die Darstellung von Alpha Werten ist die Sortierung der einzelnenObjekten der Szene. Fur die richtige Anzeige ist eine Back-To-Front Sortierung angefordert.Aktuell ist diese Sortierung nur fur die Objekten auf einem Prozessor gegeben aber nicht furdie Komposition aller Prozessoren.

Ein gangiges Maß, fur die Bewertung einer Parallelisierung eines Verfahrens istdas Speedup Sp

Sp =T1Tp

(7.1)

mit p - die Anzahl der verwendeten Prozessoren, Tp - die Laufzeit der Anwendung auf pProzessoren und T1 - die Laufzeit derselben Anwendung in sequentiellen Fall. Im Folgen-den wird das Speedup fur das Color Mapping, Konturengenerierung und Glyphing betrach-tet(Abb.7.12(a)). Die rechte Abbildung 7.12 zeigt die Dauer der Kompistionsphase(BilderZusammenfassen) fur die drei Algorithmen. Aus der Ergebnisse folgt, dass die Verfahren Kon-turgenerirung und Glyphing sich sehr gut parallelisieren lassen. Bei Color-Mapping werdenahnliche Zahlen mit unterschiedlichen Anzahl von Prozessoren erreicht.

Die vorgestellte Ergebisse zeigen den Potenzial des Steering Frameworks in den Punktenwie Parallelisierung, Visualisierung und Interaktion. Die Verwendung der VTK-Bibliothek er-laubt die leichte Erweiterung um andere Filters. So konnen die Synchronisationspunkten zubeliebigen Simulationsapplikationen ubergetragen werden und die um die notwendigen Visua-lisierungsmethoden auf der Seite des Visualisierungsserver erweitert werden. Der verwendeteSort-Last Verfahren fuhrt zur Erzeugung von mehreren unabhangigen Pipelines. Es erlaubtdas Erreichen von einem großen Parallelisierungsgrad der Visualiserung.

Zusatzlich wird die Belastung des Netzwerks durch die Verwendung der Desktop-DeliveryMethode bei der Verbindung zwischen Benutzerschnittstelle und Visualisierungsserver geringgehalten.

Seite 90 8 Erweiterungsmoglichkeiten

8 Erweiterungsmoglichkeiten

Die vorgestellten Implementierung stellt nur ein Prototyp fur eines Steering Systems dar unddeshalb konnen zahlreiche Erweiterung auf der Visualiserungsseite und die UI sowie auf derSimulationsseite gemacht werden. Im Folgenden werden diese Moglichkeiten fur Peano undfur die Steering Applikation erortert.

8.1 Erweiterungen in Peano

8.1.1 Checkpointing

Ein wichtiger Punkt bei der Weiterentwicklung der Steering-Schnittstellen von Peano ist dieFehlertoleranz. Durch Einfuhrung eines Checkpointing Mechanismus kann die Simulation inDivergenzfall bis zu einem konsistenten Zustand zuruckgesetzt werden. Das erlaubt das Sparenvon lastigen Neustarts der Simulation in solchen Falle. Diese Mechanismen wurden fur Peanoschon entwickelt und deshlab ist eine Erweiterung der Funktionalitat des Steering-Frameworksmit Interfaces fur Checkpointg sinnvoll.

Wichtig dabei ist die Definition von Stellen in dem Code, wo das Prozess stattfinden kann.Ein weiterer Punkt ist der korrekte Auswahl der Variablen, die den Zustand der Simulationzu den letzten konsistenten Zeitpunkt beschreiben konnen. Das Checkpoiting und Recoverysollen dabei automatisch sowie Benutzer-gesteuert durchgefuhrt werden konnen.

8.1.2 Bewegliche Geometrien-Teil II

Aktuell wird das Steering der Geometrien nur anhand von Verschiebungen in der Szene reali-siert. Die Rotation und die Skalierung werden dabei auf der Simulationsseite nicht behandelt.Fur die Berechnung der Krafte bei einer Rotation wird analog zu 5.3 vorgegangen. Um dieendgultige Weltkoordinaten des Objektes berechnen zu konnen muss auch die Orientierungdes Objektes beschrieben werden. Die Orientierung eines Korpers ist durch die 3x3 MatrixRotationsmatrix R(t) gegeben. Die Weltkoordinaten p(t) des Objektes sind dann wie folgtdefiniert:

p(t) = R(t)p(0) + pcm (8.1)

mit pcm die Postition des Schwerpunkts des Objektes. Eine weitere Große wird benotigt, umdie Drehung des Korpers zu beschreiben, namlich die Winkelgeschwidigkeit !(t).

8.2 Erweiterungsmoglichkeiten fur dieVisualisierung Seite 91

Die Gleichung 5.2 wird wie folgt erweitert:

dX(t)

dt=

d

dt

⎛⎜⎜⎝x(t)R(t)P (t)L(t)

⎞⎟⎟⎠ =

⎛⎜⎜⎝v(t)

!(t)∗R(t)F (t)�(t)

⎞⎟⎟⎠ (8.2)

mit P (t) das linear Momentum ,L(t) das Winkelmomentum und �(t) das Drehmoment. ImWeiteren sei a∗ fur ein Vektor a die folgende Matrix:

a∗ =

⎛⎝ 0 −az ayaz 0 −ax−ay ax 0

⎞⎠ (8.3)

Eine Ausfuhrliche Beschreibung dieses Berechnungsvorgangs kann in [Bar01] gefunden werden.

Ein spannender Punkt ist das Anbinden und Simulation einer Stromung mit komplexerentriangulierten Hindernisse. Im Rahmen von Peano existiert die Client/Server Verbindungzu der Umgebung preCICE([Gat08]). Diese Bibliothek erlaubt die High-Performanz Zugriffauf die triangulierten Daten. Die Flachen werden dann fur die Generierung von adaptivenGitterstrukturen von Peano verwendet. Zusatzlich wird das Mapping und Speicherung vonInterface Daten wie Krafte und Dislozierungen angeboten.

8.1.3 Implizite Losungsverfahren und Lattice-Bolzmann

Im Weiteren werden anderen Methoden zur Losung von CFD-Problemen in dem Peano-Framework unterstutzt.In dieser Gruppe fallen die implizite Losungsverfahren sowie Verfahrenhoherer Ordnung. Weiterfuhrende Ansatze wie Lattice-Bolzmann und das IDO-Verfahren([Aok97])erlauben das effizientere Losen des Problems. Diese Methoden sollen in einer zukunftigen Ar-beit um die definierten Steering-Schnittstellen erweitert werden.

8.2 Erweiterungsmoglichkeiten fur die Visualisierung

Die Verwendung der offentlichen Bibliothek VTK macht das Spektrum der moglichen Er-ganzungen der Visualisierungsmethoden riesig. Eine Verbesserungsmoglichkeit wird durch diePerformanz heutigen SIMD-GPUs gegeben. Es existieren verschiedene Ansatze, die die Be-rechnung der vorgestellten Algorithmen fur Darstellung von CFD-Daten auf der GPU(vgl.[Bec05])durchfuhren. Als besonders geeignet sind Partikel Tracers Verfahren. Andere Erweiterungs-moglichkeit sind die Ansatze fur GPU-basierten Ray Tracing Methoden.

Fur die Parallelisierung der Visualisierung wurde das bereits berechnete Dekomposition desDomains innerhalb von Peano verwendet. Unter Umstanden kann diese Dekomposition zurschlechte Parallelisierung der verwendeten Visualisierungsalgortihmen fuhren(vgl. Abb.8.1).


(a) Eine schlechte Domain Dekomposition fur dieBerechnung von Stromlinien

(b) Gute Domain Dekomposition

Abbildung 8.1: Evaluierung des Parallelisierungsgewinns bei der Visualisierung vom Stromli-ninien vgl.[CF08]

Es exisitieren unterschiedlichen Partitionierungsschemata je nach Visualisierungsverfahren.Beispielsweise wurde in [CF08] ein Verfahren fur die Dekomposition des Volumens entlangdes Flusses anhand von dem Fluss-gerichteten anistrophic Diffusionsoperator fur die paralleleDarstellung von Stromlinien vorgestellt. Beim Verlassen des Domains eines Prozesses mus-sen bei der Berechnung der Stromlinien die Zwischenwerte zu dem Nachfolger weitergeleitetwerden. Eine gute Dekompostion fur die Stromlinien ist dann gegeben, wenn die Domaineines Prozesses nicht verlassen werden soll. Die Abbildung 8.1(a) skizziert ein Beispiel fureine gute Dekomposition. Die Speedup werte fur dieses Algortihmus werden in Abbildung 8.3dargestellt.

Abbildung 8.2: Vergleich unterschiedlichen Partitionierungen fur die berechnung von Strom-linien nach [CF08]

Eine weitere Moglichkeit fur die Partitionierung aufgrund von Schnittebenen wird in [Sim03]vorgestellt. Dabei werden die Normalen der Ebenen berechnet. Die kleinste Komponente des

8.3 Steering und Virtual Reality Seite 93

berechneten Vektors gibt die Achse der Portionierung an.

Bei der Verwendugn von Transparenz konnen in der aktuellen Implementierung verschie-denen Artefakte entstehen. Fur die Generirung von Transparenz wird im seriellen Modus dasAlpha Blending Verfahren verwendet. Dabei speichern die einzelnen Pixels nicht nur die Farb-werten und die Z-Puffer Werten sondern auch einen Alpha-Wert, was die Durchsichtigkeit desKorpers beschreibt. Dabei bedeutet den Wert von 0.0 unsichtbarkeit und 1.0 opak. Fur dasBleding der Endfarben wird das over-Opertor wie folgt definiert:

co = ascs + (1− as)cd (8.4)

mit cs die Farbe des transprenten Objektes(Source Object), as den Alpha Wert dieses Ob-jektes, cd die ursprungliche Farbe(destination) und co die resultierende Farbe nach der Plat-zierung eines transprenten Objektes uber die Szene. Das Rendering von transprenten Objek-ten fordert in den meisten Falle eine Sortierung der Objekten an. Am Anfang werden dieundurchsichtigen Objekten gerendert. Im zweiten Schritt passiert das Rendering der transpa-rente Objekten anhand des over-Operators in back-to-front Anordnung. Die Entstehung vonArtefakten wird mir der Anordnungsabhangigkeit der Bleding-Gleichung erklart. In [AMH02,103–106] werden Multi-Pass Techniken zum Rendering von transparenten Objekten ohne vor-handene Sortierung vorgestellt.

8.3 Steering und Virtual Reality

Abbildung 8.3: Eine Powerwall-Einrichtung aus der VR

Oft werden Steering Frameworks zusammen mit Techniken aus der Virtual Reality ver-wendet. Typischerweise wird die Szene auf Powerwalls, Caves und andere Darstellungsein-richtungen der VR angezeigt. Dabei wird eine spezielle Art von Rendering verwendet: dasStereo Rendering.Bei dem Stereo Rendering werden zwei Bilder der Szene gerendert - einpro Auge(stereo pair). Eine allgemeine Technik ist die Erzeugung eines Bildes in Rot undeines in Grun. Das zusammengesetzte Bild wird dann mit Rot-Grun Brillen betrachtet. Das


Stereographische Rendering wird von VTK unterstutzt. Fur die Powerwalls und Caves wer-den in [MT03] Erweiterungen fur die Bibliothek beschrieben, die die Verwendung von dieserEinrichtugen in ahnlicher Art und Weise wie das beschriebe Dekstop-Delivery erlauben.

Fur die Interaktion in VR wird oft das Tracking verwendet. Es existiern unterschiedlichenMethoden fur Tracking (optisch, magnetisch u.a.). Die verbreitetste Methode ist das optischeTracking. In den meisten Falle wird das zu trackende Objekt mit Markers versehen und derenPositionen werden dann durch Techniken aus der Bildverarbeitung ermittelt.

Ein weiterer Punkt aus VR ist die colloborative Verwendung einer VR-Interface, was dieSteuerung einer Simulation von mehreren Benutzer erlauben soll. Eine Erweiterung um dieKomponenten fur Multi-User Betrieb ist einen wichtigen Punkt der zukuftigen Expansionendes vorgestellten Frameworks.

Seite 95

9 Ausblick

Das Ziel des vorgestellten Steering Frameworks ist die Bereitstellung der notwendigen Inter-faces fur die Echtzeit Interaktion mit Simulationen. Die beschriebene Implementierung undMethodik erreicht dieses Ziel durch Verwendung von passenden Algorithmen fur die Visua-lisierung von großen, verteilten Daten. Diese Ansatze erlauben die effiziente Exploration desParameterraumes einer Simulation. Weiterhin wird die Bedienung durch 2D-UI erleichtert.Die implementierte Schnittstellen fur Uberwachung und Steuerung lassen sich dabei leichtauf anderen Simulationsapplikationen durch minimalen Veranderungen der gegebenen Imple-mentierungen ubertragen.

Durch die vorgestellten Methoden fur Parallelisierung der Visualisierung wird das Ver-wenden des Systems in komplexeren parallelen HPC-Architekturen moglich. Die Technik furDesktop-Delivery ermoglicht zusatzlich die Durchfuhrung komplexeren Simaltionslaufe mitden Betriebsmittel eines Thin-Clients außerhalb des Clusters.

Durch die Ausgefuhrten Experimente fur die Verwendung der Schnittstellen fur die Manipu-lation von Geometrien wird der Vorzug des implementierten Verfahrens gegenuber Technikenfur Manipulation anhand von Textfeldern und anderen Methoden gezeigt. Die Ergebnisse derParallelisierung zeigen dabei eine gute Tendenz im Bezug auf den Speedup der verwendetenVisualisierungsmethoden.

Seite 96 Literaturverzeichnis

Literaturverzeichnis

[ALS+00] J. Ahrens, Ch. Law, W. Schroeder, K. Martin, and M. Papka. A parallel approachfor efficiently visualizing extremely large, time-varying datasets. 2000.

[AMH02] T. Akenine-Moeller and E. Haines. Real-Time Rendering. Technik, USA, 2002.

[Aok97] T. Aoki. Interpolated differtial operator(ido) scheme for solving partial differen-tial equations. Comput.Phys.Comm, 1997.

[Bar01] D. Baraff. Physical based modelling:rigid body simulation. 2001.

[Bec05] B. Becker. Integration von gpu-basierten methoden zur visualisierung von par-tikeln in adaptiven gittern. Diplomarbeit, TUM, 2005.

[B.M87] M. Brown B.McCormick, T. DeFanti. Visualization in scientific computing. Com-puter Graphics, 21.6, 11 1987.

[CF08] L. Chen and I. Fujishiro. Optimizing parallel performance of streamline visuali-zation for large distributed flow datasets. IEEE Pacific Visualisation Symposium2008, 2008.

[CL93] B. Cabral and L. Leedom. Imaging vector fields using line integral convolution.Computer Graphics, 27:263–272, 1993.

[CPC90] M.S. Chong, A.E. Perry, and B.J. CAntwell. A general classification of three-dimensional flow fields. Phys.Fluids, 2:765–777, 5 1990.

[EIH00] M. Eldridge, H. Igehy, and P. Hanrahan. Pomegranate:a fully scalable graphicsachritecture. Computer Graphics, 11(6):290–296, 7 2000.

[Fly72] M.J. Flynn. Some computer organizations and their effectiveness. IEEE Tran-sactions in Computers, 1972.

[Gat08] B. Gatzhammer. A partitioned approach for fluid-structure interaction on car-tesian grids. Diplomarbeit, TUM, 2008.

[GH95] A. Gueziec and R. Hummel. Exploiting triangulated surface extraction usingtetrahedral decomposition. IEEE Transactions on Visualisation and ComputerGraphics, 1:328–342, 12 1995.

[GKP97] G.A. Geist, J.A. Kohl, and P.M. Papadopolous. Cumulvs: Providing fault tole-rance, visualization, and steering of parallel applications. The International Jour-nal of Supercomputer Applications and High Performance Computing, 11(3):224–235, 1997.

Literaturverzeichnis Seite 97

[Gou71] H. Gouraund. Continuous shading of curved surfaces. IEEE Transactions onComputers, C-20:623–629, 6 1971.

[Gri97] M. Gribel. Numerical Simulation in Fluid Dynamics: A Practical Introduction(Monographs on Mathematical Modeling and Computation). Number 0. Societyfor Industrial and Applied Mathematics, 1997.

[HH91] J. Helman and L. Hesselink. Visualizing vector field topology in fluid flows. IEEEComputer Graphics and Applications, 11:36–46, 5 1991.

[Lı¿01] R. Lı¿12hner. Applied computational fluid dynamics techniques: An introduction

based on finite element methods. Wiley, 2001.

[Mol94] S. Molnar. A sorting classification of parallel rendering. 1994.

[MT03] K. Moreland and D. Thompson. From cluster to wall with vtk. Proceedings ofthe IEEE Symposium on Parallel and Large-Data Visualization and Graphics,2003.

[MvWvL98] J.D. Mulder, J.J. van Wijk, and R. van Liere. A survey of computational steeringenvironments. Software Engineering (SEN), SEN-R9816, 9 1998.

[Nec09] T. Neckel. The PDE Framework Peano : An Environment for Efficient FlowSimulations. PhD thesis, TUM, 2009.

[OH01] S. Olbrich and Pralle H. Verteilte visualisierung von ingenieurwissenschaftlichensimulationsergebnissen. ICCES-Kolloquium, 1 2001.

[Rob94] L. Robertson, P.K.;De Ferrari. Systematic approaches to visualization:is a re-ference model needed. Scientific Visualization.Academic Press, pages 287–305,1994.

[Sal07] D. Salomon. Data Compression. Springer, 4 edition, 2007.

[Sim03] D. Simonetti. Interactive visualization of biomedical data. Diplomarbeit, Uni-versiteit van Amsterdam, 7 2003.

[SM00] H. Schumann and W. Mı¿12 ller. Visualisierung : Grundlagen und allgemeine

Methoden. Springer, Berlin, 2000.

[SML04] W Schroeder, K. Martin, and B. Lorensen. Visualization Toolkit:An Object ori-ented Approach to 3D Graphics. 3 edition, 2004.

[Unt09] K. Unterweger. Cfd simulations of moving geometries using cartesian grids.Diplomarbeit, TUM, 2009.

[VS95] J. Vetter and K. Schwan. Progress: a toolkit for interactive program steering.International Conference on Parallel Processing, pages 139–142, 1995.

[Wei09] T. Weinzerl. A Framework for Parallel PDE Solvers on Multiscale AdaptiveCartesian Grids. PhD thesis, TUM, Mı¿1

2nchen, 2009.

Seite 98 Abbildungsverzeichnis

Abbildungsverzeichnis

3.1 Skizze der wirkenden Volumenkrafte . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Architekturaufbau von Peano . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Visualisierung von verschiedenen Gitterreprasentationen der Drift-Rachet Geo-metrie in 3D:(a) regulare kartesische Gitter (b) adaptive kartesische Gitter . . . 11

3.4 Traversierung von adaptiven Gitter anhand der Peano-Kurve . . . . . . . . . . 12

3.5 Das Visualisierungsreferenzmodell nach [Rob94] . . . . . . . . . . . . . . . . . . 14

3.6 Die Renderingpipeline(vgl.[AMH02]) ist in drei konzeptuellen Phasen aufgeteilt: Applikationsphase, Geometrie-Phase und die Rasterungssphase. Jede Phasekann selbst auch eine Pipeline sein. . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.7 View Tranformationen nach [AMH02]. Das linke Bild stellt die Benutzer defi-nierte Position und Orientierung der Kamera. Nach der Anwendung der Sichtstrans-formation steht die Kamera im Ursprung des Koordinatensystems und ist ent-lang der negativen z-Achse ausgerichtet. . . . . . . . . . . . . . . . . . . . . . . 16

3.8 Links-orthographische Projektion,Rechts-Perspektivenprojektion . . . . . . . . 17

3.9 Die 24 Marching Squeres Falle fur 2D :die dunklen Punkten bezeichnen Verticesmit Skalarwert uber den Konturwert (vgl. [SML04] ) . . . . . . . . . . . . . . . 19

3.10 Zufalliger Auswahl von mehrdeutigen Fallen kann zur Erzeugung von Locherin der ISO-Flachen fuhren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.11 Visualisierungstechniken fur Vektorfelder vgl. [SML04] . . . . . . . . . . . . . . 21

3.12 Klassifikation von kritischen Punkten nach [HH91] . . . . . . . . . . . . . . . . 23

3.13 Visualisierung von Vektorfelder mit lokalen und globalen Methode vgl. [SML04] 24

3.14 Klassifikation nach Flynn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.15 Aufteilung der MIMD-Architekturen nach Speicherverwaltung . . . . . . . . . . 26

3.16 Der Steering Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.1 Das Client-Server Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Remote Procedure Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Zuordnung der RPC und RMI Komponenten in das ISO-OSI Referenzmodell . 37

5.4 Architektur der Single Process-Steering Applikation und ihre Anwendung. . . 38

5.5 Steering-Architektur mit Remote-Visualisierung . . . . . . . . . . . . . . . . . . 39

5.6 Steering mittels mehreren Visualisierungsservers . . . . . . . . . . . . . . . . . 40

5.7 Zusammenhang zwischen Traversierung und Verfeinerungszustande eines Ver-texes vgl. [Wei09] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.8 Die Aufbau der graphische Oberflache . . . . . . . . . . . . . . . . . . . . . . . 44

5.9 Die Visualisierungskomponentein der GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.10 Skalar-Vektor Data Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.11 Mapper-Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.12 Reprasentationsauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Abbildungsverzeichnis Seite 99

5.13 Eingabemaske fur dieKonturengenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.14 Eigenschaften : Pfeilenskalierung, LoD,Geometrie-Widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.15 Scenario-Maske . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.16 Die Bahnlinien-Maske . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.17 Die Schnittebenen-Maske . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.18 Browser der aktuallenGeomterie-Instanzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.19 Eigenschaften derausgewahlten Geometrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.20 Partitionierung der Visualisirungspipeline aus [OH01] . . . . . . . . . . . . . . 50

5.21 Die allgemeine Architektur von graphischen HPC-Anwendungen nach [EIH00] . 51

5.22 Taxonomie der graphischen HPC-Anwendungen nach [EIH00]. . . . . . . . . . . 52

5.23 Achsen-gerichtete BSP-Baum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.1 Zustandsdiagramm des Simulation-Clients . . . . . . . . . . . . . . . . . . . . . 55

6.2 Zustandsdiagramm des Steering-Server . . . . . . . . . . . . . . . . . . . . . . . 55

6.3 Pakete fur die Kommunikation zwischen Client und Steering Server . . . . . . . 56

6.4 Aufbau der QVTKWidget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.5 Vererbungsdiagram der verwendeten 3D Widgets . . . . . . . . . . . . . . . . . 62

6.6 Pipeline fur die Erstellung von Schnittebenen . . . . . . . . . . . . . . . . . . . 64

6.7 Pipeline fur die Generierung von Glyphs . . . . . . . . . . . . . . . . . . . . . . 64

6.8 Pipelines fur die Generierung von Bahnlinien . . . . . . . . . . . . . . . . . . . 65

6.9 Aufbau der Geometrie-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.10 Aufrufsequenz bei der Aktualisierung einer Geometrie . . . . . . . . . . . . . . 67

6.11 Beziehung zwischen Simulationsclients und Visualisierungsserver . . . . . . . . 68

6.12 Interaktionen des parallelen Managers wahrend Rendering vgl.[MT03] . . . . . 70

6.13 Interaktionen zwischen einzelnen Prozessen bei Steuerung der Sichtbarkeit ei-nes Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.14 VGL Image Transport mit Remote 2D X Server . . . . . . . . . . . . . . . . . . 74

6.15 X11 Image Transport mit X Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.16 Sun Ray Image Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.17 Ablauf des Renderingvorgangs bei der Verwendung von Desktop-Delivery vgl.[MT03] 76

7.1 Zusammenfassung der Eigenschaften von Progress, CUMULVS und der aktu-ellen Arbeit(PeanoFE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.2 Visualiserung von Skalaren mit Hilfe von Color Mapping(Obsticle in ChannelScenario): a) Color Mapping-Zellen, b) Color Mapping Vertex . . . . . . . . . . 82

7.3 Konturengenerierung : 20 Werte fur den Druck zwischen 0 und 0.1 . . . . . . . 82

7.4 Schnittebenen : Darstellung von vier Schnittebenen. Fur die Anzeige der selek-tierten Ebene werden Konturen verwendet. . . . . . . . . . . . . . . . . . . . . 83

7.5 Strombander in Obstacle in Channel 3D . . . . . . . . . . . . . . . . . . . . . . 84

7.6 Visualiserung von Vektorfelder: a) Stromlinien b) Glyphed-Stromlinien . . . . . 84

7.7 Das dargestellte Szenario ist Obstacle in channel mit einer Kugel. Die zweiteKugel wurde zum Laufzeit eingefugt. Rechts unten werden die Eigenschaftender selektierten Geometrie angezeigt. . . . . . . . . . . . . . . . . . . . . . . . . 85

Seite 100 Abbildungsverzeichnis

7.8 Durchfuhrung einer Bewegung durch das Bounding Box Widget . . . . . . . . . 867.9 Bewegung einer Kugel in adaptiven Gitter mit LoD Prunning . . . . . . . . . . 867.10 Vergleich der Laufzeit der Simulation bei Bewegung mit und ohne LoD Pruning 877.11 Parallele Darstellung von Strombander auf vier Prozessoren . . . . . . . . . . . 887.12 Evaluierung des Speedups und des Aufwands der Komposition . . . . . . . . . 89

8.1 Evaluierung des Parallelisierungsgewinns bei der Visualisierung vom Stromli-ninien vgl.[CF08] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8.2 Vergleich unterschiedlichen Partitionierungen fur die berechnung von Stromli-nien nach [CF08] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8.3 Eine Powerwall-Einrichtung aus der VR . . . . . . . . . . . . . . . . . . . . . . 93

Tabellenverzeichnis Seite 101

Tabellenverzeichnis

3.1 Beschreibung der Ereignisse und die Ursachen fur die beiden Gitterarten inPeano. Die mit * gekennzeichneten Zeilen sind nur fur adaptiven Gitter definiert. 13

6.1 Die Event-Aktion Tabelle der VTKClient Adaptoren . . . . . . . . . . . . . . . 58

design und implementierung eines computational steering ... · ich versichere, dass ich diese...

Documents