Simulation der Ausbreitung radioaktiver Schadstoffe Software Engineering W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Mrz-17

Inhalte der Vorlesung 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 W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Mrz-17

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 - Mrz-17

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 - Mrz-17

Software Paradigmen, Frameworks Extreme Progamming Werte Kommunikation Einfachheit Rückmeldung Mut und Respekt W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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 - Mrz-17

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 - Mrz-17

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 - Mrz-17

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 - Mrz-17

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 - Mrz-17

Software Paradigmen, Frameworks Extreme Programming Praktiken Organisation Anforderungsmanagement Planung User-Stories Aufwandabschätzung Entwicklung und Abschluss W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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 - Mrz-17

Software Paradigmen, Frameworks Extreme Programming Praktiken: Planung Änderungskostenkurve Bei XP weitgehend linear Name Universität Stuttgart - 1XX-123 – Modulthema - Mrz-17

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 - Mrz-17

Software Paradigmen, Frameworks Extreme Programming Praktiken : Planung User-Storys und Iterationen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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 - Mrz-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 - Mrz-17

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 - Mrz-17

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 - Mrz-17

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 - Mrz-17

Software Paradigmen, Frameworks Extreme Programming Praktiken W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

Software Paradigmen, Frameworks Extreme Programming Zeitliche Aufteilung Name Universität Stuttgart - 1XX-123 – Modulthema - Mrz-17

W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

Software Paradigmen, Frameworks "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 - Mrz-17

Software Paradigmen, Frameworks 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 - Mrz-17

Software Paradigmen, Frameworks White-Box Frameworks, Wiederverwendung und Erweiterung durch Vererbung Black-Box Frameworks, Wiederverwendung und Erweiterung durch Aggregation W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

Software Paradigmen, Frameworks 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 - Mrz-17

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 - Mrz-17

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 - Mrz-17

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 - Mrz-17

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 - Mrz-17

ABR V2.0 Framework DiSiF Logische Struktur Physikalische Struktur Name Universität Stuttgart - 1XX-123 – Modulthema - Mrz-17

ABR V2.0 Framework DiSiF Authentifizierung Sessions Authentifizierung Verwaltung, Zuweisung der Benutzerrollen Verfügbare Simulationsressourcen anzeigen Simulations Verwaltung der auf der Ebene darunter liegenden „workflows“ Name Universität Stuttgart - 1XX-123 – Modulthema - Mrz-17

ABR V2.0 Framework DiSiF Workflows Verwaltung der auf der Ebene darunter liegenden ausführbaren Programme, Module Calculation Services Verfügbare Programme, Module Name Universität Stuttgart - 1XX-123 – Modulthema - Mrz-17

ABR V2.0 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 Name Universität Stuttgart - 1XX-123 – Modulthema - Mrz-17

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 - Mrz-17

ABR V2.0 Modularisierung der physikalischen Prozesse Module durch Altsystem vorgegeben Module sind in sich abgeschlossene lauffähige Einheiten WINDO Windfeldmodul MCF Windfeldmodul PAS Modul zur Berechnung des Partikeltransports AIRDOS Modul zur Berechnung der Gammasubmersion DOSE Modul zur Dosisberechnung Zeitintegration erfolgt auf Modulebene Vorwärts verkettetes System Keine Rückkopplung t + ∆t WINDO PAS AIRDOS DOSE t Name Universität Stuttgart - 1XX-123 – Modulthema - Mrz-17

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 - Mrz-17

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 - Mrz-17

ABR V2.0 Ptolemy: Einsatzbereich der Workflow Engine W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

ABR V2.0 Ptolemy: Descrete Event Director DE Director WINDO PAS AIRDOS … DOSE Regeln für Simulationen mit diskreten Ereignissen Ereignisse werden erzeugt Auf Ereignissen wird reagiert Ereignis: Modul n hat zu Ende gerechnet Reaktion: Modul n+1 fängt an zu rechnen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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 Zeitschritt / parallele Prozesse Zeit A = WINDO, B = PAS, C = AIRDOS, D = DOSE Ohne Pipeline Mit Rechenzeit / Zeitschritt = max{A,B,C,D} + I/O Mehraufwand + Störungen (z.B. Prozesse anderer Benutzer) W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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 - Mrz-17

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 - Mrz-17

ABR V2.0 Aspektorientierte Programmierung Warum Ziel 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 - Mrz-17

ABR V2.0 Aspektorientierte Programmierung Traditionelle Programmierung g: Zugangskontrolle f: Kernfunktionalität W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

ABR V2.0 Aspektorientierte Programmierung Trennung von Kern- und Aspektfunktionalität Kernmodul Umsetzung des Zugangskontrollaspektes Aspektmodul Schnittstellen zwischen Kern- und Aspektfunktionalität werden durch „Annotations“ (Metadaten) realisiert W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

ABR V2.0 Modelle Topographie Quellterm Windfeldberechnung 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 - Mrz-17

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 - Mrz-17

ABR V2.0 Modellgrenzen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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: Skalierte Höhe Z*: Z* = Z0 + dZ * H0 / HMAX W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

ABR V2.0 Modelle Gammasubmersionsberechnung Erfolgt mittels adjungierter Flüsse Spektren für 30 Energiegruppen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

ABR V2.0 Modelle Gammasubmersionsberechnung 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 W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

ABR V2.0 Modelle Gammasubmersionsberechnung 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. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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. 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 xq, yq (bzw. rq) zq der Mittelpunkt des Quellvolumens Vq bezeichnet W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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 - Mrz-17

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

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

Benchmark, Validierung Vergleich der Simulationsergebnisse mit Experimenten Benchmark Vergleich der Simulationsergebnisse mit denen anderer Modelle W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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 - Mrz-17

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 - Mrz-17

Benchmark, Validierung Beispiel 1: Vergleich ABR - JRODOS Benchmark-Szenarien Basis   Basis + Topographieeinfluss Winddrehung 1 Winddrehung 2 mehrere Freisetzungsphasen Anlagenbeschreibung Standort Philippsburg KKP 2 Neckarwestheim GKN 2 Standortkoordinaten in Gauß-Krüger Thermische Leistung 3950 MWth 3850 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 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 133 6,2 E+18 siehe Benchmark-2 Cs 137 9,8 E+12 1,2 E+13 (Angaben für Nuklidgruppen) I 131 1,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 W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

Benchmark, Validierung ABR – JRODOS: Erste Ergebnisse Vergleich der Maximalwerte Altersgruppe: Erwachsene ODL [mSv/h] Schilddrüse [mSv] Inhalation [mSv] ABR 183,000 266,200 15,020 ATSTEP 23,669 73,627 3,811 DIPCOT 6,932 74,458 3,856 RIMPUFF 3,421 63,407 3,284 W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

Benchmark, Validierung ABR – JRODOS: Erste Ergebnisse W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

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 KKL Kernkraftwerk Leibstadt KKP Kernkraftwerk Philippsburg GKN Gemeinschaftskernkraftwerk Neckar W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

Benchmark, Validierung ABR – ADPIC: KKL: Vergleich der max. Windgeschwindigkeiten Höhe ABR ADPIC 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. 550 m ü. M. 6,9 [m/s] 7,6 [m/s] ABR ADPIC W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

Benchmark, Validierung ABR – ADPIC: Aktivitätskonzentration nach dem 6. Zeitschritt, Standort KKP W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17