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

W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - 11. Apr 2023 Seite 1 von 23

Simulation der Ausbreitung radioaktiver Schadstoffe

Software Engineering

Inhalte der Vorlesung

W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - 11. Apr 2023 Seite 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

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 - 11. Apr 2023

Seite 3 von xx


• 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 - 11. Apr 2023

Seite 4 von xx


• Extreme Progamming– Werte

» Kommunikation» Einfachheit» Rückmeldung» Mut und» Respekt


Seite 5 von xx


• 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


Seite 6 von xx


• 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


Seite 7 von xx



» 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).


Seite 8 von xx



» 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)


Seite 9 von xx



» 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.


Seite 10 von xx


• Extreme Programming– Praktiken

» Organisation» Anforderungsmanagement» Planung» User-Stories» Aufwandabschätzung» Entwicklung und Abschluss


Seite 11 von xx


• 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.


Seite 12 von xx


• Extreme Programming– Praktiken: Planung

» Änderungskostenkurve• Bei XP weitgehend linear


Seite 13 von xx


• 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.“


Seite 14 von xx


• Extreme Programming– Praktiken : Planung

» User-Storys und Iterationen


Seite 15 von xx


• 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


Seite 16 von xx


• 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.


Seite 17 von xx


• 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.


Seite 18 von xx


• 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.


Seite 19 von xx


• 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.


Seite 20 von xx


• Extreme Programming– Praktiken


Seite 21 von xx


• Extreme Programming– Zeitliche Aufteilung


Seite 22 von xx


Seite 23 von xx


• 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.


Seite 24 von xx


• 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.


Seite 25 von xx

ExtensionPoint

Pattern

Framework

*

1

*

*

1

*

Component

**

**

*

*

*

*11

Class A ClassB

*11 *

Class A ClassB

*11 *


• Framework– White-Box Frameworks, Wiederverwendung und Erweiterung

durch Vererbung– Black-Box Frameworks, Wiederverwendung und Erweiterung

durch Aggregation


Seite 26 von xx


• 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.


Seite 27 von xx

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


Seite 28 von xx

ABR V2.0

• Anforderungen– Erhöhung der Ausfallsicherheit– Flexibilisierung des Systems– Robuste aber offene Architektur– Verteilung– Persistenz– Zugangs- und Zugriffskontrolle– Performanz– Erweiterbar– Leicht wartbar


Seite 29 von xx

ABR V2.0

• Ausgangslage:– Reihe von physikalischen Prozessen

» Makroskopischen Ebene• Freisetzung• Transport• Ablagerung

» Detailebene• Radioaktiver Zerfall• Chemische Reaktionen• Washout, rainout• Turbulenz• Bodeneinfluss


Seite 30 von xx

ABR V2.0

• Rahmenbedingungen:– Einbindung in eine bestehende Infrastruktur

» Systemumgebung• Rechner• Betriebssystem• Netzwerk

» Organisation• Wer darf wann was

– Integration von „Altlasten“» Bestehende Komponenten


Seite 31 von xx

ABR V2.0

• Framework DiSiF


Seite 32 von xx

Logische Struktur Physikalische Struktur

ABR V2.0


Seite 33 von xx

• Framework DiSiF– Sessions

» Authentifizierung» Verwaltung,

Zuweisung der Benutzerrollen

» Verfügbare Simulationsressourcen anzeigen

– Simulations

» Verwaltung der auf der Ebene darunter liegenden „workflows“

ABR V2.0


Seite 34 von xx

• Framework DiSiF– Workflows

» Verwaltung der auf der Ebene darunter liegenden ausführbaren Programme, Module

– Calculation Services

» Verfügbare Programme, Module

ABR V2.0


Seite 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

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


Seite 36 von xx

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


Seite 37 von xx

t + ∆t

WINDO PAS AIRDOS DOSEt

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


Seite 38 von xx

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


Seite 39 von xx

ABR V2.0

• Ptolemy: Einsatzbereich der Workflow Engine


Seite 40 von xx

ABR V2.0


Seite 41 von xx

Akteure Ein- und Ausgabeports Kapseln z.B. Rechencodes ein Hierarchische Einkapselung

AtomarerAkteur C

Daten

Ablaufsteuerung

Token

AtomarerAkteur D

AtomarerAkteur A

AtomarerAkteur B

• Ptolemy: Akteurorientierte Modellierung

ABR V2.0

• Ptolemy: Descrete Event Director


Seite 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 erzeugtAuf Ereignissen wird reagiert

DE Director

WINDO PAS AIRDOS… DOSE

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


Seite 43 von xx

Zeitschritt / parallele Prozesse

Zeit

A = WINDO, B = PAS, C = AIRDOS, D = DOSEZeit

OhnePipeline

MitPipeline

Rechenzeit / Zeitschritt = max{A,B,C,D} + I/O Mehraufwand + Störungen (z.B. Prozesse anderer Benutzer)

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


Seite 44 von xx

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


Seite 45 von xx

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


Seite 46 von xx

ABR V2.0

• Aspektorientierte Programmierung– Traditionelle Programmierung


Seite 47 von xx

f: Kernfunktionalität

g: Zugangskontrolle

ABR V2.0

• Aspektorientierte Programmierung– Trennung von Kern- und Aspektfunktionalität


Seite 48 von xx

Umsetzung des Zugangskontrollaspektes

Kernmodul

Aspektmodul

Schnittstellen zwischen Kern- und Aspektfunktionalität werden durch „Annotations“ (Metadaten) realisiert

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


Seite 49 von xx

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


Seite 50 von xx

ABR V2.0

• Modellgrenzen


Seite 51 von xx

Modellgröße Wertebereich Einheit

Horizontale Ausdehnung (Radius) (klein, mittel, groß) 1, 10, 25 Km

Vertikale Ausdehnung 200 – 1000 m

Zeitlicher Kontext 10 - 4320 min

Maximale Topographiedifferenz (Min-Max) 400 – 500 m

freie Luftschicht Max 1000 m

Zahl der Maschen in X und Y Richtung je 100

Zahl der Z-Maschen (kartesisch) Max 40

Maschengröße Z (kartesisch) 20 – 40 m

Maschengröße X, Y (klein, mittel, groß) 20,200,500 m

Maximale Steigung (NOABL) 15 %

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:


Seite 52 von xx

HMAX

Toleranz

Z0

dZH0

Skalierte Höhe Z*:

Z* = Z0 + dZ * H0 / HMAX

ABR V2.0

• Modelle– Gammasubmersionsberechnung

» Erfolgt mittels adjungierter Flüsse » Spektren für 30 Energiegruppen


Seite 53 von xx

ABR V2.0



Seite 54 von xx

''''' '

ddEEEEgradME

T

dErdErRErRDV E

,,

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 ErR ,

ABR V2.0



Seite 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:

MM

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.

RD

ABR V2.0


» 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.


Seite 56 von xx

22

,

)()(

),(),(),,(

yyxxr

VzyxQzzrzyxD

qqq

qqqqgqqq g

g

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

ABR V2.0


» Quellpunkt Q(rq,zq) und Aufpunkt P(x,y,z) bei Dosisberechnungen


Seite 57 von xx

IKE 29.3. 2012 7

Universität Stuttgart

Inst

itu

t fü

r K

ern

en

erg

etik

un

d E

ner

gie

sys

tem

e

22

,

)()(

),(),(),,(

yyxxr

VzyxQzzrzyxD

qqq

gqqqgqqq g

g

),,( zyx

qr

Berechnung der Dosisleistung mittels adjungierterPhotonenflüsse

qz

ABR V2.0



Seite 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

ABR V2.0



Seite 59 von xx

Abhängigkeit der adjungierten Funktion vom Abstand Quellpunkt-Aufpunkt für 2 verschiedene Quellenergien. Dargestellt sind der totale und ungestreute Beitrag

Benchmark, Validierung

• Validierung– Vergleich der Simulationsergebnisse mit Experimenten

• Benchmark– Vergleich der Simulationsergebnisse mit denen anderer

Modelle


Seite 60 von xx


• 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


Seite 61 von xx


• 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


Seite 62 von xx


• Beispiel 1: Vergleich ABR - JRODOS


Seite 63 von xx

Benchmark-Szenarien Basis Basis + Topographieeinfluss Winddrehung 1 Winddrehung 2 mehrere Freisetzungsphasen

Anlagenbeschreibung

Standort Philippsburg KKP 2 Neckarwestheim GKN 2 Neckarwestheim GKN 2 Neckarwestheim GKN 2 Philippsburg KKP 2

Standortkoordinaten in Gauß-Krüger

Thermische Leistung 3950 MWth 3850 MWth 3850 MWth 3850 MWth 3950 MWth

Dauer der letzten Revision 28 Tage 28 Tage 28 Tage 28 Tage 28 Tage

Anzahl Vollasttage nach der letzten Revision 100 Tage 100 Tage 100 Tage 100 Tage 100 Tage

Zeit seit dem Abschalten des Reaktors 6 Stunden 6 Stunden 6 Stunden 6 Stunden 6 Stunden

Emission

Emissionshöhe 50 m 50 m 50 m 100 m 50 mEmissionsbeginn gleich Simulationsbeginn

(siehe unten) gleich Simulationsbeginn

(siehe unten)

gleich Simulationsbeginn (siehe unten)



Emissionsdauer 1 Stunde 1 Stunde 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 6,2 E+18 6,2 E+18 6,2 E+18 siehe Benchmark-2

Cs 137 9,8 E+12 1,2 E+13 1,2 E+13 1,2 E+13 (Angaben für Nuklidgruppen)

I 131 1,9 e+14 1,9 E+14 1,9 E+14 1,9 E+14

Verhältnis von organisch gebundenem und elementarem Iod 50/50 50/50 50/50 50/50 50/50

Nuklidvektor (Nuklidzusammensetzung) nach FK1 für DWR nach FK1 für DWR nach FK1 für DWR nach FK1 für DWR nach FK1 für DWR

• Ergebnisdaten für den Vergleich:- Konzentrationen (Bodennahe Schicht, Deposition)- Ortsdosisleistung


• ABR – JRODOS: Erste Ergebnisse– Vergleich der Maximalwerte

» Altersgruppe: Erwachsene


Seite 64 von xx

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


• ABR – JRODOS: Erste Ergebnisse


Seite 65 von xx

0.0000E+00 3.0000E+03 6.0000E+03 9.0000E+03 1.2000E+04 1.5000E+04 1.8000E+040.0000E+00

2.0000E+06

4.0000E+06

6.0000E+06

8.0000E+06

1.0000E+07

1.2000E+07

1.4000E+07 Iodkonzentration (Deposition) entlang der Windrichtung

ABR

ATSTEP

DIPCOT

RIMPUFF

Pluto

Entfernung [m]

Ko

nze

ntr

atio

n [

Bq

/m2]


• ABR – JRODOS: Erste Ergebnisse– Ortsdosisleistung zum 1. Zeitschritt (Werte < 1.0E-5 mSv/h

unterdrückt)


Seite 66 von xx

DIPCOTRIMPUF

ABR ATSTEP


• 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


Seite 67 von xx


• ABR – ADPIC: KKL: Vergleich der max. Windgeschwindigkeiten


Seite 68 von xx

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. 7,1 [m/s] 7,1 [m/s]

550 m ü. M. 6,9 [m/s] 7,6 [m/s]

ADPIC ABR


• ABR – ADPIC: Aktivitätskonzentration nach dem 6. Zeitschritt, Standort KKP


Seite 69 von xx

Adpic (max. 1,9 E-7 [Bq/m3]) ABR (max. 2,1 E-7 [Bq/m3])


• ABR – ADPIC: Aktivitätskonzentration nach dem 6. Zeitschritt, Standort KKP


Seite 70 von xx

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

Documents

Transcript of W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Apr-14Seite 1 von 23 Simulation...