1. INTRODUCTION

Probabilistic Risk/Safety Assessment (PRA/PSA) includes all the methodologies used to determine the risk associated with a nuclear power plant in terms of possible accident scenarios, their probabilities of occurrence and consequences. Traditionally, the Event-Tree (ET)/Fault-Tree (FT) approach has been used to generate the possible accident sequences arising from an initiating event, when a set of events, selected by the analysts, can either occur or not along the accident evolution.

The ET/FT methodology presents, however, some limitations in view of the fact that the interaction among hardware/process/software/human behavior through time is not explicitly accounted for. The or-der of events is preset by the analyst, often resorting to the use of expert judgement.

In order to overcome these limitations, new methodologies have been proposed which are desig-nated as Dynamic PRA/PSA (DPRA/DPSA) methodologies (Aldemir, 2013). These methodolo-gies integrate the phenomenological analysis within the probabilistic framework, explicitly accounting for the time of occurrence of the events relevant to the accident evolution. As a consequence, both aleatory and epistemic uncertainties are systemati-cally treated in the accident progression in DPRA/DPSA methodologies, as well as their impact on mutual interactions among stochastic (e.g., compo-nent failure and recovery) and dynamic (temporal

evolution of the system) aspects with possible differ-ent levels of component failures (Aldemir, 2013; Zio, 2014).

The Dynamic Event Tree (DET) method has been developed in this context. With respect to the static ET/FT approach, the explicit modeling of the time of occurrence of events in DETs leads to an impor-tant advantage. Indeed, the decision to branch is made using the output from plant simulators rather than the often-subjective judgment of the analyst. Consequently, once the basic events and the branch-ing conditions are set, the DET is able to follow the possible event sequences starting from a given initi-ating event for the evaluation of the possible conse-quences. To perform such an analysis, at least two interconnected computer codes which exchange in-formation are needed:

A code which is able to simulate the behav-ior of the system as the system evolves ac-cording to the assumed branching conditions

A driver code that creates different event se-quences (branches) as the simulation pro-gresses and that computes the probability of occurrence of different branches.

In order to perform a DET analysis, in general, the simulator has to fulfill some requirements. Particu-larly, the simulator has to be able to:

stop the simulation every time that a branch-ing condition occurs;

Coupling of RAVEN and MAAP5 for the Dynamic Event Tree analysis of Nuclear Power Plants

C. Picoco

The Ohio State University, Columbus, OH, 43210; Électricité de France, EDF R&D, Palaiseau, 91120

T. Aldemir

The Ohio State University, Columbus, OH, 43210

V. Rychkov

Électricité de France, EDF R&D, Palaiseau, 91120

A. Alfonsi, D. Mandelli, C. RabitiABSTRACT: Dynamic Event Trees (DETs) have been developed within the context of Dynamic Probabilistic Risk Assessment (DPRA) in order to overcome the limitation of the static event-tree/fault-tree approach, namely that the interaction among hardware/process/software/human behavior through time is not explicitly accounted for. To build a DET for a given initiating event, two computer codes are required: a plant analysis code (simulator) and a scenario generator (driver). Different driver codes have been developed for this pur-pose and coupled to simulators (e.g., ADAPT-MAAP4, ADAPT-MELCOR, ADS-RELAP, MCDET-MEL-COR). The coupling of RAVEN and MAAP5 for performing a DET analysis of nuclear power plants is pre-sented and illustrated for DET construction following a station blackout event in a pressurized water reactor.

preferably, use the restart file to restart the simulation from the instant when it has been previously stopped;

allow to change variables within the input file from one branch to another and run it.

In the literature, different driver and simulator codes for generating DET are presented, such as ADAPT – MAAP4 (Rychkov et al., 2015), RAVEN – RELAP7 (Alfonsi et al., 2013), ADAPT – MELCOR (Hakobyan et al., 2006), MCDET – MELCOR (Hofer et al., 2002), ADS – RELAP (Chang, Mosleh, 1998).

In this work, we use MAAP5 (Electric Power Re-search Institute, 2015) and RAVEN (Alfonsi et al., 2013) as the simulator and the driver codes for the analysis, respectively. RAVEN defines communica-tion protocols via Application Programming Inter-face (API). An implementation of this API has been coded in Python programming language to couple the two codes allowing the simultaneous operation of both the simulator (describing the dynamic be-havior of the system as the accident sequences are created) and the driver (producing the different branches based on the user-defined branching condi-tions, as well as on the simulated accident progres-sion).

The paper is organized as follows. In Section 2, an overview of the two codes used for the DET genera-tion (i.e., RAVEN and MAAP5) is given. In Section 3, the Python interface and the DET generation per-formed by the two coupled codes is presented. In Section 4, a case study is provided in order to show the results obtained when an actual DET analysis is performed with RAVEN – MAAP5. The case study consists of a Station BlackOut (SBO) event in a Pressurized Water Reactor (PWR) where a set of emergency procedures has been implemented. Fi-nally, in Section 5 some conclusions are drawn.

2. SOFTWARE OVERVIEW

In Section 1 it has been pointed out how, in order to perform the DPRA/DPSA of a complex system and a DET analysis in particular, two codes are required. These two codes have to provide the dynamic model of the system under analysis and, secondly, a proba-bilistic framework able to create branches of the DET. In this section, an overview of the two codes selected for this work (i.e., RAVEN and MAAP5) is presented.

2.1 RAVENThe Reactor Analysis and Virtual control ENviron-ment (RAVEN) is a code developed at the Idaho Na-tional Laboratory (INL) for performing DPRA/DPSA. RAVEN is able to provide probabilistic and statistical framework based on the response complex system codes (Alfonsi et al., 2013). Originally de-veloped to provide risk analysis capabilities to the thermal-hydraulic code RELAP-7, the code has been thereafter coupled with different modules within the MOOSE environment (Gaston et al., 2009). RAVEN is therefore able to (Rabiti et al., 2016), among oth-ers:

model different probability density functions (both mono or multi-variate);

use different samplers (e.g., Montecarlo, Latin Hypercube Sampling, grid based, Adaptive);

Drive the execution of the generated scenar-ios using either DET or simply executing each scenario as a different point of the input space

perform post processor analysis on the data generated by the driven code (e.g., basic sta-tistics, search of the limit surface (Rabiti et al., 2016)).

This work focuses on the RAVEN capability to gen-erate DETs when coupled with a simulator. The dif-ferent DET samplers provided within RAVEN in-clude (Rabiti et al., 2016):

DET with aleatory sampling; Hybrid DET with aleatory and epistemic

sampling; Adaptive DET with goal-oriented aleatory

sampling; Adaptive Hybrid DET with goal-oriented

aleatory and epistemic sampling.

For the DET sampler, a set of branching conditions (expressed in terms of probability and/or values of the corresponding variables) are specified by the user within the RAVEN input. When one of these conditions is met, the simulation stops and two or more branches are generated corresponding either to the occurrence (with difference in magnitudes, if

Figure 1. Dynamic Event Tree scheme (Alfonsi et al., 2013)

branches are needed) and the non - occurrence of the event. The simulation of the new created branches are carried out until the following branching condi-tion is met. The DET approach is shown schemati-cally in Figure 1.

At the end of the simulation, all the possible histo-ries for the set of events taken into account starting from the initiating event will be available for further analysis (e.g., evaluation of the consequences).

2.2 MAAP5The Modular Accident Analysis Program Version 5 (MAAP5) is an integral severe accident analysis code whose development has been sponsored by the Electric Power Research Institute (EPRI). The code simulates the response of the light water reactor power plants during the evolution of severe acci-dents by modeling the physical phenomena both re-lated to the thermal-hydraulic aspects as well as to the fission products (MAAP5, 2015). In addition to the model of the primary circuit (where each single loop is separately modeled) and of the core, MAAP5 includes the model of the containment building and the auxiliary building. Consequently, the response of not only the reactor but of the entire plant is simu-lated in MAAP5, hence the attribute of ‘integral’ code (MAAP5, 2015). Qualified for both Level 1 and Level 2 PRA, MAAP5 computes the timing of important events in the severe accident analysis in-cluding time of core uncovery, the core damage and the vessel failure (MAAP5, 2015).

In order to run a simulation with MAAP5 at least two files are required: the parameter file and the in-put file. The parameter file provides a best-estimate, as-built, as-operated representation of the plant (MAAP5, 2015). It is usually plant specific and it contains the state of the plant including the set point for the activation of the safety systems, the defini-tion of the MAAP5 events (e.g., related to the state of the different systems of the plant) (MAAP5, 2015).

The MAAP5 input file contains the sequence to be simulated in terms of initiator events, actions to be taken when defined conditions are met, the mis-sion time, etc. (MAAP5, 2015). We will define the different branches of the DET in this file.

Finally, it is worth noticing that MAAP5 fulfills the requirements listed in the previous section for the DET analysis (i.e., capability to stop the simula-tion, to use restart file and to restart with modified input file).

3. THE INTERFACE AND THE GENERATION OF THE DYNAMIC EVENT TREE

The two codes, RAVEN and MAAP5, communicate through a Python interface that implements RAVEN’s API. In this section, we present the inter-face function and how the two input files (RAVEN and MAAP5) need to be set for a DET analysis.

The goal of the interface is to let the two codes to communicate in order to determine when to branch, write the new input files and run them, collect the output of the different branch simulations. Sections 3.1 and 3.2, respectively, describe RAVEN and MAAP5 inputs. The interface is described in Section 3.3.

3.1 RAVEN inputAs already mentioned, RAVEN is the driver of the DET. For this purpose, the RAVEN input has to contain:

The list of all the files required by MAAP5 in order to run a simulation (e.g., parameter, input, plotfil, etc.).

The stop simulation condition. This condition can be either: i) reaching of the mission time (the ‘END TIME’ declared within the MAAP5 input), or, ii) the occurrence of a given event either corresponding to a MAAP5 event (e.g., the core uncovery) or used-defined (e.g., the achievement of a given condition). In the second case, the user has to define the number of the correspond-ing event as listed within the MAAP5 files. For those sequences where the selected event never occurs the simulation continues up to the ‘END TIME’ declared within the MAAP5 input.

The list of the variables that trigger the oc-currence of the branch and their correspond-ing probability density function.

For each of the previous variables, the cor-responding threshold (in terms of dimen-sional values or a-dimensional cumulative distribution function (cdf)) that should trig-ger, when exceeded, the execution of a new branch corresponding to a different sce-nario.

For the sake of clarity, let’s consider an example. Suppose a branch occurs in a SBO accident leading possibly to the recovery of the AC power. Also sup-pose that the recovery time is described by a Weibull distribution and branches occur when it is equal to 5000 s and 7500 s. In this case, the user has to define in the RAVEN input firstly the Weibull distribution with its own parameters and secondly, define the

name of the MAAP5 variable corresponding to the AC power recovery time (e.g., ‘ACREC’) with the corresponding thresholds for the occurrence of the branches (e.g., 5000 s, 7500 s).

3.2 MAAP5 inputIn a similar way, MAAP5 input has to contain some special features. Here it is important to note that it is assumed that an initial input file exists for MAAP5. This input file will be then modified by the interface and run in each branch as the simulation progresses. The way the interface changes the input file will be clearer later in Section 3.3. The initial MAAP5 first input file has to contain:

The declaration of the variables that give rise to the different branches. This declara-tion occurs with a specific syntax: VARI-ABLE = $RAVEN-VARIABLE$. The use of this syntax allows the interface to distinguish the DET variables with those variables not leading to any branches and to replace these variables with the corresponding threshold (defined in the RAVEN input) within the MAAP5 file input. Referring therefore to the previous SBO example, this means that in the initial file the variable needs to be de-clared as ‘ACREC=$RAVEN-ACREC$’ and then ACREC will be then automatically modified by the interface within the branches as, for instance, ‘ACREC = 5000 s’.

The branching conditions and the events oc-curring within the branch. For example, when the ‘ACREC’ meets the threshold (e.g., ACREC > 5000 s) then the AC power is re-covered. The control logic allows the occur-ring of the branch only when the branching condition is met.

Stop simulation condition. It is important for a DET analysis that the simulation stops ev-ery time that a branching condition is met. The stop allows on one hand to create the two (or more) branches that have originated at that time point and on the other hand, to use the restart file. In order to do this, a timer needs to be activated every time that a branching condition is met. The initial stop simulation conditions block will contain therefore the instruction to stop the simula-tion when any of the timer is activated (in-cluding the timer for the end of the entire simulation).

The restart file is extensively used for DET analysis. The restart files consist in snapshots of the sequence that can be used to initiate the sequence at an inter-mediate time (MAAP5, 2015). The use of restart files allows to run each branch simulation starting

from the end of the parent branch, instead of running again the simulation history from the beginning, leading to a considerable resource savings.

3.3 InterfaceOnce both RAVEN and MAAP5 input files have been set, the simulation can be run and proceeds au-tomatically using the Python interface. The main tasks of the interface are the following:

Check that a branching condition exists for each variable defined in the RAVEN input and that a timer has been defined for each of them.

Update the ‘RESTART TIME’ and the ‘RESTART FILE’ within the MAAP5 input. Since we use the restart files, MAAP5 re-quires each input to have declared the time at which simulation has to restart and the name of the restart file to be used. These two pieces of information change from one branch to another and are in turn changed by the interface for each current MAAP5 input.

Update the stop simulation condition for the branch by removing the timer corresponding to the branches already occurred.

Once the MAAP5 simulation of one branch has ended, check if the simulation stops be-cause the condition declared in the RAVEN input (either mission time of occurrence of a specific event) has been reached. If yes, then the sequence is completed. Otherwise, the in-terface writes an xml file that allows RAVEN to create the new branches based on the in-formation provided by the interface itself within this xml file (such as which variable has caused the branching, which events have to occur or not due to the branches, recovery or not of the AC power).

Save the temporal evolution of the variables of interest (pressure, temperature, level, etc.) for each branch.

Once the RAVEN and MAAP5 input files are cre-ated, the simulation of each sequence progresses as shown in Figure 2.

4. THE CASE STUDY

The simultaneous operation of RAVEN and MAAP5 for the generation of the DET is illustrated in this section through a case study. Section 4.1 describes the scenario under consideration. Section 4.2 presents the results.

4.1 The scenarioThe scenario consists of a preliminary study of a SBO accident in a PWR. The procedure to be fol-lowed in case of SBO (Metzroth, 2011) have been implemented within the MAAP5 input file. The fail-ure on demand of various safety systems called upon during the evolution of the scenario have then been taken into account in generating possible scenarios, leading to the generation of the different branches of the DET.

The possible branching considered are the follow-ing:

AC power recovery is assumed to have a Weibull distribution with shape parameter k = 0.745 and scale parameter λ= 6.14. Branching for the AC power recovery time occurs at approximately 410 s, 5540 s, 8972 s, 13514 s and 28358 s corresponding to threshold in cdf 0.05, 0.3, 0.4, 0.5 and 0.7 re-spectively.

DC battery failure time is assumed to be de-scribed by triangular distribution with mini-mum at 4 h, maximum at 6 h and peak at 5 h. Branching for the failure of the DC battery (only if AC power has not been recovery yet) occurs at 16009 s and 19990 s corresponding respectively to a threshold in the cdf of 0.1 and 0.9.

At t = 360 s from the beginning of the sce-nario, the Turbine Driven Auxiliary Feed Water (TDAFW) is switched on. A failure can occur as the TDAFW is demanded.

A seal Loss of Coolant Accident (LOCA) is assumed to occur at t = 0 s corresponding to a flow rate of 21 gpm/Reactor Coolant Pump (RCP). At t = 780 s, the LOCA rate can ei-ther increase to 76 gpm/RCP, 182 gpm/RCP or 480 gpm/RCP or either been kept at 21 gpm/RCP. Multiple branches are used to simulate the occurrence of the different break sizes.

Possible charging pump failure upon de-mand.

4.2 ResultsThe simulation has lead to the following results:

• 126 branches simulated;

• 54 completed histories;

• 7 out of 54 histories end due to the occur-rence of “core uncovery”;

• “Core uncovery time” ranges from 5257 s to 12853 s.

As example results, Figure 3 and Figure 4 show, re-spectively, the temporal evolution of the core level and of the flow rate into the break for all the com-pleted 54 histories.

From Figure 3, it is possible to notice those se-quences ending with the core uncovery. It is worth recalling indeed that the simulation is such that the sequence ends if core uncover occurs, otherwise it continues up to the mission time that in this case is equal to 64800 s (18 h). Sequences when the recov-

Figure 4: Break flow rate

Figure 3: Core level

ery power allows to prevent the core uncover are also indicated on the plot.

The plot in Figure 4 illustrates the occurrence of the multiple branches and illustrates how the occur-rence at 780 s of the increase of the LOCA break size (i.e., from 21 gpm/RCP increases to 76 gpm/RCP or 182 gpm/RCP or 480 gpm/RCP), as well as the non-occurrence of the event (therefore the break size does not increase) leads to different behavior in the break flow.

5. CONCLUSION

In this paper the process of coupling of two codes, MAAP5 and RAVEN, for the generation of the DET starting from a SBO, has been presented. The techni-cal aspects of the coupling have been pointed out with a particular emphasis on the requirements for the coupling (the necessity to stop the simulation ev-ery time a branching condition is met, the impor-tance of using the restart files, etc.). The interface to allow RAVEN to communicate with MAAP5 has been also presented with all the tasks performed dur-ing the simulation. It has been shown how the inter-face creates the new MAAP5 input corresponding to the new branches based on the user defined thresh-olds defined within the RAVEN input and on the simulation progression and how the RAVEN and MAAP5 input have to be initially set for the analy-sis. A case study has been used to illustrate how the two codes works together to perform a complete DET analysis.

REFERENCES

Aldemir, T. 2013. A survey of Dynamic Methodologies for Probabilistic Safety Assessment of Nuclear Power Plants. Annals of Nuclear Engineering 52: 113-124.

Alfonsi, A. et al. 2013. Dynamic Event Tree Analysis through RAVEN. ANS PSA 2013 International Topical Meeting on Probabilistic Safety Assessment and Analysis, Columbia.

Chang, Y.H., Mosleh, A. 1998. Dynamic PRA using ADS with RELAP5 code as its thermal hydraulic module. Mosleh, A., Bari, R. (Eds.). PSAM 4, Springer-Verlag, New York: 2468-2473.

Gaston, D., Hansen, G. and Newmann, C. 2009. MOOSE: A Parallel computational framework for coupled system of nonlinear equations. INL/CON-08-15008. Idaho National Laboratory, Idaho Falls, Idaho, USA

Hakobyan, A., Denning, R., Aldemir, T., Dunagan, S., Kun-sman, D. 2006. A methodology for generating dynamic ac-cident progression event trees for level-2 PRA. PHYSOR-2006 - American Nuclear Society's Topical Meeting on Re-actor Physics, 9 p.

Hofer, E., Kloos, M., Krzykacz-Hausmann, B., Peschke, J., Woltereck, M. 2002. An approximate epistemic uncertainty

analysis approach in the presence of epistemic and aleatory uncertainties. Reliability Engineering and System Safety 77: 229-238.

Metzroth, K. 2011. A Comparison of Dynamic and Classical Event Tree Analysis for Nuclear Power Plant Probabilistic Safety/Risk Assessment. Electronic Thesis or Dissertation. Retrieved from https://etd.ohiolink.edu/

Modular Accident Analysis Program 5 (MAAP5) Applications Guidance: Desktop Reference for Using MAAP5 Software - Phase 2 Report. EPRI, Palo Alto, CA: 2015. 3002005285.

Rabiti, C., Alfonsi, A., Mandelli, D., Cogliati, J., Kinoshita, R., Sen, S. 2016. RAVEN User Manual, INL/EXT-15-34123, Idaho National Laboratory, 2016.

Rychkov, V., Kawahara, K. 2015. ADAPT-MAAP4 coupling for a dynamic event tree study. International Topical Meet-ing on Probabilistic Safety Assessment and Analysis, PSA 2015, 1, pp. 140-143.

Zio, E. 2014. Integrated deterministic and probabilistic safety assessment: Concepts, challenges, research directions. Nu-clear Engineering and Design. DOI: 10.1016/j.nucengdes.2014.09.004, 2014.