8.1. COLLECTION OF PLANT DATA
The first important step in developing input data for the computer code for the plant under consideration is to collect the necessary documentation and other reliable sources of data; see also Annex I. The sources that serve as a basis for data collection may be as follows:
(a) Documentation on plant design;
(b) Technical specifications of equipment;
(c) Documentation gathered during the startup and commissioning of the installation;
(d) Operational documentation for the plant (limits and conditions, operating instructions, and records of operational regimes);
(e) ‘As built’ plant documentation.
All documents and other data sources used for the preparation of the input data need to be clearly identified and referenced.
If there is found to be a contradiction between the sources of information, this contradiction needs to be checked against a different independent source. An effective way to resolve a contradiction is to hold direct discussions with the operating organization. If documentation and/or data are missing or questionable, it is suggested that a walkdown of the plant be performed.
For the clarification of contradictory information, a comparison of data from plant to plant could also be carried out if the plants are similar (of the same type or of the same series) and if they were developed by the same general designer and equipment manufacturer. Such a comparison would need to be performed carefully owing to the fact that ‘sister plants’ cannot be guaranteed to be identical. In certain cases, if the missing data were replaced by truly plant specific data, the results of a comparison could be misleading.
All data necessary for the preparation of a particular computer code input deck can be compiled and formalized into a single specific document, called a ‘database for safety analysis’. This database needs to contain all necessary information, such as information on geometry, thermal and hydraulic parameters, material properties, characteristics of the control system and set points, and the range of uncertainties in plant instrumentation devices, including drawings and other graphical documents (Annex III). It would preferably be independent of the type of analysis and the computer code used. The database is subject to quality control, and relevant quality assurance procedures need to be applied.
8.2. ENGINEERING HANDBOOK AND INPUT DECK
The creation of a plant model for computer codes is an interactive procedure that includes the selection of a nodalization scheme and preparation of the code input deck, and documentation of these activities. Depending on the objectives of the analysis, the plant model, or the code input deck, could be accident dependent.
The engineering handbook needs to be developed in parallel with the development of the code input deck (Annex III). This handbook is a document containing a full description and records of how the database has been converted into an input deck for the particular computer code. The document contains details of:
(a) Methods and simplifying assumptions used to convert the technical plant data into the code input data;
(b) All calculations made to convert the technical plant data to the necessary format for the input deck;
(c) Nodalization schemes used for a single component as well as for the complete system being modelled;
(d) All modelling assumptions made, adequately described and explained.
The engineering handbook needs to allow a unique interpretation of, and the reproducibility of, the code input. This handbook is subject to quality control and related quality assurance procedures for the ongoing maintenance of the contents.
The nodalization scheme of the modelled system needs to be established using the basic guidelines given in the code user’s manual. This requires knowledge in depth of both the capabilities of the code and the specifics of the system modelled. Development of the nodalization scheme is typically an essential part of the preparation of the input data, since in most codes the quantification of the nodes plays an important part in the modelling of certain phenomena or specific effects in the system. However, refined nodalization does not always produce more precise analysis results. The adequacy of the nodalization needs to be confirmed by spatial convergence studies or on the basis of previous experience.
The final product of the preparation process for input data is the computer deck file for the input data, in the format needed by the code. It is advantageous to develop one ‘master’ input deck. Furthermore, it is strongly suggested that, before the final analysis is performed, the code version, the models selected by the user and the ‘master’ input deck be ‘frozen’ as they are and placed under strict control.
Any necessary changes, once the analysis has begun, need to be peer reviewed and then approved and implemented by the individual responsible for the control. All changes needed for a specific calculation should to be recorded and documented so that the point at which improvements or corrections of errors have been introduced into the ‘master’ can be traced. Note that any changes to the code may necessitate
that the code be revalidated to show that it is still sufficiently accurate for the intended use.
8.3. VERIFICATION OF INPUT DATA
When the new input deck is being developed, errors could be introduced by a developer at any stage of the development process from the preparation of the engineering handbook to the preparation of the final input deck. Since these errors could result in unacceptable faults in the analysis, their early detection and correction are important.
Verification of the input deck is needed to check its formal correctness; i.e. that no erroneous data have been introduced into it and that all formal and functional requirements are fulfilled accurately and therefore will permit its successful use.
Current practice in accident analysis is to apply, in a systematic manner, the complete verification process. The verification process gives the confidence required that the modelling needs have been met. Verification of the input data involves reviewing and cross-checking the input deck and confirming that no mistakes have been made so that the input deck is ready for application. An effective way to avoid possible subjective errors in the development of the code input deck is to apply any available code specific preprocessing software.
The verification of the input deck needs to be performed and documented by qualified individuals or groups who have not been involved in the development of the input data. The reviewers can be from either the same organization or a different organization. They need to have access to all relevant documentation. All errors that were detected and corrections that were made in the verification process need to be properly documented.
8.4. VALIDATION OF INPUT DATA
Validation is performed after the verified input deck is completed and before the accident analysis is started. The purpose of validating input data is to demonstrate that the model adequately represents the functions of the modelled systems.
Experience gained in the validation of the computer code and from the analysis of similar problems would be utilized in such a validation.
Validation of input data is an iterative process by means of which the correctness and adequacy of the plant models are confirmed so as to provide a good representation of the behaviour of the plant systems. The validation needs to assess whether the behaviour of the key performance parameters corresponds with reality.
The validation would include, but not be limited to, the following:
(a) Checking the spatial and time convergence of the nodalization, for example, by performing a sensitivity analysis in relation to changes in nodalization for a typical case of the analysis under consideration.
(b) Checking the energy and mass balances in the systems modelled, including long term system energy and mass balances. This can be done by: comparing the power generation in the heated structures with the surface heat flux;
comparing the power generation in individual components with the corresponding enthalpy rise; comparing the evaporation rate with the surface heat flux; comparing changes in mass inventories with the difference between the injection and leakage rates; checking the consistency of the flows in adjacent junctions.
(c) Checking the behaviour and response of individual components of the equipment or of the separate systems through determination of the respective boundary conditions.
(d) Checking the steady state conditions for different operational states, preferably by comparison with real plant data.
(e) Comparing the fluid volume and pressure distributions of the model with the height and pressure drops of the real installation.
(f) Performing a comparison between the NPP behaviour predicted by calculations with relevant data from measurements in integral test facilities.
(g) Checking the computational results against real plant data from operational events.
In relation to each of the aforementioned items, quantitative acceptance criteria for the code input deck could already be available or they could be established.
The plant data collected during commissioning and startup tests, conducted under well controlled conditions and with additional instrumentation, are very useful and need to be applied for validation of the input data. However, in some cases, such data may differ from the data obtained during plant operation. Consideration needs to be given to such differences where applicable.
For the validation process it is advisable to use tools for graphical display of the nodalization and simulation of the plant states.