ComsolGrid - Konzeption, Entwicklung und Implementierung eines

Transcription

ComsolGrid - Konzeption, Entwicklung und
Implementierung eines Frameworks zur
Kopplung von COMSOL Multiphysics und
BOINC um hoch-skalierbare Parameterstudien
zu erstellen
Masterarbeit
Dipl.-Ing. (FH) Christian Benjamin Ries
zu erstellen
Masterarbeit
zur Erlangung des akademischen Grades eines
Master of Science (M.Sc.)
in
Optimierung und Simulation
von
geboren in Bielefeld, Deutschland
Fachhochschule Bielefeld
Ingenieurwissenschaften und Mathematik
Computational Materials Science & Engineering
Bielefeld, Germany
www.fh-bielefeld.de
c 2010 Dipl.-Ing. (FH) Christian Benjamin Ries. Ich erkläre hiermit, dass ich die vorliegende Arbeit
selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
Umschlag: Feldlinien zweier Metallstäbe mit dem BOINC Logo
zu erstellen
Eingereicht von:
Kontakt:
Matrikelnummer:
[email protected]
xxxxxx
Zusammenfassung
Berkeley Open Infrastructure for Network Computing (BOINC) ist ein Open-Source Framework zur Lösung von hoch-skalierbaren und komplexen Berechnungsproblemen. Das Arbeitsprinzip von BOINC basiert
auf den Public-Resource Computing (PRC) Prinzipien. Im Gegensatz zu den Ansätzen des zentral organisierten
Cluster-Rechnens, werden bei PRC die Berechnungsanwendungen an eine große Anzahl von heterogenen Computern verschickt. Diese Computer können über ein lokales oder globales Netzwerk, z.B. dem Internet, mit dem
Projekt verbunden sein und erhalten ein oder mehrere Arbeitspaket(e), welche individuell, absolut unabhängig
von den anderen Computern und ohne Kommunikation zu weiteren Computern gelöst werden. Allgemein wird
durch die Nutzung von PRC die Benutzerfreundlichkeit eingeschränkt - da keine direkte Ausführungskontrolle vorhanden ist. Heutzutage stehen in jeder Firma - ob groß oder klein - eine Unzahl von ungenutzten,
nicht direkt nutzbaren Rechnerressourcen zur Verfügung. Von der Eingangspforte, über die Sekretärin, bis zum
Chefzimmer - es gibt keine Möglichkeit der direkten Ausnutzung dieser Ressourcen, um aufwendige Berechnungsaufgaben zu lösen. Diese Rechnerkapazitäten werden im wahrsten Sinne des Wortes „verschwendet“. In
dieser Masterarbeit wird ein Ansatz verfolgt, eine Schnittstelle und Technologie zur Verfügung zu stellen, mit
der diese Ressourcen zur Lösung von Rechenaufgaben genutzt werden können. Einzig und allein die Simulationssoftware COMSOL Multiphysics und ein Projektserver mit BOINC muss zur Verfügung stehen. Weiterhin
zeigt diese Masterarbeit einen Ansatz, um eine einfache Erstellung von Arbeitspaketen zu ermöglichen. Durch
diesen Ansatz wird der Schritt soweit vereinfacht, dass innerhalb weniger Klicks eine komplette, automatische
und optimierte Parameterstudie erstellt und gestartet werden kann.
Prüfungsausschuss:
1. Gutachter:
2. Gutachter:
Ausgabe am:
Abgabe am:
Prof. Dr. rer. nat. Christian Schröder
Prof.in Dr. rer. nat. Svetozara Petrova
Vorwort
Entwicklung macht Spaß, neue Dinge erschaffen auch, worüber jeder meckert ist das Schreiben von
Berichten. Dies wird gerne immer weiter nach Hinten verschoben oder sogar mal vergessen. Dabei
ist es egal ob es sich um einen Bericht für eine Diplom-/Bachelor-/Masterarbeit oder Dissertation
handelt.
Durch das Schreiben von Berichten kann auf einfache Weise eine Struktur in den Alltag gebracht
werden. Es kristallisiert sich nach jedem Kapitel oder Abschnitt heraus, was noch gemacht werden
muss, oder wie etwas besser umgesetzt werden kann. Dieser Bericht entstand parallel zur eigentlichen
Entwicklungsarbeit und ist mit jeder hinzugekommenen Funktion gewachsen und hat mich sehr bei
der Entwicklung der Softwarekomponenten unterstützt.
Den nachfolgenden Comic finde ich sehr lustig und er illustriert schön das Geschehen beim Schreiben
eines Berichts...
Ich wünsche Ihnen viel Spaß beim Lesen dieser Arbeit!
Bielefeld, Deutschland
1. Oktober 2010
iii
Veröffentlichungen
Teile dieser Arbeit sind in den nachfolgenden Arbeiten veröffentlicht worden:
• C. B. Ries, ComsolGrid - Ein Framework zur Kopplung von COMSOL Multiphysics und BOINC um hoch-skalierbare Parameterstudien zu erstellen, Poster, [science fair], Universität
Bielefeld, 2010
• C. B. Ries, and C. Schröder, ComsolGrid - A framework for performing large-scale parameter
studies using Comsol Multiphysics and BOINC, COMSOL Conference, Paris, France, 2010
v
Inhaltsverzeichnis
Vorwort
iii
Veröffentlichungen
v
Inhaltsverzeichnis
vii
Abbildungsverzeichnis
xi
Listings
xiii
Abkürzungsverzeichnis
1
2
Einleitung
1.1 Zielgruppe . . . . . . . . .
1.2 Motivation . . . . . . . . .
1.3 Aufbau dieser Arbeit . . .
1.4 Forschungsfragen . . . . .
1.5 Terminologie . . . . . . .
1.6 Fremdwörter und Begriffe
xv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
1
2
2
3
Grundlagen
2.1 COMSOL Multiphysics . . . . . . . . . . . . . . . . . . . . . .
2.1.1 COMSOL Anwendungsbereiche . . . . . . . . . . . . .
2.1.2 COMSOL Startmodus . . . . . . . . . . . . . . . . . .
2.2 Fast Common Gateway Interface (FastCGI) . . . . . . . . . . .
2.2.1 FastCGI Architektur . . . . . . . . . . . . . . . . . . .
2.2.2 FastCGI Example . . . . . . . . . . . . . . . . . . . . .
2.2.3 FastCGI Installation und Verwendung . . . . . . . . . .
2.3 Server Technologien . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Apache Webserver . . . . . . . . . . . . . . . . . . . .
2.3.2 MySQL Datenbank . . . . . . . . . . . . . . . . . . . .
2.4 Berkeley Open Infrastructure for Network Computing (BOINC)
2.4.1 BOINC Server . . . . . . . . . . . . . . . . . . . . . .
2.4.2 BOINC Client . . . . . . . . . . . . . . . . . . . . . .
2.4.3 BOINC Architektur und Prinzipien . . . . . . . . . . .
2.4.4 BOINC Manager . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
6
10
10
10
12
12
13
13
14
15
16
18
19
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vii
INHALTSVERZEICHNIS
2.5
2.6
Qt Development Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Programmiersprachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Bisherige Arbeiten auf diesem Gebiet
21
3.1 Wrapper Implementierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Matlab und BOINC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 ComsolGrid Framework
4.1 Grundidee . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Automatische Installation eines BOINC Projekts . . . . . . . .
4.3 Sicherheitsaspekte und Authentifizierung . . . . . . . . . . . .
4.4 Benutzerrollen und deren Definitionen . . . . . . . . . . . . . .
4.5 ComsolGrid Framework - Architektur und Abhängigkeiten . . .
4.6 ComsolGridFCGI - Serverschnittstelle für Parameterstudien . .
4.7 ComsolGridStarter - BOINC Wrapper für COMSOL . . . . . .
4.7.1 COMSOL Multiphysics Prozesskontrolle . . . . . . . .
4.7.2 COMSOL Multiphysics Start- und Simulationsparameter
4.7.3 COMSOL Multiphysics Prozessfortschritt . . . . . . . .
4.8 COMSOL Dateiformate und Magic Numbers . . . . . . . . . .
4.9 Ermittlung der COMSOL Simulationparameter . . . . . . . . .
4.10 Ermittlung der COMSOL Applikationen und Versionen . . . . .
4.11 Modifikationen und Plattformdefinitionen des BOINC Manager
4.12 Kommunikationsprotokoll . . . . . . . . . . . . . . . . . . . .
4.12.1 ComsolGridFCGI - HTML/XML-Response Nachrichten
4.12.2 ComsolGridFCGI - HTML/XML-Request Nachrichten .
4.13 Ermittlung von System-/Prozessinformationen . . . . . . . . . .
4.14 Erstellung von Arbeitspaketen . . . . . . . . . . . . . . . . . .
4.15 Definition der Parameterstudienwerte . . . . . . . . . . . . . .
4.16 ComsolGridQt - Benutzerschnittstelle für Simulanten . . . . . .
4.17 ComsolGrid Validator . . . . . . . . . . . . . . . . . . . . . . .
4.18 ComsolGrid Assimilator . . . . . . . . . . . . . . . . . . . . .
5 Testlauf und Funktionsprüfung
5.1 Testumgebung . . . . . . .
5.2 Testparameter . . . . . . .
5.3 Ergebnisse des 1. Testlaufs
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
24
26
27
28
31
33
33
36
39
39
40
42
43
45
45
48
51
53
56
57
64
64
.
.
.
.
65
65
67
69
70
6 Zusammenfassung und weitere Betrachtungen
75
6.1 Wissenschaftlicher Beitrag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3 Zukünftige Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
viii
Literaturverzeichnis
77
A COMSOL Multiphysics Startparameter
81
INHALTSVERZEICHNIS
B ComsolGrid Testprojekt Installationsskript
B.1 ComsolGrid Templates . . . . . . . . . . . . . . . . . . . .
B.2 ComsolGrid Projektserver Konfiguration . . . . . . . . . . .
B.3 Apache Webserver . . . . . . . . . . . . . . . . . . . . . .
B.4 Testskript für die ComsolGridFCGI Schnittstelle . . . . . .
B.5 Struktur des Projektbaumes/des mitgelieferten Datenträgers .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
85
86
89
89
92
ix
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
Beispiel eines Mesh in einem COMSOL Simulationsmodell . . . . . . . . . . . . . . . .
Anwendungsbereiche von COMSOL Multiphysics - Quelle: www.comsol.com . . . . .
Grafische Benutzeroberfläche von COMSOL Multiphysics in der Version 4.0a . . . . . .
Architektur der FastCGI Implementierung [22] . . . . . . . . . . . . . . . . . . . . . .
Aufbau der Datenbanktabellen einer BOINC Grundinstallation . . . . . . . . . . . . . .
Der BOINC Server besteht aus einzelnen Komponenten und diese Komponenten teilen
sich einen Speicherort - (engl. A BOINC server consists of several components, sharing
several forms of storage) - Quelle: [5] . . . . . . . . . . . . . . . . . . . . . . . . . . .
Elemente des Aufgabenservers (engl. Components of a BOINC task server) - Quelle: [5]
Darstellung einer Möglichkeit zur Nutzung von BOINC . . . . . . . . . . . . . . . . . .
6
7
8
11
15
18
19
19
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
Verteilungsdiagramm mit einem Blick auf die ComsolGrid Komponenten . . . . . . . .
Architektur des ComsolGrid Frameworks und den implementierten Anwendungen . . . .
Das Zustandsdiagramm von ComsolGridFCGI . . . . . . . . . . . . . . . . . . . . . .
Ablaufdiagramm der Implementierung von ComsolGridStarter . . . . . . . . . . . . . .
BOINC Manager mit Darstellung des fraction_done Wertes von ComsolGridStarter . . .
Magic Numbers der COMSOL Simulationsmodelldateien . . . . . . . . . . . . . . . . .
Definition von Simulationskonstanten in den COMSOL Versionen 3.5 und 4.0 . . . . . .
Ermittlung der Simulationsparameter aus einem (1) COMSOL Simulationsmodell der
COMSOL Multiphysics Versionen (2) 3.5 und (3) 4.0 . . . . . . . . . . . . . . . . . . .
Der Informationsbeschaffungsprozess in einem UML2 Zustandsdiagramm . . . . . . . .
Der Informationsbeschaffungsprozess in einem UML2 Sequenzdiagramm . . . . . . . .
Beispiel eines Komponentendiagramm für ein Arbeitspaket im ComsolGrid Framework .
ComsolGridQt - Ansicht der Authentifizierungbereiche und dem Debug Bereich . . . . .
ComsolGridQt - Ansicht der Prozessinformationen . . . . . . . . . . . . . . . . . . . .
ComsolGridQt - Ansicht zur Erstellung einer neuen Parameterstudie . . . . . . . . . . .
ComsolGridQt - Tabelle zum Erstellen von Simulationsparametern . . . . . . . . . . . .
ComsolGridQt - Einstellungen für ComsolGridStarter . . . . . . . . . . . . . . . . . .
ComsolGridQt - Liste der unterstützten ComsolGridStarter Versionen . . . . . . . . . .
ComsolGridQt - Ansicht des „Informationsfensters“ . . . . . . . . . . . . . . . . . . . .
ComsolGridQt - Daten der Arbeitspakete (engl. Workunits) und Ergebnisse (engl. Results)
ComsolGridQt - Ansicht der Konfiguration einer neuen Parameterstudie . . . . . . . . .
24
29
32
37
39
40
41
5.1
5.2
Struktur der ComsolGrid Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Ergebnis des COMSOL Multiphysics Testmodells falling_sand.mph . . . . . . . . . 67
42
52
54
55
58
59
60
61
61
62
62
62
63
xi
5.3
5.4
5.5
5.6
5.7
5.8
xii
Parameter des COMSOL Multiphysics Testmodells falling_sand.mph
Ergebnisseite des 1. Testdurchlaufs . . . . . . . . . . . . . . . . . . . .
Fehleransicht des 1. Testdurchlaufs . . . . . . . . . . . . . . . . . . . .
Auflistung der Fehler des 1. Testdurchlaufs . . . . . . . . . . . . . . .
Ergebnisseite des 2. Testdurchlaufs . . . . . . . . . . . . . . . . . . . .
Ergebnisseite des 2. Testdurchlaufs nach manueller Validierung . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
68
71
71
71
72
73
Listings
2.1
2.2
2.3
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
4.24
4.25
4.26
4.27
4.28
4.29
5.1
5.2
5.3
5.4
Fehlermeldung beim Starten von COMSOL in der Version 4.0 mit dem Target batch .
Beispiel einer FastCGI Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aktivierung zweier Apache Module . . . . . . . . . . . . . . . . . . . . . . . . . .
Bildung des Passwort Hash-Wertes für die Authentifizierung an einem BOINC Projekt
Datenbanktabelle zur Umsetzung von Benutzerrollen . . . . . . . . . . . . . . . . .
Definition der Benutzerrollen im ComsolGrid Framework . . . . . . . . . . . . . . .
Beispielkonfiguration der Applikation ComsolGridFCGI . . . . . . . . . . . . . . .
Prozessstruktur von COMSOL Multiphysics 3.5x nach dem Start . . . . . . . . . . .
Prozessstruktur von COMSOL Multiphysics 4.0a nach dem Start . . . . . . . . . . .
Aktivierung der implementierten Prozesskontrollmechanismen . . . . . . . . . . . .
Signalhandler für die manuelle Signalverarbeitung . . . . . . . . . . . . . . . . . .
Struktur und Beispiel einer ./comsol.xml Konfigurationsdatei . . . . . . . . . . . .
Standardausgabe bei der Ausführung von COMSOL Multiphysics im Batch-Modus .
Struktur eines COMSOL Multiphysics Java Archivs . . . . . . . . . . . . . . . . . .
C++-Quelltext zur Ermittlung der Simulationsparameter aus einer Simulationsdatei .
Ermittlung der COMSOL Multiphysics Major Versionen . . . . . . . . . . . . . . .
Modifikation am BOINC Manager zur Ermittlung der COMSOL Versionen . . . . .
Vom BOINC Manager hinzugefügte Plattformdefinitionen . . . . . . . . . . . . . .
Basis HTTP-Request der die XML Daten aufnimmt . . . . . . . . . . . . . . . . . .
HTTP/XML-Response - ComsolGridFCGI <status> . . . . . . . . . . . . . . . . .
HTTP/XML-Response - ComsolGridFCGI <apps> . . . . . . . . . . . . . . . . .
HTTP/XML-Response - ComsolGridFCGI <comsol_release> . . . . . . . . . . . .
HTTP/XML-Response - ComsolGridFCGI <comsol_error> . . . . . . . . . . . . .
HTTP/XML-Response - ComsolGridFCGI Fehlernummern . . . . . . . . . . . . .
HTTP/XML-Request - Eine Parameterstudie erstellen . . . . . . . . . . . . . . . . .
HTTP/XML-Request - Status und Applikationen ermitteln . . . . . . . . . . . . . .
HTTP/XML-Request - Authentifizierung am Projektserver . . . . . . . . . . . . . .
Beispielanwendung zur Beschaffung von Informationen über definierte Prozesse . . .
Änderung der Zugriffsrechte für das BOINC Skript ./bin/status . . . . . . . . . .
Manuelle Erstellung eines Arbeitspakets . . . . . . . . . . . . . . . . . . . . . . . .
Beispiel eines Range mit drei Parametersätzen . . . . . . . . . . . . . . . . . . . . .
Beispiel einer Parameterdatei, die aus den Parameter Ranges erstellt wird . . . . . .
Konfiguration des NFS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hostnamen der COMSOL Multiphysics Testhosts . . . . . . . . . . . . . . . . . . .
Konfiguration zum Importieren des Ordner der COMSOL Multiphysics Installation .
32-Bit und 64-Bit Version von ComsolGridStarter . . . . . . . . . . . . . . . . . . .
9
11
13
26
27
28
33
34
34
35
36
37
39
41
41
43
44
44
45
46
47
47
48
48
50
50
51
52
53
55
56
57
66
66
66
67
xiii
LISTINGS
5.5
5.6
5.7
5.8
5.9
A.1
A.2
A.3
B.1
B.2
B.3
B.4
B.5
B.6
B.7
B.8
B.9
B.10
xiv
Ausgabe der ComsolGridFCGI Applikation zur Erstellung von Arbeitspaketen
Projektstatus, nachdem die Parameterstudie initialisiert ist (gekürzte Ausgabe) .
Konfiguration zum Deaktivieren eines Daemon . . . . . . . . . . . . . . . . .
Status des BOINC Projekts mit deaktiviertem file_deleter Prozess . . . . .
Gekürzte Ansicht der Ergebnisdateien . . . . . . . . . . . . . . . . . . . . . .
COMSOL Multiphysics allgemeine Startparameter - Hilfemenü . . . . . . . .
COMSOL Multiphysics Major Release 3.5a Startparameter - Batch Hilfemenü
COMSOL Multiphysics Major Release 4.0a Startparameter - Batch Hilfemenü
ComsolGrid Standarddatenbankeintrag für ein Testprojekt . . . . . . . . . . .
ComsolGrid Installationsskript für ein Testprojekt . . . . . . . . . . . . . . . .
ComsolGrid Template Input . . . . . . . . . . . . . . . . . . . . . . . . . . .
ComsolGrid Template Result . . . . . . . . . . . . . . . . . . . . . . . . . . .
ComsolGrid Projektserver Konfiguration . . . . . . . . . . . . . . . . . . . . .
Liste der Plattformen die der Projektserver zur Verfügung stellt . . . . . . . . .
Apache Webserver Konfiguration für die BOINC Projektnutzung . . . . . . . .
Apache Webserver Konfiguration für die FastCGI Nutzung . . . . . . . . . . .
Testskript für die ComsolGridFCGI Schnittstelle . . . . . . . . . . . . . . . .
Struktur des mitgelieferten Datenträgers . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
68
69
70
72
72
81
82
82
83
83
85
86
86
88
89
89
89
92
Abkürzungsverzeichnis
API . . . . . . . . . . .
Bash . . . . . . . . . .
BOINC . . . . . . .
CAD . . . . . . . . . .
CGI . . . . . . . . . . .
CKL . . . . . . . . . .
CPU . . . . . . . . . .
CR . . . . . . . . . . .
FastCGI . . . . . . .
FEM . . . . . . . . . .
FQDN . . . . . . . .
GPU . . . . . . . . . .
GUI . . . . . . . . . .
HTML . . . . . . . .
HTTP . . . . . . . . .
IP . . . . . . . . . . . .
IPv4 . . . . . . . . . .
IPv6 . . . . . . . . . .
ISO . . . . . . . . . . .
LF . . . . . . . . . . . .
NFS . . . . . . . . . .
OOP . . . . . . . . . .
OpenGL . . . . . .
OSI . . . . . . . . . . .
PHP . . . . . . . . . .
PID . . . . . . . . . . .
PRC . . . . . . . . . .
SHM . . . . . . . . . .
SQL . . . . . . . . . .
SSL . . . . . . . . . . .
SWT . . . . . . . . . .
TCP/IP . . . . . . . .
UML . . . . . . . . .
VPN . . . . . . . . . .
WU . . . . . . . . . . .
XML . . . . . . . . .
Application Programming Interface
Bourne-again shell
Boinc Open Infrastructure for Network Computing
Computer Added Design
Common Gateway Interface
Class-Kit License
Central Processing Unit
Carriage Return
Fast Common Gateway Interface
Finite-Elemente Methode
Fully-Qualified Domain Name
Graphics Processing Unit
Graphical User Interface
HyperText Markup Language
Hypertext Transfer Protokoll
Internet Protocol
Internet Protokoll in der Version 4
Internet Protokoll in der Version 6
International Organization for Standardization
Line Feed
Network File System
Objektorientierter Programmierung
Open Graphics Library
Open Systems Interconnection
PHP Hypertext Processing
Prozessidentifikationsnummern
Public Resource Computing
Shared-Memory
Structured Query Language
Secure Socket Layer
Standard Widget Toolkit
Transmission Control Protocol/Internet Protocol
Unified Modeling Language
Virtual Private Network
Workunit
Extensible Markup Language
xv
Kapitel 1
Einleitung
Es ist sinnlos zu sagen: Wir tun unser Bestes. Es muss dir gelingen, das zu tun, was
erforderlich ist.
Winston Churchill
Dieses Kapitel beschreibt die Beweggründe dieser Masterarbeit. Es wird beschrieben, aus welcher
Motivation heraus diese Masterarbeit entstanden ist. Weiterhin wird darauf eingegangen, auf welche
Besonderheiten der Leser beim Studieren dieser Masterarbeit achten muss und welche terminologischen Definitionen verwendet werden.
1.1 Zielgruppe
Diese Masterarbeit richtet sich an Softwareentwickler, Wissenschaftler und Forscher in allen Bereichen der Natur- und Ingenieurswissenschaften und an interessierte Leser.
1.2 Motivation
Diese Arbeit wurde in Angriff genommen, da es bisher noch keinen Ansatz gibt, mit dem das Simulationswerkzeug COMSOL Multiphysics in Kombination mit dem Berkeley Open Infrastructure for Network Computing (BOINC) Framework verwendet werden kann. Forschergruppen und
Studierende an der Fachhochschule Bielefeld arbeiten seit längerem mit COMSOL Multiphysics und
stehen vor dem Problem, dass viele verschiedene Simulationsdurchgänge für ein Modell durchgeführt werden müssen. Je nach Modell kann ein solcher Durchlauf Minuten oder bis zu mehreren
Tagen dauern. Genau dort setzt diese Arbeit an und versucht solche Parameterstudien auf mehrere
Rechner zu verteilen. So kann die Last der Ausführungen verteilt werden, so können womöglich
schnellere Ergebnisse der Simulationen erhalten werden.
1.3 Aufbau dieser Arbeit
Sechs Kapitel führen durch diese Masterarbeit. Angefangen mit dem aktuellen Kapitel, in dem Informationen über die Terminologie dieser Arbeit aufgeführt sind.
Im Kapitel 2 werden Grundlagen und Begriffe der Informationstechnik beschrieben. Es wird erläutert was das BOINC Framework ist und welche Architektur dahinter steht. Weiterhin wird ein
kurzer Überblick über die COMSOL Multiphysics Simulationsoftware gegeben und beschrieben in
welchen Anwendungsbereichen diese Software verwendet wird. Die Datenbanktechnologie MySQL
1
1.4 Forschungsfragen
Einleitung
wird kurz erläutert. Außerdem werden die in dieser Masterarbeit benötigten Programmiersprachen
aufgeführt.
Das Kapitel 3 liefert Einblicke in bis dato getätigte Arbeiten und gibt Informationen über den Stand
der Technik.
Den Kern dieser Arbeit deckt das Kapitel 4 ab. Hier werden alle Ideen und Implementierungen dieser Masterarbeit erwähnt und erläutert. In diesem Kapitel werden die Softwareimplementierungen
beschrieben und Einblicke in die umgesetzte Architektur des ComsolGrid Framework gewährt. Die
Softwarekomponenten, zur Erstellung von Parameterstudien und deren Benutzerbedienung, werden
beschrieben. Das Kapitel beinhaltet weiterhin das Kommunikationsprotokoll, mit dem der Projektserver und die Projektteilnehmer eine Kommunikation durchführen. Der ComsolGrid Wrapper, mit
dem Namen ComsolGridStarter, wird vorgestellt. Techniken zur Ermittlung der Simulationsparameter und der COMSOL Multiphysics Major Version werden erläutert.
Eine Testinstallation und Testlaufimplementierung wird in Kapitel 5 vorgestellt. Diese Installation
zeigt, dass die in dieser Masterarbeit beschriebenen Softwarekomponenten und umgesetzten Ideen
zu einem erfolgreichen Ergebnis führen und einen Nutzen für den Anwender haben.
Das letzte Kapitel gibt eine Zusammenfassung und einen Ausblick auf mögliche nachfolgende Arbeiten.
1.4 Forschungsfragen
Die Frage dieser Arbeit formte sich aus dem Wunsch, das COMSOL Multiphysics Simulationswerkzeug für hoch-skalierbare Parameterstudien anwenden zu können. Das Ziel dieser Masterarbeit ist
es, diese Lücke zu füllen, so dass die COMSOL Multiphysics Simulationsoftware in Kombination
mit dem BOINC Framework verwendet werden kann. In der Vergangenheit wurde erfolgreich die
Kombination mit Berkeley Open Infrastructure for Network Computing (BOINC) und Matlab implementiert und präsentiert [6]. In dieser Masterarbeit sollen die nachfolgenden Fragen untersucht
werden:
• Welche Softwarekomponenten werden benötigt oder müssen entwickelt werden?
• Wie kann die Erstellung und Administration einer hoch-skalierbaren Parameterstudie aussehen?
• Welche Systemanforderungen müssen erfüllt sein?
• Wäre eine solche Verwendung sinnvoll und rentabel?
• Wie kann eine Realisierung aussehen?
1.5 Terminologie
In dieser Arbeiten werden folgende Terminologien verwendet:
• Benutzer, die sich Arbeitspakete vom BOINC Projektserver herunterladen, werden in dieser
Arbeit als Anwender bezeichnet. Anwender erfüllen den Zweck von Maschinen, die nur
drei Arbeitsschritte abdecken: (1) Arbeitspakete holen, (2) Arbeitspakete bearbeiten und (3)
Ergebnisse an das BOINC Projekt zurücksenden.
2
Einleitung
• Der Administrator oder Entwickler wird in dieser Arbeit als Simulant bezeichnet. Der Simulant ist in diesem Fall die Person, die Parameterstudien und die wissenschaftlichen Applikationen und Arbeitspakete erstellt und einem BOINC Projekt hinzufügt.
• Namen von Anwendungen und Programmen werden durch ein Dollarzeichen angeführt und
besitzen folgende Schriftart: $cat /proc/meminfo. Dieses kleine Beispiel beschreibt das
Programm $cat, welches den Inhalt aus der Datei /proc/meminfo ausliest.
• Dateien werden wie Anwendungen und Programme dargestellt, mit der Ausnahme, dass kein
Dollarzeichen am Anfang steht und kein abschließender Schrägstrich angehängt ist, z.B.
/proc/meminfo. Ordnerpfade oder alleinstehende Ordner werden mit einem abschließenden
Schrägstrich beschrieben: (1) relativer Pfad Documents/University/ und (2) absoluter Pfad
/home/cr/Documents/University/.
In dieser Arbeit werden Begriffe und Fremdwörter fallen, die nicht im Duden stehen, aber in der
Informationstechnik zum Alltag gehören. Um nicht bei jeder Verwendung eine Erläuterung durchführen zu müssen, werden diese Begriffe und Wörter in der nachfolgenden Auflistung definiert. Es
kann sich bei dieser Auflistung um deutsche und englische Wörter handeln.
Framework Dieses Fachwort bezeichnet ein Gerüst zur Umsetzung einer zielgerichteten Gesamtheit
von Funktionen. Dieses Gerüst kann verschiedene Ausprägungen haben. Im Rahmen dieser
Masterarbeit ist ein Softwaregerüst gemeint, das mehrere Funktionalitäten kapselt und für
eine oder mehrere Aufgaben verwendet werden kann.
Syntax-Highlighted Editor Ein Editor ist in der Softwarebranche ein Textfeld zum Eingeben von
Text. Wenn ein solcher Editor zum Schreiben von Programmierquelltext verwendet wird, dann
können bestimmte Wörter und Zeichen mit Farben oder Schriftstilen dargestellt werden. Dies
wird Syntax-Highlight genannt und meint eine Hervorhebung von besonderen Darstellungsregeln.
Thread Ein Prozess, der im Kontext einer Programmausführung - meist im Hintergrund - ausgeführt
wird.
Multi-Thread Entspricht einer Anzahl N von Threads, die im Hintergrund ausgeführt werden und
in den meisten Fällen eine besondere, gesonderte Synchronisation benötigen. Dies liegt daran,
weil Threads oft auf dieselben Daten zugreifen können oder müssen.
Render Engine Eine Webseite besteht aus einer Auflistung von beschreibenden Textelementen dem sogenannten HTML - diese Elemente werden gelesen und zu einer grafischen Seite aufgebaut. In einem solchen Fall wird von einer Render Engine gesprochen. In Computerspielen
wird eine Render Engine zum Beispiel zur Darstellung von Landschaften oder Räumen verwendet.
Download-/Upload Diese Wörter beschreiben das Herunter- und Hochladen von Dateien, aus dem
Internet auf den eigenen Rechner oder vice versa.
Major Version Dies ist eine Hauptversion eines Softwarelebenszyklus. Es gibt z.B. die Linux Kernel 2.2.x, 2.4.x und 2.6.x. Diese Versionsnummern sind die Major Versionen. Die x Nummern beschreiben die Minor Version.
Aliase Dies entspricht einer Substitution von Befehlsketten.
3
Einleitung
HTTP-Request HTTP-Anfrage - Webanfrage, z.B. an einen Webserver.
HTTP-Response HTTP-Antwort - Webantwort, z.B. von einem Webserver.
Daemon, Dämon Wie ein Thread, allerdings wird hier der komplette Prozess im Hintergrund ausgeführt und dieser kann wiederum Threads beinhalten. In dieser Arbeit wird generell der englische Begriff verwendet, um direkt zu zeigen, dass es sich um solch einen Dämonen handelt.
4
Kapitel 2
Grundlagen
Man soll die Dinge so nehmen, wie sie kommen. Aber man sollte auch dafür sorgen,
dass die Dinge so kommen, wie man sie nehmen möchte.
Curt Goetz
Dieses Kapitel beinhaltet Informationen über die Grundlagen, der in dieser Arbeit verwendeten
Technologien. Es wird kurz darauf eingegangen, welche Funktionalitäten die Technologien besitzen
und was die Zielfunktionen sind. Dieses Kapitel erhebt sicherlich nicht den Anspruch auf Vollständigkeit, bzgl. der Gesamtheit der Beschreibungen aller zur Verfügung stehenden Funktionen
dieser Technologien. Die Verweise zu den Technologien führen zu weiteren Informationen.
2.1 COMSOL Multiphysics
Die COMSOL Multiphysics Simulationssoftware enthält alle Funktionalitäten, um die Geometrie
eines Simulationsmodell zu erstellen, dieses Modell mit einem Gitter (engl. Mesh) zu überziehen, die
physikalischen Gesetzmäßigkeiten zu definieren, um die Lösung der Problemstellung zu berechnen
und um das Visualisieren der erhaltenden Ergebnisse durchzuführen [35]. Die Abbildung 2.1 zeigt
exemplarisch ein Modell, welches mit einem Mesh überzogen ist. Die Modelle werden mit Hilfe
von Differenzialgleichungen beschrieben und durch die Finite-Elemente Methode (FEM) gelöst.
Das Mesh und die FEM arbeiten eng zusammen. Erst durch das Mesh wird die Möglichkeit der
Berechnung durch die FEM ermöglicht, da die FEM mit kleinen Abschnitten des Ganzen arbeitet
und Einzelergebnisse berechnet. Das Mesh kann in der Feinheit justiert werden und hat Einfluss
auf die Dauer der Simulation und in einigen Fällen auch auf das Ergebnis. Je nach Einstellung des
Mesh kann es vorkommen, dass eine Berechnung nicht konvergiert. Die Ergebnisse werden nach
Vervollständigung aller Berechnungen zusammen geführt, woraus sich ein Gesamtergebnis bildet.
Die Simulationssoftware ist mit den Betriebssystemen Linux (32-Bit/64-Bit), Mac OS X (32-Bit/64Bit) und Windows (32-Bit/64-Bit) ausführbar.
In dieser Masterarbeit werden für diese Software verschiedene Namen verwendet, diese beziehen
sich alle auf die COMSOL Multiphysics Simulationssoftware. Die verschiedenen Namen sind: COMSOL, COMSOL Multiphysics, COMSOL Multiphysics Simulationssoftware, Simulationssoftware
und Simulationswerkzeug. Die Simulationssoftware kann mit einer ganzen Reihe von verschiedenen Dateiformaten arbeiten. Das Standarddateiformat, welches von COMSOL definiert und entwickelt wurde, besitzt die Dateiendung *.mph. Dateien mit dieser Endung haben mehr als eine
Aufgabe: (1) diese können Simulationsmodelle enthalten oder (2) Definitionen von Materialeigenschaften. Ansonsten unterstützt COMSOL Multiphysics u.a. Parameter/Variablen/Postprocessing5
Grundlagen
Abbildung 2.1: Beispiel eines Mesh in einem COMSOL Simulationsmodell
Daten1 /Farbtabellen in formatierten Textdateien (.txt), Bildformate (.jpg, .png, .bmp, .eps, etc.),
Computer Added Design (CAD) Dateien (.dxf, .vrml, .stl), Mesh Dateien (.nas, .bdf, .nastran, .dat,
.vrml, .vrl, .stl) und Funktionen in den Programmiersprachen Java (.java) und C. In der grafischen
Ausgabe von COMSOL Multiphysics, können die Modelle in den Achsenrichtungen XY- und Z
gedreht, in das Modell hineingezoomt und die Ansicht verschoben werden.
2.1.1
COMSOL Anwendungsbereiche
COMSOL Multiphysics lässt sich in zahlreichen Bereichen der Technik und Naturwissenschaften
einsetzen. Das Simulationswerkzeug ist so aufgebaut, dass die verschiedenen Bereiche durch Module abgedeckt werden. Zum Zeitpunkt des Schreibens dieser Masterarbeit gibt es 12 Module, eine
Materialbibliothek (engl. Material Library) und eine Schnittstelle mit dem Namen LiveLink. Diese
bietet die Möglichkeit mit den vier externen Programmen „Pro/ENGINEER“, „Inventor“, „SolidWorks“ und „MATLAB“ Daten auszutauschen. In Abbildung 2.2 sind die vorher erwähnten Bereiche
der Technik und Naturwissenschaften aufgelistet und es wird illustriert in welchen Abhängigkeiten
diese zueinander stehen. COMSOL Multiphysics kann ein Clustersystem nutzen. Dadurch können
die Ressourcen solch eines Clustersystem für einen Simulationsdurchlauf genutzt werden. Weiterhin
unterstützt COMSOL Multiphysics die Möglichkeit sogenannte Sweeps zu definieren. Sweeps sind
Parameterstudien für ein Modell, die nacheinander - sprich sequentiell - ausgeführt werden, entweder mit Hilfe eines Clustersystem oder auf einer einzelnen Rechnermaschine. Die Unterstützung von
Sweeps ermöglicht allerdings nicht, dass mehrere Parameterstudien parallel bzw. verteilt verarbeitet
werden. Diese Rechnermaschine kann evtl. mehr als einen Prozessor besitzen. Das Verwenden von
mehreren Prozessoren wird auch durch COMSOL Multiphysics unterstützt.
2.1.2
COMSOL Startmodus
Die COMSOL Multiphysics Simulationssoftware kann in verschiedenen Modus Simulationen durchführen. Diese Modus wird durch das Angeben von Parametern beim Starten der Simulationssoftware bestimmt. Bei COMSOL werden diese Ausführungsarten COMSOL Targets genannt. Es stehen
sechs Targets zu Verfügung:
1 Dies
6
sind Ergebnisdaten, die für die Darstellung der Ergebnisse nach bearbeitet werden können.
Grundlagen
Abbildung 2.2: Anwendungsbereiche von COMSOL Multiphysics - Quelle: www.comsol.com
1. comsol Dieses Target ist der Standardausführungsmodus. Die grafische Benutzeroberfläche
wird gestartet und es kann sofort mit dem Erstellen eines Simulationsmodell oder der Ausführung einer Simulation begonnen werden. Die Abbildung 2.3 zeigt die Standardbenutzeroberfläche einer gestarteten Anwendungsinstanz von COMSOL.
2. comsol server Mit diesem Target wird ein COMSOL Server gestartet. Dadurch können sich
Anwender eine Lizenz zum Starten von COMSOL auf Nachfrage reservieren und COMSOL
bei sich auf der Maschine ausführen. Dies ist z.B. im akademischen Bereich von Vorteil. Es
arbeiten zu einem Zeitpunkt x, nicht alle Studierenden gleichzeitig mit COMSOL, somit können andere Studierende mit COMSOL arbeiten, da in diesem Fall einfach die nicht genutzten
Lizenzen zur Ausführung von COMSOL verwendet werden.
3. comsol batch Durch dieses Target wird das Starten von COMSOL aus dem Eingabefenster
bzw. einem Konsolenfenster ermöglicht. Weiter unten wird dieses Target noch näher betrachtet.
4. comsol compile Dieses Target kompiliert ein Simulationsmodell, welches als Java2 Quelle
zur Verfügung steht.
5. comsol server matlab Dieses und das nächste Target können nur zusammen mit einer Matlab Installation ausgeführt werden. Das aktuelle Target startet COMSOL in Kombination mit
Matlab und versucht sich zu einem COMSOL Server zu verbinden.
6. comsol matlab Hier wird COMSOL mit Matlab Unterstützung gestartet.
In dieser Masterarbeit wird dem dritten Target ganz besondere Aufmerksamkeit zuteil. Dieses Target
ermöglicht das Starten von COMSOL in der Texteingabe, der sogenannten Konsole bzw. einem
Terminal. Mit der Auswahl dieses Targets, werden weitere Parameter für den Anwender zur Auswahl
gestellt. Diese Parameter sind nachfolgend aufgelistet:
-inputfile <filename> Die Eingangsdatei, die ein Simulationsmodell enthält.
-outputfile <filename> Das Ergebnis der Simulation wird in dieser Datei gespeichert.
2 Java
ist eine sehr verbreitet und objektorientierte Programmiersprache, siehe auch http://www.sun.com.
7
Grundlagen
Abbildung 2.3: Grafische Benutzeroberfläche von COMSOL Multiphysics in der Version 4.0a
-study <study name> Ein Simulationsmodell, respektive die Eingangsdatei kann mehrere Studien
beinhalten. Diese Studien besitzen jeweils einen Namen. Mit der Angabe eines Namen für eine
Studie, wird die Simulation für die benannte Studie ausgeführt.
-job <job name> Dieser Parameter startet einen bestimmten COMSOL Job.
-pname <parameter name> Eine Simulation kann mehrere Parameter enthalten, z.B. die Geometriedaten eines Rechtecks oder Kreises. Ein Rechteck besitzt eine Länge und Breite, diese
Werte können durch Parameter (auch Variablen genannt) während der Modellierung des Simulationsmodells benutzt werden. Diese Variablennamen können beim Starten ausgewählt
und mit Werten gefüllt werden. Für das Setzen von Werten, wird der nachfolgende Parameter
genutzt.
-plist <parameter values> Dieser Parameter füllt die soeben beschriebenen Variablen mit Werten,
die dann während einer Simulation verwendet werden sollen.
-batchlog <log filename> Durch diesen Parameter wird eine Ausgabedatei definiert, in die Fehler
oder Warnungen über die Ausführung geschrieben werden. Diese Datei beinhaltet zum Beispiel
eine Fehlermeldung, wenn die Lizenz nicht richtig konfiguriert ist, so dass COMSOL nicht gestartet werden kann.
-client Die COMSOL Multiphysics Simulationssoftware kann wie oben erwähnt als Serverapplikation gestartet werden. Durch diesen und den nachfolgenden zwei Parametern, kann eine
Verbindung zu diesem Server erstellt und für die Kommunikation genutzt werden.
-host <hostname> Die Hostadresse des COMSOL Multiphysics Server.
-port <port number> Die Portnummer des COMSOL Multiphysics Server.
Weiterhin enthalten alle Targets grundsätzliche Parameter, die beim Start angegeben werden können.
Nachfolgend nur eine Liste von Parametern, die für diese Masterarbeit eine Relevanz besitzen.
8
Grundlagen
-ckl Dieser Parameter ist die Kurzform von Class-Kit License. Durch diesen Parameter wird die
benötigte Lizenz zur Ausführung von COMSOL von einem Lizenzserver abgefragt. In dieser
Masterarbeit wird der Lizenzserver der Fachhochschule Bielefeld verwendet. Die benötigten
Einstellungen, Serveradresse und Portnummer, werden in der Datei
/usr/local/comsolXX/license/license.dat vorgenommen und haben folgendes Format:
1
2
3
# SN=1024706
SERVER infma −l i c e n s e . fh −b i e l e f e l d . de ANY 19353
USE_SERVER
Der Computer, auf dem COMSOL ausgeführt werden soll, muss sich im Adressbereich der
Fachhochschule Bielefeld befinden. Dies kann entweder durch Anmeldung im Netzwerk der
Fachhochschule geschehen oder durch die Erstellung einer VPN3 -Verbindung zum Universitätsnetzwerk der Universität Bielefeld.
-32 | -64 Diese zwei Parameter definieren beim Starten von COMSOL ob eine 32-Bit oder 64-Bit
Plattform benutzt wird. Auffällig, aber dies scheint COMSOL nicht alleine ermitteln zu können.
-np <number of processors> Prozessoren mit mehr als einem Kern sind heutzutage Stand der
Technik und sollten auch verwendet werden können. Dieser Parameter ermöglicht es zu definieren, mit wie vielen Prozessorkernen eine Simulation ausgeführt werden soll.
-ipv6 Dieser Parameter steht für das Internet Protokoll in der Version 6 (IPv6). Die aktuelle und fast
noch ausschließlich verwendete Version ist IPv4. Dieses Protokoll definiert die Art und Weise
der Adressierung von Rechnern in einem Netzwerk. Der Unterschied dieser beiden Protokollversionen betrifft die mögliche Anzahl an adressierbaren Rechnern und weitere Änderungen,
die die Sicherheit und auch Priorisierung von Internetdiensten beeinflussen.
Es gilt folgendes für das Target batch zu beachten:
Dieses Target ist in Kombination mit der Class-Kit License nicht in der COMSOL Version 4.0
nutzbar. Getestet wurde das Ausführen mit Hilfe des CKL Parameters in der COMSOL Version 4.0
mit einem Linux Betriebssystem. Das Ergebnis dieser Ausführung ist die nachfolgende Ausgabe:
1
2
3
4
5
6
7
8
9
10
11
12
∗∗∗∗∗∗∗∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗
∗∗∗∗∗∗∗∗COMSOL p r o g r e s s o u t p u t f i l e ∗∗∗∗∗∗∗∗
∗∗∗∗∗∗∗∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗
F r i Sep 03 1 1 : 3 2 : 3 4 CEST 2010
Running : S tu d y 1
The_following_feature_has_encountered_a_problem
Exception :
com . co m s o l . u t i l . e x c e p t i o n s . F l E x c e p t i o n : The f o l l o w i n g f e a t u r e h a s e n c o u n t e r e d a
p r o b lem
M es s ag es :
The f o l l o w i n g f e a t u r e h a s e n c o u n t e r e d a p r o b lem
− F e a t u r e : S tu d y S t e p 1 ( s o l 1 / s t 1 )
− Error : License e r r o r .
Listing 2.1: Fehlermeldung beim Starten von COMSOL in der Version 4.0 mit dem Target batch
Diese Problematik ist in der COMSOL Version 3.5a und 4.0a nicht vorhanden!
3 Virtual
Private Network (VPN), ermöglicht die Kommunikation mit Hilfe einer verschlüsselten Verbindung.
9
2.2 Fast Common Gateway Interface (FastCGI)
Grundlagen
FastCGI ist eine freie und offene Erweiterung zum Common Gateway Interface (CGI) mit einer
hohen Performance (engl. performance) in allen Internetanwendungen, ohne die Latenzzeit einer
evtl. vorhandenen Schnittstelle eines Webservers. Die Implementierung soll eine schnelle Verarbeitung von Webanfragen ermöglichen. Applikationen mit FastCGI Nutzung, können im Kontext
eines Webservers ihren Dienst verrichten oder als eigenständige (engl. stand-alone) Applikation gestartet werden.
Mit FastCGI können Anwendungen entwickelt werden, die direkt eine Geschäftslogik (engl.
business logic) enthalten. Es sind unendlich viele Anwendungen möglich, z.B. kann eine Applikation
Anfragen entgegen nehmen und direkt Steuerungsaufgaben starten, ohne den Umweg über weitere
Schnittstellen zu nehmen. FastCGI unterstützt dies nativ, da der Kern von FastCGI als stand-alone
Applikation arbeiten kann. Heutige Webtechnologien sind in der Regel so aufgebaut, dass ein Interpreter - z.B. PHP Hypertext Processing (PHP) - auf dem Webserver installiert ist, ein Benutzer eine
in PHP programmierte Seite aufruft, dort Daten in Formulare eingibt, diese an den Server abschickt
und dieser Server die Daten in eine Datenbank einträgt. Im Hintergrund läuft ein Prozess, der diese
Daten kontinuierlich ausliest, um daraus Ereignisse zu erstellen. Im Unterschied dazu, steht FastCGI. Mit FastCGI ist der Weg zum Ziel nahezu minimal: die Daten werden von der Anwendung mit
FastCGI gelesen und die Ereignisse werden erstellt.
Beim Start einer Anwendung mit FastCGI (nachfolgend auch „FastCGI Applikation„ genannt)
werden die Standardein-/ausgabekanäle, sowie der Fehler-kanal4 umgeleitet. Während der Laufzeit einer Konsolenapplikation ohne FastCGI Nutzung, wird eine Ausgabe in der Konsole oder
dem Terminal ausgegeben. Eingaben des Benutzers erfolgen in der Regeln über die angeschlossene
Tastatur und die Konsolenapplikation liest diese Werte direkt ein. Eine Applikation mit FastCGI
Nutzung, verschickt und liest die Daten auf einer Netzwerkverbindung. Dabei erfolgt der Datentransfer in Form von HTTP-Nachrichten. Wenn sich ein Anwender verbindet, wird ein Nachrichtenkanal geöffnet. Dieser Nachrichtenkanal wird dann als Ein- und Ausgabekanal verwendet.
In dieser Masterarbeit wird FastCGI verwendet, da FastCGI auch im BOINC Framework genutzt
wird.
2.2.1
FastCGI Architektur
Die Abbildung 2.4 enthält die Architektur der FastCGI Implementierung. Der Webserver baut eine
Verbindung zur FastCGI Applikation auf und kommuniziert mit dieser Applikation über eine FullDuplex Verbindung5. Der Webserver kann weitere Verbindungen zu anderen Anwendungen haben.
Dies wird durch die Datenbank im unteren Bereich der Abbildung beschrieben. Eine FastCGI Applikation kann auch zusätzliche Verbindungen besitzen oder sich zu anderen Diensten verbinden.
Dieses muss vom Entwickler umgesetzt werden. Bei einer stand-alone Anwendung, ist der linke
Benutzer direkt mit der FastCGI Applikation verbunden.
2.2.2
FastCGI Example
Dieser Abschnitt beschreibt ein Beispiel einer FastCGI Applikation. In Listing 2.2 werden Webanfragen verarbeitet (Zeile 22 − 49). Dabei wird dem Anfragenden (Zeile 22) eine Nachricht geschickt
(Zeile 24 − 26), sobald sich dieser mit der FastCGI Applikation verbunden hat. In den Zeilen 28 − 35
4 In der Programmierung werden die Kanäle folgender weise bezeichnet: STDOUT (Standardausgabe), STDIN (Standardeingabe) und STDERR (Standardfehlerausgabe).
5 Verbindung über die in beide Richtungen kommuniziert werden kann.
10
Grundlagen
Abbildung 2.4: Architektur der FastCGI Implementierung [22]
wird geprüft ob Daten vom Anfragenden gesendet werden. Falls ja, werden diese zurück an den Anfragenden gesendet (Zeile 43) und dort eventuell im Webbrowser oder in einem Terminal angezeigt.
In den Zeilen 47 und 48 werden die Umgebungsvariablen ausgegeben. Einmal die Umgebungsvariablen des FastCGI Prozesses und zusätzlich die Umgebungsvariablen des übergeordneten Prozesses.
Das bedeutet, bevor der FastCGI Prozess initialisiert ist, sind nur die allgemeinen Umgebungsvariablen eines Linux Prozesses präsent. Wenn der FastCGI Prozess initialisiert ist, sind zusätzliche
Umgebungsvariablen vom Webserver oder von der FastCGI Ausführung gesetzt worden.
Das Programm kann mit dem Aufruf
setzt werden.
1
2
3
4
5
6
7
8
g++ −o echo echo.c −lfcgi
in ein ausführbares Programm über-
/∗
∗ ech o . c −−
∗ P r o d u ce a page c o n t a i n i n g a l l FastCGI i n p u t s
∗ C o p y r i g h t ( c ) 1996 Open Market , I n c .
∗ S ee t h e f i l e " LICENSE . TERMS" f o r i n f o r m a t i o n on u s a g e and r e d i s t r i b u t i o n
∗ o f t h i s f i l e , and f o r a DISCLAIMER OF ALL WARRANTIES .
∗/
# i n c l u d e < f c g i _ s t d i o . h>
9
10
11
12
13
14
15
16
s t a t i c v o i d P r i n t E n v ( char ∗ l a b e l , char ∗∗ envp ) {
p r i n t f ( "%s : \ n \ n " , l a b e l ) ;
f o r ( ; ∗ envp ! = NULL ; envp ++) {
p r i n t f ( "%s \ n " , ∗ envp ) ;
}
p r i n t f ( " \ n " ) ;
}
17
18
19
20
i n t main ( i n t a r g c , char ∗∗ a r g v ) {
char ∗∗ i n i t i a l E n v = e n v i r o n ;
in t count = 0 , len = 0;
21
22
23
24
25
26
w h i l e ( FCGI_Accept ( ) >= 0 ) {
char ∗ c o n t e n t L e n g t h = g e t e n v ( "CONTENT_LENGTH" ) ;
p r i n t f ( " C o n t e n t −t y p e : t e x t / h t m l \ r \ n \ r \ n "
" < t i t l e > F as tC G I echo < / t i t l e > "
" <h1 > F as tC G I echo < / h1 > \ n " ) ;
27
28
29
i f ( c o n t e n t L e n g t h ! = NULL) {
l e n = s t r t o l ( c o n t e n t L e n g t h , NULL, 1 0 ) ;
11
2.3 Server Technologien
} else {
len = 0;
}
i f ( l e n <= 0 ) {
p r i n t f ( "No d a t a from s t a n d a r d i n p u t . \ n " ) ;
} else {
i n t i , ch ;
p r i n t f ( " S t a n d a r d i n p u t : \ n \ n " ) ;
f o r ( i = 0 ; i < l e n ; i ++) {
i f ( ( ch = g e t c h a r ( ) ) < 0 ) {
p r i n t f ( " E r r o r : Not enough b y t e s r e c e i v e d on s t a n d a r d i n p u t \ n " ) ;
break ;
}
p u t c h a r ( ch ) ;
}
p r i n t f ( " \ n \ n " ) ;
}
PrintEnv ( " Request environment " , en v ir o n ) ;
PrintEnv ( " I n i t i a l environment " , i n i t i a l E n v ) ;
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
}
return 0;
49
50
51
Grundlagen
}
Listing 2.2: Beispiel einer FastCGI Applikation
2.2.3
FastCGI Installation und Verwendung
Wie oben erwähnt, kann FastCGI auf mehreren Wegen installiert und genutzt werden. Der erste Weg
ist ein direktes Starten der FastCGI Applikation. Eine weiterer Weg ist die Konfiguration des Apache
Webservers, damit dieser Server die Schnittstelle zwischen Anwender und der FastCGI Applikation
bildet. Im Anhang B.3 findet sich ein Konfigurationsbeispiel für die Konfiguration eines Apache
Webservers. In dem im Listing B.8 aufgeführten Beispiel, sind die Zeilen 4, 7 und 13 wichtig und
haben folgende Bedeutungen:
Zeile 4 Diese Konfigurationszeile setzt einen Alias zur Applikation mit der FastCGI Implementierung. In dieser Konfiguration würde die Webanfrage http://visualgrid-1/comsolfcgi
zur Applikation des Speicherorts /home/boincadm/sources/comsol_fcgi/comsol.fcgi
verweisen und diese Applikation würde die Anfrage bearbeiten.
Zeile 7 Diese Option aktiviert das Ausführen von externen Programmen durch den Apache Webserver. In dieser Konfiguration, wird direkt die vorher genannte Applikation mit FastCGI zur
Ausführung aktiviert.
Zeile 13 Diese Zeile startet eine Art Daemon FastCGI Applikation. Der Parameter am Ende definiert,
dass ein Prozess erstellt werden soll. Dieser Daemon wird beim Starten des Apache Webserver
initialisiert. Dadurch wird die Ausführung dieser Applikation beschleunigt, da nicht bei jedem
Webzugriff die Ausführung von Beginn an gestartet werden muss. Weiterhin wird diese Konfiguration für die kontinuierliche Aktualisierung der Prozessinformation aus Abschnitt 4.13
benötigt.
In diesem Abschnitt sind die Servertechnologien erwähnt, mit denen in dieser Arbeit gearbeitet wird.
12
Grundlagen
2.3.1
Apache Webserver
Der Apache Webserver ist ein Stück Software, die dafür zuständig ist Webseiten auf Anfrage bereitzustellen. Erst durch Webserver und das Hypertext Transfer Protokoll (HTTP) wurde das Internet
so, wie es heute ist und genutzt wird [13]. Webserver können mehr als nur Webseiten darstellen.
Durch Skript-sprachen wie Perl6 , PHP7 , Ruby8 und einer Fülle mehr, können Webserver mit Intelligenz gespickt werden. Webserver sind das Rückgrat unserer Informationsgesellschaft. Dienste wie
Facebook9, StudiVZ10 , Twitter11 - nur um die populärsten zu nennen - sind ohne Webserver nicht
denkbar.
Der Apache Webserver kann mit zahlreichen Funktionen angereichert werden. Diese Funktionen
stehen als Module zur Verfügung, die während der Laufzeit zur Konfiguration hinzugefügt werden
können. Ein Neustart des Webservers aktiviert diese Module. Bei den meisten Linux Distributionen
ist der Apache Webserver als Installationspaket verfügbar. In dieser Arbeit wird die Ubuntu Distribution verwendet, dort kann der Apache Webserver durch einen Aufruf in der Konsole installiert
und administriert werden [28]. Ubuntu liefert Administrationsskripts mit, durch die das Aktivieren
der benötigten Module auf ein Minimum des Verwaltungsaufwand abfällt. In Listing 2.3 werden die
Befehle zum Aktivieren der FastCGI und SSL/TLS Verschlüsselung aufgelistet.
1
$ s u d o a p t −g e t i n s t a l l a p a c h e 2 ap ach e2 −common ap ach e2 − u t i l s <−− Apache
Installation
2
3
4
5
$ s u d o a2enmod s s l
$ s u d o a2enmod f a s t c g i
$ s u d o / e t c / i n i t . d / a p a c h e r e s t a r t <−− a k t i v i e r t d i e zw ei Module
Listing 2.3: Aktivierung zweier Apache Module
In dieser Arbeit wird der Apache Webserver mit dem Modul für das Secure Socket Layer12 (SSL)
und FastCGI verwendet.
2.3.2
MySQL Datenbank
MySQL ist eine relationale Datenbank, die durch die Structured Query Language (SQL) bearbeitet
wird. Die Struktur einer Datenbank besteht aus Tabellen, die jeweils aus Zeilen bestehen. In jeder
Zeile steht ein Datensatz, der wiederum aus mehreren Elementen besteht. Diese Elemente sind in
Spalten der Tabelle strukturiert (nachfolgend „Datenspalte“ genannt). Es werden verschiedene Datentypen unterstützt [38, Kapitel 10]. Zwischen mehreren Tabellen können Beziehungen bestehen,
den sogenannten Relationen [11]. Das Listing 2.3.2 enthält eine Auflistung, die den Aufbau einer
Tabelle verdeutlichen soll. Die erste Ausgabe in den Zeilen 2 − 7 zeigt die verfügbaren Datenbanken.
Nach Auswahl der Datenbank comsolwrapper, kann die Struktur der Tabelle app angezeigt werden (Zeilen 12 − 26). In der ersten Spalte stehen die Namen der Datenspalten, in der zweiten Spalte
sind einige Datentypen aufgelistet und die letzte Spalte beschreibt für die Datenspalte id, dass der
Dezimalwert automatisch inkrementiert wird. Aus der vierten Spalte kann entnommen werden, dass
sich die Werte dieser Datenspalte als Primärschlüssel deuten lassen. Durch einen Primärschlüssel
können verkettete Relationen zu weiteren Tabellen erstellt werden. Diese Tabellen stehen dann in
Abhängigkeit zueinander. Wenn zum Beispiel zwei Tabellen in Relation stehen und in einer, eine
6 http://www.perl.org
- eine Programmiersprache
- eine Programmiersprache
8
http://www.ruby-lang.org - eine dynamische Interpretersprache
9 http://www.facebook.com - virtuelles Sozialnetzwerk
10 http://www.studivz.de - virtuelles Sozialnetzwerk
11 http://www.twitter.com - virtueller Kurznachrichtendienst
12 http://httpd.apache.org/docs/2.0/ssl - Modul für SSL/TLS Verschlüsselung.
7 http://www.php.net
13
Grundlagen
Datenreihe gelöscht wird, dann wird automatisch die in Relation stehende Datenreihe in der anderen
Tabelle gelöscht, wenn solch eine Aktion definiert ist. Es können verschiedene Aktionen definiert
werden. Die MySQL Datenbank kann Tabellen mit einer Größe von 65536 Terabyte (2567 − 1Byte)
verwalten [38, Kapitel 1].
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
mysql > show d a t a b a s e s ;
+−−−−−−−−−−−−−−−−−−−−+
| Database
|
+−−−−−−−−−−−−−−−−−−−−+
| information_schema |
| comsolwrapper
|
| mysql
|
+−−−−−−−−−−−−−−−−−−−−+
3 rows i n s e t ( 0 . 0 0 s e c )
mysql > u s e c o m s o l w r a p p e r ;
D a t a b a s e ch an g ed
mysql > d e s c r i b e app ;
+−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−+−−−−−−+−−−−−+−−−−−−−−−+−−−−−−−−−−−−−−−−+
| Field
| Type
| N u l l | Key | D e f a u l t | E x t r a
|
+−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−+−−−−−−+−−−−−+−−−−−−−−−+−−−−−−−−−−−−−−−−+
| id
| in t (11)
| NO
| PRI | NULL
| auto_increment |
| create_time
| in t (11)
| NO
|
| NULL
|
|
| name
| v a r c h a r ( 2 5 4 ) | NO
| UNI | NULL
|
|
| min_version
| in t (11)
| NO
|
| 0
|
|
| deprecated
| smallint (6)
| NO
|
| 0
|
|
| user_friendly_name
| v a r c h a r ( 2 5 4 ) | NO
|
| NULL
|
|
| h o m o g en eo u s _ r ed u n d a n c y | s m a l l i n t ( 6 )
| NO
|
| 0
|
|
| weight
| double
| NO
|
| 1
|
|
| beta
| smallint (6)
| NO
|
| 0
|
|
| target_nresults
| smallint (6)
| NO
|
| 0
|
|
+−−−−−−−−−−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−+−−−−−−+−−−−−+−−−−−−−−−+−−−−−−−−−−−−−−−−+
10 rows i n s e t ( 0 . 0 0 s e c )
mysql > SELECT A . id , A . name , A . u s e r _ f r i e n d l y _ n a m e FROM app AS A;
+−−−−+−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| i d | name
| user_friendly_name
|
+−−−−+−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| 1 | c o m s o l s t a r t e r | COMSOL v4 . 0 Wrapper ( p r o t o t y p e ) |
+−−−−+−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
1 row i n s e t ( 0 . 0 0 s e c )
Das BOINC Framework aus dem nachfolgenden Abschnitt 2.4 enthält in der Grundinstallation 33 Tabellen. Diese Tabellen beinhalten Informationen über die registrierten Benutzer, die zu
verwendenden wissenschaftlichen Applikationen mit ihren Plattformdefinitionen und einige weitere Informationen. Die Abbildung 2.5 zeigt die Datenbanktabellen einer BOINC Grundinstallation.
Links sind die 33 Tabellen aufgelistet, in der Mitte können diese Tabellen administriert werden,
d.h. Datensätze hinzugefügt, editiert oder gelöscht werden. Nicht alle der 33 Datenbanktabellen sind
für die Ausführung eines BOINC Projekts notwendig. Die BOINC Grundinstallation liefert u.a. ein
Spendensystem mit, durch das Freiwillige Geld an die Organisation hinter einer Projektinstallation
spenden können. Sehr gut zu erkennen, ist die oben erwähnte Tabelle app, in der Informationen über
die wissenschaftlichen Applikationen abgelegt sind.
BOINC (Berkeley Open Infrastructure for Network Computing) ist ein Framework zur Erstellung
von hoch-skalierbaren, komplexen und rechenintensiven Problemen im Sinne des Public Resource
Computing (PRC) Prinzips. Mit diesem Framework wird der Rechenaufwand in kleine Pakete unterteilt. Diese Pakete werden Workunits genannt. Jeder kann sich an der Arbeit zur Lösung solcher
14
Grundlagen
Abbildung 2.5: Aufbau der Datenbanktabellen einer BOINC Grundinstallation
Arbeitspakete beteiligen, ganz freiwillig. Freiwillige (engl. Volunteer) registrieren sich bei einem
Projekt, installieren sich ein Programm auf ihren Rechner (dem sog. BOINC Client/Manager) und
verbinden sich mit den selbst gewählten Authentifizierungsdaten zum Projekt. Nach Authentifizierung kann der Freiwillige sich die wissenschaftliche Applikation mit den zugehörigen Arbeitspaketen
herunterzuladen. Da sich Freiwillige an solch einem Projekt anmelden und teilnehmen können, wird
dies auch Volunteer Computing genannt. Die Freiwilligen bearbeiten die Arbeitspakete, schicken das
Ergebnis an den Projektserver zurück und holen sich ein oder mehrere neue Arbeitspakete. Auf dem
Projektserver wird das Ergebnis validiert und bei Gültigkeit zu einem Gesamtergebnis hinzugefügt
oder als Einzelergebnis an einem spezifizierten Ort abgelegt. Der Freiwillige kann gleichzeitig an
mehreren Projekten teilnehmen.
Passionierte Entwickler und Wissenschaftler können sich eine eigene wissenschaftliche Applikation erstellen. Zu diesem Zweck liefert BOINC ein Framework, das es dem Nutzer ermöglicht eine
wissenschaftliche Applikation zu erstellen. Diese kann dann zur Lösung von einfachen bis komplexen mathematischen Aufgaben verwendet werden. Die Funktionalitäten des BOINC Framework sind
in verschiedene Kategorien eingeordnet und nachfolgend erläutert [4, 2, 3].
2.4.1
BOINC Server
Der BOINC Server bietet mehrere Funktionen, über die nachfolgend ein kleiner Überblick gegeben
wird [20].
• Configurations: Der Projektserver kann individuell konfiguriert werden. Die Konfigurationsdateien sind im XML Format.
• Work Generator: Jede wissenschaftliche Applikation benötigt Arbeitspakete, die durch einen
Generator erzeugt werden.
• Validator: Der Validator übernimmt das Validieren der Berechnungsergebnisse. Der Entwickler, Projektadministrator oder Wissenschaftler kann entscheiden, nach welchem Verfahren das
Validieren durchgeführt wird.
15
Grundlagen
• Assimilator: Validierte Ergebnisse werden vom Assimilator zusammengeführt. Die Logik des
Assimilator kann projektspezifisch implementiert sein, z.B. können die Einzelergebnisse zusammen geführt oder an einem bestimmten Ort abgespeichert werden.
2.4.2
BOINC Client
Der vom Freiwilligen installierte BOINC Client, übernimmt die Steuerung der wissenschaftlichen
Applikation und die Kommunikation mit den BOINC Projekten. Der BOINC Client übernimmt
zahlreiche Funktionalitäten und Verwaltungsaufgaben, diese sind in der nachfolgenden Auflistung
kurz erläutert [20].
• Initializing and Termination: Diese Funktionalität bereitet das BOINC Framework für die
Arbeit vor. Dafür stehen Funktionen zur Initialisierung und Beendigung einer Applikation
zur Verfügung. In der Initialisierung wird geprüft ob Diagnosemarken gesetzt sind. Die Initialisierung übernimmt die Einstellung von Standardoptionen, die während der Applikationslaufzeit modifiziert werden können. Die Ausführung der Applikation kann in vier Instanzen
unterteilt werden: Suspend, Resume, Quit und Abort. Die ersten zwei pausieren bzw. heben
eine Pausierung der Ausführung auf. Quit und Abort brechen die Ausführung einer Berechnung ab.
• Resolving Filenames: In den Applikationen werden keine festen Dateinamen vergeben. Es
wird bei der Programmierung ein generalisierter Name gewählt, der eine assoziative Verknüpfung zu Dateien symbolisiert. Bei einem Benutzer können gleichzeitig mehrere Projektanmeldungen vorhanden sein. Jedes Projekt besitzt seine eigenen projektspezifischen Ein-/Ausgabedaten. Damit diese Dateien nicht in Konflikt zueinander geraten, werden sogenannte Slots erstellt. Diese Slots beinhalten eine oder mehrere Dateien, welche wiederum einen symbolischen
Link enthalten. Dieser symbolische Link verweist auf die aktuelle zu verwendende Datei.
• I/O13 Wrappers: BOINC ist für die Ausführung unter verschiedenen Betriebssystemen entworfen, u.a. Windows, Linux. Um eine Konsistenz für den Zugriff auf Dateien zu ermöglichen,
sollten die im BOINC Framework implementierten Dateifunktionen, z.B. boinc_fopen(char∗ path
, char∗ mode), verwendet werden. Bei Windows können u.a. Sicherheitsmechanismen den Zugriff verwehren, bei Linux werden Signale gesendet wenn ein Fehler aufgekommen ist. Die
mitgelieferten Funktionen bieten einen Workaround an und schließen automatisch die Datei,
wenn die Applikation (unerwartet) beendet wird.
• Checkpointing: Eine Applikation kann während der Ausführung jederzeit unterbrochen werden. Dies ist z.B. der Fall, wenn die Prioritäten für die Ausführung so gesetzt sind, dass die
Applikation nur ausgeführt werden soll, wenn der Anwender nicht am Rechnersystem arbeitet
(Idle Betrieb). Bei der Unterbrechung wird der aktuelle und mögliche Stand der Ausführung
in einer Checkpoint-Datei abgesichert und wenn die Applikation weitergeführt werden soll,
wiederhergestellt.
• Critical Sections: In der Ausführung einer Applikation kann es sein, dass Bereiche nicht unterbrochen werden dürfen. Z.B. wenn die Datenkonsistenz bei der Synchronisation von verschiedenen Rechenabschnitten gegeben sein muss. Diese Bereiche können in atomare Abschnitte implementiert werden. Solche Prozesse sind nicht unterbrechbar.
• Atomic File Update: Um eine schnelle Abspeicherung in Dateien zu ermöglichen, liefert
das BOINC Framework die Klasse class MFILE{...} mit. Diese Klasse dient als Puffer. Alle
13 Eingabe/Ausgabe
16
(Input/Output)
Grundlagen
Schreibzugriffe erfolgen in einem temporär angelegten Speicherplatz, der beim Aufruf der
Methode int flush () den Inhalt auf das Dateisystem schreibt.
• Credit Reporting: Der Status der Abarbeitung kann jederzeit abgefragt werden. Die Beendigung einer Berechnung impliziert einen Punktewert (Credit), der dem Benutzerkonto gutgeschrieben wird. Diese Credits beschreiben das Verhältnis zwischen zur Verfügung gestellter
CPU-Zeit14 und einer projektspezifischen Maximalpunktzahl.
• Reporting Progress: Mit der Funktion boinc_fraction_done (double fraction_done ) kann der aktuelle
prozentuale Wert der Abarbeitung gesetzt werden. Dieser wird dem BOINC Client gemeldet
und kann angezeigt werden.
• Miscellaneous Data: Dieses sind Daten, die zahlreiche Informationen über die verwendete
Applikation, das System, die Ressourcen, u.v.m. liefern. Zur Abfrage muss eine Instanz der
Struktur struct APP_INIT_DATA{...} mit der Funktion boinc_get_init_data (APP_INIT_DATA data) gefüllt werden. Diese Informationen werden vom BOINC Client zusammengetragen.
• Timing Information: Mit int boinc_wu_cpu_time(double &cpu_time) wird der Gesamtwert der CPU
Zeit ermittelt, seitdem ein Arbeitspaket gestartet wurde. Nach Berechnungspausen liefert die
Funktion double boinc_elapsed_time () das Delta der Zeit zwischen der Pause und dem aktuellen
Zeitpunkt. Diese Funktionen liefern Messwerte über die Ausführung der wissenschaftlichen
Applikation.
• Standalone Mode: Mit der Funktion int boinc_is_standalone () kann geprüft werden, ob die wissenschaftliche Applikation außerhalb der Kontrolle des BOINC Client gestartet ist. Dieser
Modus dient dem Testen und Überprüfen der Funktionen einer wissenschaftlichen Applikation.
• Registering a Timer Handler: Wiederkehrende Funktionen können während der Ausführung
im BOINC Framework registriert werden. Diese registrierten Funktionen werden mit einem
Intervall von einer Sekunde ausgeführt.
• Requesting Network Connection: In der Ausführung der wissenschaftlichen Applikation kann
dem BOINC Client übermittelt werden, dass eine Netzwerkverbindung zur Verfügung gestellt
werden muss, z.B. um Ergebnisse zu versenden.
• Diagnostic: Bei der Entwicklung einer Applikation können plattformspezifische Fehler bei
den Projektteilnehmern auftreten. Wenn eine wissenschaftliche Applikation abstürzt oder abgebrochen wurde, werden der Stacktrace15 und Informationen über die Ausführung (Wert der
Beendigung, Signalidentifikationen, Plattforminformationen und die Datei für die Standardfehlerausgabe) an den Projektserver gesendet. Es kann vom Entwickler der wissenschaftlichen
Applikation festgelegt werden, welche Informationen gesendet werden sollen.
• Long-Running Applications: Wissenschaftliche Applikationen können mehrere Wochen oder
Monate laufen. Damit der Projektserver ein Arbeitspaket nicht bei einem Teilnehmer abbricht, werden durch sogenannte Trickle-Messages während der Ausführung, der aktuelle
Stand (CPU Nutzung, Zusammenfassung der Ergebnisse, Befehle die für die Ausführung Bedeutung haben) zwischen dem Teilnehmer und dem Projektserver ausgetauscht.
• Graphics: Die wissenschaftliche Applikation kann um die Möglichkeit eines Bildschirmschoners (engl. Screensaver) erweitert werden. Zu diesem Zweck existiert eine Grafikschnittstelle, die vom Entwickler zu implementierende Funktionen definiert.
14 Bei
BOINC die Anzahl der Fließkomma- und Ganzzahloperationen für die Lösung einer Rechenaufgabe.
und Interpretation des Inhalts des Stacks.
15 Ausgabe
17
Grundlagen
Abbildung 2.6: Der BOINC Server besteht aus einzelnen Komponenten und diese Komponenten
teilen sich einen Speicherort - (engl. A BOINC server consists of several components, sharing several
forms of storage) - Quelle: [5]
• Graphics Processing Unit (GPU): Die Ausführung auf einer GPU beschleunigt die Ausführungszeit um mindestens einen Faktor zwischen zwei und zehn. Ab der BOINC Client
Version 6.10.10 werden neben NVidia auch ATI Grafikkarten unterstützt.
2.4.3
BOINC Architektur und Prinzipien
In Abbildung 2.6 und 2.7 ist die Architektur eines BOINC Projekts aufgeführt [5]. BOINC Projekte sind autonom. Jedes Projekt basiert aus verschiedenen Komponenten: Webschnittstelle (engl. web interface), Aufgabenserver (engl. task server) und Datenserver (engl. data server). Diese
Komponenten teilen sich Daten aus der Datenbank und der Download-/Upload-Dateiordner. Jeder
Client verbindet sich periodisch zum Aufgabenserver um fertige Arbeitspakete zu melden und um
neue herunterzuladen. Das mittlere Element „task server“ aus Abbildung 2.6, wird in Abbildung 2.7
näher beschrieben. Den Kern bildet die MySQL Datenbank. Die einzelnen Komponenten arbeiten
in eigenen Prozessen und tauschen ihre Daten mit Unterstützung der MySQL Datenbank aus. Dieser Datenaustausch betrifft die beschreibenden Daten eines Arbeitspakets. Konfigurationen der Anwendungen oder Informationen zur Prozessindentifikation, werden nicht in der Datenbank abgespeichert. Solche Informationen werden in Dateien im Dateisystem abgelegt. Die zwei Prozesse links
im Bild, kommunizieren über eine Shared-Memory (SHM) Speicherstelle. Die Clients verbinden
sich zum „scheduler“, senden Ergebnisse vorheriger Arbeitspakete und erfragen neue Arbeitspakete.
Der „scheduler“ ist die Intelligenz eines BOINC Projekts. Dieser steuert welche Arbeitspakete an
welchen Client gesendet werden und speichert Ergebnisse zur Überprüfung ab.
Die Abbildung 2.8 zeigt, wie eine Installation eines BOINC Projekts in der Laufzeit aussehen kann.
Der untere rechte Teil beschreibt eine BOINC Projektinstallation auf einer Unix/Linux Arbeitsmaschine. Die dunklen, vertikalen Elemente sollen Computer beschreiben, die am BOINC Projekt registriert sind. Diese Computer können überall auf der Welt stehen und benötigen nur eine Verbindung
zum Projektserver. Es ist unerheblich, ob die Rechner sich direkt am Projektserver anmelden oder ob
diese durch ein Firmennetzwerk/privates Netzwerk verbunden sind. BOINC verwendet das TCP/IPSystem16 und kann dadurch auch eine Verbindung zu Computern auf dem Mond herstellen, falls
dort welche installiert sein sollten.
16 Transmission
18
Control Protocol/Internet Protocol (TCP/IP)
Grundlagen
2.5 Qt Development Framework
Abbildung 2.7: Elemente des Aufgabenservers (engl. Components of a BOINC task server) - Quelle:
[5]
Abbildung 2.8: Darstellung einer Möglichkeit zur Nutzung von BOINC
2.4.4
BOINC Manager
Der BOINC Manager ist die direkte Schnittstelle zum Projektteilnehmer und ist eine grafische Anwendung. Mit dieser Anwendung kann der Projektteilnehmer sich an verschiedenen BOINC Projekten anmelden. Diese grafische Komponente ermöglicht das schnelle Einstellen von BOINC Einstellungen, z.B. wie viele Prozessoren generell verwendet werden dürfen, oder wie viel Rechenzeit
für die wissenschaftlichen Applikationen zur Verfügung steht. Das Einstellen der Anzahl der Prozessoren kann nicht für bestimmte wissenschaftliche Applikationen vorgenommen werden, d.h. eine
Applikation kann nicht x viele Prozessoren für die Ausführung reservieren. Wenn im BOINC Manager drei Prozessoren zur Verwendung freigegeben sind, dann werden diese durch drei verschiedene
Arbeitspaketberechnungen der wissenschaftlichen Applikationen genutzt. Es ist unerheblich, welche
wissenschaftliche Applikation genutzt wird.
2.5 Qt Development Framework
Qt ist ein Framework zur Erstellung von grafischen Benutzeroberflächen für Computersysteme [32,
7]. Das Qt (lies engl. cute, Aussprache [kju:t]) Framework ist für die Plattformen: Embedded Linux, Mac OS X, Windows, Linux/X11, Windows CE/Mobile, Symbian und Maemo verfügbar. Es
19
2.6 Programmiersprachen
Grundlagen
sind Werkzeuge zur Erstellung von grafischen Formularen vorhanden, die direkt in einem SyntaxHighlighted Editor mit Programmlogik gefüllt werden können. Das Framework liefert einen hohen
Funktionsumfang. Die Funktionen decken folgende Bereiche ab:
3D Grafik mit OpenGL17 , Multi-Thread Anwendungen, eingebettete Fenstersysteme,
Inter-Objekt Kommunikation, 2D Grafik Darstellung, Multimedia Unterstützung, HTML
Render Engine (WebKit), Netzwerkkonnektiviät, XML Unterstützung, Werkzeuge um
Skripts für Qt Anwendungen zu schreiben, Datenbankkonnektivitäten, Unterstützung
für verschiedene Sprachen
Qt kann auf unterschiedliche Weise installiert werden. Die Firma Nokia, die seit 2008 im Besitz
von Qt ist, stellt die Quelltextdateien zur Verfügung. Mit diesen Quellen kann eine ganz persönlich
angepasste Installation erfolgen. Weiterhin werden Installationspakete angeboten, die eine Übersetzung der Quellen für die unterschiedlichen Rechnerplattformen und verschiedenen Betriebssysteme
beinhalten. Durch diese kann eine sofortige Installation erfolgen und das Qt Framework genutzt
werden. In dieser Arbeit wird Qt für die grafische Oberfläche von ComsolGridQt verwendet. Die
Version der verwendeten Qt Installation ist 4.7.0 mit der Revisionsnummer 1c0f52a091.
2.6 Programmiersprachen
Um diese Arbeit verstehen zu können, muss der Leser ein wenig Programmiererfahrung mitbringen.
Es ist wünschenswert, wenn der Leser sich mit objektorientierter Programmierung (OOP) auskennt. Es ist nicht verkehrt, ein Basiswissen über Thread-Programmierung zu haben [31, 8]. Für die
Leser, die eventuell das ComsolGrid Framework verwenden wollen, wäre es gut zu wissen, wie
ein Makefile erstellt und angewendet wird [24]. Die Quellen dieser Arbeit können mit den Compilern gcc bzw. g++ compiliert werden [15]. Sprachdialekte wie Extensible Markup Language (XML)
und HyperText Markup Language (HTML) sollten zumindest ansatzweise bekannt sein. Ein Wissen
über Unterschiede einer 32-Bit und 64-Bit Rechnerplattform ist hilfreich, um zu erkennen wieso
verschiedene Plattformdefinitionen in dieser Masterarbeit von Belang sind.
17 http://www.opengl.org
20
- Ein Industriestandard für Grafikbearbeitungen in 3D.
Kapitel 3
Bisherige Arbeiten auf diesem Gebiet
Gehirn: ein Organ, mit dem wir denken, dass wir denken.
Ambrose Bierce
In diesem Kapitel wird kurz auf bisherige Arbeiten eingegangen. Diese Arbeiten beschäftigen sich
mit dem Thema BOINC, BOINC Wrapper und verteilten Applikationen. Es wird erwähnt ob von
bisherigen Arbeiten partizipiert werden kann.
3.1 Wrapper Implementierungen
Das BOINC Framework liefert ein Beispiel für eine Wrapper Implementierung. Dieser Wrapper
liest aus einer Datei die Aufgaben (engl. Tasks) und führt diese Tasks sequentiell aus. Der Wrapper
unterstützt die Erstellung einer Checkpoint Datei. Das Problem bei dieser Checkpoint Datei ist, dass
der Wrapper nur die einzelnen Schritte zwischen mehreren Tasks erkennt und diese in der Checkpoint Datei als Status speichern kann. Das heißt, falls z.B. drei Tasks in der Datei vorhanden sind
und der erste Task benötigt durchschnittlich fünf Minuten zur Lösung, der zweite Task 54 Minuten
und der letzte Task eine Minute, dann ist es wahrscheinlich, dass der zweite Prozess sehr oft unterbrochen wird. Ob ein Prozess unterbrochen wird oder nicht, liegt am Nutzerverhalten der Anwender und wie die Anwender die Einstellungen im BOINC Manager vorgenommen haben. Weiterhin
könnte es sein, dass der Task unterbrochen werden muss, da eventuell das Pausieren nicht für den
Task ausgeführt werden kann. Unter Umständen wird der Task alle zehn Minuten abgebrochen und
neu gestartet. Dieser Task könnte dann zu einer Langzeitaufgabe mutieren, wie sie bisher nur aus
Klimaberechnungsmodellen bekannt sind1 . Dieser BOINC Wrapper leitet die Ausgaben in Dateien
um, auch die Eingaben für ein Programm werden umgeleitet. Wenn eine Applikation eine Eingabe benötigt, muss diese vorher in einer Datei zeilenweise aufgeführt werden. Die Applikation liest
diese Zeilen als einzelne Eingabebefehle ein. Dies ist ein sehr fehleranfälliges Verfahren. Wenn z.B.
Zahlen als Eingabe erwartet werden, dann können Zeicheneingaben den Task zum Absturz bringen.
Noch schlimmer, es könnten falsche Ergebnisse berechnet werden.
Weiterhin existiert ein zweiter Wrapper mit dem Namen GenWrapper [23]. Dieser kann wie der
BOINC Wrapper mehrere Tasks aufnehmen, welche in einem Shell-Skript aufgeführt sind und in
einer virtuellen Maschine ausgeführt werden. In dieser virtuellen Maschine sind Linux Standardwerkzeuge enthalten, u.a. tar, awk, sed, zip, etc. Durch diese Werkzeuge können viele kleine Aufgaben bewerkstelligt werden. Wenn eine Berechnung z.B. Dateien aus einem Archiv erhält, können
diese entpackt und zur Simulation hinzugefügt werden. Dem GenWrapper ist es egal welche Tasks
in dem Shell-Skript definiert sind, sie werden einfach ausgeführt und nach jedem Schritt kann eine
1 http://climateprediction.net
- Ein BOINC Projekt um Wettervorhersagen zu berechnen.
21
3.2 Matlab und BOINC
Bisherige Arbeiten auf diesem Gebiet
Checkpoint Datei erstellt werden. Dieser Wrapper hat auch wie beim ersten Wrapper das Problem,
das Arbeitspakete zu Langzeitsimulationen mutieren können.
3.2 Matlab und BOINC
In der Vergangenheit wurden Anstrengungen betrieben Matlab mit BOINC zu verheiraten [6]. Es
wurde ein System entwickelt mit dem es möglich ist sequentiell arbeitende Matlab Programme auf
eine parallel arbeitende und verteilte Infrastruktur zu portieren. Dies wurde erfolgreich für ein Videound Bildverarbeitungssystem durchgeführt.
In [14] wird ein Projekt vorgestellt, dass sich zur Aufgabe gemacht hat ein Programm zu schaffen, dass es ermöglicht verschiedenste Legacy Applikationen innerhalb eines BOINC Projekts auszuführen. Es gibt erste Ergebnisse und Kennziffern über die Performance, allerdings keine öffentlich
zugängliche Version bzw. Auflistung über die unterstützten Legacy Applikationen.
22
Kapitel 4
ComsolGrid Framework
Größte Anstrengungen führen nicht zum Ziel, wenn sie nicht von umfassendem
Wissen geleitet werden. Denn was man nicht versteht, lässt sich auch nicht verbessern.
W. Edwards Deming
4.1 Grundidee
Abbildung 4.1 zeigt die Grundidee von dem ComsolGrid Framework. Das Grundprinzip des BOINC Framework wird übernommen, so dass das System im Prinzip jederzeit mit weiteren wissenschaftlichen Applikationen gestartet werden kann. Die linke Seite in der Abbildung 4.1 zeigt die
Systemkomponenten der Serverinstallation (nachfolgend „Projektserver“ genannt). Der Projektserver beinhaltet das BOINC Projekt „Comsolwrapper“. Weiterhin ist der Apache Webserver für die
Verarbeitung der Benutzeranfragen, die Schnittstelle ComsolGridFCGI zur Projektadministration
und eine MySQL Datenbank für die Datenverwaltung vorhanden.
Der Projektserver besitzt eine klare Struktur der Kommunikationswege. Die Datenbank kann nur
gelesen und zur Speicherung von Daten genutzt werden. Sie selber besitzt keine „Intelligenz“ oder
aktiven Komponenten um Zugriffe nach Außen zu ermöglichen. Der Apache Webserver greift als
einzelne Instanz auf die Daten im BOINC Projekt zu, d.h. die Webserverkomponente dient lediglich
als Schnittstelle zum BOINC Projekt. Das BOINC Projekt besitzt eigene Programmskripts und
Dateien um eine Webseite darzustellen und um die Administration durch eine Webschnittstelle zu
ermöglichen. Mit den Programmskripts aus dem BOINC Projekt, kann auf die Datenbankeinträge
zugegriffen und diese editiert oder gelöscht werden. ComsolGridFCGI ist die Schnittstelle zum Simulanten. Im Abschnitt 4.6 wird näher auf die Schnittstelle ComsolGridFCGI eingegangen.
Die rechte Seite der Abbildung 4.1, zeigt die Komponenten der zum Projektserver verbundenen
Benutzer. Beim Benutzer ist mindestens der BOINC Client zu installieren. Der BOINC Manager
ist optional, wird aber empfohlen um eine bessere Kontrolle des BOINC Clients zu haben [2, 1].
Um eine erfolgreiche Zusammenarbeit mit dem Projektserver zu ermöglichen, sind Änderungen am
BOINC Manager vorgenommen worden. Die Programmlogik wurde um die Möglichkeit erweitert,
dass automatisch die installierten COMSOL Multiphysics Versionen ermittelt werden. Dadurch erhält der Benutzer vom Projektserver die passenden Arbeitspakete. Auf diese Modifikationen wird
in Abschnitt 4.11 in mehr Detail eingegangen. Die Softwarekomponenten ComsolGridStarter (vgl.
Abs. 4.7) und ComsolGridQt (vgl. Abs. 4.16) sind in dieser Arbeit konzipiert und implementiert
worden.
Die Kommunikation zwischen den Benutzern und dem Projektserver kann auf einer unsicheren
(unverschlüsselten) oder abgesicherten (verschlüsselten) Verbindung statt finden. Prinzipiell findet
die Kommunikation mit dem Hypertext Transfer Protocol (HTTP) statt. Das HTTP ist im ISO/OSI
23
4.2 Automatische Installation eines BOINC Projekts
Abbildung 4.1: Verteilungsdiagramm mit einem Blick auf die ComsolGrid Komponenten
Schichtenmodell in der Anwendungsschicht angesiedelt und kann durch geringen Programmieraufwand und der Einbindung von vorhandenen Programmierbibliotheken verwendet werden. In
dieser Arbeit wird die FastCGI Bibliothek verwendet. Diese Bibliothek ermöglicht eine einfache
Definition und Erstellung einer HTTP-Kommunikation [29, 30, 10]. Der Apache Webserver wird
für die unsichere und sicherere Kommunikation konfiguriert. Für diesen Zweck wird das Secure
Socket Layer (SSL) zum Webserver hinzugefügt. Die Idee ist, dass die Benutzer über die unsichere
Verbindung und die Anwender und Simulanten über die sicherere Verbindung mit dem Projektserver
kommunizieren. Im Abschnitt 4.16 wird auf die Beweggründe eingegangen, weshalb die Anwender
und Simulanten eine sichere Verbindung verwenden sollen. Die Benutzer benutzen die unsichere
Verbindung, da keine sicherheitsrelevanten Daten transferiert werden müssen. Das BOINC Framework versendet nach der ersten Anmeldung per Definition, keine Namen oder Passwörter zwischen
dem BOINC Client und den BOINC Projektservern. Auf diese Besonderheit wird in Abschnitt 4.3
eingegangen.
In dieser Arbeit wurde die erfolgreiche Umsetzung mit dem Betriebssystem Linux erreicht.
Die Installation eines BOINC Projekts ist sehr zeitaufwändig und fehleranfällig. Die Hauptentwickler des BOINC Frameworks liefern ein Programm mit, durch dessen Aufruf und der Angabe von
verschiedenen Parametern, eine Grundinstallation eines BOINC Projekts durchgeführt wird. Das
Programm trägt den Namen $make_project und befindet sich im Unterordner tools/ der BOINC
Quellen. Die nachfolgenden Einstellungen sind dabei am wichtigsten:
1. Datenbankzugriffsdaten (Benutzername, Zugriffspasswort), Name der zu installierenden oder
vorhandenen Datenbank,
2. der Name des Computers/Hosts, der einmalig sein muss und am besten ein Fully-Qualified
Domain Name (FQDN) sein sollte. Nur der lokale Knotenname ohne Vaterdomain kann zu
Problemen führen1.
1 Es hat sich gezeigt, dass die Verwendung von einer IP-Adresse oder FQND fehlerfrei funktioniert. Es ist zu beachten,
dass dieser gewählte FQND Eintrag in einigen Dateien übernommen wird. Der FQND Eintrag sollte mit Bedacht gewählt
sein, eine spätere Änderung kann zu Laufzeitfehlern im Projekt führen.
24
3. Weiterhin muss ein Standardbenutzer, der als Hauptadministrator dient und für die spätere
BOINC Administrationsseite eines Projekts benötigt wird, angegeben werden.
4. Das Zielverzeichnis des BOINC Projekts, auf dem Serverknoten, sollte definiert sein und
5. weiterhin können nicht kritische Werte angegeben werden. Diese Werte betreffen eine optional zu installierende Testapplikation, den Ordnernamen der Administrationsseite und den
Webnamen zum Zugreifen auf den BOINC Projektscheduler.
Die oben Punkte eins bis vier sind immer zu beachten und haben einen Einfluss auf die Integrität
eines BOINC Projektes, d.h. die Werte müssen zueinander passen und valide sein. In dieser Masterarbeit wird auf diese Werte nicht näher eingegangen, diese liegen nicht im Fokus dieser Ausarbeitung. Es ist nicht ergiebig, die Webseiten für die Administration oder der Schedulerprogramme
eines BOINC Projektes an einem nicht Projekt bezogenen Ort zu installieren2 .
In dieser Arbeit wurde ein Programm zur Erstellung einer Standardinstallation implementiert.
Dieses Programm ist als Skript für die Bash-Konsole umgesetzt (vgl. Anhang B.2). Der Aufruf dieses
Programms ist trivial und wird durch den Befehl $./make_wrapper_project comsolwrapper initiiert. comsolwrapper ist in diesem Fall der Name des Projekts, das installiert wird. Das Programm
nimmt folgende Einstellungen vor:
• Die Projektwebseite ist unter der Adresse http://192.168.1.200/comsolwrapper zu erreichen.
• Die Adresse http://192.168.1.200/comsolwrapper_ops wird für die Projektadministration verwendet.
• Scheduleranfragen werden an ein Unterprogramm, im Ordner der Adresse
http://192.168.1.200/comsolwrapper_cgi, gestellt.
• Die Konfigurationsdateien sind angepasst und für eine wissenschaftliche Applikation mit dem
Namen comsolstarter vorbereitet.
• Plattformdefinitionen werden zum Projekt hinzugefügt, z.B. x86_64-pc-linux-gnu für eine
Intelarchitektur mit 64-Bit Linux Betriebssystem.
• Applikationen im Dateiordner $ROOTPRE/sources/comsol_wrapper/apps/comsolstarter/ werden zum Projekt hinzugefügt.
• Eingabe-/Ergebnisschablonen aus dem Ordner
$ROOTPRE/sources/comsol_wrapper/templates/ werden hinzugefügt.
• Sicherheitsmechanismen im Webseitenordner des Projekts werden angepasst, so dass eine Anmeldung auf der Administrationsseite ermöglicht wird und u.a. Aktionen wie das Abbrechen
von Arbeitspaketen möglich ist.
• Es werden die Dateiordner mit den richtigen Zugriffsrechten gesetzt.
Das Programm erstellt beim Aufruf automatisch eine Apache Webserver Konfiguration. Diese erstellte Datei enthält die Aliase zu den oben erwähnten Adressen: Web-, Administration- und Schedulerseite. Eine manuelle Übernahme dieser Eintragungen, in die Apache Webserver Konfiguration,
ist notwendig. In den meisten Fällen reicht ein kurzer Aufruf wie $sudo cat comsolwrapper.httpd
.conf » /etc/apache2/httpd.conf. Mit diesem Aufruf wird der Inhalt der Datei zu der Apache
Webserver Konfiguration hinzugefügt. Dieser Aufruf muss ggf. an die eigenen Bedürfnisse und
Wünsche angepasst werden. Eine Installationsanleitung ist auf einschlägigen Webseiten zu finden
[33, 34].
2 Das dies auch anders sein kann, zeigt Abbildung 2.6. Der Webserver und der Scheduler können auf unterschiedlichen
Systemen installiert sein.
25
4.3 Sicherheitsaspekte und Authentifizierung
4.3 Sicherheitsaspekte und Authentifizierung
Die Kommunikation zwischen den Benutzern, Simulanten und Anwendern zum Projektserver, findet
auf zwei Wegen statt. Zum einen existiert eine Konfiguration für eine sichere Verbindung, durch das
Hinzufügen des SSL zum Apache Webserver. SSL wird in diesem Fall als Modul hinzugefügt und
kann sofort für die gesamte Webserverkommunikation verwendet werden [36, 37]. Zum anderen
findet eine unverschlüsselte Kommunikation statt, die für die Benutzer vorhanden ist.
Die sichere Verbindung dient der Erstellung von Parameterstudien. Das Erstellen von Parameterstudien bedarf besonderer Zugriffsrechte, weshalb Authentifizierungsdaten zwischen dem Simulanten und dem Projektserver transferiert werden. Das HTTP ist ein Klartextprotokoll, d.h. jeder der
auf der Netzwerkverbindung den Datentransfer abhört, kann diese Authentifizierungsdaten mitlesen
und für sich verwenden und so das System korrumpieren.
Die Benutzer benötigen keine sichere Verbindung. Das BOINC Framework ist von der Architektur so beschaffen, dass keine sicherheitskritischen Daten versendet werden. Jeder am BOINC Projekt
teilnehmende Benutzer, wird durch einen Hash-Wert3 eindeutig beschrieben. Durch diesen HashWert kann ein Host in Kombination mit der E-Mail Adresse des Benutzers, respektive die des Simulanten bei vorgegebener Installation, eindeutig als Benutzer innerhalb eines Projekts zugewiesen
werden. Sollte der Wert nicht zu dem in der Datenbank passen, wird der Zugriff zum Projektscheduler abgelehnt. Dadurch ist die Sicherheit gegen unerlaubte Zugriffe gewährleistet.
Der Simulant muss bei der Erstellung einer Parameterstudie, in der Anwendung ComsolGriQt
seinen Benutzernamen, seine E-Mail Adresse und das passende Passwort angeben. Das Passwort
eines Simulanten und denen der Anwender/Benutzer wird im BOINC Framework durch einen HashWert gebildet. Dieser Hash-Wert ist ein Message Digest 5 (MD5) Wert [21] und wird aus der zusammengesetzten Zeichenkette aus Passwort und E-Mail Adresse gebildet. Das Listing 4.1 zeigt den
C++-Programmausschnitt zur Erstellung dieses Hash-Wertes. Zeile 12 zeigt außerdem, wie dieser Wert in Verbindung des Benutzernamens zur Authentifizierung des Benutzers durch eine SQLAbfrage realisiert wird.
Der Simulant muss nicht für alle Anfragen die Authentifizierungsdaten mitgeben. Bei falschen
Authentifizierungsdaten wird eine entsprechende Fehlermeldung ausgegeben. Diese weist allerdings
nur darauf hin, dass die Kombination aus Benutzernamen, E-Mail Adresse und Passwort nicht mit
den Daten in der Datenbank übereinstimmt. Welche Anfragen diese Authentifizierungsdaten benötigen, wird in Abschnitt 4.12 beschrieben.
Weitere Sicherheitsrestriktionen sind denkbar. Der Netzwerkadressbereich für die Simulanten
könnte eingeschränkt werden, so dass nur bestimmte Abteilungen in einer Firma oder Institution
auf die Administrationsschnittstellen zugreifen können. Diese Art der Absicherung wurde in dieser
Masterarbeit nicht weiter beachtet. Dies hat nichts mit dem ComsolGrid Framework zu tun, sondern
kann durch weitere Funktionen abgedeckt werden, u.a. Betriebssystemfunktionen wie $ipchains
oder $iptables [25].
1
2
3
4
...
r e m o v e _ q u o t e s ( u s er n am e ) ;
remove_quotes ( email ) ;
remove_quotes ( password ) ;
5
6
7
8
9
10
h a s h w r a p p e r ∗ h = new md5wrapper ( ) ;
i f ( h == NULL) {
return 0;
}
p a s s w o r d = h−>g e t H a s h F r o m S t r i n g ( p a s s w o r d+ e m a i l ) ;
11
3 Dieser Hash-Wert bildet sich aus dem Domainnamen, der IP-Adresse, dem freien Speicherplatz auf der Festplatte und
der aktuellen Zeit.
26
12
13
4.4 Benutzerrollen und deren Definitionen
s t d : : s t r i n g q= " where name = ’ " + u s er n am e + " ’ and p as s w d _ h as h = ’ " + p a s s w o r d+ " ’ " ;
...
Listing 4.1: Bildung des Passwort Hash-Wertes für die Authentifizierung an einem BOINC Projekt
4.4 Benutzerrollen und deren Definitionen
Jeder Simulant und Anwender erhält innerhalb eines Projekts eine Benutzerrolle. Benutzerrollen
beschreiben Regelsätze, um Zugriffe auf Ressourcen zu regulieren, z.B. der Simulant XY darf nur
Arbeitspakete für das Projekt IJ erstellen.
1
2
3
4
5
6
7
CREATE TABLE ‘ co m s o lw r ap p er ‘ . ‘ c o m s o l g r i d _ r o l e s ‘ (
‘ id ‘ INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
‘ u s e r i d ‘ INT NOT NULL ,
‘ ap p id ‘ INT NOT NULL ,
‘ r o l e ‘ INT ( 5 ) NOT NULL ,
‘ d e s c r i p t i o n ‘ VARCHAR( 254 ) NOT NULL
) ENGINE = MYISAM ;
Listing 4.2: Datenbanktabelle zur Umsetzung von Benutzerrollen
Benutzerrollen sind nicht bei der Grundausstattung eines BOINC Projektes vorhanden und müssen
durch eigene Umsetzung beigesteuert werden. Zu diesem Zweck wurde eine neue Datenbanktabelle zur MySQL Datenbankstruktur hinzugefügt. Das Listing 4.2 zeigt das SQL-Statement, um die
benötigte Tabelle in der Datenbank zu erstellen. Es werden fünf Felder erstellt, die nachfolgend
beschrieben werden:
id Dies ist eine eindeutige Identifikationsnummer für einen Rolleneintrag und wird automatisch bei
neuen Einträgen um Eins erhöht. Dieser Wert gilt allein für eine eindeutige Zuordnung und
hat keinen weiteren Einfluss auf die logische Struktur dieser Tabelle. Mit diesem Zahlenwert
soll ein eindeutiges Modifizieren oder Löschen des Eintrags möglich sein.
userid Der Wert in diesem Feld beschreibt die Zuordnung der Benutzerrolle zu einem registrierten
Benutzer.
appid Dies ist eine Identifikation des Benutzers zu einer Applikation. Dadurch können bestimmte
Benutzerrollen für unterschiedliche wissenschaftliche Applikationen definiert werden.
role Dieser Wert beschreibt die Benutzerrolle und ist in den ComsolGrid Quellen hard-codiert
und die logische Struktur eines Werts kann zur Laufzeit des Programms nicht geändert werden. In der Testversion sind folgende Rollen definiert: (1) Administrator, (2) Developer (im
Deutschen „Entwickler“ ), (3) Scientist (im Deutschen „Wissenschaftler“) und (4) Tester. Die
Rollen werden in der Tabelle 4.1 näher beschrieben.
description Dies ist ein beschreibender Text, mit einer festgelegten maximalen Zeichenkettenlänge.
Diese Beschreibung muss kurz und prägnant sein, z.B. Benutzer dürfen Arbeitspakete für Projekt XY erstellen.
Im Abschnitt 4.12 wird beschrieben, welche Kontrollbefehle in den jeweiligen Benutzerrollen ausgeführt werden können, speziell in der Testversion des ComsolGrid Framework. Zur Unterscheidung
der Rollen und zur Ermöglichung einer eigenen Implementierungsstrategie, sind die Rollen mit den
Standardwerten aus Listing 4.3 definiert. Es können weitere Rollendefinitionen zum ComsolGrid
Framework hinzugefügt werden. Es ist eine nochmalige Kompilierung der ComsolGrid Quellen
nötig, wenn an den Rollen etwas modifiziert wird.
27
4.5 ComsolGrid Framework - Architektur und Abhängigkeiten
Rollenname
Administrator
Beschreibung
Diese Benutzer dürfen neue Versionen von wissenschaftlichen
Applikationen zu einem BOINC Projekt hinzufügen und deren
Konfigurationen ändern.
Benutzer mit dieser Rollendefinition dürfen alle Funktionen
nutzen.
Mitglieder dieser Gruppe, dürfen für die definierten wissenschaftlichen Applikationen Arbeitspakete erstellen, löschen und
abbrechen. Ergebnisse dürfen von diesen Benutzern eingesehen
und als brauchbar markiert werden.
Diese Rolle wird hauptsächlich von einem ComsolGrid Framework Entwickler verwendet und ist nur für Testzwecke vorhanden. In einem produktiven System, sollte diese Rolle gelöscht
werden. Das Testsystem enthält zum Teil Regelsätze die es erlauben, dass die Rolle Tester jeden Zugriff auf alle Funktionen
erhält.
Developer
Scientist
Tester
Tabelle 4.1: Rollenbeschreibungen der Zugriffsregelungen bei einem ComsolGrid Projekt
1
2
3
4
5
6
/ / Roles
# d e f i n e CG_UNKNOWN
# d e f i n e CG_ADMINISTRATOR
# d e f i n e CG_DEVELOPER
# d e f i n e CG_SCIENTIST
# d e f i n e CG_TESTER
0
1
2
4
8
//
//
//
//
//
00000000 b
00000001 b
00000010 b
00000100 b
00001000 b
Listing 4.3: Definition der Benutzerrollen im ComsolGrid Framework
Alle Funktionalitäten, wenn möglich, wurden in einer Bibliothek im C++ Namensraum ComsolGrid
implementiert. Die Bibliothek hat den Namen libcomsolgrid.so. Die Abhängigkeiten dieser Bibliothek zu den eingebundenen Bibliotheken und implementierten Anwendungen sind in der Abbildung
4.2 aufgestellt. Der linke obere Bereich zeigt die Bibliotheken die von dem BOINC Framework mitgeliefert werden. Oben rechts stehen Bibliotheken die entweder von den BOINC Bibliotheken oder
direkt von der libcomsolgrid.so genutzt werden. Die Bibliothek libh++.so bietet Funktionen
um mit MD5 Kodierungen umzugehen [16]. Der untere Bereich zeigt die Applikationen, die in dieser Arbeit implementiert sind oder modifiziert worden. Die Applikationen ComsolGridFCGI, ComsolGridStarter, ComsolGridQt und BOINC Manager benötigen die Bibliothek libcomsolgrid.so
um lauffähig zu sein, deshalb ist in der Abbildung eine Komposition als Assoziation gezogen. Der
ComsolValidator und ComsolAssimilator sind in der aktuellen Testversion nicht von der Bibliothek
abhängig, dies kann sich in weiteren Entwicklungen ändern.
Die Bibliothek libcomsolgrid.so besitzt einige Implementierungen, die dem Entwickler bei
der Erstellung einer neuen wissenschaftlichen Applikation eine Erleichterung bieten. In Listing 4.5
sind die Prototypen der Implementierungen aufgelistet und jeweils eine kleine Erläuterung dazu
aufgeführt. Für eine komplette Referenz, inklusive Funktionsaufrufgraphen oder Abhängigkeitsdiagrammen der einzelnen Elemente, wird auf die Quellen des ComsolGrid Frameworks verwiesen. Die
Quellen wurden mit einer Doxygen4 Formatierung ausgestattet. Mit dieser Formatierung wird eine
4 http://www.doxygen.org
28
- Ein Dokumentationssystem für die Programmiersprachen C/C++, Java und IDL.
Abbildung 4.2: Architektur des ComsolGrid Frameworks und den implementierten Anwendungen
sehr gut strukturierte Dokumentation generiert, verschiedene Ausgangsformate können als Zielformat ausgewählt werden, z.B. HTML oder Manpages. Es gilt zu beachten, dass einige in Listing 4.5
erwähnten Prototypen, in den nachfolgenden Abschnitten erläutert werden und daher nicht mit einer
hohen Detailtiefe beschrieben sind.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
/ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗
∗ S t r u k t u r e n
∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗ ∗ /
/ / S t e l l t e i n e B e n u t z e r r o l l e dar .
s t r u c t COMSOL_ROLES {}
/ / E r l e i c h e r t den Z u g r i f f a u f d i e B e n u t z e r o l l e n d e f i n i t i o n e n i n d e r D a ten b a n k .
s t r u c t DB_COMSOL_ROLES {}
/ / S t r u k t u r zum E i n l e s e n d e r ’ co m s o l . xml ’ D a t e i i n d e r C o m s o l G r i d S t a r t e r
Implementierung .
s t r u c t ComsolXML {}
/ / P a r s t e i n e A u f l i s t u n g von COMSOL M u l t i p h y s i c s V e r s i o n e n a u s ein em XML−Baum .
s t r u c t VersionXML {}
/ / P a r s t e i n e A u f l i s t u n g von P l a t f o r m d e f i n i t i o n e n a u s ein em XML−Baum .
s t r u c t PlatformXML {}
/ / P a r s t e i n e L i s t e von AppXML E l e m e n t e n .
s t r u c t AppsXML {}
/ / P a r s t e i n e A u f l i s t u n g von A p p l i k a t i o n s d e f i n i t i o n e n a u s ein em XML−Baum .
s t r u c t AppXML {}
/ / Parst d ie I n fo r m a tio n en ueber P r o z es s in fo r m a tio n en .
s t r u c t StatusXML {}
/ / E n th a elt I n fo r m a tio n en ueber einen Parametersatz , wich tig fu er ein e
Parameterstudie .
s t r u c t P a r a m e t e r {}
/ / E n t h a e l t d i e I n f o r m a t i o n e n beim H o ch la d en e i n e r n eu en P a r a m e t e r s t u d i e .
s t r u c t ComsolStudyXML {}
24
25
26
27
28
29
30
31
32
33
/ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗
∗ K l a s s e n
∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗ ∗ /
/ / Uebernimmt d i e K o n t r o l l e e i n e s P r o z e s s e s und v e r a r b e i t e t g e s e n d e t e S i g n a l e w ie
SIGSTOP , SIGUSR , SIGCONT .
c l a s s Task {}
/ / E r s t e l l t e i n e n T h r ea d d e r I n f o r m a t i o n e n u e b e r P r o z e s s e e i n h o l t .
c l a s s I n f o s {}
/ / E r m i t t e l t d i e V e r s i o n s d e f i n i t i o n e n a u s e i n e r V e r s i o n s z e i c h e n k e t t e von COMSOL
Multiphysics .
c l a s s V e r s i o n s {}
34
29
35
36
37
38
39
40
41
42
43
44
45
46
47
/ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗
∗ T y p d e f i n i t i o n e n
∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ /
/∗
∗ L i s t e n d e f i n i t i o n e n um m eh r er e E l e m e n t e a b s p e i c h e r n
∗ z u ko en n en .
∗/
typedef s td : : vector < s td : : s tring > S t r i n g L i s t ;
t y p e d e f s t d : : v e c t o r <PlatformXML > P l a t f o r m L i s t ;
typedef s t d : : vector <Versions > V e r s i o n s L i s t ;
t y p e d e f s t d : : v e c t o r Range ;
t y p e d e f s t d : : v e c t o r <Range > Ranges ;
t y p e d e f s t d : : v e c t o r <AppXML> A p p L i s t ;
48
49
50
51
52
53
54
55
56
57
/ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗
∗ F u n k t i o n s p r o t o t y p e n
∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗∗ ∗ ∗ ∗∗ ∗ ∗ /
/ / E r m i t t e l t d i e B e n u t z e r r o l l e e i n e s B e n u t z e r s , S i m u l a n t e n und Anwenders .
i n t r o l e _ u s e r ( DB_USER u s e r , DB_COMSOL_ROLES &r o l e , FCGI_FILE ∗ l o g f i l e )
/ / P r u e f t ob d e r B e n u t z e r , S i m u l a n t o d e r Anwender s i c h r i c h t i g a u t h e n t i f i z i e r t .
i n t a u t h e n t i c a t e _ u s e r ( DB_USER &u s e r , s t d : : s t r i n g username , s t d : : s t r i n g em ail , s t d
: : s t r i n g p as s w o r d , FCGI_FILE ∗ l o g f i l e =NULL)
/ / P a r s t den XML−Baum m i t A u t h e n t i f i z i e r u n g s d a t e n .
i n t p a r s e _ a u t h ( FILE ∗ in , DB_USER &u s e r , FCGI_FILE ∗ l o g f i l e )
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
/ ∗ ∗∗∗∗∗∗∗∗∗∗
∗ F u n k t i o n e n f u e r C o m s o l G r i d S t a r t e r und dem BOINC Manager
∗∗∗∗∗∗∗∗∗∗ ∗ /
/ / E r m i t t e l t d i e PID d e s e r s t e n K i n d p r o z e s s e i n e r b e s t i m m t e n
P r o z e s s i d e n t i f i k a t i o n s n u m m e r ( PID ) .
p i d _ t g e t F i r s t C h i l d r e n ( p i d _ t p id , u i d _ t u id , char ∗ p a t t e r n )
/ / S u c h t nach a u s f u e h r b a r e n COMSOL M u l t i p h y s i c s A p p l i k a t i o n e n .
V e r s i o n s L i s t lookup ( )
/ / S u c h t nach a u s f u e h r b a r e n COMSOL M u l t i p h y s i c s A p p l i k a t i o n e n .
s t d : : s t r i n g l o o k u p ( ComsolGrid : : ComsolXML ∗ cxml )
/ / Kopiert eine Datei .
i n t f i l e c o p y ( s t d : : s t r i n g src , s t d : : s t r i n g dest )
/ / S p e i c h e r t Daten i n e i n e r D a t e i .
i n t s t o r e ( char ∗ d a t a , i n t l e n , s t d : : s t r i n g d e s t )
/ / E r m i t t e l t den Typ d e r A n f r a g e vom B e n u t z e r , S i m u l a n t e n .
i n t cxmlMode ( char ∗ l i n e )
/ / E r m i t t e l t den Typ e i n e r D a t e i .
i n t f i l e _ t y p e ( s t d : : i f s t r e a m &i f s )
/ / E r m i t t e l t den ’ f r a c t i o n _ d o n e ’ Wert d e r d u r c h f u e h r e n d e n S i m u l a t i o n .
char ∗ g e t P r o c e s s ( char ∗ p e r c e n t , i n t b u f s i z e , FILE ∗ f d )
/∗
∗ E r m i t t e l n d i e P a r a m eter d i e e v e n t u e l l i n e i n e r
∗ S i m u l a t i o n s d a t e i vo r h a n d en s i n d .
∗/
i n t p a r a m e t e r _ c o m s o l _ g e n e r a l ( s t d : : i f s t r e a m &i f s , s t d : : s t r i n g f i l e n a m e )
S t r i n g L i s t p a r a m e t e r _ c o m s o l 3 5 ( s t d : : i f s t r e a m &i f s , s t d : : s t r i n g f i l e n a m e )
S t r i n g L i s t p a r a m e t e r _ c o m s o l 4 0 ( s t d : : i f s t r e a m &i f s , s t d : : s t r i n g f i l e n a m e )
S t r i n g L i s t parameter_comsol ( s td : : s t r i n g filename )
86
87
88
89
90
91
92
93
94
30
/ ∗ ∗∗∗∗∗∗∗∗∗∗
∗ Funktionen fuer Z eichenketten
∗∗∗∗∗∗∗∗∗∗ ∗ /
/ / T e i l t e i n e Z e i c h e n k e t t e in E i n z e l e l e m e n t e , ’ elems ’ i s t das Trennwort .
S t r i n g L i s t& s p l i t ( s t d : : s t r i n g &s , char d elim , S t r i n g L i s t &elem s )
/ / T e i l e e i n e Z e i c h e n k e t t in E i n z e l e l e m e n t e , ’ delim ’ i s t das T r ennz eichen .
S t r i n g L i s t s p l i t ( s t d : : s t r i n g &s , char d e l i m )
/ / W a n d elt S c h r a e g s t r i c h e i n G e g e n s c h r a e g s t r i c h e um , von BOINC uebernommen .
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
4.6 ComsolGridFCGI - Serverschnittstelle für Parameterstudien
v o i d s l a s h 2 b a c k s l a s h ( char ∗ p )
/ / E n t f e r n t G a e n s e f u e s s c h e n , von BOINC uebernommen .
v o i d r e m o v e _ q u o t e s ( s t d : : s t r i n g &p )
/ / E r m i t t e l t d ie P o s i t i o n ein er Z e i c h e n k e t t e in ein er anderen Z e i c h e n k e t t e .
i n t s t r p o s ( char ∗ h a y s t a c k , char ∗ n e e d l e )
/ / L i e s t d i e n a e c h s t e Z e i l e a u s ein em S p e i c h e r p l a t z , Z e i l e n s i n d d e f i n i e r t m i t dem
Ende ’ n e e d l e ’ .
char ∗ l i n e ( char ∗ buf , i n t l e n , c o n s t char ∗ x m l p a r t , char ∗ n e e d l e )
/ / E n t f e r n t a l l e Zeichen ’ elem en ts ’ auf der l i n k e n S e i t e der Z e i c h e n k e t t e ’a ’ .
s t d : : s t r i n g l t r i m ( s t d : : s t r i n g &a , s t d : : s t r i n g e l e m e n t s )
/ / E n t f e r n t a l l e Zeichen ’ elem en ts ’ auf der r ech ten S e i t e der Z e i c h e n k e t t e ’a ’ .
s t d : : s t r i n g r t r i m ( s t d : : s t r i n g &a , s t d : : s t r i n g e l e m e n t s )
/ / R u f t ’ l t r i m ’ und ’ r t r i m ’ n a c h e i n a n d e r a u f .
s t d : : s t r i n g t r i m ( s t d : : s t r i n g &a , s t d : : s t r i n g e l e m e n t s )
/ / E n t f e r n t d i e Z eichen aus ’ c h a r a c t e r ’ in der Z e i c h e n k e t t e ’ t e x t ’ .
v o i d r e m o v e _ c e r t a i n _ c h a r a c t e r s ( s t d : : s t r i n g &t e x t , c o n s t char ∗ c h a r a c t e r )
/ / E n t f e r n t a l l e Z eichen aus s er d i e aus ’ c h a r a c t e r ’ in der Z e i c h e n k e t t e ’ t e x t ’ .
v o i d n o t _ r e m o v e _ c e r t a i n _ c h a r a c t e r s ( s t d : : s t r i n g &t e x t , c o n s t char ∗ c h a r a c t e r )
/ / E n t f e r n t a l l e Z eichen aus s er d i e aus ’ c h a r a c t e r ’ in der D a t e n k e t t e ’ data ’ .
v o i d n o t _ r e m o v e _ c e r t a i n _ c h a r a c t e r s ( c o n s t char ∗ d a t a , c o n s t i n t s i z e , char ∗
r e s u l t _ d a t a , i n t ∗ r e s u l t _ s i z e , c o n s t char ∗ c h a r a c t e r )
/ / E r m i t t e l t d i e E r w e i t e r u n g e i n e s D a tein a m en s .
s t d : : s t r i n g f i l e _ e x t e n s i o n ( s t d : : s t r i n g name )
116
117
118
119
120
121
/ ∗ ∗∗∗∗∗∗∗∗∗∗
∗ F u n k t i o n e n f u e r ComsolGridFCGI
∗∗∗∗∗∗∗∗∗∗ ∗ /
/ / E r s t e l l t d ie Eingabedaten fu er A r b e i t s p a k e t e .
S t r i n g L i s t c r e a t e _ i n f i l e s ( SCHED_CONFIG ∗ c o n f i g , char ∗ n am etp l , i n t s i z e , Ranges ∗
r a n g e s , i n t ∗ e r r o r , FCGI_FILE ∗ l o g f i l e , i n t ap p id , i n t w u _ h i g h e s t _ i d )
Die Applikation ComsolGridFCGI (nachfolgend „ComsolGridFCGI“ oder „Anwendung“ genannt)
ist nach dem ComsolGridStarter in Abschnitt 4.7, das zweit wichtigste Element im ComsolGrid
Framework. ComsolGridFCGI verarbeitet die eingehenden HTTP/XML-Requests der Simulanten
und erstellt die passenden Antworten (vgl. Abs. 4.12). Die Anwendung ist in C++ geschrieben,
verbindet sich zum Datenbankserver, verarbeitet XML-Bäume (vgl. Abs. 4.12), protokolliert die
Ereignisse in einer Protokollierungsdatei, läuft als Prozess im Apache Webserver, übernimmt die
Arbeitspaketerstellung (vgl. Abs. 4.14), liefert Informationen über Prozesse (vgl. Abs. 4.13), gibt
Auskunft über die installierten wissenschaftlichen Applikationen (s. Listing 4.18) und liefert bei
Fehler oder Erfolg der Verarbeitung, die richtigen Fehlernummern (s. Listing 4.21).
In Abbildung 4.3 ist das Zustandsdiagramm von ComsolGridFCGI abgebildet. Dies ist eine
abstrakte Sichtweise auf die implementierte Struktur und enthält nicht alle Zustände, sondern nur
die für die Grundstruktur elementaren Zustände. Der linke Bereich in der Abbildung stellt den Startprozess von ComsolGridFCGI dar. Argumente, die beim Starten angegeben sind, werden verarbeitet
und die Konfigurationsdatei wird eingelesen. Mit den Daten aus der Konfigurationsdatei wird eine
Datenbankverbindung hergestellt. Dies ist die Datenbank des BOINC Projekts, daher müssen in der
Konfiguration die selben Daten wie bei der BOINC Projektkonfiguration angeben sein. Eine Erleichterung ist implementiert, es wird standardmäßig die selbe Konfigurationsdatei geöffnet wie sie
auch beim BOINC Projekt verwendet wird. Der Standarddateiname der Konfigurationsdatei lautet
project.xml und daher reicht ein symbolischer Link auf diese Datei. Dieser symbolische Link
wird muss von der Konfigurationsdatei zu dem Dateiordner gesetzt werden, in dem sich ComsolGridFCGI befindet. Bevor auf eingehende Webanfragen reagiert wird, muss der Prozess für die
Prozessinformationsbeschaffung erstellt werden. In Abschnitt 4.13 wird erläutert, dass der Prozess
31
Abbildung 4.3: Das Zustandsdiagramm von ComsolGridFCGI
in einem eigenen Thread abläuft und kontinuierlich Informationen über definierte Prozesse einholt.
Somit stehen die Informationen sofort zur Verfügung, egal wann der Simulant oder Anwender diese
erfragt.
Nach den oben erwähnten Schritten, geht ComsolGridFCGI in den Wartezustand. Im Wartezustand wartet der Prozess auf eingehende Webanfragen, dies wird durch eine Dauerschleife realisiert
und die Funktion FCGI_Accept() liefert einen Wert ≥ 0 wenn eine Verbindung akzeptiert wurde.
Wenn eine Verbindung akzeptiert wurde, werden die Daten des Simulanten oder Anwenders
gelesen und der Typ der Anfrage ermittelt. Der Zustand „Anfrage Verarbeiten“ ist als Switch-Case
Konstrukt aus mehreren If-Else Elementen implementiert. Für jeden Typ der Anfrage existiert ein
Unterzweig. In diesen Unterzweigen wird die richtige Verarbeitung durchgeführt und eine Antwort
für den Simulanten oder Anwender erstellt.
Folgende Dinge müssen bei der Verwendung von ComsolGridFCGI beachtet werden!
Wenn ComsolGridFCGI innerhalb eines Apache Webserver gestartet ist, dann müssen Zugriffsbeschränkungen auf Verzeichnisse innerhalb des BOINC Projektes geändert werden. ComsolGridFCGI läuft in diesem Fall mit der Benutzer- und Gruppenzugehörigkeit des Apache Webserver. Bei
einer Linux Ubuntu Systemumgebung ist das der Benutzer www-data und die Gruppe www-data. Ein
BOINC Projekt sollte, nach den Vorschlägen aus der BOINC Internetgemeinde, mit dem Benutzer
boincadm und der Gruppe boincadm gestartet werden.
Weiterhin erstellt ComsolGridFCGI bei der Verarbeitung zur Erstellung von Parameterstudien
Dateien, die für Arbeitspakete relevant und benötigt werden. Diese haben bei der Erstellung den
Benutzereigentümer und die Gruppenzugehörigkeit www-data. Wenn diese Dateien in einem Unterordner des BOINC Projektes mit Zugriffsbeschränkung erstellt werden sollen, dann funktioniert
dies nicht, aufgrund der Tatsache, dass die Zugriffsrechte dies nicht zulassen. Somit können keine
Parameterstudien angelegt werden. Es gibt mehrere Möglichkeiten dieses Problem zu beheben:
1. Der Benutzer boincadm wird zu der Gruppe www-data hinzugefügt und die Gruppenrechte
für die Up-/Download-Dateien auf Lesen+Schreiben gesetzt, oder
2. der Apache Webserver läuft mit den selben Benutzer- und Gruppenidentifikationen wie das
BOINC Projekt.
Es ist schwer zu sagen welche Möglichkeit die bessere ist. Dies wird dem Administrator oder den Restriktionen der Firma überlassen. Für die Testzwecke in dieser Masterarbeit ist die erste Möglichkeit
gewählt worden.
32
4.7 ComsolGridStarter - BOINC Wrapper für COMSOL
ComsolGridFCGI liest eine Konfigurationsdatei ein, diese hat den Namen comsol_fcgi.xml.
In dieser Datei können Angaben zum Speicherort der hoch geladenen Dateien gemacht werden.
Dadurch können die oben genannten Probleme umschifft werden, da ein Zielverzeichnis mit passenden Zugriffsrechten definiert sein kann. Die unterstützten Parameter sind im Listing 4.4 aufgelistet.
1
2
3
4
5
6
7
<comsol_fcgi >
< l o g f i l e > / home / boincadm / p r o j e c t s / c o m s o l w r a p p e r / l o g _ v i s u a l g r i d −1/ c o m s o l _ f c g i . lo g
</ l o g f i l e >
 / home / boincadm / p r o j e c t s / c o m s o l w r a p p e r / c o m s o l g r i d _ u p l o a d / 
 / home / boincadm / p r o j e c t s / c o m s o l w r a p p e r / t e m p l a t e s / 
10 
<wu_name_tpl > w u _ co m s o lg r i d _%d_%05d < / wu_name_tpl >
</ c o m s o l _ f c g i >
Listing 4.4: Beispielkonfiguration der Applikation ComsolGridFCGI
Die einzelnen Parameter in der Konfigurationsdatei haben folgende Bedeutungen:
<comsol_fcgi> Dieser XML-Tag umschließt die Konfigurationseinstellungen und muss mit
</comsol_fcgi> beendet werden.
<logfile> Definiert die Protokollierungsdatei, in die Meldungen über Aktionen während der Laufzeit von ComsolGridFCGI geschrieben werden.
<uploaddir> Setzt den Ordnernamen oder Pfad in dem die Simulationsdateien beim Hochladen
zwischengespeichert sind. Der Benutzer mit dem der Apache Webserver läuft, muss die Rechte
zum Erstellen von Dateien in diesem Ordner haben.
<info_refresh_interval> Das Zeitintervall indem die Prozessinformationen aktualisiert werden.
<wu_name_tpl> Dieses XML-Tag beschreibt das Format der Namen der Arbeitspakete (engl.
Workunit, WU). Das Format kann durch Standardformatierungselemente beschrieben sein,
z.B.%d für eine Dezimalzahl oder %s für eine Zeichenkette. Diese Elemente können z.B. in
den Manpages zu den Standard C-Funktionen $man 3 printf nachgelesen werden5. Die Implementierung von ComsolGridFCGI muss an das Format angepasst sein. Grundsätzlich wird
bei der Erstellung von Arbeitspaketen die Identifikationsnummer der wissenschaftlichen Applikation und eine inkrementierende Identifikationsnummer für jedes Arbeitspaket erstellt. Es
wird daher empfohlen den hinteren Teil, des im Listing 4.4 gezeigten Formats, zu übernehmen
_%d_%05d.
Der Kern dieser Arbeit ist die Wrapper Implementierung „ComsolGridStarter“. Durch diese Implementierung wird es erst ermöglicht, dass die COMSOL Multiphysics Simulationssoftware mit
BOINC gestartet und durch das BOINC Framework gesteuert werden kann. Die Implementierung
ist in der Testversion vom ComsolGrid Framework nur auf Linux Systemen vorhanden und getestet.
4.7.1
COMSOL Multiphysics Prozesskontrolle
Die Abbildung 4.4 enthält das abstrakte Aktivitätendiagramm der ComsolGridStarter Implementierung und gibt einen Überblick über die Komplexität der darunterliegenden Architektur. Die Architektur kann grob in drei Bereiche unterteilt werden:
5 Die meist genutzten Elemente sind: %d=Dezimalzahl, %f=Fließkommazahl (float), %lf=Fließkommazahl (double) und
%s=Zeichenkette (char*).
33
1. Dem BOINC Manager, der das Starten und Steuern von ComsolGridStarter übernimmt,
2. der Implementierung des Wrapper „Comsolstarter“ selbst und
3. die COMSOL Multiphysics Simulationssoftware und der damit einhergehenden virtuellen Java Maschine6 .
COMSOL Multiphysics ist durch die Nutzung von Java unabhängig von der Plattform ausführbar.
Diese Unabhängigkeit wird durch das Verwenden einer virtuellen Maschine erreicht, die zwischen
den Programmbefehlen der Ausführung und der Plattformarchitektur gestartet wird und die Umsetzung der Programmbefehle zu den plattformspezifischen Instruktionen übernimmt. Das ist auch
schon das Problem der eingangs erwähnten Wrapper Implementierungen aus Abschnitt 3.1, mit denen die COMSOL Multiphysics Simulationssoftware nicht steuerbar ist.
Listing 4.5 zeigt die Prozessstruktur einer COMSOL Multiphysics Ausführung der Major Release Version 3.5x und das Listing 4.6 zeigt die Prozessstruktur eines Major Release in Version
4.0a. Die Zahlen in den Klammern sind die Prozessidentifikationsnummern (PID). Es ist zu sehen,
dass COMSOL mit der PID(30521) läuft und als Kindprozess eine Java Instanz mit der PID(30674)
besitzt. Diese Java Instanz besitzt weitere Java Kindprozesse. Die vorhandene Wrapper Implementierung [23] arbeitet mit der PID(30521), um das Programm zu steuern. Wenn der Prozess mit der
PID(30521) das Signal SIGSTOP empfängt, würde dieser Prozess stoppen, aber der Java Prozess mit
der PID(30674) und die Kindprozesse arbeiten in diesem Fall weiter.
Für das weitere Verständnis ist es wichtig zu wissen, dass das Signal SIGSTOP nicht den Prozess
so stoppt, dass dieser beendet ist. Dieses Signal pausiert die Ausführung, die zu einem späteren
Zeitpunkt wieder aufgenommen werden kann. Der pausierte Prozess verbleibt während dieser Zeit
im Speicher.
Bei der COMSOL Multiphysics Version 4.0a verhält es sich gleich. Ein SIGSTOP für den Prozess
PID(15895) stoppt nicht den gesamten Prozess, es wird die PID(15919) benötigt. Der COMSOL
Multiphysics Prozess ist somit nicht auf diesem Wege steuerbar. Wenn allerdings der Java Prozess
mit der PID(30674) ein SIGSTOP empfängt, dann wird der Prozess inklusive der Kindprozesse
gestoppt.
1
2
3
s u ( 3 0 4 4 3 )−−−b a s h ( 3 0 4 5 2 )−−−comsol ( 3 0 5 2 1 )−−−j a v a ( 3 0 6 7 4 )−+−{j a v a } ( 3 0 6 7 5 )
| −{ j a v a } ( 3 0 6 7 6 )
‘ −...
Listing 4.5: Prozessstruktur von COMSOL Multiphysics 3.5x nach dem Start
An dieser Problematik setzt die Implementierung von ComsolGridStarter an und ermittelt nach
dem Starten von COMSOL Multiphysics diese relevante PID des Java Prozesses und schickt die
Steuerungssignale an diesen Prozess. Zu diesem Zweck wurde die Klasse ComsolGrid::Task zur Steuerung des Prozesses entwickelt.
1
2
3
4
s u ( 1 3 5 6 4 )−−−b a s h ( 1 3 5 7 6 )−+−comsol ( 1 5 8 9 5 )−−−co m s o lla u n c h e r ( 1 5 9 1 9 )−+−{co m s o lla u n c h e r }
|
| −{ co m s o lla u n c h e r }
|
| −{ co m s o lla u n c h e r }
|
‘ −...
Listing 4.6: Prozessstruktur von COMSOL Multiphysics 4.0a nach dem Start
Anwendungen die durch den BOINC Client (nachfolgend „BC“ genannt) gestartet werden, stehen
mit dem BC in Kontakt. Der BC steuert das gestartete Programm durch Statusnachrichten. Dafür
ist ein Kommunikationskanal vorhanden, der zwischen dem BC und dem Wrapper Daten austauscht
und dabei Shared-Memory (SHM) verwendet [2]. Diese Informationen können kontinuierlich abgefragt werden, wenn vorher konfiguriert wurde, dass diese vom Entwickler zu handhaben sind.
6 Die
34
COMSOL Multiphysics Simulationssoftware ist in Java programmiert.
Die bis hier erwähnten Charakteristika über die Prozessstruktur und implementierten BOINC
Funktionalitäten werden in Listing 4.7 angewendet. Das Listing 4.7 enthält eine gekürzte Form
der ComsolGridStarter Implementierung. In der main(...)-Funktion werden im ersten Abschnitt
die BOINC Optionen gesetzt, so dass der Wrapper die Prozesskontrolle übernehmen kann (Zeilen
3 − 15). Ab Zeile 17 beginnt die Funktionalität von ComsolGridStarter. Es wird eine Instanz der
Prozesskontrollklasse erstellt, die Konfiguration von ComsolGridStarter in der Struktur cxml übergeben, der Pfad und die Parameter für die Ausführung von COMSOL Multiphysics angegeben und
die Prozesspriorität7 gesetzt.
In Zeile 22 wird COMSOL Multiphysics gestartet und ab Zeile 24 kontinuierlich geschaut, wie
weit der Fortschritt der Simulation (Zeile 28 und 29) ist und welche Steuerungsbefehle vom BC
geschickt werden (Zeile 31). Die Funktion aus Zeile 31 ist ab Zeile 37 aufgeführt. Sie liest den Status
aus, prüft die Werte in der Status Struktur und reagiert in den Fallunterscheidungen passend auf die
einzelnen Werte. Die Instanz task zur Prozesskontrolle, besitzt Methoden um den Java Prozess zu
beenden (SIGKILL, SIGINT), zu stoppen (SIGSTOP) und weiterarbeiten (SIGCONT) zu lassen.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
...
BOINC_OPTIONS o p t i o n s ;
memset(& o p t i o n s , 0 , s i z e o f ( o p t i o n s ) ) ;
/ / Es h a n d e l t s i c h um d i e Hauptanwendung .
o p t i o n s . m ain _ p r o g r am = t r u e ;
/ / P r u e f e n ob V e r b i n d u n g zum C l i e n t b e s t e h t .
o p tio n s . ch eck _ h ea r tb e a t = true ;
/ / Der E n t w i c k l e r h a n d h a b t d i e P r o g r a m m s teu er u n g .
o p tio n s . h a n d l e _ p r o c e s s _ c o n t r o l = true ;
/ / S t a t u s N a c h r i c h t e n s en d en , z . B . f r a c t i o n _ d o n e .
o p tio n s . s en d _ s tatu s _ m s g s = true ;
/ / Damit d i e o b e r e n O p t i o n e n g r e i f e n !
options . di re ct_process_ac tion = false ;
b o i n c _ i n i t _ o p t i o n s (& o p t i o n s ) ;
...
co m s o lT as k = new ComsolGrid : : Task ( ) ;
comsolTask −>setComsolXML(& cxml ) ;
comsolTask −>s e t C o m s o l B i n a r y ( c o m s o l B i n a r y , &a r g s ) ;
comsolTask −> s e t P r i o r i t y ( PROCESS_IDLE_PRIORITY ) ;
21
i f ( ! comsolTask −>r u n ( ) ) { / ∗ E r r o r h a n d l i n g ∗ / }
22
23
w h i l e ( comsolTask −>i s R u n n i n g ( ) ) {
/ / r e a d o u t t h e f r a c t i o n done −> BOINC c l i e n t
f r a c t i o n D o n e = comsolTask −>g e t F r a c t i o n D o n e ( ) ;
24
25
26
27
boinc_fraction_done ( fractionDone ) ;
boinc_report_app_status ( 0.0 , 0.0 , fractionDone ) ;
28
29
30
p o l l _ b o i n c _ m e s s a g e s ( co m s o lT as k ) ;
31
32
boinc_sleep (1. 0) ;
33
}
34
35
}
36
37
38
39
40
v o i d p o l l _ b o i n c _ m e s s a g e s ( ComsolGrid : : Task ∗ t a s k ) {
...
BOINC_STATUS s t a t u s ;
b o i n c _ g e t _ s t a t u s (& s t a t u s ) ;
41
42
i f ( s t a t us . no_heartbeat )
{ t a s k −> k i l l ( ) ; e x i t ( 0 ) ; }
7 Nähere Informationen zu diesem Parameter sind in den Manpages der Funktionen getpriority und setpriority zu
finden, $man 2 setpriority.
35
i f ( s t a t u s . q u i t _ r e q u e s t ) { t a s k −> k i l l ( ) ; e x i t ( 0 ) ; }
i f ( s t a t u s . a b o r t _ r e q u e s t ) { t a s k −> k i l l ( ) ; e x i t ( 0 ) ; }
43
44
45
/ / COMSOL M u l t i p h y s i c s p a u s i e r e n o d e r
/ / weiterlaufen lassen .
i f ( s t a t u s . suspended ) {
i f ( ! t a s k −>i s S u s p e n d e d ( ) ) {
t a s k −> s t o p ( ) ;
}
} else {
i f ( t a s k −>i s S u s p e n d e d ( ) ) {
t a s k −>r es u m e ( ) ;
}
}
46
47
48
49
50
51
52
53
54
55
56
57
}
Listing 4.7: Aktivierung der implementierten Prozesskontrollmechanismen
Das Aktivitätendiagramm in Abbildung 4.4 verdeutlicht den Verlauf und die Prinzipien der Implementierung von ComsolGridStarter. Mit dem BOINC Manager können Befehle über den BC an
den ComsolGridStarter geschickt werden. Es wird kontinuierlich geprüft ob Arbeitspakete (engl.
Workunits) vorhanden sind, falls ja wird geschaut wo auf dem System die COMSOL Multiphysics
Simulationssoftware installiert ist und dann ausgeführt. Der ComsolGridStarter erstellt einen zweiten Prozess. Dieser führt die COMSOL Multiphysics Simulationssoftware aus. COMSOL Multiphysics startet eine virtuelle Java Maschine um die Simulation durchzuführen (oberer Kasten „InitializeComsol()“). Der Speicherbereich dieser Startfunktion wird durch COMSOL Multiphysics
ersetzt. Die PID des Prozesses von COMSOL Multiphysics wird an die „HandleBOINCStuff()“
Darstellung weitergegeben. Diese sucht im Prozessbaum nach der PID der virtuellen Java Maschine
und hält diese für spätere Aktivitäten des Benutzers bereit. Wenn der Benutzer die Durchführung
stoppen (Aktivität „User_Stop()“), weiterführen (Aktivität „User_Resume()“) oder beenden (Aktivität: „User_Abort()“) will, wird diese PID verwendet und das passende Signal an den richtigen
Prozess geschickt und eine volle Kontrolle der Durchführung der COMSOL Multiphysics Simulationssoftware ist möglich. Weiterhin ist eine manuelle Steuerung der ComsolGridStarter Applikation möglich, wenn diese nicht in Verbindung mit dem BC ausgeführt werden soll. Dafür musste das
Signal SIGSTOP umdefiniert werden. Das Signal kann nicht mit einem Signalhandler abgefangen
werden, so dass die Ausführung einer Applikation immer sofort zur Beendigung führt. Wenn die
Applikation ComsolGridStarter pausiert werden soll, muss nach Definition das Signal SIGUSR1 verwendet werden. Das Signal zum Fortführen der Ausführung SIGCONT ist ohne Probleme anwendbar.
Die Implementierung des Signalhandler für die manuelle Verwendung ist in Listing 4.8 nachzulesen.
1
2
3
4
5
6
7
8
9
void s i g n a l _ h a n d l e r ( i n t s i g n r ) {
i f ( co m s o lT as k ! = NULL) {
i f ( s i g n r == SIGUSR1 | |
s i g n r == SIGCONT | |
s i g n r == SIGSTOP ) {
comsolTask −> s i g n a l H a n d l e r ( s i g n r ) ;
}
}
}
Listing 4.8: Signalhandler für die manuelle Signalverarbeitung
4.7.2
COMSOL Multiphysics Start- und Simulationsparameter
COMSOL Multiphysics kann unter verschiedenen Betriebssystemen und Systemarchitekturen gestartet werden. Es werden von der Firma COMSOL hauptsächlich die Betriebssysteme Linux, Win36
Abbildung 4.4: Ablaufdiagramm der Implementierung von ComsolGridStarter
dows und Mac OS unterstützt, jeweils in der 32-Bit und 64-Bit Version. Die Systemarchitektur
kann beim Starten von COMSOL Multiphysics angegeben werden. Dies wird empfohlen um eine
höhere Ausführungsgeschwindigkeit zu erzielen. Bei der Ausführung von ComsolGridStarter wird
die Datei ./comsol.xml eingelesen und die darin enthaltenen Werte verarbeitet, in Listing 4.9 ist ein
Beispiel dieser Datei aufgelistet. Parameter, bei denen zwischen mehreren Optionen gewählt werden
kann, werden in dem Listing durch den Oder-Operator | voneinander getrennt.
1
2
OUTPUT:
<output >%s < / output >
3
4
5
6
PARAMETER:
<param>%s < / param>
[PARAMETER]
7
8
9
10
11
GLOBALS:
<globals >
[PARAMETER]
</ g l o b a l s >
12
13
14
15
XML_comsol_cfg :
<comsol >
<version >3.5 a | 4.0 | 4.0 a </ version >
<!−− B e i s p i e l −−>
37
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<32 b i t / > | <64 b i t / >
<ckl / >
< co res >6 </ co res >
<model > comsol . mph < / model >
[OUTPUT] ?
<parameters >
< f i l e > comsol . t x t < / f i l e >
<param>maxT < / param>
<param> o b jW id th < / param>
<param> o b j H e i g h t < / param>
[PARAMETER] ∗
</ parameters >
[GLOBALS] ?
< l o g f i l e > comsol . lo g < / l o g f i l e >
< s t d o u t _ f i l e n a m e > c o m s o l _ s t d o u t . lo g < / s t d o u t _ f i l e n a m e >
< s t d e r r _ f i l e n a m e > c o m s o l _ s t d e r r . lo g < / s t d e r r _ f i l e n a m e >
</ comsol >
<!−− B e i s p i e l −−>
<!−− B e i s p i e l −−>
<!−− B e i s p i e l −−>
<!−−
<!−−
<!−−
<!−−
Beispiel
Beispiel
Beispiel
Beispiel
−−>
−−>
−−>
−−>
<!−− B e i s p i e l −−>
<!−− B e i s p i e l −−>
<!−− B e i s p i e l −−>
Listing 4.9: Struktur und Beispiel einer ./comsol.xml Konfigurationsdatei
Mit dem XML-Tag <version> ermittelt der ComsolGridStarter die zur Simulationsdatei
<model> passende COMSOL Multiphysics Major Version (vgl. Abs. 4.10). Das XML-Tag <ckl/>
ist bei der Anwendung in der Fachhochschule Bielefeld von Bedeutung, da dort Floating-Licenses8
verwendet werden. Der XML-Tag <cores> ist in der aktuellen Testversion nicht umgesetzt, dieser
soll später dazu dienen n Prozessoren für eine ComsolGridStarter Ausführung zu reservieren. Das
Reservieren von Prozessoren wird von dem BOINC Framework in der verwendeten Version 6.11.0
nicht unterstützt. Durch Erstellung einer weiteren Abstraktionsschicht oder der Modifikation des
BOINC Framework könnte diese Funktion implementiert werden. Mit dem XML-Tag
<parameters> wird ein Bereich eröffnet, der die Simulationsparameter (vgl. Abs. 4.9) beschreibt.
Die Werte der variablen Parameter eines Simulationsmodell sind in der durch <file> beschriebenen Eingabedatei enthalten.
Das Format der Eingabedatei ist wichtig. Jede Zeile beschreibt die Simulationsparameter für
einen Simulationslauf. Die Anzahl der zu variierenden Simulationsparameter ist gleich der Anzahl
an Spalten in dieser Datei, d.h. jede Spalte symbolisiert einen Simulationsparameter. Diese Simulationsparameter sind jeweils mit einem Tabulatorsprung voneinander getrennt, es können mehrere
aber mindestens einer verwendet werden. Es darf keine Leerzeile am Ende vorkommen. Im Abschnitt 4.14 wird näher auf diese Datei eingegangen.
Alle weiteren Parameter werden beim Aufrufen von COMSOL Multiphysics verwendet.
<logfile> gibt die Datei an, in die Protokolldaten geschrieben werden. <stdout_filename>
wird verwendet, um die Standardausgaben des Programms zu speichern und <stderr_filename>
enthält den Namen der Datei, die die Standardfehlerausgaben enthält.
Die Log- und die Standardfehlerausgabendatei sind nicht weiter beachtenswert, bei der Standardausgabedatei ist der Fall anders. Darauf wird in Abschnitt 4.7.3 näher eingegangen.
Aus den in Listing 4.9 aufgeführten Parametern mit der Markierung <!- Beispiel ->, wird folgender Befehl erstellt:
/usr/local/comsol35a/bin/comsol -ckl -64 batch -input comsol.mph -paramfile comsol.txt “maxT,objWidth,objHeight“ -logfile comsol.log
8 Im Netzwerk ist ein Lizenzserver mit einer Anzahl N vorhandener Lizenzen installiert. Beim Starten einer Lizenz
pflichtigen Anwendung wird eine Verbindung zu diesem Server aufgebaut und geschaut ob eine passende Lizenz vorliegt
oder noch frei ist.
38
4.8 COMSOL Dateiformate und Magic Numbers
Abbildung 4.5: BOINC Manager mit Darstellung des fraction_done Wertes von ComsolGridStarter
4.7.3
COMSOL Multiphysics Prozessfortschritt
Die Standardausgabedatei <stdout_filename> aus dem Listing 4.9, wird dazu verwendet um zu
ermitteln, wie weit der Simulationsfortschritt der Ausführung ist. Eine Beispielausgabe von COMSOL Multiphysics ist in Listing 4.10 aufgeführt.
1
2
3
COMSOL B atch (64− b i t )
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
V e r s i o n : COMSOL 3 . 5 a (COMSOL 3 . 5 . 0 . 6 0 3 )
4
5
6
7
8
P aten t pending .
C o p y r i g h t ( c ) 1998 −2008 by COMSOL AB .
All r i g h t s reserved .
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
9
10
11
12
13
14
15
16
17
18
19
20
21
22
S t a r t i n g batch job .
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
S o l v e P r o b lem
Current Progress :
0 %
U p d a t i n g e x t e n d e d mesh
Current Progress :
0 %
...
...
Matrix f a c t o r i z a t i o n
Current Progress :
1 %
20
2.0858
0.36232
36
9
36
2
1
21
2.4482
0.36232
37
9
37
2
1
...
0
0
Listing 4.10: Standardausgabe bei der Ausführung von COMSOL Multiphysics im Batch-Modus
Der Funktionsaufruf comsolTask−>getFractionDone() in Listing 4.7, Zeile 26, öffnet diese Datei, springt
an das Ende, liest rückwärts x Bytes und sucht in diesen Daten nach der Zeichenkette Current
Progress:. Bei einer gefundenen Zeichenkette, wird der Prozentwert ausgelesen und an die aufrufende Funktion zurückgegeben. Dieser Wert wird mit einer Funktion des BOINC Framework
boinc_report_app_status (...) an den BOINC Client gesendet. Der Wert wird mit dem BOINC Manager
ausgetauscht und dann dort in der grafischen Ausgabe angezeigt (vgl. Abb. 4.5).
4.8 COMSOL Dateiformate und Magic Numbers
Dateien auf Computersystemen können durch verschiedene Verfahren unterschieden werden. Windows Anwender sehen sich mit Dateiendungen9 konfrontiert, auf Unix/Linux Systemen, sind Dateiendungen nicht unbedingt nötig, werden aber auch verwendet. Ein Verfahren, das sich etabliert hat,
9 Dateiendungen sind Erweiterungen des vergebenen Dateinamens um den Typ der Datei zu definieren, z.B. .doc für
Dokumentendateien für Microsoft Office Dokumente, .exe wird bei ausführbaren Dateien verwenden.
39
4.9 Ermittlung der COMSOL Simulationparameter
Abbildung 4.6: Magic Numbers der COMSOL Simulationsmodelldateien
ist das Auslesen der sogenannten Magic Numbers in Dateien. Dabei werden die ersten N Bytes am
Anfang der Datei gelesen, die den Typ einer Datei definieren sollen. Magic Numbers werden nicht
nur für Dateien verwendet, sondern auch in Kommunikationsprotokollen um bestimmte Nachrichtentypen zu definieren. Sie unterstützen im Falle der Kommunikation die ordentliche Konversation.
Diese Arbeit arbeitet mit Simulationsdateien von COMSOL Multiphysics. Die Dateiendung
einer solchen Datei ist .mph. Die COMSOL Multiphysics Versionen unterscheiden sich in der Art
des Dateiformats zur Abspeicherung von Simulationen. In der COMSOL Major Version 3.5 wird
die von Java unterstütze Serialisierung verwendet [26]. Die COMSOL Major Version 4.0 verwendet
hingegen Java Archive10 zur Speicherung [27]. Die Abbildung 4.6 zeigt die zwei Dateiformate einer
Simulationsdatei, die als Beispielmodell bei den jeweiligen COMSOL Major Versionen vorhanden
ist.
Dateien, die die Java Serialisierung enthalten, besitzen immer 0xAC und 0xED als die ersten zwei
Bytes am Dateianfang. Java Archive werden durch die ersten 10 Bytes einer Datei beschrieben, die
Werte sind 0x50, 0x4B, 0x03, 0x04, 0x14, 0x00, 0x08, 0x00, 0x08 und 0x00. Das ComsolGrid Framework enthält die Funktion int ComsolGrid:: file_type ( std :: ifstream &); um den Dateityp zu ermitteln und
gibt eine der folgenden drei Konstanten zurück:
MAGIC_CODE_UNKNOWN Der Typ der Datei ist keine der beschriebenen Dateitypen.
MAGIC_CODE_JAVA_SERIALIZATION Dieser Wert gibt an, dass es sich um eine Datei mit
einer Java Serialisierung handelt.
MAGIC_CODE_JAVA_ARCHIVE Die Datei ist ein Java Archiv.
Durch die Ermittlung des Dateityps einer Simulationsdatei aus Abschnitt 4.8, wird die Möglichkeit
geschaffen mit diesen Dateien zu arbeiten. Je nach Dateityp können diese Dateien ausgelesen und
dabei evtl. vorhandene Simulationsparameter ermittelt werden. Die Abbildung 4.7 zeigt die Fenster
zur Konfiguration von Simulationsparametern. Es wurden zur Verdeutlichung 5 verschiedene Konstanten bzw. Parameter definiert. Das Listing 4.12 zeigt, wie diese Parameter mit Funktionen aus
10 Java Archive sind im Grundsätzlichen ZIP-Archive [12], allerdings enthalten Java Archive eine bestimmte Struktur die
von der Firma SUN definiert wurde [27].
40
Abbildung 4.7: Definition von Simulationskonstanten in den COMSOL Versionen 3.5 und 4.0
dem ComsolGrid Framework gelesen werden. Die wichtige Funktion steht in Zeile 16, die Funktion ComsolGrid::parameter_comsol (...) wird aufgerufen. Diese Funktion liest die Simulationsdateien ein,
deutet deren Inhalt und ermittelt die Simulationsparameter.
Wie oben erwähnt, schreibt das COMSOL Release 3.5 serialisierte Java Daten in eine Datei. Das
Simulationsmodell wird in einem XML-Baum abgespeichert. Dieses Modell wird von den XMLTags <model> und </model> eingeschlossen. Die Daten des XML-Baums werden im Klartext
abgespeichert und der Text zwischen diesen einschließenden XML-Tags kann so direkt ausgelesen werden. Dieser Bereich mit Daten, wird nach der Zeichenkette <const type=class"> und dem
abschließenden XML-Tag </const> durchsucht. Der Wert zwischen diesen XML-Tags ist ein Simulationsparameter.
Bei dem COMSOL Release 4.0 wird das Simulationsmodell als Java Archiv gespeichert. Das
Java Archiv der Testdatei, auf der rechten Seite in Abbildung 4.7, hat die Struktur aus Listing 4.11.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
.
|−−
|−−
|−−
|−−
|−−
|−−
|−−
|−−
|
|
|
|
‘−−
geom1 . mphbin
geom2 . mphbin
geommanager1 . mphbin
g u i m o d e l . xml
mesh1 . mphbin
modelimage . png
model . xml
<−−− e n t h a e l t d i e P a r a m e t e r
savepoint1
|−− geom1 . mphbin
|−− geommanager1 . mphbin
|−− mesh1 . mphbin
‘−− model . xml
s o l u t i o n 1 . mphbin
Listing 4.11: Struktur eines COMSOL Multiphysics Java Archivs
Die Datei model.xml enthält die definierten Parameter und ist im Klartext abgespeichert. In der
Datei wird nach den XML-Tags <param tag=param"> und </param> gesucht. Die relevanten
Simulationsparameter sind in den jeweiligen Zeilen zwischen diesen einschließenden XML-Tags
aufgeführt.
Die Ergebnisse der jeweiligen Suchvorgänge, werden in eine ComsolGrid:: StringList abgespeichert
und können zu späteren Zeitpunkten verwendet werden, z.B. um bei der Parameterstudie automatisch
die Auswahlfelder für die Parameter zu erstellen (vgl. Abs. 4.16).
1
2
3
/ / / C++
# include <iostream >
# include < s tring >
4
5
/ / / ComsolGrid
41
4.10 Ermittlung der COMSOL Applikationen und Versionen
Abbildung 4.8: Ermittlung der Simulationsparameter aus einem (1) COMSOL Simulationsmodell
der COMSOL Multiphysics Versionen (2) 3.5 und (3) 4.0
6
7
8
# i n c l u d e < s t r u t i l . h>
# i n c l u d e < m ag icco d e . h>
# i n c l u d e < s i m p a r a m e t e r . h>
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
i f ( argc != 2) {
s t d : : c e r r << " Usage : " << a r g v [ 0 ] << " ’COMSOL S i m u l a t i o n F i l e ( ∗ . mph ) ’ " <<
s td : : endl ;
return 1;
}
try {
ComsolGrid : : S t r i n g L i s t p a r a m e t e r = ComsolGrid : : p a r a m e t e r _ c o m s o l ( a r g v [ 1 ] ) ;
ComsolGrid : : S t r i n g L i s t : : i t e r a t o r i t = p a r a m e t e r . b e g i n ( ) ;
f o r ( ; i t ! = p a r a m e t e r . end ( ) ; i t ++) {
s t d : : c o u t << " P a r a m e t e r : " << ∗ i t << s t d : : e n d l ;
}
} c a t c h ( s t d : : s t r i n g m es s ag e ) {
s t d : : c o u t << " E r r o r −> " << m es s ag e << s t d : : e n d l ;
}
}
Listing 4.12: C++-Quelltext zur Ermittlung der Simulationsparameter aus einer Simulationsdatei
4.10 Ermittlung der COMSOL Applikationen und Versionen
Im Listing 4.13 ist eine Beispielanwendung aufgelistet, um auf einem Rechner die installierten
COMSOL Ausführungsdateien inklusive der Versionen ermitteln zu können. Diese kleine Implementierung ist eine starke Abstraktion, des logischen Ablaufs für die Einholung und Verarbeitung
der Information einer COMSOL Installation.
Die komplette logische Struktur verbirgt sich hinter dem Methodenaufruf ComsolGrid::lookup().
Dieser Aufruf arbeitet sequentiell eine Liste von Standardbverzeichnissen ab und prüft ob dort eine
ausführbare COMSOL Datei vorhanden ist. Ausführbare COMSOL Dateien werden definiert als
Dateien mit dem Namen $ABSOLUTERPFAD/bin/comsol. Wenn diese Datei vorhanden ist, wird
42
versucht diese mit dem Parameter −version auszuführen. Die Zeichenkette, die durch diesen Aufruf ausgegeben wird, enthält die Versionsnummer von COMSOL. Der Aufbau dieser Zeichenkette
unterscheidet sich zwischen dem Major Release 3.5 und 4.0. Die Major Version 3.5 gibt als Beispiel
folgende Zeichenkette aus: COMSOL 3.5a (COMSOL 3.5.0.603, $Date: 2008/12/03 17:02:19 $).
Das Major Release der 4.0 Reihe gibt nachfolgendes als Beispiel aus: COMSOL 4.0.0.925.
Diese beiden Major Releases können zu hundert Prozent unterschieden werden. Bei dem Major
Release 3.5 wird zuerst geprüft ob Klammerausdrücke vorhanden sind. Wenn ja, wird an die Stelle
der öffnenden Klammer gesprungen, die nachfolgenden 16 Zeichen gelesen und dieser Teil passend
in einzelne Elemente unterteilt. Wenn keine Klammerausdrücke vorhanden sind, dann handelt es sich
um ein Major Release 4.0 und die Information kann sofort in die einzelnen Elemente aufgetrennt
werden.
Die zuvor genannten Schritte werden außer Acht gelassen, wenn eine der Umgebungsvariablen COMSOL_PATH_V35A, COMSOL_PATH_V40, COMSOL_PATH_40A - gesetzt ist und der Aufruf der Funktion ComsolGrid::lookup() ohne Parameter erfolgt. Es wird diesen Umgebungsvariablen
vertraut und keine weitere Prüfung auf die Ausführbarkeit der COMSOL Applikation gemacht.
1
2
3
/ / C++
4
5
6
7
/ / ComsolGrid
# i n c l u d e <cxml . h>
# i n c l u d e < c o m s o l b i n . h>
8
9
10
11
12
13
14
15
ComsolGrid : : V e r s i o n s L i s t v e r s i o n s = ComsolGrid : : l o o k u p ( ) ;
f o r ( i n t i = 0 ; i < v e r s i o n s . s i z e ( ) ; i ++) {
s t d : : c o u t << " V e r s i o n : " << v e r s i o n s . a t ( i ) . g e t V e r s i o n ( ) << " − "
<< " Major : " << v e r s i o n s . a t ( i ) . g e t M a j o r ( ) << s t d : : e n d l ;
}
}
Listing 4.13: Ermittlung der COMSOL Multiphysics Major Versionen
Der Aufruf für die COMSOL Major Version 3.5 kann unter Umständen eine hohe Latenzzeit haben.
Das hängt damit zusammen, dass die Simulationsdatei von der ersten Byte Position bis zum Aufkommen der oben erwähnten XML-Tags durchsucht wird. Desto größer die Simulationsdatei ist, desto
länger kann das Auffinden von Simulationsparametern dauern. Bei der Major Version 4.0 kann direkt auf die Information zugegriffen werden und die Zugriffszeit ist bei größer werdenden Modellen
noch immer relativ schnell.
In Abschnitt 4.10 wird gezeigt wie die installierten COMSOL Multiphysics Versionen auf einem
Rechner gefunden werden. Ein ComsolGrid Projekt kann verschiedene Parameterstudien besitzen,
z.B. eine Studie für einen Temperaturübergang durch Glas, jeweils in einem Modell eines COMSOL
Multiphysics 3.5 oder 4.0 Major Release. Die Modelle sind untereinander nicht kompatibel und es
muss für die jeweilige Datei die richtig COMSOL Version installiert sein. Der Benutzer hat eventuell
nur eine von beiden installiert und kann von daher die Simulation nicht durchführen. Es ist unsinnig,
dass dieser Benutzer Arbeitspakete vom Projektserver erhält, wenn er diese nicht bearbeiten kann.
Um dieses Problem handhaben zu können, ist der BOINC Manager modifiziert worden. Die
Quellen des BOINC Projektes enthalten im Subordner client/ u.a. die Quellen des BOINC Manager. In der Datei ./cs_platform.cpp werden die Informationen der verwendeten bzw. unterstützten
Plattformen ermitteln, z.B. ob es sich um ein Linux oder Windows System handelt auf dem der
43
BOINC Manager installiert ist. Diese Funktion wurde um den Teil in Listing 4.14 erweitert. Dieser
kurze Teil durchläuft die gefundenen Plattformdefinitionen (gespeichert in einem C++-Container
platforms ) und fügt jeweils die gefundenen COMSOL Multiphysics Versionen hinzu.
1
2
3
4
//
/ / Add COMSOL v e r s i o n s t o f o u n d e d p l a t f o r m s .
//
ComsolGrid : : V e r s i o n s L i s t v e r s i o n s = ComsolGrid : : l o o k u p ( ) ;
5
6
int s = platforms . size () ;
7
8
9
10
11
12
13
14
15
16
17
18
19
20
f o r ( u n s ig n ed i n t i = 0 ; i < s ; i ++) {
s t d : : s t r i n g pname = p l a t f o r m s . a t ( i ) . name ;
f o r ( u n s ig n ed i n t j = 0 ; j < v e r s i o n s . s i z e ( ) ; j ++) {
s t d : : s t r i n g pname_comsol = pname ;
pname_comsol += " _ co m s o l " ;
s t d : : s t r i n g m ajo r = v e r s i o n s . a t ( j ) . g e t M a j o r ( ) ;
/ / Removes t h e ’ . ’ c h a r a c t e r , n o t s u p p o r t e d by BOINC .
m ajo r . e r a s e ( 1 , 1 ) ;
pname_comsol += m ajo r ;
f p r i n t f ( s t d o u t , " Add p l a t f o r m : %s \ n " , pname_comsol . c _ s t r ( ) ) ;
a d d _ p l a t f o r m ( pname_comsol . c _ s t r ( ) ) ;
}
}
Listing 4.14: Modifikation am BOINC Manager zur Ermittlung der COMSOL Versionen
Werden z.B. zwei Plattformen mit den nachfolgenden Definitionen gefunden
i686-pc-linux-gnu
x86_64-pc-linux-gnu
Linux running on an Intel x86-compatible CPU
Linux running on an AMD x86_64 or Intel EM64T CPU
werden diese jeweils um eine Definition erweitert, wenn z.B. die COMSOL Multiphysics Version
3.5a installiert ist
i686-pc-linux-gnu_comsol35a
x86_64-pc-linux-gnu_comsol35a
...x86-compatible CPU with COMSOL v3.5a
...x86_64 or Intel EM64T CPU with COMSOL v3.5a
Die wissenschaftlichen Applikationen müssen im Projekt mit eben diesen Plattformdefinitionen
und in der Datenbank des Projekts hinzugefügt sein. In den Namen darf kein Punkt vorhanden sein,
dieser wird von dem BOINC Framework als Trennzeichen erkannt. Aus diesem Grund wird im Listing 4.14 dieser Punkt mit major. erase (1,1) ; entfernt. Das Vorgehen zum Hinzufügen von Plattformdefinitionen innerhalb einer Projekts, geschieht im Projektverzeichnis durch den Befehl $./bin/xadd.
In der Protokollierungsdatei stdoutdae.txt11 des BOINC Manager, wird die Meldung aus
Listing 4.15 ausgegeben, um zu zeigen welche COMSOL Multiphysics Versionen gefunden wurden.
1
2
3
4
5
6
Add
Add
Add
Add
Add
Add
platform
platform
platform
platform
platform
platform
:
:
:
:
:
:
x86_64−pc−l i n u x −g n u _ co m s o l3 5 a
x86_64−pc−l i n u x −g n u _ co m s o l4 0
x86_64−pc−l i n u x −g n u _ co m s o l4 0 a
i6 8 6 −pc−l i n u x −g n u _ co m s o l3 5 a
i6 8 6 −pc−l i n u x −g n u _ co m s o l4 0
i6 8 6 −pc−l i n u x −g n u _ co m s o l4 0 a
Listing 4.15: Vom BOINC Manager hinzugefügte Plattformdefinitionen
11 Diese
44
Datei wird im Ordner des BOINC Manager erstellt.
4.12 Kommunikationsprotokoll
Das Kommunikationsprotokoll basiert auf der Schicht 7 des ISO/OSI Referenzmodells. Es ist Klartext basierend und verwendet durchgehend einen XML Dialekt. Dieser XML Dialekt wird in HTTPRequests eingebettet und durch die Applikation ComsolGridFCGI verarbeitet. Die Kommunikation
in der Testversion des ComsolGrid Frameworks findet zwischen ComsolGridQt und ComsolGridFCGI statt. Das Listing 4.16 enthält den HTTP-Request an die Applikation ComsolGridFCGI, der
durch die verwendete FastCGI Bibliothek automatisch bearbeitet wird und die reinen XML Daten
zur Weiterverarbeitung zur Verfügung stellt.
Die drei Variablen ${HOSTNAME}, ${XMLDATENLAENGE} und ${XMLDATEN} müssen
durch entsprechende Werte gefüllt werden. ${HOSTNAME} ist der FQDN oder die IP-Adresse des
Hosts mit der gestarteten Applikation ComsolGridFCGI. Der Dateipfad /comsolfcgi in der ersten Zeile, beschreibt den Namen der Schnittstelle ComsolGridFCGI, durch die die Applikation mit
einem HTTP-Request aufgerufen werden kann. Dieser Wert wurde für den Apache Webserver in
den Einstellungen des Servers eingetragen. Im Anhang B.3 sind die verwendeten Apache Konfigurationen aufgelistet.
1
2
3
4
5
6
POST / c o m s o l f c g i HTTP / 1 . 1 \ r \ n
H o s t : $ {HOSTNAME} \ r \ n
User−Agent : COMSOL T e s t s u i t e \ r \ n
C o n t e n t −L en g th : $ {XMLDATENLAENGE} \ r \ n
C o n t e n t −Type : a p p l i c a t i o n / x−www−form−u r l e n c o d e d \ r \ n
\ r \ n$ {XMLDATEN} \ r \ n \ r \ n
Listing 4.16: Basis HTTP-Request der die XML Daten aufnimmt
Es gilt zu beachten, dass alle einzelnen XML-Tags in einer eigenen Zeile stehen und durch folgende
Zeichen voneinander getrennt werden müssen: \ r \n. Es wird empfohlen, am Ende eines HTTP/XMLRequest oder HTTP/XML-Response zwei dieser Zeichenketten zu verwenden. \ r \n sind zwei EscapeSequenzen mit den Akronymen CR (Carriage Return, ’\r’, 0x0D, 13 in dezimal) und LF (Line
Feed, ’\n’, 0x0A, 10 in dezimal) in der Informationstechnik, Die hier erwähnten und aufgelisteten
HTTP/XML-Requests enthalten Platzhalter in folgender Schreibweise:
%s Es wird eine Zeichenkette als Füllelement erwartet.
%d Diese Stelle wird durch eine ganze Zahl ersetzt.
Die Tabelle 4.2 enthält die wenigen implementierten Kommunikationsdialoge im ComsolGrid Framework. Die linke Spalte „ComsolGridQt Anfrage“ enthält die Anfänge einer Konversation, zwischen
den Applikationen ComsolGridQt und ComsolGridFCGI. In der mittleren Spalte „ComsolGridFCGI Antworten“, werden die passenden Antwortelemente aufgelistet. Die letzte Spalte enthält eine
grobe Beschreibung der Konversation. Die einzelnen Sprachelemente werden in den nachfolgenden
Listings erläutert.
4.12.1
ComsolGridFCGI - HTML/XML-Response Nachrichten
Die Listings 4.17 bis 4.19 enthalten die HTTP/XML-Response Nachrichten von ComsolGridFCGI
an ComsolGridQt. Es sei erwähnt, dass auch andere Programme auf ComsolGridFCGI zugreifen
können, z.B. mit einem Webbrowser. Der Webbrowser muss richtige Anfragen an die Applikation
senden, sonst wird immer die Nachricht aus Listing 4.20 zurückgeliefert. Es sind allgemeine Rückgabewerte definiert und hard-codiert implementiert. Diese Werte sind in Listing 4.21 aufgelistet.
Das Listing 4.17 beschreibt die Antwort auf die Nachfrage nach den Prozessinformationen. Der
Abschnitt 4.13 beschreibt die Implementierung zur Beschaffung der Informationen. Der HTTP/XMLResponse enthält hingegen die Informationen über die Prozesse. Eingebettete Daten wie diese Informationen, müssen in einem unterschiedlichen Darstellungsformat verwendet werden, da es sonst zu
45
ComsolGridQt
Anfrage
ComsolGridFCGI
Antwort
Beschreibung
<comsol_put>
...
</comsol_put>
<comsol_error>
...
</comsol_error>
Die Anfrage ist zum Hinzufügen einer Parameterstudie und für das Hochladen von Simulationsund Schablonendateien gedacht. Das Format dieser
Anfrage wird in Listing 4.22 gezeigt. Das Ergebnis dieser Anfrage wird mit einer Fehlernummer
berichtet. Die Namensgebung „Fehlernummer“ ist für
das Ergebnis evtl. irreführend, es sei angemerkt, dass
auch in einem Erfolgsfall eine solche Fehlernummer
gesendet wird. In Listing 4.21 sind die Fehlernummern aufgelistet.
<server_major/>
<version>
...
</version>
Die Anfrage ruft die Major Versionsnummer der Applikation ComsolGridFCGI ab. Das Ergebnis wird in
Listing 4.19 beschrieben. Die Major Versionsnummer
ist im Normalfall eine einzelne Ziffer.
<server_minor/>
<version>
...
</version>
Diese Anfrage ähnelt sehr der <comsol_major>Anfrage, mit dem Unterschied, dass die Minor Versionsnummer abgefragt wird. Die Antwort wird in
Listing 4.19 aufgelistet.
<server_release/>
<version>
...
</version>
Das Ergebnis dieser Anfrage ist die komplette Versionsnummer der ComsolGridFCGI Applikation. Die
Zeichenkette in der Antwort aus Listing 4.19 ist
eine Zusammensetzung aus den Major.Minor Versionsnummern.
<comsol_release/>
<version>
...
</version>
Diese Antwort enthält alle zur Verfügung gestellten
COMSOL Multiphysics Versionen. In der Testversion vom ComsolGrid Framework werden immer die
folgenden drei Versionen zurückgesendet: 3.5a, 4.0,
4.0a.
<status>
...
</status>
<status>
...
</status>
Der Status kann nur von autorisierten Simulanten
abgefragt werden. Für diesen Zweck muss eine Authentifizierung statt finden, siehe Listing 4.24.
<apps>
...
</apps>
<apps>
...
</apps>
Die Liste der wissenschaftlichen Applikationen kann
nur von autorisierten Simulanten abgefragt werden.
Für diesen Zweck muss eine Authentifizierung statt
finden, siehe Listing 4.24.
Tabelle 4.2: HTTP/XML-Request - ComsolGridQt Anfragen und zugehörige ComsolGridFCGI
Antworten
Verarbeitungsproblemen bei der Abarbeitung und Filterung der Informationen kommen kann. Sollten in den Daten z.B. „kleiner als“ < oder „größer als“ > Zeichen auftauchen, könnten diese auch
Startpunkte oder Endpunkte eines XML-Tag sein. Durch Base64 Verschlüsselung der Daten, kann
dieses Problem eliminiert werden [17, 18]. Base64 wird oft dazu verwendet binäre Daten in Textform
zu bringen, wenn diese über eine Verbindung transferiert werden sollen, die z.B. ein Text basiertes
Kommunikationsprotokoll verwenden. In den nachfolgenden Listings werden Base64 kodierte Daten mit der eingebetteten Funktion base64_encode(%s) beschrieben.
1
2
3
4
5
6
7
8
46
<status >
<boinc >
 b a s e 6 4 _ e n c o d e (TEXT) 
</ boinc >
<server >
<uptime > b a s e 6 4 _ e n c o d e ( ‘ uptime ‘ ) </ uptime >
<meminfo > b a s e 6 4 _ e n c o d e ( ‘ c a t / p r o c / meminfo ‘ ) </ meminfo >
< cp u in f o > b a s e 6 4 _ e n c o d e ( ‘ c a t / p r o c / cp u in f o ‘ ) </ cp u in f o >
9
10
11
12
< d i s k f r e e i n o d e > b a s e 6 4 _ e n c o d e ( ‘ d f −h −− t o t a l − i −l ‘ ) </ d i s k f r e e i n o d e >
< diskfreememory > b a s e 6 4 _ e n c o d e ( ‘ d f −h −− t o t a l −l ‘ ) </ diskfreememory >
</ s e r v e r >
</ s t a t u s >
Listing 4.17: HTTP/XML-Response - ComsolGridFCGI <status>
Das Listing 4.18 beschreibt die Antwort auf den Wunsch des Simulanten, zu erfahren welche wissenschaftlichen Applikationen in welchen Versionen vorhanden sind. Der XML-Tag Bereich <version>
kann dabei öfter vorkommen und wird für die jeweiligen Applikationen erstellt. Die Informationen in
diesem Bereich werden direkt aus der Datenbank übernommen, dort sind diese Informationen in den
Tabellen „app“, „app_version“ und „platform“ abgelegt. Die letzten zwei Zeilen der HTTP/XMLAntwort, liefern Zahlenwerte über die Anzahl der noch zu verarbeitenden Arbeitspakete und einen
Wert der aussagt, wie viele Arbeitspakete schon fertig bearbeitet sind.
1
2
3
4
5
6
7
8
9
10
11
VERSION :
<version >
<app_id >%d < / app_id >
<app_name>%s < / app_name >
< a p p _ u s e r f r i e n d l y >%s < / a p p _ u s e r f r i e n d l y >
< version_number>%d < / version_number >
%d 
<platform_name >%s < / platform_name >
%s 
</ v e r s i o n >
[ VERSION ]
12
13
14
15
16
17
18
XML:
<apps >
[ VERSION ]
< w o rk u n it _ co u n t>%d < / w o rk u n it _ co u n t >
< r e s u l t _ c o u n t >%d < / r e s u l t _ c o u n t >
</ apps >
Listing 4.18: HTTP/XML-Response - ComsolGridFCGI <apps>
Der Bereich XML_comsol_release in Listing 4.19 beschreibt die ComsolGridFCGI unterstützten
COMSOL Multiphysics Versionen. Antworten die Informationen über Versionen enthalten, werden
immer mit dem XML-Tag <version> gestartet, wie dies auch in den Beschreibungen in Listing
4.19 der Fall ist. In der aktuellen ComsolGrid Framework Testversion sind vier Antworten implementiert:
1. XML_comsol_release wie zuvor beschrieben,
2. XML_server_major,
3. XML_server_minor und
4. XML_server_release.
Die Tabelle 4.2 enthält nähere Erläuterungen zu diesen Antworten.
1
2
3
RELEASE :
< r e l e a s e >%s < / r e l e a s e >
[ RELEASE ]
4
5
6
7
8
X M L _ co m s o l_ r eleas e :
<version >
<comsol_release >
RELEASE
47
9
10
</ c o m s o l _ r e l e a s e >
</ v e r s i o n >
11
12
13
14
15
XML_server_major :
<version >
< s erv er_ m a j o r >%s < / s erv er_ m a j o r >
</ v e r s i o n >
16
17
18
19
20
XML_server_minor :
<version >
< s erv er_ m in o r >%s < / s erv er_ m in o r >
</ v e r s i o n >
21
22
23
24
25
XML_server_release :
<version >
< s e r v e r _ r e l e a s e >%s < / s e r v e r _ r e l e a s e >
</ v e r s i o n >
Listing 4.19: HTTP/XML-Response - ComsolGridFCGI <comsol_release>
Das Listing 4.20 beschreibt die Antwort von ComsolGridFCGI, wenn während der Verarbeitung
einer Anfrage ein Problem aufgetreten ist. Die Antwort enthält eine durch Doppelpunkte getrennte
Information: (1) die Fehlernummer und (2) eine kleine Beschreibung des Fehlers. Es sind vordefinierte
Fehlernummern im ComsolGrid Framework definiert und in dem Listing 4.21 aufgeführt. Diese
Fehlernummern können abgeändert und an die eigenen Bedürfnisse angepasst werden, sie dienen
der Unterstützung bei einer Konversation. Wie oben erwähnt, wird eine solche Nachricht auch dann
verwendet, wenn im System alles erfolgreich funktioniert hat. In diesem Fall wird die Fehlernummer
C_OK oder C_FINISHED verschickt.
1
2
3
< co m s o l_ erro r >
COMDOL_ERROR_ID : COMSOL_ERROR_DESCRIPTION
</ co m s o l_ erro r >
Listing 4.20: HTTP/XML-Response - ComsolGridFCGI <comsol_error>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# i f n d e f __CODES_H__
# d e f i n e __CODES_H__
/ / / C = COMSOL
# d e f i n e C_NOCMD −1
# d e f i n e C_OK 0
# d e f i n e C_FAILED 1
# d e f i n e C_LOGINFAILED 2
# d e f i n e C_FINISHED 3
# d e f i n e C_NOFILES 4
# d e f i n e C_UDIRPERM 5
# d e f i n e C_UPLOADOK 6
# d e f i n e C_TPLINMISS 7
# d e f i n e C_TPLRESMISS 8
# d e f i n e C_WRONGROLE 9
# e n d i f / / __CODES_H__
Es i s t k e i n R e q u e s t an g eg eb en .
Die V e r a r b e i t u n g v e r l i e f f e h l e r f r e i .
Es i s t e t w a s s c h i e f g e l a u f e n .
Der a n g e g e b e n e B e n u t z e r k o n n t e s i c h n i c h t an m eld en .
G l e i c h t C_OK, a l l e r d i n g s w i r d k e i n e N a c h r i c h t g e s c h i c k t .
Es s i n d k e i n e D a t e i e n zum H o ch lad en an g eg eb e n .
F e h l e n d e R e c h t e zum O e f f n e n e i n e s V e r z e i c h n i s s e s .
Das H o ch lad en d e r P a r a m e t e r s t u d i e v e r l i e f f e h l e r f r e i .
Es f e h l t d i e E i n g a b e s c h a b l o n e n d a t e i .
Es f e h l t d i e E r g e b n i s s c h a b l o n e n d a t e i .
Der S i m u l a n t b e s i t z t e i n e v e r k e h r t e B e n u t z e r r o l l e .
Listing 4.21: HTTP/XML-Response - ComsolGridFCGI Fehlernummern
4.12.2
ComsolGridFCGI - HTML/XML-Request Nachrichten
Dieser Abschnitt enthält die komplexeren Anfragen an ComsolGridFCGI. Die Kommunikationselemente <server_major>, <server_minor>, <server_release>
und <comsol_release> werden nicht näher behandelt, da diese schon in Tabelle 4.2 ausreichend
48
beschrieben sind. Die Anfrage aus Listing 4.22 ist die komplizierteste aller implementierten Kommunikationselemente. Der Beginn dieser Anfrage ist <comsol_put> und muss mit einer Authentifizierung <auth> (vgl. Listing 4.24) fortgeführt werden. Zweck und Aufgabe dieser Anfrage ist
das Erstellen einer Parameterstudie in einem Projekt. Eine Parameterstudie benötigt folgende Daten:
1. Eine oder mehrere COMSOL Multiphysics Simulationsdateien,
2. Parameter mit denen die Simulation durchgeführt werden soll und
3. Eingabe-/Ergebnisschablonen zum Laden und Speichern der Simulationseingabedaten und
Simulationsergebnisse.
Das XML-Tag <comsol> beschreibt den Bereich der Informationen, die speziell für die ComsolGridStarter Applikation verwendet werden. In Abschnitt 4.7 wird auf die Parameter eingegangen.
Weiterhin haben die XML-Tags folgende Bedeutungen:
name Name der wissenschaftlichen Applikation, für die die Parameterstudie erstellt werden soll.
Der Name kann mehrmals vorhanden sein, weshalb zur Unterscheidung zusätzlich die appid
verwendet wird.
appid Dies ist die eindeutige Identifikationsnummer einer wissenschaftlichen Applikation.
count Das ist die Anzahl an Simulationsdateien die hinzugefügt werden sollen, z.B. COMSOL
Multiphysics Dateien (*.mph), oder Eingabedaten die von der Simulation eingelesen werden.
filename Der Dateiname der Simulationsdateien.
description Eine Beschreibung der jeweiligen Simulationsdateien.
max_nbytes Die Größe der jeweiligen Simulationsdateien in Bytes.
data Dieser XML-Tag enthält die jeweiligen Simulationsdateien in Base64 Kodierung.
ranges In diesem Bereich sind Simulationsparameter definiert, die beschreiben in welchen Umfang
die Parameterstudien durchgeführt werden.
range Enthält eine Liste von einzelnen Simulationsparametern.
parameter Definiert einen Parameter durch fünf Elemente: (1) NAME ist der Name der Variablen die
beschrieben wird, (2) START ist eine Fließkommazahl die den Beginn des Simulationswertes
angibt, (3) STOP ist das Gegenstück zu START und gibt das Ende des Simulationswertes an,
(4) STEP beschreibt die Schrittweite zwischen START und STOP in der die Simulation durchgeführt wird und (5) DEFAULT ist ein Standardwert des Simulationswertes, wenn die Simulationsschritte dieses Parametern durchgearbeitet worden sind und weitere Variationen von anderen
Simulationsparametern durchgeführt werden. Ein Beispiel ist Zaehler:1:10:1:5, hier würde
die Variable Zaehler von 1 bis 10 hochgezählt werden, mit einer Schrittweite von 1, der Standardwert ist 5. Im Abschnitt 4.16 wird das Prinzip der Simulationsparameter ausführlicher
beschrieben.
template_input, template_output Sind die Eingabe-/Ergebnissschablonen einer Parameterstudie.
Diese werden für die Erstellung von Arbeitspaketen benötigt und werden in Kapitel 2 beschrieben.
49
1
2
3
4
5
6
7
8
9
10
FILE :
<file >
< f i l e n a m e >%s < / f i l e n a m e >
< d e s c r i p t i o n >%s < / d e s c r i p t i o n >
<max_nbytes >%s < / max_nbytes >
<data >
base64_encode ( $s )
</ data >
</ f i l e >
[ FILE ]
11
12
13
14
PARAMETER:
<parameter >NAME: START : STOP : STEP : DEFAULT< / parameter >
[PARAMETER]
15
16
17
18
19
20
RANGE:
<range >
[PARAMETER]
</ range >
[RANGE]
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
XML_comsol_put :
<comsol_put >
[AUTH]
<name>%s < / name>
<appid >%d < / appid >
<count >%d < / count >
[ FILE ]
<ranges >
[RANGE]
</ ranges >
< t e m p l a t e _ i n p u t > b a s e 6 4 _ e n c o d e (% s ) </ t e m p l a t e _ i n p u t >
< t e m p l a t e _ r e s u l t > b a s e 6 4 _ e n c o d e (% s ) </ t e m p l a t e _ r e s u l t >
<comsol >
<ckl / >
< l o g f i l e >%s < / l o g f i l e >
< s t d o u t >%s < / s t d o u t >
< s t d e r r >%s < / s t d e r r >
</ comsol >
</ comsol_put >
Listing 4.22: HTTP/XML-Request - Eine Parameterstudie erstellen
Wenn der Benutzer die richtigen Authentifizierungsdaten eingibt und eine passende Rolle besitzt,
erhält er durch die Anfragen aus Listing 4.23 Informationen über Prozesse und über die vorhandenen
wissenschaftlichen Applikationen.
1
2
3
4
XML_status :
<status >
[ AUTHENTICATION ]
</ s t a t u s >
5
6
7
8
9
XML_apps :
<apps >
[ AUTHENTICATION ]
</ apps >
Listing 4.23: HTTP/XML-Request - Status und Applikationen ermitteln
Das Listing 4.24 enthält die Struktur der Authentifizierung. Dieser Bereich muss in Anfragen eingebettet werden und die logische Abarbeitung von ComsolGridFCGI muss für die einzelnen XMLTags erweitert werden. Die Authentifizierungsfunktionen des ComsolGrid Frameworks ermitteln
50
4.13 Ermittlung von System-/Prozessinformationen
aus diesen Daten automatisch die Informationen des Simulanten und die jeweils definierte Benutzerrolle. Die Daten sind im Klartext einzutragen. Sonderzeichen, die nicht nach dem XML Standard [9]
verwendet werden können, müssen vermieden werden.
1
2
3
4
5
6
AUTHENTICATION :
<auth >
<username>%s < / username >
< email >%s < / email >
<password>%s < / password >
</ auth >
Listing 4.24: HTTP/XML-Request - Authentifizierung am Projektserver
Die Simulantenschnittstelle zum Erstellen von Parameterstudien, ermöglicht es dem Simulanten Informationen über den Projektserver und der durchzuführenden Parameterstudie abzufragen. Die Informationen werden im ComsolGridFCGI als statische Informationen abgespeichert. Bei Verwendung von statischen Informationen wird nicht unnötig Speicherplatz verwendet, so dass bei mehrmaliger Instantiierung des Informationsbeschaffungsprozesses (IBP), der selbige Speicherplatz verwendet wird.
Abbildung 4.9 enthält ein UML2 Zustandsdiagramm. Dieses Diagramm beschreibt die Implementierung des IBP im ComsolGrid Framework. Der IBP wird auf der linken Seiten mit dem
schwarzen Punkt begonnen. Der Übergang auf die Gabelung nach unten, beschreibt die Erstellung
eines neuen Prozesses, welcher nach rechts verläuft und für die Aktualisierung der Informationen
sorgt. Simulanten können die Informationen seit der letzten Aktualisierung abfragen, welche sich
im Datenspeicher STORE befinden. Der rechte Bereich in der Abbildung 4.9 zeigt, wie die Aktualisierung der Prozessinformationen statt findet. Der Prozess kann abstrakt durch drei Schritte beschrieben werden:
• Eine angegebene Zeit warten,
• Systembefehle ausführen um die Informationen zu erhalten und
• die Daten in den Datenspeicher STORE schreiben.
Die Implementierung und die logische Struktur dieses Sachverhalts wird durch das Sequenzdiagramm in Abbildung 4.10 erläutert. Das Sequenzdiagramm zeigt drei Zeitlinien. Die linke Zeitlinie
zeigt den Verlauf der Aktivitäten des Simulanten. Die mittlere Zeitlinie (Information Process Handler, nachfolgend „IPH“ genannt) beschreibt den linken Prozess aus Abbildung 4.9 und die rechte
Zeitlinie (Information Process Process nachfolgend „IPP“ genannt) beschreibt die Sequenzen des
rechten Prozesses aus dem Zustandsdiagramm in Abbildung 4.9. Es zeigt, dass die IPP in einer
Schleife läuft und kontinuierlich die Prozessinformationen ermittelt. Die IPH wird vom Simulanten
befragt, ob der IBP gestartet ist und wenn ja, werden die Informationen gelesen, wenn diese nicht
im Moment aktualisiert werden. In der Testversion des ComsolGrid Frameworks werden die nachfolgenden Informationen durch ComsolGridFCGI bereitgestellt. Die Namen auf der linken Seite
werden zum spezifischen Abruf der einzelnen Informationen verwendet und sind im ComsolGrid
Framework hard-codiert (vgl. Listing 4.25).
INFOS_BOINC_PROCESSES Durch diesen Namen werden Informationen über die BOINC
Prozesse abgefragt. Diese Informationen enthalten Daten darüber ob das BOINC Projekt gestartet ist, welche Daemons verwendet werden und mit welchen Parametern diese gestartet
sind. Es wird von den jeweiligen Prozessen die Prozess Identifikationsnummer (PID) angezeigt.
51
Abbildung 4.9: Der Informationsbeschaffungsprozess in einem UML2 Zustandsdiagramm
Bei periodisch ausgeführten Programmen wird ausgegeben, wann diese das letzte mal ausgeführt wurden und nach welchen Zeitintervall der nächste Aufruf erfolgt.
INFOS_SERVER_UPTIME Dieser Name liefert Standardinformationen über die Laufzeit des Betriebssystems. Die Ausgabe entspricht dem Format: 19:48:51 up 10:13, 7 users, load average:
0.01, 0.10, 0.14. Diese Zeichenkette enthält folgende Informationen (von links): (1) die aktuelle Uhrzeit, (2) die Zeit wie lange das System schon läuft, (3) die Anzahl der angemeldeten
Benutzer und (4) die durchschnittliche Systemauslastung der aktuellen, der letzten fünf und
fünfzehn Minuten.
INFOS_SERVER_MEMINFO Hier werden Informationen über den verfügbaren physikalischen
sowie logischen Arbeitsspeicher aufgelistet. Weiterhin wird aufgeführt wie viel Arbeitsspeicher verwendet wird. Die Informationen entsprechen der Ausgabe des Befehls
$cat /proc/meminfo eines Linux System.
INFOS_SERVER_CPUINFO Eine Auflistung der verfügbaren Central Processing Units (CPU)
wird durch diesen Namen erreicht. Der Befehl entspricht der Ausgabe des folgenden Befehls
innerhalb eines Linux Systems: $cat /proc/cpuinfo | grep -A3 model name".
INFOS_SERVER_DFINODE Liefert Informationen über die freien Inodes, entspricht dem Linux
Befehl $df -h -total -i.
INFOS_SERVER_DFMEMORY Ermittelt den freien Speicherplatz eines Rechnersystems. Dies
entspricht dem Linux Befehl $df -h -total.
1
2
3
4
5
/ / ComsolGrid
# i n c l u d e 
/ / C++
6
7
8
9
10
11
12
13
14
15
52
ComsolGrid : : I n f o s i n f o ;
i n f o . show ( ) ;
info . se tR efr esh Int er va l (10) ;
try {
info . run ( ) ;
} c a t c h ( s t d : : s t r i n g m es s ag e ) {
s t d : : c o u t << " Could n o t s t a r t : " << m es s ag e << s t d : : e n d l ;
return 1;
}
while ( inf o . isRunning ( ) ) {
i f (! info . isUpdating () ) {
s t d : : c o u t << " INFOS_BOINC_PROCESSES : " << i n f o . g e t I n f o ( INFOS_BOINC_PROCESSES
) << s t d : : e n d l ;
s t d : : c o u t << "INFOS_SERVER_UPTIME : " << i n f o . g e t I n f o ( INFOS_SERVER_UPTIME) <<
s td : : endl ;
s t d : : c o u t << "INFOS_SERVER_MEMINFO: " << i n f o . g e t I n f o ( INFOS_SERVER_MEMINFO)
<< s t d : : e n d l ;
s t d : : c o u t << "INFOS_SERVER_CPUINFO : " << i n f o . g e t I n f o ( INFOS_SERVER_CPUINFO )
<< s t d : : e n d l ;
s t d : : c o u t << "INFOS_SERVER_DFINODE: " << i n f o . g e t I n f o ( INFOS_SERVER_DFINODE)
<< s t d : : e n d l ;
s t d : : c o u t << "INFOS_SERVER_DFMEMORY : " << i n f o . g e t I n f o ( INFOS_SERVER_DFMEMORY
) << s t d : : e n d l ;
}
sleep (10) ;
}
info . stop () ;
16
17
18
19
20
21
22
23
24
25
26
27
28
29
4.14 Erstellung von Arbeitspaketen
}
Listing 4.25: Beispielanwendung zur Beschaffung von Informationen über definierte Prozesse
Folgende Dinge müssen bei der Ausführung dieser Implementierung beachtet
werden!
Die Informationsbeschaffung dieses Prozesses läuft in der Testimplementierung innerhalb der ComsolGridFCGI und dadurch unter den Benutzerrechten des Apache Webservers www-data. Weiterhin wird ein Aufruf gestartet, der Informationen über die BOINC Prozesse ermittelt. Für diesen
Zweck wird das Skript ./bin/status aufgerufen. Dieses Skript benötigt Leserechte auf die Dateien
./pid_HOSTNAME und run_state_HOSTNAME.xml, HOSTNAME ist ein Platzhalter für den eigentlichen
Namen des Hosts auf dem der Projektserver installiert ist. Diese Dateien müssen durch die Befehle
in Listing 4.26 geänderte Zugriffsrechte erhalten, da sonst keine Ausführung möglich ist.
1
2
3
4
5
6
7
8
9
#
#
#
#
$
$
#
#
#
Normalerweise s in d d ie Rechte :
drwxr−xr −x p i d _ S a t a r i n a
−rw−r−−r−− r u n _ s t a t e _ S a t a r i n a . xml
A en d er n m i t . . .
chmod 775 pid_HOSTNAME
chmod 664 run_state_HOSTNAME . xml
. . . zu :
drwxrwxr −x p i d _ S a t a r i n a
−rw−rw−r−− r u n _ s t a t e _ S a t a r i n a . xml
Listing 4.26: Änderung der Zugriffsrechte für das BOINC Skript ./bin/status
Für die Erstellung von Arbeitspaketen bietet das BOINC Framework verschiedene Möglichkeiten.
Es kann das Werkzeug ./bin/make_work verwendet oder eine eigene Implementierung durch Verwendung der BOINC Framework API (Application Programming Interface) implementiert werden.
Das ComsolGrid Framework verwendet die zweite Lösung, da diese mehr Vorzüge bietet und besser
an die eigenen Bedürfnisse angepasst werden kann. Die Arbeitspakete werden direkt in der ComsolGridFCGI Schnittstelle erstellt und dem entsprechenden Projekt hinzugefügt. Es werden die hoch
53
Abbildung 4.10: Der Informationsbeschaffungsprozess in einem UML2 Sequenzdiagramm
geladenen Daten aus dem XML-Baum <comsol_put> verarbeitet und daraus entsprechend die
Arbeitspakete definiert und erstellt.
Ein Arbeitspaket bei BOINC besteht aus ein oder mehreren Simulationsdateien und entsprechenden Parameter Eingabedateien. Diese sind für die Simulation elementar und im Falle von ComsolGrid entsprechen diese Dateien einer COMSOL Multiphysics Simulation und einer Datei, welche
die Simulationsparameter (vgl. Abs. 4.9) enthält. Die Abbildung 4.11 enthält eine Beschreibung
eines beispielhaften Arbeitspakets. Das Arbeitspaket hängt in diesem Fall von vier Dateien ab:
1. Zwei Schablonendateien,
2. einer COMSOL Simulationsdatei und
3. einer Datei, welche die Werte für die Simulationsparameter enthält.
Bei der Erstellung eines Arbeitspakets - sei es mit dem oben genannten Werkzeug oder mit einer
eigenen Implementierung - ist die Reihenfolge der anzugebenden Dateien sehr wichtig! In dem
54
Abbildung 4.11: Beispiel eines Komponentendiagramm für ein Arbeitspaket im ComsolGrid Framework
unteren, linken Kommentar in Abbildung 4.11, ist eine Beispieldarstellung einer Eingabenschablonendatei enthalten. Dort sind zwei Dateien angegeben, die jeweils einen Index haben, beschrieben
durch den XML-Parameter <number>. Die Datei comsol.mph hat die Indexnummer 0 und die
Datei comsol.txt den Index 1. Das heißt für die Arbeitspaketerstellung, dass erst die comsol.mph
und dann die comsol.txt Datei angegeben werden muss. Im ComsolGridStarter werden die Dateinamen comsol.mph und comsol.txt zum Öffnen der Dateien angenommen, dies sind logische Namen
im BOINC Framework und werden durch die Funktion boinc_resolve_file_s(...) in die physikalischen Pfade aufgelöst. Dies sind bei BOINC die sogenannten Slots (vgl. Abs. 2).
Angenommen, es befindet sich eine Simulationsdatei ./edge2d.mph und eine Parameterdatei
./wu291_values in dem Unterordner workunits2add/, dann würde die Befehlsreihenfolge in Listing 4.27 ein Arbeitspaket erstellen (die Daten sind angelehnt an die Namen in Abbildung 4.11).
1
2
3
4
5
6
7
$ cp ed g e2 d . mph ‘ b i n / d i r _ h i e r _ p a t h ed g e2 d . mph ‘
$ cp w o r k u n i t s 2 a d d / w u 2 9 1 _ v alu es ‘ b i n / d i r _ h i e r _ p a t h w u 2 9 1 _ v alu es ‘
$ . / b i n / c r e a t e _ w o r k −appname c o m s o l s t a r t e r \
−wu_name wu291 \
−w u _ t e m p l a t e . / E i n g a b e n s c h a b l o n e \
−r e s u l t _ t e m p l a t e . / E r g eb n is s ch ab lo n e \
ed g e2 d . mph w u 2 9 1 _ v alu es
Listing 4.27: Manuelle Erstellung eines Arbeitspakets
Die erste und zweite Zeile kopieren jeweils die Simulationsdateien in die Download-Ordnerstruktur
des BOINC Projekts. Weiterhin wird in der Datenbank eine Referenz eingetragen, die die Zuordnung zwischen den Dateinamen in der Eingabeschablonendatei und der physikalischen Ordnerstruktur ermöglicht. Die dritte Zeile erstellt das Arbeitspaket, zu beachten ist die Reihenfolge der
Dateien in der letzten Zeile. edge2d.mph wird im ComsolGridStarter mit ./comsol.mph geöffnet
und ./wu291_values mit dem Dateinamen ./comsol.txt.
Die Programmierung einer Routine zur Erstellung von Arbeitspaketen kann sehr aufwendig sein.
In der Testversion dieser Masterarbeit wurde eine Routine mit geringer Fehlerbehandlung und Prüfung der Erfolge implementiert. An dieser Stelle sei erwähnt, dass die vorhandene Implementierung
einer Überarbeitung bedarf, um eine höhere Performance zu erhalten und um eventuell die Redundanz zu steigern. Das BOINC Framework liefert mit den Funktionen SCHED_CONFIG::download_path(
55
4.15 Definition der Parameterstudienwerte
char∗, char∗) und create_work (...) die Möglichkeit, eine solche Implementierung vorzunehmen. Es sind
einige Schritte nötig um solch eine Implementierung durchzuführen:
1. Die Simulationsdateien müssen aus der Base64 Kodierung dekodiert und zwischengespeichert
werden,
2. die Liste der Simulationsdateien muss erstellt werden und in der richtigen Reihenfolge sein
(die Reihenfolge kann nicht geprüft werden, ist vom Simulanten abhängig),
3. die Parameterdateien werden erstellt,
4. die einzelnen Dateien müssen in die Download Ordnerstruktur des BOINC Projektes kopiert
werden,
5. es muss eine Instanz eines leeren Arbeitspakets erstellt werden,
6. diese Instanz wird mit den vorher erstellten Dateien gefüllt,
7. die Arbeitspakete werden mit der Funktion create_work (...) erstellt und die Schritte (5) und
(6) wiederholen sich so lange, wie eine Parameterdatei vorhanden ist, welche noch nicht zum
Projekt hinzugefügt ist.
Zum Testen der Arbeitspaketerstellung ist ein Skript in PHP implementiert (vgl. Anhang B.4). Wenn
Änderungen an dem Prozess zur Erstellung von Arbeitspaketen vorgenommen werden, können diese
mit dem erwähnten Skript geprüft werden.
4.15 Definition der Parameterstudienwerte
Die Parameter in ComsolGridQt, auf der Reiter Study haben folgendes Format
START:STOP:STEP:DEFAULT, wie dies in Abbildung 4.15 zu sehen ist. Das Kommunikationselement
<comsol_put>, zur Erstellung von Parameterstudien kann mehrere dieser Parameter aufnehmen,
die sich gekapselt in einem [RANGE]-Abschnitt (vgl. Listing 4.22) befinden. Das Listing 4.28 enthält
ein Beispiel eines Parameter Range mit den drei Parametern maxT, objWidth und objHeight. Die
Werte hinter den Namen in den Zeilen 1 - 3 beschreiben das oben genannte Format.
1
2
3
s t r u c t ComsolGrid : : P a r a m e t e r p1 ={ " maxT " ,
0.0 , 1.0 , 0.1 , 0.5 };
s t r u c t ComsolGrid : : P a r a m e t e r p2 ={ " o b j W i d t h " , 1 0 . 0 , 2 0 . 0 , 1 . 0 , 1 5 . 0 } ;
s t r u c t ComsolGrid : : P a r a m e t e r p3 ={ " o b j H e i g h t " , 3 3 . 5 , 3 4 . 0 , 0 . 1 , 3 3 . 5 } ;
4
5
6
7
8
ComsolGrid : : Range r 1 ;
r 1 . p u s h _ b ack ( p1 ) ;
r 1 . p u s h _ b ack ( p2 ) ;
r 1 . p u s h _ b ack ( p3 ) ;
9
10
11
ComsolGrid : : Ranges r a n g e s ;
r a n g e s . p u s h _ b ack ( r 1 ) ;
Listing 4.28: Beispiel eines Range mit drei Parametersätzen
Bei der Erstellung der Parameterdateien werden alle drei Parameter einzeln für sich durchlaufen.
Das bedeutet, im ersten Schritt wird der Parameter maxT variiert und von 0.0 bis 1.0 hochgezählt, als
Schrittweite wird 0.1 nach jedem Schritt hinzu addiert. Bei dieser Durchführung werden die anderen
Parameter auf deren Standardwert gesetzt und für jeden Durchlauf verwendet. Für den Parameter
objWidth, wird der Wert 15.0 und für den Parameter objHeight wird 33.5 als Wert, in die Simulation mit einbezogen. Das bedeutet für den ersten Fall, dass 11 Parametersätze erstellt werden, die in
Listing 4.29 exemplarisch aufgezeigt sind.
56
1
2
3
4
5
6
7
8
9
10
11
0.0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1.0
15.0
15.0
15.0
15.0
15.0
15.0
15.0
15.0
15.0
15.0
15.0
4.16 ComsolGridQt - Benutzerschnittstelle für Simulanten
33.5
33.5
33.5
33.5
33.5
33.5
33.5
33.5
33.5
33.5
33.5
Listing 4.29: Beispiel einer Parameterdatei, die aus den Parameter Ranges erstellt wird
In dem Beispiel aus Listing 4.28 werden 28 Variationen erstellt.
Die Anwendung ComsolGridQt ist eine grafische Benutzeroberfläche (engl. Graphical User Interface) (GUI). Durch diese kann der Simulant Parameterstudien erstellen. Alle von ComsolGridFCGI
zur Verfügung gestellten Funktionen werden unterstützt. Die grafische Benutzerschnittstelle ist in
sechs Reiter aufgeteilt. Die wichtigsten Reiter sind:
• Die erste Reiter in Abbildung 4.12, zur Einstellung der Authentifizierungsdaten.
• Die zweite Reiter in Abbildung 4.13, um Informationen der Prozesse des Projektservers zu
erhalten.
• Die dritte Reiter in Abbildung 4.14, um mit Hilfe der Simulationsparameter in Abbildung 4.15
eine Parameterstudie zu erstellen.
• Reiter fünf (s. Abb. 4.16), um die Class-Kit License (CKL) zu aktivieren.
Die Authentifizierungsdaten sind elementar für die Verwendung von ComsolGridQt und bestehen
aus drei Werten wie in Abbildung 4.12 zu sehen ist. Der Benutzername (engl. Username) wird im
Feld (1), die E-Mail Adresse in Feld (2) und das Passwort (engl. Password) in Feld (3) eingetragen. Wenn der Haken bei (2) angewählt wird, werden bei der Authentifizierung am Projektserver
der selbe Wert für den Benutzernamen und die E-Mail Adresse übernommen. Das Passwort kann
abgespeichert werden, wenn ein Haken bei (3) gemacht wird. Der untere Bereich (4) enthält einen
Ausgabe, in der Informationen für das Debuggen hinzugefügt werden. Somit kann bei Problemen
mit ComsolGridQt geprüft werden wo eventuell ein Fehler vorliegt. Das untere Fenster wurde in den
Abbildungen 4.13 bis 4.17 entfernt, ist in der real ausführenden Version allerdings jederzeit sichtbar
und gibt stetig Informationen aus. Die Abbildung 4.13 zeigt die Informationen, die mit den Kommunikationselementen aus Abschnitt 4.12 vom Projektserver erfragt werden können. Es wird die
Version des Projektservers angezeigt, welche COMSOL Multiphysics Versionen unterstützt werden
(hier: 3.5a, 4.0 und 4.0a) und die in Abschnitt 4.13 erwähnten Prozessinformationen werden durch
Klicken auf die unterschiedlichen Subreitern angezeigt. Die Daten können jederzeit aktualisiert werden, dazu bedarf es einem Klick auf die Schaltfläche zum Erneuern „Refresh“ der Daten . Der Klick
richtet sequentiell vier Anfragen an den Projektserver:
1. Ermittlung der Projektserver Version,
2. Anfrage der unterstützten COMSOL Multiphysics Versionen,
3. alle Informationen der Prozesse und
57
Abbildung 4.12: ComsolGridQt - Ansicht der Authentifizierungbereiche und dem Debug Bereich
58
Abbildung 4.13: ComsolGridQt - Ansicht der Prozessinformationen
4. die Nachfrage der installierten wissenschaftlichen Applikationen.
Die Ergebnisse werden sofort in der Darstellung übernommen und angezeigt.
Die GUI Elemente in Abbildung 4.14 und 4.15 ermöglichen das Erstellen einer neuen Parameterstudie (engl. Parameter Study). Die Elemente haben folgende Bedeutungen bzw. Funktionen:
(1) Dieses Auswahlfeld ermöglicht dem Simulanten das Auswählen einer wissenschaftlichen Applikation.
(2) Hier können Simulationsdateien zur Parameterstudie ausgewählt werden.
(3) Nach dem Auswählen einer Simulationsdatei, muss diese in die Liste der hinzugefügten Dateien
(engl. Added Files), durch ein Klick auf diese Schaltfläche, übernommen werden. Beim Hinzufügen wird geprüft, ob es sich um eine COMSOL Multiphysics Simulationsdatei handelt.
Falls ja, werden vorhandene Simulationsparameter ausgelesen und in die Parameterliste in
Abbildung 4.15 zur Auswahl eingetragen (vgl. Abs. 4.9).
(4) Eine Liste der hinzugefügten Simulationsdateien.
(5) Mit den Pfeilen kann die Reihenfolge der Elemente in (4) geändert werden. Dies ist wichtig,
da die Reihenfolge der Simulationsdateien mit der Dateireihenfolge aus der Eingabeschablonendatei (6) übereinstimmen muss. Bei der Erstellung der Arbeitspakete werden die Simulationsdateien in der Reihenfolge verwendet und die Assoziation zwischen virtuellen und physikalischen Namen in der Datenbank abgelegt (s. Abs. 2.4.3). Durch die Schaltfläche Remove
(auf Deutsch „Entfernen“) können die selektierten Dateien aus der Liste (4) entfernt werden.
(6), (7) Diese beiden Schaltflächen erlauben es dem Simulanten die Eingabe- und Ergebnisschablonendateien auszuwählen. Bei einem Klick auf die Schaltfläche (8) oder (9), wird der Inhalt
59
Abbildung 4.14: ComsolGridQt - Ansicht zur Erstellung einer neuen Parameterstudie
der Dateien eingelesen, Base64 kodiert und zum XML-Baum <comsol_put> hinzugefügt
(vgl. Abs. 4.12).
(8), (9) Die Schaltfläche (8) öffnet das Fenster aus Abbildung 4.20 und (9) transferiert die Daten
der neuen Parameterstudie an den Projektserver.
Die automatisch ermittelten Simulationsparameter (vgl. Abs. 4.9) können durch eine manuelle Eingabe (2) oder durch ein Einstellungsfenster (3) erstellt werden. Bei der Nutzung über das Einstellungsfenster, werden die Änderungen sofort in der Tabelle übernommen und der Simulant kann sich
sicher sein, dass die Daten das richtige Format besitzen. Einzelne Zeilen in der Liste, können durch
einen Klick auf die rechte Schaltfläche (1) entfernt und durch die linke Schaltfläche neu hinzugefügt
werden.
In der Abbildung 4.19 werden zu der ausgewählten wissenschaftlichen Applikation, die noch
ausstehenden Arbeitspakete und die schon erhaltenen Ergebnisse durch Zahlenwerte angezeigt. Dieser Dialog ist über die Klick-Wege ’Menüleiste’ -> ComsolGrid -> Workunit Status von
ComsolGridQt zu erreichen. Die Abbildung 4.20 enthält ein Textelement, in der die gefüllte Struktur des XML-Baums <comsol_put> enthalten ist. Zu erkennen sind die einzelnen Werte aus den
oben erwähnten Abbildungen.
(1) Diese Stelle zeigt die Authentifizierungsdaten, das Passwort wurde im Nachgang entfernt.
(2) Hier wird die wissenschaftliche Applikation mit Namen und der Identifizierungsnummer beschrieben. Die Parameterstudie wird zu dieser Applikation hinzugefügt.
(3) Die neue Parameterstudie besitzt <count> viele Dateien. Eine Simulationsdatei mit dem Namen
edge_load_2d.mph und einer Dateigröße von 106539 Bytes. Die Daten (engl. data) der Datei
sind als Base64 Kodierung mit eingefügt.
60
Abbildung 4.15: ComsolGridQt - Tabelle zum Erstellen von Simulationsparametern
Abbildung 4.16: ComsolGridQt - Einstellungen für ComsolGridStarter
61
Abbildung 4.17: ComsolGridQt - Liste der unterstützten ComsolGridStarter Versionen
Abbildung 4.18: ComsolGridQt - Ansicht des „Informationsfensters“
Abbildung 4.19: ComsolGridQt - Daten der Arbeitspakete (engl. Workunits) und Ergebnisse (engl.
Results)
62
Abbildung 4.20: ComsolGridQt - Ansicht der Konfiguration einer neuen Parameterstudie
(4) Es wurde eine Parameterreihe erstellt, die fünf Parameter enthält.
(5) Ebenso wie die Daten der Simulationsdateien, sind die Daten der Schablonendateien als Base64
Kodierung mit in den XML-Baum eingetragen.
(6) Diese Parameter betreffen den ComsolGridStarter direkt, dies ist in Abschnitt 4.7.2 nachzulesen.
63
4.17 ComsolGrid Validator
4.17 ComsolGrid Validator
In der Testversion von dem ComsolGrid Framework werden zwei Standardvalidatoren verwendet.
Diese wurden direkt aus dem BOINC Framework und den beigefügten Beispielanwendungen übernommen. Es wurde der (1) trivial_validator und der (2) bitwise_validator zum ComsolGrid
Framework hinzugefügt. (1) wurde umbenannt zu comsol_trivial_validator und (2) wurde zu
comsol_bitwise_validator umbenannt, damit eine spätere Modifizierung ermöglicht wird und
nicht in den Konfigurationen des Projektservers eingegriffen werden muss. So können neuere Versionen an die Stelle der alten Versionen kopiert und der Projektserver neu gestartet werden, so dass
die Änderungen greifen.
(1) Prüft nur ob eine Grenze der Rechenzeit überschritten wurde, wenn nein, dann ist das Ergebnis
valide, andernfalls wird das Ergebnis als Fehler markiert.
(2) Prüft zwei Ergebnisse auf gleiches binäres Format, sprich ob die Dateien bitweise gleich sind,
wenn ja, ist das Ergebnis valide, andernfalls wird das Ergebnis als Fehler markiert.
4.18 ComsolGrid Assimilator
Der Assimilator im Comsol Grid Framework, wurde wie die Validatoren vom BOINC Framework
übernommen. Der dort beigefügte Beispielassimilator copydir_assimilator wurde zu
comsol_copydir_assimilator umbenannt und dem Entwicklungszweig von dem ComsolGrid
Framework hinzugefügt. Ebenso wie bei den Validatoren in Abschnitt 4.17, können Änderungen
durch einfaches Ersetzen der alten Anwendung und Neustarten des Projektservers übernommen werden. Das valide Ergebnis aus der Validierung wird in einen Dateiordner kopiert, die Ergebnisse werden durchgehend mit einer Identifikation ausgestattet. Dies ist der einzige Unterschiede zum Assimilator, welcher vom BOINC Framework mitgeliefert wird. Dort werden nur Identifikationsnummern
verwendet, wenn mehr als ein Arbeitspaket mit demselben Namen vorhanden ist.
64
Kapitel 5
Testlauf und Funktionsprüfung
If you want and expect a program to work, you will be more likely to see a working
program – you will miss failures. If you expect it to fail, you’ll be more likely to see
the problems. If you are punished for reporting failures, you will miss failures. You
won’t only fail to report them – you will not notice them.
Kaner et al., 1999
Dieses Kapitel beschreibt Testdurchläufe, die im Rahmen dieser Masterarbeit durchgeführt worden
sind. Es beinhaltet die Beschreibung einer Testumgebung, einer Darlegung der verwendeten Konfigurationen und einer Auflistung von Problemen und Fehlern die während der Tests aufkommen
sind. Insgesamt wurden zwei Testdurchläufe absolviert. Die Fehlerquote des ersten Durchlaufs aus
Abschnitt 5.3, wurde im zweiten Testlauf aus Abschnitt 5.4 stark verringert.
5.1 Testumgebung
Die Testumgebung besteht aus drei Computersystemen, die sich im Netzbereich 192.168.1.0/24
befinden. In Abbildung 5.1 ist die Testumgebung verdeutlicht. Die drei Computersysteme sind mit
einem Router verbunden. An diesen Router ist weiterhin der Projektserver angeschlossen. Es ist
nicht ausgeschlossen, dass sich weitere Teilnehmer aus den Weitere Netzwerke verbinden. Der Projektserver beinhaltet die Installation der Applikation COMSOL Multiphysics. Diese Installation wird
mit dem Network File System (NFS) Protokoll an die drei Teilnehmer verteilt. Die NFS Serverkonfiguration befindet sich in der Datei /etc/exports, in Listing 5.1 ist der Inhalt aufgelistet1 . Im
1 Die Manpage $man 5 exports zu dieser Datei liefert weitere Informationen über die Struktur und Parameter dieser
Konfigurationsdatei.
Abbildung 5.1: Struktur der ComsolGrid Testumgebung
65
5.1 Testumgebung
Listing sind die ersten beiden Zeilen auskommentiert. Das Simulationsmodell in diesen Testläufen
ist ein COMSOL Multiphysics Version 4.0a Modell, daher sind die ersten beiden COMSOL Multiphysics Versionen nicht nötig und werden nicht an die Clients exportiert. Der zweite Parameter
visualgrid-* beschreibt die Clients/Hosts, die sich die Freigaben der Applikation COMSOL Multiphysics importieren dürfen.
1
2
3
# / u s r / l o c a l / co m s o l3 5 a v i s u a l g r i d −∗(rw , f s i d = r o o t , n o _ r o o t _ s q u a s h , n o _ s u b t r e e _ c h e c k ,
async )
# / u s r / l o c a l / co m s o l4 0 v i s u a l g r i d −∗(rw , f s i d = r o o t , n o _ r o o t _ s q u a s h , n o _ s u b t r e e _ c h e c k ,
async )
/ u s r / l o c a l / co m s o l4 0 a
v i s u a l g r i d −∗(rw , n o _ r o o t _ s q u a s h , n o _ s u b t r e e _ c h e c k , a s y n c )
Listing 5.1: Konfiguration des NFS Server
Die privilegierten Clients/Hosts sind in der Datei /etc/hosts definiert, der Inhalt ist in Listing 5.2
aufgeführt. Die Definitionen aus dem Listing sind Aliase und ermöglichen die wahlweise Nutzung
der IP-Adresse oder des jeweiligen FQDN der Clients/Hosts.
1
2
3
1 9 2 . 1 6 8 . 1 . 2 0 0 v i s u a l g r i d −1
1 9 2 . 1 6 8 . 1 . 2 0 1 v i s u a l g r i d −2
1 9 2 . 1 6 8 . 1 . 2 0 2 v i s u a l g r i d −3
Listing 5.2: Hostnamen der COMSOL Multiphysics Testhosts
Eingebunden wird das exportierte Verzeichnis durch den Befehl $mount in einem Linux System.
Dieses kann automatisch beim Starten der Computersysteme geschehen, oder manuell durch den
Benutzer des Computersystems. In Listing 5.3 ist die Konfiguration aus der Datei /etc/fstab der
einzelnen Clients/Hosts aufgeführt, um durch diese Einstellungen den Ordner mit der COMSOL
Multiphysics Installation zu importieren2. Die ersten zwei Zeilen sind wie in Listing 5.1 auskommentiert, da diese COMSOL Versionen nicht in dieser Testinstallation verwendet werden.
1
2
3
# 1 9 2 . 1 6 8 . 1 . 2 0 0 : / u s r / l o c a l / co m s o l3 5 a / u s r / l o c a l / co m s o l3 5 a n f s n o s u i d , s o f t , i n t r 0 0
# 1 9 2 . 1 6 8 . 1 . 2 0 0 : / u s r / l o c a l / co m s o l4 0 / u s r / l o c a l / co m s o l4 0 n f s n o s u i d , s o f t , i n t r 0 0
1 9 2 . 1 6 8 . 1 . 2 0 0 : / u s r / l o c a l / co m s o l4 0 a / u s r / l o c a l / co m s o l4 0 a n f s n o s u i d , s o f t , i n t r 0 0
Listing 5.3: Konfiguration zum Importieren des Ordner der COMSOL Multiphysics Installation
Die drei Computersysteme haben folgende Eigenschaften:
visualgrid-1;192.168.1.200/24 Plattform: 64 Bit-System, Prozessor: 8xIntel(R) Core(T M) i7 CPU
860 2.8GHz, Speicher: 8GB, Betriebssystem: Linux Ubuntu 10.4 LTS, Kernel: 2.6.32-22generic
visualgrid-2;192.168.1.201/24 Plattform: 32 Bit-System, Prozessor: 2xIntel(R) Pentium(R) 4 CPU
3.2GHz, Speicher: 2GB, Betriebssystem: Linux Ubuntu 10.4 LTS, Kernel: 2.6.32-24-genericpae
visualgrid-3;192.168.1.202/24 Plattform: 32 Bit-System, Prozessor: 2xIntel(R) Pentium(R) D CPU
3.2GHz, Speicher: 3GB, Betriebssystem: Linux Ubuntu 10.4 LTS, Kernel: 2.6.32-24-genericpae
Die Eigenschaften des Servers sind bei einer geringen Anzahl von Clients/Hosts nicht relevant
und müssen nicht unbedingt beachtet werden. Sollte die Anzahl der Teilnehmer allerdings in die
Höhe schnellen, muss über eine angemessene Konfiguration nachgedacht werden. ComsolGridStarter wurde in einer 32-Bit und 64-Bit Version zum Projekt hinzugefügt. In Listing 5.4 werden
die zwei Versionen in der Dateisystemhierarchie der Projektinstallation angezeigt.
2 Die
66
Manpages zum $mount-Befehl geben Informationen zu der Struktur der Datei /etc/fstab.
5.2 Testparameter
Abbildung 5.2: Ergebnis des COMSOL Multiphysics Testmodells falling_sand.mph
1
2
3
4
5
6
7
8
apps /
‘++ c o m s o l s t a r t e r
‘++ c o m s o l s t a r t e r _ 0 . 1 0 _ i6 8 6 −pc−l i n u x −g n u _ co m s o l4 0 a
‘++++ c o m s o l s t a r t e r _ 0 . 1 0 _ i6 8 6 −pc−l i n u x −g n u _ co m s o l4 0 a
++++ co m s o l . xml= co m s o l_ 0 . 1 0 _ i6 8 6 −pc−l i n u x −g n u _ co m s o l4 0 a . xml
‘++ c o m s o l s t a r t e r _ 0 . 1 0 _x86_64 −pc−l i n u x −g n u _ co m s o l4 0 a
‘++++ c o m s o l s t a r t e r _ 0 . 1 0 _x86_64 −pc−l i n u x −g n u _ co m s o l4 0 a
++++ co m s o l . xml= co m s o l_ 0 . 1 0 _x86_64 −pc−l i n u x −g n u _ co m s o l4 0 a . xml
Listing 5.4: 32-Bit und 64-Bit Version von ComsolGridStarter
5.2 Testparameter
Der Testdurchlauf wird mit einem COMSOL Multiphysics Simulationsmodell für das Major Release
4.0a ausgeführt. Es wurde kein eigenes Simulationsmodell erstellt. Der Testbetrieb wird mit einem
Simulationsmodellbeispiel ausgeführt, welches bei der Installation von COMSOL Multiphysics mit
installiert wird und hat den Namen falling_sand.mph. Dieses Simulationsmodell ist eine FluidDynamik Simulation und befindet sich in dieser Testinstallation im Dateiordner
/usr/local/comsol40a/models/COMSOL\_Multiphysics/Fluid\_Dynamics/
Die Beschreibung dieser Datei steht im nachfolgenden zitierten Text, der Eins-zu-eins aus dem
Modell übernommen ist. In der Abbildung 5.2, ist das Ergebnis dieser Simulation zu finden. Für
weitere Erläuterungen und Informationen über das Modell, wird an dieser Stelle direkt auf die Hilfe
von COMSOL Multiphysics verwiesen. In dieser Masterarbeit ist nicht das Modell relevant, sondern
die Umsetzung der Parameterstudie.
Terminal Falling Velocity of a Sand Grain
A spherical sand grain falls in a water tank. Released from stand-still, the grain accelerates and reaches a terminal velocity. This model simulates the fluid flow in a moving
coordinate system coupled to an ODE that describes the force balance on the grain.
67
5.2 Testparameter
Abbildung 5.3: Parameter des COMSOL Multiphysics Testmodells falling_sand.mph
Für eine Parameterstudie werden Parameter benötigt. Das Modell besitzt schon sechs Parameter
(vgl. Abb. 5.3), diese werden so übernommen und um zwei Parameter erweitert. Diese zwei neuen
Parameter sind zum Einstellen der Geometrie gedacht. Für diesen Zweck wurden die Parametervariablen objWidth und objHeight zum Parametersatz hinzugefügt. Im Simulationsdurchlauf mit
dem ComsolGrid Framework, werden diese Parameter zwischen 0.001 − 0.015 für objWidth und
0.001 − 0.025 für objHeight definiert. Die zwei Parameter werden nach dem Format aus Abschnitt
4.9 folgendermaßen variiert:
objWidth 0.001:0.015:0.0005:0.006
objHeight 0.001:0.025:0.001:0.014
Insgesamt werden somit 54 Arbeitspakete erstellt, wie dies in Listing 5.5 zu sehen ist. Es werden
zwei Ergebnisse für die Validierung eines Arbeitspakets verlangt, daher werden in Abbildung 5.4 (1)
108 angezeigt. Im Listing 5.5 wird die Ausgabe von ComsolGridFCGI gezeigt, wenn eine Parameterstudie vom Simulanten erstellt wird. Zeile 15 und 16 enthalten die Variationsparameter mit ihren
Start-/End- und der Schrittweite. In Zeile 17 wird bekanntgegeben, dass die Arbeitspaketdateien
im Downloadordner des Projektservers erstellt sind. Die Zeilen danach, geben Auskunft darüber,
welches Arbeitspaket zum Server hinzugefügt wurde.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
68
ComsolStudyXML p a r s e ( ) e n t e r i n g . . .
a u t h u s er n am e : boincadm@fh− b i e l e f e l d . de
a u t h e m a i l : boincadm@fh−b i e l e f e l d . de
a u t h p a s s w o r d : xxx
U s er ( boincadm@fh−b i e l e f e l d . de ) l o g g e d i n .
ComsolStudyXML p a r s e ( ) l e a v i n g . . .
OK: S t o r i n g i n p u t t e m p l a t e d a t a .
OK: S t o r i n g r e s u l t t e m p l a t e d a t a .
OK: 1 f i l e ( s ) u p l o a d e d
DEBUG: u p l o a d e d f i l e : f a l l i n g _ s a n d . mph
DEBUG: u p l o a d d i r e c t o r y : / home / boincadm / p r o j e c t s / c o m s o l w r a p p e r / u p l o a d
DEBUG: w o r k u n i t name : w u _ co m s o lg r i d _%d_%05d
DEBUG: r a n g e c o u n t : 1
DEBUG: r a n g e w i t h 2 p a r a m e t e r :
DEBUG: > p : o b j W i d t h : 0 . 0 0 1 0 0 0 : 0 . 0 1 5 0 0 0 : 0 . 0 0 0 5 0 0
DEBUG: > p : o b j H e i g h t : 0 . 0 0 1 0 0 0 : 0 . 0 2 5 0 0 0 : 0 . 0 0 1 0 0 0
DEBUG: 54 f i l e s c r e a t e d
DEBUG: i n f i l e s _ l a s t _ i n d e x =1
DEBUG: f i l e n a m e ( 0 ) = f a l l i n g _ s a n d . mph
DEBUG: wu f i l e n a m e = w u _ co m s o lg r id _ 1 _ 0 0 0 0 1
DEBUG: i n f i l e s _ l a s t _ i n d e x =1
DEBUG: f i l e n a m e ( 0 ) = f a l l i n g _ s a n d . mph
DEBUG: wu f i l e n a m e = w u _ co m s o lg r id _ 1 _ 0 0 0 0 2
24
25
...
...
Listing 5.5: Ausgabe der ComsolGridFCGI Applikation zur Erstellung von Arbeitspaketen
In Listing 5.6 wird der Status des Projekts gezeigt. Die Prozesse zum Zuweisen von Arbeitspaketen
an die jeweiligen Clients (feeder, transitioner), zum Löschen von alten und nicht mehr benötigten Dateien und Datensätzen (file_deleter, db_purge) sind gestartet. Die zwei Programme
comsol_bitwise_validator (vgl. Abs. 4.17) und comsol_copydir_asssimilate (vgl. Abs. 4.18)
sind dem Projekt hinzugefügt und gestartet. Diese zwei Anwendungen validieren die zurückgelieferten Ergebnisse und speichern diese im Dateisystem ab, wenn ein valides Ergebnis vorliegt.
1
BOINC i s ENABLED
2
3
4
5
6
7
8
9
DAEMON p i d
1 12846
2 12848
3 12850
4 12852
5 12854
6 12856
status
running
running
running
running
running
running
. . . commandline
. . . f e e d e r −d 2
. . . t r a n s i t i o n e r −d 2
. . . f i l e _ d e l e t e r −d 2
. . . c o m s o l _ b i t w i s e _ v a l i d a t o r −mod 2 1 −d 2 −app c o m s o l s t a r t e r
. . . c o m s o l _ c o p y d i r _ a s s i m i l a t e −d 2 −app c o m s o l s t a r t e r
. . . d b _ p u r g e −d 2 −m in _ ag e_ d ay s 7 −g z i p
10
11
12
13
14
15
16
17
18
TASK
1
2
3
4
5
6
7
...
...
...
...
...
...
...
...
period
5 min
5 min
5 min
5 min
5 min
1 days
1 days
next run
NOW
NOW
NOW
NOW
NOW
NOW
NOW
...
...
...
...
...
...
...
...
commandline
db_dump −d 2 −dump_spec . . / db_dump_spec . xml
r u n _ i n _ o p s . / u p d a t e _ u o t d . php
r u n _ i n _ o p s . / u p d a t e _ f o r u m _ a c t i v i t i e s . php
u p d a t e _ s t a t s −u p d a t e _ u s e r s −u p d a t e _ h o s t s
r u n _ i n _ o p s . / u p d a t e _ p r o f i l e _ p a g e s . php
r u n _ i n _ o p s . / t e a m _ i m p o r t . php
r u n _ i n _ o p s . / n o t i f y . php
Listing 5.6: Projektstatus, nachdem die Parameterstudie initialisiert ist (gekürzte Ausgabe)
Das ComsolGrid Framework funktioniert. Die Testreihe aus dem vorherigen Kapitel wurde in knapp
zwei Stunden bearbeitet. In Abbildung 5.4 ist das gesamte Ergebnis der Simulationsdurchführung
nachvollziehbar. Die nachfolgende Auflistung beschreibt die nummerierten Elemente in der Abbildung.
(1) Anzahl der gesamten durchzuführenden Simulationen. Es wurden im vorherigen Abschnitt nur
die Hälfte an Arbeitspaketen erstellt, allerdings werden zwei Ergebnisse benötigt, um das
Ergebnis zu validieren.
(2) Entspricht der Anzahl an erfolgreichen Simulationsdurchführungen. Somit sind 37% der Arbeitspakete erfolgreich bearbeitet worden. Es ist eine starke Erhöhung möglich, wenn die
Fehler beim Herunterladen (vgl. Abb. 5.6) der Dateien nicht mehr vorkommen.
(3) Anzahl der Fehler bei der Durchführung der Parameterstudie.
(4) Dieser Wert ist gleich dem Vorherigen, da 34 Simulationen nicht durchgeführt wurden, müssen
diese 34 Simulationen nicht durchgeführt werden. Diese könnten nicht validiert werden, da
ein zweites Ergebnis fehlt.
(5) Anzahl der bisher erfolgreich validierten Ergebnisse, 11 weitere Validierungen wurden übersprungen, da die zweiten Ergebnisse wohl sicherlich einen Fehler bei der Durchführung hatten. Die Summe der Ergebnisse in dieser Tabelle, entsprechen dem Wert der erfolgreichen
Simulationen.
69
Es muss erwähnt werden, dass die Durchführung sicherlich eine bis zwei Stunden länger gedauert
hätte, wenn nicht im Laufe der Simulation das Simulationsmodell von dem Daemon file_deleter
gelöscht worden würde. Durch das vorzeitige Löschen, kam es zu 29 Fehlern beim Herunterladen
der Daten (vgl. Abb. 5.6). Weiterhin sind vier Fehler vorhanden, bei denen die Grenze der erlaubten
Ressourcennutzung (evtl. Ergebnisdatei zu groß, oder zu hohe Anzahl an Rechenzyklen) überschritten wurde.
Der eine unbekannte Fehler liegt an einem Absturz des BOINC Managers auf dem Host
visualgrid-2, während der Ausführung eines Arbeitspakets. Der BOINC Manager ist womöglich
deswegen abgestürzt, da es beim Starten von COMSOL ein Problem gab. Dieses Problem konnte
durch eine Änderung der COMSOL Konfiguration behoben werden. Die nachfolgende Datei enthält
die COMSOL relevanten Laufzeiteinstellungen.
/home/cr/.comsol/v40a/comsol.prefs
Der Parameter
graphics.rendering.2drend=swt
musste auf diesem Client in
graphics.rendering.2drend=swing
geändert werden. Nach dieser Änderung, wurden die Simulationen erfolgreich gestartet und ausgeführt. SWT3 und SWIFT sind Programmbibliotheken, die das Rendering von bestimmten grafischen
Elementen übernehmen.
In der Abbildung 5.5 können mehr Informationen zu den Fehlern eingeholt werden. Es wird
angezeigt, auf welchem Host welche Art von Fehler aufgetreten ist und wann dieser Fehler war.
Durch einen Klick auf die Nummern links im Bild, wird eine Detailansicht der einzelnen Ergebnisse
angezeigt. Zur Ermittlung der Fehlerquellen muss diese Detailansicht nicht in Anspruch genommen
werden, da der Fehler schon im Vorfeld gefunden wurde.
Es wurde ein zweiter Testlauf durchgeführt und die Konfiguration für diesen Testlauf wurde von der
ersten Testinstallation übernommen. Eine Ausnahme wurde hinzugefügt, der Prozess zum Löschen
von nicht mehr benötigten Dateien wurde in der Konfigurationsdatei config.xml deaktiviert. Das
folgende Listing 5.7 beinhaltet den editierten Ausschnitt der Konfigurationsdatei:
1
2
3
4
5
6
<daemon >
<cmd> f i l e _ d e l e t e r −d 2 </cmd>
< d i s a b l e d > 1 </ d i s a b l e d >
< o u t p u t > f i l e _ d e l e t e r . l o g </ o u t p u t >
 f i l e _ d e l e t e r . p i d 
</ daemon >
Listing 5.7: Konfiguration zum Deaktivieren eines Daemon
Der entscheide Parameter ist in Zeile drei hinzugefügt. Der Daemon ist deaktiviert, siehe auch das
nachfolgende Listing 5.8. Dieses sagt aus, dass der Daemon nicht gestartet ist und dadurch auch
keine PID besitzt.
3 Das Standard Widget Toolkit (SWT) ist eine Java Bibliothek zur Erstellung von Benutzeroberflächen,
http://www.eclipse.org/swt.
70
Abbildung 5.4: Ergebnisseite des 1. Testdurchlaufs
Abbildung 5.5: Fehleransicht des 1. Testdurchlaufs
Abbildung 5.6: Auflistung der Fehler des 1. Testdurchlaufs
71
Abbildung 5.7: Ergebnisseite des 2. Testdurchlaufs
1
2
3
4
DAEMON p i d
1
7119
2
7122
3
0
status
running
running
lockfile
locked
locked
UNLOCKED
disabled
no
no
yes
commandline
f e e d e r −d 2
t r a n s i t i o n e r −d 2
f i l e _ d e l e t e r −d 2
Listing 5.8: Status des BOINC Projekts mit deaktiviertem file_deleter Prozess
Das Ergebnis des zweiten Testdurchlaufs ist eine Erfolgsquote von 95%. Die Abbildungen 5.7 und
5.8 verdeutlichen dies. Der gesamte Testlauf benötigte 209 Minuten. In Abbildung 5.7 ist folgendes
zu erkennen:
(1) Es wurden 82 vollständige Simulationen erfolgreich durchgeführt.
(2) Bei der Ausführung sind 5 Fehler aufgetreten. Diese sind einfach nachvollziehbar, 3 Fehler
entsprechen den Fehlern beim ersten Testlauf und bei den 2 weiteren hat ein Rechner gestreikt.
Dieser Rechner ist einmal abgestürzt und das zweite Problem war, dass die Benutzeroberfläche
eingefroren ist und dadurch diese nicht mehr steuerbar.
(3) Zum Zeitpunkt der Erstellung des Bildschirmfoto, wurden 27 Arbeitspakete erfolgreich validiert. Es wurde danach eine manuelle Validierung durchgeführt, so dass nicht auf den nächsten
Validierungszeitpunkt gewartet werden musste. Die Abbildung 5.8 beinhaltet das Ergebnis der
manuellen Validierung, 54 Arbeitspakete sind erfolgreich validiert worden (1). Es sind weiterhin 28 invalide Ergebnisse vorhanden, da bei der manuellen Ausführung der Validierung eine
einfache Validierung gewählt, also keine zwei Ergebnisse benötigt werden.
Die Ergebnisdateien sind im Ergebnisordner gespeichert. Das Listing 5.9 beinhaltet eine gekürzte
Ansicht der Ergebnisse.
1
2
3
72
b o i n c a d m @ v i s u a l g r i d −s e r v e r : ~ / p r o j e c t s / c o m s o l w r a p p e r / c o m s o l g r i d _ r e s u l t s $ l −h
t o t a l 97M
drwxrwxr−x 2 boincadm boincadm 4 , 0K 2010−09−03 0 9 : 5 9 e r r o r s
Abbildung 5.8: Ergebnisseite des 2. Testdurchlaufs nach manueller Validierung
4
5
6
7
8
9
10
11
12
−rw−r−−r−−
...
...
1
1
1
1
1
1
1
boincadm
boincadm
boincadm
boincadm
boincadm
boincadm
boincadm
boincadm
boincadm
boincadm
boincadm
boincadm
boincadm
boincadm
5 , 1M
5 , 1M
5 , 1M
5 , 1M
5 , 1M
5 , 1M
5 , 1M
2010−09−03
2010−09−03
2010−09−03
2010−09−03
2010−09−03
2010−09−03
2010−09−03
11:17
10:24
10:18
10:26
11:09
10:59
11:37
wu_1_11_000000
wu_1_17_000000
wu_1_23_000000
wu_1_25_000000
wu_1_27_000000
wu_1_29_000000
wu_1_31_000000
Listing 5.9: Gekürzte Ansicht der Ergebnisdateien
73
Kapitel 6
Zusammenfassung und weitere
Betrachtungen
Intelligenz lässt sich nicht am Weg, sondern nur am Ergebnis feststellen.
Garri Kasparov
6.1 Wissenschaftlicher Beitrag
Der wissenschaftliche Beitrag ist:
1. Es wurde die Möglichkeit geschaffen, eine Legacy Applikation mit BOINC arbeiten zu lassen,
ohne dass eine externe Wrapper Implementierung verwendet werden muss, mit der keine direkte Prozesskontrolle möglich ist.
2. Weiterhin können hoch-skalierbare COMSOL Multiphysics Parameterstudien in Zusammenarbeit mit BOINC durchgeführt werden.
Diese Masterarbeit ermöglicht es hoch-skalierbare Langzeitsimulationen mit verschiedenen Parametern zu erstellen und unabhängig voneinander ausführen zu lassen. Dadurch können schnellere
Ergebnisse durch parallele Verarbeitung erstellt werden. Diese Arbeit besitzt - wirtschaftlich gesprochen - eine hohe Rentabilität und sollte weiter verfolgt werden!
6.2 Zusammenfassung
Diese Masterarbeit gab einen Überblick über die Funktionalitäten von BOINC, wofür BOINC verwendet werden kann, wie die Architektur eines BOINC Projekts und des zugehörigen Framework
geschaffen ist und wie Entwickler, Wissenschaftler oder Simulanten damit arbeiten können.
Im Kern dieser Arbeit wurde das ComsolGrid Framework erläutert, mit dessen Hilfe die COMSOL Multiphysics Simulationssoftware mit BOINC verheiratet wurde. Es sind die Möglichkeiten
geschaffen worden, um mit einem einfach zu bedienenden grafischen Werkzeug, hoch-skalierbare
Parameterstudien zu erstellen. Während der Laufzeit der Simulation, können zu jeder Zeit Informationen über die laufenden Prozesse eingeholt werden. Es ist ein eigener Wrapper entwickelt
worden, der die Steuerung von COMSOL Multiphysics über das BOINC Framework ermöglicht.
Der Anwender hat volle Kontrolle über die Laufzeiten der Simulationen und kann diese jederzeit
pausieren, weiterführen oder abbrechen. Der Fortschritt der Simulationen, kann von den Anwendern jederzeit eingesehen werden. Es sind verschiedene COMSOL Multiphysics Versionen nutzbar.
Es werden automatisch die einstellbaren Simulationsparameter ermittelt und dem Simulanten für
75
6.3 Zukünftige Arbeiten
Zusammenfassung und weitere Betrachtungen
Konfigurationszwecke zur Verfügung gestellt. Die ComsolGridFCGI Schnittstelle auf dem Projektserver, übernimmt die aufwendige Erstellung von Arbeitspaketen mit den unterschiedlichsten Parameterwerten. Zu guter Letzt überprüfen spezielle Validatoren und Assimilatoren die Ergebnisse
und speichern diese für spätere Zugriffe ab.
Eine kleine Testreihe hat bewiesen, dass das ComsolGrid Framework zuverlässig und richtig arbeitet.
6.3 Zukünftige Arbeiten
Durch diese Arbeit wurde der Blickwinkel auf das BOINC Framework und die darunter liegende Architektur vergrößert. Es wurde ein Gespür für die Mächtigkeit des BOINC Frameworks entwickelt.
Die Gabe einzuschätzen, mit wie vielen oder wie wenig Schritten eine Erweiterung der Funktionalität oder Abänderung der logischen Struktur von BOINC möglich ist, wurde verfeinert.
Für weitere Arbeiten wäre ein neuer Ansatz einer Wrapper Implementierung denkbar. Ein Linux Kernelmodul könnte die Verwaltung der Prozesse übernehmen. Das Simulationswerkzeug zum
Starten der Legacy Applikation registriert sich beim Kernelmodul und gibt an, welches Programm
gestartet werden soll. Das Kernelmodul startet dieses Programm und lässt sich über ein CharacterDevice steuern und auslesen. Dadurch würde der Verwaltungsapparat für das BOINC Framework
womöglich gering sein.
Das ComsolGrid Framework kann durch zahlreiche Funktionalitäten erweitert werden. Im Anhang
A sind Argumente aufgeführt, mit denen die COMSOL Multiphysics Simulationssoftware gestartet werden kann. Die aktuelle Wrapper Implementierung unterstützt nicht alle Argumente, diese
Möglichkeiten könnten geschaffen werden. Weiterhin fehlen an einigen Stellen, in der Interna des
ComsolGrid Frameworks, ordnungsgemäße Fehlerbehandlungen, z.B. bei der Erstellung von Arbeitspaketen. Bisher sind Protokollierungsdateien der beste Weg zur Analyse und Diagnose. Das
gesamte Framework ist bisher nur auf Linux Systemen geprüft und ausgeführt worden. Eine Portierung auf weitere Plattformen wäre denkbar. Der Wrapper kann für weitere Legacy Applikationen umgeschrieben werden, evtl. wäre eine Implementierung als generell verwendbarer Wrapper
denkbar. Dieser generelle Wrapper könnte sich adaptiv an die auszuführenden Legacy Applikationen anpassen, somit wäre eine dauerhafte Ausführung von verschiedensten Anwendungen denkbar
(evtl. durch Einführung von Profilen für verschiedene Anwendungen).
Weiterhin wäre eine Vereinfachung der Installation und Nutzung möglich, z.B. könnten Konfigurationen passend generiert werden. Die Installation der Grundstruktur wird bisher nur durch ein
einfaches Shell-Skript zur Verfügung gestellt. An dieser Stelle ist viel Potential für Verbesserungen vorhanden, allein in Bezug auf Fehler bei der Installation, wenn Zugriffsrechte falsch gesetzt
werden.
76
Literaturverzeichnis
[1] D. P. Anderson, BOINC: Middleware for Volunteer Computing, Space Sciences Laboratory,
University of California, Berkeley, 2010
[2] D. P. Anderson, C. Christensen, and B. Allen, Designing a Runtime System for Volunteer Computing, UC Berkeley Space Sciences Laboratory, Dept. of Physics, University of Oxford, and
Physics Dept., University of Wisconsin - Milwaukee, 2006
[3] D. P. Anderson, and G. Fedak, The Computational and Storage Potential of Volunteer Computing, IEEE/ACM International Symposium on Cluster Computing and the Grid, Singapore,
May, 2006
[4] D. P. Anderson, BOINC: A System for Public-Resource Computing and Storage, 5th
IEEE/ACM International Workshop on Grid Computing, Pittsburgh, USA, November, 2004
[5] D. P. Anderson, E. Korpela, and R. Walton, High-Performance Task Distribution for Volunteer
Computing, First IEEE International Conference on e-Science and Grid Technologies, Melbourne, December, 2005
[6] O. Baskova, O. Gatsenko, G. Fedak, O. Lodygensky, and Y. Gordienko, Porting Multiparametric MATLAB Application for Image and Video Processing to Desktop Grid for HighPerformance Distributed Computing, Poster, March, 2010
[7] J. Blanchette, and M. Summerfield, C++ GUI Programming with Qt 4, Prentice Hall Internationa, 2006
[8] R. Bless, E.-O. Blaß, M. Conrad, H.-J. Hof, K. Kutzner, S. Mink, und M. Schöller, Sichere
Netzwerkkommunikation: Grundlagen, Protokolle und Architekturen, Springer, Berlin, Juni,
2005, ISBN: 978-3540218456
[9] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, and F. Yergeau, Extensible Markup
Language (XML) 1.0 (Fifth Edition), W3C, Specification, 26. November 2008
[10] M. R. Brown, FastCGI Specification, Open Market, Inc., 245 First Street, Cambridge, MA
02142 U.S.A., April, 1996, URL: http://www.fastcgi.com
[11] P. P. Chen, The Entity-Relationship Model: Toward a Unified View of Data, ACM Transactions
on Database Systems, Volume 1, Pages 9-36, 1976
[12] P. Deutsch, GZIP file format specification version 4.3, Aladdin Enterprises, Network Working
Group, RFC 1952, 1996
77
LITERATURVERZEICHNIS
[13] C. Gillies, Wie wir waren. Die wilden Jahre der Web-Generation, Wiley-VCH, 1. Auflage, Juli,
2003, ISBN: 978-3527500666
[14] D. Gonzales, F. Vega, L. Trujillo, G. Olague, M. Cardenas, L. Araujo, P. Castillo, K. Sharman,
and A. Silva, Interpreted Applications within BOINC Infrastructure, Presentation, May, 2008
[15] B. J. Gough, and R. M. Stallman, An Introduction to GCC, Network Theory Ltd, März, 2004,
ISBN: 978-0954161798
[16] B. Grüdelbach, Programming Library: hashlib++, URL: http://hashlib2plus.sourceforge.net
[17] S. Josefsson, The Base16, Base32, and Base64 Data Encodings, Network Working Group,
RFC 3548, Juli, 2003
[18] S. Josefsson, The Base16, Base32, and Base64 Data Encodings, Network Working Group,
RFC 4648, Oktober 2006
[19] C. Kaner, J. Falk, and H. Q. Nguyen, Testing Computer Software, Wiley, 1999, ISBN 0-47135846-0
[20] C. B. Ries, T. Hilbig, and C. Schröder, UML 2.2: Profil: Visu@lGridML, University of Applied
Sciences Bielefeld, April, 2010
[21] R. Rivest, The MD5 Message-Digest Algorithm, MIT LCS & RSA Data Security, Inc., RFC
1321, April, 1992
[22] R. Saccoccio, FastCGI, O’reilly’s Open Source ’99 Conference, Monterey, CA, USA, 1999
[23] A. C. Marosi, Z. Balaton, and P. Kacsuk, GenWrapper: A Generic Wrapper for Running Lagacy
Applications on Desktop Grids, 3rd Workshop on Desktop Grids and Volunteer Computing
Systems (PCGrid 2009), Rome, Italy, May, 2009
[24] R. Mecklenburg, Managing Projects with GNU Make: The Power of GNU Make for Building
Anything, O’Reilly, November, 2004, ISBN: 978-0596006105
[25] J. Muday, ipchains and iptables for Firewalling and Routing, Instructional Technology Consultant, Department of Biology, Wake Forest University, 2003
[26] Sun Microsystems, Inc., JavaTM Object Serialization Specification, Sun Microsystems, Inc.,
901 San Antonio Road, Palo Alto, California 94303-4900 U.S.A., 2003
[27] Sun Microsystems, Inc., JAR File Specification, Oracle and/or its affiliates., 2003
[28] Canoncial Ltd., Ubuntu Team Wiki, https://wiki.ubuntu.com
https://wiki.ubuntu.com
[29] unknown, FastCGI: A High-Performance Web Server Interface, Open Market, Inc., 245 First
Street, Cambridge, MA 02142 U.S.A., April, 1996, URL: http://www.fastcgi.com
[30] unknown, FastCGI: Understanding FastCGI Application Performance, Open Market, Inc., 245
First Street, Cambridge, MA 02142 U.S.A., June, 1996, URL: http://www.fastcgi.com
[31] M. Zahn, Unix-Netzwerkprogrammierung mit Threads, Sockets und SSL, Springer, Berlin,
2006, ISBN: 978-3540002994
[32] Qt - Cross-platform application and UI framework, URL: http://qt.nokia.com
78
LITERATURVERZEICHNIS
[33] BOINC - Open-source software for volunteer computing and grid computing, URL:
http://boinc.berkeley.edu
[34] Unofficial BOINC Wiki, URL: http://www.boinc-wiki.info
[35] COMSOL Multiphysics, URL: http://www.comsol.de
[36] mod_ssl - Apache HTTP Server, URL: http://httpd.apache.org/docs/2.0/mod/mod_ssl.html
[37] SSL/TLS
Strong
Encryption:
FAQ
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html
Apache
HTTP
Server,
URL:
[38] MySQL 5.6 Reference Manual, URL: http://dev.mysql.com/doc/refman/5.6/en/
79
Anhang A
COMSOL Multiphysics Startparameter
Diese Abschnitt beinhaltet die Parameter die beim Starten von COMSOL Multiphysics mit angegeben werden können. Für diese Masterarbeit war der Parameter batch zum Starten einer Simulation
im Batch-Modus wichtig. Dieser ist in der COMSOL Multiphysics Version 4.0 fehlerhaft und funktioniert nicht mit der Class-Kit License, wie sie in der Fachhochschule Bielefeld verwendet wird.
Die COMSOL Multiphysics Versionen 3.5a und 4.0a sind im Gegensatz dazu voll einsetzbar.
1
Usage : co m s o l [ o p t i o n s ] [ t a r g e t ] [ t a r g e t a r g u m e n t s ]
2
3
COMSOL t a r g e t s :
4
5
6
7
8
9
10
co m s o l
co m s o l
co m s o l
co m s o l
co m s o l
co m s o l
server
batch
compile
s e r v e r matlab
matlab
Run COMSOL M u l t i p h y s i c s
Run COMSOL M u l t i p h y s i c s
Run a COMSOL j o b
Compile a COMSOL Model
Run MATLAB w i t h COMSOL
Run MATLAB w i t h COMSOL
D es k to p
server
java f i l e
server
paths
11
12
COMSOL o p t i o n s :
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
−h , −h e l p
−v , − v e r s i o n
−32
−64
−np <number o f p r o c e s s o r s >
−mpmode < t h r o u g h p u t /
t u r n a r o u n d / owner >
−b l a s <{ a u t o } / mkl / acml / p a t h
−b l a s p a t h <path >
−i p v 6
−t m p d i r 
−nn <no . o f nodes >
−n n h o s t <no . o f nodes >
−m p i r o o t 
−m p i r s h 
−mpi <{ a u t o } / mpich2 / i n t e l /
wccs2003 / whpc2008 /
u s er / path >
−m p i p a t h < f i l e >
−s c a l a p a c k <{ a u t o } / mkl /
u s er / path >
35
36
−s c a l a p a c k p a t h < f i l e >
Show t h i s h e l p m es s ag e
Show v e r s i o n i n f o r m a t i o n
Use a 32− b i t d a t a model i f a v a i l a b l e
Use a 64− b i t d a t a model i f a v a i l a b l e
S e t number o f p r o c e s s o r s
S e t m u l t i p r o c e s s o r mode
BLAS l i b r a r y t o u s e
S e t p a t h t o BLAS l i b r a r y
A c t i v a t e IPv6 s u p p o r t
Path to temporary d i r e c t o r y
Number o f n o d es
Number o f n o d es on e a c h h o s t
S e t p a t h t o MPI l i b r a r y
S e t p a t h t o RSH o r SSH command
MPI l i b r a r y t o u s e . p a t h r e q u i r e s
e n v i r o n m e n t v a r i a b l e COMSOL_MPI_PATH
t o be s e t
S e t p a t h t o MPI l i b r a r y
ScaLaPACK l i b r a r y t o u s e . p a t h r e q u i r e s
e n v i r o n m e n t v a r i a b l e COMSOL_SCALAPACK_PATH
t o be s e t
S e t p a t h t o ScaLaPACK l i b r a r y
37
38
options :
81
COMSOL Multiphysics Startparameter
39
40
−open < f i l e n a m e >
The i n p u t
f i l e name
41
42
Example :
43
44
co m s o l −open < f i l e n a m e >
Listing A.1: COMSOL Multiphysics allgemeine Startparameter - Hilfemenü
Die Listing A.2 und A.3 besitzen Unterschiede in den Parameternamen. Es muss beachtet werden, dass das Angeben von Eingabe- und Ausgabedaten unterschiedlich ist. Bei der COMSOL Multiphysics Version 4.0a kann außerdem ein weiterer Parameter angegeben werden, der nicht im Listing
A.3 angezeigt wird. Dieser Parameter heißt -paramfile und mit diesem kann eine Parameterdatei
angegeben wird. Dies ist ähnlich wie bei der COMSOL Multiphysics Version 3.5a und wird wohl
eine veraltetet Option sein. In zukünftige Arbeiten am ComsolGrid Framework sollte dieser Parameter durch -plist ersetzt werden.
1
B atch o p t i o n s :
2
3
4
5
6
7
8
9
−i n p u t
−o u t p u t
−p a r a m f i l e
−l o g f i l e
−pname
−g l o b a l s
−p s a v e
<filename >
<filename >
<filename >
<filename >
<, separated l i s t >
<, separated l i s t >
<on / { o f f }>
10
11
12
−h e l p
I n p u t f i l e name
O u t p u t f i l e name
P a r a m e t e r f i l e name
Log f i l e name
P a r a m e t e r names
Global e x p r e s s i o n s
I f o u t p u t m o d els s h o u l d be s a v e d
( i f o u t p u t f i l e name i s n o t g iv en ,
the input f i l e contains the r e s u l t )
Show t h i s h e l p m es s ag e
13
14
15
Example ( s o l v e t h e model i n t h e f i l e i n p u t . mph and
s t o r e r e s u l t i n o u t p u t . mph ) :
16
17
co m s o l b a t c h −i n p u t i n p u t . mph −o u t p u t o u t p u t . mph
Listing A.2: COMSOL Multiphysics Major Release 3.5a Startparameter - Batch Hilfemenü
1
B atch o p t i o n s :
2
3
4
5
6
7
8
9
10
11
12
−i n p u t f i l e <filename >
−o u t p u t f i l e <filename >
f i l e name i s u s e d )
−s t u d y < s t u d y name>
−j o b < j o b name>
−pname 
−p l i s t <parameter values >
−b a t c h l o g < l o g f i l e n a m e >
−c l i e n t
−h o s t < hostname >
−p o r t 
The i n p u t f i l e name ( . mph o r . c l a s s )
The o u t p u t f i l e name ( i f n o t s p e c i f i e d t h e i n p u t
The s t u d y t o compute
The b a t c h j o b t o r u n
Comma s e p a r a t e d l i s t o f p a r a m e t e r names
Comma s e p a r a t e d l i s t o f p a r a m e t e r v a l u e s
Fi l e to s t o r e log in
Run a s c l i e n t
C o n n ect t o h o s t < hostname >
C o n n ect t o p o r t 
13
14
Example :
15
16
co m s o l b a t c h − i n p u t f i l e − o u t p u t f i l e −j o b b3 −pname v − p l i s t 10
Listing A.3: COMSOL Multiphysics Major Release 4.0a Startparameter - Batch Hilfemenü
82
Anhang B
ComsolGrid Testprojekt Installationsskript
Das Listing B.1 enthält ein SQL Skript, welches einen Standardbenutzer in der Datenbank einträgt.
Dieses Skript wird vom Programm im Listing B.2 verwendet. Der Eintrag erstellt den Benutzer
[email protected] mit dem Passwort boincadm. Diese Daten werden für das Anmelden
beim Testprojekt verwendet und z.B. im BOINC Manager beim Hinzufügen des Projektes eingetragen.
1
2
3
4
5
6
7
CREATE TABLE I F NOT EXISTS ‘ co m s o lw r ap p er ‘ . ‘ c o m s o l g r i d _ r o l e s ‘ (
‘ id ‘ INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
‘ u s e r i d ‘ INT NOT NULL ,
‘ ap p id ‘ INT NOT NULL ,
‘ r o l e ‘ INT ( 5 ) NOT NULL ,
‘ d e s c r i p t i o n ‘ VARCHAR( 254 ) NOT NULL
) ENGINE = MYISAM ;
8
9
10
11
12
INSERT INTO ‘ co m s o lw r ap p er ‘ . ‘ c o m s o l g r i d _ r o l e s ‘ ( u s e r i d , ap p id , r o l e , d e s c r i p t i o n
) VALUES (
1, 1, 1,
’ U s er f o r e v e r y t h i n g :D ’
);
13
14
15
16
17
18
19
20
21
22
23
24
25
LOCK TABLES ‘ u s e r ‘ WRITE ;
INSERT INTO ‘ u s e r ‘ VALUES (
1 , 1277132362 ,
’ boincadm@fh− b i e l e f e l d . de ’ ,
’ boincadm@fh− b i e l e f e l d . de ’ ,
’ d133dda6e2737113d4f04b3f8e48c18e ’ ,
’ None ’ , ’ ’ , 0 , 0 , 1 2 7 7 1 3 2 3 6 2 , NULL, ’ ’ , 0 , ’ ’ ,
NULL, 1 , 1 , 0 , 0 , 0 , 0 , 0 , NULL, 0 ,
’ a1 b 9 9 8 9 e0 5 6 3 1 8 5 4 aa0 9 2 2 6 0 3 0 a5 3 1 9 3 ’ ,
’4 c60f9cc1f51ee5a9d82853a430a1b88 ’ ,
0 , 0) ;
UNLOCK TABLES ;
Listing B.1: ComsolGrid Standarddatenbankeintrag für ein Testprojekt
1
# ! / bin / bash
2
3
4
5
6
7
8
BOINCUSER= boincadm
BOINCPW= boincadm
BOINCNODE= h t t p : / / c o m s o l g r i d . fh −b i e l e f e l d . de
BOINCDBUSER=YOURUSERNAME
BOINCDBPW=YOURPASSWORD
BOINCDBHOST= l o c a l h o s t
9
83
10
11
12
13
14
i f [ $ # −l e 0 ]
t h en
echo " Usage : m a k e _ p r o j e c t ’Name o f p r o j e c t ’ "
exit 0
fi
15
16
PROJECTNAME=$1
17
18
19
20
21
22
23
24
ROOTPRE= / home / boincadm
MAKEPROJECT=$ {ROOTPRE } / s e r v e r _ s t a b l e / t o o l s / m a k e _ p r o j e c t
ROOTPROJECT=$ {ROOTPRE } / p r o j e c t s / $ {PROJECTNAME}
SRCPROJECT=$ {ROOTPRE } / s e r v e r _ s t a b l e
SRCAPPLICATION=$ {ROOTPRE } / s o u r c e s / c o m s o l _ w r a p p e r / a p p s / c o m s o l s t a r t e r
SRCTEMPLATES=$ {ROOTPRE} / s o u r c e s / c o m s o l _ w r a p p e r / t e m p l a t e s
SRCCONFIGS=$ {ROOTPRE } / s o u r c e s / c o m s o l _ w r a p p e r / c o n f i g u r a t i o n s
25
26
27
28
29
30
31
32
33
34
35
36
$ {MAKEPROJECT} −−u s er _ n am e " $ {BOINCUSER} " \
−− s r c d i r " $ {SRCPROJECT} " \
−−d e l e t e _ p r e v _ i n s t \
−−d r o p _ d b _ f i r s t \
−−p r o j e c t _ r o o t " $ {ROOTPROJECT} " \
−−u r l _ b a s e " $ {BOINCNODE} " \
−−db_name "$PROJECTNAME" \
−−d b _ u s e r "$BOINCDBUSER " \
−−db_passwd "$BOINCDBPW" \
−−d b _ h o s t "$BOINCDBHOST" \
$ {PROJECTNAME}
37
38
cd $ROOTPROJECT
39
40
41
42
43
44
45
46
# permissions
chmod 02770 u p l o a d
chmod 02770 h t m l / c a c h e
chmod 02770 h t m l / i n c
chmod 02770 h t m l / l a n g u a g e s
chmod 02770 h t m l / l a n g u a g e s / c o m p i l e d
chmod 02770 h t m l / u s e r _ p r o f i l e
47
48
49
# httpasswd
h t p a s s w d −bc h t m l / o p s / . h t p a s s w d $BOINCUSER $BOINCPW
50
51
52
53
# a k t i v a t e auth_ops ( )
s ed − i " . bak " ’68 d ’ h t m l / p r o j e c t / p r o j e c t . i n c
s ed − i " . bak " ’70 d ’ h t m l / p r o j e c t / p r o j e c t . i n c
54
55
56
# remove l i n e s t o a c t i v a t e w o r k u n i t c a n c e l a t i o n s
s ed − i " . bak " ’ 5 8 , 6 6 d ’ h t m l / o p s / c a n c e l _ w u _ a c t i o n . php
57
58
59
60
# remove u n n e c e s s a r y p l a t f o r m s
# s e d − i " . bak " ’ 2 , 9 d ’ p r o j e c t . xml
# s e d − i " . bak " ’ 1 0 , 3 7 d ’ p r o j e c t . xml
61
62
63
64
65
66
# replace uppercase
# s e d − i " . bak " ’ s / u p p e r c a s e / c o m s o l s t a r t e r / ’ p r o j e c t . xml
# s e d − i " . bak " ’ s / upperCASE / ComsolGrid v0 . 1 ( p r o t o t y p e ) / ’ p r o j e c t . xml
cp / home / boincadm / s o u r c e s / c o m s o l _ w r a p p e r / c o n f i g u r a t i o n s / p r o j e c t . xml / home / boincadm
/ p r o j e c t s / c o m s o l w r a p p e r / p r o j e c t . xml
. / b i n / xadd
67
68
69
70
84
# b e a u t i f i e r f o r t h e c o n f i g . xml o f a BOINC p r o j e c t
mv c o n f i g . xml c o n f i g . xml . o r i g
/ home / boincadm / s o u r c e s / u t i l s / b e a u t i f i e r / x m l i n l i n e c o n f i g . xml . o r i g c o n f i g . xml
71
B.1 ComsolGrid Templates
chmod 644 c o n f i g . xml
72
73
74
75
76
# r e p l a c e daemon c o n f i g u r a t i o n s
s ed −i " . bak " ’ 7 5 , 8 6 d ’ c o n f i g . xml
c a t $ {SRCCONFIGS } / daemons >> c o n f i g . xml
echo " " >> c o n f i g . xml
77
78
79
80
81
82
83
84
85
# i n s t a l l Validator & Assimilator
cp / home / boincadm / s o u r c e s / c o m s o l _ v a l i d a t o r / c o m s o l _ b i t w i s e _ v a l i d a t o r b i n /
comsol_bitwise_validator
cp / home / boincadm / s o u r c e s / c o m s o l _ v a l i d a t o r / c o m s o l _ t r i v i a l _ v a l i d a t o r b i n /
comsol_trivial_validator
m k d ir c o m s o l g r i d _ r e s u l t s /
chmod 775 c o m s o l g r i d _ r e s u l t s /
m k d ir c o m s o l g r i d _ r e s u l t s / e r r o r s /
chmod 775 c o m s o l g r i d _ r e s u l t s / e r r o r s /
cp / home / boincadm / s o u r c e s / c o m s o l _ a s s i m i l a t o r / c o m s o l _ c o p y d i r _ a s s i m i l a t e b i n /
comsol_copydir_assimilate
86
87
88
89
# Permissions to r e t r i e v e infor mation about the pr oces s es .
m k d ir l o g _ v i s u a l g r i d −1
chmod 775 l o g _ v i s u a l g r i d −1
90
91
92
t o u c h r u n _ s t a t e _ v i s u a l g r i d −1. xml
chmod 664 r u n _ s t a t e _ v i s u a l g r i d −1. xml
93
94
95
96
97
# i n s t a ll test application
m k d ir −p a p p s / c o m s o l s t a r t e r
cp −r $ {SRCAPPLICATION} / ∗ a p p s / c o m s o l s t a r t e r /
. / b i n / u p d a t e _ v e r s i o n s −v −s −f
98
99
100
101
# create symbolic l i n k s to the template f i l e s
l n −s f $ {SRCTEMPLATES} / w r a p p e r _ w u _ i n p u t . xml t e m p l a t e s / w r a p p e r _ w u _ i n p u t . xml
l n −s f $ {SRCTEMPLATES} / w r a p p e r _ w u _ r e s u l t . xml t e m p l a t e s / w r a p p e r _ w u _ r e s u l t . xml
102
103
#
104
105
cd −
106
107
108
# i n s e r t d e f a u l t m ys q l u s e r
mysql −u $BOINCDBUSER −p $PROJECTNAME < m a k e _ p r o j e c t _ m y s q l . d a t a
Listing B.2: ComsolGrid Installationsskript für ein Testprojekt
B.1
ComsolGrid Templates
Bei der Erstellung werden Templatedateien für die Erstellung von Arbeitspaketen benötigt. In der
Testumgebung wurde die Templateeingabedatei mit den Zeilen aus Listing B.3 und die Templateausgabedatei mit den Zeilen aus B.4 gefüllt.
1
2
3
4
5
6
7
8
9
10
<file_info>
<number >0< / number >
</ file_info>
<file_info>
<number >1< / number >
</ file_info>
<workunit>
<file_ref>
< f i l e _ n u m b e r >0< / f i l e _ n u m b e r >
<open_name > co m s o l . mph< / open_name >
85
B.2 ComsolGrid Projektserver Konfiguration
11
12
13
14
15
16
17
18
19
20
<copy_file />
</ file_ref>
<file_ref>
< f i l e _ n u m b e r >1< / f i l e _ n u m b e r >
<open_name > co m s o l . t x t < / open_name >
<copy_file />
</ file_ref>
< r s c _ f p o p s _ b o u n d > 1000000000000 < / r s c _ f p o p s _ b o u n d >
< r s c _ f p o p s _ e s t >1000000000000 < / r s c _ f p o p s _ e s t >
</ workunit>
Listing B.3: ComsolGrid Template Input
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<file_info>
<name><OUTFILE_0 / >< / name>
<generated_locally />
<upload_when_present / >
< m ax _ n b y tes >500000000 < / m ax _ n b y tes >
<UPLOAD_URL/ >
</ file_info >
<result>
<file_ref>
< f i l e _ n a m e ><OUTFILE_0 / >< / f i l e _ n a m e >
<open_name > c o m s o l _ o u t p u t . mph< / open_name >
<copy_file />
</ file_ref>
</ resu lt >
Listing B.4: ComsolGrid Template Result
B.2
ComsolGrid Projektserver Konfiguration
Das Listing B.5 enthält die Projektserver Konfiguration der Testumgebung aus Kapitel 5. Erwähnenswert sind die folgenden Parameter:
<max_wus_in_progress>N</max_wus_in_progress> Es werden nur N Arbeitspakete an den
Anwender gesendet, keine Weitere.
<max_ncpus>N</max_ncpus> Es werden nur N Prozessoren für die Berechnung genommen,
dies kann durch die Einstellungen des BOINC Manager überschrieben werden.
Für die anderen Parameter wird auf das BOINC Wiki verwiesen [33].
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
86
<? xml v e r s i o n = " 1 . 0 " ?>
<boinc>
<config >
 / home / boincadm / p r o j e c t s / c o m s o l w r a p p e r / u p l o a d 
<send_result_abort> 1 </ send_result_abort>
<long_name > c o m s o l w r a p p e r < / long_name >
< d o w n l o a d _ u r l > h t t p : / / 1 9 2 . 1 6 8 . 1 . 1 / c o m s o l w r a p p e r / download < / d o w n l o a d _ u r l >
<sched_debug_level > 3 < / sched_debug_level >
<disable_account_creation> 0 </ disable_account_creation>
 1024 
< c g i_ ur l > h t t p : / / 1 9 2 . 1 6 8 . 1 . 1 / comsolwrapper_cgi / < / c gi _ ur l >
<db_user> root < / db_user>
< l o g _ d i r > / home / boincadm / p r o j e c t s / c o m s o l w r a p p e r / l o g _ v i s u a l g r i d −1 < / l o g _ d i r >
< a p p _ d i r > / home / boincadm / p r o j e c t s / c o m s o l w r a p p e r / a p p s < / a p p _ d i r >
< d o w n l o a d _ d i r > / home / boincadm / p r o j e c t s / c o m s o l w r a p p e r / download < / d o w n l o a d _ d i r
>
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
<fuh_debug_level > 3 < / fuh_debug_level >
< m as ter _ u r l > h t t p : / / 1 9 2 . 1 6 8 . 1 . 1 / comsolwrapper / < / m as ter _ u r l >
< h o s t > v i s u a l g r i d −1 < / h o s t >
<db_name > c o m s o l w r a p p e r < / db_name >
<shmem_key> 0 x111144e9 < / shmem_key>
<show_results > 1 </ show_results >
< k e y _ d i r > / home / boincadm / p r o j e c t s / c o m s o l w r a p p e r / k e y s / < / k e y _ d i r >
<upload_url > h t t p : / / 1 9 2 . 1 6 8 . 1 . 1 / comsolwrapper_cgi / fi le _u pl oa d_h and le r < /
upload_url >
< db_passwd > xxx < / db_passwd >
<min_sendwork_interval > 6 < / min_sendwork_interval >
<db_host> l o c a l h o s t < / db_host>
< d a i l y _ r e s u l t _ q u o t a > 500 < / d a i l y _ r e s u l t _ q u o t a >
<one_result_per_user_per_wu > 0 </ one_result_per_user_per_wu >
< max_wus_to_s end > 2 < / max_wus_to_s end >
<max_wus_in_progress > 1 < / max_wus_in_progress >
<max_wus_in_progress_gpu> 0 < / max_wus_in_progress_gpu>
<max_ncpus> 1 < / max_ncpus>
</ config >
<tasks>
<task >
<cmd> db_dump −d 2 −dump_spec . . / db_dump_spec . xml < / cmd>
 5 min 
<disabled> 1 </ disabled>
< o u t p u t > db_dump . o u t < / o u t p u t >
</ task >
<task >
<cmd> r u n _ i n _ o p s . / u p d a t e _ u o t d . php < / cmd>
<output > update_uotd . out < / output >
</ task >
<task >
<cmd> r u n _ i n _ o p s . / u p d a t e _ f o r u m _ a c t i v i t i e s . php < / cmd>
<output > u pd at e _f or um_ ac t i vi t ie s . out < / output >
</ task >
<task >
<cmd> u p d a t e _ s t a t s −u p d a t e _ u s e r s −u p d a t e _ t e a m s −u p d a t e _ h o s t s < / cmd>
<output > u p d a t e _s t a t s . out < / output >
</ task >
<task >
<cmd> r u n _ i n _ o p s . / u p d a t e _ p r o f i l e _ p a g e s . php < / cmd>
<output > update_profile_pages . out < / output >
</ task >
<task >
<cmd> r u n _ i n _ o p s . / t e a m _ i m p o r t . php < / cmd>
 1 days 
< o u tp u t > team_import . out < / o u tp u t >
</ task >
<task >
<cmd> r u n _ i n _ o p s . / n o t i f y . php < / cmd>
 1 days 
<output > n o t i fy . out < / output >
</ task >
87
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
</ tasks>
<daemons >
<daemon >
<cmd> f e e d e r −d 2 < / cmd>
<output > feeder . log < / output >
 feeder . pid 
< / daemon >
<daemon >
<cmd> t r a n s i t i o n e r −d 2 < / cmd>
<output > t r a n s i t i o n e r . log < / output >
 t r a n s i t i o n e r . pid 
< / daemon >
<daemon >
<cmd> f i l e _ d e l e t e r −d 2 < / cmd>
<output > f i l e _ d e l e t e r . log < / output >
 f i l e _ d e l e t e r . pid 
< / daemon >
<daemon >
<cmd> c o m s o l _ b i t w i s e _ v a l i d a t o r −mod 2 1 −d 2 −app c o m s o l s t a r t e r < / cmd>
<output > com s ol_bitwis e_validator . log < / output >
 com s ol_bitwis e_validator . pid 
< / daemon >
<daemon >
<cmd> c o m s o l _ c o p y d i r _ a s s i m i l a t e −d 2 −app c o m s o l s t a r t e r < / cmd>
<output > comsol_copydir_ass imilate . log < / output >
 comsol_copydir_assimilate . pid 
< / daemon >
<daemon >
<cmd> d b _ p u r g e −d 2 −m in _ ag e_ d ay s 7 −g z i p < / cmd>
< output > db_purge . log < / output >
 db_purge . pid 
< / daemon >
< / daemons >
</ boinc>
Listing B.5: ComsolGrid Projektserver Konfiguration
Das Listing B.6 enthält die Definitionen der Plattformen die in der Testinstallation zur Verfügung
stehen. Es wird die COMSOL Multiphysics Major Release Version 4.0a mit 32 − Bit und 64 − Bit
Version unterstützt.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<boinc>
<platform >
<name> i6 8 6 −pc−l i n u x −g n u _ co m s o l4 0 a < / name>
 L in u x r u n n i n g on an I n t e l x86−c o m p a t i b l e CPU w i t h
COMSOL v40a 
</ platform >
<platform >
<name>x86_64−pc−l i n u x −g n u _ co m s o l4 0 a < / name>
 L in u x r u n n i n g on an AMD x86_64 o r I n t e l EM64T CPU w i t h
COMSOL v40a 
</ platform >
<platform >
<name>anonymous < / name>
anonymous 
</ platform >
<app >
<name> c o m s o l s t a r t e r < / name>
 ComsolGrid v0 . 1 ( p r o t o t y p e ) 
< / app >
</ boinc>
Listing B.6: Liste der Plattformen die der Projektserver zur Verfügung stellt
88
B.3
1
2
3
4
5
6
B.3 Apache Webserver
Apache Webserver
####
# S e t t i n g s f o r BOINC p r o j e c t c o m s o l w r a p p e r
####
A l i a s / c o m s o l w r a p p e r / home / boincadm / p r o j e c t s / c o m s o l w r a p p e r / h t m l / u s e r
A l i a s / c o m s o l w r a p p e r _ o p s / home / boincadm / p r o j e c t s / c o m s o l w r a p p e r / h t m l / o p s
S c r i p t A l i a s / c o m s o l w r a p p e r _ c g i / home / boincadm / p r o j e c t s / c o m s o l w r a p p e r / c g i −b i n
7
8
9
10
11
12
13
< D i r e c t o r y " / home / boincadm / p r o j e c t s / c o m s o l w r a p p e r / h t m l " >
O p t io n s I n d e x e s F o l l o w S y m l i n k s M u ltiV iew s
A llo w O v errid e A u th C o n f ig
Order allo w , deny
Allow from a l l
</ D i r e c t o r y >
14
15
16
17
18
19
20
< D i r e c t o r y " / home / boincadm / p r o j e c t s / c o m s o l w r a p p e r / c g i −b i n " >
O p t io n s ExecCGI
A llo w O v errid e A u th C o n f ig
Order allo w , deny
Allow from a l l
Listing B.7: Apache Webserver Konfiguration für die BOINC Projektnutzung
1
2
3
4
####
# C o m s o lG r id F cg i I n t e r f a c e
####
S c r i p t A l i a s / c o m s o l f c g i / home / boincadm / s o u r c e s / c o m s o l _ f c g i / co m s o l . f c g i
5
6
7
8
9
10
11
< D i r e c t o r y " / home / boincadm / s o u r c e s / c o m s o l _ f c g i / co m s o l . f c g i " >
O p t io n s +ExecCGI
A l l o w O v e r r i d e A u th C o n f ig
O r d er allo w , deny
Allow from a l l
12
13
F a s t C g i S e r v e r / home / boincadm / s o u r c e s / c o m s o l _ f c g i / co m s o l . f c g i − p r o c e s s e s 1
Listing B.8: Apache Webserver Konfiguration für die FastCGI Nutzung
B.4
1
2
3
4
5
6
7
Testskript für die ComsolGridFCGI Schnittstelle
# ! / u s r / b i n / php
<? php
/∗
∗ C h r i s t i a n B en ja m in R i e s , J u l y 2010
∗ C h r i s t i a n _ B e n j a m i n . Ries@fh− b i e l e f e l d . de
∗ U n i v e r s i t y o f A p p l i e d S c i e n c e s B i e l e f e l d , Germany
∗/
8
9
10
11
12
13
14
15
16
/∗ ∗
∗ Configuration
∗/
$ a d d r p o r t = 4 4 3 ; / / 8 0 , 443
$ a d d r h o s t = " 1 2 7 . 0 . 0 . 1 " ; / ∗ !< s s l : / / o r t l s : / / ∗ /
$ a d d r s r c = a rra y (
" f a l l i n g _ s a n d . mph " ,
);
17
18
$ co m s o l_ u s er n a m e = " boincadm@fh−b i e l e f e l d . de " ;
89
B.4 Testskript für die ComsolGridFCGI Schnittstelle
19
20
$ c o m s o l _ e m a i l = " boincadm@fh−b i e l e f e l d . de " ;
$ c o m s o l _ p a s s w o r d = " boincadm " ;
21
22
23
24
25
26
27
28
29
30
$modes = a rra y (
" upload "
=> " u p l o a d s
" smajor "
=> " r e t u r n s
" sminor "
=> " r e t u r n s
" s r e l e a s e " => " r e t u r n s
" c r e l e a s e " => " r e t u r n s
" status "
=> " r e t u r n s
" apps "
=> " r e t u r n s
);
a f i l e ( $addrsrc ) " ,
t h e s e r v e r m ajo r v e r s i o n " ,
t h e s e r v e r m in o r v e r s i o n " ,
the server re lea se version " ,
t h e s u p p o r t e d co m s o l r e l e a s e v e r s i o n " ,
the server s t a t us " ,
a l i s t o f a p p l i c a t i o n s which a r e i n s t a l l e d on t h e s e r v e r "
31
32
33
34
35
36
37
38
39
40
/ / / Print help
i f ( co u n t ( $ a r g v ) <= 1 ) {
echo " Usage : h t m l p u t . php Mode \ n \ n " ;
echo " Mode : \ n " ;
f o r e a c h ( $modes a s $key => $ d e s c ) {
printf ( "
%−15s %s \ n " , $key , $ d e s c ) ;
}
exit (0) ;
}
41
42
43
44
45
46
47
48
49
/ / / Check s e l e c t e d mode
$mode = $ a r g v [ 1 ] ;
$modeok = f a l s e ;
f o r e a c h ( $modes a s $key => $ d e s c ) {
i f ( $key == $mode ) {
$modeok = t r u e ;
}
}
50
51
52
53
54
55
56
57
58
i f ( ! $modeok ) {
p r i n t f ( " Only one o f t h e f o l l o w i n g modes a r e v a l i d ( " ) ;
f o r e a c h ( $modes a s $key => $ v a l u e ) {
p r i n t f ( "%s " , $key ) ;
}
printf ( " ) \ n" ) ;
e x i t ( −1) ;
}
59
60
61
62
63
64
65
66
67
68
69
70
/∗ ∗
∗ @param $mode
∗ @return
∗/
f u n c t i o n createXML ( $mode , $ a d d r h o s t ) {
$ h t m l H e a d e r = "POST / c o m s o l f c g i HTTP / 1 . 1 \ r \ n " ;
$htmlHeader . = " Host : $ a d d r h o s t \ r \ n " ;
$ h t m l H e a d e r . = " User−Agent : COMSOL T e s t s u i t e \ r \ n " ;
$ h t m l H e a d e r . = " C o n t e n t −L en g th : %d \ r \ n " ;
$ h t m l H e a d e r . = " C o n t e n t −Type : a p p l i c a t i o n / x−www−form−u r l e n c o d e d \ r \ n " ;
$ h t m l H e a d e r . = " \ r \ n%s \ r \ n \ r \ n " ;
71
72
73
74
g l o b a l $ co m s o l_ u s er n a m e ;
g lo b al $comsol_email ;
g lo b al $comsol_password ;
75
76
77
78
79
80
90
$authXML =
"<auth >\ r \ n "
.
" < username > " . $ co m s o l_ u s er n a m e . " </ username > \ r \ n "
.
" " . $ c o m s o l _ e m a i l . " \ r \ n "
.
" " . $ c o m s o l _ p a s s w o r d . " \ r \ n "
. " </ a u t h > \ r \ n "
81
82
B.4 Testskript für die ComsolGridFCGI Schnittstelle
;
83
84
85
86
87
88
89
90
91
92
s w i t c h ( $mode ) {
case " upload " : {
global $addrsrc ;
$xmlfiles = "" ;
$xmlfilecount = 0;
foreach ( $ ad d r s r c as $imgsrc ) {
$ f h = f o p en ( $ im g s r c , ’ r ’ ) ;
$ d a t a = f r e a d ( $fh , f i l e s i z e ( $ i m g s r c ) ) ;
f c l o s e ( $fh ) ;
93
$xmlfiles
$xmlfiles
$xmlfiles
$xmlfiles
$xmlfiles
$xmlfiles
94
95
96
97
98
99
.= "< f i l e >\ r \ n" ;
.=
" < f i l e n a m e >%s < / f i l e n a m e > \ r \ n " ;
.=
" < d e s c r i p t i o n >%s < / d e s c r i p t i o n > \ r \ n " ;
.=
" < max_nbytes >%d < / max_nbytes > \ r \ n " ;
.=
" < d a t a > \ r \ n%s \ r \ n < / d a t a > \ r \ n " ;
. = " </ f i l e > \ r \ n " ;
100
$xmlfiles = sprintf ( $xmlfiles ,
$ im g s r c ,
" Description $xmlfilecount " ,
f i l e s i z e ( $imgsrc ) ,
b a s e6 4 _ en co d e ( $ d a t a )
);
$ x m l f i l e c o u n t ++;
101
102
103
104
105
106
107
108
}
109
110
111
112
$ f h = f o p en ( " w r a p p e r _ w u _ i n p u t . xml " , ’ r ’ ) ;
$ d a t a T e m p l a t e I n p u t = f r e a d ( $fh , f i l e s i z e ( " w r a p p e r _ w u _ i n p u t . xml " ) ) ;
f c l o s e ( $fh ) ;
113
114
115
116
$ f h = f o p en ( " w r a p p e r _ w u _ r e s u l t . xml " , ’ r ’ ) ;
$ d a t a T e m p l a t e R e s u l t = f r e a d ( $fh , f i l e s i z e ( " w r a p p e r _ w u _ r e s u l t . xml " ) ) ;
f c l o s e ( $fh ) ;
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
$ co m s o lx m lf m t =
" < co m s o l_ p u t > \ r \ n "
$authXML
.
" <name>%s < / name > \ r \ n "
.
" < ap p id >1 </ ap p id > \ r \ n "
.
" < co u n t > " . co u n t ( $ a d d r s r c ) . " </ co u n t > \ r \ n "
.
"%s "
.
"<ranges >\ r \ n "
.
" < r an g e > \ r \ n "
.
"<parameter >objWidth : 0 . 0 0 1 : 0 . 0 1 5 : 0 . 0 0 0 5 : 0 . 0 0 6 < / parameter >\ r \ n "
.
"<parameter >objHeight : 0 . 0 0 1 : 0 . 0 2 5 : 0 . 0 0 1 : 0 . 0 1 4 < / parameter >\ r \ n "
.
" </ r an g e > \ r \ n "
.
" </ r a n g e s > \ r \ n "
.
" < t e m p l a t e _ i n p u t > " . b a s e6 4 _ en co d e ( $ d a t a T e m p l a t e I n p u t ) . " </
tem plate_input >\ r \ n"
.
" < t e m p l a t e _ r e s u l t > " . b a s e6 4 _ en co d e ( $ d a t a T e m p l a t e R e s u l t ) . " </
t e m p l a t e _ r e s u l t >\ r \ n"
.
" <comsol > \ r \ n "
.
"<ckl / >\ r \ n"
.
" < l o g f i l e > co m s o l . lo g < / l o g f i l e > \ r \ n "
.
" < s t d o u t > c o m s o l _ s t d o u t . lo g < / s t d o u t > \ r \ n "
.
" < s t d e r r > c o m s o l _ s t d e r r . lo g < / s t d e r r > \ r \ n "
.
" </ comsol > \ r \ n "
. " </ co m s o l_ p u t > " ;
140
91
B.5 Struktur des Projektbaumes/des mitgelieferten Datenträgers ComsolGrid Testprojekt Installationsskript
$comsolxml = s p r i n t f ( $comsolxmlfmt ,
" c o m s o l s t a r t e r : : ComsolGrid v0 . 1 ( p r o t o t y p e ) " , $ x m l f i l e s ) ;
r e t u r n s p r i n t f ( $ h tm lH ead er , s t r l e n ( $comsolxml ) , $comsolxml ) ;
141
142
143
}
case " smajor " :
r e t u r n s p r i n t f ( $ h tm lH ead er , 1 7 , " < s e r v e r _ m a j o r / > \ r \ n " ) ;
case " sminor " :
r e t u r n s p r i n t f ( $ h tm lH ead er , 1 7 , " < s e r v e r _ m i n o r / > \ r \ n " ) ;
case " s r e l e a s e " :
r e t u r n s p r i n t f ( $ h tm lH ead er , 1 9 , " < s e r v e r _ r e l e a s e / > \ r \ n " ) ;
case " c r e l e a s e " :
r e t u r n s p r i n t f ( $ h tm lH ead er , 1 9 , " < c o m s o l _ r e l e a s e / > \ r \ n " ) ;
case " s t a t u s " : {
$statusxml =
"< s t a t u s >\ r \ n"
. $authXML
. " </ s t a t u s > \ r \ n "
;
r e t u r n s p r i n t f ( $ h tm lH ead er , s t r l e n ( $ s t a t u s x m l ) , $ s t a t u s x m l ) ;
}
case " apps " : {
$ ap p s x m l =
" <apps > \ r \ n "
.
$authXML
. " </ a p p s \ r \ n "
;
r e t u r n s p r i n t f ( $ h tm lH ead er , s t r l e n ( $ ap p s x m l ) , $ ap p s x m l ) ;
}
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
}
165
166
}
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
/ / / Run . . .
$a = ( $ a d d r p o r t == " 443 " ? " s s l : / / " : " " ) . $ a d d r h o s t ;
echo " H o s t : " . $a . " \ n " ;
$ f p = f s o ck o p en ( $a , $ a d d r p o r t , $ e r r n o , $ e r r s t r , 3 0 ) ;
i f ( ! $fp ) {
echo " $ e r r s t r ( $ e r r n o ) \ n " ;
} else {
$ s t r = createXML ( $mode , $ a d d r h o s t ) ;
if (1) {
f w r i t e ( $fp , $ s t r , s t r l e n ( $ s t r ) ) ;
while ( ! f eof ( $fp ) ) {
echo f g e t s ( $ f p ) ;
}
} else {
echo ( $ s t r . " \ n " ) ;
}
f c l o s e ( $fp ) ;
}
?>
Listing B.9: Testskript für die ComsolGridFCGI Schnittstelle
B.5
Struktur des Projektbaumes/des mitgelieferten Datenträgers
Der Datenträger beinhaltet vier Ordner und zwei weitere Dateien:
1
2
3
4
5
6
7
8
9
92
+ Datentraeger
|−− P r e s e n t a t i o n
|−− S o f t w a r e
|−− S o u r c e s
|
|−− c o m s o l _ a p i
|
|−− c o m s o l _ a s s i m i l a t o r
|
|−− c o m s o l _ f c g i
|
|−− c o m s o l _ v a l i d a t o r
|
|−− c o m s o l _ w r a p p e r
ComsolGrid Testprojekt Installationsskript B.5 Struktur des Projektbaumes/des mitgelieferten Datenträgers
10
11
12
13
14
15
16
|
|
|
|−−
|
|
‘−−
|−− q t
|−− s e r v e r _ s t a b l e
‘−− u t i l s
Thesis
|−− im ag es
‘−− t e x
UML
Listing B.10: Struktur des mitgelieferten Datenträgers
Im Ordner Presentation/ befinden sich Folien für Vorträge und dem Kolloquium für diese Masterarbeit. Der Dateiordner Software/ beinhaltet alle BOINC Manager Versionen, die am 31. August
2010 zur Verfügung standen. Im Ordner Sources/ sind alle entwickelten Komponenten enthalten.
Die LaTex Dateien und der Bericht befindet sich im Ordner Thesis/. Im UML/ Ordner ist die Datei
mit den UML Modellen für die Visual Paradigm Applikation.
93

ComsolGrid - Konzeption, Entwicklung und Implementierung eines

Transcription

Similar documents

Versuch 1 PWM-Motorsteuerung mit dem PowerPC 555 unter dem

2. Kombinatorik

myRoom Guestroom Solutions Brochure

Zusatz 1 - Technische Universität Braunschweig

Sophos Disk Encryption Tools

Fehlermeldungen EDIABAS

SafeGuard Easy Tools-Anleitung

SafeGuard Enterprise Tools-Anleitung

Thermoguard Systemhandbuch