ML19350C936
| ML19350C936 | |
| Person / Time | |
|---|---|
| Issue date: | 02/03/1981 |
| From: | Catton I NRC |
| To: | Boehnert P NRC |
| References | |
| ACRS-CT-1310, NUDOCS 8104100434 | |
| Download: ML19350C936 (3) | |
Text
l
\\
W L.
C 7-M/d Q
February 3,1981 T0:
Paul Boehnert FROM:
Ivan Catton
SUBJECT:
Code Development and Assessment ECCS Subcommittee Meeting, 14-15 January 1981 The users of codes within NRC have experienced a great deal of frustration.
They are not now able to use a realistic code for assessment of a full scale PWR, Unfortunately most of the talent and money is devoted to advanced codes that never seem to reach a usable state.
There is no support for day to day user needs. When a code reaches a state that it is considered ready for use it is given to the user. The user then runs into difficulties and is given very little support.
There is need to focus more on the details of a usable code. The customer for the product seems to be forgotten. As a result of this lack of attention, NRR appears after six years of struggling to have given up in their attempt to get an assessed or verified code from RES.
There are now a number of technical assistance programs sponsored by NRR that seem to be directed towards filling their need for usable codes. Two code programs is one too many.
The RES code development and assessment program is in need of revision.
A number of codes are under development with versions being released from time to time. The released version is then available on a user beware basis and the developers go on to bigger and better codes.
Problems frequently arise with the released version and the users do not get sufficient support to remedy them. Sone comments on specific aspects of the code development and assessment program as presently formulated by RES are contained in the following paragraphs.
Code Development. Before discussing the present code development program, I would like to express a concern about multi-dimensional advanced codes.
Most, if not all, the advanced codes use two fluid modeling. As long as the code is one-dimensional, the necessary cross flow averaging used to obtain the equations and their interaction terms are soundly based on experimental data with constants resulting from replacing the average of a product with a product of averages being absorbed into universal constants or correlations (most of which is one dimensional in nature).
If, however, the code is to be three-dimensional, the averaging takes place over an elemental volume and replacing averages of products with products of averages will lead to coefficients in the equations describing vapor and liquid behavior that are space dependent (and possibly time dependtnt).
Further, there is now a requirement for interfacial interaction te,ms that are local. The physical processes involved with understanding the interfacial interaction terms are not well enough understood at this time to proceed with confidence. A program directed at gaining this understanding is not evident.
A clear picture of what the goals of a code development program should be needsto be stated. A code that uses little core and runs in zero time while giving exact answers is an admirable but impossible goal. The question is what do we settle for. Continuing to develop multi-dimensional codes without an experimental program devoted to obtaining the need for physical 04100 0
U so g
t
~
Paul Boehnert Page 2 3
February 3,1981 parameters is inconsistant.
Improving the numerics to decrease running time from a valve that is already significantly better than what is available to the user is not an example of a well balanced program. Balance between the needs of the user arid code improvements is necessary.
Code Assessment. The code assessment program appears to be budgeted 15-20M over the next four years. These funds are primarily devoted to the TRAC code. A number of other codes are in various states of usage by NRC.
For example IRT is used at BNL by NRR without full knowledge of its limitations.
BNL is presently obtaining RETRAN from EPRI and will most likely use it in the future. The entire industry uses the MARCH / CORRAL code package. PNL-is developing the COBRA / TRAC package for UHI studies and SANDIA has a RELAP version for UHI studies. BEACON is now being used at LASL for NRR.
Finally there is the WRAP package at SRL.
Different groups have different interests and some codes receive attention and others do not. With computer codes being a primary licensing tool, a better overall plan for establishing their goodness or badness is clearly needed. Such a plan needs to coordinate efforts of several offices within NRC.
The task of code assessment is a difficult one.
First one has to decide what is meant by " independent" and developmental.
Presently independent assessment is when the code is tested against a number of experiments at a laboratory other than where it was developed.
Even if problems are discovered, they do not touch the code.
Further, it will often be tested against experiments other than where the problem was discovered without change.
Developmental assessment takes place in the hands of the code developer and he can remedy problems as he finds them. This leads to an iterative effort between the assessor and the developer that could be very costly. There seems to be a lack of trust of the " code developer" and a feeling that the public view is somehow different if the code developer does not assess his own code.
It is my naive opinion that this has been carried to an extreme and that it is time that we approach code assessment from a point of view that is technically sound rather than politically expedient.
The code assessment program as planned involves three laboratories. This effort is to be coordinated by RES.
I don't believe RES has the manpower to accomplish this task. With 350 odd different experiments in the matrix a tremendous amount of material will be generated for review. How these results will be used and who will use them needs to be planned before such an effort is implemented.
A clear plan for code improvement was not evident from the meeting.
For example, if a code has proceeded part way through its assessment, and a problem is discovered (a wrong or inadequate model) then what? How does one handle the required developmental task? Does one change codes in the middle of the matrix? While the developmental task is underway, do the other three laboratory efforts go into a holding pattern? Problems will surely be found and such questions as these must be faced.
As a part of code assessment, one must decide what experiment should be
o
\\
t..
Paul Boehnert 0
Page 3 February 3,1981 used to access ones ability to address a certain phenomena of importance.
Of course this implies we know what is important which we may not. I would like to see a systematic review of the code application that will highlight the various important phenomena. This should include a risk viewpoint to establish their importance. With the phenomena of importance listed, a systematic review of the available experimental facilities, that includes a complete scaling analysis, to establish which facility will contribute data for assessment of the predictability of a given phenomena. Missing elements will be highlighted by such a process and plans can then be made to run further experiments.
Code developers and modelers of physical phenomena should work together on this.
Code Maintenance.
Codes that are developed by and for NRC need to be maintained. When errors are found they must be corrected. Simple changes to facilitate use need to be incorporated into existing codes if they are to be useful. The larger the number of codes, the greater this maintenance effort should be. Who will maintain the codes and how the maintenance effort will be budgeted needs to be established. A period of time, much like a new car during warranty, is needed where the code developers spend some time making the customer happy with their product and teaching him how to use it is needed.
Presently there are twenty or thirty codes (a guess) in use by various offices of NRC and national laboratories. Some are good and some are bad for any given computational chore. The code user is typically not a sophisticated analyst like the code developer. The result is NRR or other NRC offices sometimes using an inappropriate code. An example is BNL use of IRT when phase change occurs. A continuing interaction between code developers and code users is needed. Review of the usefulness of the various codes for different problems needs to be carried out continuously with the results comunicated to the code user.
Code maintenance as I see it is an important part of keeping the tools of NRC in good working order as well as seeing to their proper use. With the number of codes in existence now and their tendency to multiply through revisions and mod fications, proper maintenence could get very expensive, cc:
M. S. Plesset i
1 l
l
.._