Home

Dokument 1

1. Shared Data Space Shared Data Space Abbildung 4 1 Die COVISE Systemarchitektur Seite 27 4 Konzept eines verteilten Visualisierungssystems 4 1 Die verteilte Datenverwaltung 4 1 1 Der Datenaustausch zwischen Modulen Im Gegensatz zu AVS und IRIS Explorer sind die Module bei COVISE nicht direkt miteinander ver bunden vergleiche dazu die Abbildungen 3 1 3 3 und 4 1 W hrend bei AVS anf nglich die Daten zwischen aufeinanderfolgenden Modulen immer mittels TCP Sockets bertragen wurden wurde dies bei IRIS Explorer von Beginn an nur bei Modulen die auf verschiedenen Rechnern laufen getan In sp te ren AVS Versionen wurde ebenso wie bei IRIS Explorer f r den Austausch von Daten zwischen loka len Modulen Shared Memory genutzt Dennoch sind die Module nach wie vor mittels eines TCP Sockets miteinander verbunden Sinn dieser Verbindung ist die Information ber Daten direkt von einem Modul zum n chsten flie en zu lassen In COVISE gibt es keine direkte Verbindung zwischen den Modulen Ein Modul wei nie und mu auch nicht wissen welche und wieviele Module vor oder nach ihm laufen und ob diese lokal oder ver teilt sind Der Zugriff auf Daten erfolgt immer ber den Shared Data Space und die Information wo die gew nschten Daten zu finden sind wird beim Request Broker eingeholt Wesentlich bei der Realisie rung dieses Datenaustauschs ist da es si
2. Abbildung 5 1 Der Datenflu bei der Darstellung der PEGASE Ergebnisse In der linken H lfte sind die Module zu sehen die auf dem Supercomputer laufen Da dort kein Shared Memory zur Verfiigung steht hat jeder Modul seinen eigenen Shared Data Space Dies hat zwar wie man auch an den Objekten erkennen kann zur Folge da Daten kopiert werden m ssen obwohl beide Module auf demselben Rechner laufen dies ist in Anbetracht der groBen Datenmengen jedoch immer noch effizienter als sie komplett tiber das Netzwerk zu schicken Der PEGASE Modul schreibt nun das Geschwindigkeitsfeld 2 und die Wirbelst rke 1 in seinen Shared Data Space Der Isofl chen modul und der Colormapmodul greifen auf die Kopien dieser Datenobjekte zu 2 und 1 Diese Kopien werden jeweils von dem Requestbroker der in den entsprechenden Modul integriert ist angelegt nach dem der Modul nach der Adresse dieses Datenobjektes gefragt hat Das Ergebnisobjekt des Isofl chen moduls 3 wird dann vom Colormapmodul benutzt um die endg ltig darzustellende Geometrie zu generieren 4 Damit der Rendermodul auf der Workstation anschlie end das Bild erzeugen kann mu nur dieses Geometrieobjekt in den Shared Data Space auf der Workstation kopiert werden 4 5 1 2 Str mung im Zylinder eines Motors In diesem deutlich komplexeren Beispiel soll die kollaborative Visualisierung einer Off Line gerech neten Simulation der Str mungsvorg nge in e
3. y Kopien Zugriff Typ L nge Koordinaten Objekt Eintrag E Typ L nge Attribute F Kopien Zugriff Zeiger Ursprung L Shared Data Space d Abbildung 4 5 Zugriff auf den Shared Data Space 4 2 3 Zugriff eines Moduls auf die Datenobjekte Erstellung eines Datenobjekts Um ein neues Datenobjekt im Shared Data Space anzulegen sind im wesentlichen nur der Platzbe darf und der Name den das Datenobjekt tragen soll n tig Aus der Sicht eines Modulprogrammierers stellt sich der Ablauf sehr einfach dar Er ruft einfach den Konstruktor f r ein Objekt des gew nschten Datentyps auf und bergibt als Argumente den Namen und alle Parameter die f r die Gr e des Objekts relevant sind bei einem strukturierten Gitter sind das z B die Anzahl der Gitterpunkt in allen Richtun Seite 37 4 Konzept eines verteilten Visualisierungssystems gen Er erh lt dann ein Objekt bei dem er sich Zeiger direkt auf die zu beschreibenden Datenelemente holen kann mehr dazu in Kapitel 4 6 Wesentliche Strategien der Implementierung Die Prozesse die unterhalb dieser Programmierschnittstelle ablaufen sind allerdings ein wenig kom plexer Aus der Information tiber das gewiinschte Datenobjekt wird eine Message generiert die an den Request Broker mit der Bitte um Erzeugung des Objekts und Bereitstellung des daf r ben tigten Spei cherplatzes ges
4. 1 Bei Ensight werden immer zwei Prozesse gestartet ein Server der die berechnungsintensiven Aufgaben aus f hrt und ein Client der das User Interface und die Graphikausgabe handhabt Die einzige Variationsm glichkeit besteht darin diese beiden Prozesse entweder auf demselben oder auf zwei verschiedenen Rechnern laufen zu las sen Seite 25 3 Vergleich mit existierender Software Seite 26 Kapitel 4 Konzept eines verteilten Visualisierungssystems Nach ausf hrlicher Untersuchung der bislang verf gbaren Visualisierungssysteme wurde ein Kon zept entwickelt das die Vorteile dieser Systeme vereinen und die Nachteile vermeiden soll Besondere Aufmerksamkeit wurde dabei von Anfang an der Verteilung der einzelnen Komponenten auf verschie dene Rechner gewidmet In Kapitel 2 wurde die System Architektur bereits kurz vorgestellt Dieses Kapitel beginnt mit einer detaillierten Darstellung der verteilten Datenverwaltung 4 1 Des weiteren werden die Datenobjekte vorgestellt 4 2 dabei wird auch auf den Aspekt der Objektorientierung eingegangen und damit zusam menh ngend Persistenz 4 3 und partitionierte Objekte 4 4 dargestellt Abschlie end wird ein Blick auf die besonderen Anstrengungen die zur Nutzung von High Performance Infrastruktur unternommen wurden 4 5 geworfen und die wesentlichen Strategien bei der Implementierung werden erl utert 4 6 Lokale Workstation Entfernte Workstation UI
5. C Database Development MIS Press New York 1992 Stroustrup B The C Programming Language 2 Auflage Addison Wesley 1991 Ihe Common Object Request Broker Architecture and Specification Object Management Group OMG Treinish L A The role of data management in discipline independent datavisualization Extracting Meaning from Complex Data Processing Display Interaction Edward J Farrell Editor Proc SPIE 1259 261 271 1990 Upson C Faulhaber T Kamins D Laidlaw D Schlegel D Vroom J Gurdwitz R van Dam A The Application Visualization System A Computational Environment for Sci entific Visualization EEE Computer Graphics and Applications Volume 9 Number 4 pp 30 42 July 1989 User Guide AIX Visualization Data Explorer 6000 Version 3 1 IBM Corporation Yorktown Heights 1995 Volle C Seybold J R hle R RSYST User s Guide Version 3 6 0 Forschung und Ent Seite 98 74 75 76 77 78 79 80 81 7 Literatur wicklungsberichte RUS 34 Rechenzentrum der Universitat Stuttgart 1996 Wierse A Rumpf M GRAPE Eine interaktive Umgebung f r Visualisierung und Nume rik Informatik Forschung und Entwicklung Springer 7 pp 145 151 1992 Wierse A Lang U R hle R Architectures of Distributed Visualization Systems and their Enhancements Workshop Papers ofthe Fourth Eurogra
6. e eine besondere Menge ist der sogenannte TimeSet In dieser Menge befinden sich analog zu dem gew hnlichen Mengenobjekt mehrere Elemente gleichen Typs die aber zus tzlich in einem zeitli chen Zusammenhang stehen Da f r viele Module dieser zeitliche Zusammenhang unerheblich ist beispielsweise bei der Berechnung einer Schnittfl che durch die einzelnen Zeitschritte funktio nieren die ganz normalen Funktionen einer Menge genauso auf einem TimeSet F r Module die auf die Zeitinformationen zugreifen m ssen wie zum Beispiel das Modul f r eine Partikelverfol gung gibt es entsprechend zus tzliche Schnittstellen e Multi Media Objekte die darauf ausgelegt sind Datenstr me zu verarbeiten Dies kann z B in der Form eines Ringpuffers erfolgen d h es gibt bei einem Videodatenstrom Speicherplatz f r eine gewisse Anzahl von Frames die kontinuierlich dort abgespeichert werden Ein Modul das lesend darauf zugreift kann ebenfalls permanent Frames auslesen Siehe hierzu auch 16 und 39 Anwendungs Modul Kommunikation ber Shared Data Space Zugriff Zeiger Handle Objekt lokal Variable Variable Variable Feld Feld Feld x_disk y_disk z_disk x_koord y_koord z_koord Request Broker N zgr zgr iy Objekt Eintrag Typ L nge Koordinaten L nga Objekt Baum
7. 7 DN CAD USE nee teks ayis apne E at 7 DDS Sysiemarchitekl r science 7 2 3 Motivation des Verteilungsmechanismus uueennssssenssssnnnnnnnnnnn 9 DARSYS Te sul a EEE 12 De TRAP ES Saa id ea E EE teaasels 14 Seite IX Kapitel 3 Vergleich mit existierender Software u eneen 17 3 1 Visualisierungssoftware u eek 17 LINSE EEE NER i e RE 18 2 AN SIER NEEE E CEE Si es tee Bi dies E ale a 20 Il KIRIS Prplorer ne reagiert 21 3 4 Date Explorer ai 22 3 1 9 ERSICHl an EAEE ee A AE 23 3 2 bersicht stable 24 Kapitel 4 Konzept eines verteilten Visualisierungssystems 27 4 1 Die verteilte Datenverwaltung 2 a DE an 28 4 1 1 Der Datenaustausch zwischen Modulen 2200222000ssssensnsensssnnennnnnnennn nenn 28 4 1 2 Vorteile der fehlenden Direktverbindung 0s2400ssssnsnsnsennennnnnn 31 4 1 3 Mechanismen zur Konfliktvermeidung 2000222000sssssenssnnenssnnensnnnnenn nen 31 A DADS D ten bjekte una 34 4 2 1 Anforderungen an die Speicherung der Datenobjekte eee eeeese cence ern 34 4 2 2 Hierarchie der Datentypen isror eei EB 35 4 2 3 Zugriff eines Moduls auf die Datenobjekte oe eee esse ceeeeeeeeeeeeeeaeeeaeees 37 AD PEISISENZ onesie eera a a i aa aa E TR i 40 4 3 1 Definition Von Persistenz oieta na e a ee 40 4 3 2 Auswirkungen der Persistenz aac she fe ened ade iat uated rade gedens co eaciag Sind a onaases eaters 40 4 3 3 Vorteile
8. ndern Es gibt auch keine bersicht ber die existierenden Datenobjekte Weder der globale noch der lokale Controller haben eine Datenmanagementkomponente Lokale Workstation Entfernte Workstation UI LC LC A nn B gt C gt D gt E Shared Memory Shared Memory Abbildung 3 3 Die Systemarchitektur des IRIS Explorer 3 1 4 Data Explorer Der IBM Data Explorer folgt zwar auch dem Paradigma des visuellen Programmierens aber seine Proze struktur ist monolithisch Das hei t da einzelne Module oder auch Gruppen von Modulen nicht jeweils einem Proze entsprechen sondern vielmehr alle Module in einem einzigen Executable gelinkt sind Die M glichkeit einzelne Module auf andere Rechner auszulagern war daher nicht von Anfang an gegeben sondern wurde erst in einer sp teren Version hinzugef gt allerdings ohne die Grundarchitektur zu ndern 1 72 In dieser Grundarchitektur siehe Abbildung 3 4 gibt es nur zwei Prozesse einen Client und einen Server der Executive Der Client ist das Frontend ber das der Benutzer die Anwendung steuert im Seite 22 3 1 Visualisierungssoftware Server wird die tats chliche Visualisierungsarbeit geleistet und die gesamte Anwendung gesteuert Beide Prozesse k nnen auch auf verschiedenen Rechnern laufen so da z B die Rechenkapazit t eines Com puters ohne
9. 3g Display Abbildung 1 1 Die Visualisierungspipeline e An erster Stelle steht in diesem Beispiel die Simulation Man kann diesen Schritt auch als Daten generator oder Datenquelle bezeichnen Entsprechend k nnte dort statt der Simulation auch ein Eingabeschritt stehen der Daten einliest die nach einer fr heren Rechnung in einer Datei gespei chert wurden e Der n chste und in Anbetracht der immensen Datenmengen sehr wichtige Schritt ist das Filtern Hier findet alles statt was den eigentlich Datensatz reduziert Ausd nnen in den r umlichen Kom ponenten Ausd nnen in zeitlicher Richtung Weglassen von Zeitschritten Abschneiden der Geometrie Extrahierung von Schnittfl chen etc e Im Mapper werden die berechneten Daten in Geometriedaten umgerechnet oder abgebildet Bei einer Schnittfl che wird z B der Temperaturwert als Farbe auf diese Fl che abgebildet Bei einer Partikelverfolgung werden Partikel in die Str mung geworfen und deren Weg berechnet als Ergebnis erh lt man eine Partikelbahn in Form eines Polygonzuges Eine sehr verbreitete Methode besteht darin Isofl chen also Fl chen gleichen Wertes auf den zugrundeliegenden Daten zu berechnen Auf die daraus resultierenden Polygone lassen sich noch weitere Daten als Farbwerte abbilden In gewissem Sinne befindet sich hier der Kern des Visualisierungsvorgangs e Der darauffolgende Renderingschritt berechnet aus den ihm vorliegenden
10. 5 2 Messungen Versuche mit erh hter Priorit t auf den beiden Crays der maximal vom System her an nicht Systempro zesse vergebbaren Priorit t haben nicht zu dem gew nschten Erfolg gef hrt Wenn es sich beispiels weise erreichen lie e da ein Request Broker Proze vom Eintreffen einer Botschaft ber das Einpacken bis hin zum Verschicken nicht unterbrochen w rde lie e sich die Effizienz der Datenkommunikation sehr nahe an das Optimum bringen ohne jedoch die Gesamtperformance f r andere Benutzer allzu sehr einzuschr nken diese sicher vorhandene Einschr nkung lie e sich ber passende Accounting Mecha nismen relativ einfach abgelten Die Probleme die durch die knappe Ausstattung der Y MP mit Hauptspeicher auftraten lassen sich allerdings kaum durch solche Mechanismen l sen So gut dieser Rechner f r die reinen Fileserver Akti vit ten ausgestattet ist f r die Einbeziehung dieser F higkeiten in eine interaktive Visualisierungsumge bung scheint er doch kaum geeignet Dies ist sehr bedauerlich da gerade die interaktive Einbindung eines Fileservers einem Benutzer den Zugriff auf die Ergebnisse fr herer Berechnungen deutlich verein fachen w rde F r einen dem interaktiven Datenzugriff besser ger steten Fileserver w re eine ad quate Hauptspeicherausstattung unbedingt erforderlich Nicht verschwiegen werden soll in diesem Zusammenhang auch mit welch gro em Aufwand diese Me ergebnisse erreicht wurden Dazu z hlen nicht
11. Brokers absch tzen Dies ist jedoch f r die Messungen nicht von Belang In Abbildung 5 10 sind die hier verwendeten Me punkte zu sehen deren Plazierung im Quellcode den Me punkten aus Abbildung 5 8 entspricht FDDI Verbindung In Tabelle 5 2 sind die Ergebnisse dieser Messungen zu sehen Auffallend an diesen Ergebnissen ist da sie deutlich unter den Erwartungen f r Messungen mit Supercomputern liegen Eine maximale Transferrate von etwas ber 2 MB s ber FDDI ist insbesondere im Vergleich zu den Messungen zwischen zwei mit FDDI vernetzten Workstations Abschnitt 5 2 1 u erst unbefriedigend Hinzu kommt die Schwankung der Me werte bis hinunter zu 200 KB s Verursacht werden diese schlechten Durchsatzraten allein durch die Spalte Netzwerk CuttingPlane DM in PEGASE packobj Netzwerk Netto Durchsatz Brutto Durchsatz 6 1 5 2 4 3 6 1 5 2 Netzwerk Gr e CuttingPlane Gr e 7 448 0 015 0 015 7 432 2107 KB s 2103 KB s 74 945 0 015 0 014 74 930 209 KB s 209 KB s 14 738 0 016 0 016 14 721 1064 KB s 1063 KB s 19 228 0 016 0 015 19 211 815 KB s 815 KB s Tabelle 5 2 C94 zu Y MP FDDI Seite 79 5 Resultate Eine genauere Untersuchung f rderte folgende Ursachen f r diese Me ergebnisse zu Tage der bei der Verbindung zwischen den beiden Crays verwendete Gigaswitch zeigt aufgrund hoher Belastung durch viele Zugriffe auf den Fileserver die Y MP einen hohen Packetverlust durch Blocki
12. Hierarchische Strukturierung von Objekten Durch die Persistenz ist es dem Benutzer ohne weiteres m glich ber einen gewissen Zeitraum hin weg eine gro e Anzahl von Objekten zu erzeugen Wenn man den Idealfall betrachtet da diese Pro grammierumgebung die einzige vom Benutzer genutzte Anwendung ist so werden alle vom Benutzer erzeugten und bearbeiteten Daten im Shared Data Space und seiner persistenten Erweiterung vorliegen Um diese Datenmengen berschaubar handhaben zu k nnen ist es unbedingt n tig dem Benutzer eine Strukturierungsm glichkeit zu geben Das hei t der Benutzer mu die M glichkeit haben seine Daten entsprechend seinen Vorstellungen hierarchisch gliedern zu k nnen Als einfachste M glichkeit bietet sich eine Dateisystemstruktur an d h die Datenobjekte werden als einzelne Dateien unter ihrem Objektnamen abgespeichert Parallel dazu wird eine Liste mit den Objekt Ids gehalten Zur hierarchischen Strukturierung dienen dann die normalen Verzeichnisstrukturen Es besteht auch die M glichkeit Meta Information in gesonderten Dateien abzulegen Unter Performance Gesichtspunkten hat diese L sung jedoch ihre Schw chen da jeder Zugriff durch eine Reihe von Systemaufrufen und den Standarddateizugriff des Betriebssystems erfolgen mu Es erscheint daher g nstiger einen exklusiven Bereich auf dem permanenten Medium zu reservieren und diesen unter eigener Regie m glichst optimal zu nutzen Dies erm glicht auch die einfac
13. die Ausgabe daten des Moduls auf dem entfernten Rechner werden durch die AVS Remote Module Support Library und gegebenenfalls nach Konvertierung durch xdr Routinen ber Berkeley Sockets zum lokalen Rech ner berspielt Dort werden sie n tigenfalls f r das lokale Datenformat durch xdr Routinen konvertiert und dann vom Flow Executive an das Filtermodul weitergereicht F r die Kommunikation ber diese Socket Verbindung werden Remote Procedure Calls verwendet TCP IP AVS Remote Module Flow Compute Support Library XDR XDR y Executive g Filter Abbildung 3 2 Datentransfer bei AVS ber Rechnergrenzen hinweg Auf diesem Weg sind etliche teure Zwischenschritte durchzuf hren Nachdem das Modul seine Aus gabedaten erzeugt hat reicht es diese an die AVS Remote Module Support Library weiter die wiederum die xdr Routinen zur Konversion aufruft Diese Konversion ist nat rlich nicht n tig wenn die beiden Rechner dasselbe Datenformat benutzen In einer Supercomputer Workstation Umgebung ist dies jedoch h ufig nicht der Fall insbesondere wenn Cray Computer benutzt werden Die xdr Routinen auf Super computern sind jedoch h chst ineffizient verglichen mit den Routinen die die Hersteller selbst zur Ver f gung stellen und die zum Beispiel optimiert sind f r die Ausf hrung auf Vektorprozessoren siehe hierzu auch Kapitel 5 2 Messungen Hinzukommt da f r den Fall da der Flow Executive und das Modul nicht in einem einzigen Proze unterge
14. die besondere Schnittstellen erfordert wie z B Quality of Service bei ATM zu nutzen m ssen diese Schnittstellen nur im Request Broker integriert werden Alle Module sind weiterhin unver ndert lauff hig und k nnen sofort von den Vorteilen der neuen Technologie profitieren 4 1 3 Mechanismen zur Konfliktvermeidung Die einfache Tatsache da auf ein Datenobjekt von mehreren Modulen in schreibender oder lesender Weise zugegriffen werden kann birgt bereits eine gewisse Gefahr in sich w hrend ein Modul liest k nnte ein zweiter Modul schreiben so da entweder ein gar nicht mehr aktuelles Objekt gelesen wird oder aber was in der Regel deutlich schlimmer ist ein inkonsistentes Bild als Ergebnis des Lesevorgan ges entsteht eine H lfte des Datenobjekts war w hrend des Lesens noch auf dem alten Stand die andere H lfte bereits durch das neue Datenobjekt ersetzt Durch die Verteilung von Datenobjekten auf mehrere Rechner gewinnt diese Problematik noch weiter an Bedeutung Vereinfachend wiederum wirkt da es sich bei diesem System nicht um ein voll ausgebautes Daten banksystem handelt da sich mit vielen gleichzeitigen Schreib und Lesezugriffen auf dieselben Daten s tze innerhalb k rzester Zeit auseinandersetzen mu Vielmehr werden die zeitkritischen Zugriffe in der Regel durch den Ablauf einer mittels des visuellen Programmierens zusammengesetzten Anwendung bestimmt Dadurch wird zum Beispiel nie von mehr als einem Modul gleichzei
15. die n tig sind um den von der Anfrage beabsichtigten Effekt herbeizuf hren z B berechnen des Ergebnisses und aktualisieren des Systemstatus Aus diesen Definitionen wird bereits der Unterschied zu dem in dieser Arbeit behandelten Daten und Objektmodell deutlich W hrend die CORBA Architektur das Objekt in klassischer Manier in den Mit telpunkt aller Abl ufe stellt und Anfragen in der Form von Methoden die an ein Objekt geschickt wer den gehandhabt werden werden in COVISE Objekte und Methoden bzw Module gleichberechtigt nebeneinander gesehen Der Object Request Broker Abbildung 2 3 zeigt wie eine Anfrage von einem Client zur Implementierung des Objektes geschickt wird Der Client ist die Einheit die eine Operation auf einem Objekt durchf hren m chte und die Objektimplementierung sind der Code und die Daten die tats chlich das Objekt implementieren Der ORB ist verantwortlich f r alle Mechanismen die n tig sind die passende Objektimplementierung zur Anfrage zu finden die Implementierung f r den Empfang der Anfrage vorzubereiten und die Daten die diese Anfrage ausmachen zu kommunizieren Seite 10 2 3 Motivation des Verteilungsmechanismus Das Interface das der Client sieht ist v llig unabh ngig davon wo das Objekt liegt welche Program miersprache benutzt wurde es zu implementieren oder von jedem anderen Aspekt der nicht die Schnitt stelle des Objektes betrifft Der Object Request Broker zeichnet sich also da
16. r x_koord und z_koord dargestellt 4 Trifft der Konstruktor beim Lesen auf einen Zeiger auf ein anderes Datenobjekt so wird dieses ebenfalls sofort f r den Zugriff vorbereitet Dies ist eigentlich ein rekursiver Vorgang d h man steht genau dort wo man am Anfang des Zugriffes auf das gerade bearbeitete Objekt stand man hat seine Adresse im Shared Data Space Im Falle eines Polygons ist dann jedoch schon bekannt da es sich um ein Linien Unterobjekt handeln mu Bei einem Mengenobjekt ist jedoch nichts ber den Typ bekannt Soll ein Datenobjekt gelesen werden von dem der Typ noch nicht bekannt ist so tritt ein Mechanis mus in Aktion den man als virtuellen Konstruktor bezeichnen k nnte man ruft ihn auf ohne zu wissen was als Ergebnis herauskommen wird Da diese M glichkeit von C jedoch nicht zur Verf gung gestellt wird mu te ein entsprechender Mechanismus implementiert werden Im wesentlichen wird basierend auf der im Shared Data Space vorhandenen Typ Identifizierung aus einer Liste von vorher registrierten Datentypen der richtige herausgesucht und ein entsprechendes Objekt erzeugt Der Modul programmierer hat dann die M glichkeit den tats chlichen Typ abzufragen und basierend darauf in ent sprechende Routinen zu verzweigen genaueres hierzu findet sich in Kapitel 4 6 Wesentliche Strategien der Implementierung Seite 39 4 Konzept eines verteilten Visualisierungssystems 4 3 Persistenz 4 3 1 Definition von Persiste
17. ren Einarbeitungsaufwandes als ein sehr positiver Faktor erwiesen dies gilt sowohl f r die Wartung als auch die Weiterentwicklung der Software Selbstverst ndlich l t sich auch in C modular programmie ren und auch eine gewisse Objekt Orientiertheit erreichen wenn auch nicht so elegant wie in C Die zwangsweise Besch ftigung mit Klassen Objekten und Methoden in C macht es dem Programmierer jedoch wesentlich leichter wirklich objekt orientiert zu programmieren 54 Wie bereits in Abschnitt 2 3 erl utert wurde ist die Objekt Orientierung im Hinblick auf die Daten objekte des Shared Data Space nicht nach dem klassischen Objekt Methode Ansatz erfolgt bei dem das Objekt im Mittelpunkt steht Vielmehr wurde ein Ansatz verfolgt bei dem Objekt und Methode d h in diesem Fall Modul gleichberechtigt nebeneinander stehen Bei der Implementierung jedoch wurde die volle Bandbreite objektorientierten Programmierens genutzt So wurde eine Proze klasse eingef hrt die die gesamte Kommunikation mit den anderen Prozessen sowie das Management des Shared Data Space bernimmt Je nach den speziellen Anforderungen der einzelnen Proze typen Request Broker Anwen dungsmodul Controller etc werden einzelne Klassen abgeleitet die die spezifischen Daten und Seite 55 4 Konzept eines verteilten Visualisierungssystems Methoden enthalten Es gibt unter anderem Klassen fiir die Anbindung an den Shared Data Space fiir Socket Verbindungen fiir das E
18. Ein Modul empf ngt seine Befehle start stop beenden etc und Informationen z B Parameter immer tiber dieselbe Verbindung vom Controller alles was mit dem Datenaustausch mit anderen Modulen zu tun hat geht tiber die Verbindung zum Request Broker Auch ist es f r einen Modul vollkommen transparent ob der n chste Modul lokal oder auf einem anderen Rechner liegt Der Austausch von Daten mit anderen Modulen wird immer auf die selbe quasi lokale Weise durchgef hrt Das Moduldesign wird dadurch wesentlich vereinfacht was sich bei der Entwicklung neuer Module deutlich bemerkbar macht Der ganze Aufwand der zur Verwaltung mehrerer Socketverbindungen und zur internen Ablaufsteuerung n tig ist entf llt Weitere Vorteile bestehen in der weitergehenden Trennung von anwendungsspezifischen und kom munikationsspezifischen Systemteilen wenn man einmal von der Mindestkommunikation eines Moduls mit dem Controller und dem Request Broker absieht Dadurch da die komplette Kommunikation von Daten im Gegensatz zur Steuerinformation an einer wohldefinierten Stelle im System stattfindet ist es besonders einfach die zur optimalen Nutzung von High Performance Hardware n tigen Anpassungen und Parametermodifikationen schnell und effizient durchzuf hren ohne auch nur einen Modul neu kom pilieren zu m ssen Dies ist insbesondere im Hinblick auf die Erweiterung eines Hardwaresystems durch neue Netzwerk komponenten wichtig Um eine neue Netztechnologie
19. Erzeugung eines neuen Datentyps hnlich einer Struktur in der Programmierspra che C dient die oberste Ebene Mittels dieser Ebene lassen sich alle Elemente der unteren drei Hierarchiestufen zu einer neuen Gruppe zusammenfassen Die prinzipielle Speicherung dieser Gruppe hnelt der eines Character Feldes zun chst eine Typ Identifizierung dann die L nge des Feldes in Bytes dann die einzelnen Elemente selbst Im weiteren werden Datentypen der Ebene Seite 35 4 Konzept eines verteilten Visualisierungssystems vier als Strukturdatentypen bezeichnet Ein neudefinierter Datentyp wird ber eine Typidentifizierung in das System aufgenommen Zun chst gibt es die explizit festgelegten Grunddatentypen CHARSHM SHORTSHM INTSHM LONGSHM FLOATSHM DOUBLESHM sowie die Typen der zweiten Ebene CHARSHMARRAY SHORTSHMARRAY INTSHMARRAY LONGSHMARRAY FLOATSHMARRAY und DOU BLESHMARRAY Die Zeiger der dritten Ebene sind an dem Typ SHMPTR und ihre Felder an SHMPTRARRAY erkennbar Dann gibt es noch eine Reihe von Spezialtypen zur Verwaltung der Objekte z B eine Objekt Identifizierung Ein zusammengesetzter Datentyp der Ebene vier ist ganz einfach daran zu erkennen da er zu keinem der anderen Datentypen geh rt Wenn also beim Parsen des Shared Data Space eine Typidentifizierung auftritt die keinem der fest eingebauten Datentypen entspricht kann davon ausgegangen werden da es sich um einen neuen Daten typ ha
20. Geometriedaten Koor dinaten Farben Normalen dann das resultierende Pixelbild e Abschlie end wird dieses Pixelbild vom Displayschritt auf dem Bildschirm ausgegeben In vielen F llen werden Rendering und Displayschritt in einem Schritt zusammengefa t 1 1 3 Die Verteilung Die Visualisierungspipeline liegt in der Regel nicht komplett auf dem Rechner auf dem auch die Simulation l uft Daf r gibt es eine Reihe von Gr nden Einer der wesentlichen ist da Rechenzeit auf dem Supercomputer auf dem die Numerik in der Regel am schnellsten l uft im Vergleich zu der lokalen Workstation die der Wissenschaftler an seinem Arbeitsplatz hat sp rbar teurer ist Viele Visualisie rungsalgorithmen sind auch nicht an die speziellen Gegebenheiten der Supercomputer angepa t so da sie auf einer Workstation kaum langsamer laufen als auf dem Supercomputer Dar berhinaus kann es durchaus vorkommen da das Antwortzeitverhalten des Supercomputers f r die interaktive Nutzung zu langsam ist bedingt z B durch entsprechend hohe Auslastung durch gro e Numerikberechnungen Hinzu kommt da die Graphikhardware die in Workstations heute zu finden ist bereits sehr leistungsf hig ist und das rein software m ige Rendern direkt auf dem Supercomputer nur in wenigen F llen sinn voll ist z B bei Volume Rendering Auf der anderen Seite ist es wenig sinnvoll und in der Regel unm glich die oben erw hnten 57 6 GB auf eine Workstation zu laden Selb
21. Graphikhardware genutzt werden kann und die Bilder anschlie end auf der Workstations des Benutzers dargestellt werden In diesem Fall wird die Graphikdarstellung ber X Windows abgewik kelt befinden sich Server und Client auf demselben Rechner kann eine eventuell vorhandene Graphik hardware f r die Darstellung genutzt werden Sollen Module auch auf einem anderen Rechner laufen kann man sogenannte Execution Groups bil den In solchen Gruppen werden mehrere Module zusammengefa t die dann einem speziellen Rechner zugewiesen werden k nnen Beim Start des Data Explorers wird dann auf jedem der beteiligten Rechner ein Executive gestartet der f r die Ausf hrung der Module seiner Execution Group zust ndig ist Der Master Executive das ist der mit dem das Benutzer Interface verbunden ist initialisiert die Kommuni kation mit den anderen Executives und steuert die Ausf hrung der Programme User Interface Client Script _ bo I Sprache Executive A B C D Server Datenmanagement Abbildung 3 4 Kommunikation des IBM Data Explorer Eine andere M glichkeit eine Anwendung zu verteilen sind die Outboard Module Outboard Module werden separat bersetzt und laufen auch als separater Proze die Datenkommunikation wird hier ber Sockets abgewickelt selbst wenn die kommunizierenden Prozesse auf demselben Computer laufen Ein Outboard Modul kann auch auf einem anderen Computer
22. KB s 4950 KB s 1 852 0 003 0 002 1 849 8472 KB s 8458 KB s 2 047 0 016 0 016 2 030 7714 KB s 7652 KB s 1 557 0 016 0 015 1 541 10161 KB s 10056 KB s Tabelle 5 4 C94 zu Y MP HIPPI asynchrones write Der Schl ssel zur besseren Ausnutzung der HIPPI Infrastruktur liegt in den Parametern der verwen deten Sockets hier im wesentlichen bei der Puffergr e Die Standardpuffergr e die vom Betriebssy stem vorgegeben wird ist f r den Einsatz von Ethernet oder FDDI gedacht und liegt in der Gr enordnung von mehreren KB Da die Leistung von HIPPI mit seiner theoretischen Maximaltrans ferrate von 100 MB s jedoch deutlich ber der dieser Netzwerke liegt wird der Overhead der mit den Standardpuffergr en verbunden ist zu einer deutlichen Bremse bei 100 MB s und einer Puffergr e von 8 KB m ssen ca 12500 Pakete verschickt werden Durch Erh hen der Puffergr e auf 384 KB reduziert sich diese Anzahl auf etwa 300 Pakete Der Parameter TCP_WINSHIFT sorgt unter UNICOS f r eine entsprechende Vergr erung des Puffers In Tabelle 5 5 ist denn auch der Erfolg dieser Ma nah men zu sehen CuttingPlane RB in PEGASE packobj Netzwerk Nettodurchsatz Bruttodurchsatz 2 419 0 011 0 008 2 408 2672 KB s 2660 KB s 6 080 0 019 0 009 6 069 1060 KB s 1058 KB s 0 194 0 078 0 073 0 116 55475 KB s 33171 KB s 19 217 0 012 0 009 19 205 335 KB s 334 KB s 0 130 0 013 0 009 0 117 55001 KB s 49501 KB s 24 933 0 015 0 009 24
23. Modul A Modul B Abbildung 4 4 Deadlock Situation Nach der Definition des Benutzer Isolationsgrades von Transaktionen in 21 l t sich diese Art des Zugriffs mit dem Isolationsgrad 3 belegen Anhand der dortigen Benutzer Definition von Isolation soll dies berpr ft werden Eine Transaktion ist in diesem Kontext definiert als ein abgeschlossener Zugriff eines Moduls auf ein Datenobjekt im Shared Data Space Eine Transaktion ist isoliert von anderen Transaktionen wenn gilt 0 Eine Transaktion T berschreibt keine ung ltigen Daten anderer Transaktionen Gilt da ein Schreibzugriff nur dann erlaubt wird wenn kein anderer Zugriff stattfindet Seite 32 4 1 Die verteilte Datenverwaltung 1 Von T geschriebene Daten werden vor T s Abschlu von anderen Transaktionen weder gelesen noch geschrieben Gilt da w hrend eines Schreibzugriffes keine anderen Zugriffe weder lesen noch schreiben erlaubt werden 2 T liest keine ung ltigen Daten anderer Transaktionen Gilt da w hrend eines Schreibzugriffes keine anderen Schreibzugriffe erlaubt werden 3 Andere Transaktionen schreiben keine ung ltigen Daten die T liest bevor T nicht beendet ist Gilt da w hrend eines Lesezugriffes keine Schreibzugriffe erlaubt werden und ein Lesezugriff auf ein Datenobjekt auf das bereits schreibend zugegriffen wird nicht erlaubt wird Die Zugriffe von Modulen auf Datenobjekte die ber den Request Broker ge
24. Partitionen zun chst nicht von Interesse sein diese werden bei Partikelverfolgungen ben tigt Nachdem der erste Modul ein partitioniertes Datenobjekt ge ffnet hat teilt er dies dem Controller mit und beginnt mit seiner Arbeit Der Controller schickt daraufhin eine Startbotschaft zum n chsten Modul mit dem Hinweis da es sich um ein partitioniertes Objekt handelt Dieser Modul erzeugt daraufhin wie derum ein partitioniertes Objekt f r die Ausgabe von Datenobjekten teilt dem Controller mit da er bereit ist und wartet darauf da die erste Partition seines Eingabeobjektes eintrifft Der erste Modul hat in der Zwischenzeit seine erste Partition erzeugt und in das partitionierte Datenobjekt hineingesteckt Dadurch wird der Request Broker ber das Vorhandensein einer neuen Partition informiert und unter richtet wiederum alle Module die sich f r die Bearbeitung dieses partitionierten Datenobjektes angemel det haben ber das Vorhandensein dieser Partition Diese k nnen jetzt auf die neue Partition im Shared Seite 46 4 4 Partitionierte Objekte Data Space zugreifen und ihrerseits mit der Arbeit beginnen Die Resultate dieser Arbeit werden in die partitionierten Ausgabedatenobjekte gesteckt was die Benachrichtigung der darauf wartenden Module bewirkt Nach Abschlu der Arbeiten warten die Module wieder auf eine neue Partition ihrer Inputob jekte 4 4 4 Datentypen und Visualisierungsalgorithmen bei der Partitionierung Die Partit
25. Vereinfachungen hinsichtlich der Diskretisierung der Motorgeometrie und der Behandlung der Turbulenz die in einer Motorinnen raumstr mung auftreten Trotz all dieser Vereinfachungen dauert die Berechnung eines vollen 4 Takt Zyklus eines Otto Motors auf schnellen Workstations etwa 30 Tage Auf einem Supercomputer reduziert sich dies zwar deutlich nimmt aber immer noch viele Stunden in Anspruch Je nach Komplexit t k nnen sogar mehrere Tage vergehen Direkte Konsequenz dieser gro en Rechenzeiten und der komplizierten Geometrien ist eine gro e Menge an Daten Im Beispiel des Motors kommt man bei etwa 1 000 000 Gitterpunkten einem Daten satz pro Grad Kurbelwinkel 720 bei insgesamt zwei Umdrehungen und mindestens zehn Werten pro Gitterpunkt Koordinaten Geschwindigkeit Temperatur Druck Konzentration der wichtigsten Ele mente Verbindungen auf 57 600 000 000 Bytes also 57 6 GigaByte an Daten 1 1 2 Die Visualisierung Die einzige M glichkeit solche Datenmengen sinnvoll auszuwerten besteht in der Regel darin sie graphisch darzustellen zu visualisieren 7 17 41 Dazu werden eine ganze Reihe von Visualisie rungstechniken angewendet die sich in einer sogenannten Visualisierungspipeline darstellen lassen Seite 1 I Einleitung siehe Abbildung 1 1 In dieser Visualisierungpipeline sind die Schritte die zu einer solchen Visualisie rung geh ren zu sehen 31 Simulation ie Filter gg Mapper I Renderer
26. Verteilung der Daten gehandhabt werden sollte Der Objektmanager von AVS Express verwaltet zwar die Objekte aber aufgrund des bisher monolithischen Ansatzes kein eigener Proze l t sich nicht absehen wie dieser Objektmanager in einer verteilten Umgebung arbeiten wird Das Projekt MP Express wird zur Zeit von AVS nicht weiter verfolgt Obwohl AVS Express mit einem Objektmanager arbeitet und identifizierbare Objekte kennt kann man nicht von einem datenbankorientierten Ansatz sprechen Die Objekte werden dem Benutzer auf der Benutzungsoberfl che angeboten und lassen sich dort auch bearbeiten aber es gibt keine Datenbank hnlichen Zugriffsm glichkeiten Beim Programmieren von Modulen hat man allerdings die M glich keit eine einfache Suche anhand des Namens eines Objektes durchzuf hren 3 1 3 IRIS Explorer Die Systemarchitektur von IRIS Explorer wurde von Craig Upson dem Entwickler von AVS konzi piert Die Vermutung da auf den Erfahrungen mit der Entwicklung von AVS aufbauend einige Ver n derungen oder Verbesserungen in das Design eingebaut wurden best tigen sich bei einem Blick auf die Systemarchitektur von IRIS Explorer siehe Abbildung 3 3 19 26 27 Im Gegensatz zu AVS gibt es hier nicht nur einen Flow Executive der alle Abl ufe koordiniert son dern ein zweistufiges Konzept Dem Flow Executive entspricht dabei im wesentlichen der Global Con troller GC Hier ist die Information ber die Topologie gespeichert we
27. Zei ger reserviert Bei einem Feld reserviert der Request Broker nun einen Speicherbereich der ben tigten Gr e und tr gt dann dessen Adresse in den daf r reservierten Speicherplatz f r einen Zeiger ein Han delt es sich um einen Zeiger auf ein Objekt so wird entweder der in diesem Fall gleich mitgelieferte Zei ger eingetragen oder der Zeiger als Null Zeiger initialisiert Nachdem nun der ben tigte Speicherbereich zugeteilt und die administrativen Daten des Datenobjek tes initialisiert sind schickt der Request Broker die Adresse d h Segmentnummer und Offset zur ck an das Modul das diese Anfrage stellt Der gesamte Vorgang ist atomar d h zwischen dem Eingang der Message mit der Bitte um Objekterzeugung und dem Zur cksenden der Adresse des erzeugten Datenob jektes f hrt der Request Broker keine anderen Services aus Da dieser Vorgang in der Regel jedoch nicht allzu lange dauert stellt dies keine Beeintr chtigung der Gesamtperformance dar Probleme k nnten h chstens auftreten wenn die Zeiten die f r die Reservierung von Speicherplatz im Shared Data Space ben tigt werden aufgrund einer gro en Anzahl von kleinen Objekten zu sehr wachsen Dann lie en sich jedoch problemlos zwischen einzelnen Reservierungsvorg ngen Abfragen einbauen die nach den neue sten Messages fragen und diese gegebenenfalls sofort behandeln Damit das Modul auf das neu erzeugte Datenobjekt zugreifen kann sind mehrere Schritte notwendig die in etwa denen e
28. den graphischen Darstellungsm glichkeiten eines Visualisierungssystems zu einem Werkzeug verkn pft werden das dem Nutzer die vollst ndige Kontrolle ber die Verteilung der Daten auf den genutzten Rechnern erm glicht Aufgezeigt wird eine M glichkeit diese beiden Welten so miteinander zu verbinden da die Vorteile beider Bereiche zusammenkommen Der Schwerpunkt liegt in dieser Arbeit dabei zum gr ten Teil auf der Visualisierungsseite Wie k nnen Ans tze die aus dem Gebiet der Datenverwaltung kommen f r eine effizientere Visualisierung genutzt werden Wie l t sich die Handhabung der Daten in einer Visua lisierungsumgebung mit Hilfe von Datenmanagementtechniken verbessern Ist der durch solche Techni ken zus tzlich eingef hrte Aufwand gerechtfertigt Aus den Anforderungen die an die gew nschte Visualisierungsumgebung gestellt werden insbeson dere die effiziente Nutzung verteilter Umgebungen ergibt sich schnell da ein modularer Ansatz sehr gut geeignet ist die damit verbundenen Probleme zu l sen 37 Das hei t die Visualisierungsfunktiona Seite 3 I Einleitung lit t wird in Module zerlegt die entweder auf demselben oder aber auch auf verschiedenen Rechnern ausgef hrt werden k nnen Die daraus folgenden Besonderheiten bei der Integration der Visualisierung mit einer entsprechenden Datenverwaltung erfordern entsprechende Interfacetechnologien In einem baustein artigen System m ssen die Schnittstellen ber d
29. der Kopie wird sozusagen der Lesezugriff gleich mitkopiert Da auch meh rere Lesezugriffe gleichzeitig aktiv sein k nnen k nnen somit auch mehrere Kopien gleichzeitig zum Lesen freigegeben werden Betrachtet man nun das Anlegen einer Kopie als permanenten Lesezugriff damit der Request Broker Leseanfragen seiner Module ohne zeitraubende Nachfrage genehmigen kann bleibt nur der Fall eines Schreibzugriffes gesondert zu behandeln Dies soll zun chst f r den Fall da das Original zum Schreibzugriff freigegeben werden soll betrachtet werden Hierf r mu jeder Request Broker der eine Kopie des Datenobjektes besitzt befragt werden ob nicht gerade eine Lesezugriff wirklich aktiv ist Falls ja kann man entweder warten bis dieser Zugriff beendet ist oder aber den Schreibzugriff ablehnen und damit das Warten in den Schreibzugriff anfordernden Modul verlagern Falls kein Lesezugriff bei einem der Request Broker die eine Kopie haben aktiv ist kann der Schreibzugriff erteilt werden Aus Effizienzgr nden wird man bei der Anfrage Seite 33 4 Konzept eines verteilten Visualisierungssystems bei diesen Request Brokern gleich den Lock f r den Schreibzugriff mitsetzen so da mit dem Einver st ndnis des letzten Request Brokers der Schreibzugriff dem anfragenden Modul erteilt werden kann Wird nun die Anfrage nach dem Schreibzugriff nicht f r das Originaldatenobjekt sondern f r eine Kopie gestellt so wird der Request Broker der Kopie b
30. der Persisten z asien een en 43 4 4 Parlitionierte Objeklesu uns sea 43 4 4 1 Definition der Partitionierung a secssnektiieeninukieenine 43 4 4 2 Gr nde f r die Partitionieruns ana ee 44 4 4 3 Die Synchronisierung des Zugriffes auf Partitionen 20022000ss essen 46 4 4 4 Datentypen und Visualisierungsalgorithmen bei der Partitionierung 47 4 5 High Performance Komponenten ccccceescecceeseeceeesneceeeeeeeeeeeeneeees 51 II SUBereomp ler an ena ea A EE A ges pueden San ueteen tess 51 ASD INCI WER E rioni ae essen nee else 53 Seite X 4 6 Wesentliche Strategien der Implementierung enesnen 54 4 6 1 Die Programmiersprache und verwendete Systemfunktionen eee 54 4 6 2 Objekt Offentenine 51 eis 55 4 6 3 Zugriff auf die Datenobjekte Ss Ba ehe 57 Kapitel 5 FRE SUIT AUG sun 2 een 67 Di lt Anwendunssbeispiele Au cnessikinetetfetes ea 67 5 1 1 PEGASE Berechnung einer Wirbelaufl sung uursuursusesnersneesnnennnennnnennn 67 5 1 2 Str mung im Zylinder eines Motors 222csssssesssnsnsssnnensnnenssnnennnnnnnnonsnnnanann 68 31 3 SUOMI Meinem Saustchr var 72 SEA MESSUNG en es ee ee Eee ee 74 5 2 1 Messungen zwischen zwei Indigo Workstations uursuersseenseessnersnennnnennnen nen 76 5 2 2 Messungen zwischen den beiden Cray Vektor Supercomputern uee 79 5 2 3 Messungen zwischen einer Workstation und einer Cray eusersnersn
31. deutlich gr er ist als der einer SGI Indigo R4000 beim Kopieren Um eine effizi ente Konvertierung vornehmen zu k nnen sind nat rlich Zusatzinformationen ber Typ und Feldgr en im Shared Data Space mitgespeichert n heres dazu in Abschnitt 4 2 Verschiedene Netzwerktechnologien erfordern unter Umst nden auch verschiedene Parameter f r die Verbindung um den optimalen Gebrauch der darunterliegenden Hardware zu erm glichen So hat zum Beispiel die Einstellung der Puffergr en bei TCP Sockets einen ganz wesentlichen Einflu auf den erreichbaren Durchsatz Die Konzentration der Datenverbindungen auf die Request Broker erm glicht es eine auf den f r die jeweilige Hardwaresituation abgestimmte Umgebung zu erzeugen Das k nnte theoretisch soweit gehen da auf jedem Rechner in einem Pool eine f r dessen Netzwerkinterfaces opti mierte Version des Request Brokers vorhanden ist aber dieselben Module zur Ausf hrung kommen Das mag sich zwar etwas bertrieben anh ren doch unsere Erfahrungen bei den Messungen siehe Abschnitt 5 2 haben gezeigt da gerade bei sehr schnellen Technologien wie z B HIPPI bereits das Abweichen eines Parameters vom Optimum zu deutlichen Leistungseinbu en f hrt Seite 30 4 1 Die verteilte Datenverwaltung 4 1 2 Vorteile der fehlenden Direktverbindung Die Vermeidung einer direkten Verbindung zwischen den Modulen hat mehrere Vorteile Die Pro grammierung eines Moduls wird von viel Ballast befreit
32. die Datenbanken sie werden dazu genutzt eine gro e Menge von Daten so zu speichern da ein Benutzer m glichst einfach auf sie zugreifen kann Es gibt M glichkeiten in diesen Daten zu suchen und eine ganze Reihe von Operationen auf ihnen durchzuf hren verkn pfen sortieren usw d h sie zu analysieren Betrachtet man diese beiden Abs tze genau so stellt man jedoch sehr schnell eine grundlegende Gemeinsamkeit dieser beiden Gebiete fest beide helfen dem Benutzer dabei die Daten zu verstehen und zu nutzen Bei der Visualisierung berwiegt dabei der Aspekt der Einsicht bei den Datenbanken der der Strukturierung und Ordnung Es wird aber unmittelbar deutlich da sich die beiden Gebiete sehr gut erg nzen wer viele komplexe Daten zu analysieren hat braucht unbedingt eine M glichkeit Ordnung in seinen Daten zu halten Wer Ordnung in einer gro en Menge von Daten zu halten hat kann durchaus ein Instrument gebrauchen da es ihm erm glicht sich diese Daten genauer anzuschauen Es gibt jedoch noch weitere Unterschiede bei den Begriffen Ordnung und Anschauen in den beiden Gebieten Bei Datenbanken stellt man sich meist eine gro e Menge relativ hnlicher Datens tze oder objekte vor die f r sich genommen vergleichsweise klein sind wie zum Beispiel die Personaldaten einer gro en Firma Bei der Visualisierung komplexer Daten handelt es sich meist um sehr gro e Datens tze die zwar eine innere Struktur haben wie z B die Elemente b
33. die Module der gerade ausge w hlten Kategorie Die rechte Liste zeigt die Objekte die beim aktuellen Ausf hrungszustand der Anwendung vorhanden sind Durch Anklicken lassen sich diese Objekte detailliert inspizieren siehe dazu auch Abbildung 5 5 Datenobjekt Anzeige der Partikelbahn Im rechten unteren Fenster ist die OpenInventor basierte Graphikdarstellung zu sehen Auch in die sem Fenster gibt es eine Spalte in der die Objekte auf denen diese Graphik basiert zu sehen sind Bei dem rechten oberen Fenster handelt es sich um ein Parameterfenster in dem die Parameter einzelner Module gemeinsam dargestellt und vom Benutzer ge ndert werden k nnen E COVISE MapEditor vistst7 35 COVISE CtiPanel vistst7 Session Execution Hosts Setups iMasterConiret CuttingSurface 1 0 064539 0 002714 23 254999 Hosts Categories 0 99791 Collect 1_OUT 01 ColorMap_1_OUT_01 ColorMap 2 OUT 01 u EEE Renderer File Viewing Editors Manips Lights Sync e MASTER Colormaps Geometry Objects sync menr RWCovise_5_OUT_01 2 Collect_1_OUT_01 Collect 2_OUT_01 TracerUSG_2_OUT_01_0 TracerUSG_2 OUT_01_1 Messages from Modules UIF gt gt can t find timer record for requested vistst7_isovalue Rotx Roty 45 1 Abbildung 2 2 Bildschirma
34. die Schwerpunkte durchaus auch auf verschiedene St r ken dieses Ansatzes gelegt bei SPOCK auf die Erweiterbarkeit bei COVAS auf die Flexibilit t auch bei der Visualisierung gro er Datenmengen ber relativ langsame Datenverbindung bei VRS Lab auf die effiziente Daten bertragung bei Echtzeit relevanten Anwendungen Die Datenverwaltung neben der Gesamtsteuerung der zentrale Teil in COVISE erf llt dabei h chste Anforderungen unter verschieden sten Bedingungen Siehe auch 3 37 70 und 79 5 2 Messungen In Kapitel Kapitel 4 Konzept eines verteilten Visualisierungssystems wurde bereits mehrfach erw hnt da bei der Konzeption und Implementierung gro er Wert auf eine effiziente Ausnutzung von High Performance Komponenten wie Supercomputern oder schnellen Netzwerken gelegt wurde ver gleiche hierzu auch 22 47 und 77 In diesem Kapitel soll anhand einiger ausgew hlter Messungen belegt werden da dieses Ziel erreicht wurde Der Vergleich mit anderen verteilten Visualisierungs werkzeugen gestaltet sich jedoch etwas schwieriger die Me punkte die f r die Messungen benutzt wur den liegen zu einem gro en Teil an Stellen des Systems die bei kommerziellen Produkten f r den Modulprogrammierer nicht zug ngig sind Daher k nnen f r diese Produkte nur wenige Messungen durchgef hrt werden HIPPI Y MP CISCO Router Switch fe HIPPI Channel NSC DXE CY PX Ethernet
35. ein Fileserver F und zwei Benutzerworkstations A und B wobei Benutzerworkstation B mit tels einer relativ langsamen Netzwerkverbindung mit den beiden anderen Rechnern verbunden ist deren A Abbildung 5 3 Leistungsf higkeit von Rechnern und Netzwerk Seite 69 5 Resultate Kosten sich auch nach der tibertragenen Datenmenge richtet Die Verbindung zwischen A und F soll mit gew hnlicher LAN Geschwindigkeit arbeiten Beide Workstations haben nur begrenzten Speicherplatz der es nicht erm glicht den kompletten Datensatz vom Fileserver dorthin zu laden Der Fileserver ist eigentlich nur f r die Haltung von Daten aber nicht f r die Durchf hrung von Berechnungen gedacht Dennoch steht eine verglichen mit den Workstations sehr hohe Rechenleistung zur Verf gung die allerdings nur gegen eine entsprechend hohe Geb hr auch genutzt werden kann In Abbildung 5 3 ist eine graphische Darstellung dieser Verh ltnisse zu sehen wobei Gr e bzw Dicke f r die Leistungsf higkeit des Rechners bzw des Netzes stehen und die Farbe f r die damit verbundenen Kosten dunkel teuer wei preiswert F r die Visualisierung sollen nun folgende Algorithmen zum Einsatz kommen e die Berandung des Berechnungsgebietes mu bestimmt werden e um einen guten Eindruck von der Str mung zu bekommen sollen anfangs einige Partikel verfolgt werden e zur genauen Analyse wird im Laufe der Sitzung mehrfach die Isofl che mit verschiedenen Werten f
36. einzelnen Modulen ben tigt werden werden vom Benutzer an der Benutzungsschnittstelle eingestellt und ber den Flow Executive an die Module weitergereicht Bei AVS werden Module nicht notwendigerweise als einzelne Prozesse gestartet Vielmehr sind h u fig genutzte Module in einem gemeinsamen Executable untergebracht Dies bringt auf der einen Seite den Vorteil da der Rechner nicht mit unn tig vielen Prozessen belastet wird andererseits verhindert dies z B die einfache Parallelisierung von parallel verlaufenden Zweigen des Netzwerkes auf Rechnern mit mehr als einem Prozessor Der Datenaustausch zwischen solchen Modulen ist nat rlich einfach durch den gemeinsamen Adre bereich zu bewerkstelligen Module die auf demselben Rechner aber in verschiedenen Prozessen laufen tauschen ihre Daten ber Shared Memory aus der schreibende Modul legt seine Ausgabedaten dort ab bermittelt dem lesenden Modul die Adresse der Daten dort woraufhin dieser die Daten direkt f r seine Arbeit nutzen kann Im Gegensatz zu fr heren Versionen von AVS wer den auch wenn beide Module auf einem anderen Rechner als der Flow Executive laufen keine Daten ber das Netzwerk verschickt Dabei wird unter Umst nden auch eine direkte Verbindung zwischen den Modulen zum Datentransport genutzt Wenn die beiden Module auf verschiedenen Rechnern laufen f llt das Shared Memory als direktes Kommunikationsmittel nat rlich aus Hier arbeitet AVS wie folgt siehe Abbildung 3 2
37. exklusiv zur Verf gung gestellt wird Dies ist jedoch bei vier Prozessoren eine schwierige Angelegenheit es ist auch frag lich wieviele Benutzer bereit w ren den entsprechenden Preis f r die zum Teil nicht verbrauchte CPU Zeit zu zahlen Mit der zunehmenden Verbreitung von Rechnern mit mehr Prozessoren zum Bei spiel die NEC SX4 des Rechenzentrums mit 32 Vektorprozessoren k nnte es jedoch durchaus eine sinn volle Erg nzung zum traditionellen Batch Betrieb darstellen 5 2 3 Messungen zwischen einer Workstation und einer Cray Nach den Messungen zwischen jeweils zwei Rechnern gleicher Gr enordnung sollen hier die Resul tate von Messungen f r den Datenaustausch zwischen einem Supercomputer und einer Workstation untersucht werden Dieser Fall d rfte auch die h chste Praxisrelevanz haben da die meisten Benutzer von einer Workstation aus auf die Supercomputer zugreifen Bei den Me punkten siehe Abbildung 5 11 handelt es sich um eine Kombination aus den Me punkten der jeweils paarweisen Messungen der Workstations und Supercomputer Besondere Bedeutung kommt bei diesen Messungen der Datenkon version zu Die Cray Vektorsupercomputer bedienen sich eines eigenen Formats f r die Repr sentation von Flie kommazahlen das vom Standard IEEE Format abweicht Dies bedeutet da jede Flie komma zahl die von einer solchen Cray zu einer Workstation geschickt wird konvertiert werden mu Dieser Konvertierungsvorgang wird explizit zwischen
38. gew hrlei sten ist eine hierarchische Gliederung der Grunddatentypen eingef hrt worden 1 Auf der untersten Ebene befinden sich die einfachen Datentypen f r Zahlen und Buchstaben Eine solches Element wird gespeichert indem zuerst eine Codierung des Datentypes und dann das eigentliche Datum selbst geschrieben werden Die verf gbaren elementaren Datentypen sind char short int long float und double 2 Der gr te Teil der zu speichernden Daten wird in der Regel aus umfangreichen Feldern mit Ele menten desselben Datentyps bestehen Die zweite Hierarchieebene wird daher von Feldern gebil det Beim Speichern eines solchen Feldes wird zun chst der Feldtyp geschrieben dann die Anzahl der Elemente des Feldes und anschlie end die Elemente selbst Felder k nnen aus den elementa ren Datentypen bestehen 3 Auf der dritten Ebene findet sich der Typ eines Zeigers Dieser Zeiger verweist einfach nur auf eine andere Adresse innerhalb des Shared Data Space Eine Adresse im Shared Data Space besteht aus einer Segmentnummer und einem Offset in dieses Segment Die Segmentnummer ist n tig um eine dynamische Erweiterung des Shared Data Space durch einfaches Hinzunehmen von neuen Segmenten zu erm glichen ohne alle bereits vorhandenen Daten umspeichern zu m ssen Ein Zeiger braucht als Speicherplatz f r die Typcodierung die Segmentnummer und den Offset Analog zu den Feldern der zweiten Ebene gibt es auch ein Feld mit Zeigern 4 Zur kompletten
39. in the special surrounding of a high performance environment is described taking especially the aspects supercomputing and networking into account The main strategies for the implementation also belong here The application of the data management concept to real problems will be discussed in the subsequent chapter The practicability of the approach will be shown in real applications the distributed visualisa tion of a vortex breakdown the flow in an internal combustion engine and the flow in a water turbine Since performance is an important issue for the practical use a number of measurements under different conditions will demonstrate the potential of the concept Finally an evaluation of the work will be given and an outlook will be offered on the possibilities that the concept opens up beyond the frame of the aspects realised in this thesis Seite VIII Inhaltsverzeichnis VOEWOL u En Re V Z sammenfass n Ss enra ne de tila ec tinea See E oa VII Abstract seits aaa situations VIII TAAL TS VSL ZS LEIS u a IX Abbildumssverzeichnis sis EEE XII Tabellenverzeichnit areeni soei age XV Kapitel 1 EEUE erraten ee era 1 kl Di Problemstelliins sau 1 WIL Die Dat n tosissanne a aT E esse 1 112 Die Y nal senine wlan dike eh we ua cascade en betas 1 1 1 3 Die Yertellune 2222 22 u Eee 2 1 2 Zielsetzung der Arbeit 2 2 3 1 3 Gliederung der Arbeit 222 82 reine 5 Kapitel 2 Die COVISE Visualisierungsumgebung
40. k nnen ist es n tig sie auf das IEEE Format zu konvertieren Dies wird am effizientesten von den von Cray angebote nen vektorisierenden Systemkonvertierungsroutinen bewerkstelligt Da allerdings nur dann konvertiert werden soll wenn dies auch wirklich n tig ist wird beim Verbindungsaufbau gepr ft welches Zahlen format die beiden Rechner benutzen und dann entschieden ob und wenn ja auf welchem Rechner kon vertiert werden soll siehe hierzu auch Kapitel 5 2 Messungen So wird zum Beispiel bei einer Verbindung des Cray Compute Servers mit dem Cray File Server nicht konvertiert bei einer gleichzeitig bestehenden Verbindung mit einer SGI Workstation jedoch schon Als Standard Netzwerkformat wurde das IEEE Format gew hlt mit der Byteordnung der MIPS Prozessoren Sollte also ein Cray Vektorcom puter mit einem Intel basierten Windows NT PC kommunizieren w rde der Cray Rechner auf das IEEE Format konvertieren und der Intel PC dann die Byte Ordnung ndern Die Nutzung der Cray eigenen vektorisierenden Konvertierungsfunktionen mag selbstverst ndlich erscheinen ist es aber leider nicht AVS zum Beispiel benutzt f r die Konvertierung die xdr Routinen Dabei handelt es sich um zwar weitverbreitete aber gerade f r die Konvertierung von gro en Datenmen gen recht ineffiziente Routinen die wohl der Einfachheit und der Portabilit t halber zum Einsatz kom men aber deutliche Geschwindigkeitseinbu en mit sich bringen Shared Memory Eine w
41. laufen dann wird eine Socket Ver bindung zum Haupt Executive aufgebaut Die Autorisierung bei der Ausf hrung eines Moduls auf einem anderen Computer wird ber den rhosts Mechanismus sichergestellt Dies ist jedoch eine relativ unsi chere Methode und wird daher zum Beispiel auf den gro en Compute Servern des Rechenzentrums der Universit t Stuttgart nicht unterst tzt 3 1 5 Ensight Wie bereits in der Einleitung zu diesem Kapitel erw hnt wurde folgt Ensight nicht dem Paradigma des visuellen Programmierens 15 Damit zusammenh ngend findet sich auch der Modul orientierte Ansatz nicht bei Ensight Vielmehr ist Ensight das als MPGS urspr nglich von der Firma Cray Research Inc entwickelt wurde ein klares Client Server Programm Die Ausf hrung der Visualisierungsalgorith Seite 23 3 Vergleich mit existierender Software men findet auf dem Server statt der fr her in der Regel ein Cray Supercomputer war und die Benut zungsschnittstelle sowie die Graphikausgabe finden sich auf dem Client normalerweise die Workstation am Arbeitsplatz des Benutzers Die Daten die dargestellt werden stammen in der Regel aus Dateien Aufbauend auf der Struktur dieser Daten kann der Benutzer verschiedene Algorithmen auf diese Daten anwenden z B eine Schnitt fl che durchlegen oder Partikel einstreuen Hier wird eine quasi nat rliche Objekt Orientierung aus der Sicht des Nutzers angewendet Allerdings besteht keine weitergehende Kontrolle tiber dies
42. r den Anteil des verbrannten Gases berechnet werden Dabei reicht die Speicherkapazit t der beiden Workstation nur f r die von der Isofl chenberechnung ben tigten Daten aus F r dieses Szenario soll jetzt eine optimale Verteilung der Visualisierung gefun den werden die Visualisierung soll nat rlich so schnell wie m glich aber nur so teuer wie n tig sein Randfl che berechnen Isofl che berechnen lt T Renderer Lesen eS S gt SA e L gt OA x i S B SSS I OR o gt Partikel 4 Ba Renderer verfolgen D ral Abbildung 5 4 Verteilung der Module und Daten Da es sich bei den Partikelverfolgungen um unter Umst nden recht aufwendige Berechnungen han delt die jedoch nur einmal vorkommen k nnen diese ohne allzugro e Kosten am besten direkt auf dem Fileserver erfolgen Genauso wird mit der Berechnung der Randfl che verfahren Die Berechnung der Isofl chen wird dagegen relativ h ufig ausgef hrt so da sie g nstiger auf Rechner A ausgef hrt werden kann selbst wenn dies anf nglich einige Sekunden Zeit kostet um die Daten vom Fileserver dorthin zu kopieren Auf Workstation B mu nur der abschlie ende Renderschritt ausgef hrt werden kollaborativ Seite 70 5 1 Anwendungsbeispiele mit dem Renderer von Workstation A Fiir die Verteilung ergibt sich die Situation wie
43. r die Git tergenerierung dient Im Rahmen der visuellen Programmierumgebung werden einfach die entsprechen den Aus und Eing nge der beteiligten Module verbunden und der Benutzer mu sich nicht um Dateien und deren Namen k mmern Beendet er eine Sitzung so mu er nicht nacheinander alle Zwischenobjekte in Dateien abspeichern vielmehr werden alle Datenobjekte die nicht als nicht persistent markiert sind automatisch ber den Persistenzmechanismus abgespeichert und stehen beim n chsten Programmaufruf sofort wieder zur Ver f gung Der Benutzer hat mittels der hierarchischen Strukturierung auch die M glichkeit Datengruppen aus verschiedenen Sitzungen jeweils getrennt zu halten und diese dann je nach Bedarf wieder anzukop peln von Speichern und Laden sollte in diesem Zusammenhang nicht gesprochen werden da das Abspeichern kein explizit ausgel ster Vorgang ist sondern automatisch vom System zur gegebenen Zeit durchgef hrt wird dies kann zum Beispiel auch dann passieren wenn der zur Verf gung stehende Bereich im Shared Data Space knapp wird und Objekte auf die l nger nicht zugegriffen wurde ausgela gert werden F r den Benutzer ergibt sich also eine Arbeitsweise die deutlich n her an der realen Welt orientiert ist wenn ein Handwerker ein Objekt bearbeiten will nimmt er es in die Hand wenn er seine Arbeit unterbricht legt er es wieder weg Am n chsten Tag ist das Objekt immer noch da ohne da explizit eine Handlung n tig i
44. sie in Abbildung 5 4 dargestellt ist Die Visualisierung l uft nun folgenderma en ab der Lesemodul liest die Daten aus einer Datei und schreibt sie in die entsprechenden Datenobjekte Geometrie Gitter 1 Restgaskonzentration 2 und Geschwindigkeitsfeld 3 Aus 1 wird nun direkt die Randfl che berechnet aus 3 die Partikelbahnen Der n chste Schritt findet nun auf Workstation A statt die Isofl che fordert Objekt 2 an dieses wird vom Request Broker zu Objekt 2 ber die LAN Verbindungen kopiert und der Isofl chenmodul erzeugt anschlie end Datenobjekt 6 Der Renderer fordert abschlie end die Objekte 4 und 5 an die ebenfalls ber die LAN Verbindung vom Request Broker kopiert werden Daraufhin sieht der Benutzer an Workstation A das vollst ndige Bild Parallel zur Isofl chenberechnung hat bereits der Renderer von Workstation B die Datenobjekte 4 5 und 6 angefordert Die Datenobjekte 4 und 5 werden bereits ber die langsame WAN Verbin dung vom Request Broker in die Objekte 4 und 5 kopiert Wenn diese bertragung abgeschlossen ist und die Isofl chenberechnung auf Workstation B beendet ist wird das Datenobjekt 6 von dort in das Objekt 6 auf Workstation B kopiert und der Renderer dort kann nun ebenfalls das komplette Bild zei gen Insgesamt werden auf dem teureren Fileserver die Berechnungen der Randfl che und der Partikelver folgung durchgef hrt ber die langsame Netzwerkverbindung
45. t der Isofl chenberechnung bei partitionierten Objekten das Nachbarelement in der n chsten Partition hat f r die Fortsetzung der Isofl che dieselben beiden Alternativen zur Auswahl Diese beiden Fortsetzungen m ssen aufeinander abgestimmt werden was im Fall des partitionierten Objektes zu einem Informationsaustausch mit dem Nachbarelement f hrt Darstellungen der Topologie eines Str mungsfeldes ben tigen f r ihre Berechnung zumindest die erste Ableitung meist auch die zweite der zugrundeliegenden Daten Damit die sinnvolle Fortsetzung dieser Ableitungen ber Partitionsgrenzen hinweg gegeben ist m ssen f r ihre Berechnung auf Randele menten einer Partition die Daten auf den Randelementen der benachbarten Partition miteinbezogen wer den Im Gegensatz zur Partikelverfolgung ist die Nichtlokalit t der Isofl che und der topologischen Dar stellungen allerdings begrenzt Das hei t da von einer Nachbarpartition in der Regel nur die u erste abh ngig von der ben tigten Ableitung auch die zweit u erste Elementh lle ben tigt wird Diese l t sich wenn die Partitionierung von der Anwendung selbst durchgef hrt wird durch berlappung jeweils lokal einf hren Wenn die Partitionen von einer anderen Anwendung bernommen werden lie e sich noch ein Durchgang vorschalten der diese berlappung f r die Partitionen erzeugt Dies ist jedoch mit einem vergleichsweise hohen Aufwand verbunden Seite 50 4 5 High Performance Kompo
46. werden Diese Datenobjekte sind jedoch f r den interaktiven Benutzer nicht zugreifbar Vielmehr definiert dieser Paare von Datenobjekten und Methoden die dann automatisch ausgef hrt werden wenn sich ein Parameter oder die Graphikdarstellung ndert Die sehr enge Integration aller Algorithmen in Form von Methoden in eine ausf hrbare Datei erlaubt dabei eine sehr hohe Geschwindigkeit Die Methoden befin Seite 14 2 5 GRAPE den sich dabei in einem sortierten Baum und werden ber einen ASCII Namen aufgerufen Die Datenob jekte liegen direkt in Form eines Zeigers vor Diese Strukturen machen GRAPE zu einem extrem effizienten Visualisierungswerkzeug da Para meter nderungen genauso schnell darstellt wie einfache geometrische Transformationen Die konse quent durchgehaltene Objekt Orientierung macht es sehr einfach GRAPE zu erweitern und anzupassen So lassen sich beispielsweise neue Graphikbibliotheken nach Implementierung weniger Methoden z B update begin_patch patch_normal schnell nutzen Die Ausgabe in eine PostScript Datei erfolgt bei spielsweise ber dieselbe draw Methode wie in ein Graphikfenster vorher wird nur das Graphik Device auf PostScript gesetzt GRAPE und COVISE Die Klassen f r die einzelnen Datenobjekte sind in GRAPE und COVISE sehr hnlich Das zugrun deliegende Verst ndnis vom Verh ltnis von Datenobjekten zu Methoden Modulen ist im Prinzip das selbe GRAPE ist jedoch im Gegensatz zu COVISE ausschlie li
47. werden die Randfl che die Ergebnisse der Partikelverfolgung und die Isofl che bertragen Soll nun die Isofl che neu berechnet werden so ergibt sich folgender Ablauf der Isofl chenmodul auf Workstation A greift auf das Datenobjekt 2 zu Da bereits eine Kopie 2 dieses Datenobjektes im lokalen Shared Data Space existiert wird dessen Adresse zur ckgegeben und der Isofl chenmodul kann seine Arbeit beginnen ohne da Daten ber das Netz geschickt werden m ssen Wenn der Isofl chen modul fertig ist schreibt er ein neues Datenobjekt 6 und die beiden Renderer auf den Workstations A und B werden ber diese nderung informiert Der Renderer auf Workstation A greift auf die Objekte 5 und 6 direkt zu und stellt das neue Ergebnis dar Auf Workstation B greift der Renderer auf die Objekte 4 und 5 direkt zu w hrend vor dem Zugriff auf das neue Objekt 6 eine neue Kopie 6 angelegt werden mu Diese Kopie wird durch bertragung aus dem Shared Data Space von Work station A erzeugt F r die Darstellung der ge nderten Isofl che ist nur eine kostenpflichtige bertragung der Geometrie dieser Isofl che ber die WAN Verbindung erforderlich Ansonsten findet keinerlei Datentransfer statt Dies macht deutlich da der in dieser Arbeit dargestellte Ansatz auch in der Lage ist f r komplexeste im Industriealltag tats chlich vorkommende Problemstellungen eine optimale L sung anzubieten In Abbildung 5 5 i
48. zu partitionieren Zum Abschlu dieses Kapitels werden einige praxisorientierte Betrachtungen angestellt die Realisie rung des Konzeptes im besonderen Umfeld einer High Performance Umgebung wird unter den beiden Aspekten Supercomputer und Netzwerke beschrieben Die wesentlichen Strategien bei der Implementie rung geh ren ebenso dazu Die Anwendung des Datenverwaltungs Konzeptes auf reale Probleme wird im vorletzten Kapitel untersucht In drei realen F llen wird die Praktikabilit t des Ansatzes gezeigt die verteilte Visualisie rung der Berechnung einer Wirbelaufl sung der Str mung in einem Motorinnenraum und der Str mung im Saugrohr einer Turbine Da f r die Praxis die Performance eine nicht unerhebliche Bedeutung hat folgt eine Reihe von Messungen die unter verschiedensten Bedingungen die Leistungsf higkeit des Kon zeptes demonstrieren Abschlie end erfolgt eine Bewertung der Arbeit sowie ein Ausblick ber die M glichkeiten die das Konzept ber die im Rahmen dieser Arbeit realisierten Aspekte bietet Seite VII Abstract Visualisation systems that work on large amounts of data as the ones produced by numerical simula tions must deal with this data efficiently In this thesis the requirements will be examined that the data management of such a visualisation system must fulfill in order to perform the visualisation of the results of complex numerical simulations These requirements are assessed for a standard application cas
49. 20 ennnennnen nen 78 Me punkte der Konfiguration Y MP C94 nuuenseersnersnesnnennnnennner nennen 79 Me punkte der Konfiguration Indigo C94 2uucnuessnersnesnnennnnennnen seen 82 Graphik der Me ergebnisse aus Tabelle 5 9 22u02220022042 20 esse nnnnennnen nn 85 Graphik der Me ergebnisse aus Tabelle 5 10 ucrsersseesseessnersnennnnennnen nn 87 Seite XIV Tabellenverzeichnis Tabelle 3 1 Tabelle 3 2 Tabelle 5 1 Tabelle 5 2 Tabelle 5 3 Tabelle 5 4 Tabelle 5 5 Tabelle 5 6 Tabelle 5 7 Tabelle 5 8 Tabelle 5 9 Tabelle 5 10 Tabelle 5 11 Definition der Versgleiehskriterien ass ee 24 Vergleich der Visuahsierungssysteme una eaadeaete adenine 25 Indiz Z0 ndi to PDI a2 2 I TT COATT YMA SE Ds aaa E E T a e 79 C9470 Y MPS HIPP Ei 80 C94 zu Y MP HIPPI asynchrones write essssessessssesssesesseessseessseessresseessee 81 C94 zu Y MP asynchrones write optimale Socket Parameter 81 C94 zu Indigo Ethernet kleiner Datensatz oc ceesceceeseeeeeeeceeeeeeeeneeees 83 C94 zu Indigo FDDI kleiner Datensatz u uses 83 C94 zu Indigo FDDI gro er Datensatz uusnseeessnseesssnnenssnnensnnnenennnn 84 C94 zu Indigo FDDI gro er Datensatz leere C94 ncnnsennennennenn 85 Y MP zu Indigo HIPPI nach FDD 220220002200r ser snennnennnnennnenenn 86 Y MP zu Indigo HIPPI nach FDDI leere Y MP eneen 87 Sei
50. 918 258 KB s 258 KB s 20 873 0 013 0 008 20 860 308 KB s 308 KB s Tabelle 5 5 C94 zu Y MP asynchrones write optimale Socket Parameter In den meisten der Durchl ufe ist die Auslastung der beiden beteiligten Cray Rechner ersichtlich Insbesondere bei der Y MP wird der anfragende Proze meist aus dem Hauptspeicher in den Swap Bereich verlagert bevor die Antwort wieder da ist Aber im dritten und besonders im f nften Fall ist zu erkennen da ein deutlicher Anteil des theoretisch erreichbaren Durchsatzes realisiert wurde Genaue Berechnungen des Nettodurchsatzes ergaben maximale Transferraten von etwa 66 MB s durch genaue Inspektion der Me zeiten und Vergleich von Hin und R ckweg Speziell im f nften Durchlauf wird auch deutlich da der Benutzer einen sehr gro en Anteil dieser Performance tats chlich in der Anwen dung sieht Es ist also durchaus m glich aus einer Standard Anwendung heraus durch optimale Ein stellung der Parameter einem Benutzer einen wesentlichen Teil der Leistungsf higkeit der genutzten Seite 81 5 Resultate Infrastruktur verf gbar zu machen Besonders deutlich wird hier aber auch da es dazu immer noch optimaler Bedingungen bedarf die hohe Auslastung bewirkt gerade da in diesem empfindlichen Netz werkbereich die Leistung drastisch einbricht wenn nicht alles genau pa t Eine Verbesserung dieser Situation lie e sich zum Beispiel dadurch erreichen da dem Benutzer eine CPU
51. 94 Cox M Ellsworth D Application Controlled Demand Paging for Out of Core Visualiza tion in Yagel R Hagen H Eds Visualisation 1997 Proceedings pp 235 244 IEEE Computer Society Los Alamitos 1997 Earnshaw R A Wiseman N An introductory Guide to Scientific Visualization Springer Verlag Berlin 1992 Earnshaw R A Watson D Animation and Scientific Visualization Tools amp Applicati ons Academic Press London 1993 Ehnis K Lang U Loebich I Pilz M R hle R DFN RSYST Verteilung einer Modell und Methodendatenbank mit Datenbasis im offenen Netz IKE Stuttgart 1985 Ensight User Manual for Version 5 2 Computational Engineering International Inc Research Triangle Park NC 1994 Fejes L Johannsen G Str tz G Hierarchical Data Structure for Dynamic Visual Systems in Knuth E Wegner L M Eds Visual Database Systems pp 219 234 North Holland Amsterdam 1992 Seite 95 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 7 Literatur Geiben M Rumpf M Visualization of Finite Elements and Tools for Numerical Analy sis Report 9 SFB256 Bonn 1991 erschienen in F H Post A J Hin Eds Advances in Sci entific Visualization Springer Lecture Series Band Workshop Proceedings 1993 Gentzsch W Harms U
52. Abbildung 4 12 Direkt von der Klasse ShmItem sind die beiden Klassen ShmPtr und ShmArray abgeleitet um Zeiger und Felder verwalten zu k nnen Diese beiden Klassen stellen im Seite 58 4 6 Wesentliche Strategien der Implementierung Prinzip nur einen direkten Zugriff auf die eigentlichen Daten mittels der Methode get_data_ptr bereit Bei der Feldklasse gibt es eine zus tzliche Variable die die L nge des Feldes enth lt ShmItem Shm_seq_no int offset int type int pointer void get_shm_seq_no get_offset get_type get_pointer A Abbildung 4 12 Klassenhierarchie der Zugriffselemente ShmPtr ShmArray length int ShmPtr ShmArray int seq_no int seq_no int offs int offs set_ptr get_length int seq_no set_ptr int offs int seq_no get_data_ptr int offs get_data_ptr IntShmArray ShmPtrArray StringShmArray IntShmPtr ShmPtrArray StringShmArray int seq_no int seq_no int seq_no int offs int offs int offs set_ptr set_ptr set_ptr int seq_no int seq_no int seq_no int offs int offs int offs operator int amp int operator int operator int char amp Distributedobject string_ptr_set grow int size int int no set int shm_seq_no int i in
53. Darstellung zu sehen in der die Zeit dargestellt ist die in den einzelnen Abschnitten verbracht wurde Die Skalierung ist so gew hlt da die wesentlichen Details zu erkennen sind der Ausrei er in den Me daten aus dem dritten Durchlauf geht weit ber den rechten Rand hinaus In dieser Darstellung ist sehr deutlich zu sehen welch gro en Anteil an der Gesamtzeit das Auspacken der Daten auf der Workstation hat etwa ein Viertel der Zeit wird f r diesen Teil aufgewen det Der gr te Teil der restlichen Zeit geht in den tats chlichen Datentransfer ber das Netzwerk Die Kommunikation zwischen dem Tracer Modul und dem lokalen Request Broker kann vernachl ssigt wer Seite 85 5 Resultate den die Zeit die auf der C94 zum Konvertieren und Einpacken gebraucht wird ist auch relativ klein im Vergleich zum Auspacken auf der Workstation Die Rate beim Konvertieren und Einpacken liegt immer hin noch bei ber 180 MB s zum Vergleich nur Einpacken auf der C94 450 MB s auf der Indigo 20 MB s Auch hier zeigt sich deutlich die berlegenheit der auf H chstleistung ausgelegten Supercompu ter Architektur HIPPI Messungen Als letzte Gruppe von Messungen sollen hier noch die f r die vom HIPPI Interface der Y MP zum FDDI Interface der Indigo gehende Verbindung dargestellt werden Diese Verbindung f hrt vom HIPPI Interface ber einen NSC DX HI Router in den FDDI Ring und dann direkt wiederum ber den Giga switch zum FDDI Interface der Works
54. E Das objekt orientierte Graphiksystem GRAPE GRAphics Programming Environment wird seit 1985 an der Universit t Bonn sowie seit 1992 auch an der Universit t Freiburg entwickelt siehe 55 17 und 74 Basierend auf der Programmiersprache C wurde ein objekt orientierter Kernel entwik kelt Objekte in diesem System sind hnlich wie in COVISE die Datenelemente mit denen der Benutzer arbeitet also Finite Elemente Gitter Geometrien oder hnliches Die Visualisierungsalgorithmen werden als Methoden direkt auf diese Datenobjekte angewendet Dabei sind die verschiedenen Datentypen als Klassen definiert die sich innerhalb einer Vererbungshierarchie befinden Diese ist relativ flach unter scheidet aber zum Beispiel zwischen Gittern Triang3D und Gittern mit Daten Fe3D Bei Geometrien gibt es eine Hierarchie von Punkten ber Linien zu Polygonen und Volumina Da es sich bei GRAPE um ein monolithisches und nicht verteiltes System handelt ist es relativ ein fach alle Visualisierungsalgorithmen direkt als Methoden auf den entsprechenden Datenobjekten zu implementieren So gibt es zum Beispiel f r die Klasse Fe3D eine Methode cutting plane die die Schnittfl che durch das Gitter berechnet und als Objekt der Klasse Surface zur ckgibt Durch Schicken der Methode draw wird anschlie end das Ergebnis graphisch dargestellt Die Visualisierungspipeline aus Kapitel 1 wird also in verschiedenen Schritten abgearbeitet zwischen denen Datenobjekte erzeugt
55. Eine objekt orientierte Datenverwaltung fiir eine verteilte Visualisierungsumgebung Von der Fakultat fiir Energietechnik der Universitat Stuttgart zur Erlangung der Wiirde eines Doktor Ingenieurs Dr Ing genehmigte Abhandlung vorgelegt von Andreas Wierse geboren in Trier Hauptberichter Prof Dr Ing Roland Riihle Mitberichter Prof Dr Ing Eberhard G de Tag der Einreichung 11 Oktober 2000 Tag der miindlichen Priifung 26 Oktober 2001 Anwendungen der Informatik im Maschinenbau AIM Fakultat fiir Energietechnik der Universitat Stuttgart 2001 Meiner Frau und meinem Sohn Seite III Seite IV Vorwort Die vorliegende Arbeit entstand w hrend meiner T tigkeit als wissenschaftlicher Mitarbeiter am Rechenzentrum der Universit t Stuttgart RUS und am Institut f r Computeranwendungen II ICA II Mein besonderer Dank gilt Herrn Professor Dr Ing Roland R hle der das RUS und die Abteilung Com putersimulation und Visualisierung des ICA II leitet f r seine Unterst tzung sowie f r die bernahme des Hauptberichtes und die Betreuung des Promotionsverfahrens an der Universit t Stuttgart Mein Dank gilt ebenfalls Herrn Professor Dr Ing Eberhard G de vom Institut f r Stromungsmecha nik und Hydraulische Str mungsmaschinen der Universit t Stuttgart f r die freundliche bernahme des Mitberichtes und seine Unterst tzung Diese Arbeit entstand als Teil des Software Systems COVISE und ist daher nur m glich gewes
56. HIPPI Y N C9 4 NSC DXE HI lt Indigo IP FDDI Ring FDDI FDDI FDDI Indigo Abbildung 5 7 Umgebung f r die Messungen In Abbildung 5 7 ist ein Ausschnitt aus der Konfiguration des Rechenzentrums zu sehen auf der die Messungen dieses Kapitels zum gr ten Teil durchgef hrt wurden Gemessen wurden die Datenraten zwischen folgenden Rechner Netzwerkinterface Paaren Seite 74 5 2 Messungen e C94 HIPPI und Y MP HIPPI direkt ber den HIPPI Switch e C94 FDDI und Y MP FDDI ber den NCS DXE CY Channel Router e Y MP HIPPI und Indigo FDDI ber den HIPPI Switch und den NXC DXE HI Router e C94 FDDI und Indigo FDDI direkt ber den FDDI Ring e C94 FDDI und Indigo Ethernet ber den CISCO Router e Indigo FDDI und Indigo FDDI direkt ber den FDDI Ring Zu bemerken ist noch da der FDDI Ring physikalisch aus zwei FDDI Ringen besteht die ber einen Giga Switch gekoppelt sind Logisch handelt es sich jedoch um einen einzigen Ring Der Durch satz wird durch den zus tzlichen Router jedoch nur minimal d h kaum me bar beeintr chtigt so da es durchaus legitim ist von einem FDDI Ring zu sprechen Die Rechner in dieser Abbildung sind folgenderma en konfiguriert e Cray C94 4 Prozessoren 8 GB Hauptspeicher UNICOS 8 0 2 3 HIPPI und FDDI Netzwerkinterface nor malerweise voll ausgelastet w hrend der Messungen mehr als 25 numerische Simulationen gleic
57. High Performance Computing and Networking Proceedings Volume I und II Springer Verlag Berlin 1994 Globus A Perspectives on the IRIS Explorer Visualization Environment Computer Sci ences Corporation Report RNR 91 021 1992 G bel M M ller H Urban B Visualization in Scientific Computing Springer Verlag Wien 1995 Gray J Reuter A Transaction processing concepts and techniques Morgan Kaufmann Publishers San Mateo California 1993 Haas P Christ P Networking Issues in PAGEIN The N of HPCN Lecture Notes in Computer Science W Gentzsch U Harms Vol 797 pp 86 93 Springer Berlin 1994 Hege H C Polthier K Visualization and Mathematics Springer Verlag Berlin 1997 Hocke M Otter M Entwicklung integrierter Programmsysteme mit RSYST Rechen zentrum der Universit t Stuttgart RUS 4 M rz 1990 Hocke M Seybold J Wagner U Visualisierung und Animation von Mehrk rpersyste men unter Verwendung eines objektorientierten Geometrie Datenmodells Forschungs und Entwicklungsberichte RUS 18 Rechenzentrum der Universit t Stuttgart 1993 IRIS Explorer User s Guide Release 3 Silicon Graphics 1995 IRIS Explorer 2 0 Technical Report Silicon Graphics Computer Systems Mountain View 1992 Keim D Enhancing the Visual Clustering of Query Dependent Database Visualization Techniques Using Screen Filling Curves
58. Science and Enginee ring YUFORIC Germany 98 Stuttgart 16 18th June 1998 Seite 99 7 Literatur Seite 100
59. Software derum die entsprechenden Eingabeports der nachfolgenden Module aktiviert So wird implizit tiber die Bereitstellung von Resultaten der Ablauf gesteuert Die meisten der in diesem Kapitel besprochenen Programmpakete folgen diesem Ansatz Die einzige Ausnahme stellt Ensight von CEI dar Die M glichkeit zur Verteilung von Funktionen ist bei Ensight nur sehr rudiment r da Ensight jedoch ein weitverbreitetes Visualisierungssystem ist wird es mit einer kur zen Betrachtung in diesen Vergleich mit einbezogen So einleuchtend und sinnvoll der Ansatz des reinen visuellen Programmierens auch erscheint so bringt die Tatsache da Datenflu und Ablaufsteuerung untrennbar miteinander verbunden sind doch das ein oder andere Problem mit sich Ein offensichtliches Problem ist da es keinen Weg gegen den Flu gibt Da die Ausf hrung eines Moduls ber das Eintreffen eines neuen Datenobjektes an einem der Eingabeports ausgel st wird entsteht beispielsweise sofort eine Endlosschleife wenn man den Ausgang eines Moduls mit dem Eingang eines vorher ausgef hrten Moduls verbindet da es keine nat rliche Abbruchbedingung gibt Aus diesem Grunde finden sich heute in den verbreiteten Programmen die dem visuellen Programmieren folgen fast immer Abwandlungen oder Erweiterungen des reinen Datenflu modelles 3 1 1 AVS AVS ist der Urahn des visuellen Programmierens in der wissenschaftlichen Visualisierung Als erstes Programmpaket dieser Art im wes
60. aften die zwischen Prozessen verschickt werden immer mit einer Typ Identifizierung versehen sind lassen sich auch Botschaften die von au en kom men eindeutig dem Modul oder dem Request Broker Teil zuordnen Botschaften vom Modul an den Request Broker werden nun nicht mehr ber einen Socket verschickt sondern direkt als Argument an die Eingangsschleife des Request Brokers bergeben Die Stellen an denen bei Shared Memory Rechnern die Verwaltung dieser Shared Memory Segmente erfolgt legen nun ber den C Mechanismus new neue Speichersegmente an die im weiteren Programmablauf genauso behandelt werden wie Shared Memory Segmente Die Kapselung dieser Differenzen ist so vollst ndig da der Quellcode f r ein Modul der auf einer Workstation die ber Shared Memory verf gt der gleiche ist wie auf einem Vektor Supercomputer ohne Shared Memory Auf der Workstation laufen Modul und Request Broker jeweils als eigenst ndiger Proze auf dem Vektor Supercomputer ist der Request Broker zusammen mit dem Modul in ein Execut able kompiliert Aber auch der Aufwand f r die Verwaltung des Bibliotheksquellcodes ist relativ gering da sich alle Unterschiede nur an wenigen Stellen innerhalb weniger Klassen befinden die sich ohne weiteres ber den define Mechanismus f r die verschiedenen Rechner unterscheiden lassen 4 6 2 Objekt Orientierung Die Nutzung einer objekt orientierten Programmiersprache hat sich trotz des anfangs deutlich gr e
61. ale Instanz f r die Verwaltung der Daten Der Wirkungsbereich eines Request Brokers ist im Gegensatz zu dem des Controllers auf den lokalen Rechner beschr nkt die Verbindung zum Controller ist f r den Ablauf nur von unter geordneter Bedeutung und wird daher in den weiteren Abbildungen aus Gr nden der bersicht weggelassen Ein Request Broker verwaltet jeweils einen Shared Data Space ber den der Austausch von Daten zwischen den einzelnen Anwendungsmodulen abgewickelt wird In der Regel gibt es auf jedem beteiligten Rechner einen Request Broker und einen Shared Data Space Lokale Workstation Entfernte Workstation UI Shared Data Space Shared Data Space Abbildung 2 1 Die COVISE System Architektur Eine ausf hrliche Erl uterung der System Architektur erfolgt in Kapitel 4 Konzept eines verteilten Visualisierungssystems Seite 8 2 3 Motivation des Verteilungsmechanismus Ein Bildschirmabzug einer Sitzung mit der COVISE Software ist in Abbildung 2 2 zu sehen und zeigt die Benutzungsoberfl che und den Renderer Deutlich zu erkennen ist im linken Fenster der einem Flu diagramm hnliche Aufbau der vom Benutzer zusammengesetzten Visualisierungsanwendung In den vier Listen unmittelbar dar ber sind die momentan zur Verf gung stehenden beteiligten Rechner aufgelistet die Kategorien unter denen die Module einsortiert sind sowie
62. amme laufen lie en Bei diesen Messungen die zwischen jeweils einer Cray und einer Indigo stattfanden wurde der weiter im Normalbetrieb befindliche FDDI Ring genutzt dieser war jedoch aufgrund der Wartung der beiden Cray Rechner nahezu ungenutzt Ziel der Messungen war genauen Aufschlu dar ber zu bekommen welche Stellen in diesem verteil ten Datenmanagement kritisch f r die Gesamtperformance des Systems sind Dazu gen gt es nicht ein fach die Zeit zwischen der Anforderung eines Datenobjektes das auf einem anderen Rechner liegt und seiner Verf gbarkeit zu messen Vielmehr sollten so viele der sich hinter diesem Vorgang verbergenden Einzelschritte so genau wie m glich erfa t werden um auch die Stellen herauszuarbeiten an denen wei tere Optimierungen den gr ten Erfolg versprechen Seite 75 5 Resultate 5 2 1 Messungen zwischen zwei Indigo Workstations Es handelt sich hierbei um zwei identisch konfigurierte Silicon Graphics Indigo XS24 Fiir diese Messungen wurde ein Modul benutzt der eine Partikelverfolgung durchf hrt Tracer Dieser Tracer greift auf ein Datenobjekt mit einer Gr e von 3 182 608 Bytes zu das sich auf dem anderen Rechner befindet Daraus ergibt sich die folgende Reihenfolge der Aktionen in Klammern stehen die Nummern der Me punkte in Abbildung 5 8 zun chst fragt der Tracer Modul seinen lokalen Request Broker nach dem gew nschten Objekt 1 und 2 Dieser sucht in seinen lokalen Datenstrukturen stell
63. ared Data Space ber diesen Mechanismus ist es m glich eine Menge von Objekten einen Set effi zient zu implementieren Aus diesem Grund gibt es auch eine Methode grow die es erlaubt das Feld jederzeit zu vergr ern Als Basisstruktur eines Sets ist es so m glich beliebig viele Elemente zu addie ren ohne sich um die Feldgr e k mmern zu m ssen Um den Zugriff auf die im Shared Data Space liegenden Daten eines Datenobjektes f r den Modul programmierer so einfach wie m glich zu gestalten wurde die Basisklasse DistributedObject ein gef hrt In dieser Basisklasse wird die Grundfunktionalit t sowohl f r den Zugriff auf die Daten als auch f r die damit verbundene Kommunikation mit dem Request Broker bereitgestellt wie zum Beispiel die Frage nach der Adresse eines bestimmten Datenobjektes im Shared Data Space oder die R ckgabe der Schreib und Leserechte Alles was mit der Struktur und den Datentypen eines konkreten Datentyps zu tun hat wird in einer zu diesem Datentyp geh renden von Distributedobject abgeleiteten Klasse bereitgestellt Diese Mechanismen sind so generell gehalten da es einem Modulprogrammierer ohne weiteres m glich ist einen eigenen Datentyp zu definieren und die dazugeh rende Datentypklasse von der Basisklasse abzuleiten Die Objekte die von dieser Basisklasse abgeleitet sind werden im weite ren als Zugriffsdatenobjekte bezeichnet Spezielle Zugriffsdatenobjekttypen Um das zu einem bestimmten Datenobj
64. as Datenobjekt zugreifen und seine Arbeit aufnehmen Die Verbindung zwischen den Request Brokern Im Vergleich zu den Verbindungen zwischen den anderen Prozessen kommt der Verbindung zwi schen zwei Request Brokern eine spezielle Bedeutung zu Die Tatsache da der gesamte Datenaus tausch zwischen zwei Rechnern genau ber diese Verbindung geht macht es besonders leicht Optimierungen durchzuf hren Nat rlich gehen auch ber die Verbindungen zwischen dem Controller und den auf andere Rechner verteilten Modulen Daten da es sich aber um Steuerinformationen im Umfang von nur wenigen 100 oder 1000 Byte handelt k nnen diese vernachl ssigt werden im Vergleich zu den m glicherweise mehreren Megabyte die zwischen Request Brokern ausgetauscht werden Leider sind noch nicht alle Rechnerhersteller dazu bergegangen IEEE Datentypen zu verwenden Auf den Cray Vektorsupercomputern z B wird ein Cray spezifisches Floating Point Format benutzt das wenn die Daten auf Workstations weiterverarbeitet werden sollen in das IEEE Format umgewan delt werden mu Diese Umwandlung geh rt zu den Aufgaben der Request Broker Beim ersten Aufbau der Verbindung zwischen zwei Request Brokern wird berpr ft ob eine Konversion n tig ist In diesem und nur in diesem Fall werden beim n tigen Datentransfer die Daten konvertiert und zwar auf dem Rechner der daf r am besten geeignet ist Messungen haben gezeigt da der Durchsatz einer Cray C90 beim Konvertieren
65. atenba sis m glich Im Laufe der Entwicklung von RSYST wurden verschiedene Varianten zur Integration von Graphik oder Visualisierungsfunktionalit t entwickelt und implementiert In 57 wird ein objekt orientierter Ansatz vorgestellt der graphische Primitive wie Kreise Rechtecke zwei und dreidimensionale Dia gramme als Objekte definiert Diese Datenobjekte wurden in der RSYST Datenbasis gehalten so da von entsprechenden Modulen auf diese Datenobjekte zugegriffen werden konnte Dieses Vorgehen unterscheidet sich deutlich von der Objekt Orientierung wie sie in COVISE aufgefa t wurde Die Objektgranularit t liegt bei COVISE auf dem Niveau des Anwendungsproblemes Datenobjekte sind hier ganze Berechnungsgitter Geometrien oder Datenfelder Die effiziente Handhabung dieser Datenob jekte als einzelne und transportable Objekte in einer verteilten Umgebung macht es erforderlich die Gra nularit t so grob wie m glich anzusetzen Es ist nicht sinnvoll jedes Graphikprimitiv einzeln ber das Netzwerk zu schicken wenn es auf einem anderen Rechner dargestellt werden soll Eine sp ter ca 1991 entwickelte Visualisierungskomponente von RSYST wurde ber einen Modul realisiert Im folgenden wird der PHIGS basierte Graphikmodul beschrieben der Graphikstandard PHIGS ist zwar nahezu komplett von der Bildfl che verschwunden aber die Kopplung von RSYST und PHIGS auch im Hinblick auf die Datenstrukturen ist im Hinblick auf das Thema dieser Arbeit sehr
66. atzes an den Request Broker Seite 61 4 Konzept eines verteilten Visualisierungssystems geschickt Anhand der vom Request Broker zuriickgelieferten Adresse werden dann die Zugriffsele mente initialisiert Die Methode st ore_shared wird immer in einem Konstruktor aufgerufen im Falle des strukturierten Gitters zum Beispiel DO_StructuredGrid DO_StructuredGrid char n int x int y int z DistributedObject n STRGRD x_coord set_length x y z y_coord set_length x y z z_coord set_length x y z store_shared 6 INTSHM amp x_disc INTSHM amp y_disc INTSHM amp z_disc FLOATSHMARRAY amp x_coord FLOATSHMARRAY amp y_coord FLOATSHMARRAY amp z_coord x_disc x y_disc y z disc Z Vor dem Aufruf von store_shared m ssen die L ngen aller Felder gesetzt sein damit der entspre chende Speicherplatz beantragt werden kann Nachdem der Speicherplatz zugewiesen und das Objekt im Shared Data Space erzeugt wurde k nnen die x y und z Variablen gesetzt werden restore_shared In der Methode restore_shared wird basierend auf einem bereits existierenden Datenobjekt das Zugriffsdatenobjekt initialisiert Zuerst wird dabei die Typinformation der Klasse die restore_shared aufruft mit der Typinformation die das Datenobjekt im Shared Data Space in sei nem Header tr gt verglichen Stimmen diese beide nicht berein wird die Initialisierung abgebrochen Andernfalls werden nun die Headeri
67. ber eine SQL Kommunikationsbibliothek wird dem Programmierer noch die M glichkeit geboten mit einem lokalen oder verteilten Datenbank Server zu kommunizieren Somit arbeitet AVS als Frontend zu einem relationalen Datenbanksystem Dies ist aber eine sehr lose Kopplung die man nicht mit einem integrierten Datenmanagement vergleichen kann 3 1 2 AVS Express AVS Express ist weder ein Abk mmling von AVS noch eine Weiterentwicklung Vielmehr haben die Entwickler von AVS sich damit eine Basis geschaffen um objekt orientierte Ans tze besser umset zen zu k nnen AVS Express ist im wesentlichen ein objekt orientiertes System allerdings nicht im Sinne der reinen Lehre sondern mit einigen Modifikationen 4 Im Gegensatz zu klassischen Objekten deren Interface in der Regel aus einem Satz von Methoden besteht besteht ein Objekt bei AVS Express aus einer Liste von Parametern die mit Namen bezeichnet sind Diese Parameter k nnen einfache Ele mente wie z B drei Flie kommazahlen zur Beschreibung einer Farbe oder einer ganzen Zahl f r die H he eines Widgets oder aber auch zusammengesetzte Objekte wie z B einem Bild bestehende aus Breite H he und einem Feld von Bilddaten sein Die Parameter eines Objektes k nnen mit anderen Parametern verbunden werden diese Verbindung steht dann f r ein Teilen der Information zwischen Objekten Wie in anderen objekt orientierten Syste men auch besitzen Objekte Methoden die jedoch nicht direkt zugreifbar sin
68. bracht sind dort noch einmal die Daten ber Sockets vom Flow Executive zum Modul geschickt werden m ssen Dar berhinaus besteht in AVS nicht die M glich Seite 19 3 Vergleich mit existierender Software keit Parameter der Netzwerkverbindung wie z B die Gr e von Socket Puffern zu ver ndern Dies ist jedoch unerl lich um in einer Supercomputerumgebung die gebotenen M glichkeiten auch effizient nutzen zu k nnen siehe dazu auch 77 und 22 Es wird deutlich da AVS in seiner gegenw rtigen Form nicht sehr gut f r eine mehr als nur einfach verteilte Visualisierungsanwendung d h mit nur einem nicht lokalen Modul geeignet ist Dies zeigt sich insbesondere wenn zwei Module dieselben Ausgabedaten eines Moduls das auf einem anderen Rechner l uft ben tigen In diesem Fall wird n mlich eine Kopie der Ausgabedaten zu jedem Modul geschickt d h die Ausgabedaten werden doppelt auf dem lokalen Rechner angelegt Zus tzlich zur dop pelten Netzauslastung beim Datentransfer werden also auch die Speicherkapazit ten doppelt belastet Die Daten die w hrend der Ausf hrung eines AVS Netzwerkes entstehen sind nur tempor rer Natur Das hei t der Benutzer hat keine M glichkeit sich diese Daten anzusehen oder sie zu modifizie ren Daher ist ein Datenmanagement durch den Benutzer auf den Dateibereich im Vorfeld der eigentli chen Visualisierung eingeschr nkt innerhalb des AVS Systems kann man keinen Einflu auf die Daten nehmen
69. bzug der COVISE Benutzungsschnittstelle 2 3 Motivation des Verteilungsmechanismus F r die Verteilung von Objekten und den Zugriff auf diese sind heute zwei Verfahren weit verbreitet DCOM von Microsoft und CORBA Bei DCOM handelt es sich um ein propriet res und bisher auf Unix Rechner nicht verf gbares Verfahren Da jedoch der Anwendungsbereich der Visualisierungspro bleme die den Ansto f r diese Arbeit gaben zum gr ten Teil auf eben diesen Unix Rechnern liegt wurde eine L sung auf DCOM Basis nicht weiter verfolgt CORBA ist inzwischen auf einer gro en Menge von Unix Workstations verf gbar Daher wird im folgenden ein berblick ber die Arbeitsweise von CORBA gegeben und dabei auch ein Vergleich mit den COVISE spezifischen Anforderungen ange stellt Seite 9 2 Die COVISE Visualisierungsumgebung CORBA CORBA ist eine Abk rzung f r Common Object Request Broker Architecture was sich bersetzen l t mit allgemeine Architektur zur Vermittlung von Objektanfragen Das zugrunde liegende abstrakte Objektmodel wie auch diese Architektur wurden von der Object Management Group OMG definiert Zu dieser Gruppe geh ren viele Hard und Softwarehersteller unter anderem Hewlett Packard Compaq Digital Equipment NCR und SunSoft Dieses Objektmodell liefert eine strukturierte Darstellung von Objekt Konzepten und Terminologie 69 Entwickelt wurde CORBA um die Komplexit t neuer Soft wareanwendungen zu reduzieren die Kost
70. ch bei den Daten um identifizierbare Objekte handelt Die Iden tifizierung im Rahmen der realisierten COVISE Software erfolgt durch einen Namen allerdings besitzt jedes Objekt eine eindeutige Objekt Id Lokaler Datenaustausch Nun soll der Ablauf der Datenkommunikation zwischen zwei aufeinanderfolgenden Modulen w h rend der Ausf hrung einer Applikation an einem Beispiel erl utert werden Wir betrachten in diesem Szenario einen Lesemodul A in Abbildung 4 2 der Daten aus einer Datei einliest und einen darauffol genden Filtermodul B Controller mea Shared Data Space Abbildung 4 2 Lokaler Datenaustausch Seite 28 4 1 Die verteilte Datenverwaltung Wenn der Controller die Startmessage an den Lesemodul sendet werden dieser die Namen unter denen der Lesemodul seine Datenobjekte ablegen soll mitgegeben In diesem Beispiel werde nur ein Datenobjekt ausgetauscht Der Controller hat vollst ndige Kenntnis ber die gesamten Parameter des Lesemoduls einzelne Parameter wie z B der Dateiname werden ber die Benutzungsschnittstelle vom Benutzer abgefragt Daraufhin beginnt der Lesemodul mit seiner Arbeit Sowie sich ergibt wieviel Spei cherplatz ben tigt wird um die gelesenen Daten im Shared Data Space abzulegen erzeugt der Lesemo dul ein Datenobjekt des ben tigten Typs in der ben tigten Gr e Dazu werden die Gr en der gew nschten Datenbereiche sowie die Struktur des Date
71. ch f r eine monolithische nicht verteilte Nutzung konzipiert Es findet sich keine M glichkeit Methoden auf anderen Rechnern auszuf hren Auch sind keine Vorkehrungen getroffen die einzelnen Datenobjekte die immerhin existieren dem Benutzer in irgendeiner Form zug nglich zu machen Seite 15 2 Die COVISE Visualisierungsumgebung Seite 16 Kapitel 3 Vergleich mit existierender Software Im ersten Teil dieses Kapitels 3 1 soll ein berblick ber die erfolgreichsten auf dem Markt befind lichen Visualisierungsprogramme gegeben werden Nach einer Vorstellung der prinzipiellen Funktions weise und einem berblick ber die Architektur des jeweiligen Programmes wird kurz untersucht wie den in Kapitel 1 1 geschilderten Problemen begegnet wird Da die Menge der verf gbaren Programme zwar recht gro ist in der Praxis aber nur sehr wenige weit verbreitet sind konzentrieren wir uns hier auf die erfolgreichsten Systeme In Kapitel 3 2 findet sich eine Vergleichstabelle in der die einzelnen bis dahin angesprochenen Visua lisierungssysteme einander gegen bergestellt werden 3 1 Visualisierungssoftware Im Bereich der Visualisierung hat sich in den letzten Jahren sehr deutlich das Prinzip des visuellen Programmierens durchgesetzt visual programming paradigm 9 59 Die Visualisierungsaufgaben werden dabei analog der Darstellung in Abbildung 1 1 auf einzelne Bausteine verteilt Hierzu w hlt der Benutzer f r jeden Verarbeitungssch
72. che scheibenweise Partitionierung bei Visualisierungsalgorithmen wie zum Beispiel der Partikel verfolgung abh ngig von den Daten sehr ineffizient sein kann Anzustreben ist eine m glichst kugel oder w rfelf rmige Form der Partitionen Sollte das Gitter jedoch unstrukturiert sein l t es sich nicht so einfach beim Einlesen partitionieren Ein unstrukturiertes Gitter besteht in der Regel aus Daten ber die Koordinaten der Eckpunkte und die Daten der einzelnen Elemente Dazu k nnen noch Nachbarschaftsinformationen kommen Da die Zuord Seite 48 4 4 Partitionierte Objekte nung von Eckpunkten und Elementen normalerweise ber die Elemente gesteuert wird d h zu jedem Element ist gespeichert welche Eckpunkte zu ihm geh ren die Numerierung der Eckpunkte jedoch v llig unabh ngig von den Elementen sein kann braucht man um eine elementgesteuerte Partitionie rung vorzunehmen im Prinzip die volle Eckpunktinformation im Hauptspeicher Wenn in der Datei jedoch zun chst die Element und dann erst die Eckpunktinformation gespeichert ist mu man den kom pletten Datensatz einlesen bevor man ihn partitionieren kann Im umgekehrten Fall werden zun chst die Eckpunktdaten eingelesen und dann w hrend des Einlesens der Elementinformation die Partitionen ana log zum strukturierten Fall gef llt Auch hier ergeben sich die Partitionierungen ganz zwangsl ufig aus der Reihenfolge in der die einzelnen Elemente gespeichert sind d h es k nnen im Ex
73. chen den beiden Rechnern ber die Datenverbindung zwischen den Request Brokern ausgetauscht Sieht man dagegen die Menge der ausge tauschten Daten wird diese fast ausschlie lich ber die Verbindung zwischen den Request Brokern gehen Es besteht daher die M glichkeit die Verbindung zwischen den Request Brokern ber andere Interfaces gehen zu lassen als die normalen Verbindungen zwischen dem Controller den Modulen und dem Request Broker 4 6 Wesentliche Strategien der Implementierung 4 6 1 Die Programmiersprache und verwendete Systemfunktionen Die gesamte Software ist in der Programmiersprache C programmiert 67 68 Obwohl zu Anfang noch deutliche Schwierigkeiten bei der Verf gbarkeit bestanden auf den Vektor Supercompu tern ist FORTRAN immer noch die Standardprogrammiersprache gefolgt von C und auch heute noch deutlich mehr Probleme bei der Verwendung von C im Vergleich zu C oder FORTRAN auftreten berwiegen die Vorteile des objekt orientierten Ansatzes die Nachteile bez glich Verf gbarkeit Fehler h ufigkeit und Performance Verlusten Speziell im Hinblick auf m gliche Performance Verluste wurde viel Wert auf eine effiziente Implementierung gelegt So wurde zum Beispiel die oft recht teuere Technik der virtuellen Methoden d h Methoden die erst zur Laufzeit bestimmt werden siehe dazu Abschnitt 4 6 2 Objekt Orientierung nur u erst sparsam eingesetzt Ebenso wurde generell auf sehr fortgeschrit tene Sprachelemente wie
74. chickt wird Dabei mu bereits der Datentyp der gew nschten Elemente mitgeschickt werden da der Bedarf nat rlich von den konkret gew nschten Datentypen abh ngt Der Request Broker berpr ft daraufhin zun chst einmal ob nicht schon ein Objekt des gew nschten Namens bei ihm oder einem anderen Request Broker existiert Danach werden die einzelnen Anforderungen nach Speicher platz bearbeitet Dabei mu unterschieden werden ob es sich um einfache Datenelemente handelt einfa che Zahlen oder Zeiger oder um Elemente die vom Objekt nur referenziert werden wie z B Felder Basierend darauf berechnet der Request Broker den Speicherbedarf f r die Speicherung des Objektes selbst ein Objekt der Stufe vier aus 4 2 2 und stellt diesen bereit Dann mu zun chst der Header gef llt werden d h es werden eine eindeutige Objekt Identifizierungsnummer erzeugt die Version und der Referenzz hler initialisiert ein Null Zeiger f r ein Attributfeld und ein Zeiger auf den Namen des Objektes eingef gt und der Bereich f r das Character Feld zur Speicherung des Namens reserviert und gef llt sowie die Anzahl der Datenelemente im eigentlichen Objekt eingetragen Die Datenelemente werden daran anschlie end abh ngig von ihrem Typ gespeichert Datenelemente aus der Ebene eins werden direkt mit ihrer Typidentifizierung gespeichert Handelt es sich um ein Feld aus Ebene zwei oder um einen Zeiger auf ein Objekt der Ebene vier so wird nur der Platz f r einen
75. chtlichkeit weggelassen ShMalloc lt gt _ RequestBrokerProcess sortiert listet besitzt ObjectEntry kommt von J RemoteRBEntry geh rt zu 1 2 AccessEntry Connection Abbildung 4 10 Die Klassen des Request Brokers Seite 56 Host 4 6 Wesentliche Strategien der Implementierung Ein RequestBrokerProcess hat einen SharedDataSpace ShMalloc keine oder viele ObjectEntries und keinen oder mehrere RemoteRBEntries Informationen ber andere RequestBroker Ein ObjectEn try hat eine Liste mit den Zugriffen die Verbindung zu dem Proze der es erzeugt hat und falls es sich um eine Kopie handelt den RemoteRBEntry von dem es herkommt Ein RemoteRBEntry hat die Host Information des Rechners f r den er die Informationen h lt die Verbindung zu diesem Proze gegebe nenfalls noch eine separate Verbindung f r den optimierten Datentransfer und eine Liste von ObjectEn tries die zu den Objekten geh ren die von diesem Host kopiert wurden 4 6 3 Zugriff auf die Datenobjekte In Kapitel 4 2 wurde bereits die Strukturierung der Datenobjekte im Shared Data Space beschrieben Hauptgrund f r die Art dieser Strukturierung ist da ein Request Broker in der Lage sein mu ein Datenobjekt das im Shared Data Space liegt zu einem anderen Request Broker zu schicken ohne da er vorher die Struktur dieses Dat
76. d Stattdessen werden diese Methoden automatisch jedesmal aufgerufen wenn sich ein Parameter ndert In AVS Express nennt sich das Execution Encapsulation Parameter eines Moduls die vom Programmierer dazu bestimmt sind mit anderen Parametern verbunden werden zu k nnen bezeichnet man als Ports Vergleicht man diese Art Objekte zu handhaben mit den Modulen aus AVS siehe Kapitel 3 1 1 so erkennt man da es sich im Kern um das gleiche Prinzip handelt man hat ein Modul das eine bestimmte Aufgabe erf llt und dazu mit Eingabedaten versorgt wird und Ausgabedaten erzeugt Aller dings ist der Objekt orientierte Ansatz von AVS Express sehr viel flexibler Interessant ist bei AVS Express der Umgang mit den Daten die zwischen den Objekten geteilt wer den In welche Richtung eine nderung eines Datums propagiert wird h ngt davon ab ob dieses Datum ber den Eingabe oder den Ausgabeport verbunden wird Falls dies ber den Eingabeport geschieht so wird das Datum innerhalb des Objektes als Referenz auf das Datum gef hrt dessen Ausgabeport am anderen Ende der Verbindung liegt Das Erzeugen von Schleifen durch den Benutzer wird dabei durch Seite 20 3 1 Visualisierungssoftware eine Uberpriifung im Moment der Verbindungserstellung verhindert Der Benutzer kann Referenzen sowohl mit der Maus als auch direkt tiber die Tastatur eingeben Sehr flexibel wird dieser Ansatz dadurch da man beliebige Objekte aus den Grundelementen wie z B Inte
77. den Me punkten 5 und 6 gemessen Der konvertierte Datensatz hat eine Gr e von 3 217 720 Byte der Cray Datensatz ist doppelt so gro wird aber von 8 Byte Cray Floats auf 4 Byte IEEE Floats konvertiert In diesem Abschnitt werden Messungen ber die gesamte Bandbreite der zur Verf gung stehenden Netzwerke pr sentiert Zum Teil wurden diese Messungen zwischen einer Indigo und der C94 durchge f hrt ein weiterer Teil zwischen einer Indigo und der Y MP Dies begr ndet sich in dem Interesse in der knappen verf gbaren Zeit einen m glichst guten berblick ber die verschiedenen f r Benutzer interes santen Szenarien zu bekommen Der Aufwand alle m glichen Szenarien unter allen Bedingungen zu untersuchen w re ungleich gr er gewesen die hier pr sentierten Untersuchungen ergeben jedoch schon einen sehr umfassenden Eindruck von den relevanten Einflu gr en Indigo C94 Tracer Datamanager PEGASE Anfrage _ gt Request Broker Teil von PEGASE ee A Konversion unpackobj 6 Abbildung 5 11 Me punkte der Konfiguration Indigo C94 Seite 82 5 2 Messungen Ethernet Messungen In Tabelle 5 6 sind die Messungen bei einem Datenzugriff ber das Ethernet zu sehen Obwohl das Ethernet nicht das geeignetste Netzwerk ist um auf einen Supercomputer zuzugreifen ist es doch in der Praxis f r die meisten Benutzer die einzige M glichkeit Im Hinblick au
78. die Ergebnisse von acht Messungen zu sehen In der zweiten Zeile sind jeweils die Me punkte zu sehen zwischen denen die entsprechenden Werte ermittelt wurden In den beiden letzten Spalten befinden sich die Ergebnisse einer Netto und einer Brutto Durchsatzberechnung F r den Netto Durchsatz wurde die Datenobjektgr e 3 182 608 geteilt durch die Zeit die im Netzwerk verbracht wurde Spalte f nf Dies ergibt eine Zahl die hinter dem eigentlich erreichten Durchsatz bei der ber tragung des Datenobjektes 6 5 zur ckbleibt der Netto Durchsatz beschreibt das Mittel der beiden bertragungen 4 3 und 6 5 Die bertragungszeit zwischen 3 und 4 d rfte in der Gr enordnung der H lfte der Differenz zwischen Spalte eins und Spalte zwei liegen Der Brutto Durchsatz wurde mit der Gesamtzeit die der Tracer Modul auf das Datenobjekt warten mu te Spalte eins berechnet Statt der relativ konservativ berechneten Netzwerkzeit w re nat rlich die genaue bertragungsrate f r eine einzelne Botschaft interessanter Allerdings w re f r diese Art von Messungen eine absolute bereinstimmung der Uhren der beteiligten Rechner n tig Diese bereinstimmung war jedoch selbst bei den beiden sehr eng gekoppelten Cray Supercomputern nicht gegeben Auch durch vergleichende Messungen der Hin und R ck bertragung lie en sich nie die exakten Werte ermitteln so da bei diesen Messungen nur Me punkte zueinander in Beziehung gesetzt werden die auf demse
79. diesem Shared Data Space so zu repr sentieren da sie vom Request Broker bearbeitet werden kann Zu den bislang implementierten Strukturdatentypen geh ren e eine ganze Reihe von Gittertypen rechtwinklige regelm ige rechtwinklig unregelm ige struk turierte unstrukturierte etc und dazupassende Datenstrukturen f r die Speicherung von den Ergebnissen numerischer Simulationen e Punkte Linien Polygone und Volumen Diese sind wiederum hierarchisch aufgebaut d h in einem Volumendatenobjekt werden in einem Unterobjekt Polygone referenziert deren Gesamt heit das Volumen bildet Diese Polygone wiederum bestehen aus einem Linien Unterobjekt und der zus tzlichen Information wie diese sich zu Linien zusammenfinden Und diese Linien beste hen aus Punkten und der Zusatzinformation wie diese miteinander zu verbinden sind e eine Klasse von Strukturdatentypen die nur andere Objekte enthalten ohne zus tzliche Informa tion hinzuzuf gen Die gebr uchlichsten sind die Menge Set und die Geometrie Ein Objekt des Typs Menge ist nichts weiter als eine Klammer um eine beliebige Anzahl von Objekten beliebigen Typs dabei ist die Anzahl beliebig und kann auch dynamisch ver ndert werden Eine Geometrie besteht aus einem Objekt das eine Basisgeometrie enth lt z B eine Polygonliste oder eine Menge von Linien sowie aus zwei optionalen Zusatzobjekten die dazu passend die Farbe und die Normalen enthalten Seite 36 4 2 Die Datenobjekte
80. durch aus da er einem Client erm glicht Methoden an Objekte zu schicken von denen er nicht wei und auch nicht wissen m chte wo sie liegen Ein Client kennt nur die logische Struktur eines Objektes basierend auf der Schnittstelle und ihren Methoden und erf hrt das Verhalten des Objektes durch den Aufruf dieser Methoden Dabei kann ein Client durchaus auch ein Objekt sein das von anderen Clients mit Anfragen zu Methodenaufrufen veranla t werden kann Client Objekt Implementierung N r S Anfrage ORB Abbildung 2 3 Eine Anfrage ber den Object Request Broker ORB CORBA und COVISE Bei CORBA handelt es sich um ein sehr sauberes Modell f r verteilte Objekte mit gro em Gewicht auf Transparenz und Flexibilit t Dieser sehr generelle Ansatz f hrte dazu da lange Zeit keine Imple mentierungen von CORBA ORBs verf gbar waren und auch die heute verf gbaren nur auf wenigen Plattformen laufen Hinzu kommt da durch die sehr generelle Auslegung ein signifikanter Overhead bedingt ist der auch bei den verf gbaren ORBs deutlich wird CORBA ist langsam Die zweite Genera tion der ORBs geht zwar dieses Problem an und ist auch deutlich schneller als die erste Generation liegt aber immer noch deutlich unter dem Optimum Die Umgebung in der COVISE zum Einsatz kommt zeichnet sich dagegen durch gro e Datenmengen aus die in zum Teil sehr speziellen Rechnerumgebun gen m gl
81. e Datei wird zun chst komplett gelesen dann werden gelesene Daten komplett gefiltert als ganzes auf eine Geome trierepr sentation abgebildet und anschlie end dargestellt Durch die Nutzung partitionierter Daten k nnte sich folgender Ablauf ergeben der Lesemodul liest den ersten Teil z B ein hundertstel der in der Datei gespeicherten Daten ein schreibt sie in eine Partition und beginnt dann den n chsten Teil zu lesen Der darauffolgende Filtermodul beginnt daraufhin bereits mit der Arbeit und reicht die gefilterte Partition an den Geometriemodul weiter der sofort die Partition f r den letzten Schritt die Darstellung erzeugt W hrend der Lesemodul erst bei der dritten oder vierten Partition ist sieht der Benutzer bereits die Darstellung der ersten Partition dies funktioniert nat rlich nicht so einfach wenn man zum Beispiel eine Partikelverfolgung berechnet Hinzukommt da normalerweise w hrend eine Datei gelesen wird die CPU nur zu einem Bruchteil ausgelastet wird w hrend bei einer partitionierten Verarbeitung diese ungenutzte CPU Zeit bereits von den nachfolgenden Modulen genutzt wird Es findet also zus tzlich zur subjektiven Beschleunigung auch eine objektive statt Noch deutlicher wird diese Beschleunigung wenn es sich um einen einfachen Mehrprozessorrechner handelt zum Beispiel mit vier Prozessoren Bei der nicht partitionierten Ausf hrung ist im wesentli Seite 45 4 Konzept eines verteilten Visualisierungssystems c
82. e Objekte oder die Resultate aus der Anwendung der Algorithmen wie sie bei einer Datenverwaltung vorhanden w re Die einzige M glichkeit eine Visualisierung abzuspeichern besteht darin neben dem urspriingli chen Datensatz eine sogenannte View zu schreiben die s mtliche Parameter die f r diese Visualisierung notwendig sind enth lt Da Ensight als MPGS Multi Purpose Graphics System urspr nglich von Cray Research Inc entwik kelt wurde finden sich viele speziell auf die Nutzung von Supercomputern optimierte Eigenschaften So ist die Cray Server Version beispielsweise vektorisiert und die Kommunikation erfolgt nicht wie bei AVS ber die recht langsamen xdr Funktionen 3 2 bersichtstabelle In der folgenden Tabelle sind die wesentlichen Merkmale die an ein verteiltes Visualisierungssystem gestellt werden f r die Systeme aus Kapitel 2 und Kapitel 3 aufgelistet Die Definition dieser Merkmale lautet dabei Tabelle 3 1 Definition der Vergleichskriterien Objekt Orientierung das System folgt einem objekt orientierten Ansatz im generellen Sinne Klassen es existieren verschiedene Klassen f r die verschiedenen Datentypen Vererbung es gibt eine M glichkeit Klassen abzuleiten Methoden es gibt Methoden die zu den jeweiligen Klassen geh ren Modul es gibt Module die ber wohldefinierte Schnittstellen Daten miteinander ne austauschen eine einfache Art von Objekt Orientierung verschiedene Met
83. e of todays industry and will then be viewed under the aspect of their effect on the visualisation Next the system architecture of the COVISE visualisation system and the systems that influenced its development will be presented COVISE serves as a prototype that is used to implement most of the con cepts presented in this work In addition several widely used visualisation systems will be analysed according to the initially defined requirements for the data management This will be compared to the concept that has been realised in COVISE These concepts will be presented in detail in the following chapter Here the focus is on the distribu ted data management it is described how the data exchange between the modules is realised for the local case as well as for a distributed scenario The advantages of this approach will be explained as well as the necessary mechanisms to assure an unambiguous data access in a distributed system In this context the data objects play a key role The structures that are important for the management of the computational and geometrical data are developed and the corresponding hierarchies are shown With regard to the use of these data objects through the modules the handling and the access mechanisms are described Here also possibilities are discussed to make data objects persistent or to partition them To finalise this chapter it is reflected on some practically oriented thoughts the realisation of this concept
84. ebnisse in Tabelle 5 4 zeigen deutlich da die durchschnittliche Durchsatzrate deutlich ber der des synchronen write liegt Das hei t f r den Benutzer zeigt sich eine sichtbar verbesserte Leistung obwohl sich an der Handhabung f r ihn nichts ge ndert hat Durch die Nutzung des asynchronen write mu der Proze nun nicht mehr darauf warten da die Daten vollst ndig ber das Netzwerk wegge schickt wurden bevor die write Routine wieder zur ckkommt Der maximal erreichbare Durchsatz liegt jedoch in der selben Gr enordnung Die Schwankungen in den Zeiten die zum Einpacken des Seite 80 5 2 Messungen Objektes ben tigt werden sind wiederum eine Folge der Auslastung der C94 An den optimalen Werten 3 ms wird auch das tats chliche Potential dieser Supercomputer deutlich 3 ms zum Einpacken von mehr als 15 MB ergeben einen Durchsatz von etwa 490 MB s Im Vergleich dazu brauchen die Indigo Workstations aus Abschnitt 5 2 1 f r etwa 3 MB mehr als 150 ms was einem Durchsatz von etwa 20 MB s entspricht Hierbei kommen die Vorteile des auf optimalen Memory Durchsatz optimierten Systems zur Geltung Der Netzwerkdurchsatz bleibt jedoch immer noch hinter den Erwartungen zur ck CuttingPlane RB in PEGASE packobj Netzwerk Netto Durchsatz Brutto Durchsatz 1 282 0 059 0 030 1 222 12817 KB s 12219 KB s 1 754 0 003 0 002 1 751 8946 KB s 8931 KB s 1 610 0 003 0 002 1 607 9748 KB s 9729 KB s 3 164 1 657 1 656 1 507 10391
85. egul ren Hexaedergitter den Vorgang einer Wirbelauf l sung Als Anfangsbedingung wird auf diesem Gitter ein Wirbel vorgeschrieben Zur guten Aufl sung des zylindrischen Wirbels in der Mitte der beiden radialen Koordinatenachsen ist das Gitter dort feiner Seite 67 5 Resultate aufgel st als am Rand Mit fortschreitender Berechnung l st dieser Wirbel sich immer mehr auf das hei t seine anfangs klare Struktur franst aus Zur Visualisierung eines solchen Resultates eignet sich am besten eine Isofl che die konstant mit dem Betrag der Geschwindigkeit ist Auf diese Isofl chen lie en sich dann andere Werte wie zum Beispiel die Temperatur oder die Wirbelst rke abbilden mit Hilfe eines sogenannten Colormap Moduls Die bei der numerischen Berechnung anfallenden Datenmengen k nnen sehr gro werden Die Daten die zur Darstellung der Isofl che ben tigt werden sind vom Umfang her in der Regel erheblich geringer so da es sich anbietet die Berechnung der Isofl che noch auf dem Supercomputer auf dem auch die numerische Rechnung l uft vorzunehmen Dies gilt ebenso f r die Abbildung der anderen Daten auf die Isofl che F r den Datenflu ergibt sich das in Abbildung 5 1 dargestellte Bild Aus Gr n den der bersichtlichkeit wurden nur die wesentlichen Komponenten eingezeichnet Supercomputer Workstation PEGASE Isofl che Colormap Renderer 10 On Ome Fa Shared Data Space 6 ono
86. ei der Finite Element Methode die aber im Hinblick auf das Gesamtproblem nur eine untergeordnete Rolle spielen Entsprechend interessiert man sich bei einer Datenbank meist f r einen einzelnen Datensatz oder eine Menge von Datens tzen die ein bestimmtes Merkmal gemeinsam haben Bei einer Visualisierung wird jedoch in der Regel die Informa tion die in einem Datensatz steckt in vergleichsweise aufwendiger Form aufgearbeitet bevor sie darge stellt wird 11 12 13 20 56 Da es sich jedoch sowohl bei der Visualisierung als auch bei den Datenbanken um Felder handelt die au erordentlich weit reichen gibt es durchaus sehr starke Ber hrungspunkte die es sinnvoll erscheinen lassen diese beiden Gebiete st rker miteinander in Verbindung zu bringen als dies bisher der Fall ist Es gibt mehrere Richtungen diese beiden Gebiete st rker miteinander zu verbinden Seite 91 6 Bewertung und Ausblick e zu einer bestehenden Datenbank wird eine Visualisierungsfunktionalit t hinzugef gt die es erm glicht die in dieser Datenbank gespeicherten Daten die oft schon Graphikdaten enthalten Satellitenbilder oder allgemeine Fotos Ergebnisse numerischer Berechnungen direkt darzustel len Dazu kommen Abfragem glichkeiten die versuchen den Inhalt der Bilder abfragbar zu machen siehe hierzu 38 79 und insbesondere 2 e die Komplexit t einer Datenbank oder die Struktur der in ihr gespeicherten Daten wird graphisch sichtbar gemacht Dies
87. eich die Ethernet Paketgr e liegt bei 1 5 KB Nun m ssen nur noch gen gend viele dieser Pakete pro Sekunde verschickt werden um die 800 MBit s zu erreichen Wenn eine Anwendung Daten ber eine Ultranet Verbindung verschicken m chte tut sie das norma lerweise mit den Standardparametern die das Betriebssystem f r jede neue Verbindung einsetzt Ist die Standardpaketgr e zum Beispiel 4 KB gehen bei jedem Datenpaket 28 KB leer ber das Netz und die Leistungsf higkeit dieser Verbindung ist von 800 auf 100 MByte s reduziert Selbst wenn alle anderen Voraussetzungen optimal sind kann diese bertragungsrate nicht berschritten werden Wenn zus tz lich weitere Verluste in der Anwendung auftreten z B werden abwechselnd gro e und kleine Daten mengen verschickt oder das Verschicken der einzelnen Pakete wird durch andere Berechnungen unterbrochen bleibt f r den Benutzer nur noch ein Bruchteil der maximal erreichbaren Leistung brig Seite 53 4 Konzept eines verteilten Visualisierungssystems ohne da er daran etwas ndern k nnte Dieses Verhalten gilt wenn auch in etwas anderer Form ebenso f r HIPPI Verbindungen Bei diesen ist die Aufbauzeit relativ lang der darauffolgende Datenaustausch dann jedoch relativ schnell Auch hier werden somit die besten Ergebnisse bei maximaler Paketgr e erzielt Bei ATM das von Anfang an auf viele kleine Pakete ausgelegt wurde ist dieses Problem jedoch nicht gegeben Ein weiterer Aspekt be
88. eim Request Broker des Originals um die Schreibrechte nachsuchen Dieser wiederum fragt alle anderen Request Broker die eine Kopie halten nach dem Schreibrecht Durch diese Handhabung wird dem blichen Ablauf einer Anwendung in der ein Objekt von einem Modul angelegt und anschlie end von einem oder mehreren anderen Modulen gelesen wird Rechnung getragen Unter diesen Umst nden wird eine optimale Performance erreicht w hrend der wesentlich seltenere Fall da ein bereits existierendes Datenobjekt noch einmal zum Schreiben ge ffnet wird in seiner Performance beeintr chtigt wird 4 2 Die Datenobjekte Module arbeiten mit zwei Arten von Information Steuerinformation und auszutauschende Daten Zu den Steuerinformationen geh ren zun chst einmal der Befehl vom Controller mit der Ausf hrung zu beginnen Die meisten Module haben zus tzlich allerdings auch eine ganze Reihe von Parametern die das Verhalten des Moduls beeinflussen Das k nnen beim Renderer zum Beispiel die Einstellung bez g lich der Stereodarstellung sein oder bei einem Isofl chenmodul der Wert zu dem die Isofl che gerechnet werden soll oder ob Normalen generiert werden sollen All dies sind jedoch Informationen die sich nur auf das Modul selbst und sein Arbeitsweise beziehen und keine anderen Module beeinflussen Alle Informationen die auch andere Module beeinflussen d h die irgendeinen Informationsaus tausch zwischen zwei Modulen betreffen werden ber sogenannte Dat
89. ein m ssen Es ist also nicht m glich ein solches Gitter einfach zu zerteilen bzw zusammenzufassen vielmehr m ssen an den Parti tionsgrenzen gewisse Redundanzen ber cksichtigt werden 4 4 2 Gr nde f r die Partitionierung Es gibt im wesentlichen zwei Gr nde daf r den zus tzlichen Aufwand einer Partitionierung in Kauf zu nehmen entweder die Datenobjekte sind so gro da sie nicht mehr an einem St ck verarbeitet wer den k nnen oder es l t sich durch die Partitionierung eine berlappung der Verarbeitung erreichen die zu einer Verbesserung der Performance f hrt Datenobjektgr e Insbesondere bei der Verwendung von massiv parallelen Rechnern k nnen Datenmengen auftreten die sich nicht mehr direkt auf einer normalen Workstation wie sie bei einem Anwender normalerweise auf dem Schreibtisch steht visualisieren lassen Gerade bei einem massiv parallelen Rechner ist das Datenobjekt durch die Verteilung auf mehrere Prozessoren partitioniert so da sich eine Weiterverarbei tung dieses Datenobjektes als partitioniertes Datenobjekt anbietet Unabh ngig davon ob sich die Weiterverarbeitung noch auf dem Parallelrechner oder auf der Work station des Benutzers abspielt ist die Beibehaltung der Partitionierung die sinnvollste Methode Findet die Weiterverarbeitung auf dem Parallelrechner statt ist dadurch da die Daten auf dem Prozessor auf dem sie auch erzeugt worden sind bearbeitet werden eine nat rliche Verteilung der A
90. eitere Besonderheit der Cray Vektor Supercomputer ist das Fehlen von Shared Memory Dadurch wurde es n tig f r die Kommunikation zwischen mehreren Prozessen die auf einer Cray lau fen einen anderen Mechanismus zu finden Da es keine der Effizienz von Shared Memory vergleichbare M glichkeit gibt wurden Modul Code und Request Broker Code in ein Executable integriert Der Shared Data Space wird als lokaler Speicher vom Heap allokiert und kann von beiden Seiten des Codes zugegriffen werden Gegen ber dem restlichen System erscheint dieses gemeinsame Executable wie ein kompletter Rechner mit einem Request Broker und genau einem Modul Alle Verbindungen zum Con troller und zu den anderen Request Brokern bestehen analog zu einer Shared Memory f higen Umge bung siehe Abbildung 4 8 Die gesamten Abl ufe der Kommunikation zwischen Controller und Modul Modul und Request Bro ker und zwischen Request Brokern sind identisch zu denen auf einer Shared Memory Maschine Ein Overhead der sich nicht vermeiden l t ist die Replizierung von Datenobjekten auf demselben Rechner wenn mehrere Module auf dem Supercomputer laufen Dies hat den zus tzlichen Nachteil da gerade hier mit gro en Datenmengen gearbeitet wird F r die Zukunft ist jedoch auch in diesem Bereich Besse rung in Sicht da auch die leistungsst rksten Supercomputer zunehmend mit Shared Memory Funktiona lit t ausgestattet werden z B die NEC SX4 Der Stellenwert der dieser Funktional
91. ekt passende Zugriffsdatenobjekt von der Basisklasse Dis tributedObject abzuleiten sind im wesentlichen zwei Schritte n tig zuerst mu f r jedes Daten element des Objektes ein dazu passendes von der Klasse ShmIt em abgeleitetes Zugriffsdatenelement in die neue Klasse aufgenommen werden Der Datenbereich der Klasse f r ein strukturiertes nicht recht winkliges Gitter sieht folgenderma en aus class DO_StructuredGrid public DistributedObject IntShm x disc Anzahl der Punkte in X Richtung X IntShm y_disc Anzahl der Punkte in Y Richtung Y int Shim z disc Anzahl der Punkte in Z Richtung Z FloatShmArray x_coord X Koordinaten L nge X Y Z FloatShmArray y_coord Y Koordinaten L nge X Y Z FloatShmArray z_coord Z Koordinaten L nge X Y Z Der zweite Schritt besteht darin auf f r den Programmierer m glichst einfache Weise das Zugriffs datenobjekt auf die dazugeh rigen Elemente des Datenobjektes im Shared Data Space zu initialisieren Dazu sind zwei Informationen wichtig wo das Objekt im Shared Data Space liegt und aus welchen Datenelementen es besteht Seite 60 4 6 Wesentliche Strategien der Implementierung Die Lage des Datenobjektes im Shared Data Space erf hrt das Zugriffsdatenobjekt ber eine Anfrage beim Request Broker Wenn das Datenobjekt bereits existiert so mu nur der Name an den Request Bro ker geschickt werden Dieser schickt dann die Adresse als Tup
92. el Nummer des Shared Data Space Seg mentes Offset in dieses Segment Dazu gibt es in der Klasse Do_St ructuredGrida den Konstruktor DO_StructuredGrid char name DistributedObject name STRGRD Das zweite Argument im Aufruf des Konstruktors fiir die Basisklasse ist hierbei ein sechsbuchstabi ges K rzel f r den Datentyp das der Programmierer festlegt Existiert das Datenobjekt noch nicht im Shared Data Space so mu au er dem Namen noch die Information ber die Gr e der Felder als Argument bergeben werden Dazu dient der Konstruktor DO_StructuredGrid char name int x int y int z DistributedObject name STRGRD Weitere Konstruktoren k nnen verwendet werden um zum Beispiel weitere Initialisierungen vorzu nehmen oder bereits existierende Gitterdaten gleich mit bergeben zu k nnen und diese im Konstruktor sofort in den Shared Data Space zu schreiben Zum Beispiel bergibt man diesem Konstruktor in den Variablen xv yv und zv die Koordinaten f r das Gitter sie werden dann gleich in die entsprechenden Felder im Shared Data Space kopiert DO_StructuredGrid char name int x int y int z float xv float yv float zv DistributedObject name STRGRD Die Datenelemente aus denen das Datenobjekt aufgebaut ist mu der Programmierer in irgendeiner Form kodieren Damit nicht f r jeden Konstruktor dieselbe Liste kodiert werden mu und der Program mierer auch nicht f r jede abgeleitete Klasse den Code zur I
93. en durch die gro artige Zusammenarbeit mit der Entwicklergruppe in der Abteilung Visualisierung des RUS Besonders hervorzuheben ist Herr Dr Ulrich Lang der von Anfang an in ausf hrlichen Gespr chen und vielen Diskussionen als Sparringspartner wesentlich dazu beitrug da die Arbeit ihren heuti gen Stand erreicht hat Die Arbeit der Kern Gruppe der COVISE Entwickler Ruth Lang Harald Nebel Daniela Rainer Dirk Rantzau Andreas Werner und Uwe W ssner erm glichte dann die Ergebnisse dieser Arbeit in einer anwendungsnahen Weise verifizieren zu k nnen Ferner gilt mein Dank allen Kolleginnen und Kollegen des RUS sowie den Mitarbeitern der Firma Cray Research die mich insbesondere bei der Durchf hrung der Messungen und den sich daraus erge benden Optimierungen unterst tzt haben Schlie lich bedanke ich mich bei meinen Eltern ohne deren Unterst tzung mein Ausbildungsweg und diese Arbeit nicht m glich gewesen w ren Warmbronn im Dezember 1999 Andreas Wierse Seite V Seite VI Zusammenfassung Visualisierungssysteme die mit den gro en Datenmengen arbeiten die heute bei numerischen Simu lationen anfallen m ssen mit diesen Daten effizient umgehen k nnen In dieser Arbeit werden die Anforderungen untersucht die an die Datenverwaltung eines solchen Visualisierungssystems gestellt werden das f r die Darstellung der Ergebnisse komplexer numerischer Berechnungen n tig ist Dazu werden diese Anforderungen anhand eines heute i
94. en Me ergebnisse im dritten Durchlauf sind durch ein reproduzierbares Swappen auf der Workstation verursacht worden Seite 84 5 2 Messungen Genauere Untersuchungen des reinen FDDI Transfers zwischen einer SGI Indigo und der C94 erga ben im brigen da der im Vergleich zu einer Indigo Indigo Verbindung niedrigere Nettodurchsatz auf die C94 zur ckzuf hren ist sie ist einfach nicht in der Lage mehr Pakete zu verschicken wohingegen die Indigo mehr Pakete empfangen K nnte Tracer lokaler RB else ee Bes hod Konversion Netzwerk en Sn 4 836 4 827 3 181 0 140 0 128 3 041 7728 KB s 4859 KB s 7 603 1 223 3 959 0 480 0 128 3 479 6755 KB s 3091 KB s 21 401 21 385 10 379 0 141 0 129 10 238 2295 KB s 1098 KB s 4 428 4 418 3 154 0 142 0 130 3 012 7802 KB s 5307 KB s 4 215 4 202 3 043 0 141 0 129 2 902 8098 KB s 5575 KB s 3 950 3 936 2 958 0 141 0 129 2 817 8342 KB s 5949 KB s 3 995 3 985 3 005 0 141 0 129 2 864 8205 KB s 5882 KB s 3 898 3 886 2 913 0 140 0 128 2 773 8474 KB s 6028 KB s Tabelle 5 9 C94 zu Indigo FDDI gro er Datensatz leere C94 ay EOE T T T T Be en _ So o GE 0 2 4 6 Zeit in Sekunden 8 B komm Tr RB MRB in PEGASE O Konversion DO Komm RB RB MAuspacken Abbildung 5 12 Graphik der MeBergebnisse aus Tabelle 5 9 In Abbildung 5 12 ist eine graphische
95. en Modulprogrammierer Obwohl die bislang beschriebenen Mechanismen f r den Zugriff auf die Datenobjekte im Shared Data Space relativ komplex sind gestaltet sich der Zugriff f r den Modulprogrammierer sehr einfach Dazu implementiert der Programmierer der Zugriffsobjektklassen eine Reihe von Methoden die das Gew nschte liefern Um an die Gittergr en eines strukturierten Gitters zu gelangen mu der Modulpro grammierer nur die Methode get_grid_size aufrufen void get_grid_size int x int y int z xx x_disc ay Sy disc xz z_disc Bemerkenswert ist hierbei da es sich bei den Variablen x_disc y_disc und z_disc nicht um einfache Integer handelt sondern vielmehr um Objekte des Typs Intshm Diese Klassen sind so imple mentiert da sie benutzt werden k nnen wie ganz gew hnliche Integer das hei t sie k nnen wie oben zugewiesen werden aber auch auf der linken Seite einer solchen Zuweisung stehen Analog dazu ist der Klammeroperator f r die ShmArray Klassen berladen worden so da auch hier Zuweisungen in der gewohnten Weise erfolgen k nnen Zum schnellen Zugriff auf die Felder eines strukturierten Gitters gibt es noch die Methode get_addresses void get_addresses float x_c float y_c float z_c x_c float x_coord get_data_ptr y_c float y_coord get_data_ptr z_c float z_coord get_data_ptr Die Methode get_data_ptr gibt f r eine beliebiges von der Klasse ShmArray abgelei
96. en zu verringern und ihre Einf hrung zu beschleunigen Dazu wurde eine Rahmenarchitektur mit detaillierten unterst tzenden Schnittstellenspezifikationen geschaffen 46 Der in 46 verwendete Begriff Objektsystem wird folgenderma en definiert eine Ansammlung von Objekten die die Nachfrager von Services Klienten Clients von den Anbietern der Services durch eine wohl definierte kapselnde Schnittstelle isolieren Genauer gesagt werden Clients von der Implementie rung von Services im Hinblick auf Datenrepr sentation und ausf hrbaren Code isoliert Die Idee die hinter diesem Konzept steht besteht in einer v lligen Trennung von der anfordernden Einheit und der ausf hrenden Einheit Die Schnittstelle zwischen diesen beiden Einheiten wird detailliert definiert so da eine saubere Trennung sichergestellt ist Zun chst die Definition einiger Begriffe in CORBA e Objekte ein Objekt ist eine identifizierbare gekapselte Einheit die einen oder mehrere Dienste zur Verf gung stellt die von einem Client angefordert werden e Anfragen Clients fordern einen Dienst mittels einer Anfrage an Eine Anfrage ist ein Ereignis d h etwas was zu einem gewissen Zeitpunkt passiert Die Information die zu so einer Anfrage geh rt besteht aus einer Operation oder Methode einem Teilobjekt null oder mehr Parametern und optional einem Anfrage Kontext e Objektimplementierung die Implementierung eines Objektes f hrt die Berechnungsaktivit ten durch
97. end zu visualisieren e das vom DFN Verein finanzierte Projekt VRS Lab mit dem Max Planck Institut f r Biokybernetik und dem Institut f r Theoretische Astrophysik in T bingen TAT wird eine verteilte Umgebung f r eine kollaborative Visualisierung mittels Tech niken der virtuellen Realit t entwickelt e das BMBF gef rderte Projekt EFENDA in der deutschen Luft und Raumfahrtindustrie wird COVISE als Werkzeug f r die Integration von Numerik und Visualisierung in einer verteilten und kollaborativen Umgebung etabliert e das G7 Referenzprojekt SPOCK Seite 73 5 Resultate das Szenario einer verteilten Umgebung wird hierbei auf den experimentellen Bereich ausgewei tet die Ergebnisse von Windkanalversuchen und Freiflugexperimenten werden ber Module in die COVISE Umgebung eingebracht und gemeinsam visualisiert e das ESPRIT Projekt COVAS die Funktionalit t von COVISE wird den Bed rfnissen der Automobilindustrie angepa t und mit einem regionalen und einem internationalen Partner in Hinblick auf seine Effizienz im Industrie alltag hin untersucht das ESPRIT Projekt VISiT COVISE wird als Integrationsplattform eingesetzt um den gesamten Zyklus von der Gittergene rierung ber die Berechnung bis hin zur Analyse der Ergebnisse aus einer einzigen VR Umge bung heraus handhabbar zu machen In allen diesen Projekten kommt die in dieser Arbeit dargestellte Datenverwaltung zur Anwendung Dabei werden in den verschiedenen Projekten
98. enobjekte ausgetauscht Diese Datenobjekte liegen im Shared Data Space siehe 4 1 1 und werden vom Request Broker verwaltet Der Zugriff von Modulen auf diese Datenobjekte erfolgt immer lokal normalerweise ber Shared Memory Sollte kein Shared Memory auf dem benutzten Rechner verf gbar sein d h nicht implementiert werden jeweils ein Modul und ein Request Broker in einem Executable integriert und der Shared Data Space liegt auf dem Heap 4 2 1 Anforderungen an die Speicherung der Datenobjekte Die Speicherung der Datenobjekte im Shared Data Space mu die folgenden beiden Zugriffsarten erm glichen e ein Modul m chte die Daten in diesem Datenobjekt schreiben oder lesen e ein Request Broker m chte ein Datenobjekt zum Request Broker auf einem anderen Rechner sen den Aus diesen Zugriffsarten ergeben sich folgende Bedingungen f r die Speicherung e F r einen effizienten Zugriff auf die Daten mu ein Modul direkt auf den Daten arbeiten k nnen Da ein Modul unter Umst nden sehr h ufig auf die Daten zugreift z B wird bei einem Marching Cubes Algorithmus das komplette Gitter durchlaufen und dabei auf dieselben Gitterpunkte mehr fach zugegriffen m ssen die Zugriffe direkt m glich sein e Die Speicherung mu die volle semantische Information enthalten Seite 34 4 2 Die Datenobjekte Zun chst erscheint es ausreichend da zur Speicherung der Objekte eine Gr eninformation gegeben wird die es erm glicht dem Objekt e
99. enobjektes kennt falls n tig mu er sogar Datenkonvertierung vorneh men also Information ber die verwendeten Datentypen haben Wenn ein Modul nun auf ein Datenob jekt zugreift kann man zun chst einmal davon ausgehen da er die Struktur des Datenobjektes bereits kennt sonst w te er ja nicht was er damit anfangen soll Dennoch kann die Strukturierung der Daten objekte im Shared Data Space eine gute Hilfe dabei sein festzustellen ob auch wirklich ein konsistentes Datenobjekt im Speicher liegt Siehe dazu auch 29 und 42 In Abbildung 4 11 sind die bei einem Zugriff auf ein Datenobjekt im Shared Data Space aktiven Komponenten zu sehen Mit Datenobjekt wird im weiteren eine Gruppe von Speicherstellen im Shared Data Space bezeichnet in denen die eigentlichen Daten abgespeichert sind Dazu z hlen auch die Spei cherstellen auf die mit Zeigern aus diesem Objekt heraus verwiesen wird obwohl diese aus bersicht lichkeitsgr nden in dieser Abbildung nicht mit einer Schraffur hinterlegt sind diese Felder k nnen auch weit entfernt vom Datenobjekt im Shared Data Space liegen auch in einem anderen Segment Als Datenelement wird ein Teil des Objektes der einem Basisdatentyp wie Integer float Zeiger oder Feld entspricht bezeichnet Dazu geh ren eine Typ Identifizierung und das Datum selbst also in dieser Abbildung int 4 Ein Zeiger Datenelement enth lt eine Typ Identifizierung f r den Zeigertyp eine Shared Data Space Segment Numm
100. entlichen entwickelt 1989 von Craig Upson und seiner Gruppe bei Stellar 71 ist es auch das ausgereifteste und verbreitetste Inzwischen in der Version 5 verf gbar hat es einen sehr hohen Entwicklungsstand erreicht und auch zahlreiche Verbesserungen erfahren Die wesent liche Architektur hat sich seit Version 4 nicht mehr ver ndert 5 6 Parallel zu dieser Visualisierungs software gibt es die Neuentwicklung AVS Express die sich im Kern deutlich von AVS 5 unterscheidet Die Architektur von AVS Express wird in Kapitel 3 1 2 vorgestellt Local Workstation Remote Workstation f tH Shared Memory Shared Memory Abbildung 3 1 Die Kommunikation von AVS Seite 18 3 1 Visualisierungssoftware In Abbildung 3 1 ist die Systemarchitektur von AVS in einer verteilten Umgebung dargestellt Die zentrale Steuerung des Ablaufs wird von einem sogenannten Flow Executive FE tibernommen Dieser hat direkten Kontakt zu jedem Modul A bis E und zur Benutzungsschnittstelle UI Dort wird die Information tiber die Topologie des Netzwerkes gehalten d h welche Modul Ausgabeports mit welchen Modul Eingabeports verbunden sind Dies impliziert natiirlich auch die Reihenfolge in der die Module auszuf hren sind Der Flow Executive berwacht auch den Datenflu d h welche Daten wohin zu schicken sind und ber welche Kan le dies zu erfolgen hat Die Parameter die von
101. er Speicher reserviert und die Adresse dieses Speicherbereiches zur ck geschickt wurde automatisch das Schreibrecht zugeteilt Nachdem das Modul seine Arbeit verrichtet hat egal ob lesend oder schreibend gibt er seine Schreib oder Leserechte an dem Datenobjekt zur ck siehe dazu Kapitel 4 6 Wesentliche Strategien der Implementierung Des weiteren gelten einige bewu t einfach gehaltene Regeln f r den gleichzeitigen Zugriff e solange ein Datenobjekt geschrieben wird kann es nicht gelesen werden e solange ein Datenobjekt gelesen wird kann es nicht geschrieben werden e die Zahl der gleichzeitig auf ein Datenobjekt schreibenden Module ist auf eins beschr nkt e es k nnen beliebig viele Module gleichzeitig lesen Theoretisch kann es trotz dieser Regeln durchaus zu einem sogenannten Deadlock kommen ein Modul A ben tigt bevor es seine Ausgabedaten schreiben kann ein Eingabedatenobjekt das wie derum von einem anderen Modul B geschrieben werden soll das auf die Ausgabedaten des ersten Module wartet siehe Abbildung 4 4 In der Praxis kann diese Konstellation jedoch nicht vorkommen da eine solche Verbindung beim Aufbau einer Anwendung mittels des visuellen Programmierens einfach nicht zugelassen wird Weiterhin handelt es sich durch die Serialisierung der Aktionen im Controller quasi um eine Ein Benutzeranwendung d h es kann nicht vorkommen da mehrere Benutzer unkon trolliert auf dieselben Daten schreibend zugreifen
102. er und den Offset in dieses Segment Vor den eigentlichen Daten ste hen eine Reihe von sogenannten Headerinformationen f r dieses Datenobjekt dazu geh ren der Typ die Anzahl der Datenelemente die Versionsnummer ein Referenzz hler die Objekt Id ein Zeiger auf den Objektnamen und ein Zeiger auf die Attributliste Dieser Header ist bei allen Datenobjekten im Shared Data Space gleich Das Zugriffsdatenobjekt F r den Zugriff auf die Daten im Shared Data Space benutzt der Anwendungsmodul ein Zugriffsda tenobjekt Dabei handelt es sich um ein ganz normales C Datenobjekt Ein Teil dieses Objektes besteht aus den Standard C Datentypen und enth lt zum Beispiel eine Kopie der Versions und Typ nummer des Datenobjektes Der andere Teil des Zugriffsdatenobjekts besteht aus Zugriffselementen Jedes dieser Zugriffselemente ist einem Datenelement im Shared Data Space zugeordnet und zeigt direkt auf die Speicherstelle an der die f r die Anwendung relevanten Daten stehen Im Fall der Variablen y_disk zeigt der Zeiger direkt auf die 4 im Fall des Feldes z_koord direkt auf das erste Element des Datenfeldes im Shared Data Space Da jeder Datentyp aus einer Reihe von Basisdatentypen zusammengesetzt ist siehe dazu die Aufz h lung in Abschnitt 4 2 2 Hierarchie der Datentypen auf Seite 35 steht dem Modulprogrammierer f r jeden dieser Basisdatentypen eine Klasse zur Verf gung die den Zugriff auf ein Element dieses Typs im Seite 57 4 Konzept ein
103. erik Auftrag in eine Queue ein die dann zu gegebener Zeit abgearbei tet wird Durch das Vorhandensein mehrerer Queues werden die Bed rfnisse verschiedener Benutzer abgedeckt kleine kurz laufende oder gro e lang laufende Simulationen und eine CPU m ig optimale Auslastung der Supercomputer sichergestellt Allerdings sollte man durchaus dar ber nachdenken ob nicht eine Phase in der die Benutzer interak tiv eine Reihe von Vorberechnungen durchaus auch mit gr eren Problemen durchf hren effizienter ist als eine Menge vergleichsweise unkontrollierter Batch Berechnungen Die interaktive Arbeitsweise erm glicht n mlich in vielen F llen fr hzeitig zu erkennen ob eine Simulation zu den gew nschten Ergebnissen f hrt oder nicht In diesen F llen k nnte der Benutzer dann sofort reagieren und eine neue Ausf hrung mit besseren Parametern starten Dies spart nicht nur Rechenzeit ein sondern erlaubt dem Benutzer auch eine deutlich effizientere Optimierung seiner Berechnungen Insbesondere bei der Ent wicklung von Produkten in der Industrie die ja in der Regel unter einem von den Mitbewerbern erzeug ten Zeitdruck erfolgt kann der Zeitvorteil wesentlich zu k rzeren Produktzyklen und damit gr erer Wettbewerbsf higkeit f hren Eine M glichkeit die in diesen Messungen aufgetretenen lastbedingten Verz gerungen zu reduzie ren best nde zum Beispiel darin f r bestimmte Zeiten einen Proze auf einer CPU fest zu verankern Seite 88
104. ertierungsroutinen und die Routinen f r die Daten bertragung bereit Bei jedem Aufruf wird dabei erneut die komplette Abfolge von Verbindungsaufbau Datentransfer Prozedur Datenr cktransfer und Verbindungsabbau durchlau fen F r die Visualisierung der Mehrk rpersysteme werden zwei Visualisierungsmodule verwendet f r die Erstellung der Geometrie GEOEDIT der aus parametrisierten Formen die Punkt Verbindungs und Normalenvektoren berechnet die f r die Darstellung und Beleuchtung n tig sind F r die leistungsf hige online und offline Visualisierung steht MBSVIS zur Verf gung Dieser Modul ist auch in der Lage Kraftelemente darzustellen die w hrend der Visualisierung ihre Geometrie ver ndern wie z B Federn oder D mpfer Eine genaue Beschreibung von MBSVIS findet sich in 25 RSYST und COVISE Der wesentliche Unterschied zwischen RSYST und COVISE besteht darin da RSYST als Software system f r wissenschaftliche Anwendungen entwickelt worden ist dem die Visualisierung sp ter als Modul hinzugef gt wurde COVISE ist dagegen als verteiltes Visualisierungssystem konzipiert worden dem eine gewisse Funktionalit t f r den Umgang mit den dabei verwendeten Daten mitgegeben wurde hierbei sind viele Erfahrungen die im Laufe der RSYST Entwicklung gemacht wurden eingeflossen 37 Dementsprechend liegen auch die St rken von RSYST bei der Datenbasis die von COVISE in der Visualisierungsorientierung und der Verteilung 2 5 GRAP
105. erung seiner Puffer Head of Line Blocking Selbst eine direkte Low Level Messung ergab nicht mehr als 4MB s f r diese Verbindung Hinzukommt da die Y MP nur sehr knapp mit Hauptspeicher ausgestattet ist Dadurch werden Prozesse die warten was der das Datenobjekt anfordernde CuttingPlane Modul tut sehr schnell aus dem Hauptspeicher in den Swapbereich ausgelagert Das Wiedereinlagern dauert dann unter Umst nden sehr lange daher die ber 70 Sekunden im zweiten Durchgang Diese Probleme sind inzwischen durch Umkonfiguration gel st worden Die sehr geringen Unterschiede zwischen der zwei ten und dritten Spalte belegen auch den minimalen Overhead den das Suchen des Datenobjektes in den Datenstrukturen des Request Brokers mit sich bringt HIPPI Verbindung F r diese Messungen gelten die gleichen Me punkte wie im Fall der FDDI Verbindung Die im Ver gleich h heren Zeiten f r die im Request Broker verbrachte Zeit ist auf die zum Zeitpunkt der Messun gen h here Auslastung der C94 zur ckzuf hren es handelte sich bei diesen Messungen um exakt den gleichen Datensatz Der gr te Teil der Zeit wird immer noch im Netzwerk verbracht Selbst der Netto Durchsatz ist weit von den theoretisch m glichen 100 MB s entfernt Die zu diesem Zeitpunkt geringere Auslastung der Y MP f hrt dazu da nun direkt der durch das Scheduling der C94 bedingte Zeitverlust sichtbar ist Zwischen der Beendigung der Arbeit des PEGASE Moduls und der Anforderung des Da
106. es verteilten Visualisierungssystems Shared Data Space handhabt Diese werden im weiteren Zugriffselemente genannt Alle diese Zugriffs elementklassen sind von der Basisklasse ShmItem abgeleitet die alle Daten die f r einen Zugriff n tig sind enth lt class ShmItem protected int shm_seq_no laufende Nummer des Shared Data Space Segments int offset Offset in dieses Segment int type Datentyp des Elements vord per direkter Zeiger auf die Daten public ShmItem shm_seq_no 0 offset 0 type NONE int get_shm_seq_no return shm_seq_no int get_offset return offset int get_type return type void get_ptr return ptr Anwendungsmodul Zugriffsdatenobjekt Objekt Versions Typ ae Zugriffselement zeiger nummer nummer er Sy Variable Variable Variable Feld Feld Feld x_disk y_disk z_disk x_koord y_koord z_koord typ l nge daten typ ee zgr int 4 int 4 int 4 zer zgr zgr typ lange daten Abbildung 4 11 Zugriff auf den Shared Data Space Von dieser Basisklasse sind die Klassen fiir den Zugriff auf einzelne Elemente oder Felder abgeleitet die wiederum fiir die einzelnen Datentypen character short integer long float und double speziali sierte Unterklassen haben sowie die Klassen zum Verwalten von Feldern von Zeigern und Feldern von Zeichenketten siehe
107. eu sah es 29 Deadlock Sit ON saat ea EEE ET ERE ERSA 32 Zugriff auf den Shared Data Space aan ansehe 37 Partitionierung eines 9 x 9 strukturierten Gitters eeeeseeeseeeeeeseeererersrese 48 Uneindeutigkeiten bei Marching Cubes 20 0 0 eee eeeeeseceeneceseeeeeeeeeeeeaeeeaeens 50 Modul Request Broker auf einem Supercomputer ccceeeseeceeeneeeeeeees 53 Ausschnitt aus der Klassenhierarchie uusessseenennnesnnennennneennennnn 56 Die Klassen des Request Brokers en ae 56 Zugriff auf den Shared Data Space 2 2 2222 22a EIER 58 Klassenhierarchie der Zugriffselemente 0 ceceeesecceeseeceeneeeeeeeeeceeneeeesaes 59 Der Datenflu bei der Darstellung der PEGASE Ergebnisse 68 Bildschirmabzug des Motordatensatzes in der COVISE Umgebung 69 Leistungsf higkeit von Rechnern und Netzwerk uu nnuersnessneesnneennennnnen 69 Verteilung der Module und Daten un 22 2 70 Datenobjekt Anzeige der Partikelbahn uer244rs024snBeeennennnnennnen en 12 Str mung im Saugrohr einer Wasserturbine seeeeeeeeeeeeeeeereereesrreeresrersreeess 73 Seite XIII Abbildung 5 7 Abbildung 5 8 Abbildung 5 9 Abbildung 5 10 Abbildung 5 11 Abbildung 5 12 Abbildung 5 13 Umgeb ng f r die Messungen sales 14 MeBpunkte der Konfiguration Indigo Indigo eseeeseeeseeeeeereeeersererrsrresreesee 76 Graphik der MeBergebnisse aus Tabelle 5 1 22u02220022402
108. f die zunehmende Verbreitung schneller Netzwerke auch f r den nicht lokalen Zugriff werden Techniken mit dieser Geschwindigkeit f r einen immer gr er werdenden Benutzerkreis interessant Allerdings zeigen die Ergebnisse sehr deutlich das gro e Ungleichgewicht zwischen Netzwerkleistung und Leistung der C94 Der im Ver gleich lange Aufenthalt im PEGASE Request Broker des ersten Durchlaufs ist wieder auf die Last der C94 zur ckzuf hren Der Unterschied im Netzwerkdurchsatz ist ebenfalls auf das Scheduling Verhalten Tracer lokaler warten im RB in ouaregn Ne Netto Brutto RB lokalen RB PEGASE Durchsatz Durchsatz 10 1 9 2 8 3 7 4 6 5 8 3 7 4 Gr e Gr e Netzwerk Tracer 13 888 13 878 13 459 1 814 0 019 11 645 276 KB s 231 KB s 7 901 1 888 7 656 0 034 0 018 7 622 422 KB s 407 KB s 14 668 14 652 14 426 0 029 0 020 14 397 223 KB s 219 KB s Tabelle 5 6 C94 zu Indigo Ethernet kleiner Datensatz der C94 zur ckzuf hren sein Die etwa 400 KB s werden jedoch auch von anderen Anwendungen nicht deutlich tiberschritten Der in diesem Ubertragungsweg liegende stark belastete CISCO Router ist dafiir verantwortlich FDDI Messungen Bei den FDDI Messungen geht die Verbindung direkt vom FDDI Interface der Workstation zum FDDI Interface der C94 Einziges Zwischenglied ist der bereits fr her erw hnte Gigaswitch der den logischen FDDI Ring in zwei physikalische Ringe teilt jedoch nur mini
109. face der Y MP und der Workstation maximal knapp ber 5 MB s Beim Bruttodurchsatz verh lt es sich hnlich statt bis zu 5 7 MB s sind es hier nur maximal 3 9 MB s Da jedoch sowohl das HIPPI Interface der Y MP als auch das FDDI Interface der Workstation zu einer wesentlich h heren Datenrate in der Lage sind ist der Grund f r die geringere Leistung beim NSC DXE HI Router von HIPPI auf FDDI zu suchen Tracer lokaler RB ve RB in Read Konversion Netzwerk sn ee 0 892 0 860 0 615 0 059 0 058 0 556 5724 KB s 3567 KB s 0 800 0 793 0 653 0 058 0 057 0 595 5348 KB s 3978 KB s 0 730 0 722 0 569 0 071 0 071 0 498 6390 KB s 4359 KB s 24 395 24 385 24 247 23 744 23 744 0 503 6327 KB s 130 KB s 8 172 8 165 8 028 7 259 7 258 0 769 4138 KB s 389 KB s 13 552 13 544 13 403 12 810 12 809 0 593 5366 KB s 234 KB s 0 702 0 694 0 557 0 060 0 059 0 497 6403 KB s 4533 KB s 0 808 0 801 0 633 0 058 0 058 0 575 5534 KB s 3938 KB s Tabelle 5 11 Y MP zu Indigo HIPPI nach FDDI leere Y MP Um auch den letzten Einflu der Auslastung der Y MP auf die MeBergebnisse auszuschlie en wur den diese Messungen noch einmal w hrend der Wartungszeit also auf leerer Maschine ohne NFS Daemons wiederholt Die Ergebnisse in Tabelle 5 11 best tigten jedoch im wesentlichen die Ergebnisse der drei schnellen Messungen auf der normal belasteten Y MP Immerhin steigt der Nettodurchsatz im Schnitt um etwa 1 MB s das hei
110. genden Daten ausf hrt anstatt die Daten erst zu reduzieren und dann auf die Workstation zu bertra gen In Abh ngigkeit von dem f r die Berechnung der Isofl che benutzten Wert reduziert sich die Menge an Daten die ber das Netz transportiert werden m ssen erheblich Speziell an diesem Beispiel wird jedoch auch ein grundlegendes Problem bei der optimalen Vertei lung interaktiver Visualisierung deutlich Die Menge an Daten die nach der Berechnung der Isofl che ber das Netz geschickt werden mu h ngt direkt vom interaktiv eingestellten Isowert ab Das hei t je nachdem f r welchen Isowert der Benutzer sich entscheidet k nnen entweder wenige oder gar keine Daten anfallen oder aber fallspezifisch Datenmengen die in der Gr enordnung des urspr nglichen Datensatzes liegen Es gibt also keine einfachen Regeln um den f r die Verteilung der Daten ber das Netz optimalen Punkt in der Visualisierungspipeline zu bestimmen Dies macht es auch schwierig bis unm glich die Verteilung sinnvoll zu automatisieren 1 2 Zielsetzung der Arbeit In dieser Arbeit wird ein Konzept pr sentiert das eine L sungsm glichkeit f r die in Kapitel 1 1 auf gezeigten Probleme darstellt Da der Kern der in diesem Kapitel beschriebenen Probleme mit der Hand habung der Daten verkn pft ist erscheint es sinnvoll die Gebiete Visualisierung und Datenverwaltung zu integrieren Die Datenmanipulationsm glichkeiten die eine Datenverwaltung bietet sollen mit
111. gepr gt haben das Datenbanksystem RSYST und die objekt orientierte Visualisierungssoftware GRAPE 2 1 COVISE Der Gegenstand dieser Arbeit die Integration von Visualisierung und Datenverwaltung wird als Kern in der Visualisierungsumgebung COVISE eingesetzt bzw ist zusammen mit ihr entwickelt wor den COVISE ist eine Abk rzung f r COllaborative VIsualization and Simulation Environment COVISE wurde seit 1993 zun chst im Rahmen der EU Projekte PAGEIN RACE II Nr 2031 und ADONNIS ESPRIT Nr 9309 entwickelt und wird heute im Rahmen zahlreicher Projekte weiter aus gebaut Diese Visualisierungsumgebung bietet auf der einen Seite eine ideale Plattform um die Ergeb nisse dieser Arbeit zu tiberpriifen auf der anderen Seite kommen aus dieser Konstellation zahlreiche neue Impulse die die Weiterentwicklung entscheidend beeinflussen Insbesondere diente COVISE bei den Messungen in Kapitel 5 als Anwendungsumgebung 2 2 Die Systemarchitektur COVISE ist eine Gemeinschaftsentwicklung mehrerer Mitarbeiter des Rechenzentrums der Universi t t Stuttgart Dabei wird die Entwicklung in mehreren relativ unabh ngigen Bereichen parallel betrieben e zentrale Ablaufsteuerung Controller e Benutzungsschnittstelle Userinterface e Graphikdarstellung in einer Fensterumgebung OpenInventor basierter Renderer e Graphikdarstellung in einer Virtual Reality Umgebung Performer basierter Renderer e Visualisierungsfunktionalit t Module e Datenver
112. ger Short Float etc in sogenannten Modulen zusammensetzen kann F r jedes dieser Grund elemente l t sich dann einstellen ob es als Ein oder Ausgabeport von au en erreichbar sein soll Aus Modulen k nnen wiederum weitere Module zusammengesetzt werden so da sich eine ganze Hierarchie von gekapselten Objekten erstellen l t von der f r den Benutzer nur das sichtbar ist was tats chlich ben tigt wird um die gew nschte Funktionalit t zu erhalten So flexibel und konsequent dieses objekt orientierte Konzept realisiert ist so fehlt doch in der momentan vorliegenden Version 2 0 die M glichkeit die Ausf hrung von Methoden auf verschiedene Rechner zu verteilen v llig Zwar spricht nichts dagegen da ein Programmierer Module schreibt die die Kommunikation mit anderen Rechnern selbst vornehmen allerdings gehen dabei alle Vorteile des AVS Express Konzeptes verloren Diese Tatsache ist nat rlich auch der Firma AVS nicht verborgen geblieben insbesondere da ja auf AVS Express die zuk nftigen AVS Versionen aufsetzen sollen Aus diesem Grund ist das Projekt MP Express initiiert worden In diesem Projekt sollte AVS Express so verbessert werden da es m glich wird verteilte Visualisie rungssoftware zu erstellen siehe dazu 43 Hauptzielrechner hierf r sollten Workstation Cluster sym metrische Multi Prozessor Systeme und Massiv Parallele Rechner sein Aus den bisher vorliegenden Unterlagen ist allerdings nicht erkennbar wie die
113. h konstant so da bei kleineren Datenobjekten die Auswirkungen gr er sein werden bei gr e ren dagegen geringer Seite 78 5 2 Messungen 5 2 2 Messungen zwischen den beiden Cray Vektor Supercomputem Da die beiden Cray Rechner nicht ber Shared Memory verf gen liegen die Me punkte bei diesen Messungen etwas anders als bei den reinen Workstation Messungen Bei dem das Datenobjekt das in diesem Fall eine Gr e von 15 667 376 Bytes hat anfordernden Modul handelt es sich um einen Cut tingplane Modul der mit seinem Request Broker in ein einziges Executable integriert ist Dadurch steht anstelle der Kommunikation zwischen den Me punkten 1 und 2 sowie 7 und 8 aus Abbildung 5 8 nur ein Funktionsaufruf Daher sind die Me punkte 2 und 7 bei diesen Messungen weggelassen worden Der Request Broker auf der C94 ist ebenfalls Teil eines Moduls n mlich des PEGASE Moduls der die Daten Y MP C94 CuttingPlane PEGASE D Request Broker Teil von Request Broker Teil von PEGASE CuttingPlane Anfrage SSS Funktionsaufruf packobj o Tm ein o Abbildung 5 10 Me punkte der Konfiguration Y MP C94 berechnet An Stelle der Me punkte 3 und 6 des lokalen Request Brokers sind hier die Me punkte 3 und 4 auf dem PEGASE Request Broker zus tzlich direkt um das Einpacken des Datenobjektes gruppiert Dadurch l t sich der Aufwand f r das Suchen des Datenobjekts in den Datenstrukturen des Request
114. he Nutzung von M glichkeiten die ber die Standard Dateisystemfunktionalit ten hinausgehen wie zum Beispiel die Abspeicherung von Zugriffsinformationen oder die Nutzung mehrerer Links zwischen verschiedenen Datenobjekten Freie Nutzung verteilter Datenobjekte Da es sich um ein grunds tzlich verteiltes System handelt mu auch sichergestellt sein da auf Daten die nicht auf dem lokalen Persistenz Bereich gespeichert sind zugegriffen werden kann Das hei t ein Zugriff auf Datenobjekte die auf einem anderen Rechner persistent abgelegt sind mu m g lich sein Durch die Verkn pfung der Request Broker ist dies jederzeit gew hrleistet Um berschneidungen bei der Nutzung der Shared Data Spaces in einer ber mehrere Rechner ver teilten Umgebung zu vermeiden sollte unter Zuhilfenahme der im vorigen Absatz erw hnten Strukturie rungsm glichkeiten disjunkte Bereiche definiert werden Zun chst sollte es einen vom jeweiligen Rechner unabh ngigen Arbeitsbereich geben in dem die f r einen Programmablauf n tigen Zwischen objekte abgelegt werden Dar berhinaus steht auf jedem Rechner ein Bereich zur Verf gung der die dort abgelegten persistenten Objekte beinhaltet Diese persistenten Objekte lassen sich jederzeit auch in den Arbeitsbereich einbinden wie sich auch tempor re Objekte durch Verkn pfen mit einem Persistenz bereich zu persistenten Objekten machen lassen F r die einem Swap Bereich vergleichbare Funktionali t t l t
115. hen Performanceeinbu en anwenden Dies wird besonders deutlich wenn man die Partikelverfolgung betrachtet Zun chst betrachten wir diesen Algorithmus im nicht partitionier ten Fall Der Benutzer w hlt einen beliebigen Startpunkt f r die Partikelbahn Zuerst mu zu diesem Punkt das Element des Gitters gefunden werden in dem er liegt Falls es gefunden wird wird basierend auf den Geschwindigkeitsdaten dieses Elementes die n chste Position des Partikels berechnet Diese Position kann entweder im selben Element liegen oder aber in einem Nachbarelement das nicht unbe dingt direkt an das aktuelle Element anschlie en mu Das Finden des Startpunktes im partitionierten Fall l t sich noch relativ einfach durchf hren nach einander werden alle Partitionen durchsucht bis die in der der Startpunkt liegt gefunden wird falls keine gefunden wird hat der Benutzer offensichtlich einen Punkt au erhalb des Gebietes ausgew hlt Nachdem die Partition die den Startpunkt enth lt gefunden ist wird das Partikel analog zum nicht parti tionierten Fall verfolgt Dabei wird es fr her oder sp ter die Partition verlassen In diesem Fall mu die Partition gefunden werden in der das Partikel sich nun befindet Das kann nat rlich auch eine Partition sein die bereits auf der Suche nach dem Startpunkt bearbeitet wurde Im ung nstigsten Fall k nnte sich Seite 49 4 Konzept eines verteilten Visualisierungssystems ein Partikel im Kreis immer wieder du
116. hen immer nur eine CPU aktiv w hrend bei der partitionierten Ausf hrung bis zu vier Prozessoren gleichzeitig arbeiten Dadurch l t sich die Gesamtlaufzeit f r diese Visualisierung deutlich reduzieren Ein hnlicher Effekt ergibt sich bei der Verteilung von Modulen ber mehrere Rechner normaler weise wird erst ein Datenobjekt auf einem Rechner komplett angelegt und anschlie end als Ganzes auf den Rechner auf dem der n chste Modul l uft bertragen W hrend die beiden Request Broker damit besch ftigt sind das Datenobjekt einzupacken zu bertragen und wieder auszupacken ist keines der anderen Module aktiv Wird dagegen ein partitioniertes Objekt bertragen k nnen gleichzeitig sowohl vorhergehende Module mit nachfolgenden Partitionen besch ftigt sein und nachfolgende Module fr here Partitionen bearbeiten 4 4 3 Die Synchronisierung des Zugriffes auf Partitionen Um die sogenannte Pipelineverarbeitung der Partitionen der einzelnen Datenobjekte zu steuern k nnte zun chst der zentrale Controller genutzt werden Das hei t nachdem ein Modul eine Partition fertiggeschrieben hat sagt es dem Controller Bescheid der dann das n chste Modul dar ber informiert da eine neue Partition zur Bearbeitung bereitliegt Bei einer komplexeren Anwendung mit hochgradig partitionierten Datenobjekten k nnen dadurch jedoch erhebliche zus tzliche Belastungen bei der Inter proze kommunikation entstehen Da es sich hierbei im wesentlichen um datenre
117. hoden k nnen beliebig auf verschiedenen Rechnern Verteilung gt ausgefiihrt werden Datenverwaltung es gibt eine dedizierte Datenverwaltung Objektzugriff es gibt eine M glichkeit auf einzelne Datenobjekte zuzugreifen Objekte werden automatisch auf die Rechner gebracht Objektverteilung BG auf denen sie ben tigt werden Supercomputer die Software ist auf Supercomputern verf gbar Optimierung die Software ist f r Supercomputer optimiert Die Informationen die in der folgenden Tabelle dargestellt sind beziehen sich auf die neueste Ver sion der entsprechenden Software Da nicht bei allen Herstellern die Dokumentation ausreichend tiefen Einblick in die entsprechenden Interna der Software gibt findet sich in den Feldern zu denen keine hin reichenden Informationen gefunden wurden ein bedeutet nicht anwendbar Seite 24 3 2 Ubersichtstabelle Tabelle 3 2 Vergleich der Visualisierungssysteme Eigenschaft aie COVISE GRAPE RSTST AVS rate Ensight rate en Objekt Orientierung Ja Ja Ja Nein Ja Nein Nein Nein Klassen Ja Ja Ja Ja Vererbung Ja Ja Nein Ja Methoden Ja Ja Ja Ja Module Ja Nein Ja Ja Ja Nein Ja Ja Verteilung Ja Nein Nein Ja Nein Nein Ja Ja Datenverwaltung Ja Nein Ja Nein Ja Nein Nein Nein Objektzugriff Ja Ja Ja Objektverteilung Ja Ja Nein Supercomputer Ja Nein Ja Ja Nein Ja Ja Ja Optimierung Ja Ja Nein Nein Ja
118. hzeitig e Cray Y MP 2E 2 Prozessoren 256 MB Hauptspeicher UNICOS 8 0 2 3 HIPPI Netzwerkinterface und FDDI Channel Router dedizierter Fileserver keine numerischen Simulationen 60 nfsd zahlreiche Migrationsprozesse mit 10 GB schnellen Platten 50 MB s und mehr als 2 TB On line Band speicher Der Hauptspeicher ist sehr knapp was zu einer heftigen Swap Aktivit t f hrt e SGI Indigo 100 MHz R4000 Prozessor 128 MB Hauptspeicher XS24Z Graphik IRIX 5 3 Ethernet und FDDI Netzwerkinterface Single User Workstation Da das Rechenzentrum eine h chstm gliche Verf gbarkeit seiner Services den Benutzern gegen ber anstrebt mu ten die Messungen unter ganz normalen Bedingungen stattfinden D h die beiden Cray Rechner waren unter voller Last die C94 in der Regel mit 25 und mehr Numerikprozessen wobei durch den mit 8 Gigabyte sehr gro en Hauptspeicher in den meisten F llen kein Mangel an Speicher besteht und daher auch kein Proze auf Festplatten ausgelagert werden mu te die Y MP hatte 60 und mehr aktive NFS Prozesse und war mit 256 Megabyte Hauptspeicher sehr knapp ausgestattet Da die Messun gen unter Betriebsbedingungen zum Teil sehr schlechte Ergebnisse zeigten durfte f r eine Folge von Messungen die Wartungszeit der beiden Cray Rechner genutzt werden Zu dieser Zeit die leider nur recht selten und relativ kurz ist befanden sich nur noch zwei aktive Systemadminstratoren auf den Rech nern die keinerlei CPU intensiven Progr
119. i der Nutzung von Netzwerken ist da nur der Systemadministrator festlegen kann auf welchem Wege ein anderer Rechner erreicht werden kann Dar berhinaus ist mit dem Namen eines Systems oft nur ein Standardnetzwerkanschlu wie zum Beispiel Ethernet benannt w hrend die leistungsf higeren Anschl sse mittels eines Suffix an diesen Namen angesprochen werden m ssen Allein dadurch ist es dem Benutzer einer Standardanwendung in der Regel nicht mehr m glich die schnelleren Verbindungen zu nutzen Diese Beispiele zeigen da zur optimalen Nutzung der verf gbaren Netzwerke Konfigurationsm g lichkeiten zur Verf gung stehen m ssen die es dem Benutzer erlauben sich auch auf den Rechnern auf denen er keinen direkten Einflu auf die Konfiguration des System hat die optimale Leistung verf gbar zu machen Dazu gen gt es auch nicht einfach die gesamte Kommunikation ber die schnellste Verbin dung laufen zu lassen wie insbesondere das Beispiel der Ultranet Verbindung zeigt Vielmehr mu es gezielt m glich sein die Daten ber eine andere Verbindung laufen zu lassen als die Steuerungsinfor mation Die in COVISE realisierte Trennung von Daten Verbindungen und Steuerungsverbindungen macht dies auf sehr einfache Weise m glich Wenn man die Verteilung von Steuer und Daten Kommunikation auf die Verbindungen eines Szenario mit zwei Rechnern und gleichverteilten Modulen betrachtet so wird nur ein geringer Bruchteil der Anzahl der Botschaften zwis
120. icherbereich der Module liegen sondern im Shared Data Space der vom Request Broker verwaltet wird Zugriff erhalten die Module nur dadurch da sie den Shared Data Space in ihren eigenen Speicherbereich einblenden k nnen Entfernt werden k nnen Datenobjekte allerdings nur durch den Request Broker selbst der Controller kann nur eine Message mit der Bitte um L schung an den Request Broker schicken Objektlebenszeit ber das Ende des Programmlaufes hinaus Ganz wesentlich f r die Persistenz ist nun da der Request Broker vor Beendigung eines Programm ablaufes die M glichkeit hat die Datenobjekte permanent abzuspeichern Die einfachste M glichkeit besteht darin alle Datenobjekte vor Programmende in eine Datei zu schreiben und diese bei Programm beginn wieder zu lesen Diese Vorgehensweise erspart dem Benutzer im wesentlichen die f r seine Arbeit n tigen Daten jedesmal von neuem selbst aus einer Datei einzulesen Ein weitergehender und flexiblerer Ansatz w rde den Shared Data Space als eine Art Cache betrach ten Das hei t der Request Broker w rde Objekte nur bei Bedarf einlesen und bei Speicherplatzmangel Seite 41 4 Konzept eines verteilten Visualisierungssystems automatisch die am l ngsten nicht benutzten Objekte auf das Permanentmedium auslagern Dies w rde gleichzeitig das gesamte Speichermanagement des Request Brokers wesentlich leistungsf higer machen und einen effizienteren Einsatz knappen Hauptspeichers erm glichen
121. ichst effizient gehandhabt werden m ssen Allein durch diese Randbedingungen ist CORBA nicht die geeignete Architektur zur Handhabung der verteilten Objekte Dies sind jedoch nicht die einzigen Gr nde die zur Entwicklung eines eigenen Datenmanagements gef hrt haben Vielmehr sind die Anforderungen die an ein Datenmanagement in einem Visualisie rungswerkzeug f r die Darstellung von Simulationsergebnissen gestellt werden deutlich anders als die die man an eine generelle Architektur zur Vermittlung von Objektanfragen stellt Von wesentlicher Bedeutung ist hier insbesondere da man gerade wenn man mit sehr gro en Mengen von Daten arbeitet sehr genau wissen mu wo sich diese Daten befinden beziehungsweise wo neue Daten erzeugt werden sollen So kann es zum Beispiel durchaus sinnvoll sein eine Isofl chenberechnung f r ein besonders komplexes Gebiet auf einem Supercomputer durchzuf hren w hrend sie im Normalfall vielleicht aus Kostengr nden auf der Workstation des Benutzers durchgef hrt wird Es mu also eine M glichkeit geben eine Berechnung einem bestimmten Computer zuzuweisen Dadurch ergibt sich abweichend vom klassischen Objekt Methoden Modell bei dem das Objekt den Ort bestimmt an dem die Methode ausgef hrt werden soll ein Methoden orientiertes Modell bei dem die Methode auf einem bestimmten Rechner ausgef hrt werden soll und die Daten dann zur n chsten Seite 11 2 Die COVISE Visualisierungsumgebung Methode ge
122. ie die verschiedenen Module auf die Daten zugreifen wohldefiniert und geeignet implementiert sein Der modulare Ansatz erlaubt eine sehr einfache und klare Strukturierung der eigentlichen Visualisie rungsaufgabe siehe auch Abbildung 1 1 Nach einer Zerlegung der Visualisierung in die einzelnen Schritte sind die entsprechenden Aufgaben jedem Modul klar zugewiesen Der innere Ablauf der Module gliedert sich im allgemeinen in drei Teile e zun chst m ssen alle Eingabeparameter und Eingabedaten in den Modul gebracht werden e auf Basis dieser Parameter und Daten f hrt der Modul dann seine eigentliche Arbeit durch e abschlie end wird das Ergebnis dieser Arbeit wiederum in Form von Ausgabedaten bereitgestellt die die Eingabedaten f r die nachfolgenden Module darstellen Um die Handhabung dieser Module so einfach wie m glich zu machen ist es sinnvoll den Modul programmierer von der Komplexit t der verteilten Umgebung abzuschirmen Der soeben dargestellte innere Ablauf macht schon deutlich da dies ohne gro e Probleme m glich ist die einzigen Kontakte zur Au enwelt des Moduls finden im ersten und im letzten Teil statt Das hei t der Kern des Moduls in dem auch der wesentliche Teil seiner Funktionalit t angesiedelt ist ist v llig unabh ngig von der Vertei lung der Visualisierungspipeline Durch die entsprechende Gestaltung dieser Zugriffe auf die Daten ist es m glich die Module durchg ngig so zu gestalten da berhaupt keine Ke
123. iel wie m glich von diesem Lei stungspotential zug nglich zu machen Dabei stellte sich des fteren heraus da eine so effiziente Nut zung der Hardware wie sie hier erreicht wurde f r einen normalen Benutzer praktisch nicht m glich ist Die Bestimmung der optimalen Parameter f r die Netzwerke lie sich oft nur ber eine umfangreiche Reihe von Messungen unter den verschiedensten Bedingungen und Kombinationen erreichen siehe dazu auch 21 Mitunter waren gerade bei den Netzwerken auch besondere Einstellungen speziell f r die Messungen n tig die nur im Single User Mode durchgef hrt werden konnten 4 5 1 Supercomputer Computer dieser obersten Leistungsklasse sind kompromi los auf ein Ziel ausgerichtet m glichst schnell zu rechnen Diesem Ziel m ssen sich alle anderen Aspekte unterordnen Diese Ausrichtung hat nat rlich Vor und Nachteile Wenn man ein Programm hat da f r die spezielle Architektur und Konfi guration eines bestimmten Supercomputers geeignet ist so wird dieses Programm auf diesem Rechner mit einer Geschwindigkeit ablaufen die deutlich ber der auf allen anderen Rechnern liegt Auch die immensen Datenmengen die bei einem Rechenlauf anfallen k nnen werden ad quat auf so einem Supercomputer verarbeitet d h zum Beispiel da die Festplatten mit einer erheblich gr eren Geschwindigkeit beschrieben und gelesen werden k nnen Vektorisierung Zu den Besonderheiten eines solchen Supercomputers geh
124. in und Auspacken von Datenobjekten die zwischen den Request Bro kern verschickt werden und fiir den Zugriff auf die Datenobjekte im Shared Data Space In Abbildung 4 9 ist ein kleiner Ausschnitt aus der Klassenhierarchie fiir die Klassen die den Anwendungsrahmen d h die Kommunikation zwischen den Prozessen und den Zugriff auf den Shared Data Space bereit stellen und die dem Modulprogrammierer den Zugriff auf die Verbindungen tiber die die Botschaften ausgetauscht werden erlauben zu sehen Diese Diagramme sind nach der Object Model Notation aufge baut der Notation der Object Modeling Technique OMT aus 54 Process Connection name id socket host port f type sender_id list_of_connections sender_type msq_gueue other_host IN recv_msg send_msg OrdinaryProcess Sa controller_connection ServerConnection ClientConnection ApplicationProcess RequestBrokerProcess request_broker_connection list_of_object shared_memory ist_ol_objects shared_memory A list_of_request_brokers RequestBrokerConnection ControllerConnection Abbildung 4 9 Ausschnitt aus der Klassenhierarchie Der etwas detailliertere Aufbau des Request Brokers ist in Abbildung 4 10 zu sehen Hier sind nur die Relationen der Klassen zueinander dargestellt die Variablen und Methoden der einzelnen Klassen sind aus Griinden der Ubersi
125. in Database Issues for Data Visualization Lecture Notes in Computer Science Volume 1183 pp 181 207 Wierse Grinstein Lang Eds Springer 1996 Khanna R Ed Distributed Computing Implementation and Management Strategies Prentice Hall Englewood Cliffs 1994 Krause E J rgen W Eds High Performance Computing in Science and Engineering 98 Springer Verlag Berlin 1999 Lang U Visualisierung wissenschaftlicher Daten Manuskript zur Vorlesung Rechenzen trum der Universit t Stuttgart 1995 Lang U Lang R R hle R Scientific Visualization in a Supercomputer Network at RUS Computer amp Graphics Vol 17 No 1 pp 15 22 Pergamon Press Ltd 1993 Lang U Grave M Data Structures in Scientific Visualizaion in Hagen H M ller H Nielson G M Focus on Scientific Visualization pp 85 102 Springer Verlag Berlin 1993 Lang U Lang R R hle R Visualisation in a Software System for Scientific Compu ting in F H Post A J S Hin Eds Advances in Scientific Visualization Springer Verlag Berlin 1992 Lang U R hle R Visualisierung von Supercomputerberechnungen am netzintegrierten Ingenieurarbeitsplatz in Meuer H Hrsg Heterogene Netze und Supercomputer pp 121 133 Springer Verlag Berlin 1992 Lang U R hle R Scientific Application Environments Positional Paper SIGGRAPH 90 Workshop on Data Struc
126. inem Verbrennungsmotor dargestellt werden siehe Abbil Seite 68 5 1 Anwendungsbeispiele dung 5 2 Das Szenario sei dabei bewu t komplex gew hlt um die Vorteile des Systems deutlich zu machen Das Beispiel der Str mung in einem Verbrennungsmotor ist dem ESPRIT Projekt HPS ICE entnommen a Ez COVISE MapEditor vistst L gaai COVISE CtriPanel vistst7 x Session Execution Hosts Setups MasterControl euttingSurface 1 vertex 0 064534 0 00271 0 997912 seat 23 25499 ay Hosts je Modules DataObjects ColorMap RWCovise_2_OUT_01 ColorRGB RWCovise_3_OUT_01 StarColorMap RWCovise_4_OUT_01 RWCovise_5_OUT_01 Collect_1_OUT_01 ColorMap_1_OUT_01 ColorMap 2 OUT 01 istst7 Inv 2 1 he n Rendere File Viewing Editors Manips Lights Sync MASTER Colormaps Sync ment Geometry Objects RWCovise_5_OUT_01 Collect_1_OUT_01 Collect 2_OUT_01 TracerUSG_2_OUT_01_0 TracerUSG_2_OUT_01 1 aM Messages from Modules UIF gt gt can t find timer record for requested vistst7_isovalue Rote Roty ETON Zoom 45 0 pony Abbildung 5 2 Bildschirmabzug des Motordatensatzes in der COVISE Umgebung Die verwendete Rechnerkonfiguration ist in Abbildung 5 3 zu sehen Dort werden drei Rechner ein gesetzt
127. inen entsprechend gro en Speicherplatz zuzuwei sen und beim Kopieren den entsprechenden Bereich in dem das Objekt liegt spezifizieren zu k nnen Wenn allerdings Daten zwischen Rechnern ausgetauscht werden m ssen die verschie dene Formate bei der internen Repr sentation von Flie kommazahlen benutzen mu beim Ver schicken der Datenobjekte von einem Request Broker zum anderen eine Konvertierung vorgenommen werden Diese Konvertierung h ngt nat rlich davon ab ob zum Beispiel eine Flie kommazahl oder eine Integerzahl verschickt werden soll e Es mu m glich sein ohne eine nderung im System neue Datentypen einzuf hren Um dem System die volle Flexibilit t zu geben auch an Situationen angepa t werden zu k nnen die bei der Implementierung der Kernkomponenten noch nicht absehbar sind ist es erforderlich da Module erstellt werden k nnen die eigene neue Datentypen benutzen Die nach diesen neuen Datentypen erzeugten Datenobjekte mu der Request Broker ebenso handhaben k nnen wie die nach bereits bekannten Datentypen erzeugten Das schlie t selbstverst ndlich auch n tige Kon vertierungen ein Aus diesen Bedingungen ergibt sich sofort da eine umfassende Typisierung der zu speichernden Daten erforderlich ist Dies bedeutet da jedes zu speichernde Element eine Typidentifikation mit sich bringen mu 4 2 2 Hierarchie der Datentypen Um die oben bereits angesprochene Flexibilit t bei der Einf hrung neuer Datentypen zu
128. innen Lokale Workstation Entfernte Workstation Controller Shared Data Space Shared Data Space Abbildung 4 3 Nicht Lokaler Datenaustausch Seite 29 4 Konzept eines verteilten Visualisierungssystems Nicht Lokaler Datenaustausch Nun soll der Fall betrachtet werden da das Lese und das Filtermodul nicht auf demselben Rechner ausgef hrt werden siehe Abbildung 4 3 Zun chst l uft alles nach genau demselben Schema ab wie im lokalen Fall Der Lesemodul bekommt mit der Startmessage den Namen des Objektes besorgt sich bei seinem Request Broker den n tigen Speicherbereich im Shared Data Space f llt ihn mit seinen Daten und schickt eine Finishmessage an den Controller zur ck Daraufhin wird eine Startmessage mit dem Objektnamen an den Filtermodul geschickt woraufhin dieser seinem Request Broker mitteilt da er auf dieses Objekt zugreifen m chte Dieser Request Broker findet jedoch in dem von ihm verwalteten Shared Data Space kein Datenobjekt dieses Namens Daraufhin setzt er sich mit dem direkt mit ihm ver bundenen Request Broker in Verbindung und bittet diesen nachzuschauen ob er ein solches Datenob jekt in seinem Shared Data Space hat und es gegebenenfalls zu schicken Nachdem nun eine Kopie D des Datenobjektes D angelegt worden ist wird die Adresse dieser Kopie an den Filtermodul B zur ckge schickt Dieser kann daraufhin wieder ganz wie im lokalen Fall auf d
129. inter essant Die Visualisierung unter RSYST basiert wesentlich auf sogenannten graphischen Objekten 34 Im Fenster des PHIGS Moduls k nnen ein oder mehrere solcher graphischen Objekte dargestellt wer den Ein graphisches Objekt ist dabei die Repr sentation einer gewissen Menge von Datenobjekten aus der RSYST Datenbasis Anzahl und Typ dieser Datenobjekte ist fest f r ein bestimmtes graphisches Objekt Gr e und Inhalt sind variabel Nachdem der Typ des graphischen Objektes festgelegt worden ist wird eine neue Instanz dieses Objektes basierend auf den Datenobjekt Informationen die aus der RSYST Datenbasis gelesen werden erstellt Ein solches graphisches Objekt kann dann auf verschiedene Weise manipuliert werden entweder ber Objekttyp unabh ngige Aktionen wie Drehen Skalieren Ver schieben etc oder ber die nderung objekttyp abh ngiger Parameter wie zum Beispiel der Isowert f r eine Isofl chenberechnung Sowohl die PHIGS Datenstruktur als auch die von RSYST sind hierarchisch organisiert Daher bot es sich an die PHIGS Datenstruktur auf die RSYST Datenbasis abzubilden d h das Ergebnis der Visuali sierung wird in der Datenbasis gespeichert Dadurch ist es m glich die Strukturen und Daten aus PHIGS mittels RSYST Modulen zu manipulieren und das Ergebnis wiederum in der PHIGS RSYST Umgebung darzustellen Dabei ist es zum Beispiel m glich nur das Muster einer Visualisierung zum Beispiel Rotations oder Translationsfaktoren die Po
130. io und Videodaten vorkommen sind schon erarbeitet worden Dazu erscheint es sinn Seite 92 6 2 Ausblick voll parallel zum Request Broker einen Proze einzuf hren der kontinuierlich Daten bertr gt und dabei automatisch die in einem Ringpuffer organisierten Datenstr me verteilt Selbstverst ndlich wird auch die bestehende Implementierung auf Verbesserungsm glichkeiten untersucht werden Der Nachteil der Datenbank orientierten Datenverwaltung gegen ber den Standard systemen soll minimiert werden wesentlich dabei ist da die Vorteile in vollem Umfang erhalten blei ben m ssen Die Implementierung ist von Beginn an auf gr tm gliche Portabilit t ausgelegt worden und l uft bereits auf allen wesentlichen Unix Plattformen Eine weitere Portierung auf nicht Unix Platt formen wird einige Anpassungen erforderlich machen Die bisher durchgef hrten Entwicklungen haben ihren Ursprung im Bereich des Supercomputing und der verteilten Visualisierung Das Konzept ist jedoch nicht auf Visualisierung beschr nkt sondern kann vielmehr als generelles Werkzeug zur Verteilung von Aufgaben auf mehrere Rechner dienen die Art diese Aufgaben ist im wesentlichen bestimmt durch einen nicht zu hohen Grad der Granularit t Dabei kann aufgrund der COVISE Gesamtarchitektur immer gleich kollaborativ gearbeitet werden Bei dieser Ausdehnung des Anwendungsbereiches wird jedoch darauf geachtet werden nicht mit Standards wie CORBA oder Anwendungen wie AVS Ex
131. ionierung von Daten ist ein sehr aktuelles Problem insbesondere im Hinblick auf die Nut zung von massiv parallelen Rechner wie zum Beispiel der Cray T3E vonSGI Bei einem f r die Paralle lisierung geeigneten Algorithmus lassen sich die Rechenzeiten durch die Verteilung auf die verschiedenen Prozessor Einheiten PEs zum Teil drastisch verk rzen Gleichzeitig steht bei ver gleichsweise normaler Ausstattung der einzelnen PEs mit Hauptspeicher z B 128 MB pro PE insge samt dennoch ein immenser Gesamtspeicher zur Verf gung bei 512 PEs ber 60 Gigabyte Bei einer numerischen Berechnung mu nun das Gitter auf dem die Berechnung durchgef hrt wird auf die ein zelnen PEs verteilt werden Dabei ist wichtig da diese Verteilung gleichm ig erfolgt so da die Berechnung m glichst schnell beendet werden kann wenn alle Knoten bis auf einen in 10 Sekunden ihre Berechnung beenden k nnen dieser eine aber eine Stunde braucht liegt die Gesamtberechnungsdauer bei einer Stunde Ein weiterer Aspekt ist da die Grenzen zwischen den einzelnen Gebieten so klein wie m glich sein sollen um den Datenaustausch zwischen den Gebieten so gering wie m glich zu hal ten F r die Partitionierung von Objekten in der Visualisierung k nnen sich deutlich abweichende Anfor derungen ergeben Diese Anforderungen h ngen wesentlich von der Visualisierungstechnik ab Isofl che Schnittfl che Partikelverfolgung aber auch von dem zugrundeliegenden Gitter str
132. istributed Systems Second Edition Addison Wesley New York 1993 Nielson G M Shriver B and Rosenblum L J Visualization in Scientific Computing IEEE Computer Society Press Los Alamitos 1990 Object Management Architecture Guide Object Management Group OMG Framingham MA 1990 Perdue J High Bandwidth Interactivity and Super Networks in Mendez R H ed Visua lization in Supercomputing pp 80 99 Springer Verlag New York 1990 Rabenseifner R et al Das DFN Remote Procedure Call Tool Benutzerhandbuch Band 1 Release 1 0 60 beta Rechenzentrum der Universitat Stuttgart 1994 Rantzau D Thomas P Parallel CFD Simulations in a Collaborative Software Environment Using European ATM Networks in Proceedings of the Parallel Computational Fluiddyna mics 96 Capri 1996 Rantzau D Lang U A Scalable Virtual Environment for Large Scale Scientific Data Analy sis in Future Generation Computer Systems 14 1998 pp 215 222 Elsevier Science 1998 Resch M Rantzau D Berger H Bidmon K Keller R Gabriel E A Metacomputing Environment for Computational Fluid Dynamics in Proceedings of the 10th Parallel Com putational Fluid Dynamics Conference Parallel CFD 98 Hsinchu Taiwan 11 14 May 1998 to be published Rill S Grosso R Future Aerospace Working Scenarios Using High Speed Networks and Supercomputers Applied to Flow Simulation for Com
133. it t allerdings von den Herstellern beigemessen wird wird darin deutlich da die NEC SX4 des Rechenzentrums bei 8 Gigabyte Hauptspeicher maximal 1 Megabyte Shared Memory pro Segment zulie Dieser Wert lie sich durch Umkonfiguration des Kernels auf maximal 8 Megabyte erh hen Eine weitere Erh hung auf Seite 52 4 5 High Performance Komponenten angemessene Werte ist nur durch eine nderung im Betriebssystem m glich Wenn also gr ere Daten mengen auf der NEC verarbeitet werden m ssen wird weiterhin auf den ineffizienten Ansatz der Inte gration von Modul und Request Broker ausgewichen werden m ssen Workstation Supercomputer UI Controller N Fe u N A B C N D RB Shared Data Space Shared Data Space Abbildung 4 8 Modul Request Broker auf einem Supercomputer 4 5 2 Netzwerke Die verschiedenen heute verf gbaren Netzwerke haben sehr unterschiedliche Charakteristiken 21 47 66 Als wenn auch schon veraltetes aber besonders deutliches Beispiel soll hier kurz das Ultranet dienen Die theoretische Bandbreite dieses Netzwerkes betr gt 800 MBit s Dies wird unter anderem dadurch erreicht da der Overhead der dadurch entsteht da jedes verschickte Datenpaket einiges an Information z B die Zieladresse mit sich tragen mu minimiert wird Die Pakete bei Ultranet sind daher extrem gro 32 KB zum Vergl
134. jekt l t sich ber die Lebenszeit eines Programmlaufes hinweg erhalten indem es auf ein permanentes Medium geschrieben wird Festplatte Band e es gibt eine M glichkeit diese Objekte hierarchisch zu strukturieren e Objekte k nnen frei w hrend eines Programmlaufes auf den genutzten Rechnern verwendet wer den Seite 40 4 3 Persistenz Identifizierung von Objekten Anfangs wurde davon ausgegangen da innerhalb eines laufzeitorientierten Systems die Namenge bung der Objekte angelehnt an den erzeugenden Modul ausreichend sei Durch die Erweiterung auf per sistente Objekte ist jedoch offensichtlich da so eine Kennzeichnung nicht mehr eindeutig ist Daher werden alle Objekte jetzt mit einer Identifizierungsnummer versehen Diese Objekt Id wird aus der IP Adresse des Rechners auf dem es erzeugt wurde der entsprechenden Zeit und der Proze Id des erzeu genden Prozesses generiert Diese Information dient alleine dem Zweck eine eindeutige Identifikation zu generieren Es wird nicht versucht aus der Objekt Id R ckschl sse auf Erzeugungsort oder Zeit zu ziehen Sollte dies n tig sein m ten eigene Attribute die diese Information enthalten gesetzt werden Der Grund f r diese Unterscheidung l t sich an einem einfachen Beispiel ersehen bei dem ein Objekt auf einen anderen Rechner kopiert wird die Kopie eines Objektes auf einem anderen Rechner tr gt denselben Namen wie das Originalobjekt Das ist auch sinnvoll denn das Obje
135. kt wird ja nur aus Gr nden der Ablaufoptimierung kopiert wenn die Kopie ge ndert wird mu unbedingt auch das Origi nal angepa t werden Es wird aber auch durchaus Zeiten geben in denen Kopie und Original unter schiedlich sind es also sinnvoll ist da diese beiden Objekte nicht dieselbe Objekt Id haben Dadurch w rde aber auch der Versuch aus der Objekt Id die urspr ngliche Erzeugungszeit abzuleiten zu einem falschen Ergebnis f hren Objektlebensdauer unabh ngig von Modulen W hrend eines normalen Programmablaufes erlischt das Interesse des Benutzers an den Datenobjek ten in der Regel in dem Moment in dem er einen Modul l scht Daher sind bei allen kommerziell erh lt lichen Visualisierungsprogrammen die auf dem Paradigma des visuellen Programmierens beruhen in dem Moment in dem ein Modul gel scht wird auch alle Daten die er direkt produziert hat verloren es sei denn der darauffolgende Modul hat sie noch in seinem Eingangsspeicher Umgekehrt sind Daten die sich nicht im Ausgangsspeicher des erzeugenden Moduls befinden verloren wenn der darauffolgende Modul gel scht wird Durch die eigenst ndige Existenz der f r den Datenaustausch zwischen Modulen verwendeten Daten objekte ist nun jedoch gew hrleistet da im Bedarfsfall diese Datenobjekte auch unabh ngig von der Lebensdauer der Module weiter verf gbar sind Dies wird offensichtlich wenn man sich in Erinnerung ruft da diese Datenobjekte eigentlich nicht im Spe
136. l ausnutzen zu k nnen Der hohe Grad der Ausnutzung der theoretisch m glichen Bandbreite bei den FDDI Workstation Workstation und bei den HIPPI Supercomputer Supercomputer Messungen sind ein deutliches Indiz daf r da sich der bei der Optimierung betriebene Aufwand gelohnt hat Gerade der hohe Anteil des Nettodurchsatzes der zum Beispiel bei der HIPPI Verbindung auch beim Bruttodurchsatz also dem f r den Benutzer einzig relevanten Durchsatz brigbleibt belegt die hohe Qualit t der Datenkommunika tion Vergleicht man diese Raten mit denen der heute meist verwendeten Mechanismen z B ftp oder NFS so wird deutlich da mit dieser interaktiven verteilten Arbeitsweise eine ganz neue Qualit t in der Nutzung Einzug h lt Und zwar in einer Weise die dem Benutzer absolut transparent erscheint und sich einfach nutzen l t Nachdenklich stimmt jedoch der gro e Einflu den die Auslastung der beiden Supercomputer auf die Gesamtperformance hat In den meisten F llen sind die H lfte der Messungen oder mehr deutlich hinter dem zur ckgeblieben was unter optimalen Umst nden erreichbar ist Gerade der Vergleich dieser Werte mit dem Durchsatz den zwei miteinander ber FDDI verbundene Workstations erreichen l t Zweifel an der Vertr glichkeit des interaktiven Arbeitens mit den derzeit dem Betrieb der Supercomputer zugrundeliegenden Bedingungen diese werden immer noch berwiegend im Batch Betrieb gefahren d h ein Benutzer stellt einen Num
137. lben Rechner mit derselben Uhr gemessen wurden Etwaige Korrekturen dieser Uhren w hrend einer laufenden Messung k nnen nicht ausgeschlossen werden d rften sich aber im Millisekundenbereich oder darunter bewegen bei mehreren Messungen ist es auch hinreichend unwahrscheinlich da diese Spr nge immer an der gleichen Stelle auftreten Da bei diesen Messungen auch nicht die maximal erreichbaren Leistungen der Netzwerkinterfaces des Workstationherstellers von Interesse sind sondern vielmehr die Zeit die insge samt im Netzwerk verloren geht reichen die Me punkte absolut aus um einen Eindruck von der Lei stungsf higkeit dieses Ansatzes zu geben Bei der Berechnung der Netzwerkzeit treten eventuelle Unterschiede zwischen den Rechnerzeiten und der genauen Zeit nicht auf sie heben sich auf Die einzig m glichen Differenzen k nnten aus einem verschieden schnellen Laufen der Uhren der beteiligten Rech ner kommen was aber beim Stande der heutigen Technik in den Gr enordnungen dieser Messungen getrost vernachl ssigt werden kann Seite 77 5 Resultate Betrachtet man die Zeit die der Tracer insgesamt warten mu te Spalte eins so sieht man da sich die optimale Performance erst nach ein oder zwei Durchl ufen einstellt bedingt durch Initialisierungen die nur beim ersten Mal auftreten oder eine vom Betriebssystem verursachte Optimierung von Cache Inhalten 0 0 2 0 4 0 6 0 8 1 Komm Tr RB mlokaler RB amp Komm RB RB remo
138. lcher Modul wo l uft und in welcher Reihenfolge die Module gestartet werden sollen Auf jedem beteiligten Rechner l uft zus tzlich ein sogenannter Local Controller LC der f r die Ausf hrung der Module sowie das Herstellen der Sok ket Verbindungen zwischen ihnen die Nutzung von UNIX Pipes und das Shared Memory zust ndig ist Durch diesen Ansatz soll die Kommunikation zwischen den Rechnern auf ein Minimum beschr nkt wer den Das hei t die Steuerung der Module D und E findet lokal auf der entfernten Workstation statt ohne da der Global Controller diese Aktion berwachen mu Das Userinterface UI ist direkt mit dem Glo bal Controller verbunden Seite 21 3 Vergleich mit existierender Software Dies l t sich als Anzeichen daf r werten da bei IRIS Explorer im Gegensatz zu AVS die Vertei lung der Module iiber verschiedene Rechner von Anfang an bei der Konzeption beriicksichtigt wurde Dazu geh rt auch da die Verwendung von Shared Memory f r Daten die auf demselben Rechner wei terverarbeitet werden von vornherein implementiert wurde Allerdings wurde dies nicht immer f r alle Datentypen unterst tzt Erst seit Version 3 0 werden zum Beispiel auch Geometriedaten zwischen Modulen ber Shared Memory ausgetauscht Der Zugriff auf die Daten die zwischen den Modulen ausgetauscht werden ist auch beim IRIS Explorer nicht direkt m glich Der Benutzer hat keinerlei M glichkeit sich ein solches Datenobjekt anzusehen oder zu
139. leichm ig auftreten In Abbildung 5 13 sind die Ergebnisse der drei schnellsten Messungen zu sehen Auch bei dieser theoretisch vergleichsweise schnellen Verbindung geht die meiste Zeit im Netzwerk ver loren w hrend etwa ein Viertel mit Ein und Auspacken sowie Konversion der Daten verbracht werden Tracer lokaler RB Da ER RB in Read Konversion Netzwerk ER on 6 846 6 838 6 626 5 922 0 051 0 704 4520 KB s 464 KB s 9 425 9 418 9 280 8 520 0 050 0 760 4187 KB s 337 KB s 10 367 10 361 10 223 9 420 0 100 0 803 3963 KB s 306 KB s 0 852 0 846 0 710 0 085 0 057 0 625 5092 KB s 3735 KB s 13 595 13 576 13 436 12 762 0 052 0 674 4721 KB s 234 KB s 1 005 0 989 0 769 0 070 0 056 0 699 4553 KB s 3166 KB s 8 828 8 821 8 687 7 804 0 050 0 883 3604 KB s 360 KB s 0 815 0 809 0 673 0 066 0 051 0 607 5243 KB s 3905 KB s Tabelle 5 10 Y MP zu Indigo HIPPI nach FDDI Seite 86 5 2 Messungen E rrr 0 0 2 0 4 0 6 0 8 1 Zeit in Sekunden Komm Tr RB RB Read Konversion Netzwerk Auspacken Abbildung 5 13 Graphik der Me ergebnisse aus Tabelle 5 10 Insgesamt bleiben jedoch sowohl der Netto als auch der Bruttodurchsatz deutlich hinter den Erwar tungen zur ck W hrend zwischen dem FDDI Interface der C94 und der Workstation bis zu 7 5 MB s bei einem vergleichbaren Datensatz flie en sind es zwischen dem HIPPI Inter
140. levante Vorg nge han delt bietet es sich an die Synchronisierung des Zugriffes auch ber den Request Broker der auch die sonstigen Datenzugriffe regelt zu sichern Dies ist auch aus dem Grunde sinnvoll da Module die ein neues Datenobjekt auch wenn es sich nur um eine Partition handelt bearbeiten m chten dessen Adresse im Shared Data Space nur vom Request Broker erfahren k nnen Selbst wenn die Synchronisierung also ber den Controller erfolgte w re doch bei jedem Schritt noch eine Kommunikation mit dem Request Broker n tig Es liegt also nahe die komplette Synchronisation direkt hier ber abzuwickeln Wenn ein Modul ein partitioniertes Objekt schreiben m chte besorgt es sich vom Request Broker zun chst ein partitioniertes Datenobjekt Dieses partitionierte Datenobjekt ist typunabh ngig und beinhaltet alles was f r die Synchronisierung n tig ist Die eigentlichen Partitionen sind ganz gew hnli che Datenobjekte die auch von den Kernalgorithmen der Module abgearbeitet werden In der Regel kann man zwar davon ausgehen da bekannt ist wieviele Partitionen vorhanden sind allerdings gilt das nicht immer zum Beispiel kann bei Isofl chen je nach Wert eine deutlich von der Partitionierung des Grundgebietes abweichende Partitionierung eintreten Daher wird zun chst davon ausgegangen da es sich um eine noch nicht bekannte Zahl von Partitionen handelt Der Einfachheit halber sollen auch die Nachbarschaftsbeziehungen zwischen den
141. lpro grammierer auf ein Datenobjekt dessen Typ er nicht kennt so bergibt er den Namen dieses Objektes an den Konstruktor der Basisklasse aller Datenobjekte Diese wiederum schickt den Namen an den Request Broker l t sich von diesem dann die Adresse zur ckschicken und nimmt eine Grundinitialisierung der datenstrukturunabh ngigen Parameter wie Name oder Referenzz hler vor M chte der Modulprogrammierer nun auf das eigentliche Datenobjekt zugreifen so ruft er die zur Basisklasse geh rende Methode create_unknown auf Diese Methode liest nun die Typ Identifizie rung aus dem Shared Data Space besorgt sich aus der statischen Liste die Adresse des dazugeh rigen Konstruktors und ruft diesen mit der Adresse des Objektes im Shared Data Space auf Dieser Konstruk tor initialisiert das Zugriffsdatenobjekt dann genauso als ob er die Adresse direkt von Request Broker bekommen h tte Als R ckgabewert der create_unknown Methode wird nun die Adresse des neuen Zugriffsdatenobjektes bergeben Der Modulprogrammierer kann nun ganz einfach von diesem Zugriffsdatenobjekt den Typ abfragen und in die entsprechende Routine verzweigen Der Modulprogrammierer mu also zwei zus tzliche Aufrufe t tigen bevor er ein Datenobjekt des sen Typ er nicht kennt bearbeiten kann Urspr nglich war eigentlich geplant diese beiden zus tzlichen Aufrufe in den Basiskonstruktor zu integrieren Leider war das durch Inkompatibilit ten der Compiler nicht auf allen Plattf
142. lst cke oder des Schnittebenenteils durchgef hrt werden Danach ist diese Partition erledigt und wird aus dem Speicher gel scht um Platz f r die n chste Partition zu machen Seite 44 4 4 Partitionierte Objekte Im Fall der Partikelverfolgung ist dies jedoch nicht so einfach m glich da sich erst aus der Berech nung der Partikelbahn ergibt mit welcher Partition fortgefahren werden mu das hei t in welche Parti tion sich das Partikel bewegt hat Dies kann dazu f hren da sich bei einem im Kreis bewegenden Partikel dieselben Partitionen immer und immer wieder geladen und anschlie end wieder gel scht wer den Sollte der Speicherbereich auf der Workstation wirklich nur die Haltung einer Partition gestatten mu jedesmal wieder neu vom Parallelrechner geladen werden besteht die M glichkeit mehrere Parti tionen entweder direkt im Shared Data Space oder wenigstens in einem per Cache beschleunigten Persi stenzbereich zu halten so l t sich zumindest das dauernde Nachladen vermeiden wobei es in einer High Performance Netzwerk Umgebung durchaus sein kann da eine HIPPI Verbindung zum Parallel rechner schneller ist als der lokale Plattenzugriff auf der Benutzerworkstation Abh ngig von der Gr e der resultierenden Datenobjekte kann die partitionierte Bearbeitung nur f r einen Teil der ganzen Visualisierung oder aber auch f r den ganzen Proze genutzt werden Wenn sie nur f r einen Teil genutzt werden soll so mu es einen M
143. malen Einfu auf den erreichba ren Durchsatz hat Die Verteilung der Me punkte ist wie im Fall der Ethernet Messungen Auch bei die sen Messungen siehe Tabelle 5 7 wirkt sich die Last der C94 aus in der H lfte der F lle dauert der Request Broker Anteil des PEGASE Prozesses mehr als drei Sekunden In der anderen H lfte zeigt sich jedoch eine gleichbleibend gute Performance die sich auch im Bruttodurchsatz niederschl gt mit fast 5 MB s wird das angeforderte Datenobjekt dem Tracer zug nglich gemacht Dies schlie t auch in diesem Fall die Konvertierung der Daten ein die mit etwa drei Prozent zu Buche schl gt also bei der Gesamt performance keine Rolle spielt Die n tige Konvertierung von Daten ist also kein Grund einen Proze nicht auf einen Cray Vektorsupercomputer auszulagern wenn der Algorithmus davon profitiert Tracer ee Kiss a RB in PEGASE Konversion Netzwerk oe Se 0 780 0 767 0512 0028 0018 0484 6648KB s 4125 KB s 4 725 4 709 4 550 3 802 0 018 0 748 4301 KB s 680 KB s 3 759 3 744 3 593 3 114 3 107 0 479 6717 KB s 856 KB s 0 683 0 670 0 456 0 029 0 018 0 427 7535 KB s 4711 KB s 0 665 0 658 0 501 0 030 0 019 0 471 6831 KB s 4838 KB s 0 664 0 650 0 491 0 040 0 029 0 451 7134 KB s 4845 KB s Tabelle 5 7 C94 zu Indigo FDDI kleiner Datensatz Seite 83 5 Resultate lokaler warten im 5 Netto Brutto Tracer RB lokalen RB RB in PEGASE Konversion Net
144. n e der Zugriff auf das Datenobjekt mu hergestellt werden unabh ngig davon wo das Datenobjekt urspr nglich angelegt wurde e auf die Teile des Datenobjektes mu zugegriffen werden k nnen m glichst in einer Weise die den Modulprogrammierer bei seiner eigentlich Arbeit der Implementierung des Visualisierungs algorithmus nicht behindert Seite 4 1 3 Gliederung der Arbeit e es mu m glich sein neue Datenobjekte anzulegen und diese mit Daten zu f llen diese Datenob jekte miissen anschlieBend natiirlich anderen Modulen zur Verfiigung stehen Um in einem verteilten System eine schnelle Antwort auf Anfragen von Modulen zu gew hrleisten ist es sinnvoll nicht einen zentralen Request Broker einzuf hren was beim Netzwerkzugriff zu deutli chen Performanceeinbu en f hrt sondern ein dezentrales Netz von jeweils lokalen Request Brokern auf jedem beteiligten Rechner aufzubauen Dies stellt sicher da keine unn tige Zeit bei der Kommunika tion ber Rechnergrenzen hinweg verloren geht Die Datenverwaltungsfunktion mu zwischen diesen Request Brokern koordiniert werden Aus den obigen Bedingungen ergibt sich da der Datenverwaltung innerhalb des gesamten Systems eine wichtige Rolle zukommt Sie garantiert eine einfache Handhabung der Module einen sauber kon trollierbaren Datenflu und ist mit ausschlaggebend f r die Leistung des Gesamtsystemes Ziel dieser Arbeit ist basierend auf diesen Annahmen ein f r die Visualisie
145. n vom Scheduling im PEGASE Request Broker unterbrochen eine davon bei der Konversion Sowohl der Nettodurchsatz mit maximal ber 8 MB s als auch der Bruttodurchsatz mit fast 6 MB s liegen sp rbar h her als bei den Messungen mit dem kleinen Datensatz Tracer lokaler RB ae a eas aa Konversion Netzwerk Kane or 5 417 5 406 3 818 0 177 0 163 3 641 6454 KB s 4338 KB s 4 247 4 239 3 065 0 151 0 136 2 914 8064 KB s 5533 KB s 14 276 14 257 10 560 0 159 0 145 10 401 2259 KB s 1646 KB s 7 594 7 582 6 222 3 173 3 157 3 065 7667 KB s 3094 KB s 4 346 4 329 3 144 0 148 0 134 2 996 7844 KB s 5407 KB s 5 950 5 936 4 940 2 095 0 139 2 845 8260 KB s 3949 KB s 4 067 4 054 3 054 0 155 0 141 2 899 8106 KB s 5778 KB s 5 324 5 310 4 310 1 469 0 252 2 841 8272 KB s 4414 KB s Tabelle 5 8 C94 zu Indigo FDDI gro er Datensatz Um den Einflu der Last auf die Messungen m glichst genau zu untersuchen wurden die Messungen mit den gleichen Daten noch einmal w hrend der Wartungszeit der C94 also auf einer nahezu leeren Maschine wiederholt Die Ergebnisse in Tabelle 5 9 zeigen da in der Maximalleistung nur noch geringe Zuw chse zu erreichen sind Allerdings wird die Maximalleistung fter erreicht als auf der aus gelasteten C94 Aus Benutzersicht bedeutet dies da die Maximalleistung auch auf einer ausgelasteten C94 erreicht werden kann es aber nur relativ selten gelingen wird Die schlecht
146. n Vorteile einer dedi zierten Datenverwaltung im Hinblick auf eine effiziente Datenkommunikation die Erweiterung in Rich tung Persistenz und Cacheing oder Einf hrung neuer Datentypen erl utert worden Der mit einer solchen nicht ganz direkten Datenhandhabung verbundene Zusatzaufwand ist dabei nicht so hoch da er die Effizienz dieses Systems in Frage stellen kann Die Messungen haben gezeigt da die Vorteile der Datenverwaltung vielmehr die Gesamteffizienz des Systems erh hen da sie dem Benutzer eine M glichkeit gibt die Verteilung der Module seiner Visualisierung optimal an die jeweili gen Gegebenheiten anzupassen ohne da er sich mit umst ndlicher Konfigurationsarbeit besch ftigen mu 75 76 6 2 Ausblick Ein gro er Teil des in dieser Arbeit aufgezeigten Potentials der Datenbank orientierten Datenverwal tung ist erst in Ans tzen realisiert Dazu geh ren unter anderem die Persistenz das Cacheing und die partitionierten Objekte Diese Bereiche werden intensiv auf ihre Funktionalit t hin untersucht werden F r die industrielle Anwendung m ssen die Fragen der Integration einer solchen Umgebung in den Pro ze ablauf gekl rt werden wie l t sich zum Beispiel das Datenmanagement an ein PDM System anbin den Weiterhin sind die Datenobjekte die bislang verarbeitet werden immer statisch selbst wenn es sich um zeitabh ngige Daten handelt Erste Konzepte f r die Handhabung von Datenstr men wie sie zum Beispiel bei Aud
147. n der Industrie blichen Falles skizziert und auf ihre Auswirkungen bei der Visualisierung hin beleuchtet Anschlie end werden die Systemarchitektur des Visualisierungssystems COVISE sowie die es direkt beeinflussenden Systeme kurz vorgestellt COVISE dient als Prototyp innerhalb dessen die meisten der in dieser Arbeit vorgestellten Konzepte realisiert sind Anschlie end werden einige verbreitete Visuali sierungssysteme anhand der anfangs festgestellten Anforderungen auf ihre Datenverwaltung hin analy siert und dem in COVISE realisierten Konzept gegen bergestellt Im darauffolgenden Kapitel werden diese Konzepte ausf hrlich vorgestellt Die verteilte Datenver waltung steht dabei im Mittelpunkt es wird beschrieben wie der Datenaustausch zwischen den Modulen realisiert ist sowohl im lokalen Fall als auch im Fall einer verteilten Anwendung Die Vorteile dieses Ansatzes und die n tigen Mechanismen um einen eindeutigen Datenzugriff in einem verteilten System sicherstellen zu k nnen werden dargelegt Den Datenobjekten kommt in diesem Zusammenhang eine Schl sselrolle zu Die f r die Handhabung der Berechnungs und Geometriedaten wichtigen Strukturen werden entwickelt und die passenden Hier archien dargestellt Im Hinblick auf die Nutzung dieser Datenobjekte durch die Module werden die Handhabung der Datenobjekte und die Zugriffsmechanismen beschrieben Dabei werden auch die M g lichkeiten diskutiert Datenobjekte persistent zu gestalten oder
148. ndelt Damit so ein neuer Datentyp vom Request Broker auch verarbeitet d h verschickt und gegebenenfalls konvertiert werden kann mu die gesamte Struktur aus den folgenden Datenelementen erkennbar sein Nach der Typnummer folgt genau wie bei einem Character Feld die L nge des gesamten Objekts in Bytes Daran schlie t sich ein bei allen Datenobjekten von der Struktur her gleicher Header an in dem alle Eigenschaften eines Datenobjektes stehen Abbildung 4 5 zeigt ein solches Datenobjekt nachdem es im Shared Data Space angelegt wurde und ein Anwendungsmodul das Handle Objekt f r den direkten Zugriff erzeugt hat Der Header enth lt eine eindeutige Objektidentifizierungsnummer ID diese setzt sich aus dem Datum und der IP Adresse des Rechners auf dem das Objekt erzeugt wurde zusammen eine Versionsnummer ver ein Referenzz hler refc die Anzahl der Elemente aus denen sich das Datenobjekt zusammensetzt el ein Zeiger auf ein Character Feld mit dem Namen zgr und ein Zei ger auf ein Feld mit einer Liste von Zeigern auf Character Felder f r die Speicherung von generellen Attributen zgr Die eigentlichen Daten folgen direkt im Anschlu entsprechend der im Header gespei cherten Anzahl k nnen nun beliebige Datenelemente in diese Struktur aufgenommen werden Dies schlie t selbstverst ndlich Zeiger ein die wiederum auf andere neue Datenobjekte der vierten Ebene zei gen k nnen Dadurch ist es m glich eine beliebige Datenstruktur in
149. nden Beispiel x y und z bekannt sein sowie die Felder xv yv und zv die Koordinaten enthalten ENGE er yy 2 float xv yv ZV DO_StructuredGrid grid grid new DO_StructuredGrid neuer Gittername xX Y Z XV YV ZV Sollten aus Gr nden der Speichereffizienz die Daten direkt f r den Shared Data Space erzeugt und in diesen geschrieben werden kann dazu die Routine get_addresses genutzt werden Der virtuelle Konstruktor Viele Anwendungsmodule lassen sich auf verschiedene Datentypen anwenden So kann man zum Beispiel eine Schnittebene durch ein strukturiertes Gitter oder durch ein unstrukturiertes Gitter legen Auch wenn das Ergebnis kaum zu unterscheiden sein mag erfordert ein unstrukturiertes Gitter einen deutlich aufwendigeren Algorithmus als ein strukturiertes Um jedoch nicht f r jeden Gittertyp einen eigenen Anwendungsmodul bereithalten zu m ssen was auch die bersichtlichkeit beeintr chtigen w rde und den Benutzer nur mit einer unn tigen Komplexit t verwirren w rde erlaubt man einem sol chen Modul einfach mehrere Datentypen f r den Eingang Das Modul mu dann allerdings eine M g lichkeit haben den Datentyp zu bestimmen und entsprechend in den geeigneten Algorithmus zu verzweigen Da mit der Startbotschaft vom Controller jedoch nur der Objektname bermittelt wird mu das Modul erst auf das Objekt im Shared Data Space zugreifen bevor er entscheiden kann mit welchem Datentyp er es zu tun hat Bei einem n
150. neenennee nen 82 32 A Fazit der Messungen an re re koe ae ave 88 Kapitel 6 Bewertung und Ausblick eeeeeeeeeseeeeeeeeeeeeeeeeeeeeeeeeeneeeennen 91 6 l CW CIs ee ea eg nee 91 62 Ausblick masse E EE 92 Kapitel 7 Uietaitseneeiee esse 95 Seite XI Seite XII Abbildungsverzeichnis Abbildung 1 1 Abbildung 2 1 Abbildung 2 2 Abbildung 2 3 Abbildung 2 4 Abbildung 3 1 Abbildung 3 2 Abbildung 3 3 Abbildung 3 4 Abbildung 4 1 Abbildung 4 2 Abbildung 4 3 Abbildung 4 4 Abbildung 4 5 Abbildung 4 6 Abbildung 4 7 Abbildung 4 8 Abbildung 4 9 Abbildung 4 10 Abbildung 4 11 Abbildung 4 12 Abbildung 5 1 Abbildung 5 2 Abbildung 5 3 Abbildung 5 4 Abbildung 5 5 Abbildung 5 6 Die Vistalisiertingspipe ine nen 2 Die COVISE System Architektur aaa za ana 8 Bildschirmabzug der COVISE Benutzungsschnittstelle _ 220 eeeeeeeees 9 Eine Anfrage ber den Object Request Broker ORB ee 11 Komponenten des integrierten Programmsystems RSYST 12 Die Kommunikation von AVS na 18 Datentransfer bei AVS ber Rechnergrenzen hinweg uensensensernnee een 19 Die Systemarchitektur des IRIS Explorer 2002224022042 20er nee snnennnnennnnn een 22 Kommunikation des IBM Data Explorer u 22u00220s2nersnnersnneennennnnennnen een 23 Die COVISE Systemarchitektur un neigen 27 l kaler Datenaustausch asus namen 28 Nicht Lokaler Datenaustausch
151. nenten 4 5 High Performance Komponenten Die Entwicklung der ganzen COVISE Umgebung erfolgte unter den Vorgaben eines Arbeitsumfel des das von der Rechenleistung tiber I O Bandbreite und Vernetzung bis hin zur Graphikleistung von h chster Leistungsf higkeit gepr gt ist Die Supercomputer die am Rechenzentrum der Universit t Stuttgart zur Verf gung standen waren anfangs eine Cray 2 mit 4 Prozessoren und 2 Gigabyte Haupt speicher sp ter eine Cray C94 mit 4 Prozessoren und 8GB und heute eine NEC SX4 mit 32 Prozessoren a 2 GigaFLOPS und 8 GB statischem SSRAM und 16 GB dynamischen DRAM Hauptspeicher sowie eine Cray T3E von SGI mit 512 Prozessoren und 64 GB Hauptspeicher Als File Server diente eine Cray M92 mit verschieden schnellen Dateisystemen bis zu 50 MB s und Migrationsm glichkeit auf einen Bandroboter An Netzwerken standen au er dem blichen Ethernet zur Verf gung Ultranet FDDI HIPPI und ATM bis zu 622 MBit s Als Graphikworkstations dienten mehrere Silicon Graphics Rechner bis hin zu einer Onyx2 Infinite Reality mit 14 Prozessoren und 4 GB Hauptspeicher Gemeinsam ist all diesen Komponenten da es in der Regel einiger Anstrengung bedarf die optimale Leistung zu erreichen Dabei ist es leider selbstverst ndlich da die von den Herstellern genannten Lei stungsdaten nur in Ausnahmef llen erreicht werden k nnen Besonderes Anliegen bei der Entwicklung von COVISE war daher dem Benutzer ohne zus tzlichen Aufwand sov
152. nformationen des Datenobjektes zum Teil in das Zugriffsdatenob jekt bertragen oder die Zeiger des Zugriffsdatenobjektes initialisiert bertragen wird beispielsweise die Versionsnummer des Datenobjektes ndert sich diese im Shared Data Space wird vor dem n chsten Zugriff eine Neuinitialisierung der Zugriffselemente durchgef hrt Die Zeiger f r das Zugriffselement der Attribute wird initialisiert Wurde das Zugriffsdatenobjekt schon einmal initialisiert wird die der Methode restore_shared sehr hnliche Methode update_shared verwendet um das Zugriffsdatenobjekt auf den neuesten Stand zu bringen Normalerweise wird die Methode restore_shared aus einem Konstruktor heraus aufgerufen befindet sich damit also im Einflu bereich des Programmierers des neuen Datentypes Manchmal kann es jedoch auch n tig sein diese Methode aus einem Teil des Systems aufzurufen auf den der Modulprogrammierer keinen Zugriff hat Dies ist zum Beispiel der Fall wenn verschachtelte Datenobjekte angelegt oder rekonstruiert werden Dabei wird die Methode restore_shared rekursiv auf dem geschachtelten Datenobjekt aufgerufen Innerhalb der restore_shared Methode des anderen Datentyps ist zum Zeitpunkt des Kompilierens nicht unbedingt bekannt um was f r ein Datenobjekt es sich handelt da dies auch von einer Benutzereingabe abh ngen kann Die Argumente die f r die Methode restore_shared des Datenobjekt in der Schachtelung gebraucht werden sind dahe
153. nitialisierung der Zugriffselemente neu schreiben mu wurde diese Funktionalit t in die Basisklasse Distributedobject verlagert Dazu dienen in der Basisklasse drei Funktionen int store_shared int count int restore_shared int count virtual int rebuild_from_shm Die beiden Funktionen store_shared und restore_shared sind einander recht hnlich Sie erwarten als Argumente zun chst eine Zahl die die Anzahl der folgenden Argumente enth lt Mit diesen Argumenten teilt der Programmierer dem System mit welche Datentypen die Klasse enth lt und welche Adressen die Zugriffselemente haben store_shared Die Methode store_shared wird benutzt um ein neues Datenobjekt erstmals anzulegen Im Fall der Klasse DO_StructuredGrid sieht der Aufruf von store_shared folgenderma en aus store_shared 6 INTSHM amp x_disc INTSHM amp y_disc INTSHM amp z_disc FLOATSHMARRAY amp x_coord FLOATSHMARRAY amp y_coord FLOATSHMARRAY amp Zz_coord Zur Beschreibung der Datenelemente eines Datenobjektes f r ein strukturiertes Gitter braucht man sechs Argumente drei Integer f r die Feldgr en und drei Felder von Floats f r die Gitterkoordinaten Innerhalb der Methode store_shared wird nun der ben tigte Speicherplatz sowohl f r das Datenob jekt selbst inklusive seines Headers als auch f r die Felder bestimmt und mit der Bitte um die Erzeu gung eines neuen Objekts und Zuweisung des dazugeh rigen Speicherpl
154. nntnis ber die Verteilung der vorausgehenden oder nachfolgenden Module n tig ist Nachdem nun die Module keinerlei Information ber die Lokalisierung der Daten ben tigen mu eine entsprechende Instanz eingef hrt werden die diese Information verwaltet und daf r sorgt da alle Module direkt auf die jeweils ben tigten Daten zugreifen k nnen In einem verteilten System mu diese Instanz den berblick ber alle im System vorhandenen Datenobjekte haben Dar berhinaus mu sie in der Lage sein jede Anfrage eines Moduls nach einem entsprechenden Datenobjekt zu bearbeiten und dem Modul die gew nschten Daten bereitzustellen In Anlehnung an hnliche Mechanismen wird diese Instanz im folgenden Request Broker genannt Die Arbeit dieses Request Brokers besteht also im wesentlichen aus zwei Teilen e aus Modulsicht mu das Datenobjekt zugreifbar sein d h der Request Broker mu auf Anfrage das Datenobjekt zur Verf gung stellen und dem Modul mitteilen wo es zu finden ist e aus Sicht des Request Brokers mu eine Datenverwaltungsfunktion vorhanden sein die erlaubt die Anfragen der Module zu bearbeiten Aus Modulsicht mu der Zugriff auf die Datenobjekte in einer Weise gestaltet werden da der Modulprogrammierer m glichst ohne Umwege auf die gew nschten Dateninhalte zugreifen kann Man kann in diesem Zusammenhang von einem sogenannten Datenzugriffsinterface sprechen Dieses Inter face mu die folgende Funktionalit t abdecke
155. nobjektes in den Grunddatentypen und der Name des zu erzeugenden Datenobjekts an den Request Broker bermittelt Dieser stellt sicher da kein gleichnamiges Datenobjekt existiert sucht dann in seinem Shared Data Space nach entsprechenden Bereichen setzt das Datenobjekt im Shared Data Space daraus zusammen und sendet anschlie end des sen Adresse in einem proze unabh ngigen Format an den Lesemodul zur ck Mit Hilfe dieser Informa tion wird dann ein lokales Datenobjekt erzeugt ber dessen Methoden der Zugriff des Lesemoduls auf die Daten im Shared Data Space erfolgt Nun kann der Lesemodul die gelesenen Daten in den Shared Data Space schreiben und abschlie end eine Finishmessage an den Controller zur ckschicken Der Controller sendet nun an den darauffolgenden Filtermodul wiederum eine Startmessage die neben den modulspezifischen Parametern den Namen des Datenobjektes enth lt das der Filtermodul als Eingabedaten ben tigt Dieser erzeugt nun ein lokales Datenobjekt das ihm den Zugriff auf die Daten im Shared Data Space erm glicht Dazu wird einfach der Name des gew nschten Datenobjektes an den Request Broker geschickt dieser sucht die Adresse des dazugeh rigen Speicherbereiches im Shared Data Space und schickt diese an den Filtermodul zur ck Das lokale Datenobjekt kann nun seine Zugriffsmethoden so initialisieren da die richtigen Speicherbereiche angesprochen werden Der Filter modul kann daraufhin mit seiner eigentlichen Arbeit beg
156. ntsprechen die beim Zugriff eines Moduls auf ein bereits existierendes Objekt n tig sind Diese werden im n chsten Abschnitt mitbehandelt Zugriff auf ein bereits existierendes Datenobjekt F r den Fall da ein bereits existierendes Datenobjekt von einem Modul direkt zugegriffen werden soll mu das Modul nur den Namen dieses Datenobjektes kennen Ist zus tzlich zum Namen auch der Datentyp des Datenobjektes bekannt ruft das Modul einfach den Konstruktor f r diesen Datentyp auf und bergibt als Parameter den Namen Dieser Name wird dann mittels einer Message an den Request Broker geschickt der in seinem internen Objektbaum nach diesem Namen sucht Findet er einen Eintrag Seite 38 4 2 Die Datenobjekte so schickt er die Adresse des Datenobjektes an den Modul zuriick Der Kenntnisstand des Moduls ist jetzt der gleiche wie bei der Erzeugung eines neuen Objektes am Ende des vorigen Abschnittes das Modul kennt den Datentyp und hat eine Adresse im Shared Data Space Als erstes wird jetzt die Typidentifikation an der ersten Stelle der Repr sentation des Datenobjektes im Shared Data Space mit der des aufrufenden Datentypkonstruktors verglichen Stimmt der Typ nicht berein wird der Zugriff mit einem Fehler abgebrochen Ansonsten werden einige der Informationen aus dem Header in eine interne Datenstruktur kopiert Da unter diesen Bedingungen die Anzahl und der Typ der Datenelemente des Objektes bekannt sind lassen sich diese nun nacheinande
157. nur die speziellen Implementierungen in der Soft ware sondern auch die zum Teil u erst aufwendige Suche nach den optimalen Konfigurationen Nur durch den engen und guten Kontakt zu den jeweils zust ndigen Mitarbeitern des Rechenzentrums lie en sich viele Parameter optimal einstellen und der jeweils beste Weg finden dazu z hlt unter anderem auch das Routing bei Vorhandensein mehrerer Netzwerkinterfaces F r einen Benutzer au erhalb eines Rechenzentrums d rfte sich dieser Optimierungsvorgang noch wesentlich schwieriger gestalten Dies sollte jedoch nicht als Abschreckung f r Benutzer gesehen werden sondern vielmehr als Aufforderung an die Rechenzentren und die Hersteller der High Performance Komponenten die enorme Leistung die in ihrer Ausstattung steckt auch den au enstehenden Benutzern optimal zur Verf gung zu stellen Seite 89 5 Resultate Seite 90 Kapitel 6 Bewertung und Ausblick 6 1 Bewertung In dieser Arbeit werden zwei Gebiete in Verbindung gebracht die normalerweise nicht sehr viel mit einander zu tun haben Datenbanken und Visualisierung Die Visualisierung besch ftigt sich damit aus Daten Informationen einem Betrachter in der bestm g lichen Weise zug nglich zu machen Das wird deutlich in dem bekannten Spruch ein Bild sagt mehr als tausend Worte bertragen auf die Visualisierung der Ergebnisse komplexer numerischer Berechnungen sagt ein Bild mehr als eine Milliarde Zahlen Auf der anderen Seite stehen
158. nz Persistenz aus dem lateinischen bersetzt bedeutet Bestehenbleiben eines Zustandes ber l ngere Zeitr ume Bezogen auf die Fl chtigkeit einer Information im Hauptspeicher eines Computers wenn der Strom ausf llt ist auch die Information verloren und auch auf die durch die Laufzeit eines Program mes beschr nkte Lebensdauer dieser Information bedeutet Persistenz in diesem Zusammenhang Persistente Objekte sind Objekte die eine andauernde Existenz haben d h eine Existenz deren Dauer nicht durch das Ende einer Programmausf hrung begrenzt ist 58 Dar berhinaus ist Persistenz f r die anderen Eigenschaften eines Datenobjektes nicht von Bedeutung Persistente Objekte unterscheiden sich bez glich anderer Eigenschaften wie z B Zustand Verhalten oder Klassenzugeh rigkeit nicht von nichtpersistenten Objekten 53 In einer Objekt orientierten Umgebung l t sich diese Unabh ngigkeit besonders einfach dadurch deutlich machen da Persistenz eine Eigenschaft ist die mit der Basisklasse also der Klasse von der alle Datenobjekte abgeleitet werden verbunden ist D h die Persistenzeigenschaft kann einem beliebi gen Datenobjekt dadurch verliehen werden da man sie ihrer Basisklasse verleiht 4 3 2 Auswirkungen der Persistenz Bei herk mmlichen dem Paradigma des visuellen Programmieren und des Datenflu netzwerkes fol genden Applikationen bestehen zwischen den einzelnen Modulen Verbindungen ber die die Da
159. odellbanksystem die Integration von Programmen und Daten in Ingenieurs und wissenschaftlichen Berechnungen zum Ziel hat 24 36 53 73 Bei RSYST handelt es sich nicht um eine Datenbank im herk mmlichen Sinne Vielmehr ist die Datenbasis in RSYST die zentrale Komponente um die herum die brigen Teile angelegt sind der Benutzer baut eine Folge von Modulen auf die ihre Daten ber eine Datenbank austauschen Die Daten stehen also ganz zentral und die einzelnen Funktionen die der Benut zer ausf hren m chte werden auf sie angewandt RSYST ist im Kern ein monolithisches nicht verteiltes System die verschiedenen Komponenten in Abbildung 2 4 entsprechen daher nicht verschiedenen Pro zessen Methoden und Dialogsystem Modellbank Programmsystem Ablauf Informations Datenbank Steuerung System Abbildung 2 4 Komponenten des integrierten Programmsystems RSYST Die Ans tze RSYST auf verteilte Umgebungen anzupassen basierten auf dem sogenannten Remote Procedure Call das hei t Funktionen auf anderen Rechnern werden ber eine bestimmte Schnittstelle hnlich Programm internen Funktionen aufgerufen 14 63 Die Daten die mit diesen Funktionen aus getauscht werden werden in Form von Argumenten bergeben Die Datenbasis bleibt dabei lokal es ist Seite 12 2 4 RSYST kein direkter Zugriff vom Rechner auf dem die Funktion ausgef hrt wird auf die Daten in der D
160. odul geben der aus den partitionierten Objek ten wieder ein ganzes Objekt erstellt das dann von den weiteren Modulen standardm ig weiterverarbei tet werden kann Die Gr e dieses Objektes mu allerdings f r den benutzten Rechner geeignet sein Dies kann insbesondere bei der Berechnung von Isofl chen problematisch sein da diese abh ngig vom benutzerdefinierten Isowert entweder sehr klein bis hin zu einer leeren Isofl che oder aber in dersel ben Gr enordnung wie der urspr ngliche Datensatz sind Daher wird man in solchen F llen von einer durchgehend partitionierten Verarbeitung ausgehen das hei t ein Modul reicht jede Partition die er bearbeitet hat sofort an den n chsten Modul weiter Erst im letzten Modul einer Anwendung in der Regel im Darstellungsmodul werden dann die Partitionen zu einem Gesamtobjekt zusammengebaut dies mu allerdings nicht ein Datenobjekt im Shared Data Space sein sondern kann auch ganz einfach die interne Geometrierepr sentation des Renderers sein Performance Verbesserung Die Partitionierung von Objekten kann sich auch ohne die Nutzung eines massiv parallelen Rechners als sinnvoll erweisen Der wesentliche Vorteil besteht bei einem solchen Szenario darin da der Benut zer fr her erste Darstellungen erh lt Geht man von der Standardsituation aus in der eine Datei eingelesen die Daten bearbeitet und anschlie end dargestellt werden sollen so ergibt sich normalerweise folgendes Bild di
161. ormalen Zugriff bei dem das Modul wei um welchen Datentyp es sich handelt ruft er einfach den Konstruktor der entsprechenden Klasse mit dem Namen des Datenob jektes auf siehe oben Weil er aber in diesem Fall noch nicht wei um was f r ein Datenobjekt es sich handelt mu es eine andere M glichkeit geben Seite 64 4 6 Wesentliche Strategien der Implementierung Praktisch w re es wenn in diesem Fall das Prinzip der virtuellen Funktionen in C auch fiir den Konstruktor gelten w rde der Modulprogrammierer ruft einfach einen generellen Konstruktor auf der im weiteren Verlauf feststellt um welchen Datentyp es sich handelt und dann automatisch den Konstruk tor dieses Datentypes aufruft und das passende Datenobjekt zur ckliefert Leider funktioniert dieses Prinzip des virtuellen Konstruktors nicht es mu also eine andere L sung gefunden werden Eine zwar insgesamt nicht ganz so einfache aber f r den normalen Modulprogrammierer d h jemand der nur mit den vorgefertigten Datentypen arbeitet quasi identische M glichkeit wurde mittels einer statischen Liste der vorhandenen Datentypen geschaffen Dazu mu sich jeder Datentyp der dyna misch erkannt werden soll zur Kompilierzeit in diese Liste eintragen Dazu liefert er seine Typ Identifi zierung und die Adresse einer Funktion die einen Konstruktor dieses Datentyps mit dem Namen des Objektes als Argument aufrufen kann und tr gt dieses Paar in diese Liste ein Trifft nun der Modu
162. ormen m glich so das dieser zwar etwas umst ndlichere aber daf r portable Weg gew hlt wurde Der Programmierer eines neuen Datentypes mu dar berhinaus noch die Methode die den Konstruktor aufruft schreiben und seinen Datentyp in der statischen Liste quasi registrieren Seite 65 4 Konzept eines verteilten Visualisierungssystems Seite 66 Kapitel 5 Resultate Wie bereits in der Einleitung erw hnt ist die in dieser Arbeit vorgestellte Datenverwaltung Teil eines verteilten und kollaborativen Visualisierungssystemes COVISE Das Ausgangsprojekt PAGEIN Pilot Applications in a Gigabit European Integrated Network hatte zum Ziel kollaboratives Arbeiten in der Predesign Phase der Entwicklung eines Flugzeugs einzuf hren und die daf r n tigen Werkzeuge bereit zustellen Die Projektpartner Daimler Benz Aerospace Airbus Aerospatiale British Aerospace und Defense Research Agency lieferten daf r das Anwenderszenario DLR NLR ONERA und CIRA waren zusammen mit dem RUS f r die Durchf hrung verantwortlich genauer gesagt f r die Entwicklung der n tigen Werkzeuge 49 50 Das Szenario des PAGEIN Projektes bestand aus der kollaborativen Analyse einer Simulation die auf einem Supercomputer l uft Das hei t es waren zun chst einmal die Grundz ge eines verteilten Systems zu analysieren und ein Rahmenwerk zur Verf gung zu stellen in dem die gestellte Aufgabe angegangen werden konnte Eine Analyse der Bed rfnisse und der bereits exi
163. phics Workshop on Visualiza tion in Scientific Computing Abingdon UK April 1993 Wierse A Lang U R hle R A System Architecture for Data oriented Visualization Database Issues for Data Visualization Lecture Notes in Computer Science Volume 871 pp 148 159 Lee Grinstein Eds Springer 1994 Wierse A Performance of the COVISE visualization system under different conditions in Visual Data Exploration and Analysis II Georges G Grinstein Robert F Erbacher Editors Proc SPIE 2410 218 229 1995 Wierse A Lang R Lang U Nebel H Rantzau D The Performance of a Distributed Visualization system Visualization Methods in High Performance Computing and Flow Simulation W Borchers G Domik D Kr ner R Rautmann D Saupe VSP International Science Publishers Zeist 1996 Wierse A Grinstein G G Lang U Eds Database Issues for Data Visualization Lec ture Notes in Computer Science Volume 1183 Proceedings IEEE Visualization 95 Work shop Atlanta Springer Verlag Berlin 1996 W ssner U Implementierung von Visualisierungsmethoden f r unstrukturierte Gitter in einer Multi Block Umgebung Studienarbeit im Fach Angewandte Informatik Rechenzen trum der Univsersit t Stuttgart 1996 W ssner U Rantzau D Rainer D Interactive Simulation Steering in VR and Handling of Large Datasets in Proceedings of the IEEE Youth Forum in Computer
164. plete Aircraft Lecture Notes in Compu ter Science W Gentzsch U Harms Vol 797 pp 60 69 Springer Berlin 1994 R hle R RSYST Ein Softwaresystem zur Integration von Daten und Programmen zur Simulation wissenschaftlich technischer Systeme Rechenzentrum der Universit t Stuttgart RUS 5 M rz 1990 Rumbaugh J Blaha M Premerlani W Eddy F Lorensen W Object Oriented Mode ling and Design Prentice Hall Englewood Cliffs 1991 Rumpf M Schmidt A et al GRAPE GRaphics Application and Programming Environ Seite 97 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 7 Literatur ment SFB256 No 8 Bonn 1989 Scateni R van Wijk J Zanarini P Eds Visualization in Scientific Computing 95 Springer Verlag Wien 1995 Schlecht B Entwurf und Implementierung eines interaktiven anwendungsunabh ngigen Grafiksystems Forschungs und Entwicklungsberichte RUS 3 Rechenzentrum der Universi t t Stuttgart 1989 Schmidt D Persistente Objekte und objektorientierte Datenbanken Carl Hanser Verlag M nchen Wien 1991 Schroeder W Lorensen W Montanaro G Volpe C VISAGE An Object Oriented Scientific Visualization System Visualization 92 Proceedings Boston MA Schroeder W Martin K Lorensen W The Visualization Toolkit An Object O
165. press in Konkurrenz zu treten sondern vielmehr mit ihnen zusammenzuarbeiten wo es sinnvoll ist und sie zu erg nzen wo die St rken der hier realisierten Daten bank orientierten Datenverwaltung wie z B schnelle Verf gbarkeit auch auf exotischen Rechnern wie der Cray T3E oder der NEC SX4 sowie die effiziente Ausnutzung dieser teuren Rechner zum Tragen kommen Auch die Integration mit echten relationalen oder objekt orientierten Datenbanken ist bislang noch nicht weiter verfolgt worden Hierbei ergeben sich interessante Kombinationsm glichkeiten mit lokalen oder ebenfalls verteilten Datenbanken und der Unterst tzung von Visualisierungsfunktionalit t sowohl f r die Visualisierung von Daten in den Datenbanken als auch der Strukturen dieser Datenbanken Die Leistungsf higkeit des hier pr sentierten Ansatzes ist sicher noch nicht ausgesch pft so da sich ein gro es Feld an weiteren Aufgaben finden l t die von diesem Ansatz profitieren k nnen Wesentlich ist dabei da das inh rent Datenverwaltungs orientierte Konzept es sehr leicht macht mit Datenbanken und ihrer Funktionalit t zusammenzuarbeiten und dabei auch die enge Integration mit der Anwendung unterst tzt Seite 93 6 Bewertung und Ausblick Seite 94 Kapitel 7 Literatur 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Abram G Treinish L An Extended Data Flow Architecture for Data Analysis and Vis
166. r f r den Zugriff vorbereiten Dabei k nnen in einer solchen Elementliste nur Datentypen der Ebenen eins und drei vor kommen Einzelelemente und Zeiger Die Vorbereitung sieht bei den verschiedenen Datenelementen folgenderma en aus 1 Bei den Datenelementen der Ebene eins wird ein Zeiger auf die tats chliche Speicheradresse gelegt Zugriffe auf dieses Datenelement werden durch Operator Overloading wie eine normale Zuweisung in der Programmiersprache C gehandhabt in beiden Richtungen f r Implementie rungsdetails siehe Abschnitt 4 6 2 Ist das n chste Datenelement ein Zeiger so wird dieser verfolgt und abh ngig von dessen Typ weiterbearbeitet auch hier wird die Zul ssigkeit des Typs berpr ft W Felder der Ebene zwei werden hnlich gehandhabt wie die Datenelemente der Ebene eins auf den Beginn des eigentlichen Datenbereiches vorher stehen der Typ und die Anzahl der Elemente wird ein Zeiger gerichtet Auch hier kann durch Operator Overloading ein sehr nat rlicher Zugriff auf die Feldelemente angeboten werden der insbesondere auch berpr ft ob der Index auch im zul ssigen Bereich liegt Allerdings ist es f r die Performance vorteilhaft direkt unter Umgehung dieses Mechanismus auf das Feld zuzugreifen Dazu kann sich der Modulprogrammierer einen Zeiger direkt auf die Feldelemente geben lassen In Abbildung 4 5 ist dieser direkte Zugriff ber den Feld Eintrag zu erkennen der direkt einen Zeiger auf die Daten enth lt f
167. r nicht bekannt rebuild_from_shm Um dieses Problem zu l sen gibt es in der Basisklasse DistributedObject eine virtuelle Methode rebuild_from_shm F r jede von Distributedobject abgeleitete Klasse mu der Pro Seite 62 4 6 Wesentliche Strategien der Implementierung grammierer eine Methode rebuild_from_shm zur Verf gung stellen Diese Methode enth lt im Prin zip nichts anderes als einen Aufruf der Methode restore_shared mit den fiir dieses Zugriffsdatenobjekt passenden Argumenten Dadurch da diese Methode virtuell ist wird sichergestellt da auch wenn sie von einer Stelle aufgerufen wird an der der eigentliche Datentyp der zu diesem Datenobjekt geh rt unbekannt ist die restore_shared Methode mit den richtigen Argumenten auf gerufen wird Durch einen Aufruf der Methode rebuild_from_shm wird jederzeit die richtige restore_shared Methode aufgerufen egal ob sie ber einen Zeiger auf den richtigen Datentyp oder auf die Basisklasse DistributedObject aufgerufen wird In hnlicher Weise k nnen die Programmierer eines neuen Datentypes auch Informationen f r die Darstellung eines Datenobjektes in der Benutzeroberfl che liefern Dazu gibt es in der Basisklasse eine virtuelle Methode get_class_object_info Als Argument wird eine Zeiger auf eine Liste von Zei chenketten geliefert die dann abh ngig vom konkreten Datentyp allokiert und mit den entsprechenden Informationen gef llt wird Zugriff auf die Daten f r d
168. rbeit gegeben Dabei kann abh ngig vom Algorithmus und den vom Benutzer gew hlten Parametern eine nicht vorher sehbare Auslastung der Prozessoren erfolgen e bei der Bestimmung einer Isofl che in einem dreidimensionalen Gitter wird in der Regel das Gebiet komplett durchlaufen da sich nicht von vorneherein bestimmte Partitionen ausschlie en lassen e bei der Bestimmung der Schnittebene durch ein dreidimensionales regelm ig partitioniertes strukturiertes Gitter l t sich an Hand der Eckkoordinaten einer Partition direkt feststellen ob die gesuchte Schnittfl che die Partition schneidet oder nicht e soll die Verfolgung einer Partikelbahn berechnet werden so h ngt die Nutzung der verschiedenen Partitionen daf r sowohl vom Startwert den der Benutzer angibt als auch von der numerischen L sung ab In der Regel ergibt sich hierbei eine absolut ungleichm ige Auslastung der Prozesso ren Findet die Weiterverarbeitung auf der Workstation statt so ergeben sich hnliche Konstellationen mit allerdings teilweise unterschiedlicher Bedeutung Da die Workstation in der Regel ber deutlich weniger Hauptspeicher verf gt wird sie die Bearbeitung partitionierter Objekte st ckweise das hei t Partition f r Partition vornehmen F r den Fall der Isofl che und der Schnittebene ergibt sich im wesentlichen der gleiche Ablauf wie bei der Weiterverarbeitung auf dem Parallelrechner f r jede Partition kann direkt die Bestimmung der Isofl chentei
169. rch alle Partitionen hindurchbewegen was zu einem permanenten Suchen und Neuladen von Partitionen f hren w rde Der Aufwand lie e sich etwas reduzieren wenn die Nachbarschaftsinformation zu den einzelnen Partitionen vorhanden w re man also nicht mehr suchen sondern nur noch nachladen m te 0 1 Abbildung 4 7 Uneindeutigkeiten bei Marching Cubes Bei der Isofl chenberechnung ist nicht gleich zu erkennen warum es sich unter Umst nden um eine nichtlokale Aktion handelt Dies liegt aber im meist benutzten Isofl chenalgorithmus dem Marching Cubes 40 80 begr ndet Vereinfacht ausgedr ckt wird bei diesem Algorithmus nach den Werten in den Eckpunkten geschaut und dann abh ngig vom gegebenen Iso Wert untersucht ob eine Verbindungs kante von der Isofl che geschnitten wird Aus den Schnittpunkten wird dann ein Fl chenst ck gebildet das mit allen anderen Fl chenst cken die Isofl che bildet Dies ist offensichtlich ein lokaler Vorgang da kein Nachbarelement betroffen ist Unter gewissen Umst nden kann es jedoch zu nicht eindeutigen Kon stellationen kommen In Abbildung 4 7 ist eine solche Konstellation zu sehen Dargestellt ist der Blick auf die Seitenfl che eines Hexaeders der an die Nachbarpartition grenzt Bei einem Isowert von 0 5 und den dargestellten Daten in den Eckpunkten ergeben sich zwei M glichkeiten die Isofl che durch die Randseite fortzusetzen Hierin liegt auch die Nichtlokalit
170. ren u a Vektorisierung die Nutzung anderer Floating Point Formate oder auch das Fehlen solcher von Workstations her vertrauten Dinge wie Shared Memory Die Vorteile der Vektorregister bestehen darin da eine gr ere Anzahl von gleichen Befehlen die auf verschiedenen zusammenh ngenden Daten in der Regel Felder angewendet werden sehr effizient ablaufen Dazu wird eine gewisse Menge dieser Daten abh ngig von der L nge der Vektorregister in diese Vektorregister geladen und anschlie end dieser eine Befehl auf dem gesamten Vektorregister auf einmal ausgef hrt Meist werden diese verschiedenen Stufen Laden Dekodieren Ausf hren etc ber lappend ausgef hrt d h w hrend ein Befehl auf einem Vektorregister ausgef hrt wird wird parallel schon der n chste Befehl vorbereitet In der Regel handelt es sich bei diesen Befehlen um Additionen Seite 51 4 Konzept eines verteilten Visualisierungssystems oder Multiplikationen d h die Vorteile der Vektorisierung kommen besonders bei numerischen Simula tionen zur Geltung Aber auch einfache Vorg nge wie das Kopieren von Feldern k nnen mit Hilfe der Vektorisierung deutlich beschleunigt werden Datenkonvertierung Ebenfalls von der Vektorisierung profitiert die Konvertierung von Daten Die Cray Vektor Super computer benutzen nicht das in der Workstationwelt vorherrschende IEEE Floating Point Format son dern ein Cray spezifisches Um diese Daten auf der Workstation weiterverarbeiten zu
171. riented Approach to 3D Graphics Prentice Hall Upper Saddle River NJ 1996 Schroeder W Martin K Lorensen W The Design and Implementation of An Object Oriented Toolkit For 3D Graphics And Visualization in Yagel R Nielson G M Eds Visualization 96 Proceedings pp 93 100 IEEE Computer Society Press Los Alamitos 1996 Seybold J Angewandte objektorientierte Modellierung von Mehrk rpersystemen fiir die parametrische Visualisierung dynamische Simulation und Optimierung Forschungs und Entwicklungsberichte RUS 40 Rechenzentrum der Universitat Stuttgart 1998 Seybold J Spezifikation und Implementierung eines Moduls DFNMDL zur Verteilung von RSYST Moduln auf verschiedene Plattformen Interne Mitteilung Rechenzentrum der Uni versit t Stuttgart 1996 Seybold J R hle R Biomechanische Computersimulation und Visualisierung in Arbeitsgemeinschaft Simulation in der Gesellschaft f r Informatik ASIM Mitteilungen aus den Arbeitskreisen Heft Nr 46 pp 105 116 Otto von Guericke Universit t Magdeburg 1995 Sloman M Ed Network and Distributed Systems Management Addison Wesley Wor kingham England 1994 Spaniol O Betriebserfahrungen und Messungen an einem gro en FDDI Netz und sich daraus ergebende Konsequenzen in Encarnagao J Telekommunikation und multimediale Anwendungen der Informatik pp 22 34 Springer Verlag Berlin 1991 Stevens A
172. ritt Filter Mapper Renderer Display aus einer Vielzahl von ver schiedenen Algorithmen den f r seine Visualisierung n tigen aus Es gen gt jedoch nicht die zu ver wendenden Algorithmen auszuw hlen vielmehr mu der Benutzer dem System auch noch genau mitteilen in welcher Reihenfolge die Module die die Algorithmen ausf hren abgearbeitet werden sol len und wie die Ergebnisse eines Moduls zum n chsten Modul gelangen Dazu sind die Module mit sogenannten Eingabe und Ausgabeports versehen An den Eingabeports werden die Daten angeliefert die der Modul braucht um seine Arbeit auszuf hren Die Resultate seiner Arbeit stellt er dann an den Ausgabeports zur Weiterverarbeitung zur Verf gung Durch Verbinden von Ausgabe und Eingabeports bestimmt der Benutzer nun welche Daten von welchem Modul verarbeitet werden Betrachtet man nun das gesamte Szenario so baut der Benutzer aus den Modulen und durch das Ver binden der Ports ein Flu diagramm auf das seinen Visualisierungswunsch ausf hrt In diesem Zusam menhang spricht man auch von einem Datenflu model Dataflow Model Viele Visualisierungspakete gehen sogar so weit den Ablauf dieses Netzwerkes ber diesen Datenflu zu steuern das hei t ein Modul beginnt dann mit der Ausf hrung wenn alle ben tigten Eingabeports mit Daten versorgt sind Wenn der Modul dann fertig ist stellt er seine Resultate an den Ausgabeports zur Verf gung was wie Seite 17 3 Vergleich mit existierender
173. rungssoftware COVISE geeignetes Kon zept f r die Integration von Visualisierung und Datenverwaltung zu entwickeln und zu realisieren 1 3 Gliederung der Arbeit Nach einer kurzen Vorstellung der COVISE Softwareumgebung und ihres Hintergrundes in Kapitel 2 wird ein berblick ber die gebr uchlichsten Visualisierungssysteme gegeben und deren Datenmanage ment und Eignung f r verteilte Visualisierung betrachtet dazu geh ren auch ein Blick auf die Daten bankszene und Mechanismen zur Verteilung von Daten und Objekten Kapitel 3 In Kapitel 4 wird das Konzept in allen Einzelheiten vorgestellt wobei auch auf die Probleme aus Kapitel 1 1 und die entspre chenden L sungen eingegangen wird Um zu zeigen da dieses Konzept auch in der Praxis funktioniert werden in Kapitel 5 dann Anwendungsbeispiele vorgestellt Zu der umfassenden Betrachtung dort geh ren auch die Ergebnisse von Messungen die unter realistischen Bedingungen auf Produktionsrechnern durchgef hrt worden sind In Kapitel 6 werden schlie lich die Ergebnisse dieser Arbeit diskutiert und ein Ausblick auf die weiteren Entwicklungsm glichkeiten gegeben Seite 5 I Einleitung Seite 6 2 1 COVISE Kapitel 2 Die COVISE Visualisierungs umgebung In diesem Kapitel wird ein kurzer Uberblick iiber die Historie von COVISE und seine Systemarchi tektur gegeben Dariiberhinaus werden zwei Software Entwicklungen vorgestellt die das in dieser Arbeit entwickelte Konzept wesentlich mit
174. schickt werden die durchaus auch auf einem anderen Rechner liegen kann Besonders deutlich wird dies wenn man sieht wie Visualisierungsvorg nge im allgemeinen beschrieben werden siehe auch Abbildung 1 1 Die Visualisierungspipeline es wird eine Prozedur beschrieben mit der man von einem Ausgangsdatenobjekt zu einem Bild gelangt Dabei stehen die Methoden im Mittelpunkt und nicht die als Zwischenrepr sentation entstehenden Objekte Ein weiterer Aspekt ist die Performance eines solchen verteilten Systems Damit ist noch nicht ein mal die generelle Performance von CORBA Implementierungen gemeint sondern vielmehr die speziell an die High Performance Umgebung anzupassenden Parameter z B von Netzwerkverbindungen Mes sungen siehe Abschnitt 5 2 haben ergeben da bei HIPPI Verbindungen die Standardparameter den maximalen Durchsatz auf knapp ber 10 des theoretisch m glichen Durchsatzes beschr nkten Bei der Optimierung der Verbindungsparameter konnten bis zu 70 des theoretisch m glichen Durchsatzes erreicht werden Das hei t selbst wenn f r die benutzten Rechner CORBA Implementierungen verf g bar gewesen w ren w re die Effizienz mit der diese Implementierungen die Infrastruktur ausnutzen unbefriedigend gering gewesen 2 4 RSYST Am Institut f r Kernenergetik und Energiesysteme und sp ter am Rechenzentrum der Universit t Stuttgart wird seit 1969 das Softwaresystem RSYST entwickelt das als offenes Daten Methoden und M
175. schlie t unter Umst nden auch eine graphische dreidimensionale Benut zeroberfl che ein so da der Benutzer direkt mit den Daten agiert 28 e einem Visualisierungssystem wird eine Schnittstelle zu einer Datenbank eingebaut Bei einem modularen System wird in der Regel ein Modul angeboten der die M glichkeit bietet ber eine Abfragesprache z B SQL eine Anfrage an eine Datenbank zu richten und mit den daraus resul tierenden Daten zu arbeiten Bei dem in dieser Arbeit vorgestellten Ansatz wird jedoch eine vollst ndige Integration dieser beiden Bereiche angestrebt Das interne Datenmanagement eines Visualisierungssystems wird mittels einer Datenbank orientierten Technik durchgef hrt Wie bereits erl utert handelt es sich hierbei nur um eine relativ einfache Datenbank hnliche Datenverwaltung dennoch entspricht die interne Datenhandhabung der einer normalen Datenbank damit ein Modul mit einem Datenobjekt arbeiten kann stellt es eine Anfrage an einen Request Broker der dann im Gegenzug das gew nschte Objekt bzw seine Adresse zur Verf gung stellt Zur Zeit ist diese Anfrage sehr einfach gehalten da ein Modul nur nach dem Namen eines Objektes fragen kann Es spricht aber nichts dagegen an dieser Stelle eine generelle Abfragem glichkeit einzu f hren die es sowohl Modulen erm glicht umfangreichere Abfragen zu stellen als auch dem Benutzer ber die Benutzerschnittstelle Weiterhin sind in dieser Arbeit bereits die zahlreiche
176. sich ein gesonderter Bereich nutzen der nicht notwendigerweise die Persistenzeigenschaft aufweisen mu aber durchaus kann um Sitzungen einfach unterbrechen und sp ter wieder fortsetzen zu k nnen Seite 42 4 4 Partitionierte Objekte 4 3 3 Vorteile der Persistenz Die zeitlichen Gr enordnungen in denen die Arbeitsabl ufe eines Ingenieurs stattfinden der nume rische Simulationen bearbeitet reichen von in der Regel einigen Stunden bis zu mehreren Wochen In Ausnahmef llen sind auch interaktive Berechnungen m glich dies h ngt jedoch stark von den verwen deten Super Computern ab Zur Zeit kann die Arbeitsweise zum Beispiel folgenderma en aussehen 1 der Nutzer erzeugt eine Geometrie auf der die Berechnung durchgef hrt werden soll 2 f r diese Geometrie wird ein Gitter erzeugt 3 die Randbedingungen f r die Berechnung werden bestimmt 4 die Berechnung wird durchgef hrt 5 die Ergebnisse der Berechnung werden ausgewertet d h visualisiert Zwischen den einzelnen Schritten m ssen Daten ausgetauscht werden was in der Regel ber Dateien erfolgt d h aus dem Programm zur Geometrie Erzeugung wird eine Datei mit den Geometriedaten geschrieben die vom Programm f r die Gittererzeugung eingelesen wird Durch die Nutzung persisten ter Objekte l t sich diese etwas umst ndliche Schnittstelle deutlich einfacher handhaben das Modul zur Geometrieerzeugung hat ein Ausgabedatenobjekt vom Typ Geometrie das als Eingabeobjekt f
177. sition von Lichtquellen oder Objekttyp abh ngige Parame ter wie den Isowert abzuspeichern In 62 wird ein Konzept zur Visualisierung von Mehrk rpersystemen mit RSYST als Integrationssy stem vorgestellt Hierbei werden verschiedene Komponenten gekoppelt die f r den Datenaustausch die RSYST Datenbasis verwenden Alle Module greifen auf die Datenobjekte die zwischen ihnen ausge tauscht werden ber diese Datenbasis zu Aus Geschwindigkeitsgr nden werden bei den Optimierungen die Datenobjekte sowie die Strukturinformationen im Hauptspeicher gehalten Um den Simulations und Optimierungsmodul der hier zur Anwendung kommt auch auf andere leistungsf hige Rechner ausla gern zu k nnen wird eine sogenannte Multiple Access Datenbank eingesetzt d h mehrere verteilte Berechnungsprogramme k nnen gleichzeitig auf dieselbe Datenbank zugreifen F r diese Verteilung von Modulen wird der Modul DFNMDL eingesetzt Dieser besteht aus drei Tei len der Initialisierung und dem Start beliebig vieler Module der Verbindung mit den im Wartestatus Seite 13 2 Die COVISE Visualisierungsumgebung befindlichen Modulen und dem Abbrechen der Verbindungen mit dem Beenden der Module Der DFN MDL Modul basiert auf dem DFNRPC eine vom DFN unterstiitzte Weiterentwicklung eines RPC 48 Ein RPC Werkzeug verteilt Anwendungen ber prozedurale Schnittstellen d h eine Funktion kann auf einen anderen Rechner ausgelagert werden Der RPC stellt dazu die n tigen Konv
178. st um klarzumachen da dieses Objekt noch gebraucht wird Vielmehr ist es so da ein Objekt das nicht mehr gebraucht wird explizit weggeworfen wird 4 4 Partitionierte Objekte 4 4 1 Definition der Partitionierung Partitionierte Objekte unterscheiden sich von den anderen Objekten dadurch da sie aus mehreren Teilen bestehen die unabh ngig voneinander bearbeitet werden k nnen siehe auch 10 Die Gesamt heit der Information ist jedoch nur dann vorhanden wenn alle Teile oder Partitionen eines Objektes zur Verf gung stehen Um ein sinnvolles Arbeiten auf einzelnen Partitionen zu erm glichen kann es n tig sein Informationen mehrfach in verschiedenen Partitionen vorzuhalten Ein einfaches Beispiel ist die Anwendung eines Isofl chen Algorithmus auf ein partitioniertes Gitter es ist unwesentlich ob es sich Seite 43 4 Konzept eines verteilten Visualisierungssystems hierbei um ein strukturiertes oder unstrukturiertes Gitter handelt der Einfachheit halber sei ein struktu riertes Rechteckgitter gegeben damit auf einem Element Hexaeder des Gitters die dieses Element durchschneidende Isofl che berechnet werden kann m ssen sowohl die Koordinaten als auch die Daten auf allen Eckpunkten des Elementes bekannt sein Sollte dieses Element auf dem Rand einer Partition liegen so ergibt sich ganz zwangsl ufig da auf dem angrenzenden Element der Nachbarpartition die Koordinaten und Daten auf den Randeckpunkten ebenfalls vorhanden s
179. st die hierarchische Struktur des Aufbaus der Datenobjekte anhand der Partikel bahn dargestellt Das Hauptobjekt ganz links ist vom Typ Geometrie dieser beinhaltet die reine Geome trieinformation eventuelle Normalen Farben und Texturen In diesem Beispiel sind nur die Geometrie und die Farben pr sent Das erste Unterobjekt der Geometrie ist eine Menge von Linien eine Partikel bahnberechnung hat hier f nf Partikelbahnen generiert die in einem Set Objekt zusammengefa t sind analog dazu ist auch das Unterobjekt f r die Farben hier nicht explizit dargestellt ein Set Objekt das f nf Elemente mit den entsprechenden Felder enth lt Jede Partikelbahn besteht aus einer Linie zweites Objekt von rechts die wiederum aus Punkten zusammengesetzt ist Objekt ganz rechts In der Darstel lung ist auch zu erkennen da zu jedem Objekt Attribute gesetzt werden k nnen In diesem Fall sind Seite 71 5 Resultate dies die Farbe der Partikelbahn sowie eine Feedback Information die es einem Renderer erlaubt die Position des Startpunktes direkt zu beeinflussen DataObject Collect_2 OUT_01 EZ DataObject TracerUSG_2 OUT_01 General General Type GEOMET ect TracerUSG_2_OUT_01_0_A DataObject TraceruUSG_2 OUT _01_0 Attributes CLOSE nel Abbildung 5 5 Datenobjekt Anzeige der Partikelbahn 5 1 3 Str mung in einem Saugrohr In diesem Fall wird die numerische Berechnung f r die Simulation der Wasserstr m
180. st wenn man vom verf gbaren Speicherplatz absieht dauert alleine der Transfer ber eine Ethernet Verbindung theoretisch 10 Mbit s etwa 13 Stunden Sogar bei der Nut Seite 2 1 2 Zielsetzung der Arbeit zung des zehnmal so schnellen FDDI braucht man noch deutlich ber eine Stunde um die Daten vom Supercomputer auf die Workstation zu laden Die logische Konsequenz in diesem Fall ist den Filterschritt auf den Supercomputer vorzuziehen Die Gesamtrechenzeit d rfte davon nicht wesentlich beeinflu t werden da hierbei keine umfangreichen Berechnungen anfallen Je nach Art der Visualisierung kann der Benutzer die Daten entsprechend redu zieren und mu nur noch die unbedingt n tigen Daten ber das Netz transportieren und auf seiner Work station speichern Je nach Komplexit t und Aufwand der Visualisierungsalgorithmen kann es selbstverst ndlich auch sinnvoll sein weitere Schritte der Visualisierungspipeline auf den Supercompu ter vorzuziehen 32 35 Als einfaches Beispiel mag hier die Berechnung einer Str mung auf einem massiv parallelen Super computer dienen F r die Simulation wird das Berechnungsgebiet mittels Gebietszerlegung in einzelne Bereiche gegliedert die dann jeweils von einem Prozessor bearbeitet werden Nach Abschlu der Berechnungen liegen die Ergebnisdaten auf dem entsprechenden Knoten vor Eine Isofl che l t sich nun am einfachsten berechnen indem man den Algorithmus auf jedem Knoten und den dort schon vor lie
181. steuert werden k nnen also im lokalen Fall als sicher gelten Der nicht lokale Fall Werden Datenobjekte auf einem anderen Rechner erzeugt als auf dem auf dem sie gelesen werden so ergibt sich eine zus tzliche Problematik die Existenz einer Kopie und die bereinstimmung mit ihrem Original Beim Standardablauf einer Anwendung wird die Kopie genau dann erzeugt wenn sie von einem lesenden Modul gebraucht wird d h auch hier ist sichergestellt da nicht gleichzeitig gele sen und geschrieben werden mu Daher wird einfach zum gegebenen Zeitpunkt eine Kopie des Objek tes auf dem zweiten Rechner erzeugt Um jedoch die volle Isolation auch im Falle mehrerer Request Broker garantieren zu k nnen m ssen die Locking Mechanismen ausgeweitet werden Dies l t sich am einfachsten dadurch erreichen da die bislang lokalen Vorg nge auf eine beliebige Anzahl von Request Brokern erweitert werden D h ein Zugriff auf eine Kopie eines Datenobjektes kann erst erfolgen nachdem der Request Broker der Kopie beim Request Broker des Originals sichergestellt hat da der Zugriff erlaubt ist Dadurch wird praktisch das Modell aus dem lokalen Fall dahingehend erweitert da nicht lokale Zugriffe auf quasi lokale Zugriffe reduziert werden Aus Gr nden der Systemperformance erscheint es jedoch sinnvoll ein wenig von diesem Modell abzuweichen Dabei ist der Fall da ein Datenobjekt erst noch kopiert werden mu sehr einfach zu handhaben mit dem Anlegen
182. stierenden Software auf diesem Gebiet f hrte zu dem in dieser Arbeit vorgestellten Design An dieser Stelle soll nicht erneut auf die Effizienzanforderungen die an ein solches Werkzeug gestellt werden eingegangen werden die bei der Entwicklung eines Flugzeuges in der Regel anfallenden Datenmengen erfordern zweifellos einen u erst effizienten Umgang mit Ressourcen aller Art Im Folgeprojekt ADONNIS A Demonstration Of New Network Interoperable Services ESPRIT Nr 9033 wurde mit Hilfe weiterer Partner u a Dassault und CASA die gesamte Software um zus tzli che Funktionalit t erweitert und an neue Anwendungsgebiete in diesem Fall die verteilte Entwicklung von Satelliten angepa t Die Zahl der auf COVISE und damit auch auf dem Datenverwaltungssystem dieser Arbeit aufsetzenden oder es weiterentwickelnden Projekte liegt inzwischen ber zehn Dazu z h len mehrere Projekte die eine Anpassung an die Bed rfnisse der Automobilindustrie zum Inhalt haben u a die Visualisierung von numerischen Simulationen der Vorg nge im Zylinder eines Verbrennungs motors oder von Crash Berechnungen Aus der Vielzahl der verf gbaren Anwendungen sollen drei exemplarisch herausgegriffen werden um an ihnen die Vorteile des Systems zu verdeutlichen 5 1 Anwendungsbeispiele 5 1 1 PEGASE Berechnung einer Wirbelaufl sung Der Numerikcode PEGASE von ONERA im Rahmen des PAGEIN Projektes zur Verf gung gestellt berechnet auf einem nicht quidistanten r
183. t auf der ausgelasteten Y MP wird selbst das Senden der relative klei nen Datenmenge noch vom Scheduling beeinflu t Auffallend ist jedoch da beim vierten bis sechsten Durchlauf trotz leerer Maschine bei der Konversion drastische Verz gerungen auftreten Seite 87 5 Resultate 5 2 4 Fazit der Messungen Diese Messungen miissen unter der Randbedingung beurteilt werden daB sie unter nicht exakt repro duzierbaren Bedingungen stattgefunden haben Auch lassen sich nicht alle Ph nomene und Besonderhei ten eindeutig erkl ren Allerdings besteht der Sinn dieser Messungen auch nicht darin absolute Performancewerte zu ermitteln die dann mit anderweitig gewonnenen verglichen werden sollen Viel mehr sollen diese Messungen beleuchten ob das Ziel ein Kommunikationswerkzeug zu schaffen das in der Lage ist High Performance Komponenten effizient zu nutzen verwirklicht worden ist Das bedeu tet da unter den Me ergebnissen insbesondere die Relation zwischen der Zeit die durch das Netzwerk verbraucht wird und der Zeit die f r die Vor und Nachbereitung des Datentransfers gebraucht wird relevant ist Nat rlich darf auch das Verh ltnis der Messungen unter optimalen Umst nden zu denen die unter den Standardbedingungen stattgefunden haben nicht vernachl ssigt werden Insbesondere die HIPPI Messungen sind ein deutliches Zeichen da es unerl lich ist sich mit den Parametern ausf hr lich zu besch ftigen um die teure Technik auch sinnvol
184. t fest da sich dieses Datenobjekt nicht in seinem Shared Data Space befindet 2 und 3 und bittet daraufhin den Request Broker der Indigo B um Zusendung dieses Objektes 3 und 4 Request Broker B sucht das Datenobjekt in seinen Strukturen und bereitet es f r den Transfer vor 4 und 5 Diese Vorbereitung besteht im wesentlichen aus dem Einpacken des Datenobjektes aus der Repr sentation des Datenobjektes im Shared Data Space wird es Element f r Element in einen Puffer kopiert der dann den Systemfunktionen f r das Senden von Daten ber einen Socket bergeben wird Die n ch sten beiden Me punkte beziehen sich auf das Senden selbst Nach Me punkt 5 f ngt der Request Broker B an zu senden und Me punkt 6 wird erreicht nachdem die zu bertragenden Daten komplett bei Request Broker A angekommen sind Dieser mu dann wiederum aus den Daten im Puffer ein Datenob jekt im Shared Data Space erzeugen 6 und 7 Als letztes wird dann die Adresse des Datenobjektes wie der an den Tracer Modul der das Datenobjekt angefordert hat zur ckgeschickt dieser baut dann sein lokales Zugriffsobjekt auf siehe Abschnitt 4 2 3 Zugriff eines Moduls auf die Datenobjekte 7 und 8 Die einzelnen Me punkte sind dabei an den folgenden Stellen im Quellcode plaziert vor dem Aufruf des Konstruktors f r das ben tigte Datenobjekt direkt bei der Ankunft der Botschaft unmittelbar vor dem Absenden der Botschaft an den Request Broker B direkt bei der Ank
185. t offset DistributedObject e string_ptr_get int no IntShmPtr int shm_seq_no int offset IntShmPtr int seq_no int offs set_ptr int seq_no int offs get int set int val int operator int int operator int val Von diesen beiden Klassen sind jeweils fiir die oben genannten Datentypen entsprechende Unterklas sen abgeleitet die in ihren jeweiligen Initialisierungsroutinen Typkontrollen durchf hren Bei der Klasse Seite 59 4 Konzept eines verteilten Visualisierungssystems fiir Einzelelemente z B IntShmPtr kommen Methoden zum Setzen und Lesen dieser Variable hinzu aber auch Operatoren fiir die Zuweisung und die Typkonversion Diese Operatoren machen es den Modul und besonders den Datentypprogrammierern sehr einfach diese Variablen zu benutzen sie k n nen n mlich fast berall wie Variablen des C Grundtyps verwendet werden F r die Feldklassen las sen sich noch eleganter die Klammer Operatoren benutzen Dadurch ist es sogar m glich bei der Adressierung zu berpr fen ob der Index innerhalb der Feldgrenzen liegt Die Klasse StringShmArray dient der Speicherung von mehreren Character Feldern und ist eingef hrt wor den um das h ufige Vorkommen von solchen Character Strings einfacher handhaben zu k nnen Die Klasse ShmPtrArray spielt eine besondere Rolle im Unterschied zu den anderen Zugriffs klassen enth lt sie nicht die Standarddatentypen sondern zeigt wiederum auf andere Datenobjekte im Sh
186. tation Die Me punkte sind wieder analog zu den anderen Mes sungen dieses Kapitels allerdings ist der erste Modul nicht mehr ein Numerikproze wie auf dem Com puteserver C94 sondern ein Proze der aus einer Datei Daten liest die Y MP ist schlie lich ein Fileserver Die zu bertragenden Daten haben eine Gr e von 3 182 608 Bytes und werden vor dem Ver senden auch vom Cray Flie komma Format in das IEEE Format konvertiert Nach den Ergebnissen der Messungen zwischen dem FDDI Interface der C94 und dem der Indigo sollten eigentlich hnliche Durchsatzraten erreicht werden k nnen Allerdings d rfte sich auch wieder die knappe Ausstattung der Y MP mit Hauptspeicher bemerkbar machen In Tabelle 5 10 ist denn auch zu erkennen da trotz des recht kleinen Datensatzes nur in drei F llen eine nahezu ungebremste bertra gung von der Y MP zur Workstation erfolgen konnte Wenn die Konversion stets unbeeinflu t vom Scheduling blieb so war doch die Zeit die der Proze im Request Broker auf der Y MP verbrachte in den meisten F llen sehr lang zwischen 5 und 12 Sekunden Dabei h tte die eigentliche Arbeit in weni ger als 100 ms erledigt werden k nnen Die im Netzwerk verbrachte Zeit war jedoch meist etwa gleich lang dies d rfte entweder darauf zur ckzuf hren sein da die relativ kleine Datenmenge mit wenigen send Befehlen verschickt wurde so da keine Unterbrechung durch das Scheduling auftritt oder da diese Unterbrechungen relativ g
187. te RB Zeitin Sekunden Abbildung 5 9 Graphik der Me ergebnisse aus Tabelle 5 1 Die Grafik in Abbildung 5 9 zeigt da sich der Zeitunterschied fast gleichm ig auf die verschiede nen Teile der Messungen verteilt Interessant ist da eine solche Initialisierungsbremse bei keiner der anderen Messungen in dieser Form auftritt Nach dieser Anfangsphase zeigen die Messungen jedoch absolut gleichbleibende Werte nur die vorletzte Messung ist etwa eine Zehntelsekunde langsamer als die anderen was sich aber eindeutig auf das Netzwerk zur ckf hren l t Insgesamt ergibt sich eine ausgesprochen gleichm ige Verteilung der Zeiten auf das Netzwerk selbst und die Vor und Nachbereitungszeit Selbst unter idealen Netzwerkbedingungen d h unendliche Netzgeschwindigkeit lie e sich maximal ein Bruttodurchsatz von etwa 11 Megabyte pro Sekunde errei chen Ebenfalls interessant ist die Zeit die f r die Kommunikation zwischen dem Tracer Modul und dem Request Broker gebraucht wird Sie liegt mit etwa 7 ms bei einem Prozent der Gesamtlaufzeit Bei einer Vorweg bertragung von Datenobjekten d h Datenobjekte von denen der Controller wei da sie auf einem anderen Rechner gebraucht werden werden sofort nachdem der erzeugende Modul seine Schreibrechte zur ckgegeben hat an den entsprechenden Request Broker bertragen sind diese 7 ms der Gesamtoverhead der durch die Verwendung dieses Konzeptes bedingt ist Dieser Overhead ist nat rlic
188. te XV Seite XVI Kapitel 1 Einleitung 1 1 Die Problemstellung 1 1 1 Die Daten Die Ergebnisse von Berechnungen auf den schnellsten verf gbaren Supercomputern finden immer mehr Eingang in das t gliche Leben Das reicht von Berechnungen zur Sicherheit der Fahrgastzelle von Automobilen bei Unf llen ber die Qualit t der Verbrennung in Ottomotoren die extrem komplexen und immer zeitkritischen Wettervorhersagen bis zur Str mungsberechnung bei Flugzeugen zur Reduzierung des Treibstoffverbrauchs und der Schallemissionen Da aber die zugrundeliegenden nat rlichen Ph no mene nur selten in einfache Formeln zu fassen sind und sich daher auch nur mit erheblichem Rechenauf wand numerisch simulieren lassen besteht ein immer gr erer Bedarf nach Rechenleistung Siehe auch 18 50 und 30 Als Beispiel soll hier die numerische Simulation der Verbrennung in einem Ottomotor dienen Die Wissenschaft ist heute weit davon entfernt ein umfassendes Modell f r die Vorg nge im Zylinder eines solchen Motors zu haben Die heute verf gbaren Modelle beinhalten bereits starke Vereinfachungen Dazu geh rt zum Beispiel eine Beschreibung der chemischen Vorg nge die sich auf die wesentlichen Elemente Verbindungen und wiederum auf die wesentlichen Reaktionen zwischen diesen Elementen Verbindungen beschr nkt Das hei t bevor man auch nur die Numerik betrachtet hat schon eine drasti sche Vereinfachung des Modells stattgefunden Hinzu kommen weitere
189. ten flie en Selbst f r den Fall da zwei Module auf demselben Rechner laufen und Shared Memory f r den Datenaustausch zwischen ihnen genutzt wird haben die Daten obwohl sie im Shared Memory abge speichert sind zun chst keine eigene Identit t F r eine Performancesteigerung kann eine einfache Art von Persistenz in Form von Cacheing eingesetzt werden Das hei t die Daten werden nach Gebrauch nicht gleich wieder gel scht sondern bleiben im Shared Memory gespeichert und k nnen so f r den Fall da sie noch einmal gebraucht werden direkt genutzt werden Wenn eine solche Anwendung been det wird oder die entsprechenden Module gel scht werden sind diese Daten jedoch verloren Der hier vorgestellte Ansatz behandelt diese Daten jedoch als eigenst ndige nicht direkt mit der Lebensdauer der Module gekoppelte Objekte Wenn ein Modul gel scht wird und der dazugeh rige Pro ze nicht mehr existiert so hat dies zun chst einmal berhaupt keine Auswirkungen auf die von diesem Modul erzeugten Datenobjekte Obwohl sich dieses Konzept zun chst nur auf die Laufzeit des Systems bezieht stellt es doch eine logische Erweiterung des Datenflu netzwerkes dar Objekte nicht nur f r die Laufzeit des Systems sondern auch dar berhinaus zu erhalten Wichtig f r die Handhabung von persistenten Objekten sind folgende Funktionalit ten e ein Objekt ist eindeutig identifizierbar e ein Objekt l t sich unabh ngig von Modulen erhalten e ein Ob
190. ten objekts durch den Request Broker des CuttingPlane Moduls auf der Y MP wird der Proze einfach in einen Wartezustand versetzt Aus diesem Wartezustand kommt er erst nach einigen Sekunden wieder zur ck so da die Netzwerkzeit um diese Sekunden gr er erscheint als sie eigentlich ist CuttingPlane RB in PEGASE packobj Netzwerk Netto Durchsatz Brutto Durchsatz 4 513 0 054 0 053 4 458 3513 KB s 3471 KB s 3 389 0 023 0 022 3 366 4653 KB s 4621 KB s 3 932 0 063 0 062 3 869 4048 KB s 3983 KB s 1 278 0 055 0 054 1 223 12804 KB s 12251 KB s Tabelle 5 3 C94 zu Y MP HIPPI Der erste Versuch diese Wartezeiten zu reduzieren ist die Nutzung des asynchronen write Befehls der C94 Dieser Befehl unterscheidet sich von einem normalen write Befehl im wesentlichen dadurch da er sofort zur ckkommt und nicht erst nachdem die Daten tats chlich verschickt wurden Normaler weise nutzt man diesen Befehl um parallel zu dem dann vom Betriebssystem abgewickelten write das Programm weiterarbeiten zu lassen In diesem Fall ist allerdings die Arbeit des Request Brokers mit dem Abschicken vorerst beendet Der eigentliche Vorteil des asynchronen write liegt hier jedoch darin da nachdem das asynchrone write zur ckkommt der eigentliche Sendevorgang vom Betriebssystem mit der Priorit t des Kernels durchgef hrt wird w hrend bei einem normalen write die Priorit t des Benutzer prozesses die Ausf hrung bestimmt Die Erg
191. tetes Feld den Zeiger auf das erste Datenelement im Shared Data Space zur ck Eine f r den direkten Zugriff gedachte Methode entbindet den Modulprogrammierer von jeglicher Index Arithmetik get_point_coordinates int i int j int k float Sx er float Ay Cy float z Seite 63 4 Konzept eines verteilten Visualisierungssystems Zugriff auf die Datenobjekte im Modul Wenn das Modul eine Startbotschaft vom Controller erh lt kommt fiir jeden Eingabeport der Name des an diesem Port liegenden Datenobjektes mit Um auf dieses Datenobjekt zuzugreifen ruft der Modulprogrammierer den Konstruktor dieses Datentypes mit dem Namen des Datenobjektes als Argu ment auf Am Beispiel des strukturierten Gitters l t sich dieser Zugriff sehr gut demonstrieren int x y Z i Jr ki float xv yv Zv DO_StructuredGrid grid new DO_StructuredGrid Gittername grid gt get_grid_size amp x amp y amp Z for i 0 i lt x i for j 0 j lt y j for k O k lt z k get_point_coordinates i j k amp xv amp yv amp ZV compute xv yv ZV Um seine Daten an ein Nachfolgemodul weiterzureichen bedient sich der Modulprogrammierer eines mit einem Ausgabeport verbundenen Datenobjektes Dieses Datenobjekt wird neu erzeugt das hei t der Modulprogrammierer mu beim Anlegen dieses Datenobjektes die Gr en der Felder kennen Um ein Datenobjekt vom Typ eines strukturierten Gitters anzulegen m ssen also im folge
192. tig schreibend auf ein Datenobjekt zugegriffen Weiterhin erfolgt eine nderung eines Datenobjektes in der Regel durch den Modul der es auch erzeugt hat Erfolgen Zugriffe nicht nach diesem Schema so sind sie durch den Benutzer direkt ausgel st und unterliegen daher auch nicht den strengen Performance orientierten Anspr chen einer automatischen Ausf hrung f r einen menschlichen Benutzer sind Antwortzeiten im Millisekundenbereich durchaus akzeptabel wenn sich bei der Ausf hrung vieler Module solche Verz gerungen im Millisekundenbereich jedoch aufsummieren kann es durchaus zu einer ernsthaften Beein tr chtigung der Performance des Gesamtsystems kommen Seite 31 4 Konzept eines verteilten Visualisierungssystems Der lokale Fall Aus diesem Grunde sind die Mechanismen zur Zugriffssteuerung so ausgelegt daB sie bei einer auto matischen Ausf hrung am effizientesten funktionieren Bei einem normalen Durchlauf einer solchen Anwendung wird ein Modul seine bereits existierenden Eingabeobjekte lesen seine Arbeit ausf hren und dabei oder danach ein Ausgabeobjekt erzeugen und schreiben Dementsprechend ist auch die Daten verwaltung im Request Broker aufgebaut wenn ein Modul nach einem bereits existierenden Datenobjekt fragt wird ihm automatisch mit der R cksendung der Adresse das Leserecht erteilt Nach Beendigung des Lesens mu das Modul das Leserecht wieder zur ckgeben Wenn ein Modul ein Datenobjekt neu anlegt so wird ihm nachdem d
193. tremfall sehr ung nstige m glicherweise sogar unzusammenh ngende Partitionen entstehen die wiederum bei der Partikelverfolgung zu gro en Performance Einbu en f hren Der Visualisierungsalgorithmus Bei den Visualisierungsalgorithmen kann man im wesentlichen unterscheiden zwischen denen die e Elemente jeweils nur lokal bearbeiten und denen die e die Nachbarschaft der Elemente die sie bearbeiten mit einbeziehen Mit lokal soll in diesem Kontext alles was zu einem Element oder einer Zelle eines strukturierten oder unstrukturierten Gitters geh rt bezeichnet werden Zu den ersteren geh ren zum Beispiel die Schnittfl che besser Schnitt mit einer Hyperfl che das Abbilden von Daten auf eine Geometrie z B mittels Farbe oder Vektorpfeilen oder das Croppen Abschneiden von Teilen Nicht lokal sind zum Beispiel Partikelverfolgungen topologische Untersu chungen und unter gewissen Bedingungen auch Isofl chenberechnungen Im Falle von lokalen Algorithmen lassen sich die Module f r ein nicht partitioniertes Objekt prak tisch ohne nderungen im Berechnungsteil auch f r partitionierte Objekte nutzen Da die Nachbarschaft eines Elementes nicht von Bedeutung f r das Ergebnis der Berechnungen f r das aktuelle Element ist l t sich das gesamte Gebiet einfach zerteilen und partitioniert abarbeiten Ist der Algorithmus dagegen nicht lokal so l t sich das Konzept der Partitionierung entweder gar nicht oder meist mit deutlic
194. trukturierten Gitter d h gleiche Diskretisierung in jeder der Raumrich tung nicht notwendigerweise gleichm ig und orthogonal d rfte es sich in der Regel um eine quader f rmige Zerlegung handeln d h einzelne Indexbereiche werden zu Bl cken zusammengefa t So f hrt Seite 47 4 Konzept eines verteilten Visualisierungssystems zum Beispiel bei einem 9 x 9 Gitter eine Zerlegung in 3 x 3 Bl cke zu einer Gesamtzahl von 16 Bl cken siehe Abbildung 4 6 Basisgitter zerlegtes Gitter 1 1 1 9 1 9 Abbildung 4 6 Partitionierung eines 9 x 9 strukturierten Gitters Deutlich wird hierbei da die Zerlegung eines solchen Gitters zu redundanter Information f hrt So geh rt zum Beispiel der Punkt mit dem Index 2 2 in Abbildung 4 6 mit einem Punkt markiert gleich zu vier verschiedenen Partitionen In diesem einfachen Beispiel w chst die Zahl der in diesem Gitter zu speichernden Gitterpunkte also von 9 9 81 auf 4 4 3 3 144 also nahezu auf das Doppelte Im dreidimensionalen Raum w ren im analogen Fall statt 9 9 9 729 sogar 4 4 4 3 3 3 1728 also deutlich mehr als das Doppelte an Punkten zu speichern Daraus ergibt sich da bei zu klei nen Partitionen der Speicherbedarf berproportional gro ist Wenn man sich dagegen die durchzuf hrende Arbeit anschaut entdeckt man da es z B bei einer Isolinienberechnung keinen zus t
195. tures and Access Software for Scientific Visualization August 1990 Seite 96 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 7 Literatur Lang U Modularisierungskonzepte bei Simulationsproblemen in integrierten Programmsy stemen Forschungs und Entwicklungsberichte RUS 2 Rechenzentrum der Universit t Stutt gart 1989 Lee J Grinstein G Eds Database Issues for Data Visualization Lecture Notes in Com puter Science Volume 871 Proceedings IEEE Visualization 93 Workshop San Jose Sprin ger Verlag Berlin 1994 L ffler K Ein Datenmodell f r wissenschaftlich technische Anwendungen Forschungs und Entwicklungsberichte RUS 1 Rechenzentrum der Universtit t Stuttgart 1988 Lorenson W E and Cline H E Marching Cubes A high Resolution 3D Surface Construc tion Algorithm in Stone M C Ed Computer Graphics SIGGRAPH 80 Proceedings no 3in vol 14 pp 2 9 Juli 1980 Merazzi S Bonomi E Graphic Representation of Numerical Simulations in Thalman D Ed Scientific Visualization and Graphics Simulation pp 149 160 Jon Wiley amp Sons Chi chester 1990 Meyer Wegener K Multimedia Datenbanken B G Teubner Stuttgart 1991 MP Express Preliminary Specification http www avs com techpapers xp mp express white paper html Mullender S Ed D
196. ua lization Proceedings Visualization 95 G Nielson D Silver Eds pp 263 270 IEEE Com puter Society Press Los Alamitos 1995 Aiken A Chen J Lin M Spalding M Stonebraker M Woodruff A The Tioga 2 Database Visualization Environment Database Issues for Data Visualization Lecture Notes in Computer Science Volume 1183 pp 181 207 Wierse Grinstein Lang Eds Springer 1996 Arya M Swanberg D Vasudevan V Wierse A Database and Visualization System Integration Issues Database Issues for Data Visualization Lecture Notes in Computer Sci ence Volume 871 pp 16 24 Lee Grinstein Eds Springer 1994 AVS Express Developer s Reference Advanced Visual Systems Waltham MA Aug 1995 AVS User s Guide Release 4 Waltham Mass Advanced Visual Systems Inc 1992 AVS Technical Overview Advanced Visual Systems Waltham MA Oct 1992 Bartz D Ed Visualization in Scientific Computing 98 Springer Verlag Wien 1998 Bell D Grimson J Distributed Database Systems Addison Wesley Workingham 1992 Burnett M Goldberg A Lewis T Eds Visual Object Oriented Programming Man ning Greenwich 1994 Causse S Juaneda F and Grave M Partitioned objects sharing for visualization in distri buted environments in Rosenblum L et al Scientific Visualization Advances and Challen ges pp 251 264 Academic Press London 19
197. ukturiert quidistant rechtwinklig Multiblock unstrukturiert Tetraeder Hexaeder beliebig In diesem Zusam menhang ist nicht der Vorgang der Zerlegung wichtig sondern vielmehr die Auswirkungen die das Bearbeiten partitionierter Objekte auf die verwendeten Visualisierungsalgorithmen hat Im Idealfall funktionieren die Algorithmen auf den einzelnen Teilen eines partitionierten Objektes genauso wie auf einem einzelnen Datenobjekt Da dies in der Regel auch der Fall ist sind die Strukturen zur Handhabung partitionierter Objekte ent sprechend einfach ausgefallen ein partitioniertes Objekt unterscheidet sich von einem nicht partitionier ten nur durch ein sogenanntes Klammerobjekt Das hei t es gibt hnlich zu einem Set also Mengenobjekt einen Datentyp zu dessen Rumpfdaten im wesentlichen abgesehen von den Standardda tenobjektelementen der Typ der in ihm steckenden partitionierten Objekte und deren Anzahl geh ren Dabei wird deutlich da ein partitioniertes Objekt homogen aus lauter Datenobjekten gleichen Typs besteht die in ihrer Gesamtheit das ganze Datenobjekt ergeben Diese Homogenit t ist zwar nicht zwin gend vereinfacht jedoch die Handhabung au erordentlich Der Gittertyp Welchen Einflu hat nun der Gittertyp auf die Partitionierung Wir gehen zun chst davon aus da die Partitionierung auf dem Datensatz der visualisiert werden soll bereits vorgegeben ist was meistens der Fall sein d rfte Bei einem s
198. unft der Botschaft unmittelbar vor dem Absenden der Botschaft an Request Broker A direkt bei der Ankunft der Botschaft unmittelbar vor dem Absenden der Botschaft an Request Broker A CNA NHN KR WN nach dem Aufruf des Konstruktors Indigo A Indigo B Tracer O Request Broker Request Broker requet 2 request lee packobj unpackobj amp Abbildung 5 8 Me punkte der Konfiguration Indigo Indigo Seite 76 5 2 Messungen Tracer lokaler RB oe ae remote RB Netzwerk Netto Durchsatz Brutto Durchsatz 8 1 7 2 6 3 5 4 6 3 S 4 Gr e Netzwerk Gr e Tracer 1 006 0 981 0 737 0 292 0 445 7151 KB s 3163 KB s 0 733 0 726 0 592 0 187 0 404 7871 KB s 4338 KB s 0 601 0 594 0 458 0 159 0 299 10627 KB s 5293 KB s 0 616 0 609 0 466 0 158 0 308 10332 KB s 5164 KB s 0 597 0 591 0 456 0 158 0 297 10698 KB s 5323 KB s 0 606 0 599 0 460 0 160 0 300 10599 KB s 5248 KB s 0 690 0 682 0 543 0 159 0 384 8277 KB s 4599 KB s 0 596 0 590 0 454 0 158 0 295 10752 KB s 5333 KB s Tabelle 5 1 Indigo zu Indigo FDDI Zwar lie e sich nach Me punkt 1 und vor Me punkt 8 noch jeweils ein Me punkt analog zu den Me punkten 3 und 6 einschieben aus Gr nden des Aufwandes und der bersichtlichkeit und da das eigentliche Interesse ja der Kommunikation der Request Broker untereinander gilt wurde darauf ver zichtet In Tabelle 5 1 sind
199. ung im Saugrohr einer Turbine auf einem Supercomputer durchgef hrt siehe Abbildung 5 6 Die Module zur Visualisie rung dieser Str mung Schnittfl che mit Vektorpfeilen Partikelbahnen Isofl che einer Geschwindig Seite 72 5 1 Anwendungsbeispiele keitskomponente laufen entweder ebenfalls auf dem Supercomputer oder aber auf der Visualisierungsworkstation Der Benutzer hat ber die Benutzerschnittstelle der Graphikworkstation die M glichkeit den Eintrittswinkel der Str mung in das Saugrohr zu bestimmen Je nach Winkel bildet sich dann in der Str mung eine R ckstr mzone Da die station re Berechnung der Str mung auf dem Supercomputer eine relativ kurze Rechenzeit ben tigt k nnen die Ergebnisse der ersten Iterationen bereits nach wenigen Sekunden visualisiert werden Abbildung 5 6 Str mung im Saugrohr einer Wasserturbine Weitere Anwendungen Die COVISE Software wird in zahlreichen Projekten des Rechenzentrums weiterentwickelt oder dient als Basis f r andere Entwicklungen Zu diesen Projekten geh ren unter anderen e das vom DFN Verein finanzierte Projekt NumLab hier wurde in Zusammenarbeit mit dem Institut f r Angewandte Mathematik der Universit t Frei burg eine kollaborative Umgebung entwickelt die es verteilt sitzenden Nutzern von Parallelrech nern erm glicht ihren Numerikcode mit Hilfe des vor Ort sitzenden Spezialisten zu parallelisieren ihn auf dem Parallelrechner laufen zu lassen und die Ergebnisse anschlie
200. waltung und Kommunikation Der Inhalt dieser Arbeit stammt fast ausnahmslos aus dem letzten Bereich und schlie t dabei die Datenzugriffsmechanismen der Module mit ein Dieser Teil ist klar von den tibrigen Teilen von COVISE entkoppelt da er im wesentlichen die untere Ebene darstellt auf der die anderen Teile aufbauen Seite 7 2 Die COVISE Visualisierungsumgebung Da COVISE in den weiteren Kapiteln vielfach referenziert wird und als Gesamtumgebung den Rah men f r diese Arbeit bietet soll zun chst ein berblick ber die Struktur von COVISE gegeben werden Die Darstellung der Systemarchitektur ist in Abbildung 2 1 zu sehen man vergleiche hierzu die Darstel lungen der Architekturen anderer Produkte Kapitel 3 Jedes Rechteck steht f r einen Proze Zentrale Komponente im Sinne der Steuerung der Abl ufe ist der Controller Dieser hat zu jedem anderen Proze eine Socketverbindung um z B den Start eines Moduls zu veranlassen UI bezeichnet die Benutzungsschnittstelle des Systems ber diesen Proze steuert der Benutzer die Anwendung und bekommt ein Feedback ber den momentanen Stand der Ausf hrung Die Prozesse A B C D und E stehen f r Anwendungsmodule Dies sind die Bausteine aus denen der Benutzer seine Anwendung zusammenbaut hnlich einem Flu diagramm siehe Abbildung 2 2 links Diese Anwendungsmodule werden im weiteren einfach als Module bezeichnet RB steht f r Request Broker Der Request Broker ist die zentr
201. zlichen Aufwand gibt im nicht partitionierten Fall sind 8 8 64 Rechtecke zu untersuchen im partitionierten 4 4 4 64 Wesentliche Unterschiede gibt es nur bei Algorithmen die auf der Gitterstruktur beruhen wie zum Beispiel die Berechnung einer Schnittfl che entlang der Gitterstruktur eines strukturierten Gitters d h eine einem festgehaltenen Index entspre chende Fl che Hier erh ht sich mit der Anzahl der Partitionen die Menge der zu berpr fenden Index bereiche Diese Erkenntnisse lassen sich im wesentlichen abgesehen von den indexabh ngigen Algorithmen auch auf unstrukturierte Gitter bertragen F r den Fall da die Partitionierung in der Visualisierung erst erzeugt werden mu stellt sich das Szenario etwas anders dar Dies d rfte haupts chlich dann der Fall sein wenn die Daten aus einer Datei eingelesen werden sollen und die Partitionierung genutzt werden soll um mehrere Prozessoren mit Hilfe des Pipelining effizient zu nutzen Im Fall eines strukturierten Gitters ist die Situation sehr einfach bei linearer Speicherung werden so viele Daten der Indexebenen bei dreidimensionalen Daten gelesen bis eine hinreichende Partitionsgr e erreicht ist Die letzte Indexebene der vorhergehenden Partition wird dann auch als erste Indexebene der n chsten Partition genutzt und wiederum so lange Daten der Index ebenen gelesen bis die Partition eine gewisse Gr e erreicht hat Es soll nicht unerw hnt bleiben da eine sol
202. zum Beispiel Exception Handling oder Run Time Type Identification RTTI verzichtet um die Portabilit t zu erhalten obwohl diese auf den Workstation Compilern verf gbar sind Bei der Benutzung von Systemfunktionen wurde ebenfalls darauf geachtet die Portabilit t nicht ein zuschr nken Das hei t zur Kommunikation werden TCP IP Sockets f r den Shared Data Space wird Seite 54 4 6 Wesentliche Strategien der Implementierung das System V Shared Memory verwendet Dies sind Standardfunktionalit ten die auf fast jedem UNIX System verf gbar sind Shared Memory auf Cray Vektor Supercomputern Eine Ausnahme hiervon bilden nur die Cray Vektor Supercomputer und das Fehlen von Shared Memory Da die Benutzung von Shared Memory jedoch auf allen anderen Rechnern einen u erst gro en Performance Gewinn mit sich bringt wurde f r den besonderen Fall der Cray Vektor Supercompu ter eine M glichkeit gefunden die Grundstruktur beizubehalten und die nderungen am Quellcode so gering wie m glich zu halten Wie schon in Abschnitt 4 5 1 Supercomputer erw hnt wurden dazu der Anwendungsmodul und der Request Broker in ein einziges Executable kompiliert Dadurch da die Schnittstelle zwischen diesen beiden Prozessen wohldefiniert ist es gibt jeweils bei beiden Prozessen eine Routine zum Verschicken von Botschaften und eine Eingangsschleife durch die alle eingehenden Botschaften kommen war es nicht weiter schwer sie zu kombinieren Da Botsch
203. zwerk Bircheatz Durchsatz 4 321 4 306 4 143 3 558 3 552 0 585 5500 KB s 744 KB s 4 164 4 150 3 840 3 220 3 213 0 620 5189 KB s 772 KB s Tabelle 5 7 C94 zu Indigo FDDI kleiner Datensatz Im Unterschied zu den Ethernet Messungen wird in den langsameren F llen die Zeit fast ausschlie lich im Request Broker auf der C94 verbracht und nicht beim Verschicken der Daten Spalte Netzwerk Dies d rfte damit zusammenh ngen da die Zeit die zum Verschicken der Daten gebraucht wird zwi schen 400 und 800 ms unterhalb der Schedulinggrenze der C94 liegt d h der Vorgang des Sendens wird in der Regel nicht unterbrochen Bei den Ethernet Messungen dauerte dieser Vorgang immer meh rere Sekunden es ist also vorprogrammiert da ein solches Senden vom Scheduling unterbrochen und dadurch weiter verl ngert wird Die Nutzung schnellerer Netzwerke macht also den Datenaustausch nicht nur durch die erh hte Geschwindigkeit schneller sondern reduziert zus tzlich noch die Anf llig keit gegen ber anderen Systemvorg ngen wie z B dem Scheduling Um diese Einfl sse weiter zu untersuchen wurden die gleichen Messungen noch einmal mit einem deutlich gr eren Datensatz durchgef hrt 23 501 008 Bytes Aufgrund einer etwas besseren Last Situa tion der C94 waren die Resultate dieser Messungen gleichm iger als mit dem kleineren Datensatz siehe Tabelle 5 8 Nur eine der Messungen wurde im Netzwerk gebremst drei der Messungen wurde

Dokument 1

Contents

Download Pdf Manuals

Related Search

Related Contents