Bachelorarbeit

Transcrição

Bachelorarbeit

Universität Augsburg
Institut für Informatik
Lehrstuhl für Softwaretechnik und Programmiersprachen
KO N Z E P T I O N U N D I M P L E M E N T I E R U N G E I N E R
W E T T E R S I M U L AT I O N U N D D A R A U F
AUFB AUENDER LEISTUNGSVORHERSAGEN FÜR
W E T T E R A B H Ä N G I G E S T RO M E R Z E U G E R I N
EINEM ORGANIC COMPUTING SYSTEM
Bachelorarbeit
Autor:
Daniel Jilg
Matr.-Nr. 987996
[email protected]
Betreuer:
Prof. Dr. Wolfgang Reif
Dipl.-Inf. Jan-Philipp Steghöfer
[email protected]
Dezember 2010
Abstract:
Basierend auf dem OC-Trust-Forschungsprojekt wird an der Universität Augsburg die Plattform
EnergyGrid realisiert, die die Infrastruktur für Organic-Computing-Anwendungen auf einem
Stromnetzwerk mit Verbrauchern und Erzeugern bereitstellt. Mit der wichtigste Aspekt des EnergyGrid ist die Wettersimulation, die Wetterdaten wie Sonnenintensität und Windgeschwindigkeit simuliert und anderen Einheiten eine simulierte Wetterprognose für zukünftige Zeitabschnitte bereitstellt. In dieser Arbeit wird die Strukturierung und technische Umsetzung dieses
Konzepts beschrieben.
Wettersimulation in einem Organic-Computing-System
Daniel Jilg
Inhalt
1. Einleitung
3
2. Grundlagen
5
2.1. Organic Computing
5
2.2. Repast Simphony als Simulationsumgebung
6
2.3. EnergyGrid
6
3. Konzepte für die Wettersimulation und -vorhersage im EnergyGrid
8
3.1.Vollständige Wettersimulation mit Numerical Weather Prediction
8
3.2. Wettersimulation durch Interpolation realer Wetterdaten
10
3.3. Wettervorhersage
15
4. Technische Umsetzung
17
4.1. InternalCalendar
17
4.2. WeatherStation
18
4.3. StochasticPowerPlant
19
5. Evaluation
22
5.1. Evaluation der räumlichen Interpolationsmethode
22
5.2. Evaluation der Wettervorhersage
24
6. Zusammenfassung und Ausblick
27
7. Anhang
29
7.1. Evaluation der räumlichen Interpolation
29
29
7.3. Inhalt der beigelegten CD-ROM
31
8. Quellen
34
1
Daniel Jilg
2
Daniel Jilg
1. Einleitung
Beim Aufbau moderner Stromnetze präsentieren sich viele Herausforderungen: Mit
dem Aufkommen neuer, umweltschonenderer Techniken zur Stromgewinnung nimmt die
Komplexität der Kraftwerkslandschaft zu. Dies geschieht vor allem auch durch die Einspeisung von Solarstrom in das Netz durch Kleinsterzeuger wie zum Beispiel Dach-Solaranlagen, die von Privatleuten betrieben werden.
Die manuelle Koordination so vieler Kraftwerke ist zeitraubend und schwierig. Erschwert wird sie durch die zum Teil langsame Reaktions- und Änderungsgeschwindigkeit
mancher Kraftwerkstypen.
Hier kann durch die Einführung von autonomen Systemen Abhilfe geschaffen werden.
Das EnergyGrid-Projekt der Universität Augsburg ist eine Simulationsplattform zur Erforschung von Systemen, die es Kraftwerken auf der Basis von Organic-Computing-Prinzipien
ermöglichen sollen sich selbst zu organisieren und zu steuern. Dazu organisieren sich die
simulierten Stromerzeuger in losen autonomen, sich selbst regelnden Gruppen.
Die Leistung der meisten konventionellen Kraftwerke (Atom, Gas, Wasser, et cetera)
ist einfach und direkt vorhersehbar, da sie nicht von äußeren Faktoren abhängt. Anders
verhält es sich bei Wind- oder Solar-Kraftwerken, deren Leistungsabgabe je nach Wetterlage variiert. Diese Variation sollen die anderen Kraftwerke möglichst schnell und genau
ausgleichen.
Es ist daher für das Projekt essentiell, über eine Wettersimulation zu verfügen. Eine
glaubhafte Nachbildung des Wetters ermöglicht es simulierten Wind- und Solarkraftwerken, realistische Leistungswerte auszugeben – inklusive aller Schwankungen. Je realistischer
die simulierten Wetterwerte dabei sind, desto näher liegt auch das Verhalten der auf sie
aufbauenden simulierten Kraftwerke an ihren Gegenstücken in der Realität. Nur in Bezug
auf dieses natürliche Verhalten können Techniken und Algorithmen, die sich mit der selbstständigen dezentralen Steuerung befassen, effizient entwickelt und evaluiert werden.
Neben der möglichst genauen Kenntnis des aktuellen Wetters ist auch eine Prognose
über seine weitere Entwicklung wichtig für das Verhalten der Kraftwerke im EnergyGrid.
Mit ihrer Hilfe errechnen vom Wetter abhängige Kraftwerke eine Leistungsvorhersage, die
es anderen Kraftwerken ermöglicht, rechtzeitig auf Veränderungen zu reagieren, indem sie
ihre Stromproduktion erhöhen oder zu senken.
Nachdem die Wettersimulation auf realen Wetterdaten basiert und zu einem Zeitpunkt in der Vergangenheit statt findet, wäre es durchaus möglich, die weitere Entwicklung
des Wetters direkt aus der Datenbank auszulesen. Spätestens bei der Übertragung der in
der Simulation entwickelten Techniken in die Realität funktioniert dieser Ansatz jedoch
nicht mehr, und die Vorhersage wird notwendig.
Für die vorliegende Arbeit ist eine Wettersimulation für das EnergyGrid entwickelt
worden, die auch eine einfache Vorhersage beinhaltet.
In Kapitel 2 wird das EnergyGrid und die Architektur, auf der es aufgebaut ist, erörtert. Hierfür wird der Begriff Organic Computing in Bezug auf Agentensysteme definiert,
das Agentensystem Repast Simphony erläutert und schließlich das in Repast implementierte, nach Organic-Computing-Prinzipien gestaltete EnergyGrid beschrieben.
3
Daniel Jilg
Kapitel 3 geht auf zwei mögliche Ansätze zur Wettersimulation ein, einerseits die Simulation mit Numerical Weather Prediction, die in der Anfangsphase erwogen wurde, und
andererseits die reine Interpolation bereits vorhandener Wetterdaten, die als geeignetere
Lösung erkannt und implementiert wurde. Es werden unterschiedliche Verfahren zur Einspeisung der zu interpolierenden Wetterdaten in das System besprochen und die Einführung von Agenten, die Wetterstationen simulieren, als sinnvollste Lösung herausgegriffen.
Dazu werden Formeln für die Interpolation definiert und erläutert. Des Weiteren wird
eine Technik zur einfachen Wettervorhersage vorgestellt.
Das 4. Kapitel beschäftigt sich mit der technischen Umsetzung der im Kapitel 3 genannten Konzepte. Dazu werden die voneinander abhängigen Klassen InternalCalendar
und WeatherStation vorgestellt und ihre Attribute und Methoden erklärt. Weiterhin wird
die Umstrukturierung und Erweiterung der PowerPlant-Klassen, sowie ihre neuen Methoden und Attribute, besprochen.
In Kapitel 5 wird untersucht, wie nahe die vom Algorithmus zur räumlichen Interpolation der Wetterdaten und vom Algorithmus zur Wettervorhersage generierten Werte an
realen Wetterwerten liegen. Dazu werden Methoden zur Evaluation der Daten vorgestellt,
angewandt und die Ergebnisse bewertet.
Kapitel 6 bietet schließlich eine Zusammenfassung der Arbeit und stellt Überlegungen
an, in welchen Gebieten das erschaffene System noch erweitert oder verbessert werden
kann.
4
Daniel Jilg
2. Grundlagen
Als Grundlage für die besprochenen
Änderungen und Neuerungen, die im Zuge
dieser Arbeit im EnergyGrid eingeführt
wurden, soll zuerst ein Überblick über den
bisherigen Aufbau des Systems gegeben
werden.
Abbildung 1. zeigt die mit dem EnergyGrid gekoppelten Technologien und Konzepte: Es ist nach Organic-Computing-Prinzipien aufgebaut und basiert auf dem Framework Repast Simphony. Daher soll im
Folgenden zuerst der Begriff des Organic
Computing definiert und eine kurze Vorstellung von Repast gegeben werden, bevor das
EnergyGrid selbst erklärt wird.
Erzeuger
Stromnetz
Verbraucher
Umgebung
Wetter
ENERGYGRID
REPAST SIMPHONY
ORGANIC COMPUTING
Abb. 1: Architektur des EnergyGrid
2.1. Organic Computing
Mit der fortschreitenden Automatisierung, Miniaturisierung und Leistungssteigerung
von computergesteuerten Systemen wird es zunehmend schwieriger, sie zentral zu steuern. Gleichzeitig besteht für die meisten dieser Systeme die Anforderung, so robust, sicher,
flexibel und vertrauenswürdig wie möglich zu sein.
Um diesen Anforderungen gerecht zu werden, wird versucht, Systeme zu entwickeln,
die möglichst unabhängig, flexibel und selbstständig handeln – anders ausgedrückt, solche,
die sich verhalten als wären sie Lebensformen. Diese Systeme werden als organisch bezeichnet.
Die einzelnen Komponenten des Systems sollen in der Lage sein, auch in unvorhergesehenen Situationen sinnvoll zu reagieren und ihr Verhalten aufeinander abzustimmen. Dazu kommunizieren sie mit anderen Komponenten, so dass ein intelligent handelndes
Netzwerk entsteht, das sich dynamisch an die gegebenen Bedingungen seiner Umgebung
anpasst. Im Unterschied zu traditionellen Ansätzen können auf diese Art Entscheidungen,
die vorher bereits zur Designzeit getroffen werden mussten, in die Laufzeit verlagert werden.
Organic-Computing-Systeme, kurz OC-Systeme, sollen eine Reihe von Eigenschaften
aufweisen, die sicher stellen, dass sie einerseits möglichst flexibel handeln, aber andererseits trotzdem beherrschbar bleiben und keine Verhaltensweisen entwickeln, die mit der
gewünschten Funktionalität im Konflikt stehen. Diese Eigenschaften sind die so genannten
“Selbst-X”-Eigenschaften: Die Systeme sollen selbst organisierend, selbst konfigurierend,
selbst optimierend, selbst heilend, selbst schützend und selbst erklärend sein[1].
Eine simulierte Umgebung, in der mehrere Einheiten (Software-Agenten) versuchen,
kollektiv ein Problem zu lösen, nennt sich ein Agentensystem und ist die Grundlage vieler
5
Daniel Jilg
OC-Systeme. Ein Ameisenhaufen ist ein natürliches Beispiel für ein solches System. Auch
das EnergyGrid ist ein Agentensystem, das mit Hilfe des Frameworks Repast Simphony
realisiert wurde. Im folgenden Abschnitt wird die Software kurz präsentiert.
2.2. Repast Simphony als Simulationsumgebung
Repast Simphony[2] ist eine Plattform für die Modellierung und Simulation von Agentensystemen. Sie ist in Java geschrieben und kostenlos unter einer Open-Source-Lizenz
verfügbar. Die Entwicklung innerhalb des Frameworks findet ebenfalls in Java statt; die Agenten sind Instanzen bestimmter Java-Klassen.
Das Framework enthält ein Geo-Informations-System, um Agenten in einer mit Koordinaten versehenen Geografie anzuordnen, Übersichtskarten darzustellen und verschiedene Geografie-basierte Daten zu berechnen, zum Beispiel die Entfernung zwischen
Agenten.
Agenten in Repast sind normalerweise ortsbasiert, haben also in der simulierten Geografie feste Koordinaten, und es ist ihnen zum Beispiel möglich, die Entfernung zu ihren
Nachbaragenten festzustellen. Sie haben außerdem die Möglichkeit, mit anderen Agenten
zu kommunizieren, indem sie deren öffentliche Methoden aufrufen.
Der Zeitablauf in Repast basiert auf Ticks genannten diskreten Zeitabschnitten. In jedem Tick wird in jedem der Agenten eine Step-Methode aufgerufen, in der der Agent mit
anderen Agenten kommunizieren, seinen internen Status verändern und generell eigenständig handeln kann. Ist die Step-Methode jedes Agenten aufgerufen, ist der Tick vorüber.
2.3. EnergyGrid
Auf Repast steht das EnergyGrid, ein Simulationssystem in dem Agenten agieren, die
ein Stromnetzwerk mit Erzeugern und Verbrauchern nachbilden. Geplant ist, kommerzielle
Kraftwerke und Kleinst-Stromerzeuger in Bayern anhand realer Daten zu simulieren und
dabei Selbstorganisations-Techniken zu entwickeln, die auch in der Realität eingesetzt
werden können.
Die wichtigsten von EnergyGrid simulierten Konzepte sind:
• Erzeuger: Kraftwerke, die Strom erzeugen. Ein Erzeuger hat einen festen Ort
und gehört zu einem bestimmten Kraftwerks-Typ, zum Beispiel ein Solar-, Nuklearoder Wasserkraftwerk.
• Verbraucher: Einzelne Geräte, Großabnehmer und ganze Versorgungsgebiete,
die Strom verbrauchen. Ein Verbraucher hat eine Lastkurve, die seinen Strombedarf
in Abhängigkeit von der Zeit angibt.
• Stromnetz: Verbindet Erzeuger und Verbraucher und ist für die Kommunikation
des Strombedarfs per Frequenzanpassung zuständig. Rechnet außerdem Übertragungsverluste mit ein.
6
Daniel Jilg
• Umgebung: Mit Koordinatensystem versehene Fläche, in der sich die Kraftwerke
und Verbraucher sowie die Verbindungen des Stromnetzes befinden.
Erzeuger werden dabei nicht zentral gesteuert und verwaltet, sondern organisieren
sich anhand von OC-Prinzipien selbst: Kraftwerke verschiedenen Typs im EnergyGrid
schließen sich zu Autonomen Virtuellen Kraftwerken (AVK) zusammen, einem Verbund,
der Leistungsschwankungen einzelner Mitglieder ausgleichen kann. Damit erreicht ein AVK
eine höhere Zuverlässigkeit in der Stromproduktion als die einzelnen Mitglieder.
In dieses bereits existierende System soll die Wettersimulation eingefügt werden. Im
nachfolgenden Kapitel werden dazu verschiedene Konzepte vorgestellt.
7
Daniel Jilg
3. Konzepte für die Wettersimulation und -vorhersage im
EnergyGrid
Es entstanden zwei verschiedene Ideen zum Einbau der Wettersimulation in das vorhandene System. Als Ziel wurde gesetzt, die beiden Konzepte Windgeschwindigkeit und
Sonnenintensität an jedem geografischen Punkt der Simulation abfragen zu können. Diese
beiden Daten sind für Wind- beziehungsweise Solarkraftwerke am relevantesten, während
andere Randdaten wie Windrichtung, Bewölkungsdichte oder Luftfeuchtigkeit zwar in der
Berechnung hilfreich sein können, aber überwiegend keine direkte Auswirkung auf die genannten Kraftwerke haben.
Im Folgenden sollen die beiden Ansätze vorgestellt werden, die für die Wettersimulation in Betracht gezogen wurden.
3.1.Vollständige Wettersimulation mit Numerical Weather Prediction
Grundidee
Der Ansatz der zu Beginn verfolgt wurde, ist die Simulation des Wetters anhand
kommerziell eingesetzter Algorithmen, wie sie zum Beispiel auch zur Vorhersage durch
Wetterdienste eingesetzt werden. Diese Technik wird auch als Numerical Weather Prediction (NWP) bezeichnet und basiert auf der Forschung des britischen Mathematikers Lewis Fry Richardson. Publikationen dazu sind [3,4,5,6] und vor allem [7].
Bei diesem Ansatz werden keine realen Wetterdaten verwendet. Eine Ausnahme ist
möglicherweise der Startpunkt einer Simulation, an dem eine realistische Grundlage gebildet werden muss. Statt dessen wird das Wetter komplett abgeschottet von der Außenwelt simuliert und berechnet. Das hat den Vorteil, dass die Simulation für jeden beliebigen
Ort ausgeführt werden kann, ohne dass kontinuierliche Wetterdaten für die Region bereit
stehen müssen.
Laut [7] ist der Ausgangspunkt des für den hier behandelten Ansatz interessanten
NWP-Modells die Simulation von Wolkenbildung und atmosphärischem Niederschlag.
Diese Konzepte werden unter dem Begriff Cloud Microphysics zusammengefasst. Zwar ist
das Verhalten von Wolken nicht direkt relevant für die Simulation im EnergyGrid, es hat
aber direkten Einfluss auf die Sonneneinstrahlung, die wiederum für die Solarkraftwerke
innerhalb der Simulation notwendig ist.
Die Lichtmenge die zu einem gegebenen Zeitpunkt auf einen Punkt auftrifft besteht
aus zwei Komponenten: Direkte Strahlung, also Sonnenstrahlen die ohne Umwege durch
die Atmosphäre auf den betrachteten Punkt gelenkt werden, und diffuse Strahlung, die
von Partikeln in der Luft zerstreut wird und erst dann auf dem betrachteten Punkt auftrifft.
Beide hängen laut [8] im Wesentlichen von der Lufttrübung (Linke turbidity factor),
dem Sonnenwinkel und der Rayleigh-optischen Dicke (Rayleigh optical thickness) ab. Auf
diese Einflussfaktoren wird im Folgenden genauer eingegangen.
8
Daniel Jilg
Die Lufttrübung bezeichnet die Durchsichtigkeit der Luft; sie wird vor allem durch
schwebende Wassertröpfchen verursacht (außerdem durch Abgas- und sonstige Partikel
– diese werden aber vom hier vorgestellten primitiven NWP-Ansatz nicht berücksichtigt).
Der Lufttrübungs-Wert lässt sich mit Hilfe der Simulation von Wolkenbildung aus [7] errechnen. Eine höhere Trübung lässt weniger direkte Strahlung bis zum Zielpunkt durchdringen; dafür wird ein größerer Anteil der Strahlen abgelenkt und trägt somit zur diffusen
Komponente bei.
Der Sonnenwinkel ist der Winkel, mit dem direkte Sonnenstrahlen auf einen bestimmten Koordinatenpunkt auftreffen. Dieser scheinbar einfach zu berechnende Wert
hängt neben Ort, Datum und Uhrzeit von vielen astronomischen und geografischen Parametern ab; eine adäquate Berechnung wurde erst 1979 durch den Niederländer Jean
Meeus entwickelt[6]. In [9] wird eine Repräsentation von Meeus’ Formeln in algorithmischer Form beschrieben, die sich für den Einbau in die NWP-Simulation des EnergyGrid
anbieten würde. Im nachfolgenden Diskussionsabschnitt werden seine Vor- und Nachteile
beleuchtet.
Die “Rayleigh-optische Dicke” ist in [8] eine Funktion des Sonnenwinkels und der
Höhe des Zielorts über dem Nullpunkt. Die optische Dicke hängt von der relativen optischen Luftmasse ab, also der Länge des Pfades, den ein Lichtstrahl von der Sonne zum
Zielpunkt innerhalb der Atmosphäre zurücklegen würde. Hier ist die optische Dicke einer
Atmosphäre gemeint die das Licht nach einer einer kontinuierlichen Rayleigh-Wahrscheinlichkeitsverteilung zerstreut.
Durch eine Kombination dieser Funktionen kann die Lichtmenge errechnet werden,
die einem bestimmten Solarkraftwerk innerhalb eines bestimmten Zeitraums zur Verfügung steht.
Äquivalent dazu kann auch ein Algorithmus entwickelt werden, der auf NWP-Prinzipien basiert und die aktuelle Windgeschwindigkeit zum Ergebnis hat; dieser ist jedoch
deutlich komplexer, da er in Regionen, die nicht in der Nähe einer Meeresküste liegen, auf
einem dreidimensionalen Modell der Umgebung aufbaut. Zudem sind NWP-Windmodelle immer noch äußerst ungenau, außer sie werden in sehr hohen Auflösungen berechnet
und haben möglichst genau kalibrierte Werte für exakt die Region, deren Winde sie simulieren sollen[7].
Diskussion
Die hier vorgestellten Teile des NWP-Ansatzes sind bereits verhältnismäßig komplex,
sie decken jedoch trotzdem nur einen kleinen Teil des gesamten Problemraums ab. Außerdem zeigt der NWP-Ansatz große Probleme im Aufwand und in der Genauigkeit der
Berechnung.
Während großflächige Phänomene wie Hoch- und Tiefdruckgebiete noch relativ zuverlässig über längere Zeit simuliert werden können, ist spätestens die Berechnung von
Wolkenbildung, und -verteilung, die ja für den Lichteinfluss in der Simulation erforderlich
ist, schnell ungenau und divergiert spätestens nach einigen simulierten Tagen drastisch von
der Situation in der Realität. Selbst kommerzielle Wetterdienste veröffentlichen deshalb
kaum Vorhersagen für längere Zeiträume als wenige Tage. Der NWP-Ansatz wäre also
9
Daniel Jilg
trotz des hohen Aufwands nicht unabhängig von stetig nachgereichten realen Wetterdaten
möglich. Stehen regelmäßig reale Wetterdaten zur Verankerung der Simulation zur Verfügung, würde sich der Ansatz anbieten, um die Zwischenräume zu überbrücken. Für diese
Aufgabe ist er aber deutlich zu kompliziert. Der nachfolgende Abschnitt zeigt, dass anstatt
der hochkomplexen Simulation auch eine einfache Interpolation zur Überbrückung benutzt werden kann.
Das Problem der Genauigkeit spiegelt sich in der benutzten Auflösung der Algorithmen wider. Moderne Numerica-Weather-Prediction-Algorithmen unterteilen die Atmosphäre horizontal und vertikal in diskrete Blöcke – je feiner die Unterteilung, desto genauer können Wetterphänomene berechnet werden. Unterhalb bestimmter Auflösungen
können Wetterphänomene wie zum Beispiel die Windrichtung kaum oder nur sehr unzuverlässig erfasst werden. Es gibt darüberhinaus bestimmte Auflösungs-Grenzen, unterhalb
derer die Algorithmen sogar komplett unrealistische Daten ausgeben[7]. Genau wie bei
anderen Berechnungsproblemen, wie zum Beispiel dem Rendern von Computergrafiken,
steigt auch hier der benötigte Arbeitsspeicher und die benötigte Prozessorleistung exponentiell mit der Auflösung an.
Dazu kommt, dass für eine zuverlässige Abbildung des Wetters innerhalb des zu simulierenden Gebiets ein möglichst großer umliegender Bereich mit berechnet werden muss;
andernfalls käme es zu Artefakten und unrealistischem Wetterverhalten an den Rändern
des Gebiets. Der vergrößerte simulierte Bereich würde ebenfalls den Berechnungsaufwand drastisch erhöhen.
Aufgrund der Kombination aus Ungenauigkeit der generierten Wetterdaten und dem
sehr hoch eingeschätzten Rechenaufwand wurde daher beschlossen, den NWP-Ansatz
nicht weiter zu verfolgen, sondern statt dessen einen Ansatz zu entwickeln, der von realen
Wetterdaten ausgeht, ohne die zugrunde liegenden atmosphärischen Phänomene zu simulieren. Zur Überbrückung zwischen den vorhandenen Datenpunkten wird dabei statt
NWP eine einfache Interpolation verwendet.
3.2. Wettersimulation durch Interpolation realer Wetterdaten
Ausgehend von der Annahme, dass reale Wetterdaten für längere Zeiträume verfügbar sind, wurde ein vereinfachter Ansatz entwickelt, um den simulierten Solar- und Windkraftwerken realistische Wetterdaten zur Verfügung zu stellen.
Grundidee
Betrachtet man zwei nahe beieinander liegende geografische Punkte, so ändert sich
das Wetter zwischen den beiden Punkten nicht abrupt. Statt dessen gehen Wetterdaten
wie Windgeschwindigkeit und Sonnenenergie fließend ineinander über.
Anders ausgedrückt: Es ist wahrscheinlich, dass zumindest Windstärke und Sonnenintensität am Mittelpunkt einer Strecke zwischen zwei Punkten a und b zu gleichen Anteilen
aus Windstärke und Sonnenintensität an den beiden Punkten bestehen. Wird ein Punkt c
betrachtet, der näher an b und weiter entfernt von a liegt, treten dort Daten auf, die mehr
von b und weniger von a beeinflusst werden (Abb. 2).
10
Daniel Jilg
Auf andere Wetterdaten
wie zum Beispiel dem NiederWind: 2,9m/s
schlag muss diese Hypothese
Sonne: 626 Wh/m
nicht zutreffen. Für die hier betrachteten Werte wird sie jea
b
doch durch die Evaluation in
c
Abschnitt 5 belegt.
Wind: 5m/s
Wind: 2m/s
Angenommen, es wären
Sonne: 865 Wh/m
Sonne: 530 Wh/m
zeitlich kontinuierliche Wetterdaten für einige Punkte in dem
zu simulierenden Gebiet vorWETTERSTATION
DATENPUNKT
handen, dann könnte man diese
an bestimmten Punkten in das
INTERPOLATION
ERZEUGER
System einspeisen. An allen anderen Punkten wäre es dann
Abb. 2: Interpolation zwischen zwei Punkten mit
möglich, durch Interpolation der
Wetterdaten
Werte der umliegenden Punkte
realistische Wetterdaten zu generieren.
In Bayern sind tatsächlich die Messwerte aller staatlichen Wetterstationen öffentlich
zugänglich und werden in maschinenlesbarer Form unter [10] von der Bayerischen Landesanstalt für Landwirtschaft zur Verfügung gestellt. Enthalten sind neben Temperatur, Luftfeuchtigkeit und Niederschlag auch die notwendigen Daten zur Globalstrahlung und
Windgeschwindigkeit, die für die Simulation im derzeitigen Rahmen benötigt werden.
Der Interpolations-Ansatz hat einige Vorteile im Vergleich zum NWP-Ansatz. So gibt
er grundsätzlich realistische Werte aus, da die benutzten Daten tatsächlich direkt gemessen und nicht approximativ errechnet wurden. Zwar können durch die Interpolation leichte Abweichungen entstehen; diese sind aber deutlich geringer als die Abweichungen, die
durch eine ungenaue numerische Simulation entstehen würden. Weiterhin ist die Interpolation weniger komplex als NWP, sowohl im Aufwand zur Berechnung als auch in der Implementierung.
Die Simulation läuft also auf der gleichen Hardware um mehrere Größenordnungen
schneller ab, nicht nur weil die benutzten Algorithmen deutlich einfacher sind, sondern
auch weil es der Interpolationsansatz erlaubt, das Wetter nur für die geografischen Punkte
zu berechnen, an denen es tatsächlich gebraucht wird, anstatt überall auf der Karte. Möglicherweise wäre die Berechnung mit der NWP-Methode auf einem einzelnen Rechner
nicht mehr in annehmbarer Zeit abgelaufen, während die Interpolationsmethode dort die
Performanz kaum beeinträchtigt.
Die geringere Komplexität der Implementierung führt zu einer übersichtlicheren Codebase, die besser wart- und erweiterbar ist. Durch die kleinere Größe ist die Wahrscheinlichkeit, dass Programmierfehler auftreten, ebenfalls verringert. Alles in allem weist
die Interpolation deutliche Vorteile gegenüber der NWP-Methode auf.
Im Folgenden werden zwei Konzepte vorgestellt, Wetterdaten ins System einzufügen.
Zum einen wird die Methode erläutert, die Daten direkt in bestimmte Kraftwerke einzu2
2
11
2
Daniel Jilg
speisen. Da diese Methode sich jedoch als mangelhaft erwiesen hat, wird sie nur kurz angesprochen. Zum anderen wird ein Ansatz gezeigt Wetterdaten über einen neuen Agententyp direkt an deren Entstehungsort einzufügen.
Bereitstellung der Wetterdaten in bestimmten Kraftwerken
Eine Möglichkeit, die Wetterdaten in das System einzuspeisen, besteht darin, die Daten direkt in Kraftwerke zu speichern, in deren Nähe sie entstanden sind.
In der Vorbereitungsphase wird dazu auf einer Karte, auf der sowohl Kraftwerke als
auch Wetterstationen eingezeichnet sind, jede Wetterstation dem ihr nächstgelegenen
Kraftwerk zugeordnet, solange die Entfernung zwischen den beiden einen bestimmten Radius nicht überschreitet. Jedes simulierte Kraftwerk, das eine Wetterstation zugewiesen
bekommen hat, kann dann direkt auf deren Wetterdaten zugreifen.
Abbildung 3 zeigt die Anordnung. Kraftwerke, die nah genug an einer Wetterstation
liegen (im Bild Mitte und rechts), erhalten deren Wetterdaten und speichern sie. Andere
Kraftwerke, wie das links im Bild, finden in der Vorbereitung keine Wetterstation innerhalb
des fest gelegten Radius und interpolieren deshalb ihr Wetter über diejenigen Kraftwerke,
die direkte Wetterdaten beinhalten. Daten von Wetterstationen, die keinen Kraftwerken
zugeordnet wurden, werden verworfen.
702
698
702
694
694
ERZEUGER
WETTERSTATION
ZUORDNUNG
DATENPUNKT
INTERPOLATION
Abb. 3: Zuordnung von Wetterdaten zu bestimmten Kraftwerken
In diesem Entwurf kommt das Konzept der Wetterstationen nicht in der Simulation
selbst vor; statt dessen ist es inhärent in den Kraftwerken enthalten, die Wetterdaten gespeichert haben. Das hat den Vorteil, dass das der Simulation zu Grunde liegende Modell
nicht weiter verändert werden muss.
Es entstehen jedoch ebenso Nachteile: Wird die maximale Entfernung, die eine Wetterstation von einem Kraftwerk trennen darf, zu hoch gewählt, entstehen Ungenauigkeiten,
da die Daten weit entfernt von ihrem Entstehungsort in das System eingespeist werden.
12
Daniel Jilg
Wird die Entfernung aber niedriger gewählt, fallen viele Wetterstationen gänzlich aus dem
Suchbereich heraus, und es werden nur wenige Punkte im System bestimmt, an denen
tatsächliche Wetterdaten eingefügt werden. Abbildung 4 zeigt, dass die Interpolation dann
sehr ungenau ist, obwohl genügend Daten vorhanden sind:
Radius zu groß:
Wetterdaten am
falschen Ort.
Radius zu klein:
Keine Wetterstationen
zugeordnet.
ERZEUGER
WETTERSTATION
ZUORDNUNG
Abb. 4: Zu klein oder zu groß gewählte Radien
Ein alternatives Konzept dazu ist, die Wettersimulation aus den Kraftwerken auszulagern und stattdessen Wetterstationen als eigene Entität in das System mit einzubauen.
Bereitstellung der Wetterdaten in Wetterstationen
741
730
694
715
738
702
ERZEUGER
WETTERSTATION
ANFRAGE
DATENPUNKT
INTERPOLATION
Abb. 5: Wetterstationen und Kraftwerke getrennt. Kraftwerke erfragen Wetterdaten von allen Wetterstationen und interpolieren
Das direkte Einbeziehen der Wetterstationen in das Simulationsmodell ist zwar möglicherweise komplexer als die Einspeisung der Daten in die Kraftwerke selbst, macht aber
aus konzeptioneller Sicht mehr Sinn und hat noch eine Reihe weiterer Vorteile.
Zum bereits vorhandenen Kraftwerk-Modell wird bei diesem Ansatz noch ein weiteres für Wetterstationen geschaffen. Instanzen des Modells werden an den Koordinaten
realer Wetterstationen platziert und mit Daten der entsprechenden Stationen verknüpft.
13
Daniel Jilg
Damit werden die Daten genau dort in das System eingespeist, an denen sie entstanden
sind. Kraftwerke, die Wetterwerte für ihre Position benötigen, können diese aus der Gesamtmenge der Wetterstationen interpolieren, wie Abbildung 5 zeigt.
Ein Vorteil dieser Methode der besonders hervorgehoben werden muss ist, dass alle
vorhandenen Wetterdaten zur Interpolation genutzt werden können, anstatt nur die, die in
der Nähe von Kraftwerken entstanden sind – unabhängig von der Definition von “Nähe”.
Damit sind die entstandenen Interpolationen genauer, und es werden keine Daten grundlos verworfen.
Außerdem ist das Modell durch die Konzeption per se näher an der Realität – Daten
werden genau dort in das System eingespeist, wo sie gemessen wurden. Das hilft dabei,
möglichst realistische Interpolationsdaten zu generieren und erleichtert Quereinsteigern
das Einlesen in die Software.
Aufgrund der genannten Vorteile ist der Ansatz, reale Wetterdaten über ein Wetterstationsmodell in das System einzuspeisen, Erfolg versprechend. Es folgt eine nähere Betrachtung einiger wichtiger Details und die Vorstellung der zur Berechnung der Interpolationswerte benutzten Formeln.
Zeitliche Interpolation in Wetterstationen
Zunächst soll die Simulation nicht davon abhängen, dass das Intervall der zur Verfügung gestellten Wetterdaten mit dem internen Wert für die Länge eines Simulationsschritts überein stimmt. Deswegen ist vor der räumlichen Interpolation, die in einem
Kraftwerk aus den Werten aller Wetterstationen berechnet wird, eine zeitliche Interpolation nötig, die dafür sorgt, dass zu jedem Tick plausible Werte berechnet werden, auch
wenn für den exakten Zeitpunkt keine Datenpunkte vorhanden sind.
Diese zeitliche Interpolation innerhalb der Wetterstation funktioniert ähnlich wie die
weiter unten vorgestellte räumliche Interpolation auf der simulierten Geografie: Sollte der
Zeitpunkt des Ticks genau auf einen diskreten Zeitpunkt in der Wetterdatenbank fallen,
werden dessen Wetterdaten benutzt. Andernfalls werden anteilsmäßig die vorherigen mit
den nachfolgenden Werten verrechnet wie in Formel (1) beschrieben. Der Wert wnow,
steht dabei für den Vektor der aktuellen Windgeschwindigkeit und der aktuellen Globalstrahlung. Er berechnet sich aus den Werten des zeitlich vorherigen und des zeitlich nachfolgenden Datenpunkts.
Dabei ist Δprev der zeitliche Abstand zum vorherigen Datenpunkt und Δnext der zeitliche Abstand zum nachfolgenden Datenpunkt in Sekunden. wprev und wnext sind die entsprechenden Werte der Datenpunkte – es wird die gleiche für Formel Windstärke und
Sonnenintensität benutzt.
Steigt der zeitliche Abstand zum vorherigen Datenpunkt, erhöht sich dadurch der
Wert Δprev. Nachdem dieser per Multiplikation mit dem nachfolgenden Datenpunkt wnext
verknüpft ist, erhöht sich durch den größeren Abstand von Δprev die Relevanz von wnext
14
Daniel Jilg
und die Relevanz von wprev wird verringert. Das gleiche gilt analog, wenn der Abstand zum
nachfolgenden Punkt erhöht und der zum vorherigen Punkt verringert wird. Anders ausgedrückt: Je weiter ein Datenpunkt zeitlich vom Messpunkt entfernt ist, desto weniger Einfluss hat er auf den interpolierten Messwert.
Räumliche Interpolation in Kraftwerken
Weiterhin muss ein Kraftwerk aus den Werten, die die Wetterstationen jeweils für
den aktuellen Tick zur Verfügung stellen, eine räumliche Interpolation berechnen, die das
Wetter an seinem Standort zum Ergebnis hat. Befindet sich ein Kraftwerk dabei exakt an
der selben Stelle wie eine Wetterstation, werden deren Daten benutzt. Ansonsten wird
Formel (2) eingesetzt, die die räumliche Interpolation zwischen Messwerten verschiedener Wetterstationen beschreibt.
Der interpolierte Wetterwert w(k) des Kraftwerks k setzt sich dabei aus Komponenten der Werte aller Wetterstationen zusammen. Dabei sei WS die Menge der Wetterstationen im System, d(x, y) der Abstand zwischen den Agenten x und y und w(x) der
Wetterwert der Wetterstation x. Wetterwerte sind dabei Vektoren der numerischen
Werte für Windgeschwindigkeit in m/s und Sonnenintensität in Wh/m2. Genau wie bei
Formel (1) wird die selbe Formel sowohl für Windstärke als auch für Sonnenenergie eingesetzt.
Formel (2) ist ähnlich wie Formel (1) aufgebaut, berücksichtigt jedoch beliebig viele
Datenpunkte anstatt nur zwei. Die zunehmende Entfernung einer Wetterstation vom
Punkt a erhöht die Multiplikatoren aller anderen Punkte außer a und verringert damit
dessen relativen Anteil am Gesamtwert.
3.3. Wettervorhersage
Die Konzeption der Wettervorhersage im System stößt auf ähnliche Probleme wie
die der Wettersimulation selbst: Eine Simulation nach NWP-Prinzipien ist aus den gleichen
Gründen nicht erwünscht, die auch schon die Simulation des aktuellen Wetters uninteressant gemacht haben – Rechenaufwand, Ungenauigkeit, Komplexität.
Die datenbasierte Simulation wäre innerhalb des Systems theoretisch möglich, denn
die virtuellen Wetterstationen haben die Möglichkeit, auch zukünftige Wetterzustände aus
ihrer Datenbank zu lesen. Behält man aber das Ziel im Auge, das EnergyGrid später zur
Steuerung realer Kraftwerke zu benutzen, macht dieser Ansatz ebenfalls wenig Sinn; spätestens in der realen Welt existiert (leider) keine Datenbank zukünftiger Wetterzustände.
15
Daniel Jilg
Die Wettervorhersage wird von Autonomen Virtuellen Kraftwerks-Clustern gebraucht, um die zukünftige Produktion ihrer einzelnen Elemente vorherzusagen und gegebenenfalls frühzeitig auf Veränderungen einzugehen. Glücklicherweise reicht dafür oft
schon eine sehr rudimentäre Aussage, weswegen für die erste Version des Wettersystems
die Vorhersage von einer Kombination des augenblicklichen Wetters und der Entwicklungskurve der Vortages abhängt.
Betrachtet man zum Beispiel die Sonnenstrahlung an zwei aufeinander folgenden Tagen g (gestern) und h (heute), so wird ihr Verlauf über beide Tage hinweg jeweils sehr ähnlich sein, solange kein Wetterwechsel wie zum Beispiel von einem sonnigen auf einen regnerischen Tag statt gefunden hat. In diesem Fall könnte also die Vorhersage für die Abendstunden von h direkt die Daten der Abendstunden von g liefern und wäre hinreichend
zuverlässig.
Findet ein Wetterwechsel statt, unterscheiden sich die Wertekurven von Tag zu Tag
vor allem in der Höhe, aber kaum in der Form – an einem bewölkten Tag dringt weniger
Sonnenlicht durch die Wolkendecke, aber die Sonne durchläuft trotzdem fast die selbe
Bahn und geht zu fast den selben Zeiten auf und unter. Ähnlich verhält es sich mit der
Windgeschwindigkeit.
Daher besteht der Vorhersagewert für einen Zeitpunkt t aus zwei Komponenten:
Dem jetzigen Wert, multipliziert mit der prozentualen Veränderung des Werts am Vortag.
Oder als Formel ausgedrückt, die Vorhersage für einen Zeitpunkt um den Wert Δt in der
Zukunft liegt lautet:
Wie die bisher genannten Formeln wird auch Formel (3) sowohl für die Berechnung
von Windgeschwindigkeit als auch von Globalstrahlung eingesetzt. w(t) sei die Funktion,
die den Vektor für beide Werte für den Zeitpunkt t ausgibt. Der aktuelle Zeitpunkt der
Simulation ist t, und Δt gibt an, wie weit die Vorhersage in die Zukunft blicken soll. Eine
Evaluation der Genauigkeit dieses Ansatzes findet sich in Abschnitt 5.2.
16
Daniel Jilg
4. Technische Umsetzung
Nachdem bisher ein theoretischer Überblick über die zu implementierenden Konzepte gegeben wurde, soll jetzt tiefer auf einige Aspekte der technischen Umsetzung eingegangen werden. Der schon vorhandene Quellcode wurde an einigen Stellen umorganisiert und refaktoriert, und es wurden neue Klassen eingeführt.
4.1. InternalCalendar
Eine wichtige Erweiterung,
die weder in Repast noch in EInternalCalendar
nergyGrid enthalten war, ist ein
systemweiter Kalender, der die
: InternalCalendar
– InternalCalendar
Zeit mitzählt. Bisher wurde der
–
theCalendar
: GregorianCalendar
zeitliche Fortschritt systemintern
in Ticks angegeben; diese waren
– startYear
: int
jedoch nicht direkt mit einer
– startMonth
: int
Datum-/Uhrzeit-Kombination
– startDay
: int
versehen, auch wenn einige Un– startHour
: int
– startMinute
: int
tersysteme (zum Beispiel die
Klasse GenericPowerConsumer)
– secondsPerTick
: int
bereits intern eine Zeitzählung
implementiert hatten. Die neue
: void
+ step()
Klasse löst dieses Problem.
: InternalCalendar
+ getInstance()
Die Klasse InternalCalen+ getCalendar()
: GregorianCalendar
dar ist ein Repast-Agent, der das
Singleton-Pattern implementiert.
Mit jeder Ausführung seiner
Abb. 6: UML-Klassendiagramm InternalCalendar
Step-Funktion erhöht der Kalender seinen Zeitwert um den
Wert secondsPerTick, der standardmäßig auf 900 Sekunden (15 Minuten) gesetzt ist.
Wie in Abbildung 6 ersichtlich ist, kann der Zeitpunkt, an dem der interne Kalender
zu zählen beginnt, frei konfiguriert werden, ebenso wie das Zeitintervall, das in jedem Tick
hinzuaddiert wird.
Der Kalender ist notwendig für die Wettersimulation, um zu jedem Tick die passenden gespeicherten Wetterdaten laden zu können, auch wenn Einträge der Wetterdatenbank nicht in regelmäßigen Abständen gespeichert sind. Nachdem die Zeit im ganzen System gleich ablaufen sollte, wurde der Kalender allen Teilen der Simulation zur Verfügung
gestellt. Dadurch können Duplikationen vermieden werden, die im schlimmsten Fall sogar
eine Zeit zählen könnten, die von der global simulierten Systemzeit abweicht.
Der interne Kalender ist nicht nur für die Zeitmessung im Gesamtsystem wichtig,
sondern wird auch von der neuen Klasse WeatherStation benötigt.
17
Daniel Jilg
4.2. WeatherStation
Agenten der Klasse WeatherStation implementieren die bereits vorgestellten Konzepte von Wetterstationen, die Daten an den Punkten auf der Karte zur Verfügung stellen,
an denen sie entstanden sind. Sie sind an Stellen in der simulierten Geografie platziert, an
denen Wetterdaten zur Verfügung stehen.
Wie in Abbildung 7 ersichtlich, stellen sie die beiden Funktionen getCurrentWindSpeed() und getCurrentSolarRadiation() zur Verfügung, die Kraftwerke vom Typ
StochasticPowerPlant dazu benutzen können, das Wetter an deren Position zu interpolieren.
WeatherStations greifen
dabei auf Daten zu, die von der
Bayerischen Landesanstalt für
WeatherStation
Landwirtschaft unter [10] im
CSV-Format zur Verfügung ge– name
: String
stellt werden. Innerhalb Schwa– id
: String
bens stehen dabei Daten für 12
– windSpeedData
: List<Double>
Wetterstationen zur Verfügung.
– solarRadiationData
: List<Double>
–
currentWindSpeed
: Double
Jede Wetterstation wird intern
–
currentSolarRadiation
: Double
mit der vom Landesamt zugewiesenen ID-Nummer (hier in
Klammern) angesprochen:
+ step()
: void
+
getCurrentWindSpeed()
: Double
• Frauenriedhausen (32)
+
getCurrentSolarRadiation()
: Double
• Spitalhof (38)
+ getPredictedWindSpeedAt(Date d) : Double
• Weißingen (58)
+ getPredictedSolarRadiationAt
• Schwabmünchen (59)
(Date d)
: Double
• Wallerstein (60)
+ getPredictedWindSpeed
ValuesUntil(Date d)
: List<Double>
• Reschenburg (62)
+
getPredictedSolarRadiation
Neuhof
(99)
•
ValuesUntil(Date d)
: List<Double>
• Ainertshofen (100)
• Gablingen (101)
• Haildenwang (102)
Abb. 7: UML-Klassendiagramm WeatherStation
Lautrach
(103)
•
• Kirchheim (137)
Die Einträge der verfügbaren CSV-Dateien enthalten die folgenden Daten:
1.
Datum und Uhrzeit
2.
Lufttemperatur 200cm über dem Boden in °C
3.
Lufttemperatur 20cm über dem Boden in °C
4.
Bodentemperatur 5cm unterhalb der Oberfläche in °C
5.
6.
7.
Luftfeuchte 200cm über dem Boden in %
18
Daniel Jilg
8.
Windgeschwindigkeit 250cm über dem Boden in m/s
9.
Niederschlag in mm
10.
Globalstrahlung 200cm über dem Boden in Wh/m2
Für jede volle Stunde sind Einträge in den Dateien vorhanden. Bei den Daten handelt
es sich dabei um Mittelwerte von den in der davor vergangenen Stunde gemessenen
Werten. Es ist nicht garantiert, dass jeder Eintrag alle Datenpunkte enthält; fehlende Daten
werden durch einen Punkt ‘.’ repräsentiert.
Bei der Initialisierung der Simulation lädt Repast die Koordinaten und Identifikationsnummern aller Wetterstationen, erstellt WeatherStation-Agenten und weist ihnen diese
Daten zu. Eine WeatherStation versucht daraufhin, eine CSV-Datei deren Dateiname sich
aus ihrer ID ableitet zu finden und zu laden.
Dabei werden zwei Datenwörterbücher der Klasse SortedMap initialisiert und der
Klasse zugewiesen, die jeweils die Daten für Windstärke und Globalstrahlung im Speicher
behalten sollen. Für vorhandene Wind- und Sonnendaten wird beim Durchlauf der CSVDatei jeweils ein Eintrag angelegt, der als Schlüssel den Zeitstempel und als Inhalt den Datenpunkt enthält; leere Einträge werden übersprungen.
In Ihrer Step-Funktion holt sich eine WeatherStation zunächst die aktuelle Zeit aus
dem InternalCalendar. Daraufhin überprüft sie, ob für den erhaltenen Zeitstempel
Wind-Daten vorhanden sind. Wenn ja, wird der entsprechende Wert gespeichert, um ihn
mit Hilfe der getCurrentWindSpeed()-Methode anderen Agenten zur Verfügung stellen zu
können. Ist kein direkter Eintrag für den Zeitstempel im Datenwörterbuch vorhanden, so
wird nach der bereits beschriebenen Formel (1) ein Interpolationswert zwischen dem
vorangegangen und dem nachfolgenden Eintrag gebildet. Für den aktuellen Wert der Sonnenintensität wird analog verfahren.
Die Wettervorhersage wird anderen Klassen über die Funktionen getPredictedWindSpeedAt(Date d), getPredictedWindSpeedValuesUntil(Date d) und ihre analogen
‘SolarRadiation’-Funktionen zur Verfügung gestellt. Die Methode getPredictedWindSpeedAt liefert dazu einen einzelnen Wert zurück, der der Vorhersage für den in d angegebenen Zeitstempel entspricht. Der Rückgabewert wird dabei mit der in oben beschriebenen
Formel (3) errechnet. Analog liefert getPredictedWindSpeedValuesUntil eine Liste von
voraussichtlichen Windgeschwindigkeitsdaten für jeden Tick bis einschließlich dem ersten
Tick nach dem angegebenen Zeitstempel d.
Diese beiden Hauptfunktionen, Wettersimulation und -vorhersage, werden von Solarund Windkraftwerken benutzt. Die beiden Kraftwerkstypen wurden dazu unter dem Überbegriff stochastische Kraftwerke zusammen gefasst.
4.3. StochasticPowerPlant
In Vorbereitung auf die Änderungen im Zuge der Einführung der Wettersimulation
wurde von den Entwicklern des EnergyGrid die Aufteilung der PowerPlant-Klassen in die
Klassen StochasticPowerPlant und DeterministicPowerPlant vorgenommen. Abbildung 8 zeigt die genaue Klassenhierarchie.
19
GenericPowerPlant
Daniel Jilg
StochasticPowerPlant
SolarPowerPlant
WindPowerPlant
– ratedPower
– minimumOutput
– maximumOutput
– currentOutput
– slope
...
: long
: long
: long
: long
: double
: double
+ step()
...
: void
– getWeatherData()
: Vector<double>
Date d)
: Vector<double>
Date d)
...
: Vector<Vector<double>>
BioFuelPowerPlant
GasPowerPlant
HydroPowerPlant
NuclearPowerPlant
DeterministicPowerPlant
StoragePowerPlant
Abb. 8: UML-Klassendiagramm der PowerPlant-Architektur
stellen Kraftwerke dar, deren Stromproduktion mit
Bestimmtheit geplant werden kann, weil sie nicht von wetterbedingten Einflüssen abhängig
sind. Der Durchsatz von StochasticPowerPlants lässt sich dagegen nur in Wahrscheinlichkeiten ausdrücken. Die Klassen SolarPowerPlant und WindPowerPlant stammen von
StochasticPowerPlant ab, während die anderen Kraftwerks-Klassen von DeterministicPowerPlant erben.
Die (abstrakte) Klasse StochasticPowerPlant wird um Code erweitert, der es ihr
erlaubt, die Daten der umliegenden WeatherStations abzufragen. Die anderen KraftwerksKlassen sind unabhängig vom Wetter und benötigen deshalb diese Erweiterung nicht.
Die neu hinzu gekommenen Methoden sind getWeatherData(), getWeatherPredictionAt(Date d) und getWeatherPredictionUntil(Date d).
Erstere erfragt die Wetterdaten aller WeatherStations und verrechnet sie nach der
bereits besprochenen Formel (2) zu Interpolationswerten für die Koordinaten des Kraftwerks. Die errechneten Daten werden dann als Vektor zurück gegeben, der Einträge für
Windgeschwindigkeit und Globalstrahlung enthält.
Die Erweiterbarkeit der Klasse um weitere Funktionen ist damit ebenfalls gegeben.
Sollte später ein weiterer Wert wie zum Beispiel die Windrichtung im System mit berücksichtigt werden, wird getWeatherData() erweitert, so dass entsprechende Daten ebenfalls
an den Vektor angehängt werden.
getWeatherPredictionAt(Date d) ist sehr ähnlich; sie errechnet keine Interpolation
des derzeitigen Wetters, sondern eine der Wettervorhersagen für einen bestimmten Zeitstempel d. Die Methode kommuniziert mit den Methoden getPredictedWindSpeedAt(Date d) und getPredictedSolarRadiationAt(Date d) der WeatherStations, errechnet nach
Formel (2) die entsprechenden Interpolationswerte, und gibt sie als Vektor zurück.
Die Methode getWeatherPredictionUntil(Date d) produziert eine Wertekurve mit
Einträgen für jeden Tick bis einschließlich dem ersten nach dem Zeitstempel d. Dazu ruft
sie die Methoden getPredictedWindSpeedValuesUntil(Date d) und getPredictedSolarRadiationValuesUntil(Date d) aller Wetterstationen auf und errechnet für jeden Eintrag
der daraus erhaltenen Listen nach Formel (2) einen Interpolationswert. Aus den erhaltenen Werten werden neue Listen gebildet, zu einem Vektor zusammengefasst und zurückgegeben.
DeterministicPowerPlants
20
Daniel Jilg
In seiner Step-Funktion holt sich das Kraftwerk über getWeatherData() die Wetterdaten, die es für die Berechnung seiner derzeitigen Produktion braucht. Falls es für die Clusterbildung und -steuerung notwendig ist, kann es eine Kurve mit seiner voraussichtlichen
Produktion (basierend auf der Wettervorhersage) errechnen und ausgeben.
Nachdem die für die Wettersimulation erschaffenen Neuerungen kurz vorgestellt
wurden, sollen jetzt einige der bisher als gegeben betrachteten Thesen untersucht und
bewertet werden.
21
Daniel Jilg
5. Evaluation
Es wurden in der vorliegenden Arbeit Hypothesen aufgestellt, die bis zu diesem Punkt
noch nicht belegt wurden. Beispielsweise dass mit der vorgestellten Interpolationsmethode glaubwürdige Wetterdaten entstehen, oder auch die Hypothese, dass die gezeigte Methode zur Wettervorhersage für die Simulation in ihrem derzeitigem Stadium ausreichend
ist. Diese Behauptungen werden im Folgenden besprochen und anhand der gesammelten
vorliegenden Wetterdaten überprüft.
5.1. Evaluation der räumlichen Interpolationsmethode
Zunächst wird überprüft, wie nahe die von der in Formel (2) beschriebenen Interpolationsmethode produzierten Daten an echt gemessenen Daten liegen. Dafür wird folgende Technik benutzt:
Es wird eine Testumgebung vorbereitet, die im Wesentlichen identisch mit der normalen Simulationsumgebung ist. Alle der Simulation zur Verfügung gestellten Daten sind dabei
die selben wie in der Simulation. Die WeatherStation-Agenten werden so erweitert, dass
sie die Möglichkeit haben, das Wetter an ihrer Position in der simulierten Geografie anhand der exakt selben Methoden wie denen der stochastischen Kraftwerke zu interpolieren.
Die Simulation wird dann für eine signifikante Anzahl an Schritten ausgeführt. In jedem Tick berechnen die modifizierten Wetterstationen zuerst das genaue Wetter aus ihrer Datenbank. Daraufhin ermitteln sie damit Interpolationswerte für Windstärke und
Sonneneinstrahlung an ihrer Position. Die Interpolationswerte werden zusammen mit den
real gemessenen Werten gespeichert.
741
730
694
715
731
738
702
WETTERSTATION
ANFRAGE
DATENPUNKT
INTERPOLATION
Abb. 9: Algorithmus zur Evaluation des räumlichen Interpolationsalgorithmus
Im Beispiel von Abbildung 9 ermittelt der Interpolationsalgorithmus für die Position
der Wetterstation in der Mitte den Globalstrahlungs-Wert von 730. Der errechnete Wert
wird zusammen mit dem tatsächlich an dieser Stelle gemessenen Wert (731) gespeichert.
22
Daniel Jilg
Insgesamt wurden für jede der vorhandenen Wetterstationen jeweils stündliche Datenpunkte für den Zeitraum zwischen 01.01.2009 und 01.09.2010 betrachtet und die darin enthaltenen Werte für Windgeschwindigkeit und Globalstrahlung mit Werten verglichen, die mit Hilfe von Interpolation für den Standort der betrachteten Wetterstation errechnet wurden. Folgende Werte wurden gespeichert und analyisert:
• Interpolation: Der nach Formel (2) berechnete Interpolationswert für den aktuellen Zeitpunkt am Ort der Wetterstation. Dafür wurden die Daten aller Wetterstationen
außer der gerade betrachteten benutzt.
• Messwert: Der tatsächliche Wert für den Zeitpunkt an der betrachteten Wetterstation.
• Unterschied: Die Differenz zwischen Interpolation und Messwert.
• Abstand: Der Absolutwert der Differenz zwischen Interpolation und Messwert.
Aus der Menge der jeweiligen Werte wurden Durchschnitt, Median, Standardabweichung und Varianz ermittelt. Alle errechneten Werte finden sich in tabellarischer Form im
Anhang; die gesamte Datenmenge wird der Arbeit auf CD-ROM beigelegt. (Eine Übersicht aller auf der CD-ROM vorhandenen Daten findet sich im Anhang.)
Werden die Interpolationswerte mit den Messwerten in einem Scatterplot verglichen, ist eine deutliche Korrelation erkennbar (Abb. 10).
Abb. 10: Scatterplots mit den interpolierten Windgeschwindigkeits-Werten (links) und Globalstrahlungs-Werten (rechts)
(x-Achse: Interpolation, y-Achse: Tatsächlicher Wert)
Die Werte für die Windgeschwindigkeit in m/s sammeln sich vor allem im unteren
Drittel der Ursprungsgerade durch den Plot, bilden aber trotzdem eine gut erkennbare
Linie. Dass die Windgeschwindigkeit sich zum Teil recht deutlich von Ort zu Ort unterscheidet, ist an der relativ breiten, runden Form der Hauptmasse des Scatterplots zu erkennen – im Idealfall wäre diese noch etwas schmaler.
Im Durchschnitt liegen die berechneten Abstände zwischen Interpolation und Messwert bei einem annehmbaren Wert von 0,6m/s. Das macht circa 4,7% des Wertebereichs
zwischen 0 und 13,2m/s aus. Im Idealfall wäre die Interpolation der Windstärke etwas genauer, für die Effektivität der Simulation ist die Korrelation aber stark genug.
Bei der Globalstrahlung ist die Korrelation im Scatterplot deutlich stärker erkennbar:
Viele der Werte sind sehr nahe an der Ursprungsgeraden. Die Sonnenintensität ist also
23
Daniel Jilg
besser interpolierbar als die Windstärke, weil sie sich weniger stark zwischen verschiedenen Orten unterscheidet.
Auch die berechneten Abstandswerte zeigen die Genauigkeit der Interpolation: Der
durchschnittliche Abstand zwischen Interpolation und Messung liegt bei etwa 36,6Wh/m2.
Das sind etwa 3,4% des Wertebereichs von 0 bis 1084,7Wh/m2.
Aus diesen Werten heraus ist ersichtlich, dass die vorgestellte Methode der Interpolation des Wetters aus Daten umliegender Wetterstationen für die Simulation geeignet ist.
Im Folgenden wird gezeigt, dass auch die vorgestellte Methode der Wettervorhersage ausreichend gut für ihren Einsatzzweck geeignet ist.
Die in beschriebene Wettervorhersage ist unkompliziert: Sie geht davon aus, dass die
Wertekurven der Wetterdaten von zwei genau 24 Stunden auseinander liegenden Zeitpunkten einander ähnlich genug sind, um eine zuverlässige Vorhersage zu bekommen, indem der aktuelle Wert mit der Steigung der Kurve des vergangenen Werts verknüpft
wird. Auch diese Hypothese soll hier auf die Probe gestellt werden.
Dazu werden die vorliegenden Daten der Wetterstationen betrachtet: Für die Windstärke- und Sonnenintensitätswerte jedes Eintrags werden jeweils Vorhersagen erstellt, die
eine Stunde, drei Stunden und 6 Stunden in die Zukunft reichen. Die Vorhersagen werden
nach Formel (3) berechnet und zusammen mit dem tatsächlichen Wert zum Zeitpunkt
der Vorhersage verglichen.
Es wurden die folgenden Werte errechnet:
• Vorhersage: Der nach o.g. Formel berechnete Erwartungswert für den in der Zukunft liegenden Zeitpunkt.
• Messwert: Der tatsächliche Wert für den Zeitpunkt.
• Unterschied: Die Differenz zwischen Vorhersage und Messwert.
• Abstand: Der Absolutwert der Differenz zwischen Vorhersage und Messwert.
Aus der Menge der jeweiligen Werte wurden Durchschnitt, Median, Standardabweichung und Varianz ermittelt. Alle errechneten Werte finden sich in tabellarischer Form im
Anfang; die gesamte Datenmenge wird der Arbeit auf CD-ROM beigelegt.
Vorhersage der Windgeschwindigkeit
Für die Evaluation der Vorhersage der Windgeschwindigkeit standen knapp über
168.000 Datenpunkte zur Verfügung. Der Wertebereich für die Messwerte lag dabei zwischen 0,0m/s und 13,2m/s.
Abbildung 11 zeigt Scatterplots, die die Vorhersagewerte für die Windgeschwindigkeit
mit den tatsächlichen Messwerten vergleichen. In ihnen ist eine deutliche Korrelation vor
allem in den niedrigen Werten zwischen 0 und 5m/s erkennbar.
24
Daniel Jilg
Abb. 11: Scatterplots mit den vorhergesagten Windgeschwindigkeitswerten (x-Achse) und tatsächlichen Werten (y-Achse)
für 1 Stunde, 3 Stunden und 6 Stunden
Die Werte für Unterschied und Abstand untermauern die Effektivität der Wind-Vorhersage weiter: Selbst bei der sechsstündigen Vorhersage liegt der Median-Abstand zwischen erwartetem Wert und tatsächlichem Messwert nur bei knapp -0,7 m/s oder etwa
4,9% des Wertebereichs. Die gewählte Methode zur Vorhersage der Windgeschwindigkeit
ist damit gut für ihren Verwendungszweck geeignet.
Vorhersage der Globalstrahlung
Die Globalstrahlung wurde anhand von etwa 154.000 verfügbaren Einträgen analysiert. Der Wertebereich für Messwerte lag dabei zwischen 0,0Wh/m2 und 1084,7Wh/m2.
Auch hier wurde eine deutliche Korrelation zwischen Vorhersagewerten und tatsächlichen
Werten gefunden, wie in den Scatterplots (Abb. 12) ersichtlich ist.
Anders als bei den Werten für die Windgeschwindigkeit korrelieren bei den Scatterplots der Sonnenintensitätswerte auch die Werte im mittleren und oberen Drittel des
Wertebereichs.
Abb. 12: Scatterplots mit den vorhergesagten Globalstrahlungswerten (x-Achse) und tatsächlichen Werten (y-Achse)
für 1 Stunde, 3 Stunden und 6 Stunden.
Die Werte für Durchschnitt, Median, Standardabweichung und Varianz sowohl der
Voraussagewerte für Globalstrahlung als auch der gemessenen Werte sind wenig aussagekräftig, da durch den Tag- und Nachtwechsel die entsprechenden Werte stark variieren.
25
Daniel Jilg
Hilfreich sind aber die Unterschieds- und Abstands-Werte, die hier, genauso wie bei der
Vorhersage der Windgeschwindigkeit, äußerst viel versprechend sind:
Der Median des Abstands zwischen erwartetem Wert und gemessenem Wert liegt
selbst für die längste Vorhersage von sechs Stunden bei unter 4Wh/m2; das sind etwa
0,3% des Wertebereichs.
Somit ist auch die Vorhersage der Globalstrahlung für kurze bis mittlere Zeiträume
sehr gut geeignet und kann für die Simulation eingesetzt werden.
26
Daniel Jilg
6. Zusammenfassung und Ausblick
In der vorliegenden Arbeit wurden Varianten zur Interpolation des Simulationswetters
aus realen Wetterdaten untersucht, von denen eine vorschlägt, Wetterdaten direkt in simulierte Kraftwerke einzuspeisen, und eine andere, virtuelle Wetterstationen in das System einzufügen und das Wetter an den Kraftwerksstandorten aus der Gesamtmenge der
Daten zu errechnen. Die zweite der beiden Varianten wurde umgesetzt, da sie eine höhere Genauigkeit aufweist, die vorhandenen Daten besser nutzt und ihr Modell die Realität
besser abbildet. Eine einfache Methode zur Wettervorhersage wurde erläutert.
Relevante Details der Umsetzung wurden vorgestellt; angefangen bei der Einführung
des internen globalen Kalenders und dessen Funktionsweise, über die Implementierung
der Wetterstationen in der WeatherStation-Klasse, bis zu den notwendigen Erweiterungen
an der Architektur der Kraftwerke. Dabei wurden Zusammenhänge zwischen den neuen
Klassen verdeutlicht, deren Zusammenspiel erklärt und ein Einblick in die technischen Überlegungen bei der Programmierung gegeben.
Zur Vorbereitung dafür wurde ein Überblick über die Architektur des EnergyGridProjekts gegeben, das Stromerzeuger und -verbraucher simuliert und Techniken zur autonomen Selbststeuerung von Stromkraftwerken entwickelt. Weiterhin wurden verschiedene Ansätze zur Implementierung einer Wettersimulation für das Projekt besprochen und
vertieft. Die Simulation mit Hilfe von Numerical Weather Prediction wurde verworfen, da
sie einen zu großen Rechenaufwand bedeuten würde und dennoch nicht unabhängig von
realen Wetterdaten existieren könnte.
In der Evaluation wurden wichtige Hypothesen zur räumlichen Interpolation der Wetterdaten und zur Wettervorhersage anhand wissenschaftlicher Methoden überprüft und
deren Ergebnisse genannt; die untersuchten Konzepte wurden für adäquat befunden.
Für die weitere Entwicklung der Wettersimulation im EnergyGrid sind bereits Ideen
vorhanden. So könnte zum Beispiel zusätzlich zur Windstärke auch die Richtung simuliert
werden, in die der Wind bläst. Dieser Wert ist zwar nicht direkt für die stochastischen
Kraftwerke relevant, aber er hat Einfluss auf das Gesamtwetter, denn fast alle Witterungsänderungen verbreiten sich schneller in die Richtung in die der Wind bläst. Selbst die Sonneneinstrahlung wird durch in Windrichtung ziehende Wolken beeinflusst.
Auch sehr interessant wäre die Simulation von Gewitterbildung. Das Auftauchen von
Gewitterwolken hängt mit Lichtverlust (die Sonne wird verdeckt), Temperaturverlust (gerade wenn es auch noch regnet) und starken Windböen zusammen. Diese Änderungen
können zum Teil sehr schnell passieren und wären gerade für die Vorhersage eine Bereicherung.
Eine gute Veränderung an der Struktur der Software wäre möglicherweise die Auslagerung des Codes zur Wetter-Interpolation an bestimmten Koordinaten aus der StochasticPowerPlant-Klasse in die WeatherStation-Klasse. Dort wäre er aus logischer Sicht besser
untergebracht und könnte auch von anderen Teilen des Systems genutzt werden.
Schließlich soll noch eine Idee für ein komplett neues Feature vorgestellt werden: Die
Visualisierung des Wetters auf den von Repast zur Verfügung gestellten Kartenansichten.
Dabei könnten Icons auf der Karte platziert werden, die die verschiedenen Wetterzustände symbolisieren – viel Sonne, wenig Sonne, viel Wind, wenig Wind, und so weiter. Eine
27
Daniel Jilg
aufwändigere Lösung könnte die Karte verschieden einfärben und sie zum Beispiel je nach
Sonnenintensität aufhellen oder abdunkeln.
Abschließend lässt sich festhalten, dass die in das EnergyGrid eingefügte Wettersimulation und -vorhersage die Nützlichkeit des Systems deutlich erhöht. Sie stellt einen Realitätsbezug her, indem sie echte Wetterdaten benutzt. Außerdem ermöglicht sie es, Algorithmen und Theorien zum Ausgleich von Stromschwankungen zu erproben und zu verbessern. Da sich die vorgestellten Algorithmen und Techniken in der Theorie als geeignet
und durchführbar erwiesen haben, wäre es auch durchaus interessant, sie in der Realität
auf Praxistauglichkeit zur prüfen.
28
Daniel Jilg
7. Anhang
7.1. Evaluation der räumlichen Interpolation
Interpolation der Windgeschwindigkeit in m/s
Messwert Min: 0,000, Max: 13,200
Durchschnitt
Median
Std.abweichung
Varianz
Interpolation
1,2376
1,0421
0,8765881
0,7684066
Messwert
1,381
1,100
1,2370330
1,530251
Unterschied
-0,1430
-0,0089
0,8744778
0,7647114
Abstand
0,6237
0,4347
0,6293852
0,3961257
Interpolation der Globalstrahlung in Wh/m2
Messwert Min: 0.000, Max: 1084,7
Durchschnitt
Median
Std.abweichung
Varianz
105,1305
7,3745
164,72925
27135,73
Messwert
130,5
8,300
208,19147
43343,69
Unterschied
-25,41
-0,004457
79,98448
6397,517
36,6063
2,4677
75,51760
5702,908
Interpolation
Abstand
Vorhersage der Windgeschwindigkeit in m/s, eine Stunde
Durchschnitt
Median
Std.abweichung
Varianz
Vorhersage
1,5214
1,0286
1,826714
3,336886
Messwert
1,382
1,100
1,238033
1,532726
Unterschied
-0,1396
0,0000
1,337558
1,789061
Abstand
0,6049
0,3132
1,201082
1.442.598
29
Daniel Jilg
Vorhersage der Windgeschwindigkeit in m/s, drei Stunden
Durchschnitt
Median
Std.abweichung
Varianz
Vorhersage
1,7326
1,000
3,053706
9,325122
Messwert
1,382
1,100
1,238020
1,532693
-0,3509
0,0000
2,772605
7,687339
1,038
0,500
2,594884
6,733422
Unterschied
Abstand
Vorhersage der Windgeschwindigkeit in m/s, sechs Stunden
Durchschnitt
Median
Std.abweichung
Varianz
Vorhersage
1,9517
0,9154
4,325997
9,325122
Messwert
1,382
1,100
1,238064
1,532801
-0,57007
0,01429
4,110818
16,89883
1,430
0,650
3,896068
15,17935
Unterschied
Abstand
Vorhersage der Globalstrahlung in Wh/m2, eine Stunde
Durchschnitt
Median
Std.abweichung
Varianz
Vorhersage
140,9
6,545
521,1447
271591,8
Messwert
130,6
8,4
208,2137
43352,95
Unterschied
-10,28
0,000
473,9485
224627,1
Abstand
43,92
1,843
472,0210
222803,8
Vorhersage der Globalstrahlung in Wh/m2, drei Stunden
Durchschnitt
Median
Std.abweichung
Varianz
Vorhersage
153,9
3,3
978,6751
957805
Messwert
130,7
8,4
208,2713
43376,92
Unterschied
-23,21
0,000
949,8708
902254,6
Abstand
76,00
2,80
947,1100
897017,3
30
Daniel Jilg
Vorhersage der Globalstrahlung in Wh/m2, sechs Stunden
Durchschnitt
Median
Std.abweichung
Varianz
Vorhersage
146,4
1,794
1055,1166
1113271
Messwert
130,8
8,5
208,3539
43411,35
Unterschied
15,63
0,000
1031,5513
1064098
Abstand
10,20
3,320
1026,6112
1053931
7.3. Inhalt der beigelegten CD-ROM
Dieser Arbeit ist eine CD-ROM beigelegt, die den erstellten Programmcode, die Wetterdaten und die aus den Wetterdaten errechneten statistischen Daten enthält. Im Folgenden werden Einstiegshilfen für den Programmcode gegeben und die Organisation der
Daten erklärt.
Wetterdaten und daraus errechnete statistische Daten
Die Wetterdaten befinden sich im Verzeichnis Wetterdaten auf der CD-ROM. Sie sind
als CSV-Dateien gespeichert, wobei die Dateinamen folgende Zuordnung haben:
Dateiname
Wetterstation
Koordinaten N
Koordinaten O
32.csv
Frauenriedhausen
48,3601
10,2416
38.csv
Spitalhof
47,4403
10,2011
58.csv
Weißingen
48,2708
10,0916
59.csv
Schwabmünchen
48,1052
10,4632
60.csv
Wallerstein
48,5249
10,3005
62.csv
Reschenberg
48,1358
10,2101
99.csv
Neuhof
48,4709
10,4710
100.csv
Ainertshofen
48,3125
11,0526
101.csv
Gablingen
48,2738
10,5000
102.csv
Haldenwang
48,2637
10,2828
103.csv
Lautrach
47,5429
10,0708
137.csv
Kirchheim
48,1056
10,2809
31
Daniel Jilg
Weiterhin werden die errechneten statistischen Daten in den folgenden Dateien mit
geliefert:
Dateiname
Inhalt
interpolation_7.csv
Daten für die räumliche Interpolation der Windgeschwindigkeit.
interpolation_9.csv
Daten für die räumliche Interpolation der Globalstrahlung.
prediction7.csv
Daten für die Vorhersage der Windgeschwindigkeit
prediction9.csv
Daten für die Vorhersage der Globalstrahlung
Einträge in den Dateien
bei das Format
interpolation_7.csv
und
interpolation_9.csv
haben da-
(interpolierter Wert), (tatsächlicher Wert), (Differenz), (Abstand)
Einträge in den Dateien prediction7.csv und prediction9.csv haben das Format
(Vorhersage um 1 Stunde), (tatsächlicher Wert), (Differenz), (Abstand),
(Vorhersage um 3 Stunden), (tatsächlicher Wert), (Differenz), (Abstand),
(Vorhersage um 6 Stunden), (tatsächlicher Wert), (Differenz), (Abstand)
Für die Automatisierung des Downloads der Wetterdaten und der Berechnung der
Statistikdaten werden Skripte bereit gestellt. Diese sind darauf ausgelegt, in einer UnixUmgebung mit installiertem Interpreter für die Programmiersprache Python ausgeführt zu
werden.
download_data.sh lädt die für die statistische Berechnung notwendigen Wetterdaten
von der Webseite der Bayerischen Landesanstalt für Landwirtschaft [10] herunter und
speichert sie in CSV-Dateien. Die entstehenden Daten sollten mit den Dateien 32.csv bis
137.csv identisch sein.
calculate_data.sh führt die statistischen Berechnungen zur Evaluation für die Dateien 32.csv bis 137.csv aus. Als Ergebnis werden die oben erklärten Dateien
interpolation_7.csv, interpolation_9.csv, prediction7.csv und prediction9.csv
erstellt.
Programmcode des EnergyGrid
Im Verzeichnis EnergyGrid auf der CD-ROM befindet sich eine Version des EnergyGrid-Projekts zum Zeitpunkt der Abgabe der Arbeit. Sie enthält den erschaffenen Programmcode für die Wettersimulation und -vorhersage, inclusive der neu erstellten Klassen
WeatherStation.java, InternalCalendar.java und StochasticPowerPlant.java.
Zur Ausführung des Programmcodes wird das Framework Repast Simphony benötigt. Es kann unter [2] heruntergeladen werden. Eine Installationsanleitung für verschiedene
Betriebssysteme findet sich unter [11].
Nach der Installation kann das Projekt in Repast geladen werden. Dazu wird zunächst
das Verzeichnis EnergyGrid von der CD-ROM auf einen beschreibbaren Datenträger kopiert. Dies ist notwendig, da EnergyGrid diverse temporäre Dateien anlegt, die auf der
CD-ROM nicht gespeichert werden könnten.
32
Daniel Jilg
Daraufhin wird die Software gestartet und der Befehl File → Import aufgerufen. Als
Import Source wird Existing Projects into Workspace ausgewählt und der Next-Button betätigt. In der darauf erscheinenden Ansicht wird mit dem Browse-Button ein DateimanagerFenster geöffnet. Das auf den beschreibbaren Datenträger kopierte EnergyGrid-Verzeichnis wird ausgewählt und die Auswahl bestätigt. Der Finish-Button wird betätigt. Damit ist
das Projekt in Repast geladen.
Zur Ausführung des Projekts muss nun der entsprechende Launcher ausgeführt werden. Dazu muss im Package Explorer am linken Bildschirmrand der Baum soweit geöffnet
werden, dass die Datei energygrid/launchers/Run energygrid Model.launch sichtbar
wird. Mit einem Rechtsklick der Datei wird das Kontextmenü aufgerufen und der der Befehl Run As → Run energygrid Model aufgerufen. Damit wird die Repast-Simulationsumgebung gestartet und das EnergyGrid-Projekt erscheint.
Um im laufenden Projekt die Simulation zu starten, muss nun im Menü der Befehl Run
→ Start gewählt werden. Daraufhin werden die Modelle initialisiert und der Tick-Zähler in
der oberen rechten Bildschirmecke wird für jeden Tick erhöht. Über die Tabs am unteren
Bildschirmrand können verschiedene Ansichten zur Visualisierung der Agenten im EnergyGrid ausgewählt werden.
33
Daniel Jilg
8. Quellen
[1] Prof. Dr.-Ing. C. Müller-Schloer. Organic Computing – On the Feasibility of Controlled
Emergence. 2004
[2] Repast Simphony. http://repast.sourceforge.net/, Dezember 2010
[3] R. G. Barry und R. J. Chorley. Atmosphere, Weather and Climate. Routledge, London,
2003.
[4] S. Emeis. Meteorologie in Stichworten. Hirt's Stichwortbücher. Borntraeger, Stuttgart,
2000.
[5] H. Malberg. Meteorologie und Klimatologie. Eine Einführung. Springer, Berlin, 2002.
[6] Jean Meeus. Astronomische Algorithmen. Barth, Leipzig, 1992.
[7] P. Tisler. Aspects of weather simulation by numerical process. Universität Helsinki, 2006.
[8] C. Rigollier, O. Bauer, und L. Wald. On The Clear Sky Model of the ESRA – European
Solar Radiation Atlas – With Respect to the Heliosat Method. Solar Energy,
68(1):33–48, 2000.
[9] I. Reda und A. Andreas. Solar position algorithm for solar radiation applications.
National Renewable Energy Laboratory, 2008.
[10] Bayerische Landesanstalt für Landwirtschaft. Agrarmeteorologisches Messnetz
Bayern, http://www.lfl.bayern.de/agm/agmlkr.php#sch, Dezember 2010
[11] Repast Simphony Downloads, http://repast.sourceforge.net/download.html
Dezember 2010
34

Bachelorarbeit

Transcrição

Documentos relacionados

Wetterstation in Göllheim

Besuch bei der ZAMG

plecs workshop

Wetterseiten im Internet

Hilfe zur Wetterstation

plexim Workshop: Simulation of Power Electronic Systems with PLECS

SAP Newsletter

Wetterdaten direkt von der Streif

"STELLA MAX" (WD 6003)

FDS_Handbuch_Inhaltsverzeichnis 1