Bachelorarbeit. Implementierung von Monte-Carlo-Simulationen für ökologische Simulationsmodelle mittels HPC-/Cloud-Diensten. Wintersemester 2010/2011

Transkript

1 Campus Jülich Bachelorarbeit Implementierung von Monte-Carlo-Simulationen für ökologische Simulationsmodelle mittels HPC-/Cloud-Diensten Wintersemester 2010/2011 Erstellt von: Christian Andrich, Matrikel-Nr Studiengang Scientific Programming Fachbereich 9, Medizintechnik und Technomathematik Betreut durch: 1. Prüfer: Prof. Dr. Hans Joachim Pflug 2. Prüfer: Dipl.-Inform. Christian Terboven Abgabetermin:

2

3 Eidesstattliche Erklärung Diese Arbeit ist von mir selbstständig angefertigt und verfasst. Es sind keine anderen als die angegebenen Quellen und Hilfsmittel benutzt worden. Christian Andrich, Aachen, , Bachelorarbeit Christian Andrich 1

4 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung - Monte-Carlo-Simulationen in der Ökologie Aufgabenstellung Grundlagen Vorstellung der Simulationsmodelle GraS IDamP Bereitgestellte Ressourcen Aachen-Cluster Paderborn/Aachen-Cloud Analyse und Vorarbeiten Vereinheitlichung der ökologischen Simulationsmodelle Änderungen an der Paderborn/Aachen-Cloud GraS-as-a-Service Das XMLRPC-Protokoll Implementierung der entfernten Steuerung Exe-as-a-Service Anpassung des GraS-Modells Automatisierter Startvorgang Bündelung der Initialdateien Automatisierte Auswertung der Ergebnisse Anpassung des IDamP-Modells Automatisierter Startvorgang und Bündelung der Initialdateien Modifikation der Monte-Carlo-Implementierung Entwicklung des Programms Sammlung des Funktionsumfangs Das Programm aus Sicht des Benutzers Interaktionsmöglichkeiten Darstellung der Informationen Das Programm aus Sicht des Entwicklers Wahl der Programmiersprache und Entwicklungsumgebung Interne Abläufe des Programms Implementierung der Komponenten helping::helper helping::logging biomcm::hpcjob biomcm::hpctask Bachelorarbeit Christian Andrich

5 Inhaltsverzeichnis biomcm::hpcresource biomcm::hpccloud cloud::cloudremote biomcm::hpccluster biomcm::hpcqueue gui::mainframe gui::addresourceframe gui::fileframe gui::addjobframe gui::viewjobframe biomcm::main Ergebnisse Zusammenfassung und Ausblick Anhang Quellcode der Klasse RemoteStarter Quellcode der Monte-Carlo-Auswertungen vom GraS-Modell Quellcode der Bündelung der Initialdateien GraS-Modell IDamP-Modell Quellcode des entwickelten Programms biomcm::hpccloud biomcm::hpccluster biomcm::hpcjob biomcm::hpcqueue biomcm::hpcresource biomcm::hpctask biomcm::main cloud::cloudremote gui::addjobframe gui::addresourceframe gui::fileframe gui::mainframe gui::viewjobframe helping::helper helping::logging Quellenangaben Bachelorarbeit Christian Andrich 3

6 1 - Einleitung - Monte-Carlo-Simulationen in der Ökologie 1 Einleitung - Monte-Carlo-Simulationen in der Ökologie In der ökologischen Forschung erhalten Computersimulationen immer mehr Aufmerksamkeit, da sie ökologische Versuche schneller und ressourcenschonender durchführen können als aufwändige Modellversuche. Diese Entwicklung führt dazu, dass viele Modelle entwickelt werden, welche solche Versuche als Simulation umsetzen. Um einen hohen Grad an Realismus zu erhalten, werden diese Modelle immer komplexer, was zu erhöhten Laufzeiten der Simulationen führt. Ein Problem, welches die Laufzeit von Simulationen noch um ein Vielfaches verlängert, ist die Tatsache, dass ein einzelner Simulationsdurchlauf nicht immer ein aussagekräftiges Ergebnis liefert. In den meisten ökologischen Simulationsmodellen werden nämlich stochastische Zufallswerte genutzt, um nicht implementierte natürliche Vorgänge wie zum Beispiel die von Tag zu Tag leicht unterschiedliche Außentemperatur zu simulieren. Um trotzdem ein nutzbares Ergebnis zu erhalten, müssen hunderte bis tausende Simulationsdurchläufe berechnet und mit stochastischen Methoden verglichen werden. Das vielfache Ausführen ein und derselben Simulation mit anschließendem Vergleich bezeichnet man als Monte- Carlo-Simulation [1]. Um den durch diese Vielzahl an Simulationen entstehenden Zeitaufwand zu bewältigen, ist es sinnvoll, nicht alle Simulationen nacheinander auf einem Rechensystem auszuführen, sondern die einzelnen, voneinander vollkommen unabhängigen Simulationen parallel auf mehreren Rechensystemen durchzuführen. Besonders sinnvoll ist es, die Simulationen nicht auf Arbeitsplatzrechnern durchzuführen, sondern dafür Ressourcen aus Hochleistungsrechensystemen zu nutzen. Diese so genannten HPC-Systeme oder HPC-Dienste bieten durch die spezielle Ausrichtung auf das Durchführen komplexer Rechnungen eine höhere Leistung bei besserer Energieeffizienz. Durch die Idee des verteilten Rechnens in HPC-Diensten entsteht allerdings unweigerlich die Frage, wie eine solche Menge an Simulationen auf den Rechensystemen verteilt und verwaltet werden kann. Für die Nutzer der Simulationsmodelle wäre es wünschenswert, wenn sie sich keine Gedanken über diesen Prozess machen müssten, und keine Einarbeitung in die neuen Rechensysteme benötigen. Was für den Benutzer zählt, ist, dass er nach möglichst kurzer Zeit mit möglichst wenig Eigenaufwand sein Ergebnis erhält. An diesen Ansatz setzt diese Bachelorarbeit an, denn ihr Thema ist die Entwicklung eines Verwaltungsprogramms, das eben diese Aufgaben der Verteilung und Überwachung übernimmt und dem Benutzer möglichst wenig Eigenaufwand abverlangt. Welche genaue Aufgabenstellung sich aus dieser Problemstellung ergibt, wird im nächsten Kapitel beschrieben. 4 Bachelorarbeit Christian Andrich

7 2 - Aufgabenstellung 2 Aufgabenstellung Zu entwickeln ist eine Schnittstelle, welche das Starten von Monte-Carlo-Simulation ermöglicht. Im Rahmen der Bachelorarbeit sollen die Simulationsmodelle Grasland Sukzessionsmodell (GraS- Modell) und Individuen-basiertes Daphnia magna Populationsmodell (IDamP-Modell) von der Schnittstelle unterstützt werden. Die einzelnen Simulationsläufe der Simulationsmodelle sollen dabei zeitlich und räumlich unabhängig voneinander sowohl in der üblichen HPC-Cluster-Umgebung am Rechen- und Kommunikationszentrum der RWTH-Aachen als auch in der Cloud-Computing- Infrastruktur der Paderborn/Aachen-Cloud gerechnet werden können. Die Schnittstelle ist so zu gestalten, dass die Weiterentwicklungsarbeiten der einzelnen Simulationsmodelle unabhängig von der Funktionalität der Schnittstelle bleiben. Die Schnittstelle ist neben dem Starten der Simulationsläufe auch für das Sammeln der Ergebnisse verantwortlich. In der Vorbereitung für die Bachelorarbeit mussten die ökologischen Modelle so erweitert werden, dass sie ohne Benutzerinteraktion Simulationsdurchläufe berechnen und ihre Simulations-Ergebnisse in maschinell-vergleichbarer Darstellung ausgeben können. Es wird erarbeitet, in welchem Umfang Ergebnisse automatisch ausgewertet und dargestellt werden können, diese Auswertung soll in den Simulationsmodellen implementiert werden. Das wesentliche Ziel der Arbeit ist die Vereinfachung der Durchführung von parallelen Berechnungen für den Anwender und eine Verkürzung der Rechenzeit durch die parallele Abarbeitung der Berechnungen. Bachelorarbeit Christian Andrich 5

8 3.1 - Vorstellung der Simulationsmodelle 3 Grundlagen In diesem Kapitel werden die aus der Aufgabenstellung hervorgehenden Simulationsmodelle und Rechen-Ressourcen vorgestellt. 3.1 Vorstellung der Simulationsmodelle In diesem Abschnitt werden nur die Simulationsmodelle beschrieben; die Änderungen, welche an ihnen gemacht wurden, werden in einem eigenen Abschnitt behandelt GraS Das Grasland Sukzessionsmodell (GraS-Modell) [2] wurde von den Wissenschaftlern des Lehrstuhls für Biologie 5 der RWTH Aachen in der Programmiersprache Delphi entwickelt. Es beschäftigt sich hauptsächlich mit der Simulation von Graslandschaften, also von verschiedenen Gräser-Arten. Es werden allerdings auch Büsche und Bäume simuliert. Das bedeutet, dass das Modell eine vorgegebene Vegetationskarte einer realen Landschaft in Zellen aufteilt und das Pflanzenwachstum in den einzelnen Zellen berechnet. In den Zellen befinden sich verschiedene Pflanzenarten, die mit den Pflanzenarten in der gleichen Zelle und den Nachbarzellen konkurrieren. Das Modell verfolgt einen iterativen Ansatz; ein Iterationszyklus ist ein virtueller Tag. Ein typischer Simulationszeitraum sind 100 virtuelle Jahre, also Iterationen. Die hauptsächliche Konkurrenz der Pflanzen entsteht durch die virtuellen Samen, welche sie auf die Nachbarzellen verteilen. Die Samen werden dabei nicht gleichmäßig verteilt, sondern teilweise bestimmt durch Zufallswerte. Durch diese Zufälligkeit entsteht die Notwendigkeit von Monte-Carlo- Simulationen. In der Natur ist die Verteilung der Samen unter anderem durch den Wind bestimmt. Über Winde in Bodenhöhe gibt es aber keine ausreichenden Daten um, auf Zufallswerte verzichten zu können. Entwickelt wurde das Programm, um die Vegetationsentwicklung im Nationalpark Eifel zu simulieren und die Auswirkung kontrollierter Eingriffe durch den Menschen in die natürlichen Abläufe zu untersuchen. So soll festgestellt werden, welche Eingriffe gemacht werden müssen, um den Nationalpark in seinem jetzigen Zustand zu erhalten IDamP Das Individuen-basierte Daphnia magna Populationsmodell (IDamP) [3] wurde auch von den Wissenschaftlern des Lehrstuhls für Biologie 5 der RWTH Aachen in der Programmiersprache Delphi entwickelt. Daphnia magna ist eine Art aus der Gattung der Daphnien. Dabei handelt es sich um den großen Wasserfloh. Dieser Wasserfloh lebt in vielen deutschen Gewässern wie Tümpeln. Im IDamP- Modell wird der Einfluss von chemischen Stoffen, wie sie zum Beispiel in Düngemitteln vorkommen, auf die Daphnien simuliert. Untersucht werden Werte wie die Nahrungsaufnahme, das Fortpflanzungsverhalten oder der verfrühte Sterben der Daphnien. Das Modell ist ein Individuen-basiertes Modell, was bedeutet, dass jeder Wasserfloh eine eigene Instanz darstellt und nicht mehrere Individuen als Schwarm zusammengefasst und simuliert werden. Dies ermöglicht eine höhere Genauigkeit der Ergebnisse, führt bei großen Schwärmen aber natürlich zu hohem Rechenaufwand. Alle Daphnien durchlaufen einen Lebenszyklus, für den sie unterschiedlich lange benötigen, da zufällig bestimmt wird, wie viel Nahrung eine Daphnie aufnehmen kann. Denn in der Natur gibt es stärkere und schwächere Individuen. Auch in diesem Modell wird durch die Zufallswerte wieder eine Monte- Carlo-Simulation benötigt, um brauchbare Ergebnisse zu erhalten. Der Sinn der Simulation ist dafür zu sorgen, dass zu aggressive Pflanzenschutzmittel nicht angewendet werden dürfen. So soll das Überleben der Art gesichert werden. Eine Simulation eignet sich hier 6 Bachelorarbeit Christian Andrich

9 3.2 - Bereitgestellte Ressourcen besser als ein realer Versuch, da es zwar gut möglich ist, die Versuche an einzelnen Individuen durchzuführen, Versuche an Schwärmen sind aber schwierig und sehr zeitaufwändig. Dieses Modell hat Monte-Carlo-Simulationen bereits implementiert. Diese benötigen aber viel Zeit, daher sollen sie so modifiziert werden, dass sie mit dem entstandenen Programm parallel berechnet werden können. 3.2 Bereitgestellte Ressourcen Vom entwickelten Programm müssen für die Durchführung der Simulationsdurchläufe Ressourcen bereitgestellt werden, welche die Simulationsdurchläufe abarbeiten. Im Umfang dieser Bachelorarbeit sollten zunächst zwei verschiedene Ressourceninfrastrukturen implementiert werden. Dabei handelt es sich um die Rechencluster-Infrastruktur im Rechen- und Kommunikationszentrum der RWTH-Aachen (Aachen-Cluster) und die Cloud-Computing-Infrastruktur, welche im Umfang des Paderborn/Aachen-Cloud-Computing-Projekts umgesetzt wurde (Paderborn/Aachen-Cloud) Aachen-Cluster Bei dem Aachen-Cluster handelt es sich um die Rechencluster-Infrastruktur im Rechen- und Kommunikationszentrum der RWTH-Aachen. Es wird allerdings nicht die gesamte Infrastruktur genutzt, sondern nur der Teil, welcher für das Hochleistungsrechnen unter Windows eingerichtet ist. Dabei handelt es sich um einen Verbund von Rechensystemen, Interaktivsystemen und einem Verwaltungssystem. Die Benutzer können sich auf den Interaktivsystemen über das Remote-Desktop- Connection-Protokoll einloggen und von dort beliebige Windows Anwendungen nutzen. Um diese Anwendungen zu nutzen, muss der Nutzer einen Rechenauftrag (Batch-Job) erstellen, welchen er dann in eine Warteschlange (Batchsystem) submittiert. Das Batchsystem wird vom Verwaltungssystem verwaltet. Das Verwaltungssystem kommuniziert mit den Rechensystemen, um freie Ressourcen zu finden und die Rechenaufträge an die freien Rechensysteme zu übergeben. Auf allen Systemen des Verbunds ist das Betriebssystem Windows HPC Server 2008 installiert, welches die von Microsoft entwickelten Verwaltungsprogramme für die Warteschleife und die Abarbeitung der Rechenaufträge mitliefert. Im Normalfall werden die Rechenaufträge mit Hilfe einer Anwendung mit grafischer Benutzeroberfläche vom Nutzer erstellt und in die Warteschlange submittiert. Es ist allerdings auch möglich, Rechenaufträge über Kommandozeilenbefehle [4] zu erstellen und zu submittieren, was für die automatisierte Erstellung von Rechenaufträgen unerlässlich ist. Über diese Kommandozeilenbefehle können die Rechenaufträge auch überwacht und gesteuert werden. Andere Interaktionsmöglichkeiten mit dem Batchsystem gibt es nicht, was ein Problem darstellt. Möchte man Rechenaufträge verwalten können, muss man als Benutzer auf einer der Interaktivmaschinen eingeloggt sein. Dies hat zur Konsequenz, dass die Ressource Aachen-Cluster von dem entstandenen Programm nur genutzt werden kann, wenn das entstandene Programm auf einer der Interaktivmaschinen gestartet wird. Was sich im ersten Moment als Nachteil darstellt, hat aber den Vorteil, dass der Nutzer die Remote-Desktop-Verbindung zur Interaktivmaschine trennen kann, ohne dass seine laufenden Programme, also auch das entstandene Programm, beendet werden. So können die Benutzer des entwickelten Programms es dauerhaft laufen lassen, ohne dass deren Heim- oder Arbeitsplatz-PC dauerhaft eingeschaltet sein muss. Es ist allerdings zu beachten, dass die Interaktivmaschinen jeden Montag zwischen drei und sechs Uhr morgens neu gestartet werden, wodurch alle Benutzer abgemeldet werden. Warum das entstandene Programm dauerhaft laufen sollte (aber nicht muss), wird später genauer erläutert. Wenn man bedenkt, dass ein Rechenauftrag auf irgendeinem Rechensystem im Verbund gestartet werden kann, tritt eine wichtige Frage auf: Wo werden eventuelle Daten gespeichert, auf die der Rechenauftrag während seiner Ausführung zugreifen muss? Dieses Problem wurde so gelöst, dass Bachelorarbeit Christian Andrich 7

10 3.2 - Bereitgestellte Ressourcen jeder Benutzer Zugriff auf einen persönlichen Bereich auf einem Netzwerklaufwerk erhält, sobald er sich auf einer Interaktivmaschine einloggt. Dieses sogenannte Home-Verzeichnis kann von jedem Rechner im Verbund unter dem gleichen Ordner-Pfad angesprochen werden, wodurch die Daten für jeden Rechner im Verbund zur Verfügung stehen. Dies ermöglicht, dass der Benutzer sein Programm und alle benötigten Dateien für die Ausführung des Programms im Home-Verzeichnis speichern kann, und seinem Programm die Anweisung geben kann, alle eventuellen Ergebnisse im Home-Verzeichnis zu speichern. Das Homeverzeichnis wird auch von dem entstandenen Programm genutzt, dazu später mehr. Alle Daten, die im Home-Verzeichnis gespeichert werden, werden dauerhaft gespeichert und sind durch regelmäßige Sicherungen des Homeverzeichnisses gegen Datenverlust geschützt Paderborn/Aachen-Cloud Die sogenannte Paderborn/Aachen-Cloud [5] ist im Rahmen des Paderborn-Aachen-Cloud-Computing- Projekts entstanden. Bei diesem Projekt handelt es sich um ein Gemeinschaftsprojekt des Rechenund Kommunikationszentrums der RWTH Aachen (RZ) und des Paderborn Center for Parallel Computing der Universität Paderborn (PC²). Diese beiden Rechenzentren haben sich zusammengeschlossen, um gemeinsam ein Cloud- Computing-Projekt umzusetzen. Beim Cloud-Computing wird eine Dienstleistung für einen Auftraggeber von einem Auftragnehmer abgearbeitet, ohne, dass der Auftraggeber den genauen Ablauf sieht. Dies kann z.b. bedeuten, dass der Auftraggeber in einer Cloud-Computing-Lösung eine Berechnung durchführt. Dabei interessiert ihn nicht, auf welchem Computer die Lösung berechnet wird oder an welchem Ort dieser Computer steht. Für den Auftraggeber ist einzig wichtig, dass er nach einer möglichst kurzen Zeit das korrekte Ergebnis erhält. In dem gemeinschftlichen Cloud-Computing-Projekt wird auf verteilten Ressourcen in Paderborn und Aachen eine Software-as-a-Service-Infrastruktur angeboten wird. Software-as-a-Service ist ein Teilgebiet des Cloud-Computing, welches umfasst, dass Nutzer des Service Programme nutzen können, ohne diese auf eigenen Ressourcen installiert zu haben. Das Programm läuft auf einem Rechner irgendwo in der Software-as-a-Service-Infrastruktur, in diesem Fall also irgendwo im RZ oder PC². Die Interaktionsmöglichkeiten mit der Software können vielfältig sein. In der Paderborn/Aachen-Cloud hat der Benutzer nur die Möglichkeit über eine Website mit der Software zu interagieren. Die Interaktionsmöglichkeiten über diese Website sind minimalistisch, denn der Benutzer kann die Anwendung nur starten und stoppen. Jegliche Beeinflussungen der Anwendung während der Laufzeit sind nicht möglich. Um überhaupt irgendeine Kontrolle über das Geschehen zu haben, kann der Benutzer beim Starten des Programms eine Konfigurationsdatei angeben, mit der das Programm gestartet wird. Nachdem die Software erfolgreich durchgelaufen ist, wird dem Benutzer auf der Website eine Ergebnisdatei zur Verfügung gestellt. Welche Form diese Datei hat, ist abhängig von der Software, die gestartet wurde. Vor Beginn der Bachelorarbeit wurden in der Paderborn/Aachen-Cloud die beiden Programme GraS und Gaussian angeboten. Bei Gaussian handelt es sich um eine Software zur Simulation chemischer Prozesse. In Vorbereitung auf die Bachelorarbeit wurde die Paderborn/Aachen-Cloud erweitert, um vollständig von dem im Umfang dieser Bachelorarbeit umgesetzten Programm genutzt werden zu können. Die durchgeführten Arbeiten werden im nächsten Kapitel genauer beschrieben. Änderungen an der Paderborn/Aachen-Cloud konnten jederzeit umgesetzt werden, da der Autor der vorliegenden Arbeit auch der Entwickler der GraS-Unterstützung in der Paderborn/Aachen-Cloud ist. 8 Bachelorarbeit Christian Andrich

11 4.1 - Vereinheitlichung der ökologischen Simulationsmodelle 4 Analyse und Vorarbeiten In diesem Kapitel werden alle Arbeiten beschrieben, die durchgeführt werden mussten, bevor mit der Programmentwicklung für die Bachelorarbeit begonnen werden konnte. 4.1 Vereinheitlichung der ökologischen Simulationsmodelle Um die sehr allgemeinen und abstrakten Anforderungen an das im ersten und zweiten Kapitel erwähnte Verwaltungsprogramm einzugrenzen und eine Implementierung für theoretisch jedes beliebige Simulationsmodell zu ermöglichen, muss gewährleistet sein, dass die Simulationsmodelle, welche unterstützt werden sollen, in einigen Punkten einheitlich aufgebaut sind. Es hat sich gezeigt, dass die benötigte Vereinheitlichung nur vier wesentliche Punkte umfasst: - Bei allen Simulationsmodellen muss es sich um Programme handeln, die unter dem Betriebssystem Windows von Microsoft lauffähig sind. Die Programme müssen dabei auf allen aktuellen Versionen von Windows laufen können. Die zurzeit älteste geforderte Version ist Windows XP. - Alle Simulationsmodelle müssen ohne das Zutun eines Menschen auf eine einheitliche Art und Weise gestartet werden können, um einen Simulationsdurchlauf durchzuführen. Dies ist notwendig, um das Starten der einzelnen Simulationsdurchläufe zu automatisieren. In der konkreten Umsetzung bedeutet dies, dass zum Starten eines unterstützen Simulationsmodell zwei Dinge benötigt werden: o Das Programm selbst in einer Form, in der es ausgeführt werden kann ohne beim ersten Start zusätzliche Dateien zu benötigen. Der erste Start ist der Moment, in dem die Anwendung ausgeführt wird, während der Laufzeit können weitere Dateien einbezogen werden. o Ein Archiv mit zusätzlichen Dateien wie zum Beispiel Eingangsdaten oder Konfigurationsdaten. - Der Start erfolgt nun mit einem Aufruf nach dem Schema Programm Archiv, was bedeutet, dass das Programm gestartet wird und den Dateinamen des Archivs übergeben bekommt. Das Programm ist nun selbst dafür verantwortlich, dass alle benötigten Dateien aus dem Archiv entpackt werden und der Simulationsdurchlauf gestartet wird. Zur Unterstützung wird das kostenlose Programm 7zip [6] von Igor Pavlov bereitgestellt. Es befindet sich als 7za.exe im Ordner 7z, eine Ordnerebene über dem Arbeitsverzeichnis. Es ist zu beachten, dass das Programm sein zugewiesenes Arbeitsverzeichnis nicht verlassen darf, um Dateien zu verändern, weil sonst nicht garantiert werden kann, dass das Programm durch andere Instanzen des gleichen Programms gestört wird, welche sich im gleichen Dateisystem befinden. - Alle Simulationsmodelle müssen dafür sorgen, dass die Dateien, welche der Benutzer als Ergebnis erhalten möchte zum Ende der Laufzeit des Programms im zugewiesenen Arbeitsverzeichnis im Unterordner result gespeichert sind. Dieser Ordner wird archiviert und dem Benutzer nach dem Simulationsdurchgang zur Verfügung gestellt. Das Simulationsmodell darf in seinem zugeordneten Arbeitsverzeichnis nicht auf die Dateien stdout.txt und stderr.txt zugreifen, weil diese den Standardausgabe- und Standardfehlerstrom des Simulationsmodells enthalten und mit in dem Ergebnisarchiv gespeichert werden. - Alle Simulationsmodelle müssen in der Lage sein, fehlerfrei ausgeführt zu werden, wenn zum gleichen Zeitpunkt auf dem gleichen Rechensystem eine weitere Instanz des Simulationsmodells Rechnungen durchführt. Bachelorarbeit Christian Andrich 9

12 4.2 - Änderungen an der Paderborn/Aachen-Cloud Diese Vereinheitlichungen ermöglichen es dem Entwickler eines Verwaltungsprogramms dafür zu sorgen, dass jedes Simulationsmodell, welches die Vereinheitlichungen befolgt, gestartet werden kann, ohne Probleme im Ablauf des entwickelten Programms zu verursachen. Generell gilt, dass die Vereinbarungen vom Entwickler oder Nutzer des Simulationsmodells implementiert werden müssen. Im Umfang dieser Bachelorarbeit wurden die Vereinbarungen in den zwei vorgestellten Simulationsmodellen aber implementiert, um die Umsetzbarkeit zu erproben und die Entwickler der Simulationsmodelle zu entlasten. 4.2 Änderungen an der Paderborn/Aachen-Cloud An der Paderborn/Aachen-Cloud mussten einige Änderungen durchgeführt werden, um sie für das entstandene Programm nutzbar zu machen. Da alle Interaktionen über eine Website laufen, war es nicht möglich die Interaktionen zu automatisieren. Dafür wurde das Programm erweitert, welches die Website bereitstellt und damit auch mit dem Innenleben der Paderborn/Aachen-Cloud kommuniziert. Um zu verstehen, was diese Erweiterung macht, muss aber bekannt sein, wie die Software-as-a- Service-Infrastruktur funktioniert, und insbesondere wie die GraS-Anwendung als Gras-as-a-Service in sie implementiert wurde GraS-as-a-Service Bei der Paderborn/Aachen-Cloud handelt es sich um eine erweiterte Eucalyptus-Cloud. Das bedeutet, dass die Cloud-Computing-Infrastruktur mit der Softwaresammlung Eucalyptus [7] umgesetzt wurde, aber noch um einige Funktionen erweitert wurde. Eucalyptus ist eine Sammlung von Open-Source- Programmen, welche es ermöglicht eine Infrastructure-as-a-Service-Infrastruktur aufzubauen. Beim Cloud-Computing bedeutet dies, dass der Nutzer der Dienstleistung eine Infrastruktur bereitgestellt bekommt, die er ganz nach seinen Wünschen nutzen kann. Dabei spielt es für den Nutzer keine Rolle, wo die tatsächlichen Rechner der Infrastruktur stehen. Der Nutzer möchte nur eine funktionierende Infrastruktur benutzen können. Diese Definition hat Eucalyptus so interpretiert, dass der Anbieter einer Eucalyptus-Cloud eine Infrastruktur bereitstellt, in der es dem Benutzer ermöglicht wird, die Abbilder seiner eigenen virtuellen Maschinen irgendwo in der Infrastruktur zu starten, und eine Netzwerkverbindung zu den laufenden Instanzen bereitgestellt zu bekommen. Eine Instanz ist eine virtuelle Maschine, welche auf echter Hardware ausgeführt wird. Normalerweise ist der Ablauf der Dienstleistung dabei folgender: - Der Nutzer der Infrastruktur überträgt das Abbild seiner virtuellen Maschine in ein Speichersystem, das sogenannte Walrus. - Der Nutzer fordert über eine Verwaltungsinstanz, den sogenannten Cloud-Controller, eine gewisse Anzahl von Ressourcen an, auf denen das übertragene Abbild gestartet werden soll. - Der Cloud-Controller sucht in der Infrastruktur nach freien Ressourcen, bzw. wartet auf freie Ressourcen, und startet dann das gespeicherte Abbild auf so vielen Ressourcen, wie vom Nutzer angefordert wurden. - Der Nutzer erhält die IP-Adresse der gestarteten und laufenden Instanzen. - Der Nutzer kann nun mit seinen Instanzen machen was er will oder sie jederzeit wieder beenden; dafür nutzt er wieder den Cloud-Controller. In Anbetracht der Tatsache, dass die Interaktion mit der Infrastruktur in Paderborn und Aachen aber so eingeschränkt werden sollten, dass nur bestimmte Anwendungen genutzt werden können, ohne Einsicht in die dahinter stehende Infrastruktur zu haben, musste dieser Ablauf wie folgt angepasst werden: 10 Bachelorarbeit Christian Andrich

13 4.2 - Änderungen an der Paderborn/Aachen-Cloud - Der Nutzer der Anwendung wählt seine Anwendung aus und erstellt eine Konfigurationsdatei, um eine bestimmte Berechnung zu starten. - Der Nutzer lädt mit Hilfe einer Website seine Konfigurationsdatei hoch und gibt möglichst wenig weitere Angaben an, die zum Starten notwendig sind. - Der Nutzer klickt auf Starten und wartet, bis die Berechnung beendet wurde. - Der Nutzer lädt über die Website die Ergebnisse seiner Berechnung herunter. Um diesen Ablauf zu ermöglichen, musste für jede Anwendung, die angeboten werden sollte, eine virtuelle Maschine von den Betreibern der Infrastruktur bereitgestellt werden, die in der Lage ist die Anwendung auszuführen. Zusätzlich muss in der virtuellen Maschine ein Programm installiert sein, das ermöglicht, die Anwendung innerhalb der virtuellen Maschine von außen zu starten und zu stoppen und die Konfigurationsdatei in die virtuelle Maschine zu laden. Eine weitere umzusetzende Komponente war die erwähnte Website, die dem Nutzer als einzige Interaktionsmöglichkeit mit der Infrastruktur dienen sollte. Das Programm, welches die Website bereitstellen sollte, musste auch in der Lage sein, mit der Infrastruktur-Steuerung und der Programm-Steuerung innerhalb der virtuellen Maschinen zu interagieren. In der tatsächlichen Umsetzung wurden beide Programme, das der Website und das zur Steuerung der Anwendung, in Python umgesetzt. Das Programm welches die Website für GraS-as-a-Service bereit stellt, läuft zurzeit auf einem Ubuntu-Server im Rechenzentrum in Aachen, die Website ist unter erreichbar. Daran ist erkennbar, dass jede Anwendung eine eigene Website erhält. Dies ist sinnvoll, da sich die Anwendungen in ihrer Handhabung teilweise zu stark unterscheiden, um eine einheitliche Handhabung zu implementieren. Auf der Website hat der Benutzer die Möglichkeit, neben der Angabe der Konfigurationsdatei noch die Anzahl der benutzen Instanzen pro Simulation anzugeben. Dies ergibt beim GraS-Modell Sinn, da das Modell auch eine einzelne Simulation parallel auf mehreren Instanzen berechnen kann, um dadurch schneller zum Ergebnis zu gelangen, und während der Berechnungen mehr Arbeitsspeicher zur Verfügung zu haben. Die Vergrößerung des Arbeitsspeichers ist notwendig, da große Datensätze sonst nicht gerechnet werden können, ohne an das Limit des Arbeitsspeichers zu stoßen und dadurch abzustürzen. Bei dem bereitgestellten Abbild der virtuellen Maschine handelt es sich um eine mit Windows XP bespielte Maschine, welche das Steuerungsprogramm und einen ssh-server enthält. Das GraS-Modell ist nicht enthalten, da es jedes Mal vor dem Starten über den ssh-server in die virtuelle Maschine übertragen wird. Dadurch kann gewährleistet werden, dass immer eine aktuelle Version des Modells genutzt werden kann. Daraus ergibt sich für das GraS-Modell folgender Ablauf der Ereignisse: - Der Benutzer startet eine neue Berechnung. - Das Website-Programm lädt die vom Benutzer angegebene Konfigurationsdatei ins Walrus hoch. - Das Website-Programm fordert den Cloud-Controller auf, die vom Nutzer gewünschte Anzahl an Instanzen mit dem für GraS bereitgestellten Abbild zu starten. - Die Website wartet, bis das Steuerungsprogramm in allen angeforderten Ressourcen ansprechbar ist. Ist dies der Fall, bedeutet das, dass alle Instanzen gestartet wurden, und Windows überall hochgefahren ist, also, dass dem Berechnen der Simulation nichts mehr im Wege steht. - Die auf dem Server der Website hinterlegte Version des GraS-Modells wird auf alle gestarteten Instanzen übertragen. - Alle beteiligten Instanzen werden über das Steuerungsprogramm aufgefordert die Konfigurationsdatei aus dem Walrus herunterzuladen. Bachelorarbeit Christian Andrich 11

14 4.2 - Änderungen an der Paderborn/Aachen-Cloud - Eine der beteiligten Instanzen wird über das Steuerungsprogramm aufgefordert das GraS- Modell zu starten. Da zum Starten ein MPI-Wrapper genutzt wird, wird auf allen anderen beteiligten Instanzen auch das GraS-Modell gestartet. Der MPI-Wrapper wird für die parallele Berechnung benötigt, was genau das bedeutet, ist für diese Bachelorarbeit aber irrelevant. - Die Website prüft nun regelmäßig den Status des GraS-Modells mit Hilfe des Steuerungsprogramms in der Instanz, die den MPI-Wrapper gestartet hat, um festzustellen, ob die Berechnungen beendet wurden, oder ob das GraS-Modell aus einem anderen Grund beendet wurde. - Nach dem Beenden des Programms werden alle Ergebnisse gesammelt, diese liegen auf der Instanz die den MPI-Wrapper gestartet hat im Ordner result, daher wird per Steuerungsprogramm der Befehl erteilt, die Daten in einem Archiv zu bündeln und ins Walrus hochzuladen. - Der Nutzer hat nun die Möglichkeit, über die Website das entstandene Ergebnis-Archiv herunterzuladen. An diesem Ablauf ist erkennbar, dass GraS-as-a-Service schon fast alles bietet, was wir für die Integration in das im Umfang dieser Arbeit entwickelten Programm benötigen. Was noch fehlt ist aber die Möglichkeit, die Aktionen, die der Nutzer auf der Website ausführen würde, automatisiert aus dem entwickelten auf einem anderen Rechner laufenden Programm durchzuführen. Dies wird im übernächsten Abschnitt beschrieben, im nächsten Abschnitt muss aber vorher kurz das XMLRPC- Protokoll vorgestellt werden, welches neben der Verwendung für die später beschriebene Erweiterung auch für die Kommunikation zwischen Website und Steuerungsprogramm in den Instanzen verwendet wird Das XMLRPC-Protokoll Das Protokoll XMLRPC [8] muss bekannt sein, um den nächsten Abschnitt zu verstehen. XMLRPC ist eine Abkürzung für Extensible Markup Language Remote Procedure Call und ermöglicht das Ausführen von Prozeduren system-, plattform- und sprachenübergreifend. Dies wird an folgendem Beispiel erläutert: Es gibt eine in Python programmierte Klasse, welche unter Linux auf einem entfernten Rechner laufen muss. Nun wird aus einem Java-Programm auf einem Windows-Rechner über das Internet eine Methode der Python-Klasse aufrufen. Dies ermöglicht XMLRPC, indem es den Methodenaufruf als XML-Code darstellt und ihn über das HTTP-Protokoll versendet. Der Rückgabewert der Methode wird ebenso als XML-Code per HTTP-Protokoll verschickt. Dazu werden ein XMLRPC-Server und ein XMLRPC-Client benötigt. Der Server wird auf der Seite gestartet, auf der die Methode aufgerufen wird. In dem Beispiel also auf dem entfernten Linux-Rechner. Der Server muss eine Klasse oder einzelne Methoden oder Funktionen übergeben bekommen, die er ausführen kann. Auf Client-Seite, also im Java-Programm unter Windows wird ein Client erstellt, welcher den gewünschten Befehl übergeben bekommt und ihn an den Server schickt. Dieses Protokoll ist weit verbreitet, und es gibt für viele Programmiersprachen Implementierungen. Es muss bei der Benutzung beachtet werden, dass für die Übergabeparameter oder die Rückgabewerte Datentypen gewählt werden, welche von XMLRPC unterstützt werden. Die jeweilige Implementierung ist dafür verantwortlich die Datentypen zu standardisieren, was z.b. bei Strings wichtig ist Implementierung der entfernten Steuerung Für die entfernte Steuerung wurde das Programm, welches die Website bereitstellt, um eine Klasse erweitert, welche alle benötigten Funktionen beinhaltet, die sonst der Nutzer ausführen würde. Es wird ein XMLRPC-Server gestartet, und ihm wird die entwickelte Klasse übergeben, wodurch jede Anwendung die einen XMLRPC-Client implementiert die Funktionen aufrufen kann, als würden sie direkt in dem aufrufenden Programm ausgeführt. 12 Bachelorarbeit Christian Andrich

15 4.2 - Änderungen an der Paderborn/Aachen-Cloud Entstanden ist die Klasse RemoteStarter, welche die 4 wichtigsten Funktionen abdeckt: - Erstellen und starten eines Rechenauftrags, diese Funktion wurde create genannt - Abbrechen eines gestarteten Rechenauftrags, die Funktion heißt abort - Abfragen des Status eines Rechenauftrags, passend status genannt - Herunterladen der Ergebnisse, zu finden als getkeydata Abbildung 1 Klassendiagramm RemoteStarter Die fünfte Funktion, echo, diente nur zum Testen der Verbindung, sie gibt direkt den übergebenen String zurück. Da der XMLRPC-Server parallel zu der Website-bereitstellenden Komponente des Website-Programms läuft, kann die enthaltene Klasse direkt die Codezeilen imitieren, die ausgeführt würden, wenn der Nutzer in der Website bestimmte Aktionen ausführte. Begonnen wird mit der Funktion create, da diese den Anfang einer jeden Simulation bildet. Am Funktionsaufbau create(user, nodes, procs, infile) kann erkannt werden, welche Daten zum Starten einer Berechnung wichtig sind. User enthält den Benutzernamen, denn auf der Website müsste sich der Benutzer mit seinem Benutzernamen einloggen um Simulationen starten zu können. Es ist angedacht den Startvorgang auch um eine Passwortabfrage innerhalb des entwickelten Programms zu erweitern, diese Funktionalität ist allerdings noch nicht implementiert, da zur Zeit auch das Überarbeiten des Einloggens auf der Website geplant ist. Nodes ist die Anzahl wie viele Instanzen gestartet werden sollen, procs gibt an, wie oft das Modell pro Instanz gestartet werden soll, denn das GraS-Modell unterstützt auch Instanz-interne Parallelität. Der letzte Übergabeparameter ist ein Byte- Array, welcher die einzelnen Bytes der Konfigurationsdatei, im Falle von GraS also eines Zip-Archivs enthält. Mit diesen Übergabeparametern ist es nun möglich, folgende Aktionen durchzuführen: - Öffnen einer Datenbank, die alle Informationen über die Rechenaufträge enthält. - In der Datenbank einen neuen Rechenauftrag erstellen und die Werte user, nodes und procs darin speichern. - In der Datenbank den Status des neuen Rechenauftrags auf pending setzten, wodurch ein Verwaltungsthread aktiv wird, welcher während der gesamten Laufzeit des Website-Programms die Datenbank überwacht. Dieser Verwaltungsthread reagiert auf den Rechenauftrag genauso, wie er auf Rechenaufträge reagieren würde, die durch einen Benutzer erstellt wird. Daher werden alle weiteren Schritte gestartet; am Anfang also das Suchen freier Ressourcen. - Mit Hilfe von infile wird die Konfigurationsdatei rekonstruiert und ins Walrus hochgeladen. Das dies erst passiert, wenn der Verwaltungsthread theoretisch bereits mit dem Starten des Rechenauftrags begonnen haben könnte ist unkritisch, da das Starten der Instanzen wesentlich länger dauert als das Hochladen der Konfigurationsdatei. Die Konfigurationsdatei sollte also immer bereits hochgeladen sein wenn sie benötigt wird. Dies wird seitens der Cloud-Computing- Infrastruktur aber nicht überprüft, hier besteht daher Vergesserungsbedarf an der Infastruktur. Zurückgegeben wird nach erfolgreicher Ausführung eine Zahl, welche eine eindeutige Identifikationsnummer des Rechenauftrags in der Datenbank darstellt, sollte die Ausführung fehlerhaft verlaufen sein, wird eine Fehlermeldung zurückgegeben. Um während der Simulation den Status abrufen zu können beginnt die Funktion status auch wie create: - Öffnen einer Datenbank, die alle Informationen über die Rechenaufträge enthält. Bachelorarbeit Christian Andrich 13

16 4.2 - Änderungen an der Paderborn/Aachen-Cloud - Anhand des Übergabeparameters jobid kann in der Datenbank ein Rechenauftrag eindeutig identifiziert werden. Dessen Status wird aus der Datenbank ausgelesen. Der Status, welcher als Zahlenwert in der Datenbank steht wird vom Website-Programm regelmäßig mit Hilfe des Steuerungsprogramms in den Instanzen überprüft und in der Datenbank aktualisiert. - Zurückgegeben wird der Status, entweder als Zahlenwert, oder als textuelle Beschreibung des Zahlenwerts und somit als String. Die textuelle Beschreibung wäre zum Beispiel bei dem Status 0 pending. Ob ein String oder ein Zahlenwert zurückgegeben wird, wird anhand der Variable string unterschieden, ist diese True wird ein String zurückgegeben. Auch die Funktion Abort benötigt die Datenbank: - Öffnen einer Datenbank, die alle Informationen über die Rechenaufträge enthält, mit jobid wird wieder der Rechenauftrag identifiziert. - In der Datenbank steht neben dem aktuellen Status auch noch ein interner Status, dieser wird auf todo_abort gesetzt, wodurch der Verwaltungsthread beginnen wird, den Rechenauftrag abzubrechen. Der Verwaltungsthread sorgt auch dafür, dass die Ergebnisdaten im Walrus gespeichert werden. - Diese Funktion gibt immer True zurück. Die letzte Funktion, getkeydata, hat mit dem Verwaltungsthread nichts zu tun, trotzdem benötigt sie die Datenbank: - Öffnen einer Datenbank, die alle Informationen über die Rechenaufträge enthält, mit jobid wird wieder der Rechenauftrag identifiziert. - Anhand der Daten aus der Datenbank wird im Walrus die Datei identifiziert, welche die Ergebnisse der Simulation enthält. Diese Datei wird dann in den Arbeitsspeicher heruntergeladen und in einen Byte-Array konvertiert. - Zurückgegeben wird der entstandene Byte-Array, also der Inhalt der Ergebnis-Datei. Da diese Funktionen alle von einem externen Programm mittels XMLRPC-Client aufgerufen werden können, gehe alle Rückgabewerte direkt an das externe Programm, im Normalfall also an das für diese Bachelorarbeit entwickelte Programm, welches später beschrieben wird. Der gesamte Quellcode der Klasse kann im Anhangt eingesehen werden Exe-as-a-Service Da mit dem entstandenen Programm nicht nur das GraS-Modell in der Paderborn/Aachen-Cloud laufen soll, musste es ermöglicht werden, auch alle anderen Simulationsmodelle in der Cloud zu starten. Rückblickend auf die Vereinbarungen aus Abschnitt 4.1 sollen die Simulationsmodelle alle in einer Form vorliegen, in der nur zwei Dinge benötigt werden: die individuelle Anwendung und die individuelle Konfigurationsdatei. Die individuelle Konfigurationsdatei stellt kein Problem dar, da auch das GraS-Modell eine individuelle Konfigurationsdatei hat, diese Funktionalität ist also schon in der Cloud implementiert. Was fehlt ist die Möglichkeit, eine individuelle Anwendung in der Cloud zu nutzen. Diese Dienstleistung wird als Exe-as-a-Service bezeichnet. Es wurde bereits erwähnt, dass sich das GraS-Modell nicht im Abbild der virtuellen Maschine befindet, sondern, dass es vor jedem Start in alle Instanzen übertragen wird, um immer eine aktuelle Version anbieten zu können. An dieser Stelle setzt Exe-as-a-Service an, denn die Dienstleistung ist GraS-as-a-Service so ähnlich, dass eine eigene Implementierung nur unnötigen Aufwand darstellen 14 Bachelorarbeit Christian Andrich

17 4.2 - Änderungen an der Paderborn/Aachen-Cloud würde. Die Idee die umgesetzt wurde ist daher vor dem Update-Vorgang die GraS-Anwendung zu ersetzten, damit eine andere Anwendung in die Instanzen verteilt wird. Die Cloud-Infrastruktur bekommt von diesem Vorgang nichts mit, was auch gar nicht erforderlich ist. Eine Überlegung, die angestellt wurde war die Frage, ob Exe-as-a-Service auf der Website, von GraSas-a-Service angeboten werden soll. Dies wurde nicht so implementiert, da Exe-as-a-Service zurzeit nur von dem in dieser Arbeit entstandenen Programm benötigt wird. Von den beiden Interaktionsmöglichkeiten, der Website und dem RemoteStarter, musste also nur der RemoteStarter angepasst werden, um Exe-as-a-Service zu unterstützen. Die Website wurde nicht modifiziert. Die create-funktion wurde deswegen um zwei Übergabeparameter erweitert: progname und prog. progname enthält den Namen der Anwendungsdatei ohne Pfadangabe als String und prog enthält einen Byte-Array mit der Anwendungsdatei, ähnlich wie der Byte-Array der Konfigurationsdatei (infile). Das erste, was die create-funktion nun macht, ist prog in eine Datei zu schreiben. Dafür wird eine leere Datei erstellt (oder überschrieben), und mit dem Inhalt von prog gefüllt. Der Dateiname wird dabei aus progname generiert, sodass die Anwendung in einem neuen temporären Ordner gespeichert wird. Es wäre noch einfacher direkt die GraS-Anwendung zu überschreiben, weil danach keine Änderungen mehr gemacht werden müssten, das hätte aber zwei Probleme zur Folge: - GraS-as-a-Service kann nicht mehr von der Website gestartet werden kann, da nicht garantiert werden kann, dass die GraS-Anwendung nicht irgendein anderes Simulationsmodell ist. - Falls zwei verschiedene Simulationsmodelle zum exakt gleichen Zeitpunkt gestartet werden, wird eines der beiden Simulationsmodelle mit der falschen Anwendung gestartet, weil es nur eine Anwendung gleichzeitig in dem Ordner geben kann. Diese Probleme werden durch das Mitberücksichtigen des Dateinamens des Simulationsmodells umgangen. Zusätzlich wird es dadurch ermöglicht auch andere Dateien als Exe-Dateien auszuführen. Dankbar wäre das Ausführen eines Batch-Scrips, welches die Anwendung erst entpackt und dann startet; für den Fall, dass mehrere Dateien für die Anwendung benötigt werden. Es entsteht aber ein neues Problem: In den Instanzen wird versucht die Datei Modell.exe des GraS-Modells zu starten und heißt die Datei anders, stürzt der Aufruf ab weil Modell.exe nicht existiert. Um dieses Problem zu lösen muss der Dateiname der Anwendung mit an die Instanzen geliefert werden. Hierfür wird sich eines Tricks bedient, denn der Dateiname wird mit in der Datenbank im Feld comment gespeichert. Diese Feld dient normalerweise dazu, dass der Nutzer Kommentare zu einzelnen Rechenaufträgen schreiben kann, wird bei Rechenaufträgen, die mit dem RemoteStarter erstellt wurden, aber nie genutzt. Beim Starten der Berechnungen durch den Verwaltungsthread muss dieser natürlich erkennen können, ob es sich um einen Kommentar handelt, oder um die Anweisung, eine andere Datei zum Starten zu nutzen. Daher wird vor den Dateinamen die Zeichenfolge ~#~ gesetzt, da es extrem unwahrscheinlich ist, dass jemand diese Zeichenfolge als die ersten drei Buchstaben seines Kommentars verwendet. Mehr Änderungen werden am RemoteStarter nicht vorgenommen. Die nächste Änderung betrifft den Vorgang der Dateiübertragung in die Instanzen. Hier wird nun die entsprechende Anwendung in die Instanzen geladen, falls die erwähnte Zeichenfolge im Kommentar erkannt wird. Die Anwendung wird dabei im gleichen Ordner in den Instanzen platziert, in dem die GraS-Anwendung platziert worden wäre. Bachelorarbeit Christian Andrich 15

18 4.3 - Anpassung des GraS-Modells Die nächste Änderung betrifft schon das Starten des Simulationsmodells durch den Verwaltungsthread mit Hilfe des Steuerungsprogramms in den Instanzen. Da beim Starten einige Variablen an die Instanz übertragen werden, war es kein Problem auch den Kommentar mit zu übertragen. Da dieser danach dem Steuerungsprogramm bekannt ist, kann wieder nach der speziellen Zeichenfolge gesucht werden. Wird diese gefunden, wird einfach der Dateiname der Anwendung, welche gestartet wird ersetzt. Dadurch wird dann das andere Simulationsmodell gestartet. Durch die Vereinbarungen, an die sich die Simulationsmodelle halten müssen, kann alles andere wie bei einer Simulation des GraS-Modells ablaufen, Unterschiede gibt es nicht mehr. Da die Änderungen sehr verteilt in einem sehr langen Quellcode sind, ist der Quellcode der Änderungen nicht angehängt. Eine Ausnahme bildet der Quellcode der Klasse RemoteStarter, welcher wie schon erwähnt im Anhang zu finden ist. 4.3 Anpassung des GraS-Modells Um das GraS-Modell mit dem entstandenen Programm nutzen zu können, mussten die Vereinheitlichungen aus Abschnitt 4.1 eingehalten werden. Welche Schritte notwendig waren um dies zu erreichen, und wie eine Auswertung der Ergebnisse ermöglicht wurde, wird in diesem Abschnitt beschrieben Automatisierter Startvorgang Das GraS-Modell hatte vor den notwendigen Anpassungen ein ganz entscheidendes Problem: Es war eine Anwendung mit grafischer Benutzeroberfläche, in der man Rechnungen durch das Anklicken von Schaltflächen und das Ausfüllen von Textfeldern startet. Ein automatisiertes Starten ist so natürlich nicht möglich. Was erreicht werden muss, ist, dass man dem Modell eine Datei übergibt, die alle nötigen Einstellungen und die Information, wie das Modell gestartet werden soll enthält. Das GraS-Modell ist so aufgebaut, dass man zum Starten einer Simulation einige Werte in der Benutzeroberfläche einstellt, zum Beispiel die Laufzeit in Jahren. Dann klickt man auf einen von mehreren Schaltflächen, welcher die Simulation startet. Je nachdem, welche Schaltfläche gedrückt wurde, werden noch einige Dateien wie zum Beispiel die Karte der zu simulierenden Landschaft benötigt. Diese werden über Datei-Dialoge vom Benutzer ausgewählt. Die Informationen die, also in einer Konfigurationsdatei stehen müssen, sind alle Werte, die in der Benutzeroberfläche eingestellt wurden, welcher Schaltflächendruck zum Starten simuliert werden muss, und welche Dateien nach dem Starten ausgewählt werden sollen. Da alle Werte, welche in Felder in der grafischen Benutzeroberfläche eingetragen werden können, auch manuell aus dem Source-Code in die einzelnen Felder geschrieben werden können, werden Werte, welche aus einer Datei gelesen werden direkt in die entsprechenden Felder eingetragen, bevor ein Schaltflächendruck simuliert wird. Der Schaltflächendruck kann durch das Aufrufen der Funktion simuliert werden, welche beim Drücken der Schaltfläche aufgerufen werden würde. Was am meisten Eingriffe in den Quellcode erforderte war das Auswählen der zusätzlich erforderlichen Dateien. Da normalerweise ein Dialogfenster zur Auswahl der Dateien erscheint musste dieses unterdrückt werden. Wann das Dialogfeld zu unterdrucken ist, wird entschieden, indem eine Variable betrachtet wird, welche speichert, ob das Programm mit einer übergebenen Datei gestartet wurde. Ist dies der Fall wird der entsprechende Wert direkt aus der Datei ausgelesen. Daraus ergeben sich zwei Funktionen die implementiert werden müssen: - Alle Werte aus einer Datei einlesen und in der Benutzeroberfläche eintragen - Einen bestimmten Wert aus einer Datei einlesen und zur Verfügung stellen Die Dateistruktur wurde so gewählt, dass jeder Wert eine eigene Zeile der Datei erhält. Um den Wert zu identifizieren stehen an den ersten beiden Stellen einer Zeile zwei Zahlen. Diese gehen in der 16 Bachelorarbeit Christian Andrich

19 4.3 - Anpassung des GraS-Modells aktuellen Version von 00 bis 71. Auch die Information welche Schaltfläche gedrückt werden soll, und welche Dateien bereitgestellt werden sollen haben eine dieser Nummern erhalten. Das Einlesen der gesamten Datei läuft nun über alle Zeilen, liest die Nummern ein, und entscheidet dann anhand der Nummer ob der Wert verwertet werden kann, und falls ja, an welche Stelle in der Oberfläche er eingefügt werden soll. Unbekannte Werte werden ignoriert. Das Einlesen eines bestimmten Wertes bedarf der Übergabe eines Zahlencodes. Dieser wird Zeile für Zeile gesucht, wurde er gefunden wird der entsprechende Wert zurück geliefert, wurde er am Ende der Datei nicht gefunden wird ein leerer String zurückgegeben. Zurückgegeben wird immer ein String, sollte sich hinter dem String ein Zahlenwert verbergen, muss die aufrufende Funktion die Umrechnung selbst durchführen. Um eine Datei einlesen zu können muss sie natürlich erst einmal erstellt werden. Dafür wurde das Optionsmenü des GraS-Modells um einen Menüpunkt erweitert. Klick man diesen an wird ein Dateiname verlangt, existiert die Datei, wird sie geladen und die Felder der Benutzeroberfläche werden gefüllt, existiert sie nicht wird der Benutzer darüber informiert und die Felder der Benutzeroberfläche behalten ihren aktuellen Wert. Danach erscheint ein neues Fenster, in dem es mehrere Textfelder gibt. In diesen Textfeldern werden die Pfade zu den Dateien eingetragen, welche zur Berechnung benötigt werden. Aus Komfortgründen öffnet sich ein Datei-Dialog wenn man doppelt in das Feld klickt, um eine Datei auszuwählen und den Pfad automatisch eintragen zu lassen. Unter den diversen Feldern für die verschiedenen möglichen Dateien gibt es eine Auswahlbox, in der der Benutzer eine Schaltfläche auswählt, auf den geklickt werden soll. Alle auswählbaren Schaltflächen starten dabei eine Simulation. Darunter gibt es drei Auswahlboxen, mit denen der Nutzer entscheiden kann, ob drei zusätzliche von den anderen Schaltflächen unabhängige Schaltflächen gedrückt werden, oder nicht. Diese Schaltflächen starten keine Simulation, daher können von diesem Schaltfächentyp mehrer angeklickt werden. Diese Schaltflächen sind zum dazu gedacht direkt Dateien zu laden. Ein Beispiel ist eine Schaltfläche, welche eine zu simulierende Landschaftskarte lädt. Als letztes Element des neuen Fensters folgt eine Schaltfläche zum Speichern. Wird dieser gedrückt, wird die am Anfang ausgewählte Datei neu erstellt bzw. überschrieben und mit allen Werten der Benutzerfläche und den im neuen Fenster eingestellten Werten gefüllt. Da die Benutzeroberfläche aus mehreren Fenstern besteht, werden unter Umständen mehr Werte gespeichert als der Benutzer sieht, dies ist aber kein Problem, da alle Felder Standardwerte haben die übernommen werden wenn sie nicht geändert wurden. Auf Fenster die nicht angezeigt werden kann zugegriffen werden, da alle Fenster beim Start der Anwendung initialisiert wurden, und manche nur unsichtbar sind. Aus diesen Umständen ergibt sie die Notwendigkeit einer weiteren Funktion: - Alle Werte aus der Oberfläche auslesen und in eine Datei speichern In dieser Methode wird einfach eine Schleife von 0 bis 71 durchlaufen und der entsprechende Wert wird aus der Benutzeroberfläche bzw. dem neuen Fenster gelesen und mit der passenden Nummer in die Datei geschrieben. Falls die Datei überschrieben werden soll wird sie vor dem Durchlaufen der Schleife komplett geleert. Alle drei Funktionen sind nicht besonders komplex, wegen der individuellen Variablennamen für die 72 Werte aber sehr lang, daher wird ihr Quellcode nicht abgebildet. Damit die Dateien auch einen Nutzen haben, wurde das Modell so erweitert, dass es erkennt, wenn es mit einer Datei als Übergabeparameter gestartet wird. Ist dies der Fall, wird die schon erwähnte Variable die speichert, ob das Modell mit einer Datei gespeichert wurde, gesetzt. Danach wird die einlesende Funktion aufgerufen um die Benutzeroberfläche mit Werten zu füllen, oder besser gesagt um die Standardwerte zu überschreiben. Als nächstes wird der Schaltflächendruck simuliert, wodurch das Modell selbstständig mit den Berechnungen beginnt. Der letzte Schritt, welcher noch benötigt wird ist das Beenden des Programms. Da die Benutzeroberfläche während der Berechnungen weiter dargestellt wird, würde sich das Programm nicht automatisch nach der Berechnung beenden. Daher Bachelorarbeit Christian Andrich 17

20 4.3 - Anpassung des GraS-Modells wurde nach den Berechnungen eine Überprüfung der schon mehrfach erwähnten Variable eingefügt, die das Programm terminiert falls es mit einer Datei gestartet wurde Bündelung der Initialdateien Durch die Änderungen aus dem vorherigen Abschnitt ist es zwar jetzt möglich, das Modell automatisch zu starten, und es ist auch möglich, das Modell mit einem Datensatz mehrfach auszuführen, um immer wieder die gleiche Simulation durchzuführen. Es wurde aber bereits erwähnt, dass in der Konfigurationsdatei Dateinamen angegeben werden, von Dateien, die während der Simulation benötigt werden. Um diese Dateien mitliefern zu können, muss das GraS-Modell so umgebaut werden, das es nicht nur mit einer Konfigurationsdatei gestartet wird, sondern mit einem Archiv, welches die Konfigurationsdatei und alle weiteren benötigten Dateien enthält. Dafür wurde das Modell so erweitert, dass es erkennt, wenn es nicht mit einer Konfigurationsdatei gestartet wird, sondern mit einem Archiv. Das Unterscheidungsmerkmal ist die Dateiendung gras bzw. zip. Wurde das Modell mit einem Zip-Archiv gestartet, wird es mit Hilfe von 7zip in das Arbeitsverzeichnis entpackt. In dem Archiv befinden sich die Konfigurationsdatei als cloud.gras und alle benötigten Dateien mit standardisierten Namen und ohne Verzeichnisbaum. Die standardisierten Namen befinden sich auch in der cloud.gras-konfigurationsdatei, welche nun gelesen werden kann. Ab diesem Moment verhält sich das Modell so, als wäre es direkt mit der Konfigurationsdatei gestartet worden. Das einzige was noch zu beachten ist, ist, dass in der Konfigurationsdatei auch die Namen der Dateien standardisiert wurden, in denen die Ergebnisse der Rechnungen gespeichert werden, damit sie im Unterordner result gespeichert werden. Damit all diese Änderungen in der Konfigurationsdatei keine menschlichen Fehler enthalten wurde das Erstellen der Archive zum Starten des Modells automatisiert. Dafür wurde das Modell um einen weiteren Menüpunkt im Optionsmenü erweitert. Klickt man diesen an, wird man aufgefordert eine existierende Konfigurationsdatei zu wählen, welche man konvertieren möchte. Zusätzlich wählt man ein nicht existierendes Archiv, als welches das generierte Archiv gespeichert wird. Nun startet der Konvertierungsvorgang, was bedeutet, dass alle benötigten Dateien aus der Konfigurationsdatei ausgelesen werden. Sie werden in einen neuen Ordner kopiert. In den neuen Ordner wird auch die Konfigurationsdatei selbst kopiert, sie wird dabei in cloud.gras umbenannt. Nun werden die Dateinamen der zusätzlichen Dateien standardisiert, was bedeutet, dass in der Konfigurationsdatei der Dateiname übernommen wird, der Pfad zu der Datei aber verworfen wird, da sich nun alle Dateien im Arbeitsverzeichnis befinden. Der Fall, dass zwei Dateien aus unterschiedlichen Verzeichnissen kommen aber gleiche Namen haben wird nicht berücksichtigt, darauf muss der Nutzer selbst achten. Nachdem alle benötigten Dateien in einem Ordner gesammelt wurden und die Konfigurationsdatei angepasst wurde, wird mit Hilfe des Programmes 7zip ein Archiv aller Dateien aus dem neuen Ordner erstellt und unter dem zuvor eingegebenen Namen gespeichert. Der Nutzer des Modells muss dabei beachten, dass das Programm 7zip in der Form 7za.exe im Verzeichnis 7z im gleichen Verzeichnis wie die Exe-Datei des Modells liegt. Durch die Lizenzbedingungen des Programms 7zip ist es möglich das Programm zusammen mit dem GraS-Modell an den Nutzer zu liefern. Das GraS-Modell genügt nun den Anforderungen des entwickelten Programms und kann damit verwendet werden. Der Quellcode zu den beschriebenen Bündelungen kann im Anhang eingesehen werden Automatisierte Auswertung der Ergebnisse Da während der Laufzeit des entwickelten Programms viele Einzelergebnisse entstehen muss das GraS-Modell eine Methode implementieren, welche die Einzelergebnisse einliest und auswertet. Dieser Vorgang wird vom Benutzer des GraS-Modells auf einem Arbeitsplatzrechner ausgeführt und hat nichts mehr mit dem entwickelten Programm zu tun. Der Benutzer bedient daher direkt das GraS- Modell und bekommt Informationen und Abfragen in dessen grafischer Oberfläche angezeigt. 18 Bachelorarbeit Christian Andrich