Protecting People and the EnvironmentUNITED STATES NUCLEAR REGULATORY COMMISSION
Official Transcript of Proceedings
NUCLEAR REGULATORY COMMISSION
Title: Advisory Committee on Reactor Safeguards
Thermal Hydraulic Phenomena Subcommittee
Docket Number: (not applicable)
Location: Rockville, Maryland
Date: Wednesday, August 22, 2001
Work Order No.: NRC-389 Pages 1-140/195-199
NEAL R. GROSS AND CO., INC.
Court Reporters and Transcribers
1323 Rhode Island Avenue, N.W.
Washington, D.C. 20005
(202) 234-4433 UNITED STATES OF AMERICA
NUCLEAR REGULATORY COMMISSION
+ + + + +
ADVISORY COMMITTEE ON REACTOR SAFEGUARDS
(ACRS)
THERMAL-HYDRAULIC PHENOMENA SUBCOMMITTEE
+ + + + +
WEDNESDAY
AUGUST 22, 2001
+ + + + +
ROCKVILLE, MARYLAND
+ + + + +
The subcommittee net at the Nuclear
Regulatory Commission, Two White Flint North, Room
T2B3, 11545 Rockville Pike, at 8:30 a.m., Doctor
Thomas S. Kress, Acting Chairman, presiding.
PRESENT:
THOMAS S. KRESS, ACTING CHAIRMAN
F. PETER FORD, MEMBER
VIRGIL SCHROCK, CONSULTANT
JOHN D. SIEBER, MEMBER
ACRS STAFF PRESENT:
PAUL A. BOEHNERT
A-G-E-N-D-A
Agenda Item Page
Opening Remarks
T. Kress, Acting Chairman. . . . . . . . . . 3
GE Nuclear Energy TRACG Code for Anticipated
Operational Occurrences, R. Landry, NRR. . . . . . 6
NRC Staff Presentation TRACG Kinetics Review
Tony P. Ulses, USNRC . . . . . . . . . . . .36
Review of Uncertainty Evaluation
Yuri Orechwa, NRR. . . . . . . . . . . . . 101
Conclusions, Ralph Landry, NRC . . . . . . . . . 125
Lunch
GE Nuclear Energy Presentation
Introduction
J. Andersen, GNF, et al. . . . . . . . . . 135
Concluding Remarks . . . . . . . . . . . . . . . 199
P-R-O-C-E-E-D-I-M-G-S
(8:30 a.m.)
CHAIRMAN KRESS: The meeting will now
please come to order. This is a meeting of the ACRS
Subcommittee on Thermal-Hydraulic Phenomena. I'm Tom
Kress and I'm Acting Chairman of this subcommittee
since our regular chairman can't be here.
The purpose of this meeting is 1) to
review the GE Nuclear Energy TRACG realistic thermal-
hydraulic code version, particularly for its
application for evaluation of anticipated operational
occurrences and, 2) review the resolution of issues
associated with the EPRI Report TR 113594, resolution
of generic letter 9606 waterhammer issues.
The subcommittee will gather information,
analyze relevant issues and facts, and formulate
proposed positions and actions as appropriate for
deliberation by the full committee. Mr. Paul Boehnert
is the designated federal official for this meeting.
The rules for participation at today's
meeting have been announced as part of the notices of
this meeting previously published in The Federal
Register on July 30 and on August 15, 2001.
Portions of this meeting will be closed to
the public to discuss GE Nuclear Energy and EPRI
proprietary information. A transcript of the meeting
is being kept and will be made available as stated in
The Federal Register notice.
It is requested that speakers first
identify themselves and then speak with sufficient
clarity and volume so they can be readily heard,
particularly by the transcriber.
We have received no written comments or
requests for time to make oral statements from members
of the public regarding today's meeting.
For the benefit of the members who may not
have been here during some of our earlier reviews of
TRACG, we did have a few problems -- or not problems,
maybe issues, questions, related to the treatment of
delayed neutrons, the treatment of rental stresses,
the treatment of wall shear and heat transfer
partitioning from the wall, flow regime transition
treatment and interfacial shear and interfacial heat
transfer treatment, among others. I think those are
just some of the more important ones.
With those comments, I'll ask if our
consultant, Virgil Schrock -- I forgot to mention the
ACRS members in attendance are Peter Ford, Jack
Sieber, and our consultant, Virgil Schrock. If
anybody wants to make any comments before we start,
Virgil, I'll start out with you.
MEMBER SCHROCK: I'm a little at a loss to
know what to say or what depth to pursue the issues,
but I found the SER to be a great disappointment. I
don't see that it has explained in any way many
questions that were discussed at the last meeting of
the ACRS on this topic. Some of that may be because
some of the things that I thought were important
evidently had not been deemed sufficiently important
by the full committee to make it on their laundry list
of things to have you respond to.
But I understand several of these problems
as well as anybody in this room, and I can say to you
that you have a superficial treatment of real problems
in this SER. If that's what you want, that's what you
will have. I think it's a disgrace to the regulatory
process. I'll give you as much detail as you'd like
to have as we go along, but that's what my reading of
it led me to believe.
CHAIRMAN KRESS: Okay. With that pleasant
note, I'll go around this way. Do you wish to add to
that?
MEMBER SIEBER: I don't think so.
CHAIRMAN KRESS: Peter, I think you wanted
to make some sort of statement.
MEMBER FORD: Yes. I'm a retired General
Electric employee. Although I had nothing at all to
do with the TRACG code, I do have to declare a
conflict of interest.
CHAIRMAN KRESS: Okay. With that then, I
don't have any additional statements, so we'll proceed
with the meeting, and I guess I'll call on Ralph
Landry to begin the inquisition. Did we give you a
laundry list of comments and issues? Since I wasn't
chairing this subcommittee at the time, I don't know
whether we did or not.
DOCTOR LANDRY: Okay. For the record, I'm
Ralph Landry from the NRR staff.
No, Doctor Kress, we did not receive a
laundry list.
CHAIRMAN KRESS: Did we pass Virgil's
written thing on to you?
DOCTOR LANDRY: No, I never received a
copy of a report from Virgil.
CHAIRMAN KRESS: That might explain,
Virgil, why the--
DOCTOR LANDRY: We were surprised when we
saw some of these items.
MEMBER SCHROCK: Let me just interject
that whether you had it in writing or not, you sat in
this room and heard the arguments. We spent a lot of
time.
DOCTOR LANDRY: Well, somewhere between
all of the discussion and getting the agenda for this
meeting, we had missed a number of these points and
did not have them down. So this time we didn't have
copies of the reports from the consultants, so we
missed the specific points. But yes, Virgil, if you
do have specifics in addition to what's on the list
with the agenda, we'd definitely like to hear your
views and specific things that you think should be
brought out.
What we're going to talk about this
morning is give a real brief review of how we got to
the SER. The approach that the staff took in the
review of the documentation on TRACG, the
applicability intended for the code, what transients
and where the code is going to be applied. Talk
briefly about the assessment of TRACG. We'll talk
about the staff evaluation and briefly about the
thermal-hydraulics. We'll go into a great deal more
depth on the neutron kinetics. Tony Ulses will
present his review of the neutron kinetics aspects of
the code. Yuri Orechwa will talk quite a bit about
the statistical methodology review which he performed,
the uncertainty analysis. We'll talk a little bit
about the code user experience. We have been running
the code. We've run some cases with the code and
tried to look at a few things, so we'll talk about
some of our experience in running TRACG. And then
review the conditions and limitations that we're
suggesting for the code and the conclusions of the
staff.
Okay. How did we get to this point? In
the spring of 1999 and the summer of 1999, TRACG was
presented to us in a preliminary fashion by General
Electric and General Nuclear Fuels, GNF. Sometimes we
use the two interchangeably, GE and GNF. So if we
swap back and forth, we mean the same company.
The preliminary information was to come in
and show us how GE would propose to submit the code
for review for AOO analyses, what material they would
suggest that we review and how they would like to
proceed with a review of the code for operational
transients.
In January of 2000, we began to receive
the materials on the code. That submittal was finally
complete in February of 2000. We received manuals and
then we received the electronic version of the manuals
and finally we received the code itself. General
Electric did submit to us both the source code and an
executable version of the code. We installed the code
on an alpha machine, a VMS machine which we purchased,
so that we could run the code in the same native mode
that the applicant ran the code for their own work.
We met with the ACRS Thermal-Hydraulics
Subcommittee in middle of November of 2000. We've
been issuing RAIs informally as we've been performing
this review and the applicant has been looking at the
RAIs and responding to those RAIs informally
throughout the review.
In July we finally issued the formal RAIs,
those that have gone through our full review by
management and have been issued formally to the
applicant, and we have received now the formal
response from the applicant which is really the same
responses which we had in draft but this now puts the
response officially on the record.
We prepared the draft SER on TRACG in July
and we have discussed that draft SER with the
applicant. We have provided it to them for review for
proprietary content, and I would point out to the
committee at this point that the draft SER which you
have received from the staff does contain proprietary
information. The applicant has determined that there
is proprietary information in there, so we are going
to withhold this draft version of the SER from the
public. We are going to work on the SER and try to
take the draft material which is proprietary out of
the SER so that we can publish a non-proprietary
version of the SER. So at this point, the SER draft
which you have received must be treated as
proprietary.
CHAIRMAN KRESS: What are the plans for
going final with that? What is your time line? Do
you have one?
DOCTOR LANDRY: We would like to have the
final SER ready in September. Assuming that the
Thermal-Hydraulic Subcommittee can report back to the
full committee at its September meeting, we would then
issue the final version of the SER in September.
MEMBER SCHROCK: Is there an
identification of the version of the code that you've
reviewed?
DOCTOR LANDRY: It's right at the
beginning of the SER. It's TRACG O2A.
MEMBER SCHROCK: What does TRACG O2A mean
precisely?
DOCTOR LANDRY: That's the specific
version which was submitted to us for a review. We
realize that the applicant is working on future
versions of the code. They have talked with us about
submitting a version of the code for realistic LOCA
analysis. So we're being very specific that the
version we review has been designated as TRACG O2A.
CHAIRMAN KRESS: Does the A stand for
anticipated?
DOCTOR LANDRY: I'd like to ask Jens
Andersen from General Electric to answer that one.
DOCTOR ANDERSEN: This is Jens Andersen
from GNS. The A simply just designates the computer
hardware that it's executed on.
MEMBER SCHROCK: Well, I had raised that
question in the previous meeting, but it seemed to be
now several different versions of TRAC as opposed to
a version which was reviewed comprehensively in the
past maybe, maybe not comprehensively but reviewed in
some depth and asked and specifically the fact that
the decay power was discussed in terms of the May-Witt
estimate which goes back to the 1960s whereas the
version of TRACBD1 which was developed by INEEL with
cooperation from GE had the 1979 decay standard in it.
A world of difference between the two in the sense of
the technical approach. One recognizes that the decay
power is not the same for different fissile muclides.
The other does not.
In any case, that led me to ask the
question in that previous meeting. Has the ANS
standard been removed from TRAC and Jens Andersen was
unable to answer the question, as I remember, at that
time. But I presumed that somebody would look and see
what is the status. Now what you have in your SER, in
one paragraph you kiss off both that issue and the
issue of what procedure is employed to weight delayed
neutron fractions according to contributions from
different fissile species. Both of those are
superficially essentially treated as non-issues, non-
questions. So if you don't understand what I'm saying
to you, Ralph, I'll try to explain it in greater
detail. Is that the problem? You don't understand
the issue that I'm addressing?
DOCTOR LANDRY: No. I think when we get
into the discussion of the neutron kinetics, we'll
address that a little bit more.
MR. ULSES: We will now.
DOCTOR LANDRY: Tony Ulses will address
that further when we get into the discussion of the
neutron kinetics because he has already looked at
that. Yes.
MEMBER SCHROCK: Okay. Well, several
related questions are, two technical issues I just
mentioned plus the question of what is the code
version? How is it defined? How are we understand
what the code version is? If it does not have the ANS
decayed heat standard in it any longer, then it's not
the same code that was reviewed for SBWR. Do you know
the answer to that?
DOCTOR LANDRY: Let me ask Jens Andersen
if he can respond to that.
DOCTOR ANDERSEN: Yes, I can comment on
that. Most of the models in the codes are the same as
what was reviewed for the SBWR and if you compare the
model description TRACG 2A -- revision one to the
model description, which was what was submitted during
the SBWR review, and then revision two, which is what
we have submitted for this review, there are minor
model differences but the majority of the code is the
same. The decayed heat model that is being used for
the application to transient is based on a simulation
of decayed heat cooks and we can get into that later
on.
What we have done is, realizing that there
were minor differences in the code, is that we
submitted a complete qualification of the code as
submitted. The material that's documented in the
qualification report is all one with the code as
submitted to the NRC.
MEMBER SCHROCK: Well, it seems to me that
there are guidelines that you have issued for code
reviews that are not met by this submittal. Is that
incorrect? You needed a starting point, but you had
a clearly defined code that you had complete
documentation for that clearly defined code. It
doesn't appear that you have that.
DOCTOR ANDERSEN: Can I make a comment
again? This is Jens Andersen. The documentation that
has been submitted for this review, model description,
qualification, the user's manual, is all specific to
the code version TRAC. It's a two way that has been
used and that was made available to NRC for
installation on their computers. So it's totally
consistent.
MEMBER SCHROCK: But not the same code
that was reviewed for SBWR?
DOCTOR ANDERSEN: That's correct.
DOCTOR LANDRY: That's correct. It's been
built on the version that was reviewed for SBWR.
MEMBER SCHROCK: Of course it's been built
on it, but unless you define changes and explain what
the changes are, how can you expect a technical body
reviewing it to tell you what yes, what you're saying
is fine when you haven't even defined what the product
is that you're reviewing?
DOCTOR LANDRY: But they have defined the
product and that is the TRACG O2A version of the code
and the documentation which they submitted on this
version of the code, the staff believes defines the
code.
When we did the review of this code, we
did build on the work that was done in the review of
SBWR version of TRACG. At that time, the contractor
which the staff was using, Brooke Haven National
Laboratory, did an extensive review of the thermal-
hydraulics of the code and a review of the kinetics
and other parts of the code.
We looked at the review that was
performed, compared that with what was being submitted
for the review of the TRACG O2A code for AOO
transients, and we felt that the thermal-hydraulic
questions and concerns that had been raised during the
SBWR review had been addressed in the material
submitted for the TRACG O2A submittal.
Because of that review and the depth that
that review was taking, the staff made the decision
that we would review the material and we only asked a
few requests for additional information on thermal-
hydraulic aspects of the code and then concentrated
heavily on the kinetic aspects of the code and on the
uncertainty analysis, the statistical methodology. We
felt that that would be a more productive use of the
resources which we had available to us in performing
the review.
You have to keep in mind what the code is
being applied to. The application of TRACG O2A for
AOOs is very limited in scope. The code is being
applied to only transients in chapter 15. It is not
being applied to Atlas, it is not being applaud
stability analysis, it is not being applied to loss of
coolant accidents. It's being applied only to
increase and decrease in heat removal by the secondary
system, a few transients in those classifications, a
decrease in the reactor coolant flow rate. It's being
applied to reactivity and power distribution
anomalies, increase and decrease in reactor coolant
inventory. Those increases and decreases that are
short of a loss of coolant accident.
When we looked at the assessment that was
performed for the code, the first thing we did was
step back and look at assessment in the way we always
do. How has the assessment been performed? Have they
looked at the phenomenological tests, separate effects
test, integral test, plant system information when
available, so that they can assess from the level of
correlations to the level of models to the level of
the entire code.
Of course, when you look at plant
operational data, because of the way the data are
taken, they're not experimental, empirical data, so
the data set is much more limited. But the assessment
that is performed is a global assessment of the code.
Does the code adequately represent the global events
occurring in a transient when those transients have
been run in a plan?
CHAIRMAN KRESS: How do you know when you
have enough assessment? I know I've asked this
before.
DOCTOR LANDRY: The big question for years
has been how good is good enough.
CHAIRMAN KRESS: Yes.
DOCTOR LANDRY: In the case of the code as
it has been submitted, since it is doing a statistical
uncertainty analysis, has enough assessment been
performed is determined by has a phenomena
identification ranking table been prepared, a thorough
PIRT, that can be reviewed and is thorough, captures
all the phenomena. Do we agree that the PIRT captures
all the high and medium importance phenomena? And
then have those phenomena been properly assessed
against data? Have enough assessments been performed
that an uncertainty analysis can be performed and
uncertainty be placed on the important phenomena?
When we look at codes, as we have in the
past, that did not do uncertainty analysis, codes such
as LOCA codes meeting Appendix K, we did not put a
handle on uncertainty. We simply said does the code
meet these set prescriptive requirements and how good
is good enough became a much more difficult question
to answer because we did not have a definition of
statistically what is enough assessment to perform and
we would have to look at the assessment and say does
it cover an adequate set of the data available. Are
there data available from the other aspect to perform
an assessment?
And we always run into the problem when we
get into those assessments that there are events that
can occur, there are phenomena that can occur, for
which there are no data and for which you can not
properly assess. There are a number of aspects in
turbulent flow where it's three-dimensional flow
effects where you don't have data and you can't really
assess the capability of the code in some of those
areas. So I hope this is answering your question.
CHAIRMAN KRESS: Yes. I think that was a
good answer.
DOCTOR LANDRY: When a code is submitted
with an uncertainty analysis under a statistical or
what we sometimes call best estimate or realistic
application, we have a better way of saying how much
assessment is enough because now we're zeroing in on
the phenomena that are important. We're saying are
those phenomena assessed properly so that a
statistical basis for the uncertainty can be assigned?
This morning later on Yuri is going to go
through an explanation of his review of the
statistical methodology and he'll give some of his
views of what has been performed and has a proper
assessment been performed.
MEMBER SCHROCK: You have made the point
in the SER that the code and its application meets the
guidelines of the CSAU methodology. Do you want to
comment on how the uncertainty and decay power
evaluated -- assessed. -- provided assessment of the
uncertainty. Uncertainty indeed is dependent upon the
details of the reactor problem that you're addressing.
It's impossible to assess such an uncertainty.
The problem may be that a good case can be
made that decay power is pretty much a second order
phenomenon in AAOs. That case is not made here. It's
nowhere to be found in your SER that I can see. But
even so --
DOCTOR LANDRY: Well, we'll take that into
consideration.
MEMBER SCHROCK: My recollection, as I
said in the previous meeting, of what GE did in using
the ANS standard first was to run a lot of Monte Carlo
calculations to find a sort of generic decay power
curve which they could put some sort of balance on,
and I think they take a penalty rather than including
that in the assessment. The details are a little bit
fuzzy in my mind, but I clearly remember that was the
general pattern of what was done. It was not a
straightforward assessment of the uncertainty using
the uncertainties that are published in the ANS
standard for decay power. That would be one way of
approaching it. It's not what they did. What they
did was found acceptable at the time. I thought it
was quite good.
My problem with this is that what I see is
superficial discussion of real life problems in an
SER. This is the government's evaluation of the
safety of that system done in a very superficial way.
That frightens the hell out of me.
DOCTOR LANDRY: Tony.
MR. ULSES: I suppose nobody -- to talk
about decay heat. Let's do it rather than wait? The
issue of decay heat and --
CHAIRMAN KRESS: Go ahead. We'll talk
about it now.
MR. ULSES: I would say I would certainly
agree with you, Doctor Schrock. It was given a
cursory discussion in the SER because I believe it has
a cursory effect on the problem, and that's my fault.
I should have discussed it in more detail and that's
a valid criticism and I will definitely change the SER
to expand upon that point. I definitely think you are
right, and that's an oversight on my part and that is
something that will be fixed.
MEMBER SCHROCK: More than that, you're
reviewing a code which is said to have been adequately
reviewed for loss of coolant accidents and other
purposes in the context of the SBWR review and now
you've not called out in any sense here that what
you're going to do is substitute for one particular
aspect of the whole calculation, a more simplistic
approach because it's more computationally efficient.
That is to invoke the Mae Witt implication for decay
heat evaluation.
MR. ULSES: Well, again, we were looking
at the version of the code that we were given and
that's a beyond scope issue. I mean this is not a
LOCA code.
MEMBER SCHROCK: Do you review something
with blinders on or do you review it with an
intelligent assessment of how it fits into the whole
picture of your dealing with this code?
MR. ULSES: Well, I reviewed it with the
scope of the application in mind.
CHAIRMAN KRESS: If they come back later
and want to use this for best estimate LOCA, then you
would face up to that problem.
MR. ULSES: Yes, sir. We will deal with
it in excruciating detail because it is very important
for LOCA applications. However, for AOOs, it is not
a significant contributor.
CHAIRMAN KRESS: You're pretty much
constrained to have to review the application as it's
presented to you.
MR. ULSES: Yes, sir. We're not really
allowed to go beyond the scope of the review, and that
would have been beyond scope if we would have gotten
into the questions about specific details of the decay
heat model because it's not a significant contributor
to the answer. But your criticism is certainly valid.
On what's written in the SER, it is not clearly
spelled out and that will definitely be corrected and
for that I apologize. The actual discussion of why it
was not reviewed in detail is not there and I will
definitely correct that.
DOCTOR LANDRY: Let me make one other
correction.
MEMBER SCHROCK: The description of the
code doesn't say we have different options for decay
heat evaluation. Those options are used in this way
for evaluation of AOOs. We invoke this simpler thing.
That's not in the GE documentation. It's not in your
interpretation of the GE documentation. But you're
telling us now, after all, that is your
interpretation, that's your understanding of it. This
is the limit of its utilization in TRACG. Is that
right?
MR. ULSES: Yes, sir. That's all that GE
will be able to actually use the code for because the
SER will be written not to allow them to use it for
any other applications. I believe we have an
additional comment.
MR. HECK: This is Charlie Heck from
Global Nuclear Fuel. In the documentation that was
submitted with the application in Section 9.3 of the
model description, it clearly describes what is the
model we're using for decay heat and it also provides
a comparison of the Mae Witt curves with the ANS
standard 5.1 and it describes the model that's being
used. That was part of the submittal.
MEMBER SCHROCK: In order to make such a
comparison, you have to say what the particular
reactor state is at the point of this evaluation by
the ANS standard. There's not just a single
comparison of Mae Witt. Mae Witt is a single entity.
That's right. It just relates it to the operating
power. But the decay heat standard gives you an
evaluation which depends upon the operating history of
the reactor and the composition of the fuel. So,
Charlie, you can't argue that that was an adequate
description. It was a comparison but with an
undefined set of circumstances for what the ANS
standard part of that comparison was calculated for.
MR. HECK: Doctor Schrock, the
documentation that was provided indicates that the
comparison was made at end of cycle conditions,
exposures and radiation time, and enrichment values
that are typical of the application for AOOs, and it
was done at that point because that's where the most
limiting conditions for AOO occur. So a comparison
that we did do -- and I acknowledge your point that
it's very specific to what has been the operating
history, what was the initial load, what are the
fissionable materials. We did provide the comparison
at a representative condition for the intended
application. But it is a single point evaluation.
MEMBER SCHROCK: Well, I think the point
that I'm making is that the documentation of these
issues is something that needs to be of concern to the
NRC. It's treated in the SER as though the problem
would never arise. That's what I have great
difficulty with.
DOCTOR LANDRY: Well, this is a draft SER
and we'll take your comments back and address them.
In looking at the assessment that has been
performed through the uncertainty analysis, we did
find that all the medium and high ranked phenomena
have been taken into account in the uncertainty
analysis and, on that basis, we feel that the proper
assessment has been performed that does show the
capability of the code to represent the experimental
and operational data as necessary for the application
to AOO transients.
CHAIRMAN KRESS: Did decay heat show up as
important in that PIRT?
DOCTOR LANDRY: No.
MR. BOLGER: This is Fran Bolger from GE.
We did identify it as a high phenomena for the loss of
heat water transient.
CHAIRMAN KRESS: For what are the AOOs
only.
DOCTOR LANDRY: Okay. Just to briefly
recap some of the thermal-hydraulic aspects of the
code because this was, as I said, more of a review of
what was done during the review of the SBWR
application of a version of TRACG. This was an
extensive review. As I said, it wasn't performed to
be a complete review because the code was withdrawn.
The whole submittal was withdrawn before the review
could have been completed. So it was not a complete
acceptance review of the code. But it was an
extensive review for thermal-hydraulic aspects.
TRACG is just basically like the TRAC
code. It's a two fluid, six conservation equation
code. Has boron transport, non-condensible mass
equation in it. It's a two regime unified flow map
instead of some of the other codes that we see
typically for PWRs that will have multiple regimes.
The regimes that are in the code are adequate to cover
the normal operating and anticipated regimes that
occur in a BWR. We're saying for AOOs the four
regimes that are covered are adequate.
There's a two phase level tracking model
which was criticized during the SBWR review because it
uses approximations for void fraction above and below
a mixture level and uses a cut point for level
detection. We feel that because there is not a high
degree of mixture tracking going on in AOOs that the
shortcomings of this model are acceptable for AOOs.
However, to go beyond AOOs, we are going to look at it
extensively.
When the application comes back for the
LOCA, we will look at this model again.
CHAIRMAN KRESS: Could you refresh my
memory on bullet one about the boron transport
equation. Is that a K epsilon turbulent transport
model or was that empirically based on the tests that
were done with salt and thermal?
DOCTOR ANDERSEN: This is Jens Andersen
again. We have a boron transport model in the code
but let me first clarify one thing is that this
particular submittal is for AOO transients, and it
does not include Atlas. It does not involve the boron
transport model. The model does assume that the boron
is transported with a fluid model. Fluid velocity.
So it's a relatively simple model. If we make a
submittal of TRAC for Atlas, that's one issue that we
would have to address in more detail.
CHAIRMAN KRESS: Thank you very much.
DOCTOR LANDRY: In the TRACG code, the
kinetic energy term has been put back into the energy
equations. The kinetic energy term was removed in the
TRACB version of the code that the NRC had supported,
and that introduces energy balance errors. By putting
the kinetic energy back in, there's better
conservation of energy with this version of the code.
CHAIRMAN KRESS: That's merely to keep
people from asking questions about why the energy
didn't balance because it was a small discrepancy.
DOCTOR LANDRY: -- will have it back in
and get rid of those problems. Reduce errors wherever
possible.
MEMBER SCHROCK: When was it removed?
DOCTOR LANDRY: That was in the early
stages of the TRACB development at INEEL.
MEMBER SCHROCK: It was not in BD1, didn't
include kinetic energy?
DOCTOR LANDRY: No. An issue that did
come up during this review that is not a TRACG
specific issue but came up during the power up rate
review is an issue concerning the GEXL heat transfer
correlation. The NRC staff review and the power up
rate found that data were generated using COBRAG for
assessment of the GEXL 14 correlation rather than
using up skew, down skew experimental data.
We raised a number of questions on the use
of artificial data instead of empirical data for doing
a statistical analysis on the MCPR safety limit. The
staff is involved with the applicant in resolution of
that issue on the power up rate concerns at this
point.
CHAIRMAN KRESS: Wouldn't your perception
of that depend on how well you thought the other code
had been validated?
DOCTOR LANDRY: If the other code was
truly independent and was properly validated. Yes.
The staff view is we don't like using one code to
validate another code rather than data. If the other
code has not been validated against data, then --
CHAIRMAN KRESS: You would always prefer
data.
DOCTOR LANDRY: We always prefer data.
CHAIRMAN KRESS: But if you have places
where you don't have data, it seems like --
DOCTOR LANDRY: But if there are data but
they're owned by another entity, then --
CHAIRMAN KRESS: Oh, that's a problem.
DOCTOR LANDRY: This is a very involved
question.
CHAIRMAN KRESS: Yes, I can see that.
DOCTOR LANDRY: This is a question that
has come up through the power up rate reviews, but
we're only pointing out in the TRACG review that yes,
if the GEXL 14 correlation is applied in this code for
a transient, this issue must be addressed and that
whatever the resolution of the GEXL 14 issue is, we
expect that to be applied in the TRACG application
also.
CHAIRMAN KRESS: I don't know if we have
a statistician here or not but it seems to me like if
you have a measure of the uncertainty for the base
code and you can use that along with comparison with
calculation of the TRACC, TRACG, then you can actually
develop the uncertainty in the TRACG based on the
uncertainty in the other code.
DOCTOR LANDRY: If you have a thorough
uncertainty analysis of the other code.
CHAIRMAN KRESS: Yes. What I'm saying, it
seems like philosophically it's a reasonable thing to
do is to use another code if you know enough about
that code and uncertainty is known about it to develop
the uncertainty in another code if they are
independent, just as a philosophical statement. Seems
like an approach that's probably reasonable,
especially in places where you can't get access to
real data or real experiments.
DOCTOR LANDRY: We did not want to get
into that issue--
CHAIRMAN KRESS: I understand.
DOCTOR LANDRY: -- other than to point out
that there is an issue which is being dealt with
independently of this review but will impact the
application of this code when it is finally resolved.
I call that out in the SER for that purpose to ensure
that the resolution of the GEXL 14 issue is properly
addressed in the application of TRACG.
CHAIRMAN KRESS: Yes. I just wanted to
give you a hint as to how the ACRS might feel about
that issue. I can't speak for the ACRS. Some of the
ACRS members --
DOCTOR LANDRY: One of the ACRS members.
CHAIRMAN KRESS: At least one of them.
DOCTOR LANDRY: In looking at the TRACG
code, the basic component models are very much the
same as in the TRACB version of the code. Models are
used as building blocks to construct physical input
models for a plant. We did note that the
applicability to isolation condensers needs to be
demonstrated should the code be applied to transients
for which the isolation condenser is important.
We feel that the steam separator model
that is in the code has been validated very well
against full scale performance data. This issue of
steam separator/steam dryer keeps coming up whether
we're talking about PWRs or BWRs because there's so
much lack of data. But here the applicant has a great
deal of full scale data.
CHAIRMAN KRESS: You'd think GE would know
more about steam separators and dryers than anybody.
DOCTOR LANDRY: Right, and they have a
great deal of full scale performance data which they
have used to validate their separator model. We just
wanted to call out that yes, they've done a very good
job and we feel that the model is very well-
documented.
CHAIRMAN KRESS: Where does it show up in
PWRs?
DOCTOR LANDRY: We're talking about steam
generator performance.
CHAIRMAN KRESS: In generator problems.
Okay.
DOCTOR LANDRY: It has default, fully
implicit integration for hydraulic equations and heat
conduction equation is used. Predictor -- technique
is used. There's implicit coupling between the heat
conduction and coolant hydraulics and this code is
less prone to error on phase shift in thermally
induced oscillation. So we feel that the numerics
have been improved in going from the TRACB to the
TRACG version of the code.
MEMBER FORD: Can I ask a question? I'm
trying to come as quickly as possible onto the issues
on this particular subject. As I understand it,
there's a whole lot of questions about the specifics
of the modeling Virgil has brought up. And also there
could be presumably some questions about how good the
model is to predict the observations. Are we going to
see any data at all today on resolving some of these
modeling questions and are we going to see any data
against which the model is calibrated?
DOCTOR LANDRY: There will be some
material presented by Tony. Tony will be coming up
next to talk about the kinetics modeling which he has
examined.
MEMBER FORD: We'll see some data points.
DOCTOR LANDRY: We'll see some data
comparisons which Tony has prepared.
MR. ULSES: Ralph, I want to interject.
We actually aren't going to discuss the data because
the data is proprietary to GNF. We obviously can't
get into it in open session this morning.
MEMBER FORD: I have a fundamental problem
then. Again, I'm learning about this whole process.
CHAIRMAN KRESS: You come into this issue
a little late, but there is a validation part of the
submittal that includes the data they have and their
comparisons with the code. We may not have gotten you
all that information yet. But it is part of the
submittal.
DOCTOR LANDRY: Tony is going to talk
about some comparisons with the code which he has
performed and the neutronics. Yuri is going to talk
about the statistical methodology that's been set up.
CHAIRMAN KRESS: That's largely based on
data.
DOCTOR LANDRY: We're trying not to
utilize proprietary information in our presentations,
so we're trying to stay away from the actual data but
by showing some analyses which we have performed how
we feel the code is performing.
MR. ULSES: And there also is an extensive
assessment manual which was given to the staff and I
believe the ACRS as well by GNF and that has a great
deal of data in it. It's like an inch and a half
thick if I recall. It's an extensive manual.
Unfortunately, I don't have it here.
MEMBER FORD: I can see some of the
problems. I personally would not like to see some of
that data.
DOCTOR LANDRY: We'll try not to show it
to you then.
DOCTOR LANDRY: The next person to talk is
going to be Tony Ulses. Tony will talk about the
neutron kinetics analysis which he has performed, and
then Yuri Orechwa will follow Tony and talk about the
statistical methodology, and then I'll come back up
and talk a little bit about some of the user
experience with the code and the conditions and
limitations on the code and our conclusions. I would
ask during the next two presentations if GE sees stuff
coming up that they think is proprietary to alert us
so that we can take appropriate action.
MR. BOEHNERT: Yes. We can close the
meeting if we need to.
DOCTOR LANDRY: We don't think that what
we're going to say is proprietary, but if it looks
like we're getting in a proprietary area, let us know.
MR. ULSES: As Ralph said, I'm Tony Ulses
of the staff. What I'd like to do is I'd like to try
and address your concerns, Doctor Schrock, before I
get into the actual details of my presentation because
I don't have any specific discussions in there about
your questions. But I'd like to make sure that I
address them. There's one question you had about beta
that I know we haven't discussed. We can talk about
decay heat more if you'd like and if there's anything
else you'd like to discuss, I'd like to do that now
just to make sure I address your questions before I
get into the presentation, just to make sure they
don't get lost.
MEMBER SCHROCK: You can explain that now
or you can explain it wherever you plan to if you did
plan to. But I would like to hear it.
MR. ULSES: It's not in the presentation.
That's why I'd like to discuss it now.
MEMBER SCHROCK: How you deal with the
calculation of beta for -- fissile fuel.
MR. ULSES: This actually goes back to the
discussion we had in the past in the RETRAN review.
The question of beta within the scope of this review
is that it's viewed as input value into TRACG. It's
calculated by the upstream codes and it's going to be
fuel type specific.
MEMBER SCHROCK: You haven't read my
December report and, therefore, you couldn't have
responded to that but in that report I said, and I
believe this to be absolutely essential in what you do
in the regulation, that you have to know what the
source of information is for inputs. You can't
extract a physical problem from a computer code and
say, now, this code doesn't deal with that issue any
more because it's input. The fact is it has to be
evaluated in order to get a completed calculation
using this code and, in fact, the input or whatever is
preparing the input has to be based upon the
conditions that you're doing the calculation--
MR. ULSES: You're certainly correct,
Doctor Schrock, and the reason why it's not reviewed
in these contexts is that GE has and uses a licensed
code which has been reviewed and approved by the staff
for doing lattice physics type calculations and also
core analyses.
MEMBER SCHROCK: What I heard is an
oblique way of telling me it's not my business to know
this. What I'm saying to you is that you, the NRR,
has gone on record as saying you have conditions for
review of computer codes and those conditions we've
reviewed. A lot of time has been spent on that.
You're not following the advice that you prepared for
industry.
MR. ULSES: I'm not particularly sure I
know what advice we're not following.
MEMBER SCHROCK: This is a part of the
calculation. I raised the issue because I read things
in some other documents, as I explained previously,
that planted the seed of the possibility that maybe
this distinction is ignored in such calculations which
seems incredible.
MR. ULSES: Well, I can assure you that it
is not ignored in the GE analysis. We do specific
fuel type analysis based on exposure.
MEMBER SCHROCK: I don't think it is
either, and Fran Bolger and Charles Heck gave a lot of
assurance last time that it is done and it's done
well. I'm not challenging that. What I'm saying is
that if you're going to review the code, if you're
going to ask us to review the code, if you're going to
ask me to review the code, don't tell me it's none of
my business how this gets calculated.
MR. ULSES: If that's the impression I
left with you, I apologize. That was not my point.
The issue is is that we have a scope of review which
has been defined for us and it's very difficult for us
to go beyond that scope and if you look at the
application that we were reviewing, it was for one
code -- in this case, the TRACG code, which uses beta
as an input value. We know because we have access to
all the previous reviews that the staff has done that
there is an approved code that GE uses for doing those
types of calculations and that they do treat all the
relevant physics, all the relevant parameters.
Unfortunately, that information was not made available
to you and actually, I don't know if we could have
made it available to you or not. I really don't know
actually in this context because again, it really is
beyond the scope of the question we were asked to
answer. Other than to assure you that it is dealt
with and it is dealt with through all the relevant
parameters.
CHAIRMAN KRESS: How do you determine
what's in scope because it seems to me like the
determination of any input value in the code could
reasonably be said to be in scope. I don't know how
you determine what's in scope.
MR. ULSES: In this case, it's determined
because we know that GE has an approved method which
the staff has already reviewed and approved. There's
an SER written on it that says it's acceptable for
doing those types of calculations.
CHAIRMAN KRESS: Okay.
MR. ULSES: That's the finding the staff
has made.
MR. CARUSO: Doctor Kress, this is Ralph
Caruso from Reactor Systems Branch. I think there may
be a little bit of concern here that in the regulatory
context there's no opportunity for the staff to review
these inputs that are generated for these codes.
Realize that reviewing the code itself is just one
part of the regulatory fabric. We do, as we've been
doing for the power upright reviews, we've been doing
a number of audits of the actual calculations where we
send people like Tony out to GE to look at the actual
design record files to look at the actual input values
that are put into these codes and that is the context
in which we would verify that they were using the
appropriate value of beta, if they were calculating it
appropriately with the lattice physics code and then
appropriately inputting it into TRACG.
The code review itself does not
necessarily include a review of all of the steps of
the surrounding methodology because we just don't have
the resources to completely review a methodology every
time we do a review of a particular part of it. We
understand that the other parts are there and we take
them into consideration as we do the review, but we
don't necessarily review them entirely. We have other
regulatory means to verify that they will be done
properly.
CHAIRMAN KRESS: You can review it at the
time of an application.
MR. CARUSO: We can review it when an
individual licensee applies for permission to use this
code for their plant. We can review it when we --
CHAIRMAN KRESS: Will part of the
limitations on the use of this code for this
particular aspect specify that the -- I guess it's the
ODYN code must be used to determine this beta.
MR. ULSES: No. Actually, the lattice
code G uses is called TGBOA. I don't know where that
came from, but that's what they call it.
CHAIRMAN KRESS: But will you specify in
your limitations that to determine this input you will
have to use that code or if somebody uses a different
code to determine that input, you'll have to review
that one at the time of the application. Is that the
approach?
MR. ULSES: Well, at the time of the
application, what'll happen is the applicant in this
case -- it would actually be the utility coming in for
the proposed application -- they would have to
identify what methods that they used.
MR. ULSES: And if they had a method that
was not reviewed and approved, we would have to make
the choice of whether we're going to review it or
whether we're going to say we don't have the resources
to review it because it would require an additional
code review.
CHAIRMAN KRESS: Does the code have a
default value for this particular input?
MR. CARUSO: Does TRACG have a default
value? Is that what you're asking?
CHAIRMAN KRESS: Yes, because I understand
part of the problem is you have to -- the input value
depends on the power history and the loading of the
code and so forth, so you can't just have one input
value. You have to know what the particular state of
the core in order to get it.
MR. ULSES: Sure. Well, there certainly
will be default values in the code. However if you
look at the application of this particular code -- in
this case, TRACG -- it's not really designed to be
used outside of the automation mechanism that they use
at GNF which basically would require that you have
input files which are calculated to the appropriate
exposure points for the appropriate reactor being
analyzed and, therefore, that's going to be imposed by
their QA program which is going to require them to do
the analysis with the correct input.
MR. CARUSO: And this actually applies to,
I would think, any calculation that is done. The QA
procedures Appendix B requires there to be a
documented description for every input value that goes
into the code and the way we regulate that is we do
inspections, we do audits to verify that they have
chosen the appropriate value and that they have a
basis for it. So even though there may be a default
value in the code, if they use that default value
without a basis, then they subject themselves to the
possibility of this being discovered during an audit
or an inspection and appropriate regulatory action can
be taken for noncompliance with Appendix B.
MR. ULSES: As an example, what I would
expect is--
CHAIRMAN KRESS: Aren't things like that
flagged in the SERs and when you get around to --
MR. CARUSO: Because of the large number
of input values, we don't flag in the SER every
individual input. That's a requirement of Appendix B
is that every value that's used in a calculation
should have a basis for it.
CHAIRMAN KRESS: Okay.
MR. ULSES: Just as an example, I would
expect when I would go down to, say, the GNA offices
in Wilmington and I would audit a design record file,
I would expect to see a discussion in there if the
analyst, say, made the choice to use the default
values and they would say why they did it, why it has
no impact, and then the reviewer of that design record
file would have to either say I agree with this, I
challenge you on this, and this is why I think this is
right or wrong. That entire deliberation ought to be
documented in the records that are kept on the
analysis. That's the QA trail for those types of
questions, and those are things that we will audit
when we go down to the site.
MEMBER SCHROCK: What is the required
detail of the input data?
MR. ULSES: I don't think I understand the
question.
MEMBER SCHROCK: Does the input provide
spatial distribution of beta?
MR. ULSES: It's handled on a fuel type.
Yes, it does. Let me just say yes to that question.
I can go into more detail if you want as to how it
actually works. Hopefully, I won't tread on any
proprietary information here. But it certainly does.
You have the information on a node-wise basis which
basically means it's a six inch by six inch by six
inch square portion of the reactor. Each one of those
nodes will have individual values of beta which are
appropriate for the exposure points that are being
analyzed. That's correct. Yes.
Do you have another question, Doctor
Schrock, or shall I go ahead and proceed here? Okay.
Let's see. I think I'll skip my name because I think
we all know who I am now.
What I'd like to do in this discussion is
I'd like to focus really and discuss basically the
conclusions of the review and then I'd like to go
through what I call sort of a lessons learned on this
particular review because this review was very
challenging. There were some areas where I ran into
some difficulties, and I'd like to discuss those and
I'd like to go through some areas where I think I can
do a better job the next time and areas where we can
improve upon what we've done. That's essentially what
I'd like to try and do today.
These are the areas where the review was
focused. We obviously reviewed the documentation
which was given to us by GE.
CHAIRMAN KRESS: Did you find the
documentation sufficiently good and detailed for you
to make your reviews?
MR. ULSES: Well, the documentation is
acceptable for use internally by GNF. It's not
information that I would consider to be acceptable for
public dissemination because it's not a discussion
from the cradle to the grave on how this code works.
But if you use it in the context of the organization
that's actually using it, I feel the documentation is
acceptable. There actually are some areas where it
was kind of disjointed and actually, I plan on
discussing those a little later. There were some
models that were described in one document whereas I
think they should have been in another one, etcetera,
etcetera. There were some areas where there were some
difficulties, but I think if you put it in the context
of the application and who's going to be using this
code, I feel that it's acceptable for internal use by
the applicant.
As part of the documentation review, we
went through a discussion of the actual model
development itself, the theoretical development. What
I refer to as an auxiliary model is, say for example,
like moderator heating effects, heating of structure,
that those are discussed in the documentation and, of
course, we also reviewed the validation that was
presented and we also went through a sample problem
which was derived -- this is very similar to what we
did in the RETRAN review.
Basically we derived a problem on which we
ran the TRACG code. This is actually the staff ran
the code and we also ran our own methods and then we
tried to do a comparison. Essentially, what we're
trying to do there us we're trying to sort of bridge
the gap between the data that we have available which
is very old data. It's on reactor designs and fuel
designs that aren't really in use any more. I wanted
to sort of bridge the gap there and try and get an
understanding of how the code will perform if we use
a more modern fuel design. That's effectively the
point of the data analysis.
MEMBER FORD: Just for clarification, your
use of the word validation is not validation of a code
to make sure that operator A gets the same results as
operator B on the code. It's on how well the code
predicts experimental observations.
MR. ULSES: Yes, sir. Right. This is a
mixture of experimental data and there's also some
plant transient data as well which has been validated
against it. Again, it's all in that report which I
understand you haven't seen so it's very difficult to
get into and it's certainly proprietary so I can't get
into the details of the actual results. I don't know
if we want to maybe do it this afternoon. I don't
know if that's possible and if it would be interesting
to anybody, we could put some cards up this afternoon
in closed session just to show you some of the
information. That's something you can think about.
CHAIRMAN KRESS: I think for Peter's
benefit and even Jack, he hasn't seen that either, it
might be worthwhile to do some of that. I don't know
how much time we've got.
MR. ULSES: Perhaps we can think about it
and if we have enough time, we can maybe do it this
afternoon. That would obviously be up to GNF if they
want to do that because it's their data.
MEMBER SCHROCK: Also, I had understood
that you had difficulty matching GE calculations in
some instances.
MR. ULSES: And that's something I want to
discuss. Yes, that's exactly one of the things I
wanted to discuss which is why I constructed the
presentation as I have. I want to get to the bottom
line, and then I want to discuss the problems that I
had which basically have been resolved. There were
some issues where basically I made a mistake is what
happened, and that's why there were differences. I'll
say my mea culpa right now. That's what I want to get
into, and I want to discuss how that happened, and I
want to discuss some areas where we can improve in the
future.
So let me move on here. I think I've
already discussed most of this. Basically, what we're
doing now in these days when we're actually reviewing
the code by having the code and executing the code is
we're focusing more on the performance of the code
rather than just looking at the presented written
material. This is a model that we found has worked
well for us in the past, and I think it actually
worked well in this case, I'd say even when one
considers the difficulties that we had along the way.
I'd say this was an effective review model. I don't
know if GNF would agree with that, but I think it was
an effective review model from the staff's
perspective.
CHAIRMAN KRESS: That's interesting to
know because ACRS has pretty much been advocating that
approach for a long time.
MR. ULSES: One thing that was certainly
useful with the way we did it this time is it actually
led us into reviewing some models that we probably
wouldn't have reviewed which actually were more
important than I originally suspected. So I guess in
a sense that was certainly an effective outcome of
this review process and again, I'll discuss that in
more detail after we get to the SER conclusions.
Basically, all the information at the
beginning of the presentation is all contained in the
SER. It's just sort of ground out of there.
These are the validation studies that are
in the assessment manual. These are the areas where
they have data. Obviously, the Peach Bottom turbine
trip tests which are validated against. And the rest
of this information is -- there's start-up testing in
there and there's also some data from planned events
which has been assessed and it is in the manual. I
just wanted to put this up here to show you that they
do have actual data that they compare their code to.
CHAIRMAN KRESS: Is this the proprietary
data?
MR. ULSES: Yes. If we actually wanted to
show the actual results, that would be proprietary.
These are effectively the conclusions that
are in the SER. We felt that the theoretical
development captured the relevant physics necessary to
predict an AOO type transient.
CHAIRMAN KRESS: It captures them to
sufficient degree?
MR. ULSES: They provided reasonable
assurance that the code will accurately predict these
answers for application to licensing.
And again, what I refer to as auxiliary
models which are basically gama heating of the liquid
in the structure. I felt them to be very well
developed, and that they would be effective in the
proposed application. And again, the decay heat
modeling. I felt it was adequate for the proposed
purpose and, again, Doctor Schrock, I definitely think
your criticism is valid, and I will definitely change
what's written in the SER to describe the constraints
on the review.
MEMBER SCHROCK: I don't know what you
mean by you feel it's adequate. I mean you need some
quantitative --
MR. ULSES: Well, let me say that it is
adequate for the proposed application because decay
heat is at best a second order effect, perhaps even a
third order effect, for the application that's been
proposed.
MEMBER SCHROCK: Well, I don't know that
it's a third order effect but --
MR. ULSES: It's definitely a second order
effect, at best.
MEMBER SCHROCK: Yes. What I'm saying is
that we haven't heard evidence of such conclusions,
and I think we should.
MR. ULSES: Interesting.
CHAIRMAN KRESS: What do you do about loss
of feed water with respect to that?
MR. ULSES: Well, it's A) not a limiting
transient. It's one that's analyzed because it's
required by Chapter 15.
CHAIRMAN KRESS: It's a low frequency.
MR. ULSES: It's usually a low effect
transient. Correct me if I'm wrong here. I think
it's usually not one that sets any limits on the plant
and, therefore, the decay heat, if it's high for that
particular scenario, the uncertainty in the model
would not have a significant effect on plant
operations. Again, correct me if I'm wrong but I
believe that's correct. And that again would be why
that was dispositioned as it was.
Again, this goes back to a discussion of
documentation we had earlier, Doctor Kress. It's
acceptable for use by the applicant, and that's
obviously the intended audience of the documentation.
It certainly isn't documentation that I would expect
somebody who didn't have a great deal of knowledge of
the methodology to pick up and be able to fully
understand it. But again, that's not the intended
audience of the documentation.
This goes on to our test problem that we
derived. Essentially, like I said, what we were
trying to do here is we were trying to bridge our
understanding of the code's ability to handle the
reactors that are being run and used right now in this
day and age. The core is based on an ABWR reactor.
It was designed to be as easy a model as we could. A
zero exposure so we didn't have exposure effects.
MEMBER SCHROCK: That may be because in
the SER you do not include ABWR as the reactor types
to which the code may be applied.
MR. ULSES: Well, the issue though is that
that was a model that GNF already had available and it
was based on modern GE fuel. That was the reason that
was chosen. And all we modeled there was the reactor
core itself. We did not model the rest of the steam
supply system at all.
MEMBER SCHROCK: Well, I asked myself the
question in the opposite sense as I read that. Why is
ABRW excluded from what the code is approved to do?
MR. ULSES: Well, I'd say right now off
the top of my head we're not running any ABWRs in the
United States and plus that's a good question. I
think that's something that we were asked to review
and approve more than likely.
MEMBER SCHROCK: Is it necessary to call
it out?
MR. ULSES: Well, it's going to be trying
to identify the source.
MEMBER SCHROCK: Or exclude it from the
list of those for which it could be applied.
DOCTOR ANDERSEN: Jens Andersen from GNF.
When we made the submittal to the NRC, we made the
submittal to be valid for operating BWRs in the United
States. There are no ABWRs in the United States.
Clearly, the difference --
MEMBER SCHROCK: So it's GE's choice, not
NRC's choice.
DOCTOR ANDERSEN: It is our choice. The
difference in the ABWR design and the conventional BWR
design is mostly in the recirculation system. There's
clearly no relevant significant differences in the
core design. We chose NABWR core design because it
would simplify the process of generating the nuclear
input that would allow us to do the comparisons
between the NRC codes and the GE codes because it was
an initial core at zero exposure. It greatly
simplifies the process.
MR. ULSES: And it's just discussed in the
SER because we were trying to identify it.
MEMBER SCHROCK: You could manage to have
the approval cover the SBWR, but that's your business,
not ours.
MR. ULSES: I was just simply trying to
identify the source of the model. That was the reason
it was discussed in there. And again, obviously we
looked at the steady state results to make sure that
we didn't have any gross discrepancies between the
application in TRACG and the application with our
methods, and we didn't see any differences. Well, we
didn't see any large differences. The codes compared
well. And we also ran some small perturbation
transients to look and make sure that we didn't see
any gross discrepancies in the way the model would
respond to, say, a small perturbation in pressure, a
small perturbation in flow.
I just want to briefly put up again. This
is all in the SER. This is the initial steady state
power distribution out of the two models, the two
codes, and they compare very well. There are some
discrepancies on the periphery due to the handling of
the modeling of the reflector. However, for this
case, we feel that this is a pretty good comparison
and that the model is working very well in both cases.
MEMBER FORD: You said the model was
working well. What is your definition of working
well?
MR. ULSES: Well, in this case, since
we're trying to compare one code to the other, if we
get good comparison, we feel that both codes are
modeling the problem in the same way and giving the
same answers. That was a figure of merit.
MEMBER FORD: Validation of those models
is based presumably on data from off-shore reactors?
MR. ULSES: Actually, the data for TRACG
is based on all data, I believe -- actually, there's
a couple of data stats from overseas reactors but, for
the most part, it's based on U.S. data.
MEMBER FORD: That's not ABWR.
MR. ULSES: Right. Again, it was just
intended to make everyone's life easy. That's the
reason why that reactor was chosen, because it was
available, there was zero exposure, and all we're
trying to do here is examine the response of the code
to a perturbation, not necessarily the ability to
actually model the steady state characteristics of the
reactor which would be burn-up, for example. That's
basically a steady state response, and that's not
really modeled in TRACG. I mean it's handled as an
input parameter to the code. So what we're trying to
do is we're trying to examine the code's ability to
model the effect of a pressure perturbation.
MEMBER FORD: The number of ABWRs against
which this prediction would be compared were not
large.
MR. ULSES: But this reactor will never
exist. This is a hypothetical reactor that we made
up. This is a sample problem. This reactor will
never exist.
MR. HECK: Excuse me. This is Charlie
Heck from Global Nuclear Fuel. The loading, the core
specification bundle designs here, one of the
constraints was that it be an initial core so that
there would be no issues regarding how exposure
differences possibly in lattice physics. And that was
Tony's specification. He said initial core as
realistic as possible, so we chose a real design which
was an ABWR core.
The only initial core we have these days.
And we took it and we trimmed it so it's really not
ABWR core per say. This is actually a 560 bundle
core. ABWR is much larger than that. Eight hundred
and twenty, I think. We trimmed it to the right size
maintaining the same proportions and the calculation
that's being done here is just for the core model
hydraulics. The vessel boundary conditions above and
below the core are specified. So this is a problem
designed specifically to focus on the neutron kinetics
and coupling of that with the hydraulic models.
CHAIRMAN KRESS: Tell me what I'm looking
at. This is one quarter of the core.
MR. ULSES: It's one quarter steady state
power distribution.
CHAIRMAN KRESS: Steady state full power
distribution and if I were to ask how to compare the
two code calculations in terms of some figure of
merit, would I be asking what the differences were in
terms of some root mean square area or would I be
asking how the differences affect peak clad
temperature of the hot model? How do you compare two
curves like this and ask yourself whether they're the
same or close enough? I see very little difference.
I can see the parts around the periphery where you say
there's some difference but it's a little hard for me
to figure out how good the comparison actually is. It
looks almost identical.
MR. ULSES: Well, the real figure of merit
for this study was the energy deposition which is
calculated by this code following a simulated
pressurization transient.
CHAIRMAN KRESS: You started at steady
state and then you ran through --
MR. ULSES: What effect are any
discrepancies you see here going to have on the effect
of the analysis with these two codes on the energy
deposition following a pressurization transient.
CHAIRMAN KRESS: It's a total energy
deposition.
MR. ULSES: Right. That's what's going to
lead to changes in MCPR. That's going to lead to
changes in the calculated changes in critical power
ratio which are clearly the figure of merit for an AAO
analysis. So that's basically the bottom line. What
we're trying to do here is make sure that the models
had no gross discrepancies at the steady state point.
That was the only point of doing this particular
figure.
MEMBER SCHROCK: TRAC/Nestle has been used
previously for AOOs.
MR. ULSES: No. It was used -- the staff
code that we used for these types of simulations, we
used it in the RETRAN work where we worked on RETRAN
3D. And it's a code that's used by the staff for
these types of audit type of calculations. It's not
a licensing code. It's not an industry code.
MEMBER FORD: I shouldn't be reading
anything more into that draft than to say that there's
little difference. Whatever the difference between
those two models are if it's an input -- it has no
impact at all on the resultant prediction.
MR. ULSES: I wouldn't say no impact but
there's a small impact on the final bottom line.
That's the only point of this curve is to make sure
that there are no gross discrepancies in the initial
conditions.
MEMBER FORD: I may be a devil's advocate
here but the model could be completely wrong because
I don't see any data, observed data.
MR. ULSES: Right. Both codes have the
potential to be completely wrong. You're correct.
And that's why you need to fold in the existence of
experimental data into these types of studies.
MEMBER FORD: For ABWRs, whatever the fuel
configuration is, there's very little data existing.
MR. ULSES: Well, I can ese it was a
mistake to put ABWR on here. The only point of this
study, this reactor, like I said, is hypothetical. It
will never exist. It will never run. It's just on
paper.
MEMBER FORD: I'm trying to understand
what may take away from that
MR. ULSES: What we're trying to do is
we're trying to design a sample problem which would be
easy for both organizations to set up and what we want
to do is we want to isolate the kinetics modeling from
the reactor system modeling as much as we can.
Obviously we can't do it entirely. So we stripped out
all the rest of the vessel model. There's no
separators. There's no recirc flow. There's nothing.
All it is is the reactor model and it's got a velocity
boundary condition at the lower tieplate and the
pressure condition in the upper plenum.
So that's the point in this. The
existence of this model was used because it already
existed and they were able to take it, they were able
to scale it down and make a smaller core out of it
without doing a great deal of work. That was the only
point of using this model. It's not intended to
validate against the ABWR at all. It was used because
we were able to isolate the kinetics modeling from the
rest of the reactor system. That's the point of this
study.
MR. BOLGER: This is Fran Bolger from GE.
I just wanted to point out that the model that you see
under the TRACG is based on the GE steady state
simulator. Now that steady state simulator is the
same simulator that is run at the plants and those
simulators are compared to LPRM and trip data
regularly. So that's the same model that's validated
on a day to day basis in the fleet.
MR. ULSES: Let me move on here.
MEMBER SCHROCK: Let me make one last
point. The TRAC/Nestle is what version of TRAC?
MR. ULSES: It's using the NRC version of
TRACB which we all know and hopefully love or don't
love. It's the version that came out of INEEL.
MEMBER SCHROCK: But you have other
experience to tell you how good or not good that
should be expected to do on a typical problem like
this.
MR. ULSES: That's correct. TRACB itself
has validation. It's not an unvalidated model.
Obviously it's not validated against the same data
that they validated TRACG against obviously because
most of the data they use is going to be GE
proprietary information. But it is a validated method
for things like, say, void fraction predictions,
density predictions, fuel temperature predictions,
things that are going to be relevant for this
particular study.
MEMBER SCHROCK: But you don't use its
kinetics model.
MR. ULSES: No, not using its kinetics
model.
MEMBER SCHROCK: Because it's not multi-
dimensional.
MR. ULSES: It has a one-dimensional
model, but it's not being used. All it's doing is
it's giving Nestle density fuel temperatures. That's
it's only function for this study.
I just wanted to put up again the axial
void fraction profile radially collapsed, one-
dimensional. The only difference is this little
change here and that comes in because of the existence
of the part length rods and that's the TRACB modeling.
There's a difference. You could go into the part
length rod and region. But again, as you'll see, it
does not have an effect on the overall bottom line
answer.
CHAIRMAN KRESS: Is this integrated
radially across the core?
MR. ULSES: Yes. This is radially
collapsed, one-dimensional average axial power
distribution. I'm sorry. Average in channel void
fraction. Okay.
This is just a brief description of how we
set the problem up. What I did was I ran an input
deck that had the entire reactor system model to get
the boundary conditions which were then imposed on our
simpler model and that enabled us to do the transient
modeling. And then we modeled the case in TRACG using
multiple options available in the code. We turned
switches on and off to see if they had effects on the
results.
MEMBER FORD: Again, I keep coming back to
this and you gave the key answer. This tells me
nothing at all how good the model is.
MR. ULSES: Right. All this is telling us
is -- well, it's telling us that we're able to bridge
the gap and that we have an understanding that we have
multiple codes which can model a reactor using modern
GE fuel. It's telling us an area where we do not have
any data because there is no data that exists.
MEMBER FORD: But the critical question is
any of these codes, they all seem to give the same
results. Are there operational data against which you
can have a one to one comparison between the
prediction and the observation? What you've told me
is there is.
MR. ULSES: For pressurization transients
with modern fuel, it's my understanding that there is
no data available. We have data from the '70s using
fuel that's no longer run in reactors which allows us
to do validation against or verification if you want
to look at it. The only point of this particular
study was to attempt to understand the ability of
TRACG when compared to another method, whether there's
anything unique about modern fuel designs which will
lead the staff to believe that the code is not capable
of modeling a modern reactor. That's the only point
of this study because there is no data with modern
fuel, as I understand it, for pressurization
transients. Correct me if I'm wrong here.
DOCTOR ANDERSEN: This is Jens Andersen
from GNF. I understand that you're a little at a
disadvantage but if you remember from Ralph Landry's
presentation, we have one of the reports that was
submitted to the NRC and also to the ACRS was the TRAC
qualification report which is about an inch and a half
thick and it has an extensive qualification consisting
of basically four sets of qualifications.
One was a set of separate effects test
where we had isolated individual phenomena and tried
to qualify those phenomena like could we predict a
given heat transfer core regime? Could we predict a
void fraction in the fuel bundle? Then it has more a
complicated section on component performance like how
well do we predict a steam separator performance? How
well do we predict a jet pump performance? This is
all based on data and full scale data wherever full
scale data was available.
Then we have a section in the report which
is what we call integral system effects test which is
basically scale simulation of an entire BWR typically
scaled down to a few bundles that are simulated
through electrical heating. That gives us a
qualification of how well the code predicts system
interactions between various components in the
systems. And then we have the final section is a
section of comparison against plant data where we have
full scale plant data, typically data taken during
plant start-up tests.
That includes data like the Peach Bottom
turbine trip test. Those are, as Tony Ulses
mentioned, all the data based on 7 X 7 and 8 X 8 fuel.
We have later data with more modern fuel types like
the Nine Mile Point pump up-shift test which contains
predominantly GE11 fuel which is typical of the modern
fuel with a large central water rods and the part
length rods. So we do have qualifications for modern
fuel types, and it shows how the kinetic reacts to
changes in the hydraulic conditions in the core.
So all of that is in the qualification
report and it's based on comparison to actual plant
data. Now, we have taken that a step further in the
application methodology report, and that's where we
apply the statistical methodology is that we have gone
in and done a statistical analysis of all the
qualification data and quantified what are the
uncertainties in predictions of the individual data so
that we can properly account for this uncertainty in
the application methodology.
So all of that is in the report and,
unfortunately, I understand you haven't seen these
reports, and we'll be happy to show one of the
reports. We can do it during the break.
MEMBER FORD: I'll look at it like this.
(Indicating blindness with his hands.)
MR. ULSES: Well, anyhow, I'd like to move
on to the next slide. Basically the next slide is the
results of the sample problem. Again, the ABWR
problem which is not a real reactor which is intended
just to allow us to bridge the gap between the areas
where we have data for the pressurization transients
which are typically limiting AOOs and BWRs to the
reactors that are operated in the year 2001. That's
the only point of this problem, again.
Actually, what I'm going to do is put up
another slide that's not in your handout. I apologize
for this. I'll get to this to you, Paul. This is a
slide that actually is in the SER. Essentially, these
are the results. These are the relevant results.
What you see here is the power on the top one, the
total power from the reactor. Obviously, there are
some discrepancies there between the codes. We have
a couple of hundred megawatt difference in the peak
power between the TRACB calculations and the TRACG
calculations. But if you look at the effect --
CHAIRMAN KRESS: Under a pressurization
transient without scram, you're basically checking the
void coefficient effect and the temperature
coefficient effect.
MR. ULSES: That's correct. That's what
we're doing. What we're doing is looking at the
balance of the reactivity from the void effect and the
fuel temperature effect.
CHAIRMAN KRESS: The voids get collapse
and that adds power and the temperature goes up
because of the increased power and it turns it around.
MR. ULSES: That's exactly what happens
and you also have a trip of the recirculation pumps as
well.
CHAIRMAN KRESS: Okay.
MR. ULSES: Which will also significantly
drop the power. That's what's going to happen. But
if you look at the bottom curve, which is just simply
the interval of the top of the curve, what you're
going to see is that the effect on the energy, which
is really the figure of merit for an AOO transient, is
effectively -- well, it's not nil. It's obviously
very difficult to see on this scale. But it's very
small which would mean that the actual calculated
change in the critical power ratio from these multiple
simulations would be very small which tells us that
these two codes obviously are able to predict that
this model is the same, if you will, in effect.
Obviously, there are some differences.
CHAIRMAN KRESS: What are the differences
between the blue and the red?
MR. ULSES: That's using a different model
in the TRACG code which I'd like to discuss next
actually. That's one of the things that I discovered
going through this review which was very intriguing.
CHAIRMAN KRESS: What's the cause of that
little plateau on the right?
MR. ULSES: Right here?
CHAIRMAN KRESS: Yes.
MR. ULSES: This is, in effect, the
competition of the void reactivity and the fuel
temperature reactivity and how it's affecting the
power. That's what's causing that.
I'd like to just move on to the review
conclusions which again are in the SER. Effectively,
what we concluded is that we have reasonable assurance
that TRACG can model AOO transients. This is based on
obviously evaluation of the GNF validation,
benchmarking, if you will, comparison to actual plant
data and also based on the sample problem which we
derived. And again, this is just simply stating what
we've already stated, that the code that's being
applied to Chapter 15 transients and that is the scope
of the SER.
MEMBER SCHROCK: In the SER you address
difficulties that you had in predicting results from
the SPERT 3 tests. You've not commented on that. Is
that because you're excluding RIAs?
MR. ULSES: That's basically the bottom
line. RIA is not included in the scope of review, but
actually I do plan on discussing --
MEMBER SCHROCK: Why is it in the SER?
MR. ULSES: Well, because it was in the
validation documentation which was given to us by GNF
and, therefore, I wanted to discuss it. And that's
one of the things I plan on discussing in the
discussion of review challenges which is what I'd like
to go to next.
CHAIRMAN KRESS: I was wondering. We need
to take a break some time right about now. Would this
be a good time?
MR. ULSES: This would be a great time.
This is sort of a change in the focus, but I do plan
on discussing really the why. I didn't discuss the
SPERT test and the SER because it really is not
relevant for the proposed application. You are
correct.
MEMBER SCHROCK: Well, if I read your SER
conclusions correctly, you have a very different view
of that than I have. It seems to me that SPERT 3's
very small core has essentially nil spatial
difficulties.
MR. ULSES: Very little, if any.
MEMBER SCHROCK: It's practically a point
reactor calculation and for what reason, I can't
imagine that a more sophisticated code shouldn't be
expected to give good results on that.
MR. ULSES: And that's a very good
question and that's the question that I had in my mind
and that's one of the reasons why I decided to discuss
it, and I do plan on talking about that in this
presentation a little bit later.
CHAIRMAN KRESS: In that case, I'm going
to declare a recess for 15 minutes. So be back 20
minutes after 10.
(Off the record for a 15 minute recess at
10:07 a.m.)
CHAIRMAN KRESS: I think we can go back in
session now. Talk about challenges. Is that what you
were going to do?
MR. ULSES: Right. This is basically the
mea culpa I referred to earlier in the presentation.
Effectively, the differences that you were talking
about, Doctor Schrock, in that one draft RIA that I
prepared which showed those major discrepancies in the
code results. Basically, the bottom line of why that
was there is I made a mistake in the input stream of
my analysis. It was discovered, and the differences
went away. The mea culpa is that I made the wrong
conclusion based on what I saw and that's what led to
that draft RIA which hasn't made it into the final
RIAs, by the way, because it was not pertinent because
it was incorrect. But that's basically the issue. If
you want, I can go into more detail as to why the
differences were there or we can leave it at that. I
will pose that as a question.
CHAIRMAN KRESS: Are you asking Virgil or
me?
MR. ULSES: I'm asking any of the members
and consultants if they have any interest in going
into more detail as to why there was a large
discrepancy in the initial analysis.
CHAIRMAN KRESS: You know, I think in the
interest of clarity, I would like to hear a little
more. Yes.
MR. ULSES: Well, basically what it really
boils down to is the way the moderator density is
handled in the TRACG code versus in the methods that
I used traditionally. I think I'm probably going to
tread on proprietary ground here.
CHAIRMAN KRESS: Yes, be careful.
MR. ULSES: With the modeling, you will
halt me. Okay. Basically, the way GE handles the
modeling of moderator density is they use a weighted
average of the in-channel density. In other words,
the water that's inside the box with the water that's
in the bypass region where the control blades run.
That's an average parameter which is passed between
the kinetics and the thermal-hydraulic solver.
Hopefully, that wasn't proprietary. That's not the
way I traditionally model that in the methods that I
use. I usually base it on the in-channel density
alone which for AOO analysis is perfectly adequate
because you don't expect to see any changes in the
bypass. It's going to start off as water and it's
going to stay solid water throughout the transient.
What I had to do was go into the codes
that I had and modify the algorithm to handle that and
I made a mistake in the way that was done and that was
discovered and the error went away. That was the
bottom line.
CHAIRMAN KRESS: So the difference was in
the void coefficient effect --
MR. ULSES: Right. And that's what was
leading to that huge discrepancy which one would
expect because obviously this transient is definitely
void dominated.
CHAIRMAN KRESS: Okay.
MEMBER SCHROCK: So that part of the SER
will be corrected.
MR. ULSES: I don't think it's in the SER.
CHAIRMAN KRESS: It was an RAI.
MR. ULSES: It was an RAI. It was a draft
RAI which is not going to be in the final RAIs because
it was incorrect. That's basically the bottom line.
Anyhow, one thing that I think was good out of all
this is that it did lead me down a path that I
wouldn't have gone into originally which leads me to
the next slide which discusses how GE and I would say
probably every other organization in the United States
uses the MCMP code for validation and verification of
lattice physics methodologies. It's widely used,
widely accepted in most organizations that I'm
familiar with and probably the ones that I'm not
familiar with. It's used to check the results from
lattice physics calculations in the absence of data if
the MCMP is accepted as a very accurate methodology
and it's used for that purpose.
CHAIRMAN KRESS: That's a Monte Carlo.
MR. ULSES: Right. It's a Monte Carlo
solver which was written by Los Alamos and has been
extensively used for these types of applications over
the years.
This leads mein to a discussion of what --
MEMBER SCHROCK: I ask you to look at page
eight of your SER.
MR. ULSES: I'm going to have to ask you
for a copy of it. I don't have one in front of me
here. Okay.
MEMBER SCHROCK: I mean you don't need to
review it now but I mean --
MR. ULSES: If there's something in there
that I have an error in, I'd like to see it.
MEMBER SCHROCK: The paragraph that
addresses the SPERT 3 report.
MR. ULSES: And that I'm going to discuss
more in the end of this presentation, Doctor Schrock.
I have a slide on it. I'd like to discuss that.
Certainly you are right. I agree with you that I
would expect a more modern accurate method to be able
to handle the E-core experiment because if you look at
the documentation that was written up on that
experiment back in the '60s, they were using point
kinetics models and they were very sufficient to model
that reactor. But I'd like to defer that until a
couple of slides from now if that's possible because
I certainly think that needs to be discussed.
Basically what this led me to was the
discovery of a model that I've dubbed the PIRT 18
model for lack of a better word. I don't think that's
what GE calls it, but I sort of made that up because
I needed a word to write in the SER. And what that
basically does is using MCMP and then based on MCMP
results they have a model in TRACG which effectively
modifies the void reactivity which they would have
calculated out of their licensing basis tool to better
compare to the MCMP results. That's effectively how
the model works in a nut shell. I hope that's a
correct characterization of the model.
DOCTOR ANDERSEN: This is Jens Andersen.
If I can just make one comment. You are right in this
characterization. This particular model is described
in the application methodology report and the reason
it's described there is that this was part of the
effort that we undertook to quantify the accuracy of
the various models in TRAC to determine what is the
bias and what is the uncertainty of all the models in
TRAC in order to know what these uncertainties are in
order to apply these uncertainties in the application
methodology.
We have quantified all the model
uncertainties for the models that we thought were
either of high or medium importance based on our
tables. The void coefficient is one of these models
and the benchmarking against the MCMP calculations
were how we quantified the uncertainty in the void
coefficient. So this is part of the process of
quantifying what bias and uncertainty of the models
are so we could account for it in the application
methodology.
We can go into details on that particular
model, but we probably would want to do that as part
of the proprietary session in the afternoon.
MR. ULSES: Sure. Well, one thing I
definitely want to point out though is I just want to
point out the area where the staff had difficulty with
the model, as we understand it.
DOCTOR ANDERSEN: Yes.
MR. ULSES: And the issue basically boils
down to the fact that when you run a Monte Carlo code,
as I'm sure you're all well aware, you don't get a
point answer out of that code. You don't get an
answer. You get a range of answers. And the way GE
has applied the MCMP results within this uncertainty
methodology, they're using the mean value of the
predicted eigen value without consideration of the
error or of the uncertainty in the analysis.
The issue that I had with that, I mean
let's go to a couple of plots here. I don't think any
of this is going to be bad. This is basically --
these are the comparisons of the lattice physics
results of the code that I used compared to the one
that GE used for the sample problem. In other words,
the ABWR test reactor that's fictional that's never
going to be run.
And then these are some calculations that
I did with MCMP myself here at NRC looking at the
lattices that were used in that problem with the
uncertainty bounds. These are the 95 percentile
confidence intervals which are plotted here as error
bars. And again, that has it on there. The issue
that I really had with this model is that let's say we
choose a mean value to do our comparisons with the
TGBLA results and we say that there's a difference
between the results and let's say we're going to
believe the MCMP results and what we're going to do is
we're going to change the TGBLA results to match the
MCMP results.
But if you look at this plot, it would be
equally valid to take the prediction down here versus
the prediction up here because again, this is a value
which is not a point value. All these values here
have been deemed to be effectively the same number
within the way that MCMP is usually applied. And if
you take this difference and you span this across this
curve, it will have an effect on the predicted power
response.
It's not going to be significant, but
there'll be an effect, and that's not accounted for in
this model and that's basically the problem that I had
with it, and that's why the SER is written as it is on
this particular model. It doesn't have a significant
effect on the bottom line answer, which is energy
deposition, but I don't believe that it's well enough
quantified in this context simply because of the lack
of the consideration of this uncertainty band.
MEMBER SCHROCK: Isn't there a probable
value in some distribution?
MR. ULSES: That's basically what this is
but the way these codes are usually applied is that
you don't simply take the most probable value. Let's
say I was going to use this and I was going to do like
a criticality safety analysis, for example, which
obviously is not really applicable here but that's
just an example. What I would do is I wouldn't take
this as the answer. I would usually take the upper
bound because what MCMP is telling me is that it can't
give me an answer with any better accuracy than with
what's within this error bar. That's what I'm getting
out of MCMP. And the point, that's just simply a mean
value, but the code is really telling me that I can't
give you an answer with any more accuracy than what's
within the error bound and, therefore, I question why
the mean value was chosen as opposed to the upper
bound versus the lower bound.
CHAIRMAN KRESS: Those error bands, are
those one sigma, two sigma?
MR. ULSES: I actually don't recall when
I plotted here. I apologize for that. I should have
had that in front of me.
CHAIRMAN KRESS: It's probably one sigma.
MR. ULSES: It probably is, I think. Yes.
CHAIRMAN KRESS: Standard.
MR. ULSES: That's what usually is
plotted.
MR. HECK: Excuse me, Tony. This is
Charlie Heck, Global Nuclear Fuel. I think you said
those are 95 percent confidence bands. Those would be
equivalent to two sigma.
MR. ULSES: That's right. This is the
confidence interval. You're right, Charlie. Thank
you for correcting me.
MEMBER SCHROCK: So they're not bounds at
all.
MR. ULSES: This is the confidence
interval which is what's applied or which is what's
usually used as the output for Monte Carlo codes.
MEMBER SCHROCK: You're calling it bounds
and they're not bounds.
MR. ULSES: Well, that's probably the
wrong choice of terminology. You're correct. But
this is a confidence interval which is what the code
is telling us. This is the highest level of
confidence that the user should put obviously on any
number that's in that range. And the way these
methods are usually applied is they're not used to
derive a point value. If I was simply going to run my
lattice code and I wanted to compare it to MCMP, then
I would say if I had an answer which landed anywhere
within this error bound, I'd say I'm happy with that.
But I wouldn't go in and modify the results of my
lattice code based on that comparison. That's the
area where the staff is a little uncomfortable here.
Everybody goes out and they modify and they actually
validate their code against this number with the error
bars on it and if they say that the answer landed in
the error bars, I'm satisfied with that. But this is
the first application that the staff has come across
where they actually use this result to go in and
modify the results of the licensing tool within the
framework of a code application. And that's the area
where we had some questions. And this was the fist
what I would call challenge of this review.
CHAIRMAN KRESS: So what was the final
resolution of this challenge?
MR. ULSES: Well, the final resolution is
that it does not significantly effect the energy
deposition. However, I do not feel that the model has
been adequately justified and I wanted to make sure it
was pointed out in the SER as such in case it's ever
reviewed again. If in the context of that review it's
determined that the model would have a significant
impact on the result, then a future reviewer would
know to look at it. That's the reason why it's
documented in the SER, for future reference.
CHAIRMAN KRESS: I was trying to figure
out how I would use that distribution and convert it
into an uncertainty on the other calculation. I'm not
sure how I would do that. But that's what you said
you did. You used this distribution to determine the
uncertainty in the other calculation.
MR. HECK: This is Charlie Heck, Global
Nuclear Fuel. We did use the mean value from MCMP.
Those do not get used directly. It's rather the slope
of the value versus a void fraction which is what
defines void coefficient and we use that to quantify
the bias in the void coefficient and the uncertainty
in the void coefficient as a function of two
parameters that are proprietary in nature that we'll
discuss this afternoon.
CHAIRMAN KRESS: But basically you're
saying the MCMP is truth and you use that to look at
a bias in the thing you got then.
MR. HECK: I acknowledge the point that we
are using the mean value from MCMP as the basis for
quantifying the void coefficient that MCMP would get
for purposes of comparing it to the void coefficient
that our TGBLA lattice physics method would predict
for the same conditions.
CHAIRMAN KRESS: Okay. I'm not sure I
have a problem with that. I'll have to think about it
a while.
MR. ULSES: I don't think I have a problem
with using it to validate. The issue I had a problem
with is using it to modify the output of the licensing
basis tool. That's the area of contention. I have no
problem actually using MCMP as a validation tool
because I believe it's a very accurate code. The
issue the staff had was that those results are used
then to actually modify the output of the TGBLA
results for application in TRACG. That's the area
where we had contention. It's not the application of
the code as a validation tool. I think that's very
acceptable.
MR. HECK: This is Charlie Heck again. I'd
just like to put this a little bit in perspective.
What we're talking about here is about a three percent
bias in void coefficient and about a five percent
standard deviation in void coefficient and the results
of that on the impact for calculating CPR. So I think
we need to consider it within that framework. We're
looking at basically the bias and the uncertainty
associated with these inputs. In this case, the
lattice physics captures these inputs and it
propagates from upstream so it's really looking at the
variability and the inputs.
I want to emphasize that the variation
lattice to lattice across the fleet and the different
kinds of lattice configurations. This is just one of
hundreds of thousands that that variation that's
accounted for on an exposure point by point for each
specific core condition is much greater than any sort
of bias that we're seeing here on a particular lattice
by lattice. It's much, much larger.
And so I would contend that consideration
of the fact that the Monte Carlo variation is
uncertain within this band is more than washed out by
much larger and more important variations associated
with modeling the specific problem.
MR. ULSES: What I'd like to do is move on
if there's no other questions, comments.
MEMBER SCHROCK: Have I got the right
interpretation of the Monte Carlo code? It's a
transport theory level code?
MR. ULSES: Yes. You could characterize
it as such. Yes. Without going into painstaking
details, yes.
That's a good lead-in to the next
discussion of the validation which is where I'd like
to discuss the SPERT question that you raised, Doctor
Schrock. The emphasis in the review was on the
validation which was presented against the
pressurization transients because those are what are
typically limiting. We certainly considered all the
validation, but if you look at the SER you're going to
find a discussion only on the pressurization
transients mainly because that's where the emphasis
was placed in the review.
And we discussed the SPERT results in the
SER and obviously those are like an RIA type of
experiment. They're not really applicable to AOO.
They're really beyond scope. But the point of
discussing them in the SER was to ensure that if TRACG
is ever applied to a situation where they would be
significant, that they're reviewed in detail because
I agree with you, Doctor Schrock, I believe that with
a code like TRACG you should be able to accurately
model the SPERT tests, and that's the reason why it's
in there. To make sure that in the future if this
code is ever reviewed for an RIA type application that
it is reviewed and also point out that the staff right
now would not be satisfied with those results in that
application.
As an example, we've demonstrated that you
can model. Let me just put a slide up here. This is
from our RETRAN work where we modeled SPERT. You can
model the SPERT reactor experiment. This is what I
was showing you before. This is what the Nestle code
comparing to a SPERT test. It's possible to model
that test very accurately with these types of codes.
These are the kinds of results that I would have
expected to see and that's again why it was pointed
out in the SER. Simply to ensure that if it's ever
reviewed in the future that it's looked at in greater
detail than what it was looked at in this case because
it was considered beyond the scope.
CHAIRMAN KRESS: The SPERT just pulls out
a control rod and--
MR. ULSES: Right. Yes. It was a rod
ejection type experiment. It was a very small
reactor. There were no spatial effects. Basically
what you're modeling is the ability to balance the
reactivity of the system. That's really all you're
after here. Which is why point kinetics models do
very well on SPERT because the reactor is very small.
But the point here is simply that these types of
modern, multi-dimensional methods can and ought to be
able to model this reactor. That's the point. And to
make sure that in the future it is reviewed.
CHAIRMAN KRESS: What did the results look
like with the GE code?
MR. ULSES: Well, they're proprietary
obviously, but they did okay on the energy.
CHAIRMAN KRESS: The bottom line.
MR. ULSES: Right. Did okay but the power
curve was off.
CHAIRMAN KRESS: Shifted?
MR. ULSES: I think it had the peak, if I
recall, in the right point but they missed the
magnitude by a pretty large percent and then they
undershot the tail which is why the energy came out
okay in the long run. And again, I can't put the
curve up here because I'm sure it's proprietary. But
that's the recollection that I have in generalities.
MEMBER SCHROCK: I'm afraid I still have
to contend that this paragraph on page eight in the
SER--
MR. ULSES: Let me look at this. I
apologize. I haven't actually looked at it yet.
MEMBER SCHROCK: It's a totally different
picture than you've just described. It's attributing
difficulties that you were unable to resolve to the
challenging nature. I mean SPERT 3 E-core is a
challenging experiment to model. That's what you just
said.
MR. ULSES: And the reason why I put that
in there is because it is a challenging experiment to
model. There was a great deal of effort that went
into the results I'm showing you right here. It's not
something that you can sit down and model just right
off the bat. You're going to have to do code changes
in order to do it. It's not going to be something
that you're going to be able to handle very easily.
It's a very challenging model. It's very challenging
to set the input up generating cross-sections.
They're very challenging. This thing used control
rods.
MEMBER SCHROCK: You could say that of any
calculation. I mean if you don't have the proper
inputs to match the experiment, you're not going to
get --
MR. ULSES: Right, but if you try to apply
say like a licensing basis lattice physics tool which
you use to model a standard in a light water power
reactor, it's going to have a very hard time trying to
model this reactor because it used control rods that
are the flux trap style. Very difficult to model.
And that's going to be a very large challenge for code
model. It's not very easy to do.
MEMBER SCHROCK: I don't find any
relevance of that to your purpose in review.
MR. ULSES: Well, the intent of the
sentence was to concede the fact that it is a very
difficult and challenging experiment to model.
However, the point that I'm trying to make here and I
believe I make in the end here is that we expect that
they should have been able to do a better job and that
we would expect to see a better job if we ever had to
do a review where we had the results of the
discrepancies between TRACG and SPERT which in this
case we felt we did not because of the scope of the
application.
MEMBER SCHROCK: I read this paragraph and
I came away with the interpretation that you're saying
that you got poor results and you're not sure why you
got poor results but there may be something here for
investigation.
MR. ULSES: Right. That's basically the
point of this paragraph. To make sure that in the
future if the scope of review or whatever include
these types of simulations, that the staff would give
it the level of review necessary and would then have
to resolve the question of why TRACG predicted one
thing and the experiment was something else. There
are literally a whole host of possible explanations
which we didn't delve into in this review because we
didn't need to because this was beyond the scope. But
I wanted to make sure we reenforced it because it was
in the documentation which we reviewed. I wanted to
make sure that it had the proper emphasis.
MR. HECK: This is Charlie Heck, Global
Nuclear Fuel. I'd just like to comment a little bit
more on what you're saying, Tony, about the
difficulties in modeling this SPERT core. I'll first
of all make the point that it's a code core, so any
comparison relative to AOO applications would be
questionable at best.
Secondly, it has a much different rod
configuration than anything in light water reactors so
that again introduces variability. Also, I'd make the
point that modeling it in point kinetics where many of
the things are of unknown nature and are collapsed
down to a single point is perhaps easier than trying
to actually model the lattice physics, especially, as
you pointed out, Tony, the lattice physics codes
themselves have to be modified to handle this
particular geometry. In which case you'd have to
question whether or not -- well, certainly they're not
the same code that's being used to model the AOO
events.
Thirdly, I think you make the point right
up there on your very slide where you indicate the
control rod worth for this particular experiment plus
or minus five percent. That's probably very
optimistic when you take a look at the data and not
even knowing how quickly the rod was ejected and some
variations on the speed.
I make the point that the experimental
description itself is not of a fidelity that allows it
to be terribly useful. Plus or minus five percent is
probably a pretty low number. One of the reasons we
over-predict the peak in TRAC is because our control
rod worth is $1.23 instead of $1.16 or .17 as you show
there. We get a higher peak and a narrower pulse.
And that thing depends on a lot of conditions all
specific to the lattice physics, all of which have
been modified in order to accommodate this particular
problem. I question its validity for application to
AOO events and, in fact, I question its validity for
purpose of quantifying rod drop backs events, but it's
all we have.
MR. ULSES: Well, I don't think I question
the validity for RIAs myself personally but I don't
really want to get into that discussion right now.
This experimental uncertainty is out of the
documentation from the experimenters. I'm not in a
position to question that, whether or not it's
accurate or not at this point. As for control rod
speeds, when I took a look at the documentation, I was
able to derive a number that I used for this
particular case. This was not an easy experiment to
model. This represents a couple of months worth of
work.
CHAIRMAN KRESS: The actual rod worth
doesn't depend on speed, does it?
MR. ULSES: No. The actual instantaneous
value will but the actual final value will not. It's
a static analysis.
The point I wanted to make here is that I
believe that this particular reactor can be
successfully modeled with these methods and at this
point, if I was reviewing TRACG for RIA calculations,
I would not have been satisfied with those results.
But in the context of an AOO review, I believe that
it's not applicable for this particular point but I
wanted to be sure and emphasize the fact that it would
need to be looked at in further detail if the
application for RIAs was ever proposed. That's the
bottom line. That's the bottom line conclusion and
that's the point of having it in the SER because it
was in the documentation that was given to us by GNF.
CHAIRMAN KRESS: Does this put into
question stability analysis at all?
MR. ULSES: No, I don't think. I think
what you're seeing here is I think you're seeing an
issue of the rod speed that was used in the analysis
myself personally. That's the place that I would look
first if I was --
CHAIRMAN KRESS: It would affect the
whole--
MR. ULSES: If I was GNF trying to
evaluate this, I would look at the assumed rod speed
myself.
MEMBER SCHROCK: Because you haven't show
us how different your result was from the experiment.
MR. ULSES: Well, these are my results
here. This is experimental data. The Xs are
experimental data and the red is the Nestle prediction
for this particular experiment. What I haven't shown
you are the GNF results which are proprietary and I
can't put up here right now.
CHAIRMAN KRESS: But you know the peak is
higher and the tail is lower.
MR. ULSES: Tail is lower so the energy is
in reasonable agreement with the experiment. The only
point of putting this particular curve up here is to
emphasize the point that the staff believes that it is
possible to model this reactor. That's the only point
of putting this up here.
CHAIRMAN KRESS: With the same kind of
neutronics actually that's's in the GNF code.
MR. ULSES: Well, I'd say generally
speaking that's true. This method here is a little
newer than the GNF methodology but generally speaking,
they're similar.
CHAIRMAN KRESS: Yes, but my conclusion
may be different than everybody's. I'm looking at
Nestle and I'm saying this has got basically the same
kind of neutronics as GNF. Therefore, GNF ought to be
usable for these kind of transients. There's just
something wrong with the way they model it.
MR. ULSES: Exactly. That's basically my
conclusion. That's what I would have concluded had I
had the need to get into it in further detail. That's
the only point of putting this curve up here is just
simply to emphasize that point.
MEMBER SCHROCK: You talked about the
uncertainty in the rod worth. HaVe you done the
calculation for the limits on how much effect would
Nestle tell you it has?
MR. ULSES: No, I have not but it would be
very large. This reactor is very small and very
sensitive to rod worth. Extremely sensitive to rod
worth.
CHAIRMAN KRESS: Well, your Nestle
predicted $1.16 rod worth.
MR. ULSES: Right.
CHAIRMAN KRESS: So you did calculate it.
MR. ULSES: Well, I calculated the value
but I didn't assess what would be the effect if I
actually increased it by five percent.
CHAIRMAN KRESS: You didn't do a
sensitivity analysis.
MR. ULSES: Right. I didn't do a
sensitivity analysis because that was not the point of
this study. This was simply to see whether or not the
code could model the reactor. Again, this was out of
the context of the RETRAN review where they were
trying to do RIA analysis. That was the point of that
review.
CHAIRMAN KRESS: I would have guessed
about a five percent effect on the --
MR. ULSES: I don't know whether it would
be linear or not but it would definitely be there. It
should be there and it would be fairly significant.
Anyhow, I'd like to not dwell on this because this is
just simply to emphasize a point.
CHAIRMAN KRESS: But the message I get out
of that is that this kind of code can calculate SPERT.
MR. ULSES: And that was the point.
CHAIRMAN KRESS: And the GE code ought to
be able to do it, too. They just did something wrong
with the analysis somewhere.
MR. ULSES: And again, we're just simply
trying to emphasize the point for future if it's ever
looked at again.
This is almost some philosophy as much as
anything else. Obviously, difficulties in this case
led to a success, I would say, in that we actually
were able to get into the MCMP modeling which is
something that I wouldn't have looked at had I not had
these problems. Obviously, this is almost a personal
pep talk. Work harder at trying to define a problem
where we can eliminate any of these cross-section
issues at all. That was not something I was
successful at in this case, and that's what led to a
lot of these issues. I was trying to find a problem
where I can give the applicant cross sections. So
that is not a question at all. So all we're doing is
looking at the results of the diffusion theory solver
with absolutely no effect on the input stream which
was an effect here that was very difficult to try and
resolve.
And I think it would be very important for
the staff when we're trying to review these codes --
like, for example, TRACG -- to have access to the up-
stream codes which are used to generate input. That
would allow the staff to do further sensitivity
studies and to try and answer some of these questions
about the input stream as well as it would also help
us to eliminate input stream issues which is really
the bigger reasons.
And obviously the bottom line conclusion
is think before I jump to conclusions and write out
these RIAs which end up being incorrect. So that's
the bottom line philosophy. And that's really all I
had to say today. If there's any other questions, I
certainly can entertain them now or we can talk later.
But that's the bottom line conclusion of the staff
review of TRACG kinetics. And I believe now we're
going to hear from Yuri to discuss statistics.
CHAIRMAN KRESS: That ought to be
interesting. Thank you, Tony. Appreciate it.
MR. ULSES: I didn't know your water over
or hit my head on your television screen.
DOCTOR LANDRY: Doctor Kress, while Yuri
is getting set, I think this has again shown us that
this move to insist on the applicant's code being in-
house for our own use has been a good move to make.
CHAIRMAN KRESS: Yes, I agree with you.
DOCTOR LANDRY: Much of this would not
have occurred had we not had the code and done this
experimenting with the code. If we had not done this
experimenting with the code, we would not have seen
much of this. Whether you go down the right path or
the wrong path, you're learning something about the
code and the methodology that's being used and we've
been gaining experience through this whole process.
This has in some ways been a little painful. Tony
said mea culpa. But it's been good in that we have
learned a great deal in the process. I think that,
all things considered, it has enabled us to perform a
better review than simply looking at documentation.
CHAIRMAN KRESS: I think that's a good
perspective. I'm glad to hear you say that. We'll
continue to support that type of review.
Yuri, I don't think we've met you before.
DOCTOR ORECHWA: No. I'm a new kid on the
block. My name is Yuri Orechwa. I'm from NRR in the
Reactor Systems Branch and the staff.
What I want to review is the uncertainty
evaluation that was presented to us for evaluation
with TRACG analysis of anticipated operational
occurrences. What I'm going to focus on is the
methodology. I can't repeat all their calculations.
So the question is if they did the arithmetic
according to the rules which they presented, then we
can judge the results accordingly.
So what we're going to look at, the review
topics that were requested, was to look at the model
uncertainties and biases. TRACG is a deterministic
code. So what we're saying is the models are
imperfect. Those imperfections, we need to express
them somehow in the results. Once that's established,
how do we combine that in order to make statements
concerning design limits and operating limits?
Let me give a heuristic overview so that
you see where I come from, where I'm going, and some
of the notation that I'm using. I have to apologize.
I'm of the old school. I still write things down. I
have a tough time with the modern software which is so
helpful that it takes you an hour to find one symbol
that you need.
CHAIRMAN KRESS: To tell you the truth, I
prefer this. I'm used to seeing them like that.
DOCTOR ORECHWA: All right. Let me say
then what's TRACG in the context of what we're going
to do. We can write down in operator notation the
neutronics model and the thermal-hydraulic model.
Those are coupled through the thermal-hydraulic
conditions and the power of that. Both operators are
dependent on parameters. Those parameters, like in
the neutronic model, the reactivity coefficients of
course are important. In the thermal-hydraulic model
it would be from correlations and things like that.
In my notion, the theta and phi set are the things
that are the beginning and are at issue at the
starting point.
TRACG is deterministic. You put in your
input, you specify theta and phi. You will get a
number when you do your computation. If you put the
same input, the same phi and the same theta, you're
going to get the same number. Whether that number is
right or wrong, Tony discussed. We're assuming that
that's done. Now the question is what are the theta
and phi going to do? We have also initial conditions
where there are also some parameters usually and stuff
like that.
So at issue is the determination of the
distribution of those parameters. In order to do
anything statistically, you've got to have sample from
somewhere and you have to characterize that sample.
To determine the model uncertainties, we need to
always estimate some distribution and the parameters
for that distribution. That represents then, it
summarizes the state of knowledge. And GE has
presented in my view, an enormous amount of data from
tests, from qualifications and all that.
Now, suppose we get our distribution of
those parameters of theta and phi. Then we know that
the solution, the TRAC solution -- that is the
parameters that are the output of the TRAC -- will be
dependent on the theta and phi. Because those come
from the distribution, will give us a distribution of
TRAC solutions. So in the TRAC solution which I kind
of write like a vector. It's not really a vector in
the mathematical sense but the set parameters. Each
parameter will be distributed. Given that
distribution, you can them make some kind of
determination of the confidence you can put into a
design limit. So that's the issue. How do I get then
to the design limit?
MEMBER SCHROCK: Yuri, could I ask, how
does the selection of the node size enter into what
you're describing, or does it, for a specific --
DOCTOR ORECHWA: Because it was
considered, but I don't think it's big. I don't
consider it here. It's not a statistical issue.
CHAIRMAN KRESS: It seems like the only
way you could incorporate it is to change it and see
what effect it has on the distribution you get out.
DOCTOR ORECHWA: That's a question of
algorithm. It's not a statistical issue.
DOCTOR ANDERSEN: This is Jens Andersen.
We did do a fair amount of nodalization sensitivity
studies that are documented in the qualification
reports. We did it both for simple tests as well as
for full scale plant cases. What we did was that we
basically looked at the simpler test to determine what
was an adequate nodalization. We then ran a plant
case and we did nodalization studies around what was
considered an adequate nodalization and we basically
quantified how large the sensitivity were on the
critical safety parameters, and we were able to show
-- and this is actually documented in the
qualification report -- that with the nodalization we
had chosen, doing further refinement to the
nodalization had very little impact on the calculated
results.
DOCTOR ORECHWA: Nodalization is a
convergence issue. It's not a statistical issue.
MEMBER SCHROCK: Well, I'll have to think
about that a little more. I think the distributions
are influenced by the nodalization.
DOCTOR ORECHWA: The distribution of the
basic parameters has nothing to do. Once you do a
solution to the TRAC equation, it will be.
Nodalization will enter a bias, you might say, but
that should come out given some parameter. If I pick
a theta and a phi, then I can compare a TRAC for
different nodalizations and see if I'm going to a
solution. I converge to this level. Now this level
will vary because I choose different parameters for my
models. So it's a convergence issue.
CHAIRMAN KRESS: There may be a question
about when you use nodalization to determine the input
as to whether or not that might affect the
distribution.
DOCTOR ORECHWA: I think, at least in my
experience, any code that's been nodalized is in a
fine mess. Once you get it, somewhere there has to be
in the manual documented what the effect of
nodalization is. That's a verification and validation
issue. The models that enter for the specific
versions is a different issue. Just say with respect
to thermal-hydraulics.
CHAIRMAN KRESS: So so far you're saying
that there are specific inputs to the code that have
to have a distribution.
DOCTOR ORECHWA: That's right.
CHAIRMAN KRESS: And that distribution has
to be determined.
DOCTOR ORECHWA: That has to be
determined.
CHAIRMAN KRESS: And it's generally
determined as much as possible by data and GE has a
lot of data.
DOCTOR ORECHWA: Right. I will go through
each of these points again.
CHAIRMAN KRESS: And the input has to be
propagated through the system to get these outcome
design limits.
DOCTOR ORECHWA: That's what I want to
step through afterwards.
CHAIRMAN KRESS: Okay.
DOCTOR ORECHWA: I was just going to say
with regard to nodalization and convergence, one of
the millennial problems in mathematics is the
uniqueness of the Navier-Stokes equation. So we don't
even know if the solution exists.
MEMBER SCHROCK: We don't solve Navier-
Stokes equations here so that's not a problem.
CHAIRMAN KRESS: We bypass that.
DOCTOR ORECHWA: We can all run out and
solve the how the existence and come home with a quick
million dollars. But those are the issues.
Okay. Now, suppose we have the
distribution of the TRAC output. Then the third basic
figure of merit which is used by GE is based on
critical power ratio. And that's defined as the GEXL
correlation as a function of what the thermal-
hydraulic conditions are that TRACG gives over the
power given by TRACG.
Because our TRACG solution has a
distribution, the critical power ratio will have a
distribution and there again then we can talk about
what is the confidence level with which we pick some
limit or operating limit?
CHAIRMAN KRESS: Is there a distribution
on the GEXL part of that?
DOCTOR ORECHWA: No, because the input --
this is the thing that has a distribution. It has its
own uncertainties.
CHAIRMAN KRESS: I know. There are
parameters in it.
DOCTOR ORECHWA: Right, but that's a
separate issue.
CHAIRMAN KRESS: That's a separate issue.
DOCTOR ORECHWA: I don't want to touch
that one. But the point is that we start with
parameters in the TRACG. Varying those, we get a
distribution of the output, the thermal-hydraulic
conditions and the power distribution. Putting that
into this correlation, we can get a distribution of
the CPR and we can then make statistical statements
about it. So that's the basic name of the game.
So the first thing is model uncertainties.
That's in my notation theta and beta. GE follows the
CSAU methodology for that and begins with what I would
call the delphi method. People see what phenomena are
important in the TRACG calculation, the relative
importance, and identifies those. Those are then the
phenomena that are associated with parameters that
will have the highest impact on the solution and,
therefore, we need to go out and get them.
The next step then is, having identified
what phenomenon there are and what parameters are
associated with those, you establish the nominal
values and uncertainties for these parameters. There
is an enormous amount of data that is presented from
separate effects test facility data, integral test
facility data, components qualifications, BWR plant
data, and these are all analyzed and the statistical
analysis for each is presented in the report.
For some parameters for which there is no
data, code comparisons are made. In particular, for
the void coefficient, for example, which Tony
discussed, code comparisons need to be made. And also
everywhere there always lurks engineering judgment, no
matter what you do.
Now, let me just comment with regard to
the void coefficient, the analysis there. Overall,
the evaluation of the experimental plant, etcetera,
data is done by standard techniques. Look at the
distribution. You assess whether it's normal. They
use a test which I had never heard of before, the
Anderson-Darling test, but that's neither here nor
there. And goes through, presents the data, shows
everything in regular fashion so it can be assessed.
And it looks proper.
In the void coefficient analysis, the main
variation comes with the variation across assemblies
or fuel types, whatever they call it. There is an
enormous number of them in the GE stable. There's 11,
Charlie, or nine? Eleven. Eleven are chosen as
representative of variation. These aren't chosen by
random. These are chosen to be representative because
there are so many. If you get down to the nitty-
gritty, you should have chosen them by random but that
would have been an extremely small sample. Probably
would have had a big bias. So the natural tendency is
we would like to choose something which is
representative. I don't have a problem with that, but
it is not according to the rules of sampling
statistics, and I don't think -- with small samples,
you will always have a problem of bias and I think by
trying to be representative you're probably moving in
the right direction. I just want to comment on that
issue. So the spirit is there.
CHAIRMAN KRESS: When an application comes
in to use this, the variation in fuel types across the
core won't be random.
DOCTOR ORECHWA: There are a lot of
different fuel types in the core.
CHAIRMAN KRESS: Yes, but they'll know
what they are.
DOCTOR ORECHWA: Oh yes, but you're
putting in one number to say the uncertainty is. The
uncertainty is not being associated with each lattice,
type of lattice. Okay. It's across lattices.
MEMBER FORD: Would you mind going back to
your previous slide, please. Maybe I missed the
discussion of the very first bullet. Have an impact
on what?
CHAIRMAN KRESS: On the important outputs.
DOCTOR ORECHWA: Looking at anticipated
operational occurrences, these are measured with
what's happening to the power pressure and things like
that in a transient. What will affect those the most?
You have a huge equation. Some parameters will be
more important than others.
MEMBER FORD: So if I was worried about a
materials problem -- just for instance -- for
instance, what is a fast neutron flux of the core
shroud? Outside this --
DOCTOR ORECHWA: No, it's not a transient
issue of materials.
MEMBER FORD: I'm still learning here.
DOCTOR ORECHWA: Okay. Then, of course,
as I said, for all of these different phenomena that
have been rated, the normality of the distribution is
assessed, which is nice, and then there's an estimate
made.
Do you have a question?
CHAIRMAN KRESS: Yes, on the "evaluate the
normality." That's based on the assumption that the
distribution will be normal and you'll want to check
to see if your assumption is correct.
DOCTOR ORECHWA: Yes, there are
statistical tests.
CHAIRMAN KRESS: Yes, I understand the
test.
DOCTOR ORECHWA: You look at the data and
it gives you a statistic for various --
CHAIRMAN KRESS: And suppose that
statistic makes you question your assumption of
normality. What do you do then?
DOCTOR ORECHWA: Statistic tells you at
what confidence you can say and those chose at the 95
confidence level that it is normal. You never have
100 percent.
CHAIRMAN KRESS: But suppose I only had 70
percent confidence in my normality. What do I do
then?
DOCTOR ORECHWA: Okay. You can approach
it in different ways with non-parametric statistics
and stuff like that. I think this is experimental
data and this is traditionally normal because there
are so many other small things that come in. I think
in what GE has presented invariably it is. In a few
cases, it looks kind of ---
CHAIRMAN KRESS: So it's just kind of a
hypothetical question.
DOCTOR ORECHWA: Later on it becomes a
little bit more of an issue.
Let me just say that although in the
report it's almost parenthetic that they do a
sensitivity analysis, but I think it's very important
in the long run that the sensitivity of CPR in the
turbine trip event with respect to each parameter as
to what the sensitivity to that is and it's diligently
done for each case.
CHAIRMAN KRESS: You'll already have a
distribution.
DOCTOR ORECHWA: Yes.
CHAIRMAN KRESS: But you don't know what
particularly caused that distribution or what the most
important parameters are so you go back and do a
sensitivity study to find out which of those
parameters had the biggest effects.
DOCTOR ORECHWA: How big the effect is if
I vary that one parameter only.
CHAIRMAN KRESS: That one only. It gives
you just additional information.
DOCTOR ORECHWA: It gives you very
important information later on, at least the argument
that I will make. So that's important.
Design limits. The parameters are
combined by random sampling from each of the
parameters. Now, GE just does straight random
sampling. There are methods where you can kind of
tighten up by using choice of sampling.
CHAIRMAN KRESS: Latin Hypercube test.
DOCTOR ORECHWA: Latin Hypercube is the
one in KSU and things like that. Let me jump ahead a
little bit. I think for this application it's
probably okay because things are kind of -- the
transients are slow and things like that.
CHAIRMAN KRESS: The only issue that
generally comes up with strict random sampling is how
many do you need to get the right --
DOCTOR ORECHWA: How many. For small
samples, it's an issue because you introduce bias
right away in a small sample. So it's just something
that needs to be noted but if you have rapidly
changing functions as you would have in a severe
transient, you might want to pay a little bit more
attention as to your sample size and its behavior in
that case, I think. But it's something that has no
definite yes or no answer again, as usual. So I want
to bring that up.
So you sample from these parameters, you
stick them in TRAC, you compute values. We get those
values and then we do our usual normal theory. Put
them in the frequency table and we again check
normality. If it's normal, we can then make a
statement concerning at 95 percent level various
design parameters, temperature, pressure, etcetera,
whatever you want to do, and you can set those.
Note greater than or equal to 59. Why is
that? As you said, suppose it's not normal. Then
what do you do? I still want to talk about setting a
limit with this level of confidence. And GE does the
usual thing. You look at order statistics. What you
do is you sequentially by size put your sample down,
59 out, and then the 95th limit is the 95th one. So
if I random sample all those, it comes from the theory
that 59 is -- it's not 60, it's 59.
Now note though. This isn't mentioned.
You can't get blood out of a turnip. Because when you
say you have a normal distribution, that's an enormous
amount of information so the non-parametric interval
is going to be usually significantly larger and then
it might be so large as being not very meaningful at
times. So just because you have an interval that's
95, your data may really be somewhere else or
something. Just because you're using order statistics,
that's fine and you can talk about it but you still
have to be careful as to exactly what you're doing
underneath that. This is just a comment on that.
CHAIRMAN KRESS: The bottom line is for
realistic code applications the rule calls for a 95/95
-- figures of merit?
DOCTOR ORECHWA: Yes, that's what people
usually talk. And for that you need 59 samples.
CHAIRMAN KRESS: You need 59 samples and
you reached it then.
DOCTOR ORECHWA: Yes. And even for normal
that's my experience is it's getting to be. Okay. So
using that, you can get your design limits. But what
we want in order to assess the transient is what GE
does is talks about the operating minimum critical
power ratio. It has two components. The safety limit
critical power ratio, which is the value of CPR which
is less than .1 percent of the rods and the core
expected to experience. That's just a definition.
In the transient, delta CPR is the
contribution from the transient itself and then the
equation says that steady state CPR basically equals
-- you have the absolute limit plus the contribution
from the transient. So that's the relationship on
which we base.
The key element in the computation is the
computation of the probability of rod experience in
transition or boiling. There are two things that GE
focuses on. The two ingredients, I should say, that
are in the computation that they use. Experimental
data from the Atlas facility which gives you a
distribution of experimental CPR. This is defined
this way and because it is experimental data, it will
give you a distribution.
Now, then you have a computed by TRACG for
a specific reactor. Minimum critical power ratio. I
have an intellectual disagreement with GE on their
computation of the probability. Let me first, because
this dates back, I think, 30 years. Let me just point
this out. The probability is the integral over a
distribution function of CPR. What is done is the
computation, if this is your experimental data, this
value that they put on to compute the probability,
this is determined by TRACG. You're mixing two
distributions. The TRACG value is in your limit and
you're integrating over an experimental value. So you
can do this only if this is true that the two
distributions are the same.
Let me give an analogy that's extreme.
Let's take the price of bananas, 1.25 per pound or
something. I can put it on here and calculate a
number, a probability. You say you're crazy, price of
bananas has nothing to do with CPR, which is true, and
to a more limited extent, the computation of TRACG and
the experiment, there is a difference. This is the
heart of the matter that we're getting at and you
can't just slough over this intellectually.
CHAIRMAN KRESS: Experimentally. Can you
extract a CPR out of that?
DOCTOR ORECHWA: Let me go on.
CHAIRMAN KRESS: Okay.
DOCTOR ORECHWA: Fundamentally, this is
strictly verboten to mix.
CHAIRMAN KRESS: I can see that.
DOCTOR ORECHWA: You can do it in the
context of Bayesian statistics but then you're going
to have to find a loss function in order to get your
point estimate of the probability. That would be the
correct way to go, blah-blah-blah. But you still have
to then-- you can mix the distributions and then say
I have --
CHAIRMAN KRESS: The problem I have is
experiments don't actually measure the critical power
ratio. You have to derive it somehow.
DOCTOR ORECHWA: Excuse me.
CHAIRMAN KRESS: I'm trying to figure out
how you would overcome your objection.
DOCTOR ORECHWA: Let me go on. I will
overcome my objection.
CHAIRMAN KRESS: I'll let you go on.
DOCTOR ORECHWA: Let me say we apply
statistics and there are certain assumptions for all
these things. We will never meet the assumptions
exactly. So you got to have a little bit of judgment.
So given that in principle, what we're doing is
strictly verboten. GE doesn't do this but let me try
to argue the following. This will be my argument and
you can give me a grade on it. With classical
statistics you come through the back door and you
bring engineering judgment.
Point one is if we take the experimental
value and we just expand it -- I mean we live by that.
Here is all the sensitivity. Now they've computed all
the sensitivities. I can use just chain rule and get
all the sensitivities through there. The
sensitivities are all very, very small if you look at
them down the line. The qualification examples that
they give and I think what Tony showed, that this is
pretty good. So the correction that differentiates
these from what we know of the real world and TRACG
and all that is probably okay.
My other argument would be we're talking
about .1 percent probability and less. So we're way
out in the tail end of the distribution. The
contribution to the probability of a difference in the
CPRs out there will be almost negligible. So either
one or both will, I think, support that what they are
doing is, I think, within our engineering judgment.
MEMBER SCHROCK: The experimental CPR from
Atlas is for one bundle.
DOCTOR ORECHWA: Is it for one? I thought
it was for many bundles.
MEMBER SCHROCK: A small number, in any
case.
DOCTOR ORECHWA: There are thousands, I
thought.
DOCTOR ANDERSEN: This is Jens Andersen
from GNF. We have measured the critical power for
each single fuel design that we have developed in the
Atlas test facility, 7 X 7, 8 X 8, 9 X 9, 10 X 10
fuel. For each fuel design, we run a large number of
tests, typically anywhere from 500 to 1,000 tests in
order to characterize the critical power as it depends
-- pressure inlets, up-cooling. So we have typically
a database of 500 to 1,000 data points in order to
determine the experimental uncertainty or the
uncertainty in the jet fuel correlation in predicting
the critical power. That's an ECPR distribution.
MEMBER SCHROCK: So you've put together
many tests to build up a core characterization of CPR.
Is that the picture?
DOCTOR ORECHWA: Yes. Right.
MEMBER SCHROCK: The reason I ask the
question is that you're defining minimum critical
power in terms of one-tenth of one percent of rods in
core. I didn't think that you had that kind of
capability in the experimental determination, but I
see that you do.
DOCTOR ORECHWA: There's a tree you're
barking up on that I'd like to address that should
really be looked at. And I think it's mentioned in
CSAU methodology, which is when you have a lot of
parameters, which you do in this case, in order to
really represent the response surface for that, you
quickly need a lot of data because it goes by the
number of values on each axis to the power of the
dimension that you run out of data very quickly in
order to give a characterization and, here again, I
think what saves this case, at least my view of
looking at the data, is the transients are mild,
response is smooth.
Once you get into something else where you
may be getting into instabilities or something like
that, you're not going to have smooth functions, and
I think there you're going to have to very carefully
look at that issue. So this case, yes. Another case,
it's not going to be so smooth.
Any other questions? What grade do I get?
CHAIRMAN KRESS: On your proposed fixed,
you get an A.
DOCTOR ORECHWA: Thank you.
CHAIRMAN KRESS: That's a good fix.
Expect I really don't think you need a fix.
DOCTOR ORECHWA: All right. Since I got
an A, we can now determine the operating limit
critical power ratio. Let me just make a comment
here, one comment concerning the submittal. This is
probably one of the most critical parts and it gets
one page in the write-up and it's pretty
undecipherable. Things should be written up a little
bit better, I think, for us even to review. So I made
my best stab at it.
I think the spirit of the thing is that we
can't track any of these large codes which take a half
a year to set up. You're not going to run random
sampling on them. It will take an enormous amount of
runs. You'll be there forever. So how do you divide
and conquer? How do you compartmentalize some of the
calculations to maximize your information so you can
make a statement with a little bit less effort by
emphasizing certain things?
GE's approach, the way I read it, is that
you first look at the generic behavior of transients
for classes. You have a transient class, you have this
type of BWR, you have this type of fuel, etcetera, and
you can develop a distribution of the CPR for that.
So the ingredients are first by class a distribution.
The other one then is for a specific case you run a
specific transient all the way through. Then you can
also for the specific case just in steady state, your
initial condition because it's not a transient, it's
an easier calculation, you can do sampling on that and
run them through.
You can then combine them via this
equation by sampling the two distributions that you
have and you get a distribution of MCPRs for which you
can then compute the value which is the criteria for
setting your operating limit minimum critical power
ratio. To my mind, that looks legitimate. I think it
accomplishes the purpose. You do capture the
uncertainties present both in transient, both in the
initial state and you kind of bridge them with a
calculation which is specific to the case under
consideration. I don't think that that's an
unreasonable approach.
Now, I think now having gone through the
methodology and it looks okay, GE does present a lot
of qualifying data where they look at actual
transients, the uncertainty band which is generated
using this methodology and I believe that there is
sufficient agreement to be able to use it for analysis
of AAOs given the background of all the back when we
started with the uncertainties that today we associate
with the input parameters to the TRAC calculation.
CHAIRMAN KRESS: So your bottom line is
that uncertainty methodology is pretty good with the
possible exception of the philosophical difference
which probably doesn't make much difference.
DOCTOR ORECHWA: Yes. I wanted to bring
that up because it can make a difference in some
situations.
CHAIRMAN KRESS: Could later.
DOCTOR ORECHWA: I think in that case it
has to be -- because for 30 years that calculation has
been done as if those two distributions are identical.
And I just want to put a flag out there not in
principle because if they're not in principle, then
you have to make an argument for why you think you can
get away with it and I passed the argument by you guys
why I think they can get away with it.
CHAIRMAN KRESS: Are there any other
questions? You're getting hungry? Well, thank you
very much for a tutorial on how to do uncertainties,
Staff us not through yet.
MR. BOEHNERT: It should be short.
CHAIRMAN KRESS: Why don't we go ahead and
hear it then and that won't give such a gap in
between. Sorry, I thought that was it.
DOCTOR LANDRY: I'd like to cover just a
couple more items before we break and go on after
lunch to the applicant's presentation. You've heard
a great deal of the experience that Tony has had
running the code and some of the work that he has
done. We've also been running the code on plant decks
and to look at the overall experience of a user in
applying the code to an analysis of an AOO transient.
That experience has shown us that TRACG
uses input decks that are very closely related to the
decks that are from the original TRACB code which
really means that if you have a knowledgeable TRAC
user, that person can come in and pick up work with
TRACG with a minimal level of additional education or
retraining.
Major changes from TRACB to TRACG are
well-described in the model description report
appendix. We're pleased with that. We did note that
the execution structure of control blocks though has
been retained from the TRACB. In other words, the
control box must be executed in numerical order and if
you want to go back and use the same control block,
you have to put it in again. There's no ability to
select control blocks according to the use within the
input stream. You have to continue in a numerical
sequence.
We did feel that additional guidance could
be provided to the user on time step size. The time
step size selection. But on the other side of that
issue, the applicant has developed a set of standard
input decks for all of their plants which takes the
user effect out very much, that the user doesn't have
too much option and doesn't have too much effect on
the calculation with TRACG.
We also noticed that TRACG determines the
correct flow regimes during the steady state
initializations, unlike some other codes where the
user can select flow regimes randomly or for different
stages, different components. The user doesn't have
that option with TRACG so we're pleased that this
removes the user effect from the code.
CHAIRMAN KRESS: Is the time step checked
internally in the code to see that it meets stability
criteria?
DOCTOR LANDRY: There are time step checks
but we thought that in looking at the material it
would be useful if the user had a better definition of
proper selection of time step.
CHAIRMAN KRESS: I was trying to figure
out what you thought was needed as additional guidance
there.
DOCTOR LANDRY: There are checks and
balances there but we thought that the user would
benefit by having it better defined. But then again,
as has been said a couple of times already, the code
is used internally within the General Electric
corporation where they have the ability to educate the
user beyond what the documentation would say. They
have an ability that if the documentation is not
adequate for the general public, they can cover for
that by making it part of their training program.
MEMBER SIEBER: Is that institutionalized?
DOCTOR LANDRY: Yes. They have a training
program within the corporation.
MEMBER SIEBER: It has a QA program
attached to that so that you can carry on?
DOCTOR LANDRY: Right. That all comes
under the QA program also. The use of the code, the
ability of the user, all gets checked and balanced
through the QA program.
MEMBER SCHROCK: Does this imply the
utility user is less skillful?
DOCTOR LANDRY: Well, the utility doesn't
use the code.
MEMBER SCHROCK: Not at all?
DOCTOR LANDRY: Unless General Electric is
licensing the code to their utilities, all the
calculations are done by General Electric.
MEMBER SCHROCK: Okay. I didn't
understand that.
DOCTOR LANDRY: Some of the conditions and
limitations that we identified in the SER. We have
already discussed the GEXL 14 correlation and the
issues surrounding GEXL 14. Again, to emphasize that
once resolution of those issues is arrived at, that we
expect that to be applied within the use of TRACG.
We've also pointed out in the
presentations already this morning and in the SER that
TRACG, if it is to be applied to stability analysis,
will have to be submitted for staff review for that
application. We are not approving the code for a
stability analysis. They haven't asked for that
either. It has not been reviewed for Atlas. They
have not asked for that, but we want to call out.
Since Atlas is considered a transient, we want to
identify that if it is applied to Atlas, we want to
re-review it.
The discussion that Tony presented, the
PIRT 18 model needs further justification before
application to reactivity insertion or control rod
ejection accidents. Tony raised that question. How
can Monte Carlo model reliably predict point kinetic
answers? Of course, the code is not being applied for
that at this point anyway, but if it should be, these
are issues that are going to have to be addressed.
We also identified in the review that for
isolation condensers further justification or review
may be necessary.
MR. BOEHNERT: What's the deal there,
Ralph? What's the problem?
DOCTOR LANDRY: This was identified back
when the in-depth thermal-hydraulic review was
performed. There was a feeling that the modeling of
isolation condensers was not adequate and needed
further review. So again, we did not see where that
had changed and we felt that we needed to point out to
future reviewers, as has been said a couple of times
this morning, this is a flag to reviewers of
applications of the code that if it is applied to a
plant with an isolation condenser, they need to look
carefully at this condenser to see if it is critical
to the transient progression. Then they need to look
at it more carefully. If it's irrelevant or low
meaning for the transient, we're not so concerned.
MEMBER SCHROCK: You had another proviso
in the SER which says that if the level tracking model
is invoked where there is significant void, it will
have to be re-evaluated.
DOCTOR LANDRY: Right. That's an
identification to the staff also when this code is
submitted for LOCA, which we anticipate in the not too
distant future, that we want to look at that level
tracking model. There is not significant voiding for
the transients for which it is being applied, but when
they get into LOCA space, then we want to look
carefully and we want the staff involved to look
carefully at the level tracking model.
MEMBER FORD: On the staff evaluation and
conditions limitations, there's a whole series of
questions arising out of the earlier subcommittee
meeting here. Are these conditions/limitations you
have there, would they be changed if you took into
account these questions?
DOCTOR LANDRY: We could put in more but
we have looked at and discussed with the applicant
those concerns that were brought out and identified on
the agenda and this afternoon General Electric is
going to present information dealing with those
specifically. We have been discussing with General
Electric what they're going to present and we do not
have problems. We are not in conflict with them at
this point.
MEMBER FORD: So these are merely points
of detail which get washed out.
DOCTOR LANDRY: Well, they're points of
detail that may not affect the application to AOO
transients, but they are some points which we will be
looking at carefully when we see the code for LOCA
analysis. Some of those are not important for AOOs
and will be important for LOCA.
MEMBER FORD: But that will be discussed
this afternoon.
DOCTOR LANDRY: Yes.
MEMBER FORD: The justification for that
statement will be discussed this afternoon.
DOCTOR LANDRY: General Electric is going
to present information on those this afternoon.
Staff conclusions. Again, GEXL 14 will be
acceptable when it is handled in accordance with
agreement with the staff. The kinetic solver is
adequate to support the conclusion that the models are
correctly derived and account for phenomena involved
in AOO transients. Kinetic solver benchmarking
demonstrates that TRACG adequately predicts results
for AOO transients. Staff analyses provide confidence
that TRACG is acceptable for AOO transients.
Uncertainty analysis follows accepted CSAU
analysis methodology. Uncertainties and biases have
been identified and all highly ranked phenomena based
on experimental data have been validated. The process
is acceptable and the quantities are reasonable.
MEMBER FORD: I guess my frustration with
all these conclusions. If you are reading those
conclusions from a paper, certainly there's been no
support from any of those conclusions given today.
DOCTOR LANDRY: No support?
MEMBER FORD: Well, the last one, the
process is acceptable and the quantities are
reasonable. We haven't seen any detailed
documentation to support those conclusions. I'm
assuming that the back-up for those conclusions are
given in other documents.
DOCTOR LANDRY: In the documentation on the
code, but that's what Yuri was going through, that
yes, the process that they went through in their
analysis, he had some philosophical differences, but
for the application the conclusion was it's
acceptable.
MEMBER FORD: I guess I'm learning about
this process as to what we're signing up to approve.
That's where I'm -- if I was a reviewer of a paper or
of a report, I wouldn't sign off on it based on what
has been presented today.
CHAIRMAN KRESS: No, you have to do it in
connection with all of the documentation we've been
supplied which is a lot of stuff to go through.
DOCTOR LANDRY: We don't reiterate all of
the submittal. What we're doing is saying what our
findings are based on a review of the submittal
without going through a reiteration of everything that
was submitted to us.
We also have concluded that the standard
input has been developed for the classes of BWR
systems for which TRACG is to be applied, BWRs 2
through 6, and that the staff finds TRACG 02A code --
again, that's designation of which version this is --
is acceptable for application to the AOO transients
presented in the submittal that's dated in January of
2000.
So those are the conclusions that the
staff has arrived at. Based on our review, we feel
that the code is acceptable for application to the AOO
transients. We've identified areas of concern and
we've identified items that we would call out as flags
for future applications, that if it goes outside the
scope of AOO transients, other things need to be
looked at.
CHAIRMAN KRESS: Thank you. Are there any
other additional comments from either members or from
GE before we break for lunch? I propose we come back
at 1:00 and hear the rest of the story. Recess.
(Whereupon, off the record at 11:55 a.m.
to reconvene at 1:00 p.m.) A-F-T-E-R-N-O-O-N S-E-S-S-I-O-N
(1:00 p.m.)
CHAIRMAN KRESS: Okay. We are now back in
session again and you guys may proceed. Here's the
part where you're going to answer all of our previous
questions. Right?
DOCTOR ANDERSEN: My name is Jens Andersen
and I'm going to give a brief presentation on the TRAC
application for anticipated operational occurrences
for transient analysis. If you'll go to the second
slide, Charlie.
Let me just introduce the people that are
here for General Electric. Over there we have Jim
Kapproth who is the manage of engineering and
technology. This is myself. We have Fran Bolger
who's sitting here who's team leader for the transient
analysis. Charlie Heck is helping me who's the
responsible engineer for TRAC. Brian Moore who's team
leader for technology and development who is our
nuclear expert and we have Antonio Possolo from
corporate research and development who is a
statistician that has helped us out. And then finally
we have Bharat SHiralkar who is the project manager
for the application of TRAC to LOCA which is the
submittal that we are planning.
What I'm going to talk about is the
submittal of TRAC. We submitted fairly extensive
documentation of TRAC to the NRC. We have had a long
review of TRAC. We have had numerous meetings and
communications with the NRC, phone conversations,
emails, meetings. There were a number of requests for
additional information, and GE Has provided responses
to these questions and I'll get into details on that.
We've also had review with the ACRS
Thermal-Hydraulic Subcommittee. We had a meeting on
November 13 last year. I'm going to address some of
the comments that we have received from the ACRS and
I'm also going to comment on some of the issues that
came up at the end of the SBW review. And finally,
I'm going to go into some concluding remarks.
Just to reiterate. The scope of the
application was to apply to operating boiling water
reactor in United States and that would be BWR 2 to
BWR 6. The events that we applied for are the
anticipated operational occurrences, also called
transients, which are basically operational events
that deals with either increase or decrease in reactor
pressure, increase or decrease in core flow, increase
or decrease in reactor coolant inventory and decrease
in core coolant temperature. These are the so-called
Chapter 15 events.
The documentation that has been submitted
for TRAC is that we first had a document that was
called the TRAC licensing application framework for
AOO transient analysis. That was actually submitted
to the NRC in 1999 and that was basically a document
that laid out the entire plan for how we would apply
TRAC to transient events. And then later towards the
end of 1999, we submitted the model description. In
early 2000 in January, we submitted the qualification
document and the application methodology.
In addition, we submitted the TRAC user's
manual and we made the TRACG 02A source code available
to NRC and, together with the source code, we made a
number of sample problems and test cases available.
The scope of the review has been to review
the application of TRAC to transient and the objective
was to get a safety evaluation report for the
application and evaluation of the TRAC's capability
for AOO transients and evaluation of the qualification
we have supplied to support that application and
finally, an evaluation of the application
methodologies which is how we apply TRAC for transient
events.
The time line. As I said, we submitted
the road map, the plan for the whole process in May of
1999. All the LTRs were submitted to the NRC by
February of 2000 and we had a kick-off meeting that
involved a meeting both with the NRC and the ACRS
Thermal-Hydraulic Subcommittee on March 16 of the year
2000. In April of 2000 the NRC issued the acceptance
review which is basically that the documentation that
was provided was sufficient to allow the review to go
on.
We had first a major meeting with NRC on
NRC review concerns in September of the year 2000.
The ACRS Thermal-Hydraulic Subcommittee was in
November of 2000. And then we had numerous other
communications. During this period, we have received
23 requests for additional information and we have
provided responses to all these requests and all
issues have been resolved. The draft safety
evaluation report, we received that in July 2001 and
we're having this meeting today on August 27, 2001
and, of course, what we are hoping to get out of it is
closure by September and get the safety evaluation
report by September.
As I said, we had submitted extensive
documentation on TRAC and the previous slide listed
the number of documents we have submitted. We have
relied on prior NRC reviews and acceptance of TRACG
application. There has been numerous application of
TRAC where it has been applied for LOCA, transient,
ATWS and stability applications that have been
accepted by the NRC and the thermal-hydraulic model of
TRAC was substantially reviewed during the SBWR
project. That project was canceled in 1996 and that
review was then subsequently stopped. However, NRC
issued a letter documenting the status of the review
when the SBWR program was stopped.
Anyway, we have had numerous interactions
with the NRC. We have supported the TRAC
installations of the NRC computers and the
benchmarking against the NRC codes. We've had the
review with the ACRS Thermal-Hydraulics Subcommittee
in November. We received a total of 23 requests for
additional information including an RIA that was
generated from ACRS comments. Most of these RIAs
dealt with providing additional information and
clarification of issues and we have provided all of
these responses and I would like to make the comment
that I feel that we have had a very good interaction
with the NRC reviewers. We have had a very
professional and open candid communication with the
NRC and I personally have been very pleased with how
this review has progressed.
Now is probably the time where we are
getting into some of the proprietary material.
MR. BOEHNERT: So we close the meeting.
We'll go to a closed meeting transcript.
(Whereupon, at 1:10 p.m., the proceedings
went into Closed Session.)
CHAIRMAN KRESS: Does the staff wish to
make any additional comments at this time? I'll tell
you what. Let me go around the table here and see if
we have comments from the consultants or the members,
and then you might want to respond to some of those.
I guess I'll start with you, Virgil. You have any
comments in the way of wrap-up comments you'd like to
make now or would you prefer to wait until you digest
it?
MEMBER SCHROCK: I think I'm going to have
to write the comments. I just don't see any way I can
summarize them all now. In some respects, the report
that I submitted in November has been addressed. In
some respects, it's not.
CHAIRMAN KRESS: Yes. I think that was
what I was looking for.
MEMBER SCHROCK: I could try to sort those
out for you.
CHAIRMAN KRESS: I think it's a little
premature. Why don't you think about it and do it in
your second report. There's no use doing it now.
MEMBER SCHROCK: My comments on the SER at
the beginning of this meeting may have been more
severe than they should have been, but I do think the
SER should be written in clearer language than it is.
I think it needs to be more technically correct than
it is. I think there are still some problems that I'm
going to comment on in my final report.
CHAIRMAN KRESS: That would be helpful.
I guess you're not allowed to comment at
this stage. Do you wish to make any more comments?
MEMBER SIEBER: No, I don't think so.
CHAIRMAN KRESS: I don't have any
additional ones, so I think I'll see if the staff has
any additional comments they want to make before we
decide what to do for the full meeting.
DOCTOR LANDRY: I think we've tried to
make it clear that this is a draft SER. There are
areas in which we intend to make some revisions. We
had intended some revisions coming in. There are
areas that we felt could be bolstered and we'll, of
course, take into consideration the comments and views
of the subcommittee in making those revisions to the
draft SER so that our goal is to have a complete
product.
CHAIRMAN KRESS: Okay.
DOCTOR LANDRY: We would appreciate
getting a copy of Professor Schrock's comments.
CHAIRMAN KRESS: We will. That was an
omission and that shouldn't have happened. We'll be
sure you get the next one.
How much time do we have on the agenda?
MR. BOEHNERT: We have an hour and 40
minutes.
CHAIRMAN KRESS: On the full committee.
An hour. Almost two hours. Right?
MR. BOEHNERT: 10:20 to 12:00 noon on the
6th of September.
CHAIRMAN KRESS: Okay. My suggestion
would be, #1, that this GE presentation we just heard,
answering the previous questions I think would be
valuable for the whole committee to hear. So I would
want to see that from GE. From the staff, I think the
committee is pretty familiar with the way the
uncertainty analysis was done so we don't really need
much on that. But I would like to see sort of a
shortened overview of the SER because we really have
to have that. Not necessarily the full thing but at
least talk about the limitations and the code
assessment part. Something like slide seven on or
something in Ralph Landry's.
I think we would want to hear a little
bit, an abbreviated version of the kinetics part. I'd
like particularly to have a little bit of that where
you talked about your experience with the use of the
code itself. I think that was helpful. And maybe
some abbreviated discussion of the use of MCNP and, of
course, your final wrap-up slide of your findings. I
think that would be my impression. Do any other
committee members want to comment?
MEMBER SIEBER: I'd start with slide five
rather than seven so that people understand what the
scope really is. Slide five actually states that.
CHAIRMAN KRESS: Let's see. Maybe the
staff would have about 45 minutes and GE 35. Do you
think you can fit it into that kind of time frame?
MR. BOEHNERT: That's total time so allow
some time for questioning.
CHAIRMAN KRESS: Yes, that's total time.
Normally we say presentation time is 50 percent of
total time. So if there are no more comments or
questions, I'd like to thank everyone. GE, thank you,
and thanks to staff, particularly those from Frank
Rosenfeld for coming back and helping us out. Hope
you can make it to the September meeting, too.
MR. ULSES: Absolutely no problem. It's
always a pleasure.
CHAIRMAN KRESS: Okay. Thank you very
much. With that, I guess this is a recess because
tomorrow is a continuation of the same subcommittee.
MR. BOEHNERT: That's right.
CHAIRMAN KRESS: So tomorrow we hear about
water --
MR. BOEHNERT: That's correct.
CHAIRMAN KRESS: Okay. I'll call this
subcommittee meeting recessed until tomorrow.
(Whereupon, the meeting was recessed.)
