Title of paper - Diego Mandelli



Coupling of RAVEN and MAAP5 for the Dynamic Event Tree analysis of Nuclear Power PlantsC. PicocoThe Ohio State University, Columbus, OH, 43210; ?lectricité de France, EDF R&D, Palaiseau, 91120T. AldemirThe Ohio State University, Columbus, OH, 43210V. Rychkov?lectricité de France, EDF R&D, Palaiseau, 91120A. Alfonsi, D. Mandelli, C. RabitiIdaho National Laboratory, Idaho Falls, ID, 83420ABSTRACT: 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 purpose and coupled to simulators (e.g., ADAPT-MAAP4, ADAPT-MELCOR, ADS-RELAP, MCDET-MELCOR). The coupling of RAVEN and MAAP5 for performing a DET analysis of nuclear power plants is presented and illustrated for DET construction following a station blackout event in a pressurized water reactor.1. IntroductionProbabilistic 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 order 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 designated as Dynamic PRA/PSA (DPRA/DPSA) methodologies (Aldemir, 2013). These methodologies 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 systematically treated in the accident progression in DPRA/DPSA methodologies, as well as their impact on mutual interactions among stochastic (e.g., component failure and recovery) and dynamic (temporal evolution of the system) aspects with possible different 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 important 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 branching conditions are set, the DET is able to follow the possible event sequences starting from a given initiating event for the evaluation of the possible consequences. To perform such an analysis, at least two interconnected computer codes which exchange information are needed: A code which is able to simulate the behavior of the system as the system evolves according to the assumed branching conditions A driver code that creates different event sequences (branches) as the simulation progresses 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. Particularly, the simulator has to be able to:stop the simulation every time that a branching condition occurs;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 Research Institute, 2015) and RAVEN (Alfonsi et al., 2013) as the simulator and the driver codes for the analysis, respectively. RAVEN defines communication protocols via Application Programming Interface (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 behavior of the system as the accident sequences are created) and the driver (producing the different branches based on the user-defined branching conditions, as well as on the simulated accident progression). The paper is organized as follows. In Section 2, an overview of the two codes used for the DET generation (i.e., RAVEN and MAAP5) is given. In Section 3, the Python interface and the DET generation performed 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. Finally, in Section 5 some conclusions are drawn.2. software overview3379470269875Figure SEQ Figure \* ARABIC 1. Dynamic Event Tree scheme (Alfonsi et al., 2013)Figure SEQ Figure \* ARABIC 1. Dynamic Event Tree scheme (Alfonsi et al., 2013)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 probabilistic 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 ENvironment (RAVEN) is a code developed at the Idaho National 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 developed 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 others: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 scenarios using either DET or simply executing each scenario as a different point of the input spaceperform post processor analysis on the data generated by the driven code (e.g., basic statistics, search of the limit surface (Rabiti et al., 2016)).This work focuses on the RAVEN capability to generate DETs when coupled with a simulator. The different DET samplers provided within RAVEN include (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 branches are needed) and the non - occurrence of the event. The simulation of the new created branches are carried out until the following branching condition is met. The DET approach is shown schematically in Figure 1.At the end of the simulation, all the possible histories 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 accidents by modeling the physical phenomena both related 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 simulated 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 including 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 input 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 definition 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 mission 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 simulation, to use restart file and to restart with modified input file).3. THE INTERFACE and the generation of the dynamic event treeThe two codes, RAVEN and MAAP5, communicate through a Python interface that implements RAVEN’s API. In this section, we present the interface 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 corresponding 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 occurrence of the branch and their corresponding probability density function.For each of the previous variables, the corresponding threshold (in terms of dimensional values or a-dimensional cumulative distribution function (cdf)) that should trigger, when exceeded, the execution of a new branch corresponding to a different scenario.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 suppose 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 declaration occurs with a specific syntax: VARIABLE = $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 declared 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 occurring within the branch. For example, when the ‘ACREC’ meets the threshold (e.g., ACREC > 5000 s) then the AC power is recovered. The control logic allows the occurring of the branch only when the branching condition is met.Stop simulation condition. It is important for a DET analysis that the simulation stops every 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 simulation when any of the timer is activated (including 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 intermediate 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 automatically 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 requires 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 because 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 interface writes an xml file that allows RAVEN to create the new branches based on the information 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.-38735732155Figure SEQ Figure \* ARABIC 2: DET simulation progression logicFigure SEQ Figure \* ARABIC 2: DET simulation progression logicOnce the RAVEN and MAAP5 input files are created, the simulation of each sequence progresses as shown in Figure 2.4. THE CASE STUDYThe 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 followed in case of SBO (Metzroth, 2011) have been implemented within the MAAP5 input file. The fail34505905080Figure SEQ Figure \* ARABIC 3: Core levelFigure SEQ Figure \* ARABIC 3: Core levelure 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 following: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 respectively.3527425421005Figure SEQ Figure \* ARABIC 4: Break flow rateFigure SEQ Figure \* ARABIC 4: Break flow rateDC battery failure time is assumed to be described by triangular distribution with minimum 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 scenario, 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 either 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 demand. 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 occurrence of “core uncovery”;“Core uncovery time” ranges from 5257 s to 12853 s.As example results, Figure 3 and Figure 4 show, respectively, the temporal evolution of the core level and of the flow rate into the break for all the completed 54 histories.From Figure 3, it is possible to notice those sequences 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 recovery 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 occurrence 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. CONCLUSIONIn 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 technical aspects of the coupling have been pointed out with a particular emphasis on the requirements for the coupling (the necessity to stop the simulation every time a branching condition is met, the importance of using the restart files, etc.). The interface to allow RAVEN to communicate with MAAP5 has been also presented with all the tasks performed during the simulation. It has been shown how the interface creates the new MAAP5 input corresponding to the new branches based on the user defined thresholds defined within the RAVEN input and on the simulation progression and how the RAVEN and MAAP5 input have to be initially set for the analysis. A case study has been used to illustrate how the two codes works together to perform a complete DET analysis.REFERENCESAldemir, 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, USAHakobyan, A., Denning, R., Aldemir, T., Dunagan, S., Kunsman, D. 2006. A methodology for generating dynamic accident progression event trees for level-2 PRA. PHYSOR-2006 - American Nuclear Society's Topical Meeting on Reactor 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 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 Meeting 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. Nuclear Engineering and Design. DOI: 10.1016/j.nucengdes.2014.09.004, 2014. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download