Adding accident models into a training simulator

Within a few weeks of the Fukushima accident several nuclear utilities contacted Corys to inquire about the possibility of incorporating severe accident simulation onto training simulators. There was an industry understanding that an improvement in the training for response to severe accidents would be one eventual outcome of Fukushima. Within a few months both Monticello and Calvert Cliffs had contracted Corys to install severe accident models onto their simulators. Subsequently, two other sites, Perry and Point Beach, also placed orders for the MELCOR models.

Two severe accident models were considered for use on training simulators, the MELCOR models, developed by Sandia National Laboratory for the NRC, and the MAAP code from EPRI. A team of experts from AREVA and Corys meet to determine which model would be the best fit for real time simulator training. Factors considered are how well the model is designed to run with the existing simulator models, the possibility of running in real time, and the complexity of the development effort. As the discussion progressed, the MELCOR models emerged as the obvious choice. Another important non-technical consideration was cost. In this case, there was no contest. The MELCOR models can be obtained at no cost, while the MAAP models require payment of a licence fee to EPRI.

Four main challenges

1.Running code in real time
Severe accident codes currently in world-wide use, including MELCOR, were designed and developed for use by scientists and engineering analysts studying the effectiveness of current and potential plant designs in mitigating the detrimental effects of serious events. There has historically been little consideration given to whether the computer programs can be completed in real time or faster-than-real time. This represents perhaps the most troublesome aspect of using severe accident codes to provide real-time simulation training.

2. Repeatability
A simulator system provides good repeatability if identical results are obtained every time a scenario is run from the same initial conditions. Since the severe accident code must run in a separate CPU thread (or on another computer system) from the remainder of the simulation, it is paramount to exchange variable information between the two processes as often as possible to get good repeatability.

3. Boundaries and model transitions
There was general consensus during the design stage that the existing THOR thermal-hydraulic simulation code package used by Corys should continue to be used as the code of choice for the primary systems models under all non-severe accident conditions. It would also continue to be used for the containment and balance-of-plant models, even under severe accident conditions. Two more challenges then are to define the boundaries between the severe accident model and the non-accident model, and to design a method of transitioning between the two codes.

4. Benchmarking and testing
The last challenge mentioned here is how to prove the effectiveness and accuracy of the completed project. Are any benchmarks or experimental testing results available?

MELCOR model development

1.Running code in real time
Corys found that it is possible to regulate the timing of the most accepted severe accident codes we considered, including MELCOR. By controlling the number of hydraulic nodes to a reasonable quantity, it is possible to run complex accident codesin real time, allowing a solution that can be integrated to an existing full-scope training simulator.

2. Repeatability
Good repeatability is ensured by communicating inputs and outputs between models ten times per second. All the important interfacing models are also run at the same rate. This lessens the chance of boundary conditions from diverting during rapid transients. Training was conducted by the Monticello plant training department following delivery of the upgraded simulator training load. Identical training scenarios were presented to the different operating crews and no problems were encountered with repeatability issues.

3. Model boundaries and transitions
After analyzing the phenomena that can occur during severe accidents, and the capabilities of the MELCOR models, it was determined that some of the capabilities present in the MELCOR codes are better left to existing simulator models. This includes the ECCS systems, containment systems, and radiation transport outside of the RCS.

It then became the primary task of the integration engineer to establish boundary conditions such as flow, pressure, enthalpy, radiation species transport and other physical properties, and to write the code to communicate these conditions between the two models.

• For the BWR reactor design, the boundaries are established at the reactor vessel nozzles. After transition to the MELCOR model, all phenomena occurring inside the reactor vessel are calculated by MELCOR, and all phenomena occurring outside remain within the original model's scope.
• For the PWR reactor design, the boundary conditions are extended beyond the reactor vessel to include all piping with the primary pressure boundary, due primarily to the hot gas flows resulting in creep-rupture failures that can occur outside of the reactor vessel, and that are exclusively modelled in MELCOR.

Transition has two aspects: 'when' and 'how.' The time to transition between the non-accident model and the severe-accident model is prior to the onset of fuel damage. This is done by monitoring the fuel cladding temperature and initiating the transition at a pre-determined high temperature, just below the temperature that rapid oxidation or melting is expected to occur.

How to transition is more complex and depends on the architecture of the two models, the one turning off and the one turning on. Suffice it to say that this was a significant challenge but was successfully met.

The basic process is: at transition time, a very detailed report of the current RCS conditions is written to an interface file by the non-accident RCS THOR model. The RCS portion of the THOR model then stops executing. Meanwhile, this interface file is read by the MELGEN process of the MELCOR code and a starting point is established for the execution of the MELCOR model. The MELCOR task then begins executing at the established iteration rate starting from these initial conditions. This entire process takes place in about a tenth of a second and is designed to be completely transparent to the trainees.

A decision was also made that once the transition to the severe accident model occurs, there is no going back to the non-accident model.

4. Benchmarking
Two benchmarks for test results were established. The first benchmark was to create a standalone MELCOR model of the nuclear unit simulator being built. The same problem initial conditions are fed to each model, each solution is run for as long as desired, and the results are compared.

The second benchmark chosen was the NRC "State-of-the-Art Reactor Consequence Analyses (SOARCA) Report".(NUREG-1935). The initial conditions and selected accident sequence were performed on the integrated Monticello-MELCOR model platform and the results of the test run were compared to the descriptions and plots provided in the NRC analyses study for the Peach Bottom plant. Monticello and Peach Bottom both have GE/BWR-4 nuclear reactors and GE Mark 1 containment designs. We anticipated differences in results due to some differences in the plants' designs and ratings, but we expected the overall sequence of events would follow a similar path.

Following MELCOR model integration with the full-scope simulator load, an accident scenario was developed for testing purposes. The scenario chosen followed the sequence of events and progression described in the NRC SOARCA analyses for the BWR short-term station blackout (unmitigated). At the time of reactor core model switchover from the non-accident code to MELCOR, an initialization file was written which could also be used by the standalone MELCOR model code. The standalone model was developed using the same structure and features as the integrated model but runs without input from the other models of the full-scope simulator. Each MELCOR model was run from the same initialization file and the outputs were compared.

Overall, the results from the two test runs compare very well. In the integrated model run, it took a little while longer for the fuel to achieve the highest temperatures and ultimately fail. The difference was attributed to some water mass located in the reactor recirculation loops in the integrated model, which flows into the reactor vessel during the scenario and provides some additional cooling. This effect is not present in the standalone model.

A comparison of the integrated model test result was also performed with the sequence of events description in the SOARCA analysis for the comparable accident sequence. The timing of the sequence of the major accident events (cladding oxidation, hydrogen production, fuel cell collapse, core plate failure, lower head dryout and failure) did not match as closely as with the standalone model test run sequence, however the events did occur in the same expected order.