Chapter 4: Safety Assessment

Computer codes for accident analysis

Types of computer codes

Computer codes for accident analysis can be classified in several categories depended on their intended use:

    • Reactor physics codes;
    • Fuel behaviour codes;
    • Thermal-hydraulic codes, including system codes, subchannel codes, porous media codes and computational fluid dynamics codes;
    • Containment analysis codes, possibly also with features for the transport of radioactive materials;
    • Structural analysis codes;
    • Severe accident codes; → See more.
    • Atmospheric dispersion and dose codes.

Classification of codes

Severe accident codes can be classified into three classes: fast running integral codes, detailed/mechanistic codes (usually slow running), and special (dedicated) codes:

    • Fast running integral codes: their models are less mechanistically based but more of a parametric character, i.e. model parameters allow the user to investigate the consequences of uncertainties on key results. These kinds of codes may also have been used for the design and validation of severe accident prevention and mitigation systems. However, to obtain realistic results, a deep knowledge of the involved physical phenomena as well as user experience in performing severe accident analysis are required. Some examples of fast running integral codes are MAAP, MELCOR and ASTEC.
    • Detailed codes model as far as possible all relevant phenomena in detail by mechanistic models. Basic requirements for detailed codes are that the modelling uncertainties are comparable with (i.e. not higher than) the uncertainties in the experimental data used to validate the code and that user-defined parameters are only necessary for phenomena which are not well understood due to insufficient experimental data. AC2, ICARE/CATHARE, SCDAP/RELAP5, COCOSYS and CONTAIN are examples of such detailed codes. In addition, ASTEC and MELCOR can be considered detailed codes, if the calculation is based on extensive nodalisation and detailed model options. The drawback of detailed codes is the long computational times required in the analysis. Furthermore, most phenomena which become relevant in the simulation after core damage are not completely understood yet, which precludes the possibility of a detailed analysis of this phase.
    • Special (dedicated) codes deal with single phenomena. Examples are MC3-D for steam explosions and ADINA-F for molten pool behaviour.

Code requirements

Three criteria can be used to judge the adequacy of the codes:

    • The use of internationally recognized and accepted codes provides some assurance that the codes are adequate for their intended application.
    • The codes should be able to simulate all the phenomena relevant for their intended use. Particularly for codes used for analysis of DBA, lists of important phenomena have been well established internationally. For codes for DEC, including conditions with core melting, the lists of important phenomena (and associated code models) are less well developed. However, formal peer reviews of the individual codes as well as other internationally sponsored documents are available (e.g. the report of the OECD Committee on the Safety of Nuclear Installations ( CSNI)The required level of model sophistication for severe accidents application is also described in IAEA SRS No. 56 on page 104. → Read more.
    • Individual codes need to be evaluated on a systematic basis, comparing the intended application of the code with the actual conditions for which the code is applied. For example, the application of parametric codes, developed strictly for severe accidents, to analysis for DBA conditions would be inappropriate.

Documentation

Each computer code needs to be adequately documented to facilitate review of the models and correlations employed, and to ensure that the models for important phenomena are appropriate and are not applied outside their range of validity. The documentation would also provide a description of the uncertainties of important models and the code itself for typical applications as well as a description of the code validation. The code documentation would also include user guidelines and input descriptions to ensure that the user can use the software properly.

Verification

Verification of the computer code should include a demonstration that the code (source code and algorithm) accurately represents the mathematical model of the real system (model verification) and conforms to the code documentation (system code verification). In general, the verification should ensure that the numerical methods, the transformation of the equations into a numerical scheme to provide solutions, and the user options and restrictions are appropriately implemented in accordance with the specifications.

Verification of the computer code should be performed by means of review, inspection and audit. Checklists may be provided for review and inspection. Audits may be performed on selected items to ensure quality.

Verification of the computer code should be performed to review the source coding in relation to its description in the code documentation. The verification should include a review of the design concept, basic logic, flow diagrams, algorithms and computational environment. If the computer code is run on a hardware or software platform (e.g. operating system) other than the one on which the verification process was carried out, the validity of the code verification for the intended platform should be assessed. Verification of the source coding should be performed to demonstrate that it conforms to accepted programming practices and that its logic is consistent with the code documentation.

A complex computer code may include the integration or coupling of simpler codes. In such cases, verification of the complex code should ensure that the links and/or interfaces between the codes are correctly designed and implemented to meet the code documentation.

Validation

Validation of the computer code should be performed to determine whether the mathematical models used in the code are an adequate representation of the real system being modelled. Outputs of the code should be compared, as far as possible, with observations of the real system or experimental data. Validation of the computer code should provide confidence in the ability of a code to predict, realistically or conservatively as required, the values of the safety parameter or parameters of interest. The level of confidence provided by the validation should be appropriate to the type of analysis. For example, the scope of validation may be relaxed for codes used in severe accident analysis, in view of the limited experimental data available, in which case additional reliance should be placed on verification.
Validation of the computer code should be performed to assess the uncertainty in the parameter values predicted by the code. Outputs of the code should be compared with relevant experimental data and, if possible, with data from operational transients representing the important phenomena expected to occur.
Validation of the computer codes used in complex analysis should be performed in two phases: the development phase, in which the validation assessment is performed by the code developer; and the independent assessment phase, in which the validation assessment is performed by the code user.
The validation should ideally include comparisons of code outputs with results from four different types of test:

    • Basic tests: These are simple test cases, which might not be directly related to a nuclear power plant. These tests may have analytical solutions or may use correlations or data derived from experiments.
    • Separate effect tests: These are designed to highlight specific phenomena that may occur at a nuclear power plant, but do not address other phenomena that may occur at the same time. Separate effect tests should ideally be performed at full scale. If not, appropriate attention should be paid to possible scaling effects.
    • Integral effect tests: These are test cases that are directly related to a nuclear power plant. All or most of the relevant physical processes are represented simultaneously. However, these tests may be carried out on a reduced scale, may use simulant materials or may be performed under different boundary conditions, compared to a nuclear power plant.
    • Nuclear power plant level tests and validation through operational transients: Nuclear power plant level tests are performed on an actual nuclear power plant, for example during the commissioning phase. Validations through operational transients, together with nuclear power plant tests, are important means of qualifying the plant model.
For more information see SSG-2 (Rev. 1) Read more →

Since for severe accident conditions, the availability of data is much more limited, phenomenological data are used more extensively to help develop models while integral data are used more for code validation. Integral data are available for the early phase of severe accidents, but data for the late phase of severe accidents are obtained primarily from separate effects experimental facilities, using simulant materials in many cases. International standard problems provide a particularly valuable source of information for code validation, since the experiments are well documented and extensive code-to-code and code-to-data comparisons are performed. Plant data from TMI-2, Chernobyl and (partially) Fukushima-Daiichi are available for the validation of severe accident models.