# A Flooding Induced Station Blackout Analysis for a Pressurized Water Reactor Using the RISMC Toolkit

Authors: Diego Mandelli; Steven Prescott; Curtis Smith; Andrea Alfonsi; Cristian Rabiti; Joshua Cogliati; Robert Kinoshita
Journal: Science and Technology of Nuclear Installations
 (2015)

---

## Abstract

In this paper we evaluate the impact of a power uprate on a pressurized water reactor (PWR) for a tsunami-induced flooding test case. This analysis is performed using the RISMC toolkit: the RELAP-7 and RAVEN codes. RELAP-7 is the new generation of system analysis codes that is responsible for simulating the thermal-hydraulic dynamics of PWR and boiling water reactor systems. RAVEN has two capabilities: to act as a controller of the RELAP-7 simulation (e.g., component/system activation) and to perform statistical analyses. In our case, the simulation of the flooding is performed by using an advanced smooth particle hydrodynamics code called NEUTRINO. The obtained results allow the user to investigate and quantify the impact of timing and sequencing of events on system safety. In addition, the impact of power uprate is determined in terms of both core damage probability and safety margins.


---

## Body

## 1. Introduction

The Risk-Informed Safety Margin Characterization (RISMC) Pathway develops and delivers approaches to manage safety margins [1]. This important information supports the nuclear power plant owner/operator decision-making associated with near- and long-term operation. The RISMC approach can optimize plant safety and performance by incorporating a novel interaction between probabilistic risk simulation and mechanistic codes for plant-level physics. The new functionality allows the risk simulation module to serve as a “scenario generator” that feeds information to the mechanistic codes. The effort fits with the goals of the RISMC Pathway, which are twofold:(1)
To develop and demonstrate a risk-assessment method coupled to safety margin quantification: the method can be used by decision-makers as part of their margin management strategies.(2)
To create an advanced RISMC toolkit: this RISMC toolkit would enable users to have a more accurate representation of nuclear power plant safety margins and its associated influences on operations and economics.When evaluating the safety margin, what we want to understand is not just the frequency of an event like core damage but how close we are (or are not) to key safety-related events and how we might increase our safety margin through proper applications of Risk-Informed Margin Management (RIMM). In general terms, a “margin” is usually characterized in one of two ways:(i)
A deterministic margin, typically defined by the ratio (or, alternatively, the difference) of a capacity (i.e., strength) over the load.(ii)
A probabilistic margin, defined by the probability that the load exceeds the capacity.A probabilistic safety margin is a numerical value quantifying the probability that a safety metric (e.g., for an important process observable such as clad temperature) will be exceeded under accident scenario conditions.The RISMC Pathway uses the probabilistic margin approach to quantify impacts on reliability and safety. As part of the quantification, we use both probabilistic (via risk simulation) and mechanistic (via physics models) approaches, as represented in Figure1. Safety margin and uncertainty quantification rely on plant physics (e.g., thermal-hydraulics and reactor kinetics) coupled with probabilistic risk simulation. The coupling takes place through the interchange of physical parameters (e.g., pressures and temperatures) and operational or accident scenarios.Figure 1
The approach used to support RIMM analysis.


## 2. The RISMC Toolkit

In order to perform advanced safety analysis, the RISMC project has a toolkit that was developed internally at INL using MOOSE [2] as the underlying numerical solver framework. This toolkit consists of the following software tools (see Figure 2):(i)
RELAP-7 [3] (see Section 2.1): it is the code responsible for simulating the thermal-hydraulic dynamics of the plant.(ii)
RAVEN [4] (see Section 2.2): it has two main functions: (1) act as a controller of the RELAP-7 simulation and (2) generate multiple scenarios (i.e., a sampler) by stochastically changing the order and/or timing of events.(iii)
PEACOCK [5] (see Section 2.3): it is the Graphical User Interface (GUI) that allows the user to create/modify input files of both RAVEN and RELAP-7. It monitors the simulation in real time while it is running.(iv)
GRIZZLY [6]: it is the code that simulates the thermal-mechanical behavior of components in order to model component aging and degradation. Note that, for the analysis described in this paper, aging was not considered.Figure 2
Overview of the RISMC toolkit.This paper presents an analysis that evaluates the impacts of power uprates on a SBO event caused by external flooding. Due to the nature of the problem, the thermal-mechanical modeling needed to simulate component aging is not required. Thus, RELAP-7, RAVEN, and PEACOCK are being used. In this respect, Sections2.1, 2.2, and 2.3 describe in more detail the components of the RISMC toolkit that are here employed: RELAP-7, RAVEN, and PEACOCK.


### 2.1. RELAP-7

The RELAP-7 code [3] is the new nuclear reactor system safety analysis codes being developed at the Idaho National Laboratory (INL). RELAP-7 is designed to be the main reactor system simulation toolkit for the RISMC Pathway of the Light Water Reactor Sustainability (LWRS) Program [7]. The RELAP-7 code development is taking advantage of the progress made in the past several decades to achieve simultaneous advancement of physical models, numerical methods, and software design. RELAP-7 uses the INL’s MOOSE (Multi-Physics Object-Oriented Simulation Environment) framework [2] for solving computational engineering problems in a well-planned, managed, and coordinated way. This allows RELAP-7 development to focus strictly on systems analysis-type physical modeling and gives priority to retention and extension of RELAP5’s multidimensional system capabilities.A real reactor system is very complex and may contain hundreds of different physical components. Therefore, it is impractical to preserve real geometry for the whole system. Instead, simplified thermal-hydraulic models are used to represent (via “nodalization”) the major physical components and describe major physical processes (such as fluid flow and heat transfer). There are three main types of components developed in RELAP-7: (1) one-dimensional (1D) components, (2) zero-dimensional (0D) components for setting a boundary, and (3) 0D components for connecting 1D components.


### 2.2. RAVEN

RAVEN (Risk Analysis and Virtual Control Environment) [4] is a software framework that acts as the control logic driver for the thermal-hydraulic code RELAP-7. RAVEN is also a multipurpose Probabilistic Risk Assessment (PRA) code that allows dispatching different functionalities. It is designed to derive and actuate the control logic required to simulate both plant control system and operator actions (guided procedures) and to perform both Monte Carlo sampling [8] of random distributed events and dynamic branching-type [9] based analysis.RAVEN consists of two main software components:(1)
Simulation controller.(2)
Statistical framework.The first RAVEN component acts as controller of the RELAP-7 simulation while simulation is running. This control action is performed by using two sets of variables [10]:(i)
Monitored variables: the set of observable parameters that are calculated at each calculation step by RELAP-7 (e.g., average clad temperature).(ii)
Controlled parameters: the set of controllable parameters that can be changed/updated at the beginning of each calculation step (e.g., status of a valve (open or closed) or pipe friction coefficient).The manipulation of these two data sets is performed by two components of the RAVEN simulation controller (see Figure3):(i)
RAVEN control logic: it is the actual system control logic of the simulation where, based on the status of the system (i.e., monitored variables), it updates the status/value of the controlled parameters.(ii)
RAVEN/RELAP-7 interface: it is in charge of updating and retrieving RELAP-7/MOOSE component variables according to the control logic.Figure 3
RAVEN simulation controller scheme.A third set of variables, that is, auxiliary variables, allows the user to define simulation specific variables that may be needed to control the simulation. From a mathematical point of view, auxiliary variables are the ones that guarantee the system to be Markovian [11]; that is, the system status at time t=t-+Δt can be numerically solved given only the system status at time t=t-.The set of auxiliary variables also includes those that monitor the status of specific control logic set of components (e.g., diesel generators, AC buses) and simplify the construction of the overall control logic scheme of RAVEN.The RAVEN statistical framework is a recent add-on of the RAVEN package that allows the user to perform generic statistical analysis. By statistical analysis we include the following:(i)
Sampling of codes: either stochastic (e.g., Monte Carlo [8] and Latin Hypercube Sampling (LHS) [12]) or deterministic (e.g., grid and Dynamic Event Tree (DET) [9]).(ii)
Generation of Reduced Order Models (ROMs) [13] also known as surrogate models or emulators.(iii)
Postprocessing of the sampled data and generation of statistical parameters (e.g., mean, variance, and covariance matrix).Figure4 shows a general overview of the elements that comprise the RAVEN statistical framework:(i)
Model: it represents the pipeline between input and output space. It comprises both codes (e.g., RELAP-7) and also ROMs.(ii)
Sampler: it is the driver for any specific sampling strategy (e.g., Monte Carlo, LHS, and DET).(iii)
Database: it is the data storing entity.(iv)
Postprocessing module: it is the module that performs statistical analyses and visualizes results.Figure 4
Scheme of RAVEN statistical framework components.


### 2.3. PEACOCK

PEACOCK is the GUI front end for the RELAP-7 code and, in general, for any generic MOOSE based application. It is a PYTHON based software interface that allows the user to interface both offline and online with the RELAP-7 simulation. The user can, in fact, both create/modify the RAVEN/RELAP-7 input file (offline) and monitor the RAVEN/RELAP-7 simulation while it is running (online). A screenshot of PEACOCK is given in Figure5.Figure 5
Screenshot of the PEACOCK GUI for a RAVEN/RELAP-7 input file.In the offline mode, the user has available all the blocks and components needed to build the RAVEN/RELAP-7 input file such as(i)
RELAP-7 simulation and component parameters,(ii)
RAVEN variables: monitored, controlled, and auxiliary (see Section2.2),(iii)
RAVEN/RELAP-7 simulation output information.


## 2.1. RELAP-7

The RELAP-7 code [3] is the new nuclear reactor system safety analysis codes being developed at the Idaho National Laboratory (INL). RELAP-7 is designed to be the main reactor system simulation toolkit for the RISMC Pathway of the Light Water Reactor Sustainability (LWRS) Program [7]. The RELAP-7 code development is taking advantage of the progress made in the past several decades to achieve simultaneous advancement of physical models, numerical methods, and software design. RELAP-7 uses the INL’s MOOSE (Multi-Physics Object-Oriented Simulation Environment) framework [2] for solving computational engineering problems in a well-planned, managed, and coordinated way. This allows RELAP-7 development to focus strictly on systems analysis-type physical modeling and gives priority to retention and extension of RELAP5’s multidimensional system capabilities.A real reactor system is very complex and may contain hundreds of different physical components. Therefore, it is impractical to preserve real geometry for the whole system. Instead, simplified thermal-hydraulic models are used to represent (via “nodalization”) the major physical components and describe major physical processes (such as fluid flow and heat transfer). There are three main types of components developed in RELAP-7: (1) one-dimensional (1D) components, (2) zero-dimensional (0D) components for setting a boundary, and (3) 0D components for connecting 1D components.


## 2.2. RAVEN

RAVEN (Risk Analysis and Virtual Control Environment) [4] is a software framework that acts as the control logic driver for the thermal-hydraulic code RELAP-7. RAVEN is also a multipurpose Probabilistic Risk Assessment (PRA) code that allows dispatching different functionalities. It is designed to derive and actuate the control logic required to simulate both plant control system and operator actions (guided procedures) and to perform both Monte Carlo sampling [8] of random distributed events and dynamic branching-type [9] based analysis.RAVEN consists of two main software components:(1)
Simulation controller.(2)
Statistical framework.The first RAVEN component acts as controller of the RELAP-7 simulation while simulation is running. This control action is performed by using two sets of variables [10]:(i)
Monitored variables: the set of observable parameters that are calculated at each calculation step by RELAP-7 (e.g., average clad temperature).(ii)
Controlled parameters: the set of controllable parameters that can be changed/updated at the beginning of each calculation step (e.g., status of a valve (open or closed) or pipe friction coefficient).The manipulation of these two data sets is performed by two components of the RAVEN simulation controller (see Figure3):(i)
RAVEN control logic: it is the actual system control logic of the simulation where, based on the status of the system (i.e., monitored variables), it updates the status/value of the controlled parameters.(ii)
RAVEN/RELAP-7 interface: it is in charge of updating and retrieving RELAP-7/MOOSE component variables according to the control logic.Figure 3
RAVEN simulation controller scheme.A third set of variables, that is, auxiliary variables, allows the user to define simulation specific variables that may be needed to control the simulation. From a mathematical point of view, auxiliary variables are the ones that guarantee the system to be Markovian [11]; that is, the system status at time t=t-+Δt can be numerically solved given only the system status at time t=t-.The set of auxiliary variables also includes those that monitor the status of specific control logic set of components (e.g., diesel generators, AC buses) and simplify the construction of the overall control logic scheme of RAVEN.The RAVEN statistical framework is a recent add-on of the RAVEN package that allows the user to perform generic statistical analysis. By statistical analysis we include the following:(i)
Sampling of codes: either stochastic (e.g., Monte Carlo [8] and Latin Hypercube Sampling (LHS) [12]) or deterministic (e.g., grid and Dynamic Event Tree (DET) [9]).(ii)
Generation of Reduced Order Models (ROMs) [13] also known as surrogate models or emulators.(iii)
Postprocessing of the sampled data and generation of statistical parameters (e.g., mean, variance, and covariance matrix).Figure4 shows a general overview of the elements that comprise the RAVEN statistical framework:(i)
Model: it represents the pipeline between input and output space. It comprises both codes (e.g., RELAP-7) and also ROMs.(ii)
Sampler: it is the driver for any specific sampling strategy (e.g., Monte Carlo, LHS, and DET).(iii)
Database: it is the data storing entity.(iv)
Postprocessing module: it is the module that performs statistical analyses and visualizes results.Figure 4
Scheme of RAVEN statistical framework components.


## 2.3. PEACOCK

PEACOCK is the GUI front end for the RELAP-7 code and, in general, for any generic MOOSE based application. It is a PYTHON based software interface that allows the user to interface both offline and online with the RELAP-7 simulation. The user can, in fact, both create/modify the RAVEN/RELAP-7 input file (offline) and monitor the RAVEN/RELAP-7 simulation while it is running (online). A screenshot of PEACOCK is given in Figure5.Figure 5
Screenshot of the PEACOCK GUI for a RAVEN/RELAP-7 input file.In the offline mode, the user has available all the blocks and components needed to build the RAVEN/RELAP-7 input file such as(i)
RELAP-7 simulation and component parameters,(ii)
RAVEN variables: monitored, controlled, and auxiliary (see Section2.2),(iii)
RAVEN/RELAP-7 simulation output information.


## 3. PWR SBO Case Study

The purpose of this case study is to show the capabilities of the RISMC workflow in order to evaluate the impacts of power uprates on a PWR system during a SBO initiating event. This assessment cannot be easily performed in a classical ET/FT based environment [14] due to the fact that its logical structures do not explicitly consider simulation elements.We employ the RISMC toolkit (see Section2). This toolkit mixes advanced simulation based tools with stochastic analysis algorithms. Such a step forward, if compared to state-of-practice PRA methods [15], will help the decision-makers to perform more risk-informed rulings.


### 3.1. PWR System

A PWR simplified model has been set up based on the parameters specified in the OECD main steam line break (MSLB) benchmark problem [16]. The reference design for the OECD MSLB benchmark problem is derived from the reactor geometry and operational data of the TMI-1 nuclear power plant (NPP), which is a 2772 MW two-loop pressurized water reactor (see the system scheme shown in Figure 6).Figure 6
Scheme of the TMI PWR benchmark.In order to simulate a SBO initiating event we need to consider also the following electrical systems (see Figure7):(i)
Primary power grid line 500 KV (connected to the 500 KV switchyard).(ii)
Auxiliary power grid line 161 KV (connected to the 161 KV switchyard).(iii)
Set of 2 diesel generators (DGs), DG1 and DG2, and associated emergency buses.(iv)
Electrical buses: 4160 V (step-down voltage from the power grid and voltage of the electric converter connected to the DGs) and 480 V for actual reactor components (e.g., reactor cooling system).(v)
DC system which provides power to instrumentation and control components of the plant. It consists of these two subsystems:
(a)
Battery charger and AC/DC converter if AC power is available.(b)
DC batteries: in case AC power is not available.Figure 7
Scheme of the electrical system of the PWR model.


### 3.2. SBO Scenario

The scenario considered is a loss of offsite power (LOOP) initiating event caused by an earthquake followed by tsunami-induced flooding. Depending on the wave height, it causes water to enter into the air intake of the DGs and temporary disable the DGs themselves. In more detail, the scenario is the following (see Figure8):(1)
An external event (i.e., earthquake) causes a LOOP due to damage of both 500 KV and 161 KV lines; the reactor successfully scrams and, thus, the power generated in the core follows the characteristic exponential decay curve.(2)
The DGs successfully start and emergency cooling to the core is provided by the Emergency Core Cooling System (ECCS).(3)
A tsunami wave hits the plant causing flooding of the plant itself. Depending on its height, the wave causes the DGs to fail and may also flood the 161 KV switchyard. Hence, conditions of SBO are reached (4160 V and 480 V buses are not energized); all core cooling systems are subsequently offline (including the ECCS).(4)
Without the ability to cool the reactor core, its temperature starts to rise.(5)
In order to recover AC electric power on the 4160 V and 480 V buses, three strategies based on the Emergency Operating Procedures (EOPs) are followed:
(i)
A plant recovery team is assembled in order to recover one of the two DGs.(ii)
The power grid owning company is working on the restoration of the primary 161 KV line.(iii)
A second plant recovery team is also assembled to recover the 161 KV switchyard in case it got flooded.(6)
Due to its lifetime limitation, the DC battery can be depleted. If this is the case, even if the DGs are repaired, DGs cannot be started. DCs power restoration (through spare batteries or emergency backup DC generators) is a necessary condition to restart the DGs.(7)
When the 4160 KV buses are energized (through the recovery of the DGs or 161 KV line), the auxiliary cooling system (i.e., ECCS) is able to cool the reactor core and, thus, core temperature decreases.Figure 8
Sequence of events for the SBO scenario considered.


### 3.3. Stochastic Parameters

For the scope of this paper, the following parameters are uncertain:twave: time at which the tsunami wave hit the plant.h: tsunami wave height.tDG_rec: recovery time of the DGs.tPG_rec: recovery time of the 161 KV power grid.tbatt_fail: failure time of the batteries (DC system) due to depletion.tbatt_rec: recovery time of the batteries (DC system).For each of these parameters we will find the appropriate probability distribution function (see Section4.3) in order to evaluate core damage probability PCD. Core damage is reached when max clad temperature in the core reaches its failure temperature (2200 F).


## 3.1. PWR System

A PWR simplified model has been set up based on the parameters specified in the OECD main steam line break (MSLB) benchmark problem [16]. The reference design for the OECD MSLB benchmark problem is derived from the reactor geometry and operational data of the TMI-1 nuclear power plant (NPP), which is a 2772 MW two-loop pressurized water reactor (see the system scheme shown in Figure 6).Figure 6
Scheme of the TMI PWR benchmark.In order to simulate a SBO initiating event we need to consider also the following electrical systems (see Figure7):(i)
Primary power grid line 500 KV (connected to the 500 KV switchyard).(ii)
Auxiliary power grid line 161 KV (connected to the 161 KV switchyard).(iii)
Set of 2 diesel generators (DGs), DG1 and DG2, and associated emergency buses.(iv)
Electrical buses: 4160 V (step-down voltage from the power grid and voltage of the electric converter connected to the DGs) and 480 V for actual reactor components (e.g., reactor cooling system).(v)
DC system which provides power to instrumentation and control components of the plant. It consists of these two subsystems:
(a)
Battery charger and AC/DC converter if AC power is available.(b)
DC batteries: in case AC power is not available.Figure 7
Scheme of the electrical system of the PWR model.


## 3.2. SBO Scenario

The scenario considered is a loss of offsite power (LOOP) initiating event caused by an earthquake followed by tsunami-induced flooding. Depending on the wave height, it causes water to enter into the air intake of the DGs and temporary disable the DGs themselves. In more detail, the scenario is the following (see Figure8):(1)
An external event (i.e., earthquake) causes a LOOP due to damage of both 500 KV and 161 KV lines; the reactor successfully scrams and, thus, the power generated in the core follows the characteristic exponential decay curve.(2)
The DGs successfully start and emergency cooling to the core is provided by the Emergency Core Cooling System (ECCS).(3)
A tsunami wave hits the plant causing flooding of the plant itself. Depending on its height, the wave causes the DGs to fail and may also flood the 161 KV switchyard. Hence, conditions of SBO are reached (4160 V and 480 V buses are not energized); all core cooling systems are subsequently offline (including the ECCS).(4)
Without the ability to cool the reactor core, its temperature starts to rise.(5)
In order to recover AC electric power on the 4160 V and 480 V buses, three strategies based on the Emergency Operating Procedures (EOPs) are followed:
(i)
A plant recovery team is assembled in order to recover one of the two DGs.(ii)
The power grid owning company is working on the restoration of the primary 161 KV line.(iii)
A second plant recovery team is also assembled to recover the 161 KV switchyard in case it got flooded.(6)
Due to its lifetime limitation, the DC battery can be depleted. If this is the case, even if the DGs are repaired, DGs cannot be started. DCs power restoration (through spare batteries or emergency backup DC generators) is a necessary condition to restart the DGs.(7)
When the 4160 KV buses are energized (through the recovery of the DGs or 161 KV line), the auxiliary cooling system (i.e., ECCS) is able to cool the reactor core and, thus, core temperature decreases.Figure 8
Sequence of events for the SBO scenario considered.


## 3.3. Stochastic Parameters

For the scope of this paper, the following parameters are uncertain:twave: time at which the tsunami wave hit the plant.h: tsunami wave height.tDG_rec: recovery time of the DGs.tPG_rec: recovery time of the 161 KV power grid.tbatt_fail: failure time of the batteries (DC system) due to depletion.tbatt_rec: recovery time of the batteries (DC system).For each of these parameters we will find the appropriate probability distribution function (see Section4.3) in order to evaluate core damage probability PCD. Core damage is reached when max clad temperature in the core reaches its failure temperature (2200 F).


## 4. Case Study Modeling

This section shows how this PWR SBO analysis is being performed using the RISMC toolkit described in Section2. In this respect, Figure 9 summarizes all the steps followed in this paper using the RISMC approach:(1)
Initiating event modeling: it includes modeling characteristic parameters and associated probabilistic distributions of the event considered.(2)
Plant response modeling: it includes modeling of the plant system dynamics.(3)
Components failure modeling: it includes modeling of specific components/systems that may stochastically change status (e.g., fail to performs specific actions) due to the initiating event or other external/internal causes.(4)
Scenario simulation: when all modeling aspects are complete (see previous steps), a set of simulations can be run by stochastically sampling the set of uncertain parameters.(5)
Given the simulation runs generated in Step 4, a set of statistical information (e.g., CD probability) is generated. We are also interested in determining the limit surface: the boundaries in the input space between failure and success.Figure 9
Overview of the RISMC approach to simulate initiating event and plant response using the RISMC toolkit.


### 4.1. Flood Modeling

A generic 3D facility model (see Figure10) with conditions similar to the Fukushima incident was created and used to simulate various tsunami flooding examples. For initial testing only a slice of the entire facility (containing just a single unit) was used; this includes(i)
turbine building,(ii)
reactor building,(iii)
offsite power facilities and switchyard,(iv)
diesel generator (DG) building.Figure 10
3D plant model developed to simulate flooding.The 3D model is used as the collision geometry for any simulations. For this demonstration all objects are fixed rigid bodies; future analysis will explore the possibility of moving debris (caused by the flood) and possible secondary impacts due to this debris.To mimic a tsunami entering the facility, a bounding container was added around the perimeter of the model and for the ocean floor. Then, over 12 million simulated fluid particles were added for the ocean volume. A wave simulator mechanism was constructed by having a flat planar surface that moves forward and rotates, pushing the water and creating a wave in the fluid particles.Various wave heights can be generated by minor parameter adjustments to the movement of the wave generator. As the fluid particles are initially forced forward their movement energy is transferred and affects the particles around them using the mathematical equations for fluid physics built into the fluid solver.There are many different approaches for simulating and optimizing fluid movement, each having different advantages and purposes. To achieve realistic and accurate results, a smooth particle hydrodynamics (SPH) based solver called NEUTRINO was used [17]. NEUTRINO also factors in advanced boundary handling and adaptive time stepping to help to increase accuracy and calculation speed. Most simulations were done using a sequential approach via 14 treads on seven cores at 2.4 Ghz and took approximately 3 minutes per frame with a total run time ranging from 75 to 90 hours depending on how many frames were needed for the simulation. With future code development, simulation time could be vastly improved by using distributed processing on computer cluster or coprocessor hardware.As the particles of a simulation move, they interact with the rigid bodies of the 3D model. The simulated fluid flows around buildings, splashes, and interacts in a similar manner to real water. Measuring tools can also be added to the simulation to determine fluid contact information, water height, and even flow rates into openings at any given time in the simulation. This information can be used in two ways, a static success or failure depending on wave height, or a dynamic result based on time could be used for more detailed analysis.Several simulations were run at different wave heights. The fluid penetration into the site is measured for each of the simulations to determine at what height the different systems fail. For our specific case, we are monitoring the venting for the DGs and the offsite power structures.As shown in Figure11 the fluid particles are penetrating both air intake vents for an 18 m wave. In more detail we know that at simulation time (or frame) 1275 DG1 fails from splash particles and DG2 fails at 1375.Figure 11
Time spacing between failures of generators due to fluid in the air intake vents of the generator room.


### 4.2. Plant Mechanistic Modeling

The reactor vessel model consists of the Downcomers, the Lower Plenum, the Reactor Core Model, and the Upper Plenum. Three core channels (components with a flow channel and a heating structure) were used to describe the reactor core. Each core channel is representative of a region of the core (from one to thousands of real cooling channels and fuel rods).In this analysis, the core model consists of three parallel core channels (hot, medium, and cold) and one bypass flow channel. Respectively, they represent the inner and hottest zone, the mid, and the outer and colder zone of the core. The Lower Plenum and Upper Plenum are modeled with branch models.There are two primary loops in this model: Loop A and Loop B. Each loop consists of the Hot Leg, a heat exchanger and its secondary side pipes, the Cold Leg, and a primary Pump. A pressurizer is attached to the Loop A piping system to control the system pressure. Since a complex pressurizer model has not been implemented yet in the current version of RELAP-7 code, a Time Dependent Volume (pressure boundary conditions) has been used instead.Figure12 shows the core layout of the PWR model. The core height is 3.6576 m. The reactor consists of 177 fuel assemblies subdivided into 3 zones. The 45 assemblies in zone 1 are represented by the hot core channel and the 60 assemblies in zone 2 and 72 assemblies in zone 3 are, respectively, represented by the average core channel and the cold core channel (see Figure 13). The fuel assembly geometry data is taken from [16]. The reactor is assumed to be at end of cycle (EOC), 650 EFPD (24.58 GWd/MHMt average core exposure), with a boron concentration of 5 ppm, and Xe and Sm at the equilibrium. The 3D core neutronics calculation results for the hot full power conditions are presented in [16].Figure 12
Screenshot of the PWR model of RELAP-7 using PEACOCK.Figure 13
Core zone correspondence (a) and assembly relative power (b) [3].
(a)
(b)Figure13 shows the relative assembly radial power distribution for a quarter of the core. Using the values presented in Figure 13, the power distribution fraction and power density for each core channel are calculated and shown in Table 1. The power density is used as input to the RELAP-7 model to calculate the heat source.Table 1
Power distribution factors for representative channels and average pellet power.
Core channel
Power distribution factor
Average fuel pellet power density (W/m3)
Hot
0.3337
3.90 108
Average
0.3699
3.24 108
Cold
0.2964
2.17 108


### 4.3. Plant and Flooding Probabilistic Modeling

While Section3.3 lists all the uncertainty parameters that are considered, this section focuses on the choice of probability distribution functions (pdfs) associated with these parameters.Regarding the time at which the tsunami wave hits the plant (i.e.,twave), we were not able to obtain a representative distribution. Such time is equal to the distance of the epicenter of the earthquake that generated the tsunami wave divided by the average speed of the wave itself. Given the absence of this information, we chose to represent the uncertainty associated with twave as a uniform distribution defined between 0 and 4 hours. Thus we expected that a representative simulated wave would hit the plant site within 4 hours.Regarding the DG recovery time (tDG_rec), we used as a reference: the NUREG/CR-6890 vol. 1 [18]. This document uses a Weibull distribution with α=0.745 and β=6.14 h (mean = 7.4 h and median = 3.8 h). This distribution represents the pdf of repair of one of the two DGs (choosing the one easiest to repair).For the PG recovery timetPG_rec we used as reference NUREG/CR-6890 vol.2 [19] (data collection was performed between 1986 and 2004). Given the four possible LOOP categories (plant centered, switchyard centered, grid related, or weather related), severe/extreme events (such as earthquake) are assumed to be similar to these events found in the weather category (these are typically long-term types of recoveries). This category is represented with a lognormal distribution (from NUREG/CR-6890) with μ=0.793 and σ=1.982.For the probability distribution for the wave height (h) we referred to [20] where an exponential distribution is defined. The average value of lambda (the characteristic parameter of the exponential distribution) is a function of return period (see Figure 14). The return period indicated the time span (in years) considered in the analysis. Figure 15 shows both probability and cumulative distribution functions (pdf and cdf) of wave heights h for three values of return periods (1, 10, and 100 years). For the scope of this paper, we assume a power uprate in conjunction with a 20-year life extension; thus, for a return period of 20 years we calculated a mean value of lambda equal to 0.206 m−1 (see Figure 14).Figure 14
Mean value of lambda as a function of return period.Figure 15
pdf and cdf of wave heighth for three different values of return periods (1, 10, and 100 years).Regarding battery life (i.e.,tbatt_fail), we chose to limit battery life between 4 and 6 hours using a triangular distribution. On the other hand, regarding the recovery time of the batteries (tbatt_rec), we used the method shown in [15] to model the pdf of human related actions. In [15], for human actions we looked into the SPAR-H [21] model contained in SAPHIRE. SPAR-H characterizes each operator action through eight parameters; for this study we focused on the two most important factors:(i)
Stress/stressors level.(ii)
Task complexity.These two parameters are used to compute the probability that an action will happen or not; the probability values are then inserted into the event trees that contain such events. However, from a simulation point of view we are not seeking if an action is performed but rather when such action is performed. Thus, we need a probability distribution function that defines the probability that an action will occur as a function of time.Since modeling of human actions is often performed using lognormal distributions [15] we chose a distribution where its characteristic parameters (i.e., μ and σ) are dependent on the two factors listed above (stress/stressors level and task complexity). We used Table 2 [15] to convert the three possible values of the two factors into numerical values for μ and σ.Table 2
Correspondence table between complexity and stress/stressor level and time values.
Complexity
μ (min)
Stress/stressors
σ (min)
High
45
Extreme
30
Moderate
15
High
15
Nominal
5
Nominal
5For the specific case of DC battery system restoration we assumed that the task has high complexity with extreme stress/stressors level. This leads toμ=45 min and σ=15 min.As part of the analysis we consider that the initiating event, that is, the tsunami wave, affects both the sequence of events and the probabilities associated with those events (see Figure16). In particular, Figure 16 summarizes how wave height affects system dynamics by using a simplified event-tree structure:(i)
Wave height and DGs loss: DGs are intact and functional if the wave does not reach the exhaust inlet.(ii)
Wave height and recovery time of PG (tPG_rec): the PG recovery time starts after the wave hits the plant. However, if the wave is high enough to reach the PG switchyard causing flooding on the switchyard itself then PG recovery time distribution tPG_rec is changed. This change reflects the fact that more time is needed to clear/repair the switchyard facility. For our case the distribution of tPG_rec is still lognormal but with a doubled mean value.Figure 16
Representation as ET structure of the RAVEN/RELAP-7 simulation. Note that the parameter characterizing the initiating event, that is, wave height, affects timing of the ET branches (e.g., PG recovery time).In conclusion, Table3 summarizes the distribution associated with each uncertainty parameter.Table 3
Probability distribution functions for sets of uncertainty parameters.
Parameter
Distribution
t
wave (h)
Uniform [0.0, 4.0]
t
DG_rec (h)
Weibull (alpha = 0.745, beta = 6.14)
t
PG_rec (h)a
Lognormal (mu = 0.793, sigma = 1.982)
t
PG_rec (h)b
Lognormal (mu = 1.586, sigma = 1.982)
t
batt_fail (h)
Triangular (4.0, 5.0, 6.0)
t
batt_rec (h)
Lognormal (mu = 0.75, sigma = 0.25)
h (m)
Exponential (lambda = 0.206)
aIf switchyard is not flooded by the wave.
bIf switchyard is flooded by the wave.


## 4.1. Flood Modeling

A generic 3D facility model (see Figure10) with conditions similar to the Fukushima incident was created and used to simulate various tsunami flooding examples. For initial testing only a slice of the entire facility (containing just a single unit) was used; this includes(i)
turbine building,(ii)
reactor building,(iii)
offsite power facilities and switchyard,(iv)
diesel generator (DG) building.Figure 10
3D plant model developed to simulate flooding.The 3D model is used as the collision geometry for any simulations. For this demonstration all objects are fixed rigid bodies; future analysis will explore the possibility of moving debris (caused by the flood) and possible secondary impacts due to this debris.To mimic a tsunami entering the facility, a bounding container was added around the perimeter of the model and for the ocean floor. Then, over 12 million simulated fluid particles were added for the ocean volume. A wave simulator mechanism was constructed by having a flat planar surface that moves forward and rotates, pushing the water and creating a wave in the fluid particles.Various wave heights can be generated by minor parameter adjustments to the movement of the wave generator. As the fluid particles are initially forced forward their movement energy is transferred and affects the particles around them using the mathematical equations for fluid physics built into the fluid solver.There are many different approaches for simulating and optimizing fluid movement, each having different advantages and purposes. To achieve realistic and accurate results, a smooth particle hydrodynamics (SPH) based solver called NEUTRINO was used [17]. NEUTRINO also factors in advanced boundary handling and adaptive time stepping to help to increase accuracy and calculation speed. Most simulations were done using a sequential approach via 14 treads on seven cores at 2.4 Ghz and took approximately 3 minutes per frame with a total run time ranging from 75 to 90 hours depending on how many frames were needed for the simulation. With future code development, simulation time could be vastly improved by using distributed processing on computer cluster or coprocessor hardware.As the particles of a simulation move, they interact with the rigid bodies of the 3D model. The simulated fluid flows around buildings, splashes, and interacts in a similar manner to real water. Measuring tools can also be added to the simulation to determine fluid contact information, water height, and even flow rates into openings at any given time in the simulation. This information can be used in two ways, a static success or failure depending on wave height, or a dynamic result based on time could be used for more detailed analysis.Several simulations were run at different wave heights. The fluid penetration into the site is measured for each of the simulations to determine at what height the different systems fail. For our specific case, we are monitoring the venting for the DGs and the offsite power structures.As shown in Figure11 the fluid particles are penetrating both air intake vents for an 18 m wave. In more detail we know that at simulation time (or frame) 1275 DG1 fails from splash particles and DG2 fails at 1375.Figure 11
Time spacing between failures of generators due to fluid in the air intake vents of the generator room.


## 4.2. Plant Mechanistic Modeling

The reactor vessel model consists of the Downcomers, the Lower Plenum, the Reactor Core Model, and the Upper Plenum. Three core channels (components with a flow channel and a heating structure) were used to describe the reactor core. Each core channel is representative of a region of the core (from one to thousands of real cooling channels and fuel rods).In this analysis, the core model consists of three parallel core channels (hot, medium, and cold) and one bypass flow channel. Respectively, they represent the inner and hottest zone, the mid, and the outer and colder zone of the core. The Lower Plenum and Upper Plenum are modeled with branch models.There are two primary loops in this model: Loop A and Loop B. Each loop consists of the Hot Leg, a heat exchanger and its secondary side pipes, the Cold Leg, and a primary Pump. A pressurizer is attached to the Loop A piping system to control the system pressure. Since a complex pressurizer model has not been implemented yet in the current version of RELAP-7 code, a Time Dependent Volume (pressure boundary conditions) has been used instead.Figure12 shows the core layout of the PWR model. The core height is 3.6576 m. The reactor consists of 177 fuel assemblies subdivided into 3 zones. The 45 assemblies in zone 1 are represented by the hot core channel and the 60 assemblies in zone 2 and 72 assemblies in zone 3 are, respectively, represented by the average core channel and the cold core channel (see Figure 13). The fuel assembly geometry data is taken from [16]. The reactor is assumed to be at end of cycle (EOC), 650 EFPD (24.58 GWd/MHMt average core exposure), with a boron concentration of 5 ppm, and Xe and Sm at the equilibrium. The 3D core neutronics calculation results for the hot full power conditions are presented in [16].Figure 12
Screenshot of the PWR model of RELAP-7 using PEACOCK.Figure 13
Core zone correspondence (a) and assembly relative power (b) [3].
(a)
(b)Figure13 shows the relative assembly radial power distribution for a quarter of the core. Using the values presented in Figure 13, the power distribution fraction and power density for each core channel are calculated and shown in Table 1. The power density is used as input to the RELAP-7 model to calculate the heat source.Table 1
Power distribution factors for representative channels and average pellet power.
Core channel
Power distribution factor
Average fuel pellet power density (W/m3)
Hot
0.3337
3.90 108
Average
0.3699
3.24 108
Cold
0.2964
2.17 108


## 4.3. Plant and Flooding Probabilistic Modeling

While Section3.3 lists all the uncertainty parameters that are considered, this section focuses on the choice of probability distribution functions (pdfs) associated with these parameters.Regarding the time at which the tsunami wave hits the plant (i.e.,twave), we were not able to obtain a representative distribution. Such time is equal to the distance of the epicenter of the earthquake that generated the tsunami wave divided by the average speed of the wave itself. Given the absence of this information, we chose to represent the uncertainty associated with twave as a uniform distribution defined between 0 and 4 hours. Thus we expected that a representative simulated wave would hit the plant site within 4 hours.Regarding the DG recovery time (tDG_rec), we used as a reference: the NUREG/CR-6890 vol. 1 [18]. This document uses a Weibull distribution with α=0.745 and β=6.14 h (mean = 7.4 h and median = 3.8 h). This distribution represents the pdf of repair of one of the two DGs (choosing the one easiest to repair).For the PG recovery timetPG_rec we used as reference NUREG/CR-6890 vol.2 [19] (data collection was performed between 1986 and 2004). Given the four possible LOOP categories (plant centered, switchyard centered, grid related, or weather related), severe/extreme events (such as earthquake) are assumed to be similar to these events found in the weather category (these are typically long-term types of recoveries). This category is represented with a lognormal distribution (from NUREG/CR-6890) with μ=0.793 and σ=1.982.For the probability distribution for the wave height (h) we referred to [20] where an exponential distribution is defined. The average value of lambda (the characteristic parameter of the exponential distribution) is a function of return period (see Figure 14). The return period indicated the time span (in years) considered in the analysis. Figure 15 shows both probability and cumulative distribution functions (pdf and cdf) of wave heights h for three values of return periods (1, 10, and 100 years). For the scope of this paper, we assume a power uprate in conjunction with a 20-year life extension; thus, for a return period of 20 years we calculated a mean value of lambda equal to 0.206 m−1 (see Figure 14).Figure 14
Mean value of lambda as a function of return period.Figure 15
pdf and cdf of wave heighth for three different values of return periods (1, 10, and 100 years).Regarding battery life (i.e.,tbatt_fail), we chose to limit battery life between 4 and 6 hours using a triangular distribution. On the other hand, regarding the recovery time of the batteries (tbatt_rec), we used the method shown in [15] to model the pdf of human related actions. In [15], for human actions we looked into the SPAR-H [21] model contained in SAPHIRE. SPAR-H characterizes each operator action through eight parameters; for this study we focused on the two most important factors:(i)
Stress/stressors level.(ii)
Task complexity.These two parameters are used to compute the probability that an action will happen or not; the probability values are then inserted into the event trees that contain such events. However, from a simulation point of view we are not seeking if an action is performed but rather when such action is performed. Thus, we need a probability distribution function that defines the probability that an action will occur as a function of time.Since modeling of human actions is often performed using lognormal distributions [15] we chose a distribution where its characteristic parameters (i.e., μ and σ) are dependent on the two factors listed above (stress/stressors level and task complexity). We used Table 2 [15] to convert the three possible values of the two factors into numerical values for μ and σ.Table 2
Correspondence table between complexity and stress/stressor level and time values.
Complexity
μ (min)
Stress/stressors
σ (min)
High
45
Extreme
30
Moderate
15
High
15
Nominal
5
Nominal
5For the specific case of DC battery system restoration we assumed that the task has high complexity with extreme stress/stressors level. This leads toμ=45 min and σ=15 min.As part of the analysis we consider that the initiating event, that is, the tsunami wave, affects both the sequence of events and the probabilities associated with those events (see Figure16). In particular, Figure 16 summarizes how wave height affects system dynamics by using a simplified event-tree structure:(i)
Wave height and DGs loss: DGs are intact and functional if the wave does not reach the exhaust inlet.(ii)
Wave height and recovery time of PG (tPG_rec): the PG recovery time starts after the wave hits the plant. However, if the wave is high enough to reach the PG switchyard causing flooding on the switchyard itself then PG recovery time distribution tPG_rec is changed. This change reflects the fact that more time is needed to clear/repair the switchyard facility. For our case the distribution of tPG_rec is still lognormal but with a doubled mean value.Figure 16
Representation as ET structure of the RAVEN/RELAP-7 simulation. Note that the parameter characterizing the initiating event, that is, wave height, affects timing of the ET branches (e.g., PG recovery time).In conclusion, Table3 summarizes the distribution associated with each uncertainty parameter.Table 3
Probability distribution functions for sets of uncertainty parameters.
Parameter
Distribution
t
wave (h)
Uniform [0.0, 4.0]
t
DG_rec (h)
Weibull (alpha = 0.745, beta = 6.14)
t
PG_rec (h)a
Lognormal (mu = 0.793, sigma = 1.982)
t
PG_rec (h)b
Lognormal (mu = 1.586, sigma = 1.982)
t
batt_fail (h)
Triangular (4.0, 5.0, 6.0)
t
batt_rec (h)
Lognormal (mu = 0.75, sigma = 0.25)
h (m)
Exponential (lambda = 0.206)
aIf switchyard is not flooded by the wave.
bIf switchyard is flooded by the wave.


## 5. Safety Margin Analysis

This section presents in detail the series of results obtained by using the flooding simulation code NEUTRINO and the RAVEN/RELAP-7 plant response code. We focus our attention to(i)
evaluate the impact of wave height on plant response (see Section5.1),(ii)
evaluate impact of power uprates on AC recovery timing (see Section5.2),(iii)
evaluate impact of power uprates on CD probability (see Section5.3).


### 5.1. Impact of Wave Height on DG and PG Status

We performed a series of simulations using the NEUTRINO code on the 3D plant model in order to measure plant response for several wave heights (see Section4.2) in the interval range of [030] meters. The basic idea is to build a response function that can be implemented in the RAVEN control logic that, depending on the sampled parameter h (wave height), it determines the status of both DGs and PG switchyard.We found that the DGs tended to fail with smaller waves than the PG structures because the DG building is closer to the ocean shore and air intake vents face the wave directly (see Figure17). In fact, if the wave is greater than 18 m, water enters in both DGs air intake while PG switchyard is flooded only for wave height greater than 30 m (see Table 4).Table 4
Status of the two DGs (DG1 and DG2) and the PG switchyard as a function of the wave height using the NEUTRINO simulation code.
Wave height (m)
DG1 status
DG2 status
Offsite power switchyard status
<17
Ok
Ok
Ok
17-18
Failed
Ok
Ok
18–30
Failed
Failed
Ok
>30
Failed
Failed
FailedFigure 17
Max flooding levels for several wave heights.Note that, given the fact that the 3D plant model represents only a partial slice of the site and there is only a small opening to the backside of the facility that allows water to reach the PG switchyard, the PG switchyard may fail with smaller waves if a more complete model would be used.


### 5.2. Impact of Power Uprate on AC Recovery Time

As a second step, we started to evaluate how power uprates change the time to reach CD for different values of DG failure time. Two facts need to be considered:(i)
A power uprate implies that a higher energy is generated within the core and, hence, clad failure temperature is reached sooner.(ii)
A late DG failure time allows the ECCS to successfully remove more heat from the RPV. Since the decay heat curve is exponential we expect that such dependency is not linear.This reduction in time to reach CD ranges from 3200 s to 4000 s; hence, on average the core reaches CD about an hour quicker if power level increases from 100% to 120%.


### 5.3. Probabilistic Analysis

While the analysis contained in Section5.2 deterministically measures timing reduction due to power uprate, it does not show how such uprate probabilistically changes the probability to reach CD. In other words, how does an average time reduction of one hour to reach CD modify the actual probability of the CD event itself?By using Latin Hypercube Sampling (LHS) available within the RAVEN statistical framework, we(i)
sampledN times the distribution of the uncertain parameters listed in Table 3,(ii)
ranN times RAVEN/RELAP-7 simulations with simulation parameter values changed accordingly to the sample values (generated in Step 1),(iii)
evaluated the overall CD probability by looking at the outcome of each RAVEN/RELAP-7 simulation.Using the RAVEN statistical framework (see Section2.2) we performed LHS of the distributions associated with the uncertain parameters listed in Table 3. We performed this sampling for both power levels: 100% and 120%. We then divided all the simulated scenarios (10,000 simulations for each power level) into four groups according to the ET structure shown in Figure 16.From the obtained results, which are shown in Table5, we can note the following:(i)
Probability of core damagePCD (branch 4 of Figure 16) increases from 217.8×10-6 to 522.2×10-6, an increase of 76%. Thus, the change in probability is(1)ΔPCD=304.417×10-6.(ii)
Probability value associated with branch 1 (wave height does not disable DGs and, hence, AC power is always available throughout the simulation) since this value depends only on the wave height (i.e., ifh is less than 18 m).Table 5
Summary of the statistical analysis for 100% and 120% power levels.
Branch
Outcome
100%
120%
Counter
Probability
Counter
Probability
1
OK
3657
0.9740
3657
0.9740
2
OK
2764
18.32 10−3
2500
18.17 10−3
3
OK
2403
7.498 10−3
2239
7.344 10−3
4
CD
1176
217.8 10−6
1604
522.2 10−6A different way to view theΔPCD is to evaluate the limit surface [22] of the system: the boundaries in the input space (Ω) between failure region (ΩF) and success region ΩS. For our cases, Ω=ΩF∪ΩS.Obviously these boundaries are deterministically determined but probabilistic information can be generated by evaluating the CD probability as(2)PCD=∫ΩFpϖdϖ,where pϖdϖ is the probability associated with the volume dϖ of the input space.In our applications, this integral is calculated using the stochastic sampling capabilities available in the RAVEN statistical framework.Figure18 shows the limit surface obtained in a two-dimensional input space, that is, DG failure time versus AC recovery time, for the two different cases: 100% and 120% power. From the stochastic samples we generated the limit surface using Support Vector Machines (SVMs) [23, 24].Figure 18
Limit surface for 100% (a) and 120% (b) cases: AC recovery time versus DG failure time. Note how the failure regionΩF (red area) expands if power increases from 100% to 120%.
(a)
(b)When power increases it is expected that the failure region (red area) grows in the input space and, thus, also the probability of CD increases.The value ofΔPCD is simply(3)ΔPCD=∫Ω120F-Ω100Fpϖdϖ,where Ω120F and Ω100F are the failure regions for the 120% and 100% power values.


## 5.1. Impact of Wave Height on DG and PG Status

We performed a series of simulations using the NEUTRINO code on the 3D plant model in order to measure plant response for several wave heights (see Section4.2) in the interval range of [030] meters. The basic idea is to build a response function that can be implemented in the RAVEN control logic that, depending on the sampled parameter h (wave height), it determines the status of both DGs and PG switchyard.We found that the DGs tended to fail with smaller waves than the PG structures because the DG building is closer to the ocean shore and air intake vents face the wave directly (see Figure17). In fact, if the wave is greater than 18 m, water enters in both DGs air intake while PG switchyard is flooded only for wave height greater than 30 m (see Table 4).Table 4
Status of the two DGs (DG1 and DG2) and the PG switchyard as a function of the wave height using the NEUTRINO simulation code.
Wave height (m)
DG1 status
DG2 status
Offsite power switchyard status
<17
Ok
Ok
Ok
17-18
Failed
Ok
Ok
18–30
Failed
Failed
Ok
>30
Failed
Failed
FailedFigure 17
Max flooding levels for several wave heights.Note that, given the fact that the 3D plant model represents only a partial slice of the site and there is only a small opening to the backside of the facility that allows water to reach the PG switchyard, the PG switchyard may fail with smaller waves if a more complete model would be used.


## 5.2. Impact of Power Uprate on AC Recovery Time

As a second step, we started to evaluate how power uprates change the time to reach CD for different values of DG failure time. Two facts need to be considered:(i)
A power uprate implies that a higher energy is generated within the core and, hence, clad failure temperature is reached sooner.(ii)
A late DG failure time allows the ECCS to successfully remove more heat from the RPV. Since the decay heat curve is exponential we expect that such dependency is not linear.This reduction in time to reach CD ranges from 3200 s to 4000 s; hence, on average the core reaches CD about an hour quicker if power level increases from 100% to 120%.


## 5.3. Probabilistic Analysis

While the analysis contained in Section5.2 deterministically measures timing reduction due to power uprate, it does not show how such uprate probabilistically changes the probability to reach CD. In other words, how does an average time reduction of one hour to reach CD modify the actual probability of the CD event itself?By using Latin Hypercube Sampling (LHS) available within the RAVEN statistical framework, we(i)
sampledN times the distribution of the uncertain parameters listed in Table 3,(ii)
ranN times RAVEN/RELAP-7 simulations with simulation parameter values changed accordingly to the sample values (generated in Step 1),(iii)
evaluated the overall CD probability by looking at the outcome of each RAVEN/RELAP-7 simulation.Using the RAVEN statistical framework (see Section2.2) we performed LHS of the distributions associated with the uncertain parameters listed in Table 3. We performed this sampling for both power levels: 100% and 120%. We then divided all the simulated scenarios (10,000 simulations for each power level) into four groups according to the ET structure shown in Figure 16.From the obtained results, which are shown in Table5, we can note the following:(i)
Probability of core damagePCD (branch 4 of Figure 16) increases from 217.8×10-6 to 522.2×10-6, an increase of 76%. Thus, the change in probability is(1)ΔPCD=304.417×10-6.(ii)
Probability value associated with branch 1 (wave height does not disable DGs and, hence, AC power is always available throughout the simulation) since this value depends only on the wave height (i.e., ifh is less than 18 m).Table 5
Summary of the statistical analysis for 100% and 120% power levels.
Branch
Outcome
100%
120%
Counter
Probability
Counter
Probability
1
OK
3657
0.9740
3657
0.9740
2
OK
2764
18.32 10−3
2500
18.17 10−3
3
OK
2403
7.498 10−3
2239
7.344 10−3
4
CD
1176
217.8 10−6
1604
522.2 10−6A different way to view theΔPCD is to evaluate the limit surface [22] of the system: the boundaries in the input space (Ω) between failure region (ΩF) and success region ΩS. For our cases, Ω=ΩF∪ΩS.Obviously these boundaries are deterministically determined but probabilistic information can be generated by evaluating the CD probability as(2)PCD=∫ΩFpϖdϖ,where pϖdϖ is the probability associated with the volume dϖ of the input space.In our applications, this integral is calculated using the stochastic sampling capabilities available in the RAVEN statistical framework.Figure18 shows the limit surface obtained in a two-dimensional input space, that is, DG failure time versus AC recovery time, for the two different cases: 100% and 120% power. From the stochastic samples we generated the limit surface using Support Vector Machines (SVMs) [23, 24].Figure 18
Limit surface for 100% (a) and 120% (b) cases: AC recovery time versus DG failure time. Note how the failure regionΩF (red area) expands if power increases from 100% to 120%.
(a)
(b)When power increases it is expected that the failure region (red area) grows in the input space and, thus, also the probability of CD increases.The value ofΔPCD is simply(3)ΔPCD=∫Ω120F-Ω100Fpϖdϖ,where Ω120F and Ω100F are the failure regions for the 120% and 100% power values.


## 6. Conclusions

In this paper we have summarized the series of steps that are needed to evaluate a RISMC detailed demonstration case study for an emergent issue using RAVEN and RELAP-7. We studied the impacts of power uprates on a flooding induced SBO event using the RISMC toolkit. We started by modeling both the PWR system dynamics using the RELAP-7 code and the flooding scenario using the NEUTRINO code.Even though the RELAP-7 and NEUTRINO codes were not tightly coupled to each other (i.e., the flooding analysis causes triggers such as a DG failure that is captured in the RELAP-7 calculation), it was possible to evaluate the overall system response on a much greater level of detail than compared to classical ET/FT based methodologies.Our statistical analysis was performed using the RAVEN code which allowed us to evaluate the impacts of power uprates on the overall probability of core damage. We also determined how plant recovery procedures get reduced in time due to the power uprate itself.In this paper we particularly focused on steps that are necessary to complete such statistical analysis and the information that can be generated from it. This information can be used to perform decision-making for the three possible scenarios:(i)
Power uprate is feasible since core damage probability increaseΔPCD is below the acceptable limits.(ii)
Power uprate is not feasible since core damage probability increaseΔPCD is above the acceptable limits.(iii)
Even thoughΔPCD is above the acceptable limits, power uprate is feasible if recovery procedures are enhanced.For the third scenario, recovery procedure enhancement may include the following:(i)
Increase the height of the wave protection wall in order to reduce flooding level in the plant. This will act on the fraction of the wave height distribution that causes DG failure.(ii)
Improve AC emergency recovery procedures (e.g., FLEX system). This action acts directly on either the DG or PG recovery distribution (tDG_rec and tPG_rec), that is, a lower DG or PG average recovery time.(iii)
Move the DGs to a non-flood-prone area of the plant site.(iv)
Improve the bunkering of the DG building in order to reduce the likelihood of flood-caused failures.



---

*Source: 308163-2015-08-04.xml*