ML20039C801
| ML20039C801 | |
| Person / Time | |
|---|---|
| Issue date: | 12/31/1981 |
| From: | Silling S NRC OFFICE OF NUCLEAR MATERIAL SAFETY & SAFEGUARDS (NMSS) |
| To: | |
| References | |
| NUREG-0856, NUREG-0856-DRFT, NUREG-856, NUREG-856-DRFT, NUDOCS 8112300254 | |
| Download: ML20039C801 (19) | |
Text
.
NUREG-0856 Draft Technical Position on Documentation of Model,xy,,
y 49-
- .s&;,c,y j g2 a
g-n
\\
k i
U.S. Nuclear Regulatory Commission Office of Nuclear Material Safety and Safeguards Compiled by S. A. Silling y necoq r
h {'
~
mu e.m
)bk[*5 p[m
7.
1 A
f t
m.
t c
i I
Available from GP05alesProgram Division of Technical Information and Document Control U.S._ Nuclear Regulatory Commission Washington, DC 20555' and National Technical Information Service Springfield, VA 22161 r
k t
s
?.
/
~
NUREG 'E56
/
Draft Technical Positio'n on Documentation of Models Aw
.a
%~,'
,j J'
/- /
j j'
s-
., - - +,
l-
/
s
'/}
Z_T _.
. _ _ _ _ E
__ n _ ___
. ___ _ _ f_ : 1. -. _.. _ _ _ _ _.
Manuscript Completed: September 1981
~
/ '
Date Published: December 1981 Compiled by j
S. A. Silling i,s s
S v.
Division of Waste Management Office of Nuclear Material Safety and Safeguards --
U.S. Nuclear Regulatory Commission Washington, D.C. 20555 pa aca,
o hhhb
- ese*
g 4-
. s' I
l,
//
.J
<~
Y
- e s
j e
o
/
~p x
.e 0
-4
?
i
/
,r i
- e., :-
/
e
~~c n
?
~;.~
9 A
'r
/
3 5
/!~ ~
ABSTRACT Guidance is given for the content of 4,
documentation on computer models which
-4 are used in support of a license appli-cation for high - level waste disposal.
The guidelines cover theoretical
- basis, programmir.9, and instructions for use of the model.
+
g?
f j
/
/
[
n er d
/
/
~
Mt.
f
}
4 f,
a s#
...w J
9
+4 f
f
>s
.f Yf
/
/
n A
c:
A x.
A )
ii L~.
l N
y
~w
.4 s
3 NOTICE
~
NUREG - 0856 is being issued to provide
- guidance that NRC staff believes should be followed. to partially meet the re-quirementss of 10 CFR 60. NUREG - 0856 is not a. substitute for the regulations, and compliance is not a requirement.
however, an approach or method different from the guidance contained herein will be accepted only if the substitute apfi"o~ ach or method provides a basis for determinirig that the above - cited regulatory requirements have been met.
~
,c-
~ _,
.. w mV t
g
\\
P Y
4 m
y em
'g
3 iii CONTENTS I
INTRODUCTION......................
1 II DOCUMENTATION GUIDELINES................ 3 EXHIBIT 1 - SOFTWARE
SUMMARY
FORM
............12 i
l l
l c
i 1
TECHNICAL POSITION ON DOCUMENTATION OF MODELS I.
INTRODUCTION The NRC anticipates that DOE will make use of analytical and computational models in providing the " reasonable assurances" required by 10 CFR 60.
Accordingly, it is necessary for NRC to evaluate these models in its licensing review. The purpose of NRC's evaluation is to ensure that the models are based on 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 models is necessary.
This technical position describes guidelines for documentation of the models used by the applicant in performing the analyses required by 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 waste licensing.
In particular, this technical position calls for theoretical documentation in much more depth then the ANSI standard requires.
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 ifcensing decisions and because certain models 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 l
(3) User's.nanual 1
(4) Moc'el assessment and support (5) Continuing documentation and code listings The sof tware summary is a one page document identifying the code and its purpose; a form is provided in Exhibit 1.
The documentation on mathematical models and numerical methods will provide the basis for NRC's review of the theory and means of solution i
e
2 used in the model.
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 documentat-lon 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 licensing 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 model on its own computer.
The documentation on model assessment and support describes to what extent and how the model 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 dll parties aware of the practical limitations of the model, to record application-oriented modifications, and to help ensure that the model is as error-free as possible.
The final category, continuing documentation, provides a means for informing NRC of changes in the models and what is known abeut 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.
The guidelines stated in this technical position refer primarily to content rather than format.
It is not necessary to write new documents 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 are designed for scientific, engineering, and mathematical models.
In developing the guidelines, it was assumed that the codes are batch-oriented rather than interactive.
If interactive codes are to be used, appropriate changes should be made in the documentation.
For documentation of analytical (non-computer) models, omit all the sections which apply specifically to computer codes.
3 II.
DOCUMENTATION GUIDELINES A.
Software Summary The software summary is a one page document which identifies the code and version number and gives other basic information.
A new 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 the people identified change.
(See part E).
A form for the software summary is provided in Exhibit 1.
The form may also be obtained in Federal Information Processing Standard Publication 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.
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 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 model being documented.
This section should be complete enough to stand alone as a basis for review of the methods used in the model.
The discussions of mathem&tical 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 solve.
Indicate in general terms the information which goes into and comes out of the model.
Show how the results of the model will be used in the overall analysis.
(2) Structure of the system model.
If the complete model is comprised of smaller "comnonent" models, as is frequently the case in large codes, describe briefly the role of each individual model.
Show
4 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 ar.d block diagrams.
l Give references for the basis numerical procedure.
If the method solves l
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).
l (4) Component models.
For each component model, provide the l
following:
l l
(a) Purpose.
Describe the purpose and scope of the component l
model.
State in general terms the input to and output from the model and l
the way the informatica is processed.
If the model is used only in certain cases, state under what circumstances it is used.
t j
(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 kr.own 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.
Indicate the degree of acceptance which the model has received among engineers and scientists.
(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 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.
Justify 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
5 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 geologic media, conditions, or types of sites for which the model may be used.
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 procedure from the mathematical 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 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 variables are input to and output from the model.
(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.
D'scuss the stability and accuracy of the numerical model.
Distinguish bitween 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.
t 6
C.
User's Manual The user's manual, for purpones 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 aie documented fully in comment cards in the code, the lines in the code which contain these comment cards 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.
(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 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 vclues automatically assigned to important variables.
These should ine ude both values of physical significance and parameters which only a'.iect program execution.
State where the values are initialized and whether they are default or fixed values.
7 (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.
(c) Auxiliary processing.
Describe any available auxiliary programs which create, modify, or use the files.
(3) Input data.
(a) General considerations.
(i) Techniques.
Describe special input techniques and requirements; e.g., blank field treatment, order of items, field delineation.
(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 contain data given on this record.
(iii) Format.
Specify the format of this record, if any.
8 (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.
State 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.
(fx) Range.
State the acceptable limits 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 the purpose of each.
Include plot and 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 teemory 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 programs require some system commands 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.
9 4
Give sample control card files or command files.
Discuss application dependence.
(5) Output. Discuss the program 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 nssd not have known solutions or experimental data.
However, they should exercise a large portion of the available programmed options and should use only a reasonable amount of computer time.
Input deck listings and sample output should be given.
D.
Model Assessment and Support This document has the purpose of describing all work which sheds light on the adequacy of the model.
The goal of the document for licensing purposes is to ensure that the model has been extensively reviewed and validated.
In addition, the document describes steps the applicant is taking to ensure that model performance will not be degraded by future changes.
(1) Model review.
Describe any projects for independent review of the methods used in the model.
Include past and ongoing 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) Code assessment.
Describe the program for evaluation 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 version delivered to NRC (see part E).
State what aspects of the model each test demonstrates and discuss how well the model 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.
\\
l l
10 l
(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 validate each version as though it were a l
separate code.
However, it is necessary to ensure that each version is i
as correct as possible aid that an orderly procedure exists for keeping i
track of the differences between versions.
Since this procedure relates l
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.
I E.
Continuing Documentation and Code Listings.
Models generally continue to evolve even after a standard version has been 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 the basis of up-to-date information, it is necessary that NRC be kept informed of changes in the codes.
Continuing documentation includes revision of the other documentation and error reporting.
It also includes computer-readable and paper listings i
of the current version and new versions as they are released.
(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 l
l
11 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.
a (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 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 state whether written response, response by telephone, or a meeting is required.
1 12 Exhibit. 1 FELERAL INFORMATION PROCE55iNG STANDARD SOFTWARE
SUMMARY
Oi. summer, s.i, 02. aumma,y p.,pa,e4 y f a am. a.. ras..,
- 02. >ummer, acason Y r.
Mo.
Day New Replacement Deles son l
l l
- 05. Sof tware seile C
C C
- 04. Sofinare das, Previous Internal Wimate m Y r.
Me Day l
j~T
- 07. Internal bois mate ID
- 06. Shoe i nle
- 06. Solimare type
- 09. Processing 10.
Applacation area mode Automated Data Computer bestems Management /
System O lateractive C Support /Unility C Business C Computer Program C Batch C Sesentific/ Engineering O Process Control C Subroutine / Module O Combrnation R Bibliographic /Tentual D Other II. Submitting organiassion and address
- 12. Iechnical conoscits) and phone
- 12..Narrariee
- 14. A e y = orJ s
- 15. Lumputer manut's and moden
- 16. Lomputer operating sysicm
- 17. Programming language < s t
- 13.. Number os source program tra:emenes
- 19. Compuser mrer==y requirements
- 20. l ape drives
- 21. Disk /brum units
- 22. lerminals
' 2. Usher operational requirements
~
L& Sof =are availabslary
- 25. Documentaison availability Available Limited in-house only Available inadequare in-house only l
O O
O O
O O
- 26. FOR SUBasliTING ORGANIZ ATION USE staNonno fonu 185 JULY 197a u $ DEPT. Cowutact Ne$
iFig$ PUB 30s
8 i*
U.S. NUCLE AR REGULATORY COMMIS$10N BIBLIOGRAPHIC DATA SHEET NUREG-0856 4 TITLE AND SUBTITLE IAdd Votume No., ef warenew)
- 2. (Leere b'M*/
Draf t. Technical Position on Documentation of Models
- 3. RECIPIENT *S ACCESSION NO.
- 7. AUTHOR (S)
- 5. DATE REPORT COMPLETED
- '"b e r l "19 "81
^
S* A* Sillin9 Octo R OHMING RG NA E MAILING A I
DATE REPORT ISSUED 9 P[fIce of OuciNIZATdIaterTalNOafety an0DREieg/nclue 2,p Codel 0
ear Sa uards MONTH l YEAR U. S. Nuclear Regulatory Commission December 19 81 Washington, DC 20555 e.it-eve u - *i
- 8. (Leave Nwk)
- 12. SPONSORING ORGANIZATION N AME AND M AILING ADDRESS mctude I,p Codel O. PROJECT / TASK / WORK UNIT NO.
U. S. Nuclear Regulatory Commission ii. CONTR ACT NO.
Washington, DC 20555
- 13. TYPE OF REPOHT PE RIOD COV E RE D (/nclus,ve adres/
Technical Position
- 15. SUPPLEMENTARY NOTES 14 lle8ve 0/ Mal
- 16. ABSTRACT (200 words or ress)
Guidance is given for the content of documentation on computer models which are used I
in support of a license application for high-level waste disposal.
17 KE) WORDS AND DOCUMENT AN ALYSIS 17a DESCRIPTORS 17b IDENTIFIERS.OPEN ENDE D TERMS
- 18. AVAILABILITY STATEMENT
- 19. SE CURITY ; LASS (Th,s reporft 21 NO OF PAGES Unlimited unclassified
- 20. SE CU RITY CL ASS (This pa e)
- 22. P RICE s
unclassified S
teRC f ORM 335 (7 77)
i
,l mQggUo oIn
%>mH 4 MOI 2 ODF ' Ou jO2 02 8OCEm2l>dO2 0 EOOmFi O
s i
n r
DmOmEtm% a.@0.
o 0 n.
]
d
=
{
k Y
DRO IAT P A SL EU N E Go F
i Es ors Mt im s
P S.
U e
N O
I 0
S 0
S 3
M6 3,
I 6
M E
5 SS O0 SU SC2 E
E NE TYC.
Uv TO,
Si S TN R
3A O LP LT A
ETUG I R CO NIQ N IF EI F
URH FY S
AW A
E N
L E
C P
U N
1 1
.ll1i' l
-l