ML20072E187
| ML20072E187 | |
| Person / Time | |
|---|---|
| Issue date: | 06/30/1983 |
| From: | Silling S NRC OFFICE OF NUCLEAR MATERIAL SAFETY & SAFEGUARDS (NMSS) |
| To: | |
| References | |
| NUREG-0856, NUREG-856, NUDOCS 8306240060 | |
| Download: ML20072E187 (20) | |
Text
Final Technical Position on Documentation of Computer Codes for High-Level Waste Management l
l 3
U.S. Nuclear Regulatory Commission Offico of Nuclear Material Safety and Safeguards l
S. A. Silling i
f* %,
9 N
R886308 8
R 0856 R PD
,~.. -., -
NOTICE.
l Availability of Reference Materials Cited in NRC Publications
-; Most documents cited in N RC publications will be available from one of the following sources:
- 1. The NRC Public Document Room,1717 H Street, N.W.
B-Washington, DC 20555 I
- 2. The NRC/GPO Sales Program, U.S. Nuclear Regulatory Commission,
- Washington, DC 20555 ;
- 3. ' The National Technical Information Service, Springfield, VA 22161 Although the listing that'follows represents the _ majority of documents cited in NRC publications,
~
L
- it is not intended to be exhaustive.
Referenced documents available for inspection and copying for a fee from the NRC Public Docu ment Room include N RC correspondence and internal NRC memoranda; NRC Office of Inspection
and Enforcement bulletins, circulars, information notices, inspection and" investigation notices; Licensee Event Reports; vendor reports and correspondence; Commission papers;and applicant and 1
licensee documents and correspondence.
l The following document's in the NUREG series are available for purchase from the NRC/GPO Sales -
F Program:. formal _ NRC staff and contractor reports, NRC-sponsored conference proceedings, and -
N RC booklets and brochures. Also available are Regulatory. Guides, NRC regulations in the Code of l Federal Regulations, and Nuclear Regulatory Commission issuances.
Documents available from-the National Technical Information. Service include NUREG series -
1i reports and technical reports prepared by other federal agencies and reports prepared by the Atomic.
Energy Commission, forerunner agenc' to the Nuclear Regulatory Commission.
I y
f' Documents available from public and special technical libraries'. include all open literature items,-
j-such as books, journal and periodical articles, and transactions. Federal Register notices, federal and.
state legislation, and congressional reports can usually be obtained from these libraries.-
Documents such as theses, dissertations, foreign reports and translations, and non-NRC conference?
I proceedings are available for purchase from the organization sponsoring the publication cited.'
- Single copies of NRC draft reports are available free upon written request to the Division of Tech-nical information and Document Control, U.S. Nuclear Regulatory Commission, Washington, DC 20555.
Copies of industry codes and standards used in a substantive manner in the NRC regulatory process 4
I are maintained at the NRC Library, 7920 Norfolk Avenue, Bethesda, Maryland, and are available1 there for reference-use by the public. Codes and standards are usually copyrighted and may be purchased from the originating organization orrif they are _American National Standards, from the American National Standards institute,1430 Broadway, New York, NY 10018.
GPO Printed copy price:
$3.00-i i
,,m
. ~. ~.., ---,~-.
NUREG-0856 Final Technical Position on
- Documentation of Computer Codes
~ for High-Level Waste Management i
ats u shed u e1 S. A. Silling Divi 2 ion of Waste Management Office of Nuclear Material Safety and Safeguards U.S. Nuclear Regulatory Commission Washington, D.C. 20666 p* =*e va W) l
l ABSTRACT Guidance is given for the content of documentation of computer codes which are used in support of a license application for high-level waste disposal.
The guidelines cover theoretical basis, programming, and instructions for use of the code.
I I
f
?!
l i
i t
l l
I e
l NOTICE NUREG-0856 is being issued to i
provide guidance that NRC staff believes should be followed to partially meet the requirements of 10 CFR 60.
NUREG-0856 is not a substitute for the regulations, and compliance is not a require-ment.
- However, an approach or method different from the guid-ance contained herein will be accepted only if the substitute approach or method provides a basis for determining that the above-cited regulatory require-ments have been met.
This report supersedes NUREG-0856, the draft of this technical posi-tion pyblished December 1981.
f r
i
{
\\
I
TABLE OF CONTENTS fage 1
I.
Introduction.
3 II.
Definitions......
3 II.
Documentation Guidelines...............
A.
Sof tware Summary.
3 B.
Mathematical Models and Numerical Methods....
4 6
C.
User's Manual.
D.
Code Assessment and Support.
9 E.
Continuing Documentation and Code Listings....
10 12 Exhibit 1.
Software Summary Form.
l l
4 I
i i
i
1 1
DOCUMENTATION OF COMPUTER CODES FOR HIGH-LEVEL WASTE MANAGEMENT i
I.
INTRODUCTION The NRC anticipates that DOE will make use of computer codes in providing thn " reasonable assurance" required by 10 CFR 60.
Accordingly, it is ntcessary for NRC to evaluate these codes-in its licensing review.
The purpose of NRC's evaluation is to ensure that the codes are based on t
sound physical and mathematical principles, and that these principles are correctly applied.
In order to provide the NRC staff with an adequate basis for this evaluation, complete documentation of the codes is necessary.
This technical position describes guidelines for documentation of.the codes used by the applicant in performing the analyses submitted in support.of a license application under 10 CFR 60.
As a basis, the guidelines draw on ANSI (American National Standards Institute) Standard N-413, Guidance for the Documentation of Digital Computer Programs.
However, many items in the ANSI standard are expanded upon in order to better suit the requirements of high-level wasta licensing.
In particular, this technical position calls for thtoretical documentation in much more depth than the ANSI standard rsquires.
This more detailed treatment of the basic methods is necessary for high-level waste licensing applications because of the anticipated importance that modeling will have in licensing decisions and because certain codes that will be used are relatively new.
The documentation called for is divided into five categories:
(1) Software Summary (2) Description of mathematical models and numerical methods (3) User's manual (4) Code assessment and support (5) Continuing documentation and code listings 1
The sof tware summary is a one page document identifying the code and its b
purpose; a form is provided in' Exhibit 1.
d e,-
. - - - ~
~
w
---,n
2 The documentation of mathematical models and numerical methods will provide the basis for NRC's review of the theory and means of solution used in the code.
It should contain derivations and justification for the model.
Mathematical models and numerical methods have been combined into one category because in many modeling procedures the two aspects are so closely related that documenting them separately is inconvenient.
However, separate documentation of the mathematical model and its numerical representation is acceptable, providing the documents are adequately cross-referenced.
The user's manual has two functions for lic'nsing review.
First, it helps the NRC staff in understanding modeling results which are submitted by the applicant during the licensing process.
Second, it permits NRC to install and use the code on its own computer.
The documentation on code assessment and support describes to what extent and how the code has been validated and verified.
It also documents the various code versions in use and the steps being taken to control and maintain these versions.
Its purpose in licensing is to keep all parties aware of the practical limitations of the code, to record application-oriented modifications, and to help ensure that the code is as error-free as possible.
The final category, continuing documentation, provides a means for informing NRC of changes in the codes and what is known about them.
It includes a provision for error reporting.
It also includes revisions of the first four categories of documentation.
This category includes computer-readable and paper source listings of the current version and new versions as they are released.
l l
The guidelines stated in this technical position refer primarily to l
content rather than format.
It is not necessary to write new documents l
if documentation exists which contains the information called for.
It is acceptable to augment existing documentation which is missing some of the information required.
The guidelines below are designed for scientific, engineering, and mathematical codes.
In developing the guidelines, it was assumed that j
the codes are batch-oriented rather than interactive.
If interactive codes are to be used, appropriate changes should be made in the documentation.
l 1
i 3
II.
DEFINITIONS Modal - A representation of a process or system.
Methtmatical model - A mathematical representation of a process or system.
Compsnent model - A logically distinct subset of a model.
Numerical method - A procedure for solving a problem primarily by a j
sequence of arithmetic operations.
Numerical model - A representation of a process or system using numerical methods.
Computer code - A set of computer instructions for performing the L
-operations specified in a numerical model.
l Varification - Assurance that a computer code correctly performs' the operations specified in a numerical model.
Validation - Assurance that a model as embodied in a computer code is a s
{
correct representation of the process or system for which it is l
intended.
III. DOCUMENTATION GUIDELINES A.
Software Summary i
Tha software summary is a one page document which identifies the code and version number and gives other basic information.
A ntw software summary should be sent to NRC when a new version is released or when major modifications are made.
NRC should be notified by letter or through submittal of a new software summary when new people are to bn designated as technical contacts.
(See part E).
l A' form for the software summary is provided in Exhibit 1.
The form may also.be obtained in Federal Information Processing Standard Publication 7
30 (FIPS PUB 30), available for sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, D.C.
20402.
Forms are also available as a GSA Federal Supply Stock Item, FSN 7540-118-8541.
L l
i i
r i
i t
i
-. s,, _ - _ - - -
4 B.
Mathematical Models and Numerical Methods This section should provide a complete explanation of the methods used.
As described below, it should include a derivation of and justification for the model and should clearly explain its capabilities and limitations.
It should contain extensive references to publications and point out places where new procedures were developed for the code being documented.
This section should be complete enough to stand alone as a basis for review of the methods used in the code.
The discussions of mathematical models and of numerical methods may be separated into different sections provided they are adequately cross-referenced.
(1) Statement and description of the problem.
Describe the overall nature and purpose of the general analysis in which the model will be used.
State which specific aspects of this analysis the model will be used for.
Indicate in general terms the information which goes into and comes out of the model.
(2) Structure of the system model.
If the complete model is comprised of smaller component models, as is frequently the case in large codes, describe briefly the role of each component model.
Show how each component model contributes to the overall solution of the problem.
Use flowcharts and block diagrams to describe the mathematical solution strategy.
(3) General numerical procedure.
Describe the numerical solution strategy and computational sequence.
Use flowcharts and block diagrams.
Give ' references for the basic numerical procedure.
If the method solves a large set of linear equations, show the structure of the equations and how the coefficients are determined.
Show how the numerical strategy is related to the mathematical strategy (e.g., how boundary conditions are introduced).
(4) Component models.
For each component model, provide the following:
(a) Purpose.
Describe the purpose and scope of the component model.
State in general terms the input to and output from the model and the way the information is processed.
If the model is used only in certain cases, state under what circumstances it is used.
5 (b) Assumptions and limitations.
Describe the assumptions and limitations of the component model, including simplifying assumptions about the geometry and behavior of the system.
Include the known ranges of validity of the model for all variables.
For empirical or semi-empirical models, state the range and type of data on which the model is based (e.g., field or laboratory data).
State any known uncertainty about the validity of the model.
(c) Notation.
Identify all algebraic variables used in equations.
Give the mathematical symbols used in both the fundamental equations and their equivalents in the numerical formulation.
Also give the computer variable name associated with each quantity.
(d) Derivation.
Give a reference for the original publication in which the component model appeared.
Give any additional references in which modifications of the model were presented that led to the final form.
Start the derivation from generally accepted principles.
Justi fy each step in the derivation and note how assumptions and limitations are introduced.
For empirical and semi-empirical models, describe how experimental data was used to arrive at the final form.
Clearly state the final mathematical form of the model.
It is acceptable to provide references to published material containing a derivation in lieu of a new derivation.
(e) Application.
Discuss the applicability of the component model to a geologic repository.
Point out any extrapolation of the model or use out of range.
Describe any restrictions on the use of the model, e.g.,
to a particular rock type.
State whether the validity of the model will be affected by unusual or extreme conditions, such as high repository temperatures.
(f) Numerical method type.
Characterize any numerical method used in the model which goes beyond simple algebra (e.g.,
finite-difference, Simpson's rule, cubic splines).
(g) Derivation of numerical model.
Derive the numerical i
procedure from the mathematical component model.
Give references for all numerical methods.
Give the final form of the numerical model and explain the algorithm.
If the numerical model produces only an 7
intermediate result, such as terms in a large set of linear equations which is later solved, explain how the intermediate results are used.
State what variabies are input to and output from the component model.
i l
[
l l
l I
6 (h) Location.
State where the component model is located within the code.
Refer to the code listing which will be part of the documentation. (See part E(6)).
(i) Numerical stability and accuracy.
Discuss the stability and accuracy of the numerical model.
Distinguish between those aspects of stability and accuracy which have been proven mathematically and those which have not been proven but have been observed in practice.
(j) Alternatives.
Briefly discuss alternatives to the component model and state why this one was selected.
(5) Experience.
Discuss the overall performance of the entire model.
Note the conditions under which the model gives good or bad results.
Point out specific component models known to perform poorly under certain circumstances.
Give any general rules or recommendations to follow in use of the models.
C.
User's Manual The user's manual, for purposes of licensing review, plays two roles.
First, it allows NRC staff to understand modeling results submitted by the applicant.
Second, it permits NRC to install and run the code on its own computer.
The user's manual together with the code listing required in part E should be sufficient to instruct the user on how to set up and run problems as well as resolve possible difficulties.
If any of the items below are documented fully in comment cards in the code or by self-documenting features, the lines in the code which contain these comment cards or features may simply be referred to in place of a detailed description in the user's manual.
However, the information must be complete enough to enable a new user with a reasonable amount of programming experience to run the code and understand errors.
(1) Program considerations.
(a) Program options.
Discuss the function of each major program option; give special attention to effects of combinations of options.
Relate options to the input values which control them.
e (b) Program paths.
Describe the purpose of each subroutine.
Use flowcharts and block diagrams to explain the paths the program can take.
If parts of the code are executed only under certain
7 conditions, state those conditions.
Show how the computational sequence and solution strategy described in part B(3) are related to the program flow.
(c) Data structures.
Discuss how data are stored during computation.
Describe the purpose and content of important common blocks and arrays.
State the array dimensions.
If dynamic dimensioning is used, describe the indexing algorithm.
This section, together with a code listing, should be sufficient to allow the user to follow the flow of important data through'the computational sequence.
(d)
Initialization.
Provide any values automatically assigned to important variables.
These should include values of physical significance and parameters which affect program execution.
State where the values are initialized and whether they are default or fixed values.
(e) Restart procedures.
Describe any restart capabilities of the code and how they are used.
(f) Error processing.
Describe the points of origin and likely causes of all major error messages, error switches, and abnormal stops.
(2) Data files.
(a) Content.
Outline the general content, purpose, and organization of each data file.
(b) Use by program.
Describe how and when the files are read and written by the program.
l (c) Auxiliary processing.
Describe any available I
auxiliary programs which create, modify, or use the files.
(3)
Input data.
(a) General considerations.
I (i) Techniques.
Describe special input techniques and requirements; e.g.,
blank field treatment, order of items, field delineation.
t
8 (ii) Consecutive cases.
If the code is able to retain input data from previous cases, give conditions for retention and reinitialization.
(iii) Defaults.
Give the general conventions governing default values.
(b)
Individual input records.
(i) Record identifier.
Give the line identifier, if any, for this type of record.
(ii)
Input variables.
State the code variables which will co'ntain data given on this record.
(iii) Format.
Specify the format of this record, if any.
(iv) Need.
For each variable, specify whether input is necessary or optional for both start and restart runs.
(v) Repetition.
State how many of these input records are required or may be used optionally.
(vi) Units.
For each input field, state the
. dimensional units.
(vii) Default.
S ta'. e the default value, if any, for each field.
(viii) Description.
Define the meaning of each variable and discuss its primary use within the code.
State how the user should assign values in setting up a run.
(ix) Range.
State the acceptable lim'its for'each variable necessary for successful operation of the model in the programming sense.
(4) System interface.
(a) System-dependent features.
List the external references in the program which must be supplied by the system, and state
i l
9
-the purpose of each.
Include plot aad mathematical libraries, but omit standard Fortran intrinsic functions.
(b) Compiler requirements.
Specify what compilers have been used and any special load options that are necessary.
Include compiler options, such as indirect large core memory addressing.
.(c) Hardware requirements.
Describe any special features needed.
State the amount of central memory. required for a typical case, or give an algorithm for determining the required amount of memory.
(d) Control cards or command files.
All computer codes require some system comn. ands to control-program initiation, manipulation of files,'and interaction with other programs.
Describe the control cards or command files necessary to run the code as part of a modeling analysis.
The appropriate level of detail will depend on the degree to which control cards or command files contain logic affecting program flow, manipulation of files, and communication among programs.
Give sample control card files or command files.
Discuss application dependence.
(5) Output.
Discuss the code output.
Relate edited output to input options, and state the origin and meaning of the output variables.
Describe any normalizations of results and list associated dimensional units.
Describe any graphical capabilities of the code.
(6) Sample problems.
Choose a few problems which demonstrate how the code is used.
These problems need not have known solutions or experimental data.
However, they should exercise a large portion of the l
available programmed options and should use only a reasonable amount of computer time.
Input deck. listings and sample output should be given.
D.
Code Assessment and Support This document has the purpose of describing all work which sheds light on the adequacy of the code.
The goal of the document for licensing purposes is to ensure that the code has been extensively reviewed and validated.
In addition, the document describes steps the applicant is taking to ensure that code performance will not be degraded by future changes.
I (1) Model review.
Describe any projects for independent review of the methods used in the model.
Include past and ongoing i
l i
t 10 programs as well as planned ones.
Summarize the results of past reviews.
Describe any plans ~for modification of the model as a result of the reviews.
Give references for publications.
(2) Verification and validation.
Describe the program for verification and validation of the code.
Include past, ongoing, and planned future activities.
Give descriptions, input files, and results for specific tests.
The input decks should be appropriate for the code varsion de' livered to NRC (see part E).
State what aspects of the code
~
each test denenstrates and discuss how well the code performed.
Describe any plans for modification of the model as a result of the tests.
It is acceptable to provide reproductions of publications, output, and reports documenting the tests.
The above information should be given for two classes'of tests:
(a) tests by the code developer; and (b) independent assessment.
(3) Maintenance and quality assurance.
Often there are several versions of a code, each with different modifications, capabilities, and limitations.
For licensing purposes, it is not necessary to completely vr.rify and validate each version as though it were a separate code.
However, it is necessary to ensure that each version is as correct as possible and that an orderly procedure exists for keepinej track of the differences between versions.
Since this procedure relates directly to the adequacy of the code for licensing purposes, provide a description of the maintenance and, quality assurance programs for the code.
Include a brief chronology of the code versions.
E.
Continuing Documentation and Code Listings.
Codes generally continue to evolve even after a standard version has been l
released.
This evolution includes the development of new capabilities, the detection and repair of errors, and application-oriented modifications.
In order to ensure that licensing decisions are made on i
I the basis of up-to-date information, it is necessary that NRC be kept l
informed of changes in the codes.
t l
Continuing documentation includes revision of the other documentation and
=
l error reporting.
It also includes computer-readable and paper listings of the current version and new versions as they are released.
1
(
c
11 (1) Updated software summaries.
Submit a new software summary when the information it contains changes, when new code versions are released, or when important changes in the code are made.
(2) Technical contact.
Identify a person whom the NRC staff can contact directly with technical questions about installing and running the code.
NRC should be informed whenever a new person is given this responsibility.
(3) Documentation revisions.
Revise the documentation sent to NRC as needed when changes are made in the code, when errors are found in the existing documentation, when new limitations of the model are found, or when new results of the assessment program described in part D appear.
(4) Error reporting.
When errors or omissions that could affect the validity or appropriateness of model itself or specific instances of its use are found, these errors must be reported to NRC promptly.
This includes input errors.
Report action taken to correct the errors.
State the significance of the error in past, current, and future modeling activities.
(5) Computer files.
Send NRC computer files containing the current code version, new versions as they are released, and necessary updates as they are determined.
Include the input decks for the sample problems (see part C (6)).
Include all necessary library routines.
The means of transmittal may be any reasonably standard medium, although 9-track magnetic tapes are preferred.
The information should be in a standard format readable by a variety of computer systems.
All files should be accompanied by a printout from the runs which created them.
(6) Paper listings.
Provide printed listings of the current version, new versions as they are released, and updates.
Code listings should include line numbers from UPDATE or another text processing l
utility.
(7) Description of updates and new versions.
All updates and new versions delivered to NRC should be accompanied by descriptions of the changes.
(8) Response to NRC questions.
Provide responses to questions
[
by NRC concerning the model, its use, or installation.
Questions will l
state whether written response, response by telephone, or a meeting is required.
i 1
i l
l
12 EXHIBIT 1.
Software Summary Form.
i
FEL!RAL INFORMATION PROCESSING STANDARD SOFTWARE
SUMMARY
- 03. Summary date
- 02. Summary prepared by (Name and Pnene)
- 03. Summary action New Replacement Deletion Yr.
Mo.
Day l
l l
- 05. Sof tware sitie C
[
[
Previous Internal Sof =are ID
- 04. Sole =are date T r.
No.
Day j
l
}
- 07. Internal solimare ID
- 06. Short title
- 04. Sof t=are rype
- 09. Processing 10.
Application area mode Automated Data Computer Systems Management /
O System C Interactive O Support /Utilsey
[ Business Computer Program C Batch
[ Scientsfic/ Engineering O Process Control
[ Subroutine / Module O Combination O Babliographic/Testual O Other
- 11. Submitting organisation and address
- 12. Techascal contact (s) and phone
- 13. harrative
- 14. Keymords
- 15. Computer manut's and modet
- 16. Computer operating system
- 17. Programming languagea)
- 18. Number of source program statements
- 19. Compner nemory requirements
- 20. Tape drives
- 21. Disk / Drum units
- 22. Terminais
- 23. Other operational requirements
- 24. Sole =are availabalary
- 25. Documentation availabslity Available Limited in-house only Available inadequate In-house only o
o o
o i
1 i
- 26. FOR SutatiTTING ORGANIZ ATION USE i
l I
STANDARD FonM 18S JULY 1974 U S. DEPT. COMMERCE NOS (Fit $ PUS 30 l
i e -
(
U.S. NUCLEAR REGULATORY COMMIS$10N BIBLIOGRAPHIC DATA SHEET NUREG. 0856 G. TITLE AND SUBTITLE (Ade Volume No.,if earer,anr1
- 2. (Leave blat *J Final Technical Position on Documentation of Computer Codes for High-Level Waste Management
- 3. RECIPIENT'S ACCESSION NO.
- 7. OUTHO R(S)
S. DATE REPORT COMPLETED l"
S. A. Silling July 14A2
- 9. PE RFORMING ORGANIZATION N AME AND M AILING ADDRESS (lactu* 2,p Codel DATE nEPORT ISSUED MONTH lVEAR June 1983 Division of Waste Management Office of Nuclear Material Safety and Safeguards 6'*'**"
U. S. Nuclear Regulatory Comission wa c hi na tn n. nr 2nGGG s (tw unn*/
- 12. SPONSORING ORGANIZATION N AME AND M AILING ADDRESS (laclue lep Co*J 0 PROJE CT/ TASK / WORK UNIT NO Same as above.
- 11. FIN NO.
13 TY PE OF RE POR T PE RIOD COVE RE O I/nciumve damsl
- 15. SUP'*LEMENTARY NbTE S
- 14. (teave atm*1
- 16. ABSTR ACT 000 words or lessi Guidance is given for the content of documentation of computer codes which are used in support of a license application for high-level waste disposal. The guidelines cover theoretical basis, programming, and instructions for use of the code.
l l
- 17. CtE Y WORDS AND DOCUVE NT AN ALYSis 17a DE SCRIPTORS l
17n IDENTIFIE RS OPEN EN DE D TE RMS 18 AV AIL ABILITY ST ATEMENT
- 19. SE CURITY CLASS (Th
rlmOIZ O>r "UOe_
52 C2 cCocEi2. k FO$@;q O4 =
n_
r -
01 GS mO: Z 2 Fm<mr Edcdm EyZpc)m3mZH D
n o
a.
aA nPs cw s
aej s
m a, /'
a ir$
t a
pts o o s P
~
t,
- i, r
y q.
]
/
4 F
e i
f r c7 y
'i4,
(
.j N
]s O
u lt I
s;-
_i.
S P'
S 71 i-rW I
00 M5 3
5 4
M5 0
E SO2 SS E C
.SU T
C.
E E
Y N
A D
IT R
S O,
SA T
UV N
BRI T
A R E L TU G CO I
I N
NGI I F F
A A
R N
AW E
P EL C
U N
f1lll