Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Apr-14Seite 1 von 23 Simulation der Ausbreitung radioaktiver Schadstoffe Software Engineering.

Ähnliche Präsentationen


Präsentation zum Thema: "W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Apr-14Seite 1 von 23 Simulation der Ausbreitung radioaktiver Schadstoffe Software Engineering."—  Präsentation transkript:

1 W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Apr-14Seite 1 von 23 Simulation der Ausbreitung radioaktiver Schadstoffe Software Engineering

2 Inhalte der Vorlesung W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Apr-14Seite 2 von 23 Ziele und Kontext von Ausbreitungsrechnungen Ausbreitungsphänomene, Modellierung physikalischer Prozesse Freisetzung, Zerfall Topographie, Geländemodelle, Koordinatensysteme Windfeldmodelle Transportmodelle Dosisberechnung, chemische Prozesse in der Atmosphäre Simulationssysteme Softwareparadigmen / Frameworks Werkzeuge zur Modellierung (UML) Architektur von ABR_V2.0 Modelle in der ABR_V2.0 Benchmarks / Validierung

3 Software Paradigmen, Frameworks Traditionell –Anforderungen sind zu Projektbeginn schwierig zu fomulieren –Änderung der Anforderungen während des Projekts sind aufwendig –Die Anzahl überflüssiger bzw. ungenutzter Merkmale –Eine schlechte, fehlende, schwer verständliche oder zu umfangreiche Dokumentation –Ein schwer verständlicher oder unflexibler Entwurf –Fehlende Regressionstests –Ein schwerfälliges Gesamtsystem Extreme Programming –Die testgetriebene Entwicklung sorgt für ein ausreichendes Vorhandensein von Regressions- tests und eine verbesserte Testbarkeit der Software –Das ständige Refactoring führt zur Fehlerbeseitigung, einem leicht verständlichen und flexiblen Entwurf sowie guter Dokumentation –Die kontinuierliche Integration erfordert zwangsläufig ein leichtgewichtiges Gesamtsystem –Um die zu entwickelnde Funktionalität zu bestimmen, und zwischen Kunde und Entwicklungsteam auszuarbeiten, werden User-Storys eingesetzt W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 3 von xx

4 Software Paradigmen, Frameworks Extreme Programming –Charakteristika »Iterativ inkrementelles Vorgehen »Teamarbeit »Einbeziehung des Kunden (Auftraggebers) »Das Lösen einer Programmieraufgabe steht im Vordergrund der Softwareentwicklung und einem formalisierten Vorgehen geringere Bedeutung zumisst »XP folgt einem strukturierten Vorgehen und stellt die Teamarbeit, Offenheit und stete Kommunikation zwischen allen Beteiligten in den Vordergrund »Kommunikation ist dabei eine Grundsäule –Komponenten »Werte »Prinzipien »Praktiken Name Universität Stuttgart - 1XX-123 – Modulthema - Apr-14Seite 4 von xx

5 Software Paradigmen, Frameworks Extreme Progamming –Werte » Kommunikation »Einfachheit »Rückmeldung »Mut und »Respekt W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 5 von xx

6 Software Paradigmen, Frameworks Extreme Programming –Werte »Das Team kommuniziert stetig, um Informationen auszutauschen »stetigen Austausch aller Beteiligten, also auch zwischen dem Entwicklungsteam und dem Kunden »Es kommen auch Personen zu Wort, die in einer gerade diskutierten technischen Aufgabenstellung keine Experten sind »Stetige Kommunikation mit dem Kunden, Aufnahme seines Feedbacks und Erfüllung seiner Wünsche »Die Kommunikation zeichnet sich ferner durch einen respektvollen Umgang aus, sowohl im Team untereinander als auch mit dem Kunden »Die Entwickler sollen mutig sein und die Kommunikation offen gestalten »Es soll die einfachste Lösung für eine Problemstellung umgesetzt werden »In jeder Iteration konzentriert sich das komplette Team genau auf die momentan umzusetzenden Anforderungen Name Universität Stuttgart - 1XX-123 – Modulthema - Apr-14Seite 6 von xx

7 Software Paradigmen, Frameworks Extreme Programming –Prinzipien »Menschlichkeit »Wirtschaftlichkeit »Beidseitiger Vorteil »Selbstgleichheit »Verbesserungen »Vielfältigkeit »Reflexion »Lauf »Gelegenheiten wahrnehmen »Redundanzen vermeiden »Fehlschläge hinnehmen »Qualität »Kleine Schritte sowie »Akzeptierte Verantwortung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 7 von xx

8 Software Paradigmen, Frameworks Extreme Programming –Prinzipien »Software wird von Menschen entwickelt. Menschen bilden also den Faktor, dem laut XP besondere Aufmerksamkeit gilt. »Durch Schaffung einer menschlichen Atmosphäre soll den Grundbedürfnissen der Entwickler (Sicherheit, Vollendung, Identifikation mit der Gruppe, Perspektive und Verständnis) entsprochen werden. »Die Wiederverwendung bestehender Lösungen, ist wichtig. »Aus Feedback und selbst gewonnenen, neuen Erkenntnissen wird die Lösung stetig verbessert. »Verschiedene Meinungen werden nicht nur geduldet sondern sogar gefördert. Dazu muss ein Konfliktmanagement etabliert werden. »Die Lauffähigkeit der Software muss zu jedem Zeitpunkt garantiert sein (Lauf). W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 8 von xx

9 Software Paradigmen, Frameworks Extreme Programming –Prinzipien »Ein offener, konstruktiver Umgang mit den Herausforderungen der Softwareentwicklung gelingt umso besser, je mehr alle Beteiligten bereit sind, ihre Verantwortung zu akzeptieren. »Qualität Steht im Gegensatz zu anderen Faktoren wie Ressourcen, Funktionsumfang oder Endtermin nicht zur Diskussion Diese Grundeinstellung unterscheidet sich von vielen anderen Methoden der Softwareerstellung ist allerdings wichtig, um das Produkt einsatzfähig, fehlerfrei und erweiterbar zu halten. Vermeidung von Redundanzen (unnötig mehrfach oder wiederholt ausgeführte oder auch manuell ausgeführte automatisierbare Schritte) W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 9 von xx

10 Software Paradigmen, Frameworks Extreme Programming –Prinzipien »Durch schnelle, kleine Schritte bleibt das Team flexibel Kann sich schnell neuen Rahmenbedingungen anpassen und auf Feedback eingehen. Die negativen Folgen eines einzelnen kleinen, nicht erfolgreichen Schrittes können wesentlich schneller durch einen neuen Schritt kompensiert werden. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 10 von xx

11 Software Paradigmen, Frameworks Extreme Programming –Praktiken »Organisation »Anforderungsmanagement »Planung »User-Stories »Aufwandabschätzung »Entwicklung und Abschluss W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 11 von xx

12 Software Paradigmen, Frameworks Extreme Programming –Praktiken: Anforderungsmanagement »Der Umgang mit den Anforderungen und deren Verwirklichung ist eine zentrale Komponente XPs. »Es wird auf eine vollständige Erhebung aller Anforderungen zu Beginn des Projektes verzichtet. »Stattdessen werden die sich erst im Laufe der Umsetzung ergebenden Anforderungen berücksichtigt. »Anforderungen werden nicht selten zunächst als Prototypen bereitgestellt. Dabei handelt es sich um Versionen, die noch nicht die volle, endgültige Funktionalität besitzen. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 12 von xx

13 Software Paradigmen, Frameworks Extreme Programming –Praktiken: Planung »Änderungskostenkurve Bei XP weitgehend linear Name Universität Stuttgart - 1XX-123 – Modulthema - Apr-14Seite 13 von xx

14 Software Paradigmen, Frameworks Extreme Programming –Praktiken: Planung »Die innerhalb der Iterationen umzusetzenden einzelnen Neuerungen werden mit dem Kunden durch User Stories, einer schlankeren Form der Anwendungsfälle (Use Cases), beschrieben. »User Stories beschreiben die Funktionsanforderungen an ein System aus Sicht eines Akteurs. »Eine User Story folgt dem Muster: Als x kann ich y tun, um z zu erreichen. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 14 von xx

15 Software Paradigmen, Frameworks Extreme Programming –Praktiken : Planung »User-Storys und Iterationen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 15 von xx

16 Software Paradigmen, Frameworks Extreme Programming –Pratiken: Planung »Den User Storys werden Prioritätswerte zugeordnet. »Team und Kunde klären: welche User Storys das höchste Risiko hinsichtlich Zeitplan, Funktionalität und Kosten haben welche User Storys dem Produkt den höchsten, respektive den niedrigsten Mehrwert bieten »Das Release sollte mit den User Storys begonnen werden, die das höchste Risiko und den höchsten Nutzen auf sich vereinen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 16 von xx

17 Software Paradigmen, Frameworks Extreme Programming –Praktiken: Aufwandsabschätzung »User-Storys werden gewöhnlich in Story-Points abgeschätzt »Story-Points sind relative Aufwandsabschätzungen, also der Entwicklungsaufwand für eine Story im Vergleich zu anderen »Es wird vom ganzen Team, in mehreren Runden, in einem Planning-Game eine Punkteanzahl für die User-Storys geschätzt. »User-Storys werden zu Beginn der Iteration in feinkörnige, technische Arbeitspakete (Tasks) zerlegt »Das Team führt diese Zerlegung durch und schätzt die Dauer eines jeden Tasks. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 17 von xx

18 Software Paradigmen, Frameworks Extreme Programming –Praktiken: Entwicklung und Abschluss »Es gibt eine tägliche kurze Besprechung (Stand-up Meeting), Jeder Entwickler berichtet, was er am Vortag geleistet hat, wo es gegebenenfalls Probleme gab und was er heute leisten möchte. Ferner werden situationsabhängig Arbeitspaare gebildet (Pair- Programming). Im Laufe des Tages findet, während die Entwickler die Funktionalität und die Tests programmieren, weiterer stetiger Austausch (Pair- Negotiations) statt. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 18 von xx

19 Software Paradigmen, Frameworks Extreme Programming –Praktiken: Entwicklung und Abschluss »Kann eine User-Story in einer Iteration nicht abgeschlossen werden, zum Beispiel weil die Tests nicht erfolgreich waren oder sich die Abschätzung als zu knapp beziehungsweise der Umfang als zu groß herausgestellt hat so wird sie gewöhnlich in mehrere kleinere aufgeteilt oder komplett in die nächste Iteration verschoben. »Auch während einer Iteration kann sich, durch sich ändernde Prioritäten des Kunden oder durch neue Erkenntnisse, an der Zusammenstellung der Iteration etwas ändern. »Ist die Iteration abgeschlossen, schauen sich Vertreter des Managements, der Kunde (Akzeptanztest) oder andere Personen, die an dem Produkt Interesse haben, das Produkt in der aktuellen Ausbaustufe an und geben Rückmeldungen. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 19 von xx

20 Software Paradigmen, Frameworks Extreme Programming –Hauptpraktiken »Räumlich zusammen sitzen »Informativer Arbeitsplatz »Team »Pair-Programming »Energievolle Arbeit »Entspannte Arbeit »Zyklen Wöchentlicher Zyklus Quartalsweiser Zyklus 10-Minuten-Build »Kontinuierliche Integration »Test-First-Programmierung und Inkrementelles Design. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 20 von xx

21 Software Paradigmen, Frameworks Extreme Programming –Praktiken W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 21 von xx

22 Software Paradigmen, Frameworks Extreme Programming –Zeitliche Aufteilung Name Universität Stuttgart - 1XX-123 – Modulthema - Apr-14Seite 22 von xx

23 W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 23 von xx

24 Software Paradigmen, Frameworks Framework –"Ein Framework ist eine Anzahl wiederverwendbarer Klassen mit einer Systemarchitektur zur Erstellung von Anwendungen. » Es stellt den Königsweg dar: ein kompletter und geprüfter Entwurf samt Implementierung von Basisfunktionalität kann wiederverwendet werden. –Ein Framework besteht also aus einer Menge von zusammenarbeitenden Klassen, die einen wiederverwendbaren Entwurf für einen bestimmten Anwendungsbereich implementieren. »Es besteht aus konkreten und insbesondere aus abstrakten Klassen, die Schnittstellen definieren. »Im allgemeinen wird vom Anwender (=Programmierer) des Frameworks erwartet, dass er Unterklassen definiert, um das Framework zu verwenden und anzupassen. Name Universität Stuttgart - 1XX-123 – Modulthema - Apr-14Seite 24 von xx

25 Software Paradigmen, Frameworks Framework –Beziehung zwischen Komponenten, Pattern und Framework »Eine Komponente kann in mehreren Patterns und Frameworks implementiert werden und ein Pattern oder ein Framework kann durch mehrere Komponenten implementiert werden. »Ein Framework kann mehrere Pattern enthalten und bietet Extension Points an »Erweiterungsstellen beschreiben, wo und wie das Framework zu erweitern ist, damit das Framework im Kontext einer konkreten Anwendung eingesetzt werden kann. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 25 von xx

26 Software Paradigmen, Frameworks Framework –White-Box Frameworks, Wiederverwendung und Erweiterung durch Vererbung –Black-Box Frameworks, Wiederverwendung und Erweiterung durch Aggregation W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 26 von xx

27 Software Paradigmen, Frameworks Framework –Vorgehensweise »Identifiziere die spezifische(n) Domäne(n), wo das Framework angewandt werden soll. »Definiere Use Cases (Anwendungsfälle), welche das Framework erbringen soll. »Identifiziere bekannte Akteure, welche mit dem Framework agieren sollen. »Identifiziere Patterns oder andere geprüfte Lösungen, welche die Framework-Entwicklung unterstützen sollen. »Entwerfe Schnittstellen und spezifiziere Komponenten des Frameworks. »Implementiere die Schnittstellen des Frameworks prototypisch. »Beschreibe und dokumentiere Erweiterungsstellen. »Schreibe Prüfspezifikationen und plane den Entwicklungsprozess. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 27 von xx

28 ABR V2.0 Motivation –Frage der Ausfallsicherheit –Änderung der Anforderungen –Notfallschutz –Einsatz als Werkzeug –Einbindung neuer Modelle –Verkürzte Messzyklen (im Ereignisfall) –Vereinfachung der Wartungs- und Pflegearbeiten –Erweiterungen im Laufe der Zeit –Separate Subsysteme (RIMPUFF) –Verbesserte Integration von ABR und ABR-Research Name Universität Stuttgart - 1XX-123 – Modulthema - Apr-14Seite 28 von xx

29 ABR V2.0 Anforderungen –Erhöhung der Ausfallsicherheit –Flexibilisierung des Systems –Robuste aber offene Architektur –Verteilung –Persistenz –Zugangs- und Zugriffskontrolle –Performanz –Erweiterbar –Leicht wartbar W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 29 von xx

30 ABR V2.0 Ausgangslage: –Reihe von physikalischen Prozessen »Makroskopischen Ebene Freisetzung Transport Ablagerung »Detailebene Radioaktiver Zerfall Chemische Reaktionen Washout, rainout Turbulenz Bodeneinfluss Name Universität Stuttgart - 1XX-123 – Modulthema - Apr-14Seite 30 von xx

31 ABR V2.0 Rahmenbedingungen: –Einbindung in eine bestehende Infrastruktur »Systemumgebung Rechner Betriebssystem Netzwerk »Organisation Wer darf wann was –Integration von Altlasten »Bestehende Komponenten W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 31 von xx

32 ABR V2.0 Framework DiSiF Name Universität Stuttgart - 1XX-123 – Modulthema - Apr-14Seite 32 von xx Logische Struktur Physikalische Struktur

33 ABR V2.0 Name Universität Stuttgart - 1XX-123 – Modulthema - Apr-14Seite 33 von xx Framework DiSiF –Sessions »Authentifizierung »Verwaltung, Zuweisung der Benutzerrollen »Verfügbare Simulationsressour cen anzeigen –Simulations »Verwaltung der auf der Ebene darunter liegenden workflows

34 ABR V2.0 Name Universität Stuttgart - 1XX-123 – Modulthema - Apr-14Seite 34 von xx Framework DiSiF –Workflows »Verwaltung der auf der Ebene darunter liegenden ausführbaren Programme, Module –Calculation Services »Verfügbare Programme, Module

35 ABR V2.0 Name Universität Stuttgart - 1XX-123 – Modulthema - Apr-14Seite 35 von xx Framework: DiSiF –Ressourcenanbieter »Schnittstelle zwischen den Schichten durch Web- Services »Netzwerkschnittstelle zwischen Workflow-Ebene und der darunterliegenden Hardware »Einheitliche Schnittstelle zwischen den Klienten und der Klientenschicht

36 ABR V2.0 Framework: DiSiF –XML-Schema zur Beschreibung aller Eingabedaten –Idee im Rahmen des letzten KEWA-Projekts –Von unterschiedlichen Klienten nutzbar »KFÜ-Klient –Erlaubt die Erweiterung des Kontexts der Anwendung »Für die Lehre »Für Forschungsarbeiten –Eingabedaten können mit Vorschlagswerten vorbelegt werden –Klare Zuordnung von Eingabedaten zu einer Simulation –Leicht erweiterbar Name Universität Stuttgart - 1XX-123 – Modulthema - Apr-14Seite 36 von xx

37 ABR V2.0 Modularisierung der physikalischen Prozesse –Module durch Altsystem vorgegeben –Module sind in sich abgeschlossene lauffähige Einheiten »WINDOWindfeldmodul »MCFWindfeldmodul »PASModul zur Berechnung des Partikeltransports »AIRDOSModul zur Berechnung der Gammasubmersion »DOSEModul zur Dosisberechnung –Zeitintegration erfolgt auf Modulebene »Vorwärts verkettetes System »Keine Rückkopplung Name Universität Stuttgart - 1XX-123 – Modulthema - Apr-14Seite 37 von xx t + t WINDOPASAIRDOSDOSE t

38 ABR V2.0 Anforderungen an die ABR-Module –Hinsichtlich Ausfallsicherheit –Hinsichtlich Lauffähigkeit im Cluster oder Grid –Module ohne Gedächtnis »Können im nächsten Zeitschritt auf andere Rechner verlagert werden »Simulationsrechnungen können nach jedem Zeitschritt gestoppt und neu gestartet werden W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 38 von xx

39 ABR V2.0 Ablaufsteuerung –Ptolemy II Workflow Engine »Ablaufsteuerungssystem für wissenschaftliche Abläufe (Workflows) »Akteur-orientierte Kontroll- und Datenflussmodellierung »Bietet mehrere Technologien zur Ablaufsteuerung an Synchronous Data Flow (SDF) Continuous Time (CT) Discrete Event (DE) Etc. »Visuelle Entwicklungsumgebung »Ausgereiftes System W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 39 von xx

40 ABR V2.0 Ptolemy: Einsatzbereich der Workflow Engine W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 40 von xx

41 ABR V2.0 W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 41 von xx Akteure Ein- und Ausgabeports Kapseln z.B. Rechencodes ein Hierarchische Einkapselung Atomarer Akteur C Daten Ablaufsteuerung Token Atomarer Akteur D Atomarer Akteur A Atomarer Akteur B Ptolemy: Akteurorientierte Modellierung

42 ABR V2.0 Ptolemy: Descrete Event Director W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 42 von xx –Ereignis: »Modul n hat zu Ende gerechnet –Reaktion: »Modul n+1 fängt an zu rechnen Regeln für Simulationen mit diskreten Ereignissen Ereignisse werden erzeugt Auf Ereignissen wird reagiert DE Director WINDOPAS AIRDOS …DOSE

43 ABR V2.0 Ptolemy: Nutzung der Semantik von Workflows –Prozesspipeline auf mehreren Prozessoren (Multicore) oder Rechner (Rechencluster oder Grid) verteilt »Rechenzeit / Zeitschritt bis zu 4x beschleunigt »Geringer Entwicklungsaufwand »Großer Kommunikationsmehraufwand in Rechencluster und Grids W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 43 von xx Zeitschritt / parallele Prozesse Zeit A = WINDO, B = PAS, C = AIRDOS, D = DOSE Zeit Ohne Pipeline Mit Pipeline Rechenzeit / Zeitschritt = max{A,B,C,D} + I/O Mehraufwand + Störungen (z.B. Prozesse anderer Benutzer)

44 ABR V2.0 Ptolemy: Umsetzung des ABR-Workflows –Kombination von standard- und benutzerdefinierten Akteuren –Fachspezifische Benutzerbibliothek (z.B. für Ausbreitungsrechnungen) –Ptolemy II Workflows können als Java-Klassen exportiert werden W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 44 von xx

45 ABR V2.0 Aspektorientierte Programmierung –Aspektorientierte Programmierung (AOP) ist eine Methode der Softwareentwicklung, die anstrebt, verschiedene logische Aspekte einer Anwendung getrennt voneinander zu entwerfen, zu entwickeln und zu testen –Die getrennt entwickelten Aspekte werden dann zur endgültigen Anwendung zusammengefügt –Übergreifende Aspekte »z.B. Persistenz, Verteilung, Ausfallsicherheit, Zugangs- und Zugriffskontrolle W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 45 von xx

46 ABR V2.0 Aspektorientierte Programmierung Warum –Aspekt- und Kernfunktionen sind im Quellcode verwoben –Redundanter, schwer verständlicher und schwer änderbarer Quellcode Ziel –Trennung der Aspekte von der Kernfunktionalität (separation of concerns) –Entwicklung, Wartung und Testen werden getrennt durchgeführt –Schnittstellen zwischen Kern- und Aspektfunktionen basieren auf Metadaten W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 46 von xx

47 ABR V2.0 Aspektorientierte Programmierung –Traditionelle Programmierung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 47 von xx f: Kernfunktionalität g: Zugangskontrolle

48 ABR V2.0 Aspektorientierte Programmierung –Trennung von Kern- und Aspektfunktionalität W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 48 von xx Umsetzung des Zugangskontrollaspektes Kernmodul Aspektmodul Schnittstellen zwischen Kern- und Aspektfunktionalität werden durch Annotations (Metadaten) realisiert

49 ABR V2.0 Modelle –Topographie »CRETOPO: Topographie in kartesischen Koordinaten »KART-GELF: Umrechnung in geländefolgende Koordinaten –Quellterm »INVENTAR: Erstellen des Nuklidinventars »FREI: Bestimmung des Nuklidvektors und der Aktivitätsraten –Windfeldberechnung »WINDO: Berechnung in kartesischen Koordinaten, divergenzfrei und massenkonsistent »MCF: Berechnung in geländefolgenden Koordinaten, divergenzfrei und massenkonsistent –Regenfelder »FLAECHINT: Berechnung der Regenmenge in jeder Masche, auch inhomogene Verteilung möglich W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 49 von xx

50 ABR V2.0 Modelle: –Simulation des Transports radioaktiver Partikel »PRWDA: Lagrange-Monte-Carlo Verfahren, kartesisch »PAS: Lagrange-Monte-Carlo Verfahren, geländefolgend –Dosis »AIRDOS:Bestimmung der Gamma-Submersion »DOSE: Bestimmung der Gamma-Bodenstrahlung, Inhalation, Schilddrüsendosis und Gesamtdosis W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 50 von xx

51 ABR V2.0 Modellgrenzen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 51 von xx

52 ABR V2.0 Modelle –CRE-TOPO »Anpassung des Geländes an die Modellgrenze: vertikale Ausdehnung »Skalieren ab der halben Höhe der planetarischen Grenzschicht, nach folgendem Modell: W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 52 von xx Skalierte Höhe Z*: Z* = Z0 + dZ * H0 / HMAX

53 ABR V2.0 Modelle –Gammasubmersionsberechnung »Erfolgt mittels adjungierter Flüsse »Spektren für 30 Energiegruppen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 53 von xx

54 ABR V2.0 Modelle –Gammasubmersionsberechnung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 54 von xx Die Transportgleichung lautet in Operatorschreibweise: M =Q Mit: Nach Lösen der Transportgleichung kann man spezielle Reaktionsraten (z. B. Dosisleistung D) mittels einer Response Funktion berechnen

55 ABR V2.0 Modelle –Gammasubmersionsberechnung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 55 von xx Eine zu M =Q adjungierte Gleichung ist M + + = R Mit: R = Response-Funktion zur Bestimmung der Dosis Die adjungierte Gleichung muss so definiert sein, dass folgende Bedingung gilt: Dies bedeutet, dass anstelle der Gleichung von M =Q auch die adjungierte Gleichung M + + = R gel ö st und die Reaktionsrate mittels folgender Gleichung bestimmt werden kann.

56 ABR V2.0 Modelle –Gammasubmersionsberechnung »Die Lösung der adjungierten Transportgleichung stellt die Relation zwischen der Photonenemission einer bestimmten Energie oder eines Energiebereichs in einem Punkt oder einem Volumen und der Dosis in einem Aufpunkt dar. »Bei der Berechnung der Dosisleistung an einem bestimmen Aufpunkt aufgrund einer momentanen Emissions-Situation aus der Abluftfahne, müssen die relevanten Beiträge aus dem gesamten Emissionsfeld integriert bzw. aufsummiert werden. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 56 von xx Hierbei werden mit dem Index q das Quellvolumen, mit dem Index g die Quellgruppe (entsprechend der Photonen-Emissionsenergie) bezeichnet. Mit den Koordinaten x,y,z wird der jeweilige Aufpunkt, mit x q, y q (bzw. r q ) z q der Mittelpunkt des Quellvolumens V q bezeichnet

57 ABR V2.0 Modelle –Gammasubmersionsberechnung »Quellpunkt Q(rq,zq) und Aufpunkt P(x,y,z) bei Dosisberechnungen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 57 von xx

58 ABR V2.0 Modelle –Gammasubmersionsberechnung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 58 von xx Dosis je Quellphoton als Funktion des Abstands Quellpunkt-Aufpunkt für verschiedene Emissionshöhen (links) Approximation der adjungierten Funktion mit Polynom 4. Ordnung (rechts) Quellenergie 3,25 MeV

59 ABR V2.0 Modelle –Gammasubmersionsberechnung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 59 von xx Abhängigkeit der adjungierten Funktion vom Abstand Quellpunkt-Aufpunkt für 2 verschiedene Quellenergien. Dargestellt sind der totale und ungestreute Beitrag

60 Benchmark, Validierung Validierung –Vergleich der Simulationsergebnisse mit Experimenten Benchmark –Vergleich der Simulationsergebnisse mit denen anderer Modelle W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 60 von xx

61 Benchmark, Validierung Durchgeführte Benchmarks –MATTHEW – ADPIC »Entwickelt in den USA »Basis des Schweizerischen Systems –ARTM »Langzeitausbreitungsmodell –JRODOS / RODOS »Entwickelt am KIT »Eingesetzt beim BfS, in einigen Bundes- und europäischen Ländern W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 61 von xx

62 Benchmark, Validierung Basis für Benchmarkrechnungen –Definierte Anfangsbedingungen »Meist beginnend mit einem einfachen Testfall »Reihe von komplexeren Fällen –Definition der Ergebnisdaten die zum Vergleich herangezogen werden W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 62 von xx

63 Benchmark, Validierung Beispiel 1: Vergleich ABR - JRODOS W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 63 von xx Benchmark-SzenarienBasis Basis + Topographieeinfluss Winddrehung 1Winddrehung 2 mehrere Freisetzungsphasen Anlagenbeschreibung Standort Philippsburg KKP 2 Neckarwestheim GKN 2 Philippsburg KKP 2 Standortkoordinaten in Gauß-Krüger Thermische Leistung 3950 MWth 3850 MWth 3950 MWth Dauer der letzten Revision 28 Tage Anzahl Vollasttage nach der letzten Revision 100 Tage Zeit seit dem Abschalten des Reaktors 6 Stunden Emission Emissionshöhe 50 m 100 m 50 m Emissionsbeginn gleich Simulationsbeginn (siehe unten) Emissionsdauer 1 Stunde 4 Stunden siehe Benchmark 2 Freigesetzte Aktivität für folgende Nuklide (nicht als Leitnuklid zu interpretieren) Xe 1336,2 E+18 siehe Benchmark-2 Cs 1379,8 E+12 1,2 E+13 (Angaben für Nuklidgruppen) I 1311,9 e+14 1,9 E+14 Verhältnis von organisch gebundenem und elementarem Iod 50/50 Nuklidvektor (Nuklidzusammensetzung) nach FK1 für DWR Ergebnisdaten für den Vergleich: Konzentrationen (Bodennahe Schicht, Deposition) Ortsdosisleistung

64 Benchmark, Validierung ABR – JRODOS: Erste Ergebnisse –Vergleich der Maximalwerte »Altersgruppe: Erwachsene W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 64 von xx ODL [mSv/h] Schilddrüse [mSv] Inhalation [mSv] ABR183,000266,20015,020 ATSTEP23,66973,6273,811 DIPCOT6,93274,4583,856 RIMPUFF3,42163,4073,284

65 Benchmark, Validierung ABR – JRODOS: Erste Ergebnisse W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 65 von xx

66 Benchmark, Validierung ABR – JRODOS: Erste Ergebnisse –Ortsdosisleistung zum 1. Zeitschritt (Werte < 1.0E-5 mSv/h unterdrückt) W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 66 von xx DIPCOT RIMPUF ABR ATSTEP

67 Benchmark, Validierung Beispiel 1: Vergleich ABR – MATHEW-ADPIC –Modellparameter »Windfeldberechnung auf Basis von Messwerten »Turbulenzparametrierung nach Pasquill-Gifford »Einheitsquelle: 1 [Bq/s] Cs 137 –Standorte »KKLKernkraftwerk Leibstadt »KKPKernkraftwerk Philippsburg »GKNGemeinschaftskernkraftwerk Neckar W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 67 von xx

68 Benchmark, Validierung ABR – ADPIC: KKL: Vergleich der max. Windgeschwindigkeiten W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 68 von xx HöheABRADPIC 350 m ü. M.7,1 [m/s]7,3 [m/s] 400 m ü. M.7,5 [m/s]7,4 [m/s] 450 m ü. M.7,7 [m/s]7,2 [m/s] 500 m ü. M.7,1 [m/s] 550 m ü. M.6,9 [m/s]7,6 [m/s] ADPIC ABR

69 Benchmark, Validierung ABR – ADPIC: Aktivitätskonzentration nach dem 6. Zeitschritt, Standort KKP W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 69 von xx Adpic (max. 1,9 E-7 [Bq/m3])ABR (max. 2,1 E-7 [Bq/m3])

70 Benchmark, Validierung ABR – ADPIC: Aktivitätskonzentration nach dem 6. Zeitschritt, Standort KKP W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Apr-14Seite 70 von xx


Herunterladen ppt "W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Apr-14Seite 1 von 23 Simulation der Ausbreitung radioaktiver Schadstoffe Software Engineering."

Ähnliche Präsentationen


Google-Anzeigen