RFP_ATT_A_PARCS-SOW_Jun_26_15.pdf

DESCRIPTION/SPECIFICATIONS/WORK STATEMENT

Contents

C.1 Title of Project C.2 Introduction C.3 Background C.4 Objective C.5 Scope of Work C.6 List Services/Deliverables C.7 Estimated Level-of-Effort (LOE) C.8 Estimated Materials Required C.9 Reporting Requirements C.10 Publications C.11 Government-Furnished Property C.12 Access to Government Property and Facilities C.13 Place of Performance C.14 Security Requirements C.15 Post-award Orientation (kickoff) or Periodic Progress Meetings C.16 Contracting Officer’s Representative (COR) C.17 Key Personnel C.18 General – Contractor Personnel C.19 Contractor Travel

DESCRIPTION/SPECIFICATIONS/WORK STATEMENT

C.1 Title of Project

Contractor Support for the Purdue Advanced Reactor Core Simulator (PARCS) Code Suite.

C.2 Introduction

As part of the review of a nuclear power plant design undertaken under 10 CFR Part 50 and 52, the staff customarily conduct confirmatory calculations with independent codes and methods which the U.S. Nuclear Regulatory Commission (NRC) developed and assessed without nuclear industry guidance. The NRC suite of confirmatory codes is Standardized Computer Analyses for Licensing Evaluation (SCALE), PARCS, and TRACE1. These confirmatory calculations are important for two reasons: they require the NRC to develop and maintain a suite of codes for confirmatory nuclear and systems engineering analyses, and performance of these exercises by NRC staff allows staff to develop a deeper understanding of the underlying algorithms and phenomena of the systems that are being analyzed. The NRC staff then use these confirmatory codes (“software”) to independently demonstrate the safety of a licensee action with a safety-related calculation. Specifically, the confirmatory codes are used to complement the staff review of the power plant design to ensure that it meets the guidance described in Chapter 15 of the Standard Review Plan (SRP) for Light Water Reactors (LWRs)

(NUREG-0800).

This suite of confirmatory codes is collectively grouped into an Evaluation Model (EM) in which the different phenomena may be modeled via the use of different codes. General EM development has been documented in a process that is described in both NUREG/CR-5249, “Quantifying Reactor Safety Margins” and Regulatory Guide (RG) 1.203, “Transient and Accident Analysis Methods.”

The support for the NRC’s EM development from the Office of Nuclear Regulatory Research (RES), Division of Systems Analysis (DSA) is ongoing. The Office of Nuclear Regulation (NRR) and the Office of New Reactors (NRO) continue to need EM code support in the form of modifying TRACE/PARCS and PARCS models and documentation in ways that support NRC staff regulatory decision making with regards to the safety of license amendments, advanced plant designs, and power uprates. The PARCS predictions are usually compared to measured data from past industry initiatives and against common code benchmarks that have been employed by nuclear plant designers.

The PARCS source code consists of the coding residing within the contractor-maintained, standalone PARCS distribution, the PARCS coding residing within the

1 TRACE is an acronym for TRAC (Transient Reactor Analysis Code) RELAP (Reactor Excursion and Leak Analysis Program) Advanced Computational Engine.

TRACE/PARCS distribution, and the PARCS coding residing within the RELAP/PARCS distribution.

The contractor shall provide all personnel, equipment, supplies, facilities, transportation, tools, materials, supervision, and other items and non-personal services necessary to perform PARCS code suite (PARCS, GenPMAXS and TRIPEN/AGREE) maintenance, user support, assessment, development, and user training as defined in this Statement of Work (SOW), except for those items specified as Government-furnished property and services.

C.3 Background

Fundamental to reactor safety analysis is the ability to predict the fission power and decay heat sources that arise under normal, off-normal, and accident conditions. Quasi-steady-state calculations of spatial core power and burn-up distributions over core operating cycles are used to analyze (a) peak pin powers in relation to fuel thermal limits, (b) reactivity and power control, (c) safe shutdown margins, (d) slow spatial xenon transients and oscillations, and (e) the initial conditions of spatial reactivity feedback characteristics, fission power, stored heat, and decay power. Dynamically coupled transient calculations are especially important in analyzing the spatial kinetics of reactivity insertion transients (e.g., rod bank withdrawal, rod drop, rod ejection) and the core power surges and oscillations associated with transient over-cooling events (e.g., turbine trip), flow and boiling instabilities, and anticipated transients without scram

(ATWS).

This predictive ability entails the use of three-dimensional (3-D) reactor physics codes such as PARCS, which has been continuously developed by RES since 1998. PARCS has been dynamically coupled to the system thermal hydraulic code TRACE and is available as both an embedded module within TRACE and as a standalone code. The dynamically coupled TRACE/PARCS is used for the analyses of normal operations and transients in operating reactors (control and power maneuvers), analyses to support resolution of generic issues, evaluation of emergency procedures and accident management strategies, confirmation of licensee’s analyses, training exercises for NRC staff, and supporting analyses for the certification review of current reactor designs, advanced reactor designs, and research and test reactors.

PARCS is a nodal reactor analysis code that calculates the transient and steady state core power (and other safety significant reactor parameters) through the numeric solution to a discretized formulation for the neutron diffusion equation. In standalone-maintained form, PARCS is coupled to PATHS2 for steady-state BWR and PWR analysis, and coupled also to a simple mass-energy balance solver for steady-state PWR analysis. SNAP (Symbolic Nuclear Analysis Package) provides a graphical interface to PARCS.

GenPMAXS3 provides the key interface between PARCS and the following lattice physics codes: CASMO, HELIOS, TRITON, POLARIS, WIMS, CONDOR, and

2 PATHS is an acronym for PARCS Advanced Thermal Hydraulic Solver.

3 GenPMAXS is the code for Generating the cross section interface file PMAXS.

SERPENT. GenPMAXS also provides the cross section processing interface for conversion into the PARCS format from lattice physics data and the TRIPEN4/AGREE5 code. In addition to converting lattice physics-averaged cross sections, GenPMAXS analytically solves for the flux discontinuity along the fuel reflector interface.

TRIPEN/AGREE is used for the analysis of prismatic gas cooled reactor designs.

Similar to the PARCS code, TRIPEN is a nodal reactor analysis code, but it has been formulated specifically for triangular meshes. The AGREE code that has been coupled to TRIPEN solves for the heat transfer within the triangular portion of a hexagonal block with a system of 1-D flow channels for fluid flow, and a thermal-circuit conduction approach for the heat transfer. As in PATHS, AGREE provides thermal-hydraulic feedback for cross section interpolation.

PARCS code suite users include all users that have received the PARCS code suite or portions thereof through NRC licensing rights (e.g. Code Applications and Maintenance Program (CAMP)), international bilateral cooperative agreements, Thermal Hydraulics Codes Users Group, NRC contractors, and NRC staff).

C.4 Objective

The objective of this contract is to obtain maintenance, code support, assessment, development, and user training of the PARCS and GenPMAXS codes and the interface of PARCS with RELAP, TRACE, and SNAP as well as maintaining TRIPEN/AGREE support for the OECD-NEA-LOFC benchmark. The PARCS code supports independent regulatory decision making through its employment as a tool in confirmatory safety reviews of power plant operator actions, core designs, power uprates, and license amendments.

C.5 Scope of Work

The contractor shall provide all resources necessary to accomplish the tasks and deliverables described in this SOW. The contractor shall provide ongoing maintenance, code support, assessment, development and user training for the PARCS code suite (PARCS including the interface of PARCS with TRACE, RELAP, and SNAP, as well as the GenPMAXS and TRIPEN/AGREE codes).

The contractor shall maintain each portion of the PARCS code suite within its own configuration control system, perform model development, and PARCS standalone and coupled code (TRACE/PARCS) assessment.

The work under this contract shall apply to, but not be limited to, the operating fleet of LWRs, as well as more advanced Generation III (ABWR and APWR), Generation III+ (ESBWR and EPR), and small modular reactor LWR designs; High Temperature Gas- Cooled Reactors (HTGRs); research and training reactors; Aqueous Homogeneous

4 TRIPEN is an acronym for TRIangular Polynomial Expansion Nodal method.

5 AGREE (Advanced Gas REactor Evaluation) is a 3-D gas dynamics and heat transfer code.

Reactors; fast reactors; and VVERs (water water energy reactors). During the course of this contract, the contractor may be required to apply PARCS expertise to other advanced reactor designs, as directed by the Contracting Officer’s Representative

(COR).

All PARCS and GenPMAXS code changes shall be consistent with Attachment A (Special Requirements) and Attachment B (TRACE Standard F90 Programming Practices and General Design Philosophies).

The contractor shall test PARCS and GenPMAXS code changes a variety of compiler/operating system combinations. The contractor shall use the following compilers during maintenance and development of the PARCS source code:

Windows (Intel Visual Fortran) Linux (g95, Lahey, gfortran, Intel, NAG, Portland Group)

The contractor shall ensure that the above compilers and platforms are in place for the entire period of performance, and that these compilers are maintained at their most current release levels throughout the contract. The contractor be required to extend support to other compiler/operating system combinations that are not listed as a result of changing priorities.

C.6 List of Services/Deliverables

C.6.1 Specific Tasks

The contractor shall perform the tasks listed below. All activities under these tasks shall be prioritized by the COR through technical direction.

Task 1 - Code Maintenance

Subtask 1.1: Identify Code Bugs

The contractor shall identify all code bugs and maintain them in a “bug report” document which summarizes code errors (bugs, unexplained behavior, and documentation problems). This document shall list code bugs in tabular form and shall include the following information for each bug: a summary description of the bug; the date the bug was reported; the person who reported the bug; the status of the bug (i.e. in what code version the bug was addressed or will be addressed); the estimated level of effort in terms of hours to correct the bug; and the recommended priority level. Priority order shall be identified using a numerical scheme with number one (1) being the highest priority. The contractor shall list code bugs in descending priority order in the report.

The contractor shall populate the bug report based on information received from the COR and all authorized PARCS users per the COR provided user list. The final version of the monthly bug report shall be maintained by the contractor.

The most current PARCS bug report in prioritized format will be provided to the contractor upon contract award, along with the current PARCS user list. The COR will provide the contractor updated PARCS user list(s) as necessary throughout the contract period of performance.

Deliverable for Subtask 1.1: Bug Report

The contractor shall deliver a bug report with a recommended work priority for each bug electronically with the monthly letter status report (MLSR). The COR will review the report and provide any comments including changes to the proposed work priority within 5 business days of report receipt. The contractor shall reflect the COR comments in the following month’s report.

Subtask 1.2: Perform Code Fixes

Under COR technical direction, the contractor shall make changes to the collective PARCS source code in response to bugs reported by the COR and all other PARCS users, as captured in the bug report under Subtask 1.1. The contractor shall perform all work in accordance with priorities indicated in the Bug Report, as approved by the COR.

PARCS bugs may include bugs identified with the PARCS plug-in with SNAP6, bugs identified due to the use of TRACE/PARCS or RELAP/PARCS in coupled form, bugs identified due to the use of PARCS in standalone form, or bugs identified due to inconsistencies in cross section methodology or formatting between PARCS and any of the several lattice physics codes (SCALE, HELIOS, CASMO7, etc.) that are readable by GenPMAXS.

Upon COR direction, the contractor shall also update code documentation as the result of the correction of typos, the elimination of features that are no longer supported in the code, or the desire of users to make the documentation more clear and relevant, which may be included in the bug report.

The contractor shall test any PARCS source code changes made as a result of code bugs against the PARCS regression test suite before being checked into the code version control system. New test problems that are added to the PARCS or GenPMAXS test suites as a result of the correction of code bugs shall be documented in the HyperText Markup Language (HTML) summary file. The contractor shall modify the run scripts for the test suite as a result of any test problem additions, changes, or deletions, and shall modify the build scripts as a result of any additions, changes, or deletions to the source code.

The contractor shall create new versions of PARCS in response to code bug corrections.

The contractor shall maintain these different code versions using a version control system methodology, and this methodology shall have the ability to retrieve previously released code versions. Each retrieved code version shall contain enough information such that it can be a self-contained distribution (an archive). Previous code distributions will be provided to the contractor by the COR at time of contract award.

The root name (upper-most directory) of the code distribution shall include the code version name. Each code distribution (i.e., in directories below the upper-most root

6 SNAP is an acronym for Symbolic Nuclear Analysis Package

7 Although written in capital letters, the names HELIOS and CASMO are not acronyms.

directory) shall contain the following: the source code and associated libraries; operating system specific build scripts and MSVS (Microsoft Visual Studio) project workspaces for re-building the executable from the source code; code documentation, including a programmer’s manual, a theory manual, and a user manual; and code version documentation, which shall include directories that contain code differences by version (Fortran source code differences with respect to the previous version); the PARCS test suite; and an HTML summary file that describes the changes that were incorporated into that specific code version.

The following information shall be included in the HTML summary file: the code version;

the developer responsible for the code version; the code peer reviewer; the date the code version is submitted or checked-in; the base version over which the code version is developed; a code summary that verbally describes the changes within the code version;

new modules or files that have been added to the code version; modules or files that have been deleted from the code version; the differences of the changed files;

summaries of the code differences for each changed module; changes to the documentation (e.g. user, theory and programmer manuals as applicable) as a result of this code version change; changes that effect input, SNAP, or output; and regression test results. New test problems that are added to the regression/assessment suites as the result of this code version shall also be listed.

Deliverable for Subtask 1.2: PARCS Code Distribution to COR

The contractor shall send each checked-in code version as a PARCS distribution to the COR. The distribution shall be archived with SecureZIP and transmitted either through email, an NRC website, or another mechanism specified by the COR. The contractor shall provide the PARCS distribution to the COR within 5 business days of the completion of a checked-in PARCS code version.

Subtask 1.3: Prepare TRACE Updates

At a frequency determined by the COR (i.e., after a number of PARCS versions have been checked-in to the PARCS version control system), the contractor shall prepare a TRACE update for submittal to the NRC website. This update shall include the revised PARCS source code (and the revised TRACE source code, if necessary), a list of the differences between code versions embedded in text files, new test problems formulated to test the code update, revised code documentation, and the results of automated testing against the TRACE regression suite. This update process is described in detail in Attachments A and C.

Deliverable for Subtask 1.3: TRACE Update File

The contractor shall upload the TRACE Update file to the NRC website or submit the TRACE Update file directly to the COR within 10 business days of COR request. After the file is uploaded, the contractor shall provide an email confirmation to the COR within 1 business day of the upload.

Task 2 - Code Support

As directed by the COR, the contractor shall provide analysis and consultation support related to PARCS. This support shall include, but is not limited to: guidance on PARCS use, explanations of the algorithms that are coded into PARCS, develop PARCS, TRACE/PARCS, RELAP/PARCS models, interpret results, or explain underlying physics phenomena or algorithms, explanations of the input format, guidance on best-practices (“how to approach a problem”), the interpretation of any associated lattice physics models or PMAXS cross section libraries that are affiliated with the core or nuclear power plant model, performing pre-analysis scoping studies, performing phenomena identification and ranking table (PIRT) processes in accordance with NUREG/CR-5249, peer review analysis, and responding to code user questions and comments provided to the contractor by the COR. Analysis and consultation support may require preparation of briefing materials, technical presentations, documents, tutorial sessions, emails, or any other written correspondence necessary, as well as participation in NRC meetings, ACRS (Advisory Committee on Reactor Safeguards) reviews, and CAMP meetings.

Deliverable for Task 2: Code Support Documentation

Upon request of the COR, the contractor shall provide written code support documents (i.e. explanatory document) to the COR via email within 10 business days of the COR request.

Task 3 - Code Development

Upon COR direction and prioritization, the contractor shall perform any PARCS source code development that may be necessary as a result of user feedback, future RES program needs, regulatory user needs, and CAMP needs. This code development shall not be limited to code fixes, but shall be broadly applied to significant code changes that support user convenience (e.g., improved error checking and advanced editing options), code robustness and speed e.g., linear solver upgrades and changes and advanced neutronic methods), significant modeling enhancements, or utility codes or scripts that support PARCS code use.

Any PARCS source code changes made as a result of code enhancements or modeling changes shall be tested against the PARCS regression test suite before being checked-in to the code version control system. The contractor shall modify the run scripts for the test suite as a result of any test problem additions, changes, or deletions, and shall modify the build scripts as a result of any additions, changes, or deletions to the source code. The contractor shall revise the User, Theory, and Programmer’s manuals to reflect the code development activity.

Subtask 3.1: Pre-Code Documentation Requirements

For each code development activity, the contractor shall develop the following documentation, per the guidance specified in NUREG-1737:

Software Requirements Specification (SRS)

The SRS is a technical document that focuses on the underlying algorithms, technical specifications, and requirements of the software.

Software Design and Implementation Document (SDID)

The SDID describes the implementation of the technical specifications and algorithms outlined in the SRS, i.e., how the software will be structured and designed.

Qualification Test Plan (QTP) (also referred to as the “test plan” in NUREG-1737)

The Qualification Test Plan is a document which describes how the implemented capability will be tested, i.e. the test problems which will be used to demonstrate the new capability.

The contractor shall provide these documents to the COR prior to commencement of any code development. The contractor shall not proceed with code development until prior written approval has been received from the COR. For each code development activity the contractor shall include the development name as part of the deliverable title.

Deliverable One for Subtask 3.1: Software Requirements Specification (SRS)

The contractor shall deliver the SRS within 20 business days after Subtask 3.1 commencement.

Deliverable Two for Subtask 3.1: Software Design and Implementation Document

(SDID)

The contractor shall deliver the SDID within 30 business days after Subtask 3.1 commencement.

Deliverable Three for Subtask 3.1: Qualification Test Plan (QTP)

The contractor shall deliver the QTP within 40 business days after Subtask 3.1 commencement.

Subtask 3.2: Develop Resource Estimate for Code Development Activity

After COR approval of the pre-code documents developed in Subtask 3.1, the contractor shall develop a resource estimate of the effort required to implement a stable and tested code version that is capable of meeting the requirements specified in the SRS. This resource estimate will not be binding, but will enable the COR to closely monitor the effort being expended during the development task.

Deliverable for Subtask 3.2: Resource Estimate

The contractor shall provide the resource estimate via email and included as a note within the financial status section of the MLSR. The resource estimate shall be emailed to the COR within 3 business days of COR approval of pre-code documentation.

Subtask 3.3: Perform Code Development

The contractor shall implement the method outlined in the SRS and SDID into the latest stable PARCS version. During development, the contractor shall test the beta code version against a test problem(s) that was developed for the QTP. It is expected that the COR and other NRC staff will peer review and test this draft distribution, and that the contractor shall make continual changes to the draft code distribution (i.e., source code, build scripts, test problems, code manuals (as applicable), etc.) as a result of this peer review. This process may result in numerous submissions of Deliverable One for Subtask 3.3

Deliverable One for Subtask 3.3: Draft PARCS Distribution

The contractor shall provide the first PARCS test version to the COR, along with beta source code and draft documentation, within 40 business days of Subtask 3.3 commencement. Each subsequent draft distribution shall be provided to the COR within 20 business days of receipt of comments from COR.

Deliverable Two for Subtask 3.3: Final PARCS Distribution

The contractor shall provide to the COR the final PARCS distribution with the implemented coding. This distribution shall be organized as described in Subtask 1.2, with the addition of test problems to the PARCS test suite that test this functionality and shall be provided to the COR within 20 business days of the receipt of COR comments on the last draft distribution.

Subtask 3.4: Prepare Completion Report

The contractor shall prepare a Completion Report (CR) that documents the programming effort. Specifically, the report shall summarize the methodology, software, and user changes, and shall include calculation results that demonstrate the changed coding.

Deliverable for Subtask 3.4: Completion Report

The contractor shall deliver a completion report to the COR within 30 business days of the completion of each programming effort.

Subtask 3.5: Prepare TRACE Updates

At a frequency to be determined by the COR, the contractor shall prepare a TRACE update for submittal to the NRC website. This update shall include the new PARCS source code (and new TRACE source code, if necessary), the differences between code versions embedded in text files, new test problems formulated to test the code update, code documentation, and the results of automated testing against the TRACE regression suite. This update process is described in detail in Attachments A and C.

Deliverable for Subtask 3.5: TRACE Update File

The contractor shall upload the TRACE Update file to the NRC website or submit the TRACE Update file directly to the COR within 10 business days of COR request. If the file is uploaded, the contractor shall provide an email confirmation to the COR within 1 business day of the upload.

Task 4 - GenPMAXS Code Support and Maintenance

The contractor shall provide technical support and code maintenance for GenPMAXS to assure the consistency and accuracy of the cross section data that feeds PARCS.

Subtask 4.1: Maintain GenPMAXS in a Version Control System

The contractor shall maintain GenPMAXS in a version control system, each version being retrievable as a self-contained unit. Along with each version the contractor shall store the build system (MSVS workspaces, Linux and windows make files, and source), the test suite (test problems and run scripts), and the code documentation. The GenPMAXS code documentation shall include a manual describing the use and methodology behind GenPMAXS, as well as documents describing known issues, planned features, and supported features. Previous code distributions will be provided to the contractor by the COR at time of contract award.

Subtask 4.2: Correct GenPMAXS Bugs

The contractor shall correct bugs resulting from the use of GenPMAXS for reading in cross section data supplied by the lattice physics codes. These bugs shall be prioritized by the COR. Any new test problems that are added to the GenPMAXS test suite as a result of the correction of code bugs shall be documented in the GenPMAXS manual.

Subtask 4.3: Update GenPMAXS Source Code

To support PARCS code development in Task 3, the contractor shall perform major updates to the GenPMAXS source as a result of changes to underlying physics methods or cross section methodology within PARCS. These updates shall be prioritized by the COR. The contractor shall modify the run scripts for the test suite as a result of any test problem additions, changes, or deletions, and shall modify the build scripts as a result of any additions, changes, or deletions to the source code. Before checking in each GenPMAXS version to the version control system, each code version shall be tested against the common SCALE/GenPMAXS regression testing system. This testing system will be provided to the contractor at time of contract award.

Deliverable for Subtask 4.3: GenPMAXS Distribution to COR

The contractor shall send each checked-in code version as a GenPMAXS distribution to the COR and shall include a SCALE/GenPMAXS regression testing report, which will include an HTML testing summary. The GenPMAXS distribution shall be provided to the COR via the mechanism specified by the COR, within 5 business days of the completion of the SCALE/GenPMAXS regression test.

Subtask 4.4: Analysis Support for GenPMAXS

The contractor shall provide analysis support for the use of GenPMAXS. This support shall include, but not be limited to: guidance on GenPMAXS use, explanations of underlying GenPMAXS algorithms, interpretation of lattice physics or PMAXS cross section libraries or models, interpretation of PARCS and TRACE/PARCS results, explanations of the input format, and guidance on best-practices. This support may also include the development of briefing materials, documents, or emails that provide written explanations or interpretations of cross section libraries or methodology, and support program and ACRS reviews.

Deliverable for Subtask 4.4: GenPMAXS Code Support Documentation

Upon request of the COR, the contractor shall provide written code support documents (i.e. explanatory document) to the COR via email within 10 business days of the COR request.

Task 5 - PARCS and GenPMAXS User Training

The contractor shall provide two training sessions that each encompass training on both PARCS and GenPMAXS. The training sessions shall each be 8 hours in length and shall be provided to NRC staff and contractors, at NRC Headquarters, Rockville, MD.

The exact dates and times of these training sessions will be determined by the COR.

The contractor shall update training materials for the GenPMAXS and PARCS training sessions, as provided and directed by the COR. The contractor shall provide training sessions based upon the most current stable code manuals in effect at the time of the training.

As part of this task, the contractor shall revise example/model instructional slides provided by the COR to supplement the current GenPMAXS and PARCS stable code manuals. This training shall include instruction on PARCS and GenPMAXS theory and use, including example problems and instruction on code execution, and shall be provided as instructor led training to audiences of no more than 30 participants in each session.

Deliverable One for Task 5: Draft PARCS/GenPMAXS Training Materials

The deliverable shall be the revised PARCS/GenPMAXS training materials. This shall include Power Point slides, starter problem sets, and worked problem sets that illustrate the theory and use of PARCS/GenPMAXS. This shall be delivered to the COR 30 business days prior to training.

Deliverable Two for Task 5: Final PARCS/GenPMAXS Training Materials

The contractor shall provide a final version of the training materials within 5 business days of receipt of COR comments on draft.

Task 6 - Support for OECD-NEA LOFC HTTR (High-Temperature Engineering Test Reactor) Benchmark

The contractor shall support the participation of the NRC within the Organization for Economic Cooperation and Development/Nuclear Energy Agency (OECD/NEA) HTTR benchmark by performing the tasks stated below. The JAEA (Japanese Atomic Energy Agency) had originally planned three separate LOFC (Loss of Forced Cooling) tests under different conditions as part of the OECD/NEA LOFC benchmark. The first test, Run 1, was completed, and a post-test TRIPEN/AGREE model for Run 1 data is available. The second and third tests (Runs 2 and 3) are to be completed pending HTTR restart in FY 2015, and pre-test TRIPEN/AGREE models for Runs 2 and 3 have been developed.

Subtask 6.1: TRIPEN/AGREE Analysis of OECD-NEA LOFC Tests

As directed by the COR, the contractor shall review the models that have been developed for Runs 2-3, develop calculational notebooks for the models, and document model revisions, if necessary. The contractor shall also perform post-test analysis of Run 2 and Run 3 of the LOFC tests. When the experimental data becomes available, the contractor shall compare the models against the experimental data and make revisions to the models, if necessary. The contractor shall provide interpretation of the results presented in the briefing materials, explain the underlying physics phenomena or algorithms, if necessary, or explain input/modeling choices via conference calls or an email to the COR.

Deliverable One for Subtask 6.1: Draft TRIPEN/AGREE Models and Calculational Notebooks

The contractor shall deliver the draft models and draft calculational notebooks to the COR within 50 business days of receipt of the Run 2 and Run 3 digitized test data from the COR.

Deliverable Two for Subtask 6.1: Draft Briefing Materials to Support the Fourth Program Review Group/Management Board OECD LOFC Meeting

The contractor shall deliver post-test analysis of Run 2 and Run 3 of the LOFC tests in the form of draft presentation(s). The contractor shall deliver these materials to the COR within 70 business days of receipt of the Run 2 and Run 3 digitized test data from the COR. It is anticipated that these materials shall be revised by the contractor as a result of feedback from the COR.

Deliverable Three for Subtask 6.1: Final Briefing Materials, Models, and Calculational Notebooks to Support the Fourth Program Review Group/Management Board OECD LOFC Meeting

The contractor shall deliver post-test analysis of Run 2 and Run 3 of the LOFC tests in the form of final presentation(s), final models for Runs 2 and 3, and final calculational notebooks for Runs 2 and 3. The contractor shall deliver these materials to the COR within 90 business days of receipt of the Run 2 and Run 3 digitized test data from the

COR.

Subtask 6.2: TRIPEN/AGREE Version Control

The contractor shall support the code maintenance, version control, and documentation of the TRIPEN/AGREE code. The contractor shall create new versions of TRIPEN/AGREE in response to code bug corrections. The contractor shall maintain these different code versions using a version control system methodology, and this methodology shall have the ability to retrieve previously released code versions. Along with each code version the following items shall be stored: the build system including the associated SCons scripts; the test suite (test problems and run scripts); and the code documentation (user and theory manuals). Each checked-out and retrieved code version shall have been tested against the TRIPEN/AGREE test suite (5 models), and shall contain enough information such that it can be a self-contained distribution (an archive). The latest stable TRIPEN/AGREE code distribution will be provided to the contractor by the COR at time of contract award.

Deliverable for Subtask 6.2: TRIPEN/AGREE Code Distribution to COR

The contractor shall send each checked-in code version as a TRIPEN/AGREE distribution to the COR within 5 business days of COR request. The contractor shall archive the distribution with SecureZIP and transmitted via a mechanism specified by the

COR.

Task 7 - Perform PARCS Assessment against Watts Bar VERA

The contractor shall perform an assessment of SCALE/GenPMAXS/PARCS against the VERA benchmark that has been developed for the Watts Bar Unit 1 (WBN1) startup core (CASL-U-2012-0131-002). Throughout the assessment, the contractor shall participate in monthly conference calls with the COR and other NRC staff to discuss the progress of the assessment.

Deliverable One for Task 7: Draft PARCS / Watts Bar/VERA Models and Monthly Status Documentation

The contractor shall provide draft slides and models summarizing monthly progress.

The draft slides shall discuss results, model inputs, and interpretations of results. The contractor shall provide these items to the COR 1 business day prior to each monthly conference call.

Deliverable Two for Task 7: Final PARCS / Watts Bar/VERA Models and Documentation

The contractor shall provide the following: final models, calculational notebook (s), and final assessment report. These items shall be provided to the COR within 50 business days of receipt of COR comments on draft materials after the final monthly conference call.

Task 8 - Exponentially Varying Control Rod History Model

Currently, the PARCS methodology relies on linear interpolation of lattice physics calculations performed at various control rod histories (i.e., between fully controlled and fully un-controlled nodes). This linear weighting of the cross section data between the control rod states occurs regardless of the amount of time spent in each of the previous states, or the order of control-bank sequence. To account for the fact that the spectrum of the current nodal state should be more heavily weighted by its most recent state, it will be necessary for the contractor to implement an exponential weighting of control rod history interpolation.

Subtask 8.1: Pre-Code Documentation Requirements

Prior to implementation of this methodology, the contractor shall develop the following documentation, per the guidance specified in NUREG-1737:

Software Requirements Specification (SRS)

The SRS is a technical document that focuses on the underlying algorithms, technical

Software Design and Implementation Document (SDID)

The SDID describes the implementation of the technical specifications and algorithms outlined in the SRS, i.e., how the software will be structured and designed.

Qualification Test Plan (QTP) (also referred to as the “test plan” in NUREG-1737)

The Qualification Test Plan is a document which describes how the implemented capability will be tested, i.e. the test problems which will be used to demonstrate the new capability. The contractor shall provide these documents to the COR prior to commencement of any code development. The contractor shall not proceed with code development until prior written approval has been received from the COR. For each code development activity the contractor shall include the development name as part of the deliverable title.

Deliverable One for Subtask 8.1: Software Requirements Specification (SRS)

The contractor shall deliver the SRS within 20 business days after Subtask 8.1 commencement.

Deliverable Two for Subtask 8.1: Software Design and Implementation Document

(SDID)

The contractor shall deliver the SDID within 30 business days after Subtask 8.1 commencement.

Deliverable Three for Subtask 8.1: Qualification Test Plan (QTP)

The contractor shall deliver the QTP within 40 business days after Subtask 8.1 commencement.

Subtask 8.2: Perform Code Development

The contractor shall implement the method outlined in the SRS and SDID into the latest stable PARCS version. An edit with descriptive information regarding the weighting scheme shall be produced in the PARCS *.out file, in addition to the modified control rod history that shall be written to the *.dep file. The format of the *.dep file shall not be changed with this new methodology. During development, the contractor shall test this new weighting scheme against Three Mile Island Cycles 1-2 (TMI C1-C2). The models and documentation for TMI C1-C2 have already been developed by NRC staff. The COR and other NRC staff will peer review this task, and that the contractor shall make continual changes to the draft code distribution (i.e., source code, build scripts, test problems, code manuals (as applicable), etc.) as a result of this peer review. The contractor shall modify existing depletion test problems within the PARCS test suite in order to test this functionality, and the testing scripts shall be modified to accommodate these additional, modified test problems. This process may result in numerous submissions of Deliverable One for Subtask 8.2.

Deliverable One for Subtask 8.2: Draft PARCS Distribution

The contractor shall provide the PARCS test version to the COR, along with beta source code and draft documentation within 55 business days of start of Subtask 8.2.

Deliverable Two for Subtask 8.2: Final PARCS Distribution

The contractor shall provide to the COR the final PARCS distribution with the implemented exponential control rod history scheme. This distribution shall be organized as described in Subtask 1.2 and shall be provided to the COR within 10 business days of receipt of final COR comments on the last draft PARCS distribution.

Subtask 8.3: Prepare Completion Report

The contractor shall prepare a Completion Report (CR) that documents the implementation of the exponentially varying control rod history model. Specifically, the report shall summarize the methodology, software, and user changes, and shall include calculation results that demonstrate the changed coding.

Deliverable for Subtask 8.3: Completion Report

A completion report shall be delivered to the COR within 30 business days of the completion of the exponentially varying control rod history model.

Task 9 - Micro-depletion Algorithm Development and Implementation within

PARCS

PARCS currently employs a macroscopic depletion method, in which the assembly-homogenized, macroscopic cross sections are functionalized by thermal-hydraulic state and node history. The nodal burnup within a node is found from a relation between the nodal burnup and the nodal power and heavy metal density, and the core-averaged power, burnup, and heavy metal density. This nodal burnup is obtained incrementally during the cycle.

The change in nuclide concentration with respect to time is expressed as a function of the parent nuclides, the disintegration constants per nuclide, the one-group scalar fluxes and absorption cross sections. The solution of equations can be expressed in terms of an exponential, or transition (transmutation) matrix, in which the matrix terms express the reaction rates and fractions and decay rates and fractions. This system of equations is solved for the nuclide field within every reactor node.

The objective of this task is for the contractor to develop and implement a microscopic depletion method within PARCS that is capable of reading in data from SCALE. In a microscopic depletion method, the number densities and microscopic cross sections of fuel assemblies are used separately to construct the macroscopic cross sections at a given state point in the reactor.

Subtask 9.1: Pre-Code Documentation Requirements

Prior to implementation of this methodology, the contractor shall develop the following documentation, per the guidance specified in NUREG-1737:

Software Requirements Specification (SRS)

The SRS is a technical document that focuses on the underlying algorithms, technical

Software Design and Implementation Document (SDID)

The SDID describes the implementation of the technical specifications and algorithms outlined in the SRS, i.e., how the software will be structured and designed.

Qualification Test Plan (QTP) (also referred to as the “test plan” in NUREG-1737)

The Qualification Test Plan is a document which describes how the implemented capability will be tested, i.e. the test problems which will be used to demonstrate the new capability. The contractor shall provide these documents to the COR prior to commencement of any code development. The contractor shall not proceed with code development until prior written approval has been received from the COR. For each code development activity, the contractor shall include the development name as part of the deliverable title.

Deliverable One for Subtask 9.1: Software Requirements Specification (SRS)

The contractor shall deliver the SRS within 20 business days after Subtask 9.1 commencement.

Deliverable Two for Subtask 9.1: Software Design and Implementation Document

(SDID)

The contractor shall deliver the SDID within 30 business days after Subtask 9.1 commencement.

Deliverable Three for Subtask 9.1: Qualification Test Plan (QTP)

The contractor shall deliver the QTP within 40 business days after Subtask 9.1 commencement.

Subtask 9.2: GenPMAXS to Support for Micro-depletion

The contractor shall develop a microscopic cross section-oriented variant of the PMAXS file (Purdue Macroscopic Cross Section). This file shall contain enough information such that it is capable of tracking either the macroscopic or microscopic cross sections of all explicitly tracked nuclides and lumped nuclides. Cross sections evaluated at a reference condition shall be incorporated, along with cross sections evaluated at “branched” conditions, either in explicit or derivative form. The methodology shall be organized into several different types of blocks, depending upon the availability of cross section data per nuclide.

The contractor shall also develop a variant of the GenPMAXS code that is capable of reading in microscopic cross section data that has been processed by the ORIGIN-S8 sequence of SCALE.

8 ORIGIN is an acronym for Oak Ridge Isotope GENeration and Depletion Code.

Deliverable for Subtask 9.2: Draft GenPMAXS Distribution

The contractor shall deliver a draft GenPMAXS distribution to the COR (as described in Subtask 4.1) that is capable of both reading in ORIGIN-S data and writing a microscopic PMAXS file, within 40 business days after Subtask 9.2 commencement.

Subtask 9.3: PARCS Binning Feature Input

The contractor shall generalize the input format such that the user has the option to input, expand, or deprecate the number of considered nuclides in the depletion chain.

The result will be some user choice over the number of nuclides tracked in the chain, with the depletion calculation ranging from coarse but quick running (a few hundred nuclides), to the most accurate but expensive (1946 nuclides). The methodology shall bin the number of nuclides, with categories determined by the number of nuclides. The binning of the nuclide groups shall take into account the “lumping” of nuclides for ease of tracking.

Deliverable for Subtask 9.3: First Draft PARCS Distribution with Binning Input

The contractor shall provide a PARCS test version to the COR, along with beta source code and draft documentation. This test version shall be capable of processing additional input cards that define user choice in the number and type of nuclides to track.

The contractor shall deliver this draft code version to the COR within 40 business days after commencement of Subtask 9.3.

Subtask 9.4: Construction of Transmutation Matrix

The contractor shall implement programming changes over the draft PARCS distribution delivered in Subtask 9.3 to include the construction of a transition matrix (which is a matrix constructed from neutron reaction rates, fractions, nuclide decay, etc., and relates the rate of change of a nuclide to all of the nuclide sources and sinks).

Deliverable for Subtask 9.4: Second Draft PARCS Distribution with Transition Matrix Construction

The contractor shall provide a PARCS test version to the COR, along with beta source code and draft documentation. This test version shall be capable of building a transition matrix within PARCS that expresses the balance equations for the tracked nuclides specified in Subtask 9.2. This draft code version shall be delivered to the COR within 80 business days after commencement of Subtask 9.4.

Subtask 9.5: Solution of Transmutation Matrix

The contractor shall implement a solution algorithm within the draft PARCS distribution that was delivered in Subtask 9.3 that solves the transmutation matrix at an exposure step by looping through the user-specified nuclides (Subtask 9.2), classifying nuclides as long or short-lived, lumping short lived nuclides together and solving iteratively, and solving for long-lived nuclides with a series solution.

Deliverable for Subtask 9.5: Third Draft Micro-depletion PARCS Distribution with Transmutation Matrix Solution

The contractor shall provide a PARCS test version to the COR, along with beta source code and draft documentation. This code version shall be capable of calculating the nuclide distribution within each region of the core for a particular exposure step. This draft code version shall be delivered to the COR within 80 business days after commencement of Subtask 9.5.

Subtask 9.6: Exposure Record Capability for Micro-depletion

The contractor shall update the draft PARCS distribution delivered in Subtask 9.5 to include the following capabilities:

PARCS shall be updated to re-construct and store macroscopic cross sections that are functionalized with user specified histories and state variables, and these macroscopic cross sections shall be stored in PMAXS format as a function of exposure and state.

PARCS shall be updated such that it writes the microscopic cross section data to the restart file during calculation, and the format of the restart file shall be updated to accommodate this additional information.

PARCS shall maintain the capability to compute and store the currently computed history and thermal-hydraulic parameters. These variables shall be written to the “dep” (burnup) file during marching through burnup.

Deliverable One for Subtask 9.6: Fourth Draft Micro-depletion PARCS Distribution with Implementation of Restart Capability

The contractor shall provide a PARCS draft distribution to the COR, along with beta source code and draft documentation. This draft distribution shall be delivered to the COR within 20 business days after commencement of Subtask 9.6.

Deliverable Two for Subtask 9.6: Final PARCS Distribution

The contractor shall provide to the COR the final PARCS distribution with the implemented coding. This distribution shall be organized as described in Subtask 1.2, with the addition of micro-depletion and macro-depletion test problems to the PARCS test suite that test the functionality. The contractor shall test the final code version against TMI C1-C2 and shall deliver it to the COR within 50 business days of receipt of COR comments on Deliverable One for Subtask 9.6.

Subtask 9.7: Prepare Completion Report

The contractor shall prepare a Completion Report (CR) that documents the programming effort. Specifically, the report shall summarize the methodology, software, and user changes, and shall include calculation results that demonstrate the changed coding.

Deliverable for Subtask 9.7: Completion Report

The contractor shall deliver a completion report to the COR within 40 business days of the completion of Subtask 9.6.

C.6.2 Table of Deliverables

Task

Deliverable

Deliverable Deliverable

Due Date Acceptance

Criteria Deliverable

Format

1.1 - Bug Report By the 20th day of the following month

Report contains required content and incorporates all

COR

comments from the prior month

MS Word

Transmitted via e-mail

1.2 - PARCS Code Distribution to

COR

Within 5 business days of the completion…