ML23146A036
| ML23146A036 | |
| Person / Time | |
|---|---|
| Issue date: | 05/22/2023 |
| From: | Jennifer Dudek Acquisition Management Division |
| To: | Dewitt K Regents of the Univ of Michigan |
| References | |
| 31310023F0047 | |
| Download: ML23146A036 (1) | |
Text
DATE OF ORDER 2
ORDER FOR SUPPLIES OR SERVICES SCHEDULE - CONTINUATION CONTRACT NO.
AMOUNT UNIT PRICE UNIT QUANTITY ORDERED SUPPLIES/SERVICES ITEM NO.
MPORTANT: Mark all packages and papers with contract and/or order numbers.
ORDER NO.
QUANTITY ACCEPTED 05/22/2023 31310023F0047 PAGE NO (a)
(b)
(c)
(d)
(e)
(f)
(g) 31310020D0007 Acceptance of Task Order No. 31310023F0047 under contract No. 31310020D0007 should be made by having an official, authorized to bind your organization, execute two copies of this document in the space provided and return one copy to the Contracting Officer.
You should retain the other copy for your records.
Accepted Task Order No. 31310023F0047 under Contract No. 31310020D0007:
Signature Name Title Date Task Order Ceiling: $1,253,470.00 Task Order Obligation Amount: $230,000.00 Accounting Info:
2023-X0200-FEEBASED-60-60D003-60B301-1145-11 174-252A-11-6-174-1145 Period of Performance: 05/22/2023 to 01/31/2027 Prescribed by GSA FAR (48 CFR) 53.213(f)
OPTIONAL FORM 348 (Rev. 4/2006)
AUTHORIZED FOR LOCAL REPODUCTION PREVIOUS EDITION NOT USABLE TOTAL CARR ED FORWARD TO 1ST PAGE (ITEM 17(H))
$0.00
31310020D0007/31310023F0047 Page 3 B - Supplies or Services/Prices.....................................................................................................4 B.1 BRIEF PROJECT TITLE AND WORK DESCRIPTION.......................................................4 B.2 TYPE OF CONTRACT (JULY 2020)...................................................................................4 B.3 CONSIDERATION AND OBLIGATION-TASK ORDERS....................................................4 B.4 PRICE/COST SCHEDULE..................................................................................................4 C - Description/Specifications.......................................................................................................5 C.1 STATEMENT OF WORK....................................................................................................5 D - Packaging and Marking...........................................................................................................6 D.1 PACKAGING AND MARKING............................................................................................6 D.2 BRANDING.........................................................................................................................6 E - Inspection and Acceptance......................................................................................................7 E.1 INSPECTION AND ACCEPTANCE BY THE NRC (SEP 2013)..........................................7 F - Deliveries or Performance.......................................................................................................8 F.1 PLACE OF DELIVERY-REPORTS.....................................................................................8 F.2 TASK/DELIVERY ORDER PERIOD OF PERFORMANCE (SEP 2013).............................8 G - Contract Administration Data..................................................................................................9 G.1 2052.215-71 CONTRACTING OFFICER REPRESENTATIVE AUTHORITY. (OCT 1999)
...................................................................................................................................................9 G.2 2052.215-77 TRAVEL APPROVALS AND REIMBURSEMENT. (OCT 1999)..................11 G.3 2052.216-71 INDIRECT COST RATES. (JAN 1993).......................................................12 H - Special Contract Requirements.............................................................................................13 H.1 NRC SPECIFIC INFORMATION......................................................................................13 H.2 SECURITY REQUIREMENTS FOR CONTRACTORS (JULY 2022)...............................14 H.3 GOVERNMENT FURNISHED EQUIPMENT/PROPERTY...............................................16 H.4 DEFINITION AND HANDLING OF EXPORT CONTROLLED INFORMATION................18 H.5 NRC INFORMATION TECHNOLOGY SECURITY TRAINING (MAY 2016)....................19 H.6 DRUG FREE WORKPLACE TESTING: UNESCORTED ACCESS TO NUCLEAR FACILITIES, ACCESS TO CLASSIFIED INFORMATION OR SAFEGUARDS INFORMATION, OR PERFORMING IN SPECIALLY SENSITIVE POSITIONS (MARCH 2019)
.................................................................................................................................................21 H.7 2052.204-70 SECURITY. (OCT 1999)..............................................................................21 H.8 2052.204-71 SITE ACCESS BADGE REQUIREMENTS. (JAN 1993).............................23 H.9 2052.215-70 KEY PERSONNEL. (JAN 1993)..................................................................23 I - Contract Clauses.....................................................................................................................25 I.1 2052.209-72 CONTRACTOR ORGANIZATIONAL CONFLICTS OF INTEREST. (JAN 1993).......................................................................................................................................25 I.2 52.227-17 RIGHTS IN DATA--SPECIAL WORKS. (DEC 2007)........................................28 J - List of Documents, Exhibits and Other Attachments..............................................................30
31310020D0007/31310023F0047 Page 4 B - Supplies or Services/Prices B.1 BRIEF PROJECT TITLE AND WORK DESCRIPTION (a) The title of this project is: Contractor Support for the Purdue Advanced Reactor Core Simulator (PARCS) Code Suite (b) Summary work description:
The objective of this acquisition is to obtain regulatory technical support with the maintenance, code support, assessment, development, and user training of the PARCS/PATHS and GenPMAXS codes and the interface of PARCS with RELAP, TRACE, and SNAP. 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.
B.2 TYPE OF CONTRACT (JULY 2020)
The contract type for this award is cost-reimbursement.
B.3 CONSIDERATION AND OBLIGATION-TASK ORDERS (a) The ceiling of this order for services is $1,253,470.00.
(b) This order is subject to the minimum and maximum ordering requirements set forth in the contract.
(c) The amount presently obligated with respect to this order is $230,000.00. The obligated amount shall, at no time, exceed the order ceiling as specified in paragraph (a) above.
When and if the amount(s) paid and payable to the Contractor hereunder shall equal the obligated amount, the Contractor shall not be obligated to continue performance of the work unless and until the Contracting Officer shall increase the amount obligated with respect to this order, in accordance with FAR Part 43 - Modifications. Any work undertaken by the Contractor in excess of the obligated amount specified above is done so at the Contractor's sole risk and may not be reimbursed by the Government.
(d) The Contractor shall comply with the provisions of FAR 52.232 Limitation of Funds, for incrementally-funded delivery orders or task orders.
B.4 PRICE/COST SCHEDULE CLIN Description Amount 00001Estimated Cost
$1,253,470.00 TOTAL $1,253,470.00
31310020D0007/31310023F0047 Page 5 C - Description/Specifications C.1 STATEMENT OF WORK See Attachment No. 1: Statement of Work - Contractor Support for the PARCS Code Suite
31310020D0007/31310023F0047 Page 6 D - Packaging and Marking D.1 PACKAGING AND MARKING (a) The Contractor shall package material for shipment to the NRC in such a manner that will ensure acceptance by common carrier and safe delivery at destination. Containers and closures shall comply with the Surface Transportation Board, Uniform Freight Classification Rules, or regulations of other carriers as applicable to the mode of transportation.
(b) On the front of the package, the Contractor shall clearly identify the contract number under which the product is being provided.
(c) Additional packaging and/or marking requirements are as follows: N/A D.2 BRANDING The Contractor is required to use the statement below in any publications, presentations, articles, products, or materials funded under this contract/order, to the extent practical, in order to provide NRC with recognition for its involvement in and contribution to the project. If the work performed is funded entirely with NRC funds, then the contractor must acknowledge that information in its documentation/presentation.
Work Supported by the U.S. Nuclear Regulatory Commission (NRC), Office of Nuclear Regulatory Research, under Contract/order number 31310020D0007 / 31310023F0047.
31310020D0007/31310023F0047 Page 7 E - Inspection and Acceptance E.1 INSPECTION AND ACCEPTANCE BY THE NRC (SEP 2013)
Inspection and acceptance of the deliverable items to be furnished hereunder shall be made by the NRC Contracting Officers Representative (COR) at the destination, accordance with FAR 52.247 F.o.b. Destination.
31310020D0007/31310023F0047 Page 8 F - Deliveries or Performance F.1 PLACE OF DELIVERY-REPORTS The items to be furnished hereunder shall be delivered, with all charges paid by the Contractor, to:
- a. Contracting Officers Representative (COR)
Refer to Section G.1 2052.215-71 CONTRACTING OFFICER REPRESENTATIVE AUTHORITY. (OCT 1999)
- b. Contracting Officer (CO) (1 electronic copy)
(End of Clause)
F.2 TASK/DELIVERY ORDER PERIOD OF PERFORMANCE (SEP 2013)
This order shall commence on May 22, 2023 and will expire on January 31, 2027.
31310020D0007/31310023F0047 Page 9 G - Contract Administration Data NRCAR Clauses Incorporated By Full Text G.1 2052.215-71 CONTRACTING OFFICER REPRESENTATIVE AUTHORITY. (OCT 1999)
(a) The contracting officer's authorized representative (hereinafter referred to as the COR) for this contract is:
Name:
Nathanael Hudson Address:
U.S. Nuclear Regulatory Commission Office of Nuclear Regulatory Research Washington, DC 20555 Phone:
301-415-2182 E-mail:
Nathanael.Hudson@nrc.gov Alternate COR:
Name:
Lucas Kyriazidis Address:
U.S. Nuclear Regulatory Commission Office of Nuclear Regulatory Research Washington, DC 20555 Phone:
301-415-7834 E-mail:
Lucas.Kyriazidis@nrc.gov (b) Performance of the work under this contract is subject to the technical direction of the NRC COR. The term "technical direction" is defined to include the following:
(1) Technical direction to the contractor which shifts work emphasis between areas of work or tasks, authorizes travel which was unanticipated in the Schedule (i.e., travel not contemplated in the Statement of Work (SOW) or changes to specific travel identified in the SOW), fills in details, or otherwise serves to accomplish the contractual SOW.
(2) Provide advice and guidance to the contractor in the preparation of drawings, specifications, or technical portions of the work description.
(3) Review and, where required by the contract, approval of technical reports, drawings, specifications, and technical information to be delivered by the contractor to the Government under the contract.
(c) Technical direction must be within the general statement of work stated in the contract. The COR does not have the authority to and may not issue any technical direction which:
(1) Constitutes an assignment of work outside the general scope of the contract.
(2) Constitutes a change as defined in the "Changes" clause of this contract.
31310020D0007/31310023F0047 Page 10 (3) In any way causes an increase or decrease in the total estimated contract cost, the fixed fee, if any, or the time required for contract performance.
(4) Changes any of the expressed terms, conditions, or specifications of the contract.
(5) Terminates the contract, settles any claim or dispute arising under the contract, or issues any unilateral directive whatever.
(d) All technical directions must be issued in writing by the COR or must be confirmed by the COR in writing within ten (10) working days after verbal issuance. A copy of the written direction must be furnished to the contracting officer. A copy of NRC Form 445, Request for Approval of Official Foreign Travel, which has received final approval from the NRC must be furnished to the contracting officer.
(e) The contractor shall proceed promptly with the performance of technical directions duly issued by the COR in the manner prescribed by this clause and within the COR's authority under the provisions of this clause.
(f) If, in the opinion of the contractor, any instruction or direction issued by the COR is within one of the categories as defined in paragraph (c) of this section, the contractor may not proceed but shall notify the contracting officer in writing within five (5) working days after the receipt of any instruction or direction and shall request the contracting officer to modify the contract accordingly. Upon receiving the notification from the contractor, the contracting officer shall issue an appropriate contract modification or advise the contractor in writing that, in the contracting officer's opinion, the technical direction is within the scope of this article and does not constitute a change under the "Changes" clause.
(g) Any unauthorized commitment or direction issued by the COR may result in an unnecessary delay in the contractor's performance and may even result in the contractor expending funds for unallowable costs under the contract.
(h) A failure of the parties to agree upon the nature of the instruction or direction or upon the contract action to be taken with respect thereto is subject to 52.233 Disputes.
(i) In addition to providing technical direction as defined in paragraph (b) of the section, the COR shall:
(1) Monitor the contractor's technical progress, including surveillance and assessment of performance, and recommend to the contracting officer changes in requirements.
(2) Assist the contractor in the resolution of technical problems encountered during performance.
(3) Review all costs requested for reimbursement by the contractor and submit to the contracting officer recommendations for approval, disapproval, or suspension of payment for supplies and services required under this contract.
(4) Assist the contractor in obtaining the badges for the contractor personnel.
31310020D0007/31310023F0047 Page 11 (5) Immediately notify the Security Branch, Division of Facilities and Security (SB/DFS) (via e-mail) when a contractor employee no longer requires access authorization and return of any NRC issued badge to SB/DFS within three days after their termination.
(6) Ensure that all contractor employees that require access to classified Restricted Data or National Security Information or matter, access to sensitive unclassified information (Safeguards, Official Use Only, and Proprietary information) access to sensitive IT systems or data, unescorted access to NRC controlled buildings/space, or unescorted access to protected and vital areas of nuclear power plants receive approval of SB/DFS prior to access in accordance with Management Directive and Handbook 12.3.
(7) For contracts for the design, development, maintenance or operation of Privacy Act Systems of Records, obtain from the contractor as part of closeout procedures, written certification that the contractor has returned to NRC, transferred to the successor contractor, or destroyed at the end of the contract in accordance with instructions provided by the NRC Systems Manager for Privacy Act Systems of Records, all records (electronic or paper) which were created, compiled, obtained or maintained under the contract.
(End of Clause)
G.2 2052.215-77 TRAVEL APPROVALS AND REIMBURSEMENT. (OCT 1999)
(a) All foreign travel must be approved in advance by the NRC on NRC Form 445, Request for Approval of Official Foreign Travel, and must be in compliance with FAR 52.247-63 Preference for U.S. Flag Air Carriers. The contractor shall submit NRC Form 445 to the NRC no later than 30 days before beginning travel.
(b) The contractor must receive written approval from the NRC Project Officer before taking travel that was unanticipated in the Schedule (i.e., travel not contemplated in the Statement of Work, or changes to specific travel identified in the Statement of Work).
(c) The contractor will be reimbursed only for travel costs incurred that are directly related to this contract and are allowable subject to the limitations prescribed in FAR 31.205-46.
(d) It is the responsibility of the contractor to notify the contracting officer in accordance with the Limitations of Cost clause of this contract when, at any time, the contractor learns that travel expenses will cause the contractor to exceed the estimated costs specified in the Schedule.
(e) Reasonable travel costs for research and related activities performed at State and nonprofit institutions, in accordance with Section 12 of Pub. L. 100-679, must be charged in accordance with the contractor's institutional policy to the degree that the limitations of Office of Management and Budget (OMB) guidance are not exceeded. Applicable guidance documents include OMB Circular A-87, Cost Principles for State and Local Governments; OMB Circular A-122, Cost Principles for Nonprofit Organizations; and OMB Circular A-21, Cost Principles for Educational Institutions.
31310020D0007/31310023F0047 Page 13 H - Special Contract Requirements NRC Local Clauses Incorporated by Full Text H.1 NRC SPECIFIC INFORMATION COPYRIGHT OF CODES - SPECIAL NUCLEAR PURPOSE LICENSE (A) The NRC may, pursuant to Section (c) of FAR Clause 52-227-14 permit and may pursuant to paragraph (c) of FAR 52.227-17, direct the contractor to claim a copyright in computer software and associated data first produced in the performance of this contract. In addition to the general government license rights identified in Section (c) of FAR Clause 52.227-14, and paragraph (c) of FAR 52.227-17, such copyright shall be subject to the following Special Nuclear Purpose License rights:
In addition to the license rights granted the government under paragraph (c) of the clause at 52.227-14, RIGHTS IN DATA-GENERAL (DEC 2007) and paragraph (c) of FAR 52.227-17, RIGHTS IN DATA-Special Works, whenever copyright to software is asserted by the Contractor, the contractor grants the NRC and others acting on its behalf an exclusive, paid up, worldwide, irrevocable license to use, disclose, reproduce, prepare derivative works and distribute any code developed in the performance of the award for nuclear health and safety purposes, which may include analyses of operational, decommissioned, or designs of nuclear reactor systems and other such facilities involving nuclear technology performed by parties which may include but are not limited to licensees, vendors, contractors, educational institutions, public interest groups, participants in NRC international agreement programs and other government agencies. Further, consistent with NRCAR 2052.209-72, CONTRACTOR ORGANIZATIONAL CONFLICTS OF INTEREST, the contractor agrees that it will not sell or distribute the code to or for the use of such parties or participants identified in NRCAR 2052.209-72(c)(1) and (c)(2) and that it will not provide technical services relating to the code to such parties or participants, unless authorized by NRC.
In addition, the contractor grants NRC the right to use, disclose, reproduce, prepare derivative works and distribute any future improvements or derivative works made to the code in the field of nuclear health and safety. Per 41 USC § 2302(b)(2), NRC retains the right to improvements made to the code resulting from the contractor's commercial activity that the NRC contracting officer determines are necessary to operate and maintain software developed under this contract. Further, the contractor agrees to include in any licensing agreement that it may enter into with a third party such limitations as are necessary to preserve the rights of the government, and limit the sale and distribution of the software as described above and as limited by the U.S.
Departments of Commerce and State concerning foreign sales.
(B) The NRC reserves the right to direct the contractor to transfer the copyright in codes and associated data developed under this contract to successor contractors subject to the above general government and special license rights. Should NRC determine that it is in the government's interest to have NRC staff perform the software development and maintenance work required under this contract, the contractor agrees to maintain the copyright subject to the above general government and special license rights.
For the electronic manuscript, prepare the text in MS Word, and use any of the following file
31310020D0007/31310023F0047 Page 14 types for charts, spreadsheets, and the like.
File Types to be used for NUREG-Series Publications:
File Type (File Extension) Word (.doc) Microsoft PowerPoint (.ppt) Microsoft Excel
(.xls) Portable Document Format (.pdf)
This list is subject to change if new software packages come into common use at NRC or by our licensees or other stakeholders that participate in the electronic submission process. If a portion of your manuscript is from another source and you cannot obtain an acceptable electronic file type for this portion (e.g., an appendix from an old publication), the NRC can, if necessary, create a tagged image file format (file extension.tif) for that portion of your report.
Note that you should continue to submit original photographs, which will be scanned, since digitized photographs do not print well.
If you chose to publish a compact disk (CD) of your publication, place on the CD copies of the manuscript in both (1) a portable document format (PDF); and (2) a Word file format.
H.2 SECURITY REQUIREMENTS FOR CONTRACTORS (JULY 2022)
It has been determined that contractor personnel with access to information related to work on this contract/order are required to obtain IT Level I access or N/A clearance.
The Contractor shall ensure that all its applicants (i.e. employees, subcontractor employees or consultants) who are assigned to perform the work herein for contract performance are approved by the NRC. The NRC Contracting Officers Representative (COR) shall make the final determination of the Building Access (BA), level of Information Technology (IT) Access (Level I or Level II), or the national security clearance level (Q or L) required for all applicants working under this contract/task order using the following guidance. The Contractor should conduct a preliminary federal facilities security screening interview or prescreening review for each of its applicants and submit to the NRC only the names that have a reasonable probability of obtaining approval necessary for access to NRC's federal facilities.
The Contractors pre-screening review, applicable to all access/clearance levels, should focus on the applicants history regarding the following:
(a) felony arrest in the last seven (7) years; (b) alcohol related arrest within the last five (5) years; (c) record of any military court-martial convictions in the past ten (10) years; (d) illegal use of narcotics or other controlled substances possession in the past year; (e) illegal purchase, production, transfer, or distribution of narcotics or other controlled substances in the last seven (7) years; (f) delinquency on any federal debts or bankruptcy in the last seven (7) years;
31310020D0007/31310023F0047 Page 15 (g) applicants with less than five (5) years permanent residency in the U.S. will not be approved for Building Access, IT Access, or a national security clearance; (h) non-U.S. citizens must provide official documentation to the DFS/PSB as proof of their permanent residency (i) foreign nationals (non-U.S. citizens) are not eligible for a national security clearance (Q or L)
SECURITY REQUIREMENTS FOR BUILDING ACCESS This is applicable when an applicant will require unescorted Building Access (BA) and a HSPD-12 PIV card (NRC badge). Temporary Building Access may be approved by the NRC based on a favorable NRC review and discretionary determination of the applicants Building Access security forms. Final Building Access will be approved by the NRC based on favorable adjudication of their background investigation completed by the Defense Counterintelligence and Security Agency (DCSA). Requires an OPM SF-85 (see https://www.opm.gov/forms/standard-forms/).
SECURITY REQUIREMENTS FOR IT LEVEL II (IT-II) ACCESS An applicant will require IT-II Access if the applicant will need access to IT systems or Controlled Unclassified Information (CUI) regardless of physical work location, including an NRC Local Area Network (LAN) account. IT-II Access includes all the access and responsibilities included under Building Access. Temporary IT Access may be approved by the NRC based on a favorable NRC review and discretionary determination of the applicants IT Access security forms. Final IT Access will be approved by the NRC based on favorable adjudication of their background investigation completed by the Defense Counterintelligence and Security Agency (DCSA). Requires an OPM SF-86 (see https://www.opm.gov/forms/standard-forms/).
SECURITY REQUIREMENTS FOR IT LEVEL I (IT-I) ACCESS An applicant will require IT-I Access if the applicant will need access to IT systems or Controlled Unclassified Information (CUI) regardless of physical work location, including an NRC Local Area Network (LAN) account. IT-I Access involves responsibility for the planning, direction, and implementation of a computer security program, and will have major responsibility for the direction, planning, and design of a computer system, including its hardware and software. IT-I access also includes the need to access a computer system during its operation or maintenance in such a way that could cause or that has a relatively high risk of causing grave damage to the agency. IT-I access also includes the applicants capability to realize a significant personal gain from computer access. IT-I Access includes all the access and responsibilities under IT-II Access and Building Access. Temporary IT Access may be approved by the NRC based on a favorable NRC review and discretionary determination of the applicants IT Access security forms. Final IT Access will be approved by the NRC based on favorable adjudication of their background investigation completed by the Defense Counterintelligence and Security Agency (DCSA). Requires an OPM SF-86 (see https://www.opm.gov/forms/standard-forms/).
SECURITY REQUIREMENTS FOR L CLEARANCE
31310020D0007/31310023F0047 Page 16 An applicant will be submitted for an L Clearance if the applicant is designated in a non-critical-sensitive position requiring access to, on a need-to-know basis, to Secret and Confidential National Security Information or Confidential Restricted Data (RD) not related to broad naval nuclear propulsion program policy or direction. A security orientation briefing must be given to the applicant by the NRC when the background investigation is completed and favorably adjudicated by the NRC. This briefing will normally be given by a representative of the NRCs Personnel Security Branch (PSB), or in a regional office by a regional security representative. Temporary IT-II Access may be approved based on a favorable NRC review and discretionary determination of the applicants national security clearance security forms. A national security clearance will be granted by the NRC based on favorable adjudication of the applicants background investigation completed by the Defense Counterintelligence and Security Agency (DCSA). Requires an OPM SF-86 (see https://www.opm.gov/forms/standard-forms/).
SECURITY REQUIREMENTS FOR Q CLEARANCE An applicant will be submitted for a Q Clearance if the applicant is designated in a critical-sensitive position requiring access to, on a need-to-know basis, to Top Secret, Top Secret RD, Secret, Secret RD, Confidential, and Confidential RD. A security orientation briefing must be given to the applicant by the NRC requiring national security clearance when the background investigation is completed and favorably adjudicated by the NRC. This briefing will normally be given by a representative of PSB, or in a regional office by a regional security representative.
Temporary IT-II Access may be approved based on a favorable NRC review and discretionary determination of the applicants national security clearance security forms. A national security clearance will be granted by the NRC based on favorable adjudication of their background investigation completed by the Defense Counterintelligence and Security Agency (DCSA).
Requires an OPM SF-86 (see https://www.opm.gov/forms/standard-forms/).
REMOVING AN APPLICANT FROM A CONTRACT AND/OR TASK ORDER The Contractor shall immediately notify the COR when an applicant will no longer support this NRC contract/order.
H.3 GOVERNMENT FURNISHED EQUIPMENT/PROPERTY (a) The NRC will provide the contractor with the following items for use under this contract:
GFP Item Quantity Date Provided to Contractor Method of Shipment Access to the current NRC-sponsored, PARCS/PATHS/GenPMAXS BugZilla bug tracking system on https://www.nrccodes.com/
1 Upon Award Electronic credentials provided through email by incumbent contractor Prior PARCS Distributions (source code, build scripts, manuals, test problems, etc.)
1 Upon Award Electronic (email or Box)
Prior GenPMAXS Distributions (source code, build scripts, manuals, test 1 Upon Award Electronic (email or Box)
31310020D0007/31310023F0047 Page 17 problems, known bugs document, regression testing summary, summary slides, etc.)
Prior PARCS and GenPMAXS Training Materials 1 Upon Award Electronic (email or Box)
SCALE/GenPMAXS Regression Testing Framework 1 Upon Award Electronic (email or Box)
Letter Report: Test Requirement Specifications for the SCALE-GenPMAXS Unified Test Suite. ORNL/LTR-2011/326.
Task 1 Letter Report. F6028 1 Upon Award Electronic (email or Box)
Letter Report: The SCALE-GenPMAXS Unified Test Suite ORNL/LTR-2012/612. Task 2 Letter Report. F6028 1 Upon Award Electronic (email or Box)
Letter Report: Unified Testing for SCALE and PARCS Development Work Benchmark Package ORNL/LTR-2013/8. Task 3 Letter Report. F6028 1 Upon Award Electronic (email or Box)
Isotopic and Fuel Lattice Parameter Trends in Extended Enrichment and Higher Burnup LWR Fuel Vol. II: BWR Fuel, ORNL/TM-2020/1835, ADAMS No.: ML21088A354 1 Upon Award Electronic (email or Box)
Isotopic and Fuel Lattice Parameter Trends in Extended Enrichment and Higher Burnup LWR Fuel Vol. I: PWR Fuel, ORNL/TM-2020/1833, ADAMS No.: ML21088A336 1 Upon Award Electronic (email or Box)
Extended-Enrichment Accident-Tolerant LWR Fuel Isotopic and Lattice Parameter Trends, ORNL/TM-2021/1961, ADAMS No.:
ML21088A254 1 Upon Award Electronic (email or Box)
NUREG-1737 1 Upon Award Obtain via public website (nrc.gov)
MD 12.3 1 Upon Award Obtain via public website (nrc.gov)
MD 12.5 1 Upon Award Obtain via public website (nrc.gov)
MD 12.6 1 Upon Award Obtain via public website (nrc.gov)
(b) Only the equipment/property listed above in the quantities shown will be provided by the Government. The contractor shall be responsible and accountable for all Government property provided under this contract and shall comply with the provisions of the FAR Government Property Clause under this contract and FAR Subpart 45.5, as in effect on the date of this contract. The contractor shall investigate and provide written notification to the NRC Contracting Officer (CO) and the NRC Division of Facilities and Security, Physical Security Branch of all cases of loss, damage, or destruction of Government property in its possession or control not later than 24 hours2.777778e-4 days <br />0.00667 hours <br />3.968254e-5 weeks <br />9.132e-6 months <br /> after discovery. The contractor must report stolen Government property to the local police and a copy of the police report must be provided to the CO and to the Division of Facilities and Security, Office of Administration.
31310020D0007/31310023F0047 Page 18 (c) All other equipment/property required in performance of the contract shall be furnished by the Contractor.
H.4 DEFINITION AND HANDLING OF EXPORT CONTROLLED INFORMATION Definition of Export Controlled Information Export Controlled Information (ECI) is unclassified information concerning certain items, commodities, technology, software, or other information whose export could reasonably be expected to adversely affect the United States national security and nonproliferation objectives, to include dual use items; items identified in export administration regulations, international traffic in arms regulations and the munitions list; license applications; and sensitive nuclear technology information.
ECI is a sub-category of Controlled Unclassified Information (CUI). ECI is defined in the CUI Registry, which is maintained by the National Archives, (https://www.archives.gov/cui/registry/category-list.). The CUI Registry itself resides in 32 CFR 2002 (https://ecfr.io/Title-32/cfr2002_main). Executive Order 13556 establishes the program for managing CUI and designates the National Archives as the Executive Agent for this program.
The program for managing CUI/ECI exists within the framework of a larger body of export control laws, regulations and directives that include but are not limited to: the Atomic Energy Act of 1954, as amended; the Arms Export Control Act (22 U.S.C. § 2751 et seq.); the Export Administration Act of 1979 as continued under the International Emergency Economic Powers Act (Title II of Pub.L.95-223, 91 Stat. 1626, October 28, 1977); Trading with the Enemy Act (50 U.S.C. App. 5(b) as amended by the Foreign Assistance Act of 1961); Assistance to Foreign Atomic Energy Activities (10 CFR part 810); Export and Import of Nuclear Equipment and Material (10 CFR part 110); International Traffic in Arms Regulations (22 CFR parts 120 through 130); Export Administration Regulations (15 CFR part 730 through 734); Foreign Assets Control Regulations (31 CFR parts 500 through 598); and the Espionage Act (37 U.S.C. 791 et seq.)
Who can access ECI?
All contractor personnel eligible to access ECI information must have either US Citizenship Status or Permanent Resident Alien status (i.e., Green Card holder status). Individuals having neither US Citizenship status nor Permanent Resident Alien status are ineligible to participate in the technical work of this contract or task order effort.
Handling of ECI:
If the contractor has any questions/concerns regarding handling of ECI material they should contact their cognizant Contracting Officers Representative (COR) for guidance.
ECI Processing (a) Electronic processing (including storage and transmission) of ECI shall only be performed on NRC equipment. The NRC-provided laptop will have the capability to connect to the NRC network using a Virtual Private Network along with the users valid NRC credentials. The NRC-provided laptop must remain in the continental United States at all times and must not be accessed by a foreign national (non-U.S. citizen).
31310020D0007/31310023F0047 Page 19 (b) Electronic ECI must be encrypted when not in use.
(c) Electronic messaging regarding the ECI shall only be performed between the users NRC email account and an NRC email account of another person that has been determined to have a need-to-know the ECI.
(d) ECI must only be shared with individuals that have a need to know the information and must be verified to be a U.S. citizen (i.e., not a foreign national) or Permanent Resident Alien (Green Card holder).
(e) Printed ECI shall be controlled as follows:
(1) ECI must not be exposed in public environments (e.g., trains, airplanes) or to a foreign national.
(2) Physical storage of printed sensitive information must be in a locked cabinet or drawer when not under the physical control of the user.
(3) Physical transmission of ECI must only be performed using one of the following methods:
- a. U.S. Postal Service: First Class Mail, Registered Mail, Express Mail, Certified Mail.
- b. Hand-carried by any individual authorized access to the ECI. That individual shall retain the ECI in his or her possession to the maximum extent possible unless they place the document in the custody of another person authorized access to the ECI in question.
- c. Approved commercial express carriers. Transmit in single opaque envelope.
(f) ECI must not be taken outside of the continental United States, regardless of whether it is in electronic or printed form.
(g) ECI must not be shown, discussed, shared, transmitted, or otherwise provided to any person without first verifying that they are either a U.S. citizen (e.g., foreign nationals cannot have access to ECI) or have Permanent Resident Alien status (Green Card holder).
(h) In the event that the contractor violates or fails to comply with these requirements, the contractor shall notify the designated contract or task order Contracting Officer, the designated contract or task order COR, and the IDIQ COR (if applicable) within three calendar days of the occurrence. Notification shall take the form of an e-mail containing information sufficient to describe the occurrence.
(i) NRC contractors shall ensure that their employees, subcontractor employees, and consultants who have been granted access to ECI comply with the requirements of this clause.
Failure to timely report the required information could result in revocation of IT-II Clearance status of contractor (or subcontractor) employee(s) and revocation of NRC system access; removal of contractor (or subcontractor) employee(s) from the contract or task order in question; termination of the contract or task order; as well as a negative CPARS evaluation.
H.5 NRC INFORMATION TECHNOLOGY SECURITY TRAINING (MAY 2016)
31310020D0007/31310023F0047 Page 20 NRC contractors shall ensure that their employees, consultants, and subcontractors with access to the agency's information technology (IT) equipment and/or IT services complete NRC's online initial and refresher IT security training requirements to ensure that their knowledge of IT threats, vulnerabilities, and associated countermeasures remains current. Both the initial and refresher IT security training courses generally last an hour or less and can be taken during the employee's regularly scheduled work day.
Contractor employees, consultants, and subcontractors shall complete the NRC's online annual, "Computer Security Awareness" course on the same day that they receive access to the agency's IT equipment and/or services, as their first action using the equipment/service. For those contractor employees, consultants, and subcontractors who are already working under this contract, the on-line training must be completed in accordance with agency Network Announcements issued throughout the year, within three weeks of issuance of this modification.
Additional annual required online NRC training includes but is not limited to the following:
(1) Information Security (INFOSEC) Awareness (2) Continuity of Operations (COOP) Awareness (3) Defensive Counterintelligence and Insider Threat Awareness (4) No FEAR Act (5) Personally Identifiable Information (PII) and Privacy Act Responsibilities Awareness Contractor employees, consultants, and subcontractors who have been granted access to NRC information technology equipment and/or IT services must continue to take IT security refresher training offered online by the NRC throughout the term of the contract. Contractor employees will receive notice of NRC's online IT security refresher training requirements through agency-wide notices.
Contractor Monthly Letter Status Reports (MLSR) must include the following information for all completed training:
(1) the name of the individual completing the course; (2) the course title; and (3) the course completion date.
The MLSR must also include the following information for those individuals who have not completed their required training:
(1) the name of the individual who has not yet completed the training; (2) the title of the course(s) which must still be completed; and (3) the anticipated course completion date(s).
The NRC reserves the right to deny or withdraw Contractor use or access to NRC IT equipment and/or services, and/or take other appropriate contract administrative actions (e.g., disallow
31310020D0007/31310023F0047 Page 21 costs, terminate for cause) should the Contractor violate the Contractor's responsibility under this clause.
H.6 DRUG FREE WORKPLACE TESTING: UNESCORTED ACCESS TO NUCLEAR FACILITIES, ACCESS TO CLASSIFIED INFORMATION OR SAFEGUARDS INFORMATION, OR PERFORMING IN SPECIALLY SENSITIVE POSITIONS (MARCH 2019)
The following Contractor employees, subcontractor personnel, and consultants proposed for performance or performing under this contract shall be subject to pre-assignment, random, reasonable suspicion, and post-accident drug testing: (1) individuals who have access to classified information (National Security Information and/or Restricted Data); (2) individuals who have access to Safeguards information (section 147 of the Atomic Energy Act of 1954, as amended); (3) individuals who are authorized to carry firearms while performing work under this contract; (4) individuals who are required to operate government vehicles or transport passengers for the NRC; (5) individuals who are required to operate hazardous equipment at NRC facilities; (6) individuals who administer the agencys drug program or who have Employee Assistance Program duties; (7) individuals who have unescorted access to vital or protected areas of Nuclear Power Plants, Category 1 Fuel Cycle Facilities, or Uranium Enrichment Facilities; or (8) incident/emergency response personnel (including on-call).
NRCAR Clauses Incorporated By Full Text H.7 2052.204-70 SECURITY. (OCT 1999)
(a) Security/Classification Requirements Form. The attached NRC Form 187 (See List of Attachments) furnishes the basis for providing security and classification requirements to prime contractors, subcontractors, or others (e.g., bidders) who have or may have an NRC contractual relationship that requires access to classified information or matter, access on a continuing basis (in excess of 90 or more days) to NRC Headquarters controlled buildings, or otherwise requires NRC photo identification or card-key badges.
(b) It is the contractor's duty to safeguard National Security Information, Restricted Data, and Formerly Restricted Data. The contractor shall, in accordance with the Commission's security regulations and requirements, be responsible for safeguarding National Security Information, Restricted Data, and Formerly Restricted Data, and for protecting against sabotage, espionage, loss, and theft, the classified documents and material in the contractor's possession in connection with the performance of work under this contract. Except as otherwise expressly provided in this contract, the contractor shall transmit to the Commission any classified matter in the possession of the contractor or any person under the contractor's control in connection with performance of this contract upon completion or termination of this contract.
(1) The contractor shall complete a certificate of possession to be furnished to the Commission specifying the classified matter to be retained if the retention is:
(i) Required after the completion or termination of the contract; and (ii) Approved by the contracting officer.
(2) The certification must identify the items and types or categories of matter retained, the conditions governing the retention of the matter and their period of
31310020D0007/31310023F0047 Page 22 retention, if known. If the retention is approved by the contracting officer, the security provisions of the contract continue to be applicable to the matter retained.
(c) In connection with the performance of the work under this contract, the contractor may be furnished, or may develop or acquire, proprietary data (trade secrets) or confidential or privileged technical, business, or financial information, including Commission plans, policies, reports, financial plans, internal data protected by the Privacy Act of 1974 (Pub. L.93-579), or other information which has not been released to the public or has been determined by the Commission to be otherwise exempt from disclosure to the public. The contractor agrees to hold the information in confidence and not to directly or indirectly duplicate, disseminate, or disclose the information, in whole or in part, to any other person or organization except as necessary to perform the work under this contract. The contractor agrees to return the information to the Commission or otherwise dispose of it at the direction of the contracting officer. Failure to comply with this clause is grounds for termination of this contract.
(d) Regulations. The contractor agrees to conform to all security regulations and requirements of the Commission which are subject to change as directed by the NRC Division of Facilities and Security and the Contracting Officer. These changes will be under the authority of the FAR Changes clause referenced in Section I of this document.
(e) Definition of National Security Information. As used in this clause, the term National Security Information means information that has been determined pursuant to Executive Order 12958 or any predecessor order to require protection against unauthorized disclosure and that is so designated.
(f) Definition of Restricted Data. As used in this clause, the term Restricted Data means all data concerning design, manufacture, or utilization of atomic weapons; the production of special nuclear material; or the use of special nuclear material in the production of energy, but does not include data declassified or removed from the Restricted Data category under to Section 142 of the Atomic Energy Act of 1954, as amended.
(g) Definition of Formerly Restricted Data. As used in this clause the term Formerly Restricted Data means all data removed from the Restricted Data category under Section 142-d of the Atomic Energy Act of 1954, as amended.
(h) Security clearance personnel. The contractor may not permit any individual to have access to Restricted Data, Formerly Restricted Data, or other classified information, except in accordance with the Atomic Energy Act of 1954, as amended, and the Commission's regulations or requirements applicable to the particular type or category of classified information to which access is required. The contractor shall also execute a Standard Form 312, Classified Information Nondisclosure Agreement, when access to classified information is required.
(i) Criminal liabilities. Disclosure of National Security Information, Restricted Data, and Formerly Restricted Data relating to the work or services ordered hereunder to any person not entitled to receive it, or failure to safeguard any Restricted Data, Formerly Restricted Data, or any other classified matter that may come to the contractor or any person under the contractor's control in connection with work under this contract, may
31310020D0007/31310023F0047 Page 24 the proposal or initially anticipated, the contractor shall immediately notify the contracting officer and shall, subject to the concurrence of the contracting officer, promptly replace the personnel with personnel of at least substantially equal ability and qualifications.
(c) Each request for approval of substitutions must be in writing and contain a detailed explanation of the circumstances necessitating the proposed substitutions. The request must also contain a complete resume for the proposed substitute and other information requested or needed by the contracting officer to evaluate the proposed substitution.
The contracting officer and the project officer shall evaluate the contractor's request and the contracting officer shall promptly notify the contractor of his or her decision in writing.
(d) If the contracting officer determines that suitable and timely replacement of key personnel who have been reassigned, terminated, or have otherwise become unavailable for the contract work is not reasonably forthcoming, or that the resultant reduction of productive effort would be so substantial as to impair the successful completion of the contract or the service order, the contract may be terminated by the contracting officer for default or for the convenience of the Government, as appropriate.
If the contracting officer finds the contractor at fault for the condition, the contract price or fixed fee may be equitably adjusted downward to compensate the Government for any resultant delay, loss, or damage.
(End of Clause)
31310020D0007/31310023F0047 Page 25 I - Contract Clauses NRCAR Clauses Incorporated By Full Text I.1 2052.209-72 CONTRACTOR ORGANIZATIONAL CONFLICTS OF INTEREST. (JAN 1993)
(a) Purpose. The primary purpose of this clause is to aid in ensuring that the contractor:
(1) Is not placed in a conflicting role because of current or planned interests (financial, contractual, organizational, or otherwise) which relate to the work under this contract; and (2) Does not obtain an unfair competitive advantage over other parties by virtue of its performance of this contract.
(b) Scope. The restrictions described apply to performance or participation by the contractor, as defined in 48 CFR 2009.570-2 in the activities covered by this clause.
(c) Work for others.
(1) Notwithstanding any other provision of this contract, during the term of this contract, the contractor agrees to forego entering into consulting or other contractual arrangements with any firm or organization the result of which may give rise to a conflict of interest with respect to the work being performed under this contract. The contractor shall ensure that all employees under this contract abide by the provision of this clause. If the contractor has reason to believe, with respect to itself or any employee, that any proposed consultant or other contractual arrangement with any firm or organization may involve a potential conflict of interest, the contractor shall obtain the written approval of the contracting officer before the execution of such contractual arrangement.
(2) The contractor may not represent, assist, or otherwise support an NRC licensee or applicant undergoing an NRC audit, inspection, or review where the activities that are the subject of the audit, inspection, or review are the same as or substantially similar to the services within the scope of this contract (or task order as appropriate) except where the NRC licensee or applicant requires the contractor's support to explain or defend the contractor's prior work for the utility or other entity which NRC questions.
(3) When the contractor performs work for the NRC under this contract at any NRC licensee or applicant site, the contractor shall neither solicit nor perform work in the same or similar technical area for that licensee or applicant organization for a period commencing with the award of the task order or beginning of work on the site (if not a task order contract) and ending one year after completion of all work under the associated task order, or last time at the site (if not a task order contract).
(4) When the contractor performs work for the NRC under this contract at any NRC licensee or applicant site,
31310020D0007/31310023F0047 Page 26 (i) The contractor may not solicit work at that site for that licensee or applicant during the period of performance of the task order or the contract, as appropriate.
(ii) The contractor may not perform work at that site for that licensee or applicant during the period of performance of the task order or the contract, as appropriate, and for one year thereafter.
(iii) Notwithstanding the foregoing, the contracting officer may authorize the contractor to solicit or perform this type of work (except work in the same or similar technical area) if the contracting officer determines that the situation will not pose a potential for technical bias or unfair competitive advantage.
(d) Disclosure after award.
(1) The contractor warrants that to the best of its knowledge and belief, and except as otherwise set forth in this contract, that it does not have any organizational conflicts of interest as defined in 48 CFR 2009.570-2.
(2) The contractor agrees that if, after award, it discovers organizational conflicts of interest with respect to this contract, it shall make an immediate and full disclosure in writing to the contracting officer. This statement must include a description of the action which the contractor has taken or proposes to take to avoid or mitigate such conflicts. The NRC may, however, terminate the contract if termination is in the best interest of the Government.
(3) It is recognized that the scope of work of a task-order-type contract necessarily encompasses a broad spectrum of activities. Consequently, if this is a task-order-type contract, the contractor agrees that it will disclose all proposed new work involving NRC licensees or applicants which comes within the scope of work of the underlying contract. Further, if this contract involves work at a licensee or applicant site, the contractor agrees to exercise diligence to discover and disclose any new work at that licensee or applicant site. This disclosure must be made before the submission of a bid or proposal to the utility or other regulated entity and must be received by the NRC at least 15 days before the proposed award date in any event, unless a written justification demonstrating urgency and due diligence to discover and disclose is provided by the contractor and approved by the contracting officer. The disclosure must include the statement of work, the dollar value of the proposed contract, and any other documents that are needed to fully describe the proposed work for the regulated utility or other regulated entity. NRC may deny approval of the disclosed work only when the NRC has issued a task order which includes the technical area and, if site-specific, the site, or has plans to issue a task order which includes the technical area and, if site-specific, the site, or when the work violates paragraphs (c)(2), (c)(3) or (c)(4) of this section.
(e) Access to and use of information.
31310020D0007/31310023F0047 Page 27 (1) If, in the performance of this contract, the contractor obtains access to information, such as NRC plans, policies, reports, studies, financial plans, internal data protected by the Privacy Act of 1974 (5 U.S.C. Section 552a (1988)), or the Freedom of Information Act (5 U.S.C. Section 552 (1986)), the contractor agrees not to:
(i) Use this information for any private purpose until the information has been released to the public; (ii) Compete for work for the Commission based on the information for a period of six months after either the completion of this contract or the release of the information to the public, whichever is first; (iii) Submit an unsolicited proposal to the Government based on the information until one year after the release of the information to the public; or (iv) Release the information without prior written approval by the contracting officer unless the information has previously been released to the public by the NRC.
(2) In addition, the contractor agrees that, to the extent it receives or is given access to proprietary data, data protected by the Privacy Act of 1974 (5 U.S.C.
Section 552a (1988)), or the Freedom of Information Act (5 U.S.C. Section 552 (1986)), or other confidential or privileged technical, business, or financial information under this contract, the contractor shall treat the information in accordance with restrictions placed on use of the information.
(3) Subject to patent and security provisions of this contract, the contractor shall have the right to use technical data it produces under this contract for private purposes provided that all requirements of this contract have been met.
(f) Subcontracts. Except as provided in 48 CFR 2009.570-2, the contractor shall include this clause, including this paragraph, in subcontracts of any tier. The terms contract, contractor, and contracting officer, must be appropriately modified to preserve the Government's rights.
(g) Remedies. For breach of any of the above restrictions, or for intentional nondisclosure or misrepresentation of any relevant interest required to be disclosed concerning this contract or for such erroneous representations that necessarily imply bad faith, the Government may terminate the contract for default, disqualify the contractor from subsequent contractual efforts, and pursue other remedies permitted by law or this contract.
(h) Waiver. A request for waiver under this clause must be directed in writing to the contracting officer in accordance with the procedures outlined in 48 CFR 2009.570-9.
(i) Follow-on effort. The contractor shall be ineligible to participate in NRC contracts, subcontracts, or proposals therefor (solicited or unsolicited) which stem directly from the contractor's performance of work under this contract. Furthermore, unless so directed in writing by the contracting officer, the contractor may not perform any technical consulting
31310020D0007/31310023F0047 Page 28 or management support services work or evaluation activities under this contract on any of its products or services or the products or services of another firm if the contractor has been substantially involved in the development or marketing of the products or services.
(1) If the contractor under this contract, prepares a complete or essentially complete statement of work or specifications, the contractor is not eligible to perform or participate in the initial contractual effort which is based on the statement of work or specifications. The contractor may not incorporate its products or services in the statement of work or specifications unless so directed in writing by the contracting officer, in which case the restrictions in this paragraph do not apply.
(2) Nothing in this paragraph precludes the contractor from offering or selling its standard commercial items to the Government.
(End of Clause)
FAR Clauses Incorporated By Full Text I.2 52.227-17 RIGHTS IN DATA--SPECIAL WORKS. (DEC 2007)
(a) Definitions. As used in this clause--
Data means recorded information, regardless of form or the media on which it may be recorded.
The term includes technical data and computer software. The term does not include information incidental to contract administration, such as financial, administrative, cost or pricing, or management information.
Unlimited rights means the rights of the Government to use, disclose, reproduce, prepare derivative works, distribute copies to the public, and perform publicly and display publicly, in any manner and for any purpose, and to have or permit others to do so.
(b) Allocation of Rights. (1) The Government shall have--
(i) Unlimited rights in all data delivered under this contract, and in all data first produced in the performance of this contract, except as provided in paragraph (c) of this clause.
(ii) The right to limit assertion of copyright in data first produced in the performance of this contract, and to obtain assignment of copyright in that data, in accordance with paragraph (c)(1) of this clause.
(iii) The right to limit the release and use of certain data in accordance with paragraph (d) of this clause.
(2) The Contractor shall have, to the extent permission is granted in accordance with paragraph (c)(1) of this clause, the right to assert claim to copyright subsisting in data first produced in the performance of this contract.
(c) Copyright--(1) Data first produced in the performance of this contract. (i) The Contractor shall not assert or authorize others to assert any claim to copyright subsisting
31310020D0007/31310023F0047 Page 29 in any data first produced in the performance of this contract without prior written permission of the Contracting Officer. When copyright is asserted, the Contractor shall affix the appropriate copyright notice of 17 U.S.C. 401 or 402 and acknowledgment of Government sponsorship (including contract number) to the data when delivered to the Government, as well as when the data are published or deposited for registration as a published work in the U.S. Copyright Office. The Contractor grants to the Government, and others acting on its behalf, a paid-up, nonexclusive, irrevocable, worldwide license for all delivered data to reproduce, prepare derivative works, distribute copies to the public, and perform publicly and display publicly, by or on behalf of the Government.
(ii) If the Government desires to obtain copyright in data first produced in the performance of this contract and permission has not been granted as set forth in paragraph (c)(1)(i) of this clause, the Contracting Officer shall direct the Contractor to assign (with or without registration), or obtain the assignment of, the copyright to the Government or its designated assignee.
(2) Data not first produced in the performance of this contract. The Contractor shall not, without prior written permission of the Contracting Officer, incorporate in data delivered under this contract any data not first produced in the performance of this contract and that contain the copyright notice of 17 U.S.C.
401 or 402, unless the Contractor identifies such data and grants to the Government, or acquires on its behalf, a license of the same scope as set forth in paragraph (c)(1) of this clause.
(d) Release and use restrictions. Except as otherwise specifically provided for in this contract, the Contractor shall not use, release, reproduce, distribute, or publish any data first produced in the performance of this contract, nor authorize others to do so, without written permission of the Contracting Officer.
(e) Removed.
(End of clause)
31310020D0007/31310023F0047 Page 30 J - List of Documents, Exhibits and Other Attachments Attachment Number Title Document Version Date Number of Pages 1
Attachment No. 1: Statement of Work - Contractor Support for the PARCS Code Suite BASE 05/02/2023 40 2
Attachment No. 2: Statement of Work -
Attachment A: TRACE Standard Programming Practices BASE 05/02/2023 6
3 Attachment No. 3: Statement of Work -
Attachment B: TRACE Special Requirements BASE 05/02/2023 2
4 Attachment No. 4: SOW Reference 1 - F6028 -
Task 1 Letter Report BASE 05/02/2023 23 5
Attachment No. 5: SOW Reference 2 - F6028 -
Task 2 Letter Report BASE 05/02/2023 33 6
Attachment No. 6: SOW Reference 3 - F6028 -
Task 3 Letter Report BASE 05/02/2023 18 7
Attachment No. 7: Subpart 2009.5 Organizational Conflicts of Interest BASE 05/02/2023 8
8 Attachment No. 8: NRC Form 187 - CONTRACT SECURITY AND/OR CLASSIFICATION REQUIREMENTS BASE 05/02/2023 4
31310020D0007 / 31310023F0047 Attachment No. 1 1
TASK ORDER STATEMENT OF WORK
- 1. PROJECT TITLE Contractor Support for the PARCS1 Code Suite
- 2. BACKGROUND 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 SCALE2, PARCS, and TRACE3. 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. 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) and other guidance such as the NuScale Design Specific Review Standard (DSRS) departures from NUREG-0800 (Docket: NRC-2015-0160) and guidance for developing design criteria for non-light-water reactors (Regulatory Guide (RG) 1.232)
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 codified into a process that is described in both NUREG/CR-5249, Quantifying Reactor Safety Margins and RG 1.203, Transient and Accident Analysis Methods.
The support for the NRCs EM development from the Office of Nuclear Regulatory Research (RES), Division of Systems Analysis (DSA) is ongoing. Recently, this support has been programmatically codified in terms of technical assistance requests (user needs) from the program offices including the Office of Nuclear Reactor Regulation (NRR) and, formally, the Office of New Reactors (NRO). User needs entail the development of TRACE/PARCS and PARCS models and documentation that support 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.
1 PARCS is an acronym for Purdue Advanced Reactor Core Simulator.
2 SCALE stands for Standardized Computer Analyses for Licensing Evaluation.
3 TRACE is an acronym for TRAC (Transient Reactor Analysis Code) RELAP (Reactor Excursion and Leak Analysis Program) Advanced Computational Engine.
31310020D0007 / 31310023F0047 Attachment No. 1 2
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 PATHS 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.
GenPMAXS4 provides the key interface between PARCS and the following lattice physics codes: CASMO, HELIOS, SCALE/TRITON, SCALE/Polaris, WIMS, CONDOR, and Serpent.
GenPMAXS also provides the cross-section processing interface for conversion into the PARCS format from lattice physics data. In addition to converting lattice physics-averaged cross sections, GenPMAXS analytically solves for the flux discontinuity along the fuel reflector interface.
The PARCS source code consists of the coding residing within the contractor-maintained, standalone PARCS distribution, the PARCS coding residing within the TRACE/PARCS distribution, and the PARCS coding residing within the RELAP/PARCS distribution. PARCS was also fully coupled with the PATHS5 steady-state thermal-hydraulic solver in version v32m03, and all references to PARCS in this document shall refer to the post-v32m03 PARCS versions that have been coupled with PATHS (PARCS/PATHS).
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).
- 3. PROJECT DESCRIPTION AND OBJECTIVE(S)
The objective of this acquisition is to obtain regulatory technical support with the maintenance, code support, assessment, development, and user training of the PARCS/PATHS and GenPMAXS codes and the interface of PARCS with RELAP, TRACE, and SNAP. 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.
- 4. SCOPE OF WORK/TASKS The contractor shall provide all resources necessary to accomplish the tasks and deliverables described in this SOW. The contractors key staff must have the ability to handle and have prior experience with proprietary information. The contractors key staff should also be able to handle Export Controlled Information (ECI) (i.e., be U.S. citizens or permanent residents). 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 and RELAP; PATHS, and the GenPMAXS code).
4 GenPMAXS is the code for Generating the cross-section interface file PMAXS.
5 PATHS is an acronym for PARCS Advanced Thermal Hydraulic Solver.
31310020D0007 / 31310023F0047 Attachment No. 1 3
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; fast reactors; and VVERs (water water energy reactors). During the course of this contract, the contractor may be required to apply PARCS/PATHS expertise to other advanced reactor designs, as directed by the Contracting Officers Representative (COR).
Unless directed by the COR, all new PARCS/PATHS, TRACE, and GenPMAXS code changes shall be consistent with Attachment A (TRACE Standard F90 Programming Practices).
PARCS/PATHS and GenPMAXS code changes shall be tested on a variety of compiler/operating system combinations. The following compilers shall be used during maintenance and development of the PARCS/PATHS source code:
Windows (Microsoft Visual Studio (MSVS)/Intel Visual Fortran)
Linux (gfortran; Intel; NAG; and choice of either Portland Group (PGFORTRAN);
Absoft Pro Fortran; or Pathscale Compiler Suite)
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 COR may require the contractor to extend support to other compiler/operating system combinations that are not listed as a result of changing priorities.
The contractor shall perform the tasks listed below. All activities under these tasks shall be prioritized by the COR through technical direction.
Task 1 - PARCS/PATHS Code Maintenance Subtask 1.1: Maintain PARCS/PATHS in a Version Control System The contractor shall maintain PARCS/PATHS in a version control system, with 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 build scripts, and source), the test suite (test problems and run scripts), and the code documentation. The PARCS/PATHS code documentation shall be maintained within the LaTeX(lua)/python-based code documentation system, and it shall include the PARCS Input, Theory, User Guide, Programmers, and MAPTAB manuals; the PATHS Input and Theory manuals; the Documentation Guide; the PARCS Input Manual To-Do List; the PATHS Input Manual To-Do List; the supporting documentation build scripts; and the supporting references.
Previous code distributions will be provided to the contractor by the COR at time of contract award.
Deliverable One for Subtask 1.1: Collective list of names of all PARCS/PATHS developmental versions (with a brief description) and the name of the latest PARCS/PATHS release
31310020D0007 / 31310023F0047 Attachment No. 1 4
On a monthly basis, the contractor shall include a list of all PARCS/PATHS developmental versions that have been branched off the trunk, and that have not yet been finalized and checked back into the trunk over the previous month. With each member of the list the contractor shall provide a matching, brief description of the capability, feature, or bug that the developmental version was branched to address. The contractor shall also append to this list the name of the latest official PARCS/PATHS release version. This list shall be delivered under Task 1.1 in the MLSR. If there are no active developmental PARCS/PATHS versions for the reporting month, then this should be stated in the MLSR under Task 1.1.
Deliverable Two for Subtask 1.1: Checkout and re-build the latest PARCS/PATHS release from the version control system On a monthly basis, the contractor shall checkout the latest PARCS/PATHS release-version from the version control system (named in Deliverable One) and: re-build all the LaTeX-edited documentation; re-build a release-level Linux binary; re-build a release-level Windows executable; and deliver the entire distribution electronically to the COR on the same date as the MLSR. The contractor shall re-build the documentation, executables, and binaries within the previous 5 days of delivery. The contractor shall deliver the distribution electronically either through the GitHub IaaS [Infrastructure as a Service] Enterprise, through the TRACE website, through Box, or through any other means as specified by the COR.
Deliverable Three for Subtask 1.1: Execute the test suite corresponding to the latest PARCS/PATHS release-version On a monthly basis, the contractor shall execute the test suite that corresponds to the checked-out PARCS/PATHS release version in Deliverable Two. The contractor shall execute this test suite with both the release-build Linux binary and with the release-build Windows executable and shall electronically deliver the output directory results monthly, on the same date as the MLSR. The contractor shall have executed the test suites within the previous 5 days of submittal. The contractor shall deliver the output directory results electronically either through the GitHub IaaS [Infrastructure as a Service] Enterprise, through the TRACE website, through Box, or through any other means specified by the COR.
Subtask 1.2: Identify Code Bugs The contractor shall either maintain a system for reporting and storing PARCS/PATHS/GenPMAXS bugs or have access to such a bug reporting system (i.e.,
through another entitys software or service). The bug report shall have fields which summarize code errors and bugs (feature requests, unexplained behavior, and documentation problems). This system shall match a bug number with the following information for each bug: a summary description of the bug; the date the bug was reported; the user or organization who reported the bug; and the status of the bug (i.e., in what code version the bug was discovered).
The bug reporting system shall be accessible by PARCS/PATHS code users (i.e., the PARCS/PATHS code developers, the COR, other NRC staff, national labs, contractors, code users from the international community (CAMP), and other PARCS/PATHS users within the Thermal-Hydraulics User Group).
31310020D0007 / 31310023F0047 Attachment No. 1 5
Deliverable for Subtask 1.2: Bug Report A list of new, reported bugs (if these exist) shall be delivered with the monthly letter status report (MLSR).
Subtask 1.3: Perform Code Fixes Under COR technical direction, the contractor shall make changes to the collective PARCS/PATHS source code in response to bugs reported by the COR and all other PARCS/PATHS users, as captured in the bug report under Subtask 1.2. Work shall be performed in accordance with priorities indicated in the Bug Report, as approved by the COR.
PARCS/PATHS 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/TRITON, SCALE/Polaris, HELIOS, CASMO, WIMS, CONDOR, and Serpent) that are readable by GenPMAXS.
Upon COR direction, the contractor shall also update the LaTeX(lua)/python-based code documentation system (the PARCS Input, Theory, User Guide, Programmers, and MAPTAB manuals; the PATHS Input and Theory manuals; the Documentation Guide; the PARCS Input Manual To-Do List; the PATHS Input Manual To-Do List; the supporting scripts; and the references) 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.
Any PARCS/PATHS source code changes made as a result of code bugs shall be tested against the PARCS regression test suite before being checked into the code version control system. New test problems that are added to the PARCS/PATHS 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/PATHS in response to code bug corrections. These different code versions shall be maintained 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 directory) shall contain the following: the source code and associated libraries; operating system specific build scripts and MSVS project workspaces for re-building the executable from the source 6 SNAP is an acronym for Symbolic Nuclear Analysis Package
31310020D0007 / 31310023F0047 Attachment No. 1 6
code; code documentation folder, which shall include directories that contain code differences by version (Fortran source code differences with respect to the previous version) and the code version documentation; the PARCS/PATHS 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 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; summaries of the code differences for each changed or new module; changes to the code 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.3: PARCS/PATHS Code Distribution to COR Each checked-in code version shall be sent as a PARCS/PATHS distribution to the COR.
The distribution shall be transmitted electronically either through the GitHub IaaS
[Infrastructure as a Service] Enterprise, through the TRACE website, through Box, or through any other means specified by the COR). The contractor shall provide the PARCS/PATHS distribution to the COR within 5 business days of the check-in of the PARCS/PATHS code version.
Subtask 1.4: Prepare TRACE Updates At a frequency determined by the COR (i.e., after a number of PARCS/PATHS versions have been checked-in to the PARCS/PATHS version control system), the contractor shall prepare a TRACE update. 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 coupled test problems formulated to test the code update, revised PARCS code documentation (if changed), and the results of automated testing against the TRACE regression suite.
The contractor shall use the TRACE regression testing framework to test and organize the associated PARCS update to TRACE. This test framework is a collection of python scripts, Perl scripts, test problems, text templates, TRACE code versions, and organized directories.
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 or new 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.4: TRACE Update Distribution
31310020D0007 / 31310023F0047 Attachment No. 1 7
The update shall be archived and submitted to the TRACE website, or else archived with SecureZip and transmitted electronically either through the GitHub IaaS [Infrastructure as a Service] Enterprise, through Box, or through any other electronic means specified by the COR within 15 business days of COR request.
Task 2 - PARCS/PATHS Code Support As directed by the COR, the contractor shall provide analysis and consultation support related to PARCS/PATHS and GenPMAXS.
This support shall include, but is not limited to:
- guidance on PARCS, PATHS, or GenPMAXS use
- explanations of the algorithms that are coded into PARCS, PATHS, or GenPMAXS
- development of PARCS, PATHS, GenPMAXS, TRACE/PARCS, RELAP/PARCS models
- interpretation of results, or explanations regarding underlying physics phenomena or algorithms
- explanations of the input format
- guidance on best-practices (how to approach a problem)
- support 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, 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, email, or input deck) to the COR via email within 10 business days of the COR request.
Task 3 - PARCS/PATHS Code Development Upon COR direction and prioritization, the contractor shall perform any PARCS/PATHS 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/PATHS code use. Upon direction of the COR, there may be several discrete code development efforts undertaken under Task 3 (Task 3-1, Task 3-2, etc.), along with the matching deliverables for each code development effort.
31310020D0007 / 31310023F0047 Attachment No. 1 8
Any PARCS/PATHS source code changes made as a result of code enhancements or modeling changes shall be tested against the PARCS/PATHS 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.
Upon COR direction, the contractor shall also update the LaTeX(lua)/python-based code documentation system (the PARCS Input, Theory, User Guide, Programmers, and MAPTAB manuals; the PATHS Input and manuals; the Documentation Guide; the PARCS Input Manual To-Do List; the PATHS Input Manual To-Do List; the supporting scripts; and the references) 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)/Qualification Test Plan (QTP)
(referred to as the test plan in NUREG-1737)
The SDID/QTP is a combined document that describes the implementation of the technical specifications and algorithms outlined in the SRS, i.e., how the software will be structured and designed, and also describes how the implemented capabilities are proposed to be tested, i.e. the test problems which will be used to demonstrate the new capability.
These documents shall be provided 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 SRS shall be delivered within 40 business days after Subtask 3.1 commencement.
Deliverable Two for Subtask 3.1: Software Design and Implementation Document/Qualification Test Plan (SDID/QTP)
The SDID/QTP shall be delivered within 60 business days after Subtask 3.1 commencement.
Subtask 3.2: Perform Code Development The contractor shall implement the method outlined in the SRS and SDID/QTP into the latest stable PARCS/PATHS version. It is expected that the COR and other NRC staff will peer review and test this draft distribution, and that the contractor shall make changes to the
31310020D0007 / 31310023F0047 Attachment No. 1 9
draft code distribution (i.e., source code, build scripts, test problems, code documentation (as applicable), etc.) as a result of this peer review.
Deliverable One for Subtask 3.2: Beta PARCS/PATHS Distribution The contractor shall provide the first PARCS/PATHS test version to the COR, along with beta source code, beta test problems, and draft documentation, within 60 business days of Subtask 3.2 commencement. This test version shall be transmitted electronically either through the GitHub IaaS [Infrastructure as a Service] Enterprise, through the TRACE website, through Box, or through any other means specified by the COR.
Deliverable Two for Subtask 3.2: Final PARCS/PATHS Distribution The contractor shall provide to the COR the final PARCS/PATHS distribution with the implemented coding. This distribution shall be organized as described in Subtask 1.1, with the addition of final test problems to the PARCS/PATHS test suite that test the added functionality.
The final distribution shall be provided to the COR within 25 business days of the receipt of COR comments on the beta distribution. The distribution shall be transmitted electronically either through the GitHub IaaS [Infrastructure as a Service] Enterprise, through the TRACE website, through Box, or through any other means specified by the COR.
Subtask 3.3: 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.3: Completion Report A completion report shall be delivered to the COR within 30 business days of the completion of the programming effort.
Subtask 3.4: Prepare TRACE Updates To incorporate the applicable PARCS development changes into the TRACE trunk, a TRACE update shall be prepared by the contractor, and shall be organized as described in Subtask 1.4.
Deliverable for Subtask 3.4: TRACE Update Distribution The update shall be archived and submitted to the TRACE website, or else archived with SecureZip and transmitted electronically either through the GitHub IaaS [Infrastructure as a Service] Enterprise, through Box, or through any other electronic means specified by the COR within 15 business days of COR request.
Task 4 - GenPMAXS Code Support and Maintenance
31310020D0007 / 31310023F0047 Attachment No. 1 10 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 build scripts, 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.
Deliverable One for Subtask 4.1: Collective list of names of all GenPMAXS developmental versions (with a brief description) and the name of the latest GenPMAXS release On a monthly basis, the contractor shall include a list of all GenPMAXS developmental versions that have been branched off the trunk, and that have not yet been finalized and checked back into the trunk over the previous month. With each member of the list the contractor shall provide a matching, brief description of the capability, feature, or bug that the developmental version was branched to address. The contractor shall also append to this list the name of the latest official GenPMAXS release version. This list shall be delivered under Task 4.1 in the MLSR. If there are no active developmental GenPMAXS versions for the reporting month, then this should be stated in the MLSR under Task 4.1.
Deliverable Two for Subtask 4.1: Checkout and re-build the latest GenPMAXS release from the version control system On a monthly basis, the contractor shall checkout the latest GenPMAXS release-version from the version control system (named in Deliverable One) and: re-build a release-level Linux binary; re-build a release-level Windows executable; and deliver the entire distribution electronically to the COR on the same date as the MLSR. The contractor shall re-build the executables and binaries within the previous 5 days of delivery. The contractor shall deliver the distribution electronically either through the GitHub IaaS [Infrastructure as a Service]
Enterprise, through the TRACE website, through Box, or through any other means as specified by the COR.
Deliverable Three for Subtask 4.1: Execute the test suite corresponding to the latest GenPMAXS release-version On a monthly basis, the contractor shall execute the test suite that corresponds to the checked-out GenPMAXS release version in Deliverable Two. The contractor shall execute this test suite with both the release-build Linux binary and with the release-build Windows executable and shall electronically deliver the output directory results monthly, on the same date as the MLSR. The contractor shall have executed the test suites within the previous 5 days of submittal. The contractor shall deliver the output directory results electronically either through the GitHub IaaS [Infrastructure as a Service] Enterprise, through the TRACE website, through Box, or through any other means specified by the COR.
31310020D0007 / 31310023F0047 Attachment No. 1 11 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. The contractor will be expected to update the test suite with additional input decks that test the resolution of bugs or requested features.
Deliverable for Subtask 4.2: Bug Report A list of new, reported bugs (if these exist) shall be delivered with the monthly letter status report (MLSR).
Subtask 4.3: Update GenPMAXS Source Code If necessary, 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 Perl-based SCALE/GenPMAXS regression testing system (described in Task 10).
This testing system will be provided to the contractor at time of contract award.
Deliverable for Subtask 4.3: GenPMAXS Distribution to COR Each checked-in code version shall be sent 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 transmitted electronically either through the GitHub IaaS [Infrastructure as a Service] Enterprise, through the TRACE website, through Box, or through any other means specified by the COR),, within 5 business days after checking in the GenPMAXS version.
Task 5 - PARCS/PATHS and GenPMAXS User Training The contractor shall provide two training sessions that each encompass training on both PARCS/PATHS and GenPMAXS. The training sessions shall each be no more than two days 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/PATHS training sessions, as provided by 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.
On COR direction, the contractor shall update the training materials with revised example problems and models that demonstrate enhanced features and use cases for PARCS/PATHS and GenPMAXS users. This training shall include instruction on PARCS/PATHS and GenPMAXS theory and use, including example problems and instruction on code execution, and shall be provided as instructor led training to audiences
31310020D0007 / 31310023F0047 Attachment No. 1 12 of no more than 50 participants in each session. The training materials (presentations and models/exercises) shall be updated, and the training material delivered, with the aim to accomplish the following set of objectives (outlined below). These are objectives that training participants will be expected to demonstrate by instructor and/or COR observation and discussion by the end of the training:
Primary Goal(s): To learn how to convert existing SCALE/TRITON and SCALE/Polaris cross section sets into PMAXS format with GenPMAXS; to learn how to run PARCS for core critical situations with no thermal-hydraulic (T-H) feedback; to learn how to run PARCS/PATHS (and also with the internal T-H solver) with T-H feedback for nominal LWR fuel cycle, depletion simulations (inter-cycle and intra-cycle), with consideration for fuel shuffling between cycles; and to learn how to run PARCS for a subset of LWR plant transients (PWR main steam line break, PWR/BWR control rod withdrawal, BWR turbine trip, and BWR instability)
Enabling Goal(s): To locate within the supporting PARCS/PATHS/GenPMAXS theory manuals the underlying theory and concepts that support an understanding of PARCS model development for situations listed in the primary goals; to locate within the supporting PARCS/PATHS/GenPMAXS user manuals and guidance manuals the code inputs necessary to activate the modeling scenarios outlined under Primary Goal(s).
Supporting Programmatic Goal(s): To solicit feedback on PARCS/PATHS/GenPMAXS capabilities and usability; to engage with potential PARCS/PATHS/GenPMAXS users at the NRC on desired features and use cases; and to spot potential bugs and misunderstandings that a PARCS/PATHS/GenPMAXS user may potentially encounter with post-training model development activities.
Miscellaneous Goal(s): To learn about PARCS capabilities (underlying theory and usage) with respect to modeling Sodium Fast Reactors (SFRs), VVERs, HTGRs, and MSRs Deliverable One for Task 5: Draft PARCS/PATHS/GenPMAXS Training Materials The contractor shall provide the revised PARCS/PATHS/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 20 business days prior to training. These training materials will be retained by the NRC for both internal and external use after the end of the POP. The NRC will store the training materials (including recordings) for use by staff (internal). Outside of the POP, the training materials will also be the basis for other trainings to be delivered to PARCS/PATHS/GenPMAXS users external to the NRC.
Deliverable Two for Task 5: Final PARCS/PATHS/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.
Deliverable Three for Task 5: Deliver First PARCS/PATHS/GenPMAXS Training Session The contractor shall deliver the first training to NRC staff at NRC HQ, either virtually or in-person, before the end of the second accumulated year of the POP.
31310020D0007 / 31310023F0047 Attachment No. 1 13 Deliverable Four for Task 5: Recording of the First PARCS/PATHS/GenPMAXS Training Session The contractor shall consent to video recording the training delivery in a format that is transferrable to Microsoft Stream or Microsoft SharePoint (*.mp4 is an example format). If training is delivered remotely, the recording shall be transferred to the COR within one month of the first trainings conclusion.
Deliverable Five for Task 5: Deliver Second PARCS/PATHS/GenPMAXS Training Session The contractor shall deliver the second training to NRC staff at NRC HQ, either virtually or in-person, before the end of the fourth accumulated year of the POP..
Deliverable Six for Task 5: Recording of the Second PARCS/PATHS/GenPMAXS Training Session The contractor shall consent to video recording the training delivery in a format that is transferrable to Microsoft Stream or Microsoft Sharepoint (*.mp4 is an example format). If training is delivered remotely, the recording shall be transferred to the COR within one month of the second trainings conclusion.
Task 6 - Support for Ongoing and Emergent Accident Tolerant Fuel (ATF)/High Burnup (HB)/Extended Enrichment (EE)/(HALEU) Confirmatory Research Efforts The purpose of this task is to support the Oak Ridge National Laboratory (ORNL) and NRC staff in efforts to evaluate the SCALE(Polaris)/GenPMAXS/PARCS/PATHS code sequence for fuel cycles loaded with ATF/HB/HALEU fuel assemblies (ATF-Accident Tolerant Fuel; HB-High Burnup; HALEU - High Assay Low Enriched Uranium). This support would span ongoing and emergent code maintenance, development, and activities and will require knowledge of the underlying algorithms and numerics of PARCS/PATHS and GenPMAXS.
ORNL is currently comparing the predictions of SCALE and PARCS/PATHS against higher-fidelity predictions, with PARCS/PATHS predictions of core-level physics parameters (kinf/keff, moderator temperature coefficient, differential boron worth, control rod worth, fuel/Doppler temperature coefficient, etc.) of cores that are loaded with ATF/HB/HALEU fuel.
ORNL needs ongoing technical support in diagnosing and interpreting input formats, in interpreting PARCS/PATHS predictions, and also in developing ATF/HB/HALEU specific code fixes and features (maintenance and development) in response to assessment against higher-fidelity models.
NRC staff and contractors will also need support in developing confirmatory models for anticipated licensing actions involving ATF/HB/HALEU fuel. For this reason, as confirmatory models are developed, NRC staff and contractors will need contractor support in developing potential methodology recommendations for ATF/HB/HALEU concepts (cross-section case matrix, radial fuel mesh refinement, or Doppler fuel temperature weighing scheme, for example).
The contractor shall support the ATF/HB/HALEU effort through user guidance, methodology recommendations, and the update of the PARCS/PATHS or GenPMAXS source code as a
31310020D0007 / 31310023F0047 Attachment No. 1 14 result code bug corrections or requested development features, consistent with the effort described in Tasks 1 through 4 and Task 10.
Deliverable for Task 6: The contractor shall provide high level description of activities and resources related to the ATF/HB/HALEU effort that are going towards Tasks 1-4 and Task
- 10. This summary shall reference any technical reports or publications authored/co-authored by the contractor that describe more detailed progress.
The contractor shall deliver this estimate (summarized in Task 6) with the MLSR on the 20th of every month.
Task 7 - Development and Implementation of a Node-Quadrant-Based (2X2) Sub-Grid Exposure Method PARCS/PATHS currently depletes node-wise and consequently produces edits of exposure and history per node. The purpose of this task is for the contractor to develop and implement a quadrant-based (2X2), sub-grid exposure and history method into the Cartesian neutronic mesh solvers of PARCS/PATHS.
The new quadrant-based exposure/history outputs shall be edited into additional depletion files that are consistent in format to the existing parcs_dep/parcs_cyc files, but of larger size to accommodate the larger amount of information. The user shall also have the option of printing edits to the expanded parcs_dep/parcs_cyc files at a specific frequency (as an input with user-requested statepoints) to control file size.
In addition, the Cartesian pin-power reconstruction method shall be augmented to incorporate both the new 2X2 sub-grid exposure method and the current nodal diffusion mesh refinement capabilities (2X2 diffusion grid with NEUTMESH_X,Y), without changing the current format of the parcs_pin file.
Subtask 7.1: Pre-Code Documentation For the quadrant-based sub-grid exposure method, the contractor shall develop an SRS and SDID/QTP, per the guidance specified in NUREG-1737 and as described in the generic code development Task 3.
Deliverable One for Subtask 7.1: Software Requirements Specification (SRS)
The SRS shall be delivered within 25 business days after Subtask 7.1 commencement.
Deliverable Two for Subtask 7.1: Software Design and Implementation Document/Qualification Test Plan (SDID/QTP)
The SDID/QTP shall be delivered within 40 business days after Subtask 7.1 commencement.
Subtask 7.2: Perform Code Development The contractor shall implement the method outlined in the SRS and SDID/QTP into the latest stable PARCS/PATHS version. It is expected that the COR and other NRC staff will peer review and test this draft distribution, and that the contractor shall make changes to the
31310020D0007 / 31310023F0047 Attachment No. 1 15 draft code distribution (i.e., source code, build scripts, test problems, code documentation (as applicable), etc.) as a result of this peer review.
Deliverable One for Subtask 7.2: Beta PARCS/PATHS Distribution The contractor shall provide the first PARCS/PATHS test version to the COR, along with beta source code, beta test problems, and draft documentation, within 40 business days of Subtask 7.2 commencement. This test version shall be transmitted electronically either through the GitHub IaaS [Infrastructure as a Service] Enterprise, through the TRACE website, through Box, or through any other means specified by the COR.
Deliverable Two for Subtask 7.2: Final PARCS/PATHS Distribution The contractor shall provide to the COR the final PARCS/PATHS distribution with the implemented coding. This distribution shall be organized as described in Subtask 1.1, with the addition of final test problems to the PARCS regression suite that exercise the added functionality.
The final distribution shall be provided to the COR within 25 business days of the receipt of COR comments on the last draft distribution. The distribution shall be transmitted electronically either through the GitHub IaaS [Infrastructure as a Service] Enterprise, through the TRACE website, through Box, or through any other means specified by the COR.
Subtask 7.3: 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, shall include calculation results that demonstrate the changed coding.
Deliverable for Subtask 7.3: Completion Report A completion report shall be delivered to the COR within 30 business days of the completion of the pin-wise burnup reconstruction programming effort.
Task 8 - Development and Implementation of a Higher Order Nodal Method to Improve Control Rod Cusping Control rod cusping refers to the artificially depressed flux that occurs with volume homogenization of a node with partially inserted control rods. To approximate the correctional nodal coupling coefficients (CNCC), PARCS currently relies on a transverse-integrated, one-dimensional finite difference formulation of the flux for the three-node problem posed by an inserted control rod (one node completely filled with control rod, one node without control rod, and one node partially filled with control rod).
The contractor shall develop or adapt a transient higher order nodal method to better approximate the CNCCs at the interfaces (upper and lower) of the partially rodded node during the nonlinear update.
Subtask 8.1: Pre-Code Documentation
31310020D0007 / 31310023F0047 Attachment No. 1 16 For the higher order control rod cusping method, the contractor shall develop an SRS and SDID/QTP, per the guidance specified in NUREG-1737 and as described in the generic code development Task 3.
Deliverable One for Subtask 8.1: Software Requirements Specification (SRS)
The SRS shall be delivered within 60 business days after Subtask 8.1 commencement.
Deliverable Two for Subtask 8.1: Software Design and Implementation Document/Qualification Test Plan (SDID/QTP)
The SDID/QTP shall be delivered within 80 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/QTP into the latest stable PARCS version. It is expected that the COR and other NRC staff will peer review and test this draft distribution, and that the contractor shall make changes to the draft code distribution (i.e., source code, build scripts, test problems, code documentation (as applicable), etc.) as a result of this peer review.
Deliverable One for Subtask 8.2: Beta PARCS Distribution The contractor shall provide the first PARCS test version to the COR, along with beta source code, beta test problems, and draft documentation, within 50 business days of Subtask 8.2 commencement. This test version shall be transmitted electronically either through the GitHub IaaS [Infrastructure as a Service] Enterprise, through the TRACE website, through Box, or through any other means specified by the COR.
Deliverable Two for Subtask 8.2: 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.1, with the addition of final test problems to the PARCS regression suite that exercise the added functionality.
The final distribution shall be provided to the COR within 25 business days of the receipt of COR comments on the last draft distribution. The distribution shall be transmitted electronically either through the GitHub IaaS [Infrastructure as a Service] Enterprise, through the TRACE website, through Box, or through any other means specified by the COR.
Subtask 8.3: 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, shall include calculation results that demonstrate the changed coding.
Deliverable for Subtask 8.3: Completion Report
31310020D0007 / 31310023F0047 Attachment No. 1 17 A completion report shall be delivered to the COR within 40 business days of the completion of the higher order control rod de-cusping programming effort.
Subtask 8.4: Prepare TRACE Updates To incorporate the applicable PARCS development changes into the TRACE trunk, a TRACE update shall be prepared by the contractor, and shall be organized as described in Subtask 1.4.
Deliverable for Subtask 8.4: TRACE Update Distribution The update shall be archived and submitted to the TRACE website, or else archived with SecureZip and transmitted electronically either through the GitHub IaaS [Infrastructure as a Service] Enterprise, through Box, or through any other electronic means specified by the COR within 20 business days of the completion of Subtask 8.3.
Task 9 - Upgrade of PARCS/PATHS Documentation The PATHS theory manual is currently maintained in MS Word and the PARCS Theory Manual is maintained with MS Word and Framemaker. The contractor shall upgrade both of these documents to Portable Document Format (pdf) with clickable links that is generated and maintained with LaTeX (lualatex)/python.
Deliverable One for Task 9: Upgraded PARCS Theory Manual The Upgraded PARCS Theory Manual shall be delivered within 70 business days of Task 9 commencement.
Deliverable Two for Task 9: Upgraded PATHS Theory Manual The Upgraded PATHS Theory Manual shall be delivered within 90 business days of Task 9 commencement.
Task 10 - Development of SCALE/Shift and SCALE/Polaris Test Problems for the GenPMAXS Perl Test Harness In order to manage the different development and testing methodologies of the SCALE and PARCS (GenPMAXS) code systems, and to catch differences in cross section calculations between them, a Perl-based regression testing harness was developed. This test harness makes use of Perls Test Anything Protocol (TAP) with interactive HTML (Hypertext Markup Language) formatters that visually illustrate differences and generate reports.
Starting from a baseline of SCALE/TRITON and corresponding GenPMAXS blessed cases (txtfile16 and PMAXS, respectively), this harness is capable of regression testing the progression of outputs for each series of file types [1], [2], and [3]. That is, txtfile16s (and PMAXSs) produced by successive SCALE/TRITON (and GenPMAXS) versions are compared to each other, txtfile16 to txtfile16 and PMAXS to PMAXS. These comparisons can be done in both fine-grained and coarse-grained mode, and the test harness completes this through a reader object for both file types. Built on top of the readers are command line
31310020D0007 / 31310023F0047 Attachment No. 1 18 utilities that enable the comparison and extraction (within user specified tolerances) of various cross section case matrix parameters.
This test harness was originally formulated to track SCALE/TRITON outputs and the associated GenPMAXS PMAXS files, based on a specific LWR test suite. This test suite is based on eight models which are categorized as either a pin cell, mini-assembly, full lattice, or fuel/reflector models, and variations of these models are expanded to 19 test cases that are ran with a specified case matrix, and with a set of lattice physics parameters that are tested.
The contractor shall develop an equivalent set of these original 19 test cases with SCALE 6.2.4/Shift and SCALE 6.2.4/Polaris and with the same PASS/FAIL criteria, convert with GenPMAXS into PMAXS files, and integrate these sets of models into the Perl test harness The contractor shall also develop several test suites of SCALE 6.2.4/Polaris input decks for ATF/HB/HALEU fuel forms that will be integrated into the Perl test harness. The input decks should be adapted from a combination of the ATF/EE/HALEU fuel lattice designs with the 19 test cases. For the HB/HALEU fuel, the contractor shall use the ORNL-stylized GE14/GNF2 BWR mechanical/nuclear lattice designs [4] and the conventional PWR 17x17 Westinghouse fuel designs (with 104 IFBA rods) that were also studied by ORNL [5].
Similarly, for the BWR and PWR ATF concepts, the contractor shall integrate the PWR (17x17 ZIRLO + Cr clad with doped fuel) and BWR (FeCrAl) lattice designs that have already been investigated by ORNL [6] into the GenPMAXS test harness.
All deliverables for Subtasks 10.1 through 10.12 shall be transmitted electronically either through the GitHub IaaS [Infrastructure as a Service] Enterprise, through the TRACE website, through Box, or through any other means specified by the COR.
Subtask 10.1: Development of SCALE/Shift Test Suite Problems Starting with the original SCALE/TRITON test problems [2], the contractor shall deliver an equivalent set of SCALE/Shift test problems. If, during the course of the model development, it becomes necessary to change model parameters, the contractor shall endeavor to approximate the models as closely as possible and summarize any deviations from the case matrix in a README text file.
Deliverable for Subtask 10.1: SCALE/Shift Test Suite (inputs and outputs) and corresponding README file that outlines test matrix.
The test suite shall be delivered within 60 business days of Subtask 10.1 commencement.
Subtask 10.2: Integration of SCALE/Shift Test Suite into Perl test harness The contractor shall use GenPMAXS to convert the SCALE/Shift txtfile16s into PMAXS files and integrate both sets of files into the Perl test harness, with the same lattice physics parameters being tested. If updates to the Perl txtfile16 and PMAXS readers are necessary, then the updated Perl readers shall be delivered with the test harness. For each test problem, the test harness shall interrogate the txtfile16s and PMAXS files according to the original, corresponding Pass/Fail criteria.
Deliverable for Subtask 10.2: Functioning Perl test harness with SCALE/Shift Test Suite
31310020D0007 / 31310023F0047 Attachment No. 1 19 The updated test suite/harness shall be delivered within 60 business days after Subtask 10.2 commencement.
Subtask 10.3: Development of SCALE/Polaris Test Suite Problems Starting with the original SCALE/TRITON test problems [2], the contractor shall deliver an equivalent set of SCALE/Polaris test problems. If, during the course of the model development, it becomes necessary to change model parameters, the contractor shall endeavor to approximate the models as closely as possible and summarize any deviations from the case matrix in a README text file.
Deliverable for Subtask 10.3: SCALE/Polaris Test Suite (inputs and outputs) and corresponding README file that outlines test matrix.
The updated test suite/harness shall be delivered within 50 business days of Subtask 10.3 commencement.
Subtask 10.4: Integration of SCALE/Polaris Test Suite into Perl test harness The contractor shall use GenPMAXS to convert the SCALE/Polaris txtfile16s into PMAXS files and integrate both sets of files into the Perl test harness, with the same lattice physics parameters being tested. If updates to the Perl txtfile16 and PMAXS readers are necessary, then those updates shall be delivered with the test harness. For each test problem, the test harness shall interrogate the txtfile16s and PMAXS files according to the original, corresponding Pass/Fail criteria.
Deliverable for Subtask 10.4: Functioning Perl test harness with SCALE/Polaris Test Suite The updated test suite/harness shall be delivered within 50 business days after Subtask 10.4 commencement.
Subtask 10.5: Development of 10 wt% 10x10 BWR HB/HALEU SCALE/Polaris Test Suite Problems The contractor shall combine the 10max-7.4av wt% DOM and the 10max-7.4av wt% VAN lattice designs of the BWR HB/HALEU study [4] with the BWR test cases (11) of the original 19 problem test suite [2], for a total of 22 test problems. This lattice is described in Reference [4], with ORNL-developed Polaris models available (https://code.ornl.gov/scale/analysis/haleu-hbu-latt-phys/-
/tree/master/bwr/section3/10 Percent).
For each test case, the 10 wt% 10x10 BWR HB/HALEU mechanical/nuclear lattice design will be combined with the original case matrix (histories and branches) of the corresponding BWR test and tested according to that tests recommended lattice physics parameters. If there is a conflict between the 10 wt% 10x10 BWR HB/HALEU lattice specifications and the original test case specifications (i.e., reference conditions, histories, depletion steps, etc.),
then the 10 wt% 10x10 BWR HB/HALEU lattice specifications described in Reference [4]
shall take precedence.
31310020D0007 / 31310023F0047 Attachment No. 1 20 Deliverable for Subtask 10.5: Functioning 10 wt% 10x10 BWR HB/HALEU SCALE/Polaris test suite of 22 models (SCALE/Polaris inputs and outputs) and corresponding README file that outlines test matrix.
This test suite shall be delivered within 30 business days of Subtask 10.5 commencement.
Subtask 10.6: Integration of 10 wt% 10x10 BWR HB/HALEU SCALE/Polaris Test Suite into Perl test harness The contractor shall use GenPMAXS to convert the 22 10 wt% 10x10 BWR HB/HALEU SCALE/Polaris txtfile16s into PMAXS files and integrate both sets of files into the Perl test harness. If updates to the Perl txtfile16 and PMAXS readers are necessary, then those updates shall be delivered with the test harness. For each test problem, the test harness shall interrogate the txtfile16s and PMAXS files according to the original, corresponding Pass/Fail criteria.
Deliverable for Subtask 10.6: Functioning Perl test harness with 10 wt% 10x10 BWR HB/HALEU SCALE/Polaris Test Suite The updated test suite/harness shall be delivered within 30 business days after Subtask 10.6 commencement.
Subtask 10.7: Development of 8wt% 17x17 PWR HB/HALEU SCALE/Polaris Test Suite Problems The contractor shall combine the 8wt% 17x17/IFBA Westinghouse lattice design of the PWR HB/HALEU study [5] with the PWR test cases (7) of the original 19 problem test suite [2], for a total of 7 test problems. This lattice is described in Reference [5], with ORNL-developed Polaris models available (https://code.ornl.gov/scale/analysis/haleu-hbu-latt-phys/-
/tree/master/pwr/section3/inputs).
For each test case, the 8wt% 17x17 PWR HB/HALEU mechanical/nuclear lattice design will be combined with the original case matrix (histories and branches) of the corresponding PWR test and tested according to that tests recommended lattice physics parameters. If there is a conflict between the 8wt% 17x17 PWR HB/HALEU lattice specifications and the original test case specifications (i.e., reference conditions, histories, depletion steps, etc.),
then the 8wt% 17x17 PWR HB/HALEU lattice specifications described in Reference [5] shall take precedence.
Deliverable for Subtask 10.7: Functioning 8wt% 17x17 PWR HB/HALEU SCALE/Polaris test suite of 7 models (SCALE/Polaris inputs and outputs) and corresponding README file that outlines test matrix.
This test suite shall be delivered within 30 business days of Subtask 10.7 commencement.
Subtask 10.8: Integration of 8wt% 17x17 PWR HB/HALEU SCALE/Polaris Test Suite into Perl test harness The contractor shall use GenPMAXS to convert the 7, 8wt% 17x17 PWR HB/HALEU SCALE/Polaris txtfile16s into PMAXS files and integrate both sets of files into the Perl test harness. If updates to the Perl txtfile16 and PMAXS readers are necessary, then those
31310020D0007 / 31310023F0047 Attachment No. 1 21 updates shall be delivered with the test harness. For each test problem, the test harness shall interrogate the txtfile16s and PMAXS files according to the original, corresponding Pass/Fail criteria.
Deliverable for Subtask 10.8: Functioning Perl test harness with 8wt% 17x17 PWR HB/HALEU SCALE/Polaris Test Suite The updated test suite/harness shall be delivered within 30 business days after Subtask 10.8 commencement.
Subtask 10.9: Development of 10 wt% 10x10 BWR FeCrAl ATF SCALE/Polaris Test Suite Problems The contractor shall combine the 10max-7.45av wt% DOM and the 10max-7.47av wt%
VAN lattice designs of the BWR FeCrAl ATF study [6] with the BWR test cases (11) of the original 19 problem test suite [2], for a total of 22 test problems. This lattice is described in Reference [6], with ORNL-developed Polaris models available (https://code.ornl.gov/scale/analysis/atf-latt-phys/-/tree/master/bwr/FeCrAl/10_percent).
For each test case, the 10 wt% 10x10 BWR FeCrAl ATF mechanical/nuclear lattice design will be combined with the original case matrix (histories and branches) of the corresponding BWR test and tested according to that tests recommended lattice physics parameters. If there is a conflict between the 10 wt% 10x10 BWR FeCrAl ATF lattice specifications and the original test case specifications (i.e., reference conditions, histories, depletion steps, etc.),
then the 10 wt% 10x10 BWR FeCrAl ATF lattice specifications described in Reference [6]
shall take precedence.
Deliverable for Subtask 10.9: Functioning 10 wt% 10x10 BWR FeCrAl ATF SCALE/Polaris test suite of 22 models (SCALE/Polaris inputs and outputs) and corresponding README file that outlines test matrix.
This test suite shall be delivered within 30 business days of Subtask 10.9 commencement.
Subtask 10.10: Integration of 10 wt% 10x10 BWR FeCrAl ATF SCALE/Polaris Test Suite into Perl test harness The contractor shall use GenPMAXS to convert the 22 10 wt% 10x10 BWR FeCrAl ATF SCALE/Polaris txtfile16s into PMAXS files and integrate both sets of files into the Perl test harness. If updates to the Perl txtfile16 and PMAXS readers are necessary, then those updates shall be delivered with the test harness. For each test problem, the test harness shall interrogate the txtfile16s and PMAXS files according to the original, corresponding Pass/Fail criteria.
Deliverable for Subtask 10.10: Functioning Perl test harness with 10 wt% 10x10 BWR FeCrAl ATF SCALE/Polaris Test Suite The updated test suite/harness shall be delivered within 30 business days after Subtask 10.10 commencement.
Subtask 10.11: Development of 8.15 wt% 17x17 PWR ATF (Cr-coated Clad with Doped Fuel) SCALE/Polaris Test Suite Problems
31310020D0007 / 31310023F0047 Attachment No. 1 22 The contractor shall combine the 8.15 wt% 17x17 PWR ATF lattice designs (with ZIRLO, Cr-coated clad and Cr2O3(800ppm)/Al2O3(200ppm) doped fuel) of the ATF (HB/HALEU) study
[6] with the PWR test cases (7) of the original 19 problem test suite [2], for a total of 7 test problems. This lattice is described in Reference [6], with ORNL-developed Polaris models available (https://code.ornl.gov/scale/analysis/atf-latt-phys/-/tree/master/pwr/Base).
For each test case, the 8.15 wt% 17x17 PWR Cr-coated/doped ATF mechanical/nuclear lattice design will be combined with the original case matrix (histories and branches) of the corresponding BWR test and tested according to that tests recommended lattice physics parameters. If there is a conflict between the 8.15 wt% 17x17 PWR Cr-coated/doped ATF lattice specifications and the original test case specifications (i.e., reference conditions, histories, depletion steps, etc.), then the 8.15 wt% 17x17 PWR Cr-coated/doped ATF lattice specifications described in Reference [6] shall take precedence.
Deliverable for Subtask 10.11: Functioning 8.15 wt% 17x17 PWR ATF (Cr-coated Clad with Doped Fuel) SCALE/Polaris test suite of 7 models (SCALE/Polaris inputs and outputs) and corresponding README file that outlines test matrix.
This test suite shall be delivered within 30 business days of Subtask 10.11 commencement.
Subtask 10.12: Integration of 8.15 wt% 17x17 PWR ATF SCALE/Polaris Test Suite into Perl test harness The contractor shall use GenPMAXS to convert the 7 8.15 wt% 17x17 PWR ATF SCALE/Polaris txtfile16s into PMAXS files and integrate both sets of files into the Perl test harness. If updates to the Perl txtfile16 and PMAXS readers are necessary, then those updates shall be delivered with the test harness. For each test problem, the test harness shall interrogate the txtfile16s and PMAXS files according to the original, corresponding Pass/Fail criteria.
Deliverable for Subtask 10.12: Functioning Perl test harness with 8.15 wt% 17x17 PWR ATF (Cr-coated Clad with Doped Fuel) SCALE/Polaris Test Suite The updated test suite/harness shall be delivered within 30 business days after Subtask 10.12 commencement.
Task 11 - Monthly Letter Status Report (MLSR)
The contractor shall provide a Monthly Letter Status Report (MLSR) which consists of a technical progress report and financial status report. This report will be used by the Government to assess the adequacy of the resources proposed by the contractor to accomplish the work contained in this SOW and provide status of contractor progress in achieving activities and producing deliverables. The report shall include order summary information, work completed during the specified period, milestone schedule information, problem resolution, travel plans, and staff hour summary.
Deliverable for Task 11: The contractor shall provide the MLSR by the 20th of the following month.
References
31310020D0007 / 31310023F0047 Attachment No. 1 23
- 1. Letter Report: Test Requirement Specifications for the SCALE-GenPMAXS Unified Test Suite. ORNL/LTR-2011/326. Task 1 Letter Report. F6028.
- 2. Letter Report: The SCALE-GenPMAXS Unified Test Suite ORNL/LTR-2012/612. Task 2 Letter Report. F6028.
- 3. Letter Report: Unified Testing for SCALE and PARCS Development Work Benchmark Package ORNL/LTR-2013/8. Task 3 Letter Report. F6028.
- 4. Isotopic and Fuel Lattice Parameter Trends in Extended Enrichment and Higher Burnup LWR Fuel Vol. II: BWR Fuel, ORNL/TM-2020/1835, ADAMS No.: ML21088A354
- 5. Isotopic and Fuel Lattice Parameter Trends in Extended Enrichment and Higher Burnup LWR Fuel Vol. I: PWR Fuel, ORNL/TM-2020/1833, ADAMS No.: ML21088A336
- 6. Extended-Enrichment Accident-Tolerant LWR Fuel Isotopic and Lattice Parameter Trends, ORNL/TM-2021/1961, ADAMS No.: ML21088A254
- 5. APPLICABLE DOCUMENTS AND STANDARDS The contractor shall comply with the following applicable regulations, publications, manuals, and local policies and procedures:
- MD 3.9. NRC Staff and Contractor Speeches, Presentations, Papers, and Journal Articles on Regulatory and Technical Subjects
- MD 12.3. NRC Personnel Security Program
- MD 12.5. NRC Cybersecurity Program
- National Institute of Standards and Technology (NIST), Special Publication (SP) 800-171r2, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations.
- NUREG-1737: Software Quality Assurance Procedures for NRC Thermal Hydraulic Codes
- 41 USC § 2302(b)(2); Special Nuclear Purpose License
- FAR Clause 52.227-17 Rights in Data-Special Works
- 6. DELIVERABLES AND DELIVERY SCHEDULE/REPORTING REQUIREMENTS The contractor shall provide the deliverables stated in the table below, in electronic format unless directed by the COR. The electronic format shall be provided using a Microsoft-based product, (e.g., Outlook, Word, Excel, PowerPoint) unless the deliverable description requires a different format (i.e., LaTex document, software text file, script, etc.).
All deliverables shall be in the format of a draft version, with accommodations to track subsequent changes. The contractor shall maintain appropriate revision control in an electronic format.
For each final deliverable (e.g., preliminary, draft, or final) that accomplishes a specific portion of a subtask activity, the contractor shall provide an electronic copy to the COR. The
31310020D0007 / 31310023F0047 Attachment No. 1 36 Experience with nuclear analysis code structure, algorithms, and code compilation/build systems Experience in coding with modern FORTRAN standards and in working with DOS, Linux, UNIX, and scripting languages such as Perl and Python; experience in software engineering and software quality assurance (SQA)
Experience with the following lattice physics packages:
HELIOS, CASMO, SCALE/TRITON, SCALE/Polaris, SCALE/Shift, and Serpent Experience with using LaTeX (lualatex)/python to maintain PARCS/PATHS documentation Experience performing quasi-steady state, fuel cycle calculations with PARCS/PATHS Experience in using PARCS/PATHS to model cores with advanced fuel forms (Accident Tolerant Fuel)
Experience in adding advanced fuel thermo-mechanical capabilities to PARCS/PATHS Experience in testing GenPMAXS versions within the Perl-based regression testing harness Experience in mounting PARCS onto a version control system (such as CVS and SVN) and making changes and modifications to the version control system Experience developing and maintaining python scripts to compare PARCS/PATHS versions to measured detector power responses as part of PARCS/PATHS assessment Experience in developing/maintaining scripts to regression test PARCS/PATHS versions Experience in developing TRACE updates for changes to PARCS source Experience in developing input decks to test PARCS/PATHS features Subject Matter Expert (SME) 2 Completion of graduate level courses in numerical methods, neutronic methods, reactor physics, and thermal-hydraulics Experience with core nuclear analysis algorithms and application; nuclear analysis methods development; Yes
31310020D0007 / 31310023F0047 Attachment No. 1 37 numerical algorithms for the solution of systems of equations; and the numerical methods and algorithms which make up PARCS Experience with the PARCS/PATHS source code and the GenPMAXS source code Experience with nuclear analysis code structure, algorithms, and code compilation/build systems Experience in coding with modern FORTRAN standards and in working with DOS, Linux, UNIX, and scripting languages such as Perl and Python; experience in software engineering and software quality assurance (SQA)
Experience with the following lattice physics packages:
HELIOS, CASMO, SCALE/TRITON, SCALE/Polaris, SCALE/Shift, and Serpent Experience with using LaTeX (lualatex)/python to maintain PARCS/PATHS documentation Experience performing quasi-steady state, fuel cycle calculations with PARCS/PATHS Experience in using PARCS/PATHS to model cores with advanced fuel forms (Accident Tolerant Fuel)
Experience in adding advanced fuel thermo-mechanical capabilities to PARCS/PATHS Experience in testing GenPMAXS versions within the Perl-based regression testing harness Experience in mounting PARCS onto a version control system (such as CVS and SVN) and making changes and modifications to the version control system Experience developing and maintaining python scripts to compare PARCS/PATHS versions to measured detector power responses as part of PARCS/PATHS assessment Experience in developing/maintaining scripts to regression test PARCS/PATHS versions Experience in developing TRACE updates for changes to PARCS source Experience in developing input decks to test PARCS/PATHS features
31310020D0007 / 31310023F0047 Attachment No. 1 38 For the purposes of developing a technical proposal, Experience is defined as some sort of exposure to the topic that can be cited in a resume. Although not all-inclusive, examples of experience could include: performing unfunded work on the topic such that the bidder could describe the work (i.e., wrote a program to do X on my own time); developing and teaching training materials on the topic (either in a university, commercial, or government setting); overseeing work on the topic as part of a government funded or commercial project; performing work on the topic as part of a government funded or commercial project; having taken courses on the topic (through a university, commercial, or government setting) and having been evaluated (with an awarded grade or certificate); working on the topic and producing a written report (peer-reviewed publication; conference proceeding; or government/commercially sponsored technical report); or having overseen work on the topic in a management or mentorship capacity.
- 8. ESTIMATED MATERIALS REQUIRED The following information technology is required during the life of the contract:
Commercial FORTRAN compilers including:
Microsoft Visual Studio (MSVS) with Intel oneAPI HPC Toolkit for Windows (2 users)
NAG Fortran Compiler for Linux (1 user)
PGI Fortran/C/C++ Workstation for Linux (1 user) 2 Engineering Workstations [Minimum Requirements: Intel Xeon Multicore Processor, 2.80GHz, 32GB RAM, 1 TB hard drive]
SecureZip Software Package Framemaker Software Package
- 9. PLACE OF PERFORMANCE The work to be performed under this contract shall be primarily performed at the contractors site.
- 10. SPECIAL CONSIDERATIONS TRAVEL/MEETINGS Contractor will be authorized travel expenses consistent with the substantive provisions of the Federal Travel Regulation (FTR) and the limitation of funds specified in this contract/order. All travel requires written Government approval from the CO, unless otherwise delegated to the COR.
Travel will be reimbursed in accordance with FAR 31.205-46, Travel costs and the General Services Administrations Federal Travel Regulations at:
http://www.gsa.gov/portal/content/104790.
31310020D0007 / 31310023F0047 Attachment No. 1 39 At the discretion of the COR, and, in deference to CDC guidance with respect to COVID-19 Community Levels at the contractors location and at NRC HQ (if Community Level is Medium or High), meetings may be conducted via telephone or video conference.
However, if the COR schedules physical meetings, then it is estimated that the following travel will be required, with each trip including travel days prior-to and following each meeting (with the exception of the Fall CAMP meeting, in which the last day is considered a travel day):
One, 2-person, 1-day contract kick-off meeting, to be held at the beginning of the contract (post-award) at NRC Headquarters in Rockville, Maryland (2 days of travel).
Two, 2-person, 2-day training sessions for PARCS Users to be held every other year (starting on the second year) at NRC Headquarters in Rockville, Maryland (4 days of travel).
Two, 1-person, 3-day participations in the annual Fall CAMP meetings, to be attended every other year (starting on the first year), and within commuting distance of NRC Headquarters in Rockville, Maryland (4 days of travel).
All travel requires prior written approval from the COR.
SECURITY Export Controlled Information It is anticipated that work described in this SOW will involve the use of Sensitive Unclassified Non-Safeguards Information (SUNSI), i.e., Export Controlled Information (ECI), and/or proprietary data. Information marked as ECI will strictly be restricted to only persons with a defined Need-to-Know (NTK) and must be handled only by U.S. citizens or permanent residents. Information marked as proprietary, but not ECI, will be restricted only to persons with a defined NTK. Any unauthorized disclosure of ECI must be reported within 1 hour1.157407e-5 days <br />2.777778e-4 hours <br />1.653439e-6 weeks <br />3.805e-7 months <br /> to the USNRC contracting officer (CO) for immediate next steps. After completion of work, the contractor must either destroy the documents containing both proprietary and ECI information or return them to the NRC. If they are destroyed, please confirm this in an email to the COR with a copy to the CO and include the date and manner in which the documents were destroyed. (Refer to Section H.4 Definition and Handling of Export Controlled Information.)
Other Security Requirements Performance under this task order requires IT Access Authorization. To the extent practicable, the contractor shall screen potential contractor personnel assigned to this task order prior to submitting such personnel for IT Access Authorization. This may expedite processing and on-boarding to the NRC. Common security concerns include criminal records, drug use, significant debt and other financial problems, failure to register for selective service, and extensive overseas contacts and/or residences.
The following regulations/requirements are applicable to this task order:
Management Directive 12.5 - MD 12.5 - NRC Cybersecurity Program - CUI-Proprietary, CUI Marking, Handling, and Processing
31310020D0007 / 31310023F0047 Attachment No. 1 40 Management Directive 12.6 - MD 12.6 - NRC Controlled Unclassified Information (CUI)
Program - CUI-Proprietary and IT Level I access Management Directive 12.3 - MD 12.3 - NRC Personnel Security Program - CUI-Proprietary and IT Level I access All work under this task order and all devices used to process NRC sensitive information shall comply with the National Institute of Standards and Technology (NIST), Special Publication (SP) 800-171r2, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations, and NRC guidance for the identification and documentation of minimum-security controls. Upon request, the contractor shall participate with the NRC to review the contractors compliance with NIST 800-171r2 (i.e., provide requested documentation, participate in meetings, etc.).
The contractor shall ensure that the software does not contain undocumented functions and undocumented methods for gaining access to the software or to the computer system on which it is installed. This includes, but is not limited to, master access keys, back doors, or trapdoors.
LICENSE FEE RECOVERY All work under this task order is not license fee recoverable.
DATA RIGHTS The NRC shall have unlimited rights to and ownership of all deliverables provided under this contract/order, including reports, recommendations, briefings, work plans and all other deliverables. All documents and materials, to include the source codes of any software, produced under this contract/order are the property of the Government with all rights and privileges of ownership/copyright belonging exclusively to the Government. These documents and materials may not be used or sold by the contractor without written authorization from the CO. All materials supplied to the Government shall be the sole property of the Government and may not be used for any other purpose. This right does not abrogate any other Government rights. The definition of unlimited rights is contained in Federal Acquisition Regulation (FAR) 27.401, Definitions. FAR 52.227-17, Rights in Data-Special Works applies and is included is this task order.
31310020D0007 / 31310023F0047 - Attachment No. 2 SOW Attachment A TRACE Standard Programming Practices and General Design Philosophies Developers shall adhere to these practices for all new coding. Please send feedback to Christopher.Murray@nrc.gov. Improper style in old coding will be corrected as resources permit.
- Write GOOD requirements - see http://www.incose.org/workgrps/rwg/writing.html for some online guidelines
- All code TRACE SQA reports and code documentation shall be prepared and submitted to NRC in Framemaker format. Equations shall be generated using Framemaker's built-in equation tools. Line and vector-based diagrams shall be generated using Framemaker's built-in drawing tools. In cases where this is not possible, the original picture files shall accompany the document and be in a format editable by common drawing tools (eps, svg, mif, pdf, cdr). Use encapsulated postscript (eps) only as a very last resort - we expect developers to employ modern drawing tools that will not lead to this limitation. For engineering plots, AptPlot is the preferred program for generating such plots. Save them to mif format for importing into a Framemaker document. Plots shall NOT be imported as bitmap images (use vector formats instead. For raster/bitmap pictures, the image may be inserted directly into the document, but the transmittal shall include the image in its own file in a standard format (gif, png, or jpg).
- All new variables will be explicitly typed, and all new routines shall include IMPLICIT NONE statements.
- Implement a standard KIND representation for Integers and Reals
+ Always insert the line "USE IntrType" after the MODULE statement, or for any subprograms that are not module procedures, after the SUBROUTINE or FUNCTION statement. If IntrType is declared at the module level, there is no need to include it within the CONTAINed subroutines.
+ Begin all definitions of real variables with "REAL(sdk)"
+ Begin all definitions of integer variables with "INTEGER(sik)"
- All use of real and integer constants should be implemented with the _sdk and _sik kind type parameters
Solicitation No. 31310023R0001 - Attachment No. 2 SOW Attachment A 2
+ For example, use 2_sik instead of just 2, or 1.0e+10_sdk instead of 1.0d+10, etc.
- Do not use continuation lines inside of variable declaration statements
- When declaring a variable of TYPE POINTER, ALWAYS initialize it with the => NULL() syntax.
- Get in the habit of using default initialization whenever variables are declared, but keep in mind that use of this syntax implies the SAVE attribute for any variable for which this is done.
Developers shall use the ONLY syntax in their USE statements. This prevents unintended variables from coming into scope and preventing the compiler from detecting instances where a local variable is undeclared or an unintended global variable is used mistakenly (as can happen with variables like cco when cutting and pasting code).
- Developers shall use object-oriented designs. What does this imply? It means that coding shall be data-centric. In other words, design the data structure first. Make it flexible enough to handle all possible situations for which you could ever envision needing it. Once an effective data structure is fleshed out, on paper, begin to think about methods that operate on that data structure. As a minimum, there ought to be constructor/initialization and destructor methods for the data structure as a whole and any substructure pointer or allocatable arrays that might exist. Make the data structure PRIVATE to the module of interest. Access to the data structure shall only be through subroutines or functions. The contractor shall factor these ideas into proposals and predictions about time and cost. The penalty with these sorts of designs is in run-time speed, so there may be situations where such designs do not make sense but a developer's priorities shall be object-oriented first, run-time second. Speed can always be recaptured in the next generation of processors or by optimizing other aspects of the code.
- All dummy arguments and important local variables shall be declared within their own TYPE declaration statements.
- The INTENT of all dummy arguments shall be declared in all new coding
- Do not use bare END statements
- All Fortran statements, attributes, intrinsic subprograms, and logical operators in new coding shall be in all upper case.
Solicitation No. 31310023R0001 - Attachment No. 2 SOW Attachment A 3
REAL(sdk), POINTER, DIMENSION(:,:) :: a, aa IF ( i.GT.j ) THEN
- Leading and trailing underscores shall not be used in any names (due to the potential for name mangling issues during linking), but underscores in the middle of names are allowed.
- Variable, file, and procedure names shall be long enough to be self-documenting, within reason, with a suggested limit of 15-20 characters
- All new variable names shall have the first letter of each sub-element capitalized except the first, as in pipeData.
- All derived type names shall end in "T", as in pipeDataT.
- Module and subprogram names shall begin with a capitalized letter, but don't change old subprogram names.
- All new coding shall be structured with an indentation level of three spaces.
DO i = 1,n DO j = 1,n IF (i.gt.j) THEN a(i,j) = - aa(j,i)
ELSE a(i,j) = aa(i,j)
ENDIF ENDDO ENDDO
- Use IF-THEN-ENDIF instead of IF (condition) statement
- "GOTO" statements shall be used sparingly, if at all. Instead, programmers shall use IF-THEN-ELSE, SELECT CASE, CYCLE, EXIT, and internal subprograms as
Solicitation No. 31310023R0001 - Attachment No. 2 SOW Attachment A 4
appropriate
- Use standard F90 free format code style with the following exceptions:
+ A limit of 110 columns per line
+ Source code shall start in column 7. Columns 1-6 are to be reserved for statement labels. This does not apply to comments and MODULE statements.
- Comments lines shall be indicated with a "!" in column 1.
- Comments that serve to delineate, summarize, and/or clarify larger multi-step algorithms shall be indented one or two spaces.
- Comments that serve to clarify the intent of and/or summarize small blocks of code shall be given the same indentation level as that code.
- Comments shall be offset by at least one blank line from the previous F90 statement.
- Comment shall not be placed at the end of a continued line (illegal Fortran).
Multi-line statements shall not be used. It makes writing scripts to parse FORTRAN more difficult and invalidates line coverage profiling studies.
- End-of-line comments shall not be used except in context of data type declaration statements or where a brief comment on the same line as the statement clearly accentuates and improves the readability and intent of the IF statement or block that follows, ala INTEGER(sik) :: height = 0.0_sdk ! height of the cell or IF (fillTab(cco)%flowin.GE. 0.0d0) THEN !Determine donor cell mixture.
- Comment blocks shall generally not be longer than a dozen lines (additional information can go in the programmer's manual, and/or the SDID subroutine report).
- Authorship information shall be included for each new subroutine that a developer creates or rewrites from scratch. When well defined blocks of changes (on the order of 100 lines or more) are made to an existing subroutine, a note shall be placed directly beneath the existing authorship info (or below the subroutine purpose if it does not) denoting the name, organization, date and quick description of the modifications.
Solicitation No. 31310023R0001 - Attachment No. 2 SOW Attachment A 5
Authorship info shall not be provided when the changes are spread out (i.e. not in well defined blocks) - even if they significantly modify some behavior of the algorithm contained therein - although the subroutine description shall be checked for accuracy and modified when appropriate.
- The following standard template shall be used for each new subroutine that is developed (a plug-in to Visual Fortran has been created which can create this automatically):
SUBROUTINE SampleSub()
USE IntrType IMPLICIT NONE
! The purpose of this routine is to <<Insert Description here>>
! Programmed by Name, Organization, Date (Month/Year)
! Subroutine Argument Descriptions:
! Variable Declarations:
RETURN END SUBROUTINE SampleSub When making a change, do not comment out the old coding but instead delete it.
- Do not surround your coding with your initials - it just uglifies the code.
- Never use COMMON. Use a MODULE and corresponding USE instead.
- Never use EQUIVALENCE. Use POINTERs if you must, but better practice is to redesign so pointers are not necessary.
- All code shall be standard F90 - use of non-standard compiler extensions or preprocessor definitions shall not be allowed.
- If available in the compiler, all code shall be developed with strict F90 standards checking and array bounds checking turned on. Also, compiler flags shall be engaged which check for any unused variables and uninitialized variables. If any unused variables are located in a routine that a developer touches, then he or she shall remove them.
Solicitation No. 31310023R0001 - Attachment No. 2 SOW Attachment A 6
- If a new subroutine is added to the code outside the scope of a MODULE statement, then an explicit interface to that routine shall be created. This allows the compiler to handle checking of the argument lists at compile time.
- Developers shall remove any unused subroutines which are created as a result of their efforts.
- When incorporating legacy code from other computer codes into TRACE, every effort shall be made to clean that code up and to ensure that it conforms to the stylistic rules and design philosophies outlined in this document.
When preparing an SRD for a particular development project, the requirements shall take into account the planned update's effect on or interaction with such areas as:
+ restart processing
+ CSS controllers
+ control system
+ exterior component and other parallel programming interfaces
+ timestep backup flow logic
+ SNAP and/or VEDA
+ English units
- Any modification or enhancement of intercomponent transfer of information shall never involve direct modification of bd array elements. All transfers shall be arranged during the initialization phase of the calculation (module SysService) through the system service transfer tables.
31310020D0007 / 31310023F0047 - Attachment No. 3 SOW Attachment B TRACE Special Requirements:
All code development activities must follow principles described in NUREG-1737 and adhere to the Programming Guidelines and Design Philosophies as outlined in Attachment A.
All TRACE code transmittal packages shall be generated using the buildTransmittal.pl perl script and shall include the following:
SQA documentation Patch files to the TRACE source in diff format Modified source files HTML summary file explaining the nature of the changes and testing Modified test input files (if any)
Newly added test input decks (if any)
HTML results of the testSummary.py python script (generated for the regression test set)
AVScript input files (if applicable)
Scripts or programming tools that might have been used/generated in the course of completing the update If changes to the TRACE code manuals are required in conjunction with a particular update, the contractor may be asked by NRC to make those modifications in addition to the SQA documentation outlined in the Statement of Work. Regarding this issue, it is NRCs expectation that the contractor shall become familiar with the content of each chapter in each manual so that manual changes are applied comprehensively and at a level of detail similar to the content that surrounds the modified or added text. The contractor shall ensure that inconsistencies between various sections of content (either in thought or in nomenclature) are not introduced.
Changes to TRACE manuals shall generally be made to the on-line, official electronic files directly. In cases where this practice is either not prudent or not possible, the contractor shall use Framemakers built-in change bar feature to call out modifications to make it easier for NRC staff to integrate those changes into the official electronic files at the appropriate time.
The NRC will not consider it acceptable to submit graduate theses as the final product of research. All final assessment reports shall use NRC-supplied Framemaker templates and shall be in accordance with the specifications provided in the Statement of Work.
The development of all assessment input problems shall be accompanied by the development of a calculation notebook that justifies the use of every value provided in the model. For every value, the calculation notebook shall answer the following questions:
31310020D0007 / 31310023F0047 - Attachment No. 3 SOW Attachment B
- What is it?
- Why was it chosen?
- What was assumed?
- How was it calculated? and/or
- Where did it come from?
ORNL/LTR-2011/326 Reactor and Nuclear Systems Division LETTER REPORT TEST REQUIREMENT SPECIFICATIONS FOR THE SCALE-GENPMAXS UNIFIED TEST SUITE Matthew A. Jessee Brian J. Ade Andrew Ward, University of Michigan Date published: August 17, 2012 Prepared for Office of Nuclear Regulatory Research U.S. Nuclear Regulatory Commission Washington, D.C. 20555-0001 JCN F6028 Prepared by OAK RIDGE NATIONAL LABORATORY Oak Ridge, Tennessee 37831-6285 managed by UT-BATTELLE, LLC for the U.S. DEPARTMENT OF ENERGY under contract DE-AC05-00OR22725
- 1. BACKGROUND The NRC has utilized the SCALE/TRITON lattice physics package to support several PARCS/TRACE analyses over the last two years. Through the course of these projects, several issues have been encountered that impact the accurate conversion of few-group (FG) cross-section (XS) data from SCALE format (xfile016) to PARCS format (PMAX) using the conversion program GENPMAXS. Three examples are provided below:
- 1. Crystal River Unit 3 (CR3) Extended Power Uprate (EPU): While generating FG XSs for CR3-EPU analysis, we identified an issue with TRITONs transport cross sections. TRITON archives two different transport cross sections onto xfile016, each computed by a different method. We determined that one set of transport cross sections was superior to the other set. Because GENPMAXS was set up to convert the inferior set of transport cross sections by default, a modification in GENPMAXS was necessary to read the transport cross section from a different location on xfile016.
- 2. Maximum Extended Load Line Limit Application Plus (MELLLA+): For MELLLA+ FG XS generation, we had to introduce a new branch block to support different boron concentrations in the bypass and in-channel regions for boron branch calculations. This required modifications to the xfile016 file format, which in turn required modifications to the GENPMAXS to allow the user to specify the branch conditions through a new input file option.
- 3. BWR Stability Analysis: In JCN F6015/V6233, we identified errors with computing kinetic parameters. These errors were fixed and released as a patch to SCALE 6.1.1, in which we changed the version number included on the xfile016. Thus, GENPMAXS needs to be updated appropriately.
All three examples above required coordination of code modifications between TRITON and GENPMAXS to deliver PMAX files for PARCS/TRACE analysis. All three examples required the creation of beta versions of SCALE and GENPMAXS to accommodate the needs of the NRC projects.
Although our goal is to use only officially released versions of SCALE and GENPMAXS in future NRC projects, coordination of code modifications and creation of beta versions can be expected, and verification of the code modifications must be demonstrated for quality assurance. Therefore the purpose of this project is to develop a suite of test cases that can be run to verify the data conversion from xfile016 to PMAX format.
- 2.
SUMMARY
The purpose of this initial task is to develop the list of parameters (e.g. few-group cross sections, k-inf values, etc.) that will be tested through the test suite. Along with the parameters, the pass/fail criteria for each parameter need to be established. This report documents the set of 19 test problems established to cover the common use cases for TRITON/PARCS/TRACE analysis. For each test case, a brief description of the TRITON input models are provided, along with the list of output parameters to be analyzed for each test case. Comparisons will be made for each listed output parameter between the TRITON output (txtfile16) and the GENPMAXS output (PMAX file). Automation of the test comparison, along with finalization of the test suite will be performed and documented in future tasks of this project. The coverage matrix for the test suite is provided on the final page of the report.
- 3. ABBREVIATIONS TF/DC/TC/CR/PC are designators for certain types of branch conditions.
TF - Fuel Temperature DC - Coolant Density TC - Coolant Temperature CR - Control Rod (=0 rods out, =1 rods in)
PC - Poison Concentration
- 4. TEST CASE SPECIFICATIONS Test Case 01: PWR pin cell depletion Description
- PWR pin cell depletion model at HFP
- Based on Westinghouse 17x17 assembly design
- 700 ppm boron
- 4.95% enriched UO2
- 80 GWD/MTU burnup, 10 depletion steps (11 statepoints) o 0, 4, 12, 20, 28, 36, 44, 52, 60, 68, 76 GWD/MTU
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o Transport cross section (2 groups x 11 statepoints) o Absorption (2 x 11) o Nu-fission (2x11) o Kappa-fission (2x11) o Fission (2x11) o Xe micro (2x11) o Sm micro (2x11) o Inverse velocity (2x11) o FP yields (Xe, I, and Pm) (3x11) o Betas/Lambdas group 1-6 (12x11) o Scatter Matrix (4x11) o Total: (35x11) 385
- Miscellaneous Parameters o Burnup Values o Visually inspect GENPMAXS KINF file for errors/warnings
Test Case 02: PWR Pin cell depletion, with TF, PC, and DC branches Description
- PWR pin cell depletion model at HFP
- Based on Westinghouse 17x17 assembly design
- 700 ppm boron
- 4.95% enriched UO2
- 20 GWD/MTU burnup, 3 depletion steps (4 statepoints) o 0, 4, 12, 18 GWD/MTU
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
- Reference + 6 Branches (7 total) o
Reference:
TF=900 DC=0.723 PC=700 CR=0 o Branch 1: DC: DC=0.500 o Branch 2: DC: DC=1.00 o Branch 3: PC: PC=2200 o Branch 4: TF: TF=293 o Branch 5: PC/TF: TF=293 PC=2200 o Branch 6: DC/PC/TF: TF=293 DC=1.0 PC=2200 Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o Same set as test case 1 o Total: (35x4x7) 980 total
- Miscellaneous Parameters o Burnup Values o Branch Conditions o Visually inspect GENPMAXS KINF file for errors/warnings Notes
- For this test, we are not co-branching TC with DC, which is common for PWRs. This will be tested in problem 18.
Test Case 03: BWR Pin cell depletion, with TF and DC branches Description
- BWR pin cell depletion model at HFP
- Based on GE 7x7 Peach Bottom Assembly
- 40 void fraction (0.4572 g/cc)
- 4.95% enriched UO2
- 20 GWD/MTU burnup, 3 depletion steps (4 statepoints) o 0, 4, 12, 18 GWD/MTU
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
- Reference + 4 Branches o
Reference:
DC=0.4572 TF=900 (40 void) o Branch 1: DC: DC=0. 738079 (0 void) o Branch 2: DC: DC=0.176345 (80 void) o Branch 3: TF: TF=1200 o Branch 4: DC/TF: TF=293 DC=1.0 (CZP)
Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o Same set as test case 1 o Total: (35x5x4) 700 total
- Miscellaneous Parameters o Burnup Values o Branch Conditions o Visually inspect GENPMAXS KINF file for errors/warnings
Test Case 04: PWR assembly depletion, with histories and branches Description
- PWR assembly depletion model at HFP
- Based on Westinghouse 17x17 assembly design, reduced to a 5x5 assembly with 1/4 symmetry
- 4.95% enriched UO2
- 20 GWD/MTU burnup, 3 depletion steps (4 statepoints) o 0, 4, 12, 18 GWD/MTU
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
- Reference History o Depletion Condition: (PC=700 ppm, DC=0.7, CR=0, TF=900) o Branch 1: CR: CR=1 o Branch 2: PC: PC=2200 o Branch 3: DC: DC=0.9 o Branch 4: TF: TF=1200
- CR History o Depletion Condition: (PC=700 ppm, DC=0.7, CR=1, TF=900) o Branch 1: CR: CR=0 o Branch 2: PC: PC=2200 (with CR=0) o Branch 3: DC: DC=0.9 (with CR=0) o Branch 4: TF: TF=1200 (with CR=0)
- DC History o Depletion Condition: (PC=700 ppm, DC=0.9, CR=0, TF=900) o Branch 1: CR: CR=1 (with DC=0.7) o Branch 2: PC: PC=2200 (with DC=0.7) o Branch 3: DC: DC=0.7 o Branch 4: TF: TF=1200 (with DC=0.7)
- PC History o Nominal: (PC=2200 ppm, DC=0.7, CR=0, TF=900) o Branch 1: CR: CR=0 (with PC=700) o Branch 2: PC: PC=2200 o Branch 3: DC: DC=0.9(with PC=700) o Branch 4: TF: TF=1200(with PC=700)
Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o 35 values documented in test case 1 o North and East Face ADFs (2 groups, all statepoints) o Total: (39x5x4x4) 3120 total
- Miscellaneous Parameters o Burnup Values o Branch Conditions o Visually inspect GENPMAXS KINF file for errors/warnings
Notes:
Decided to exclude TC branches/histories. TC co-branching for PWRs is addressed in problem
- 18.
Test Case 05: BWR assembly depletion, with histories and branches Description
- BWR assembly depletion model at HFP
- Pin dimensions based on GE 7x7 Peach Bottom Assembly
- Modeling 2.93% UO2 pins and 1 Gd2O3 pin (2.93% 235U, 3% Gd2O3)
- 20 GWD/MTU burnup, 3 depletion steps o 0, 4, 12, 18 GWD/MTU
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
- Reference History o Depletion Condition: (DC=0. 457211, CR=0, TF=950) o Branch 1: DC1: DC=0. 738079 (0% void) o Branch 2: CR: CR=1 o Branch 3: DC2: DC=0. 176345 (80% void) o Branch 4: TF: TF=1200
- DC History o Depletion Condition: (DC=0.738079, CR=0, TF=950) (0%void) o Branch 1: DC1: DC=0. 457211 (40% void) o Branch 2: CR: CR=1 (with DC=0. 457211) o Branch 3: DC2: DC=0. 176345 (80% void) o Branch 4: TF: TF=1200 (with DC=0. 457211)
- DC History o Depletion Condition: (DC=0. 176345, CR=0, TF=950) (80%void) o Branch 1: DC1: DC=0. 457211 (40% void) o Branch 2: CR: CR=1 (with DC=0. 457211) o Branch 3: DC2: DC=0. 738079 (0% void) o Branch 4: TF: TF=1200 (with DC=0. 457211)
- CR History o Depletion Condition: (DC=0. 457211, CR=1, TF=950) o Branch 1: DC1: DC=0. 738079 (with CR=0) (0% void) o Branch 2: CR: CR=0 o Branch 3: DC2: DC=0. 176345 (with CR=0) (80% void) o Branch 4: TF: TF=1200 (with CR=0)
Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o 35 values documented in test case 1 o North and East Face ADFs (2 groups, all statepoints) o Total: (39x5x4x4) 3120 total
- Miscellaneous Parameters o Burnup Values o Branch Conditions o Visually inspect GENPMAXS KINF file for errors/warnings
Test Case 06: PWR BOL Assembly model, with CDFs, PPFs, GFFs, and Det XS Description
- Westinghouse 17x17 assembly design, quarter symmetry
- 700 ppm boron
- 4.95% enriched UO2
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o 35 values documented in test case 1 o North and East Face ADFs (2 groups) o PPFs (81 pins) o GFFs (81 pins by 2 groups) o CDFs (4 corners + 4 faces, by 2 groups) o Detector XS (2 groups) o 300 Total values to check
- Miscellaneous Parameters o Visually inspect GENPMAXS KINF file for errors/warnings
Test Case 07: BWR BOL Assembly model, with CDFs, PPFs, GFFs, and Det XS Description
- Lattice type 3a, Peach Bottom Cycle 1 model from EPRI report
- 40% void
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o 35 values documented in test case 1 o North and East Face ADFs (2 groups) o PPFs (49 pins) o GFFs (49 pins by 2 groups) o CDFs (4 corners + 4 faces, by 2 groups) o Detector XS (2 groups) o 204 Total values to check
- Miscellaneous Parameters o Visually inspect GENPMAXS KINF file for errors/warnings
Test Case 08: PWR BOL Assembly/Reflector model Description
- Westinghouse 17x17 assembly design, quarter symmetry.
- 700 ppm boron
- 4.95% enriched UO2
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
- Approximately 4 cm of water reflector to the right hand side of assembly Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o 35 values documented in test case 1 for the reflector o Reflector ADFs (2 groups) o 37 Total values to check
- Miscellaneous Parameters o Visually inspect GENPMAXS KINF file for errors/warnings
Test Case 09: PWR BOL Assembly/Reflector model Description
- Westinghouse 17x17 assembly design, quarter symmetry
- 700 ppm boron
- 4.95% enriched UO2
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
- Approximately 4 cm of water reflector to the right hand side of assembly Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o 35 values documented in test case 1 for the reflector o Reflector Fluxes (2 groups) o Reflector Currents (2 groups) o 39 Total values to check
- Miscellaneous Parameters o Visually inspect GENPMAXS KINF file for errors/warnings
Test Case 10: BWR BOL Assembly/Reflector model Description
- Lattice type 3a, Peach Bottom Cycle 1 model from EPRI report
- 40% void
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
- Approximately 4 cm of water reflector to the right hand side of assembly Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o 35 values documented in test case 1 for the reflector o Reflector ADFs (2 groups) o 37 Total values to check
- Miscellaneous Parameters o Visually inspect GENPMAXS KINF file for errors/warnings
Test Case 11: BWR BOL Assembly/Reflector model Description
- Lattice type 3a, Peach Bottom Cycle 1 model from EPRI report
- 40% void
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
- Approximately 4 cm of water reflector to the right hand side of assembly Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o 35 values documented in test case 1 for the reflector o Reflector Fluxes (2 groups) o Refelctor Currents (2 groups) o 39 Total values to check
- Miscellaneous Parameters o Visually inspect GENPMAXS KINF file for errors/warnings
Test Case 12: BWR Pin cell depletion, with TF and DC branches Description
- Same as test case 3, but use the IUP option in GENPMAXS Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Same as test case 3, but note that the scattering XS will be corrected such that Sigma_Scatter2->1 will be zero.
Test Case 13: BWR Pin cell depletion, with TF and DC branches Description
- Same as test case 3, with 4G XS (E1=900 keV, E2=8 eV, E3=0.15 eV)
Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o Transport cross section (4 groups x 11 statepoints) o Absorption (4 x 11) o Nu-fission (4x11) o Kappa-fission (4x11) o Fission (4x11) o Xe micro (4x11) o Sm micro (4x11) o Inverse velocity (4x11) o FP yields (Xe, I, and Pm) (4x11) o Betas/Lambdas group 1-6 (12x11) o Scatter Matrix (16x11) o Total: (64x11) 704
- Miscellaneous Parameters o Burnup Values o Visually inspect GENPMAXS KINF file for errors/warnings
Test Case 14: BWR Pin cell depletion, with TF and DC branches Description
- Same as test case 3, with 44G XS Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o Transport cross section (44 groups x 11 statepoints) o Absorption (44 x 11) o Nu-fission (44x11) o Kappa-fission (44x11) o Fission (44x11) o Xe micro (44x11) o Sm micro (44x11) o Inverse velocity (44x11) o FP yields (Xe, I, and Pm) (44x11) o Betas/Lambdas group 1-6 (12x11) o Scatter Matrix (44x44x11) o Total: (2344x11) 25784
- Miscellaneous Parameters o Burnup Values o Visually inspect GENPMAXS KINF file for errors/warnings
Test Case 15: BWR assembly depletion, with histories and branches Description
- Same as test case 5
- Test combining multiple PMAX files into one PMAX file Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
Same as test 5.
Test Case 16: BWR assembly depletion, with branches Description
- Same as test 5, but just the reference history.
- The BWR will be modeled with the CR blade in the NE corner. This will require remapping the TRITON North and West ADFs to the PARCS North and East ADFs o Branch 4: TF: TF=1200 (with CR=0)
Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o 35 values documented in test case 1 o 2 Faces of ADFs (2 groups, all statepoints) o Total: (39x5x4) 780 total
- Miscellaneous Parameters o Burnup Values o Branch Conditions o Visually inspect GENPMAXS KINF file for errors/warnings
Test Case 18: PWR Pin cell depletion, with TF, PC, and DC branches Description
- Same as test 2, but exercise the co-branching option in GENPMAXS
- The PMAX branch structure is set in the GENPMAXS input file.
- Reference + 6 Branches (7 total) o
Reference:
TF=900 DC=0.723 PC=700 CR=0 o Branch 1: DC: DC=0.500 TC=600K in TRITON o Branch 2: DC: DC=1.00 TC=293K in TRITON o Branch 3: PC: PC=2200 o Branch 4: TF: TF=293 o Branch 5: PC/TF: TF=293 PC=2200 o Branch 6: DC/PC/TF: TF=293 DC=1.0 PC=2200 TC=293K in TRITON Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Same as test case 2
Test Case 19: BWR assembly depletion, with histories and branches Description
- Same as test 5, reference history only.
- Modified BWR branch to include a Boron Branch, with Boron injected into both in-channel and bypass region at different concentrations.
- Uses the new branch block format in TRITON.
- Reference History o Depletion Condition: (DC=0. 457211, CR=0, TF=950) o Branch 1: CR: CR=1 o Branch 2: DC1: DC=0. 738079 (0% void) o Branch 3: PC: PC=600 ppm o Branch 4: DC2: DC=0. 176345 (80% void)
Pass/Fail Criteria, compare the following values between TRITON txtfile16 and PMAX file:
- Lattice Physics Parameters o 35 values documented in test case 1 o North and East Face ADFs (2 groups, all statepoints) o Total: (39x5x4) 780 total
- Miscellaneous Parameters o Burnup Values o Branch Conditions o Visually inspect GENPMAXS KINF file for errors/warnings
Test Case Reactor Model Groups
- BOL, Depletion Only, Branches, Histories+Branches Burnup Macros / D Kinetics Xe/Sm
>2G XS Fuel ADFs Reflector ADFs (Type 2)
Reflector ADFs (Type 3)
CDFs GFFs Det. XS CR Branch PC Branch PWR TH Branch BWR TH Branch CR History PC History PWR TH History BWR TH History PMAX Merge ADF Remap GENPMAXS Input of Case Matrix IUP Option 1
LWR Pin Cell 2
Depletion Only X
X X
X 2
PWR Pin Cell 2
Branches X
X X
X X
3 BWR Pin Cell 2
Branches X
X X
X X
4 PWR 3x3 2
H+B X
X X
X X
X X
X X
X X
5 BWR 3x3 2
H+B X
X X
X X
X X
X X
6 PWR Assembly 2
BOL X
X X
X X
X X
7 BWR Assembly 2
BOL X
X X
X X
X X
8 PWR Assm/Refl 2
BOL X
X X
X 9
BWR Assm/Refl 2
BOL X
X X
X 10 PWR Assm/Refl 2
BOL X
X X
X 11 BWR Assm/Refl 2
BOL X
X X
X 12 BWR Pin Cell 2
Branches X
X X
X X
X 13 BWR Pin Cell 4
Branches X
X X
X X
X 14 BWR Pin Cell
>4 Branches X
X X
X X
X 15 BWR 3x3 2
H+B X
X X
X X
X X
X X
X 16 BWR 3x3 2
H+B X
X X
X X
X X
X X
X 17 PWR Assembly 2
BOL X
X X
X X
X X
X 18 PWR 3x3 2
Branches X
X X
X X
X 19 BWR 3x3 Branches X
X X
X X
X X
ORNL/LTR-2012/612 Reactor and Nuclear Systems Division LETTER REPORT THE SCALE-GENPMAXS UNIFIED TEST SUITE Brian J. Ade Matthew A. Jessee William A. Wieselquist Andrew Ward, University of Michigan Date published: December 19, 2012 Updated: January 14, 2013 Prepared for Office of Nuclear Regulatory Research U.S. Nuclear Regulatory Commission Washington, D.C. 20555-0001 JCN F6028 Prepared by OAK RIDGE NATIONAL LABORATORY Oak Ridge, Tennessee 37831-6285 managed by UT-BATTELLE, LLC for the U.S. DEPARTMENT OF ENERGY under contract DE-AC05-00OR22725
- 1. BACKGROUND Under Task 1, ORNL was tasked with defining the test matrix to be used for SCALE/TRITON-GenPMAXS testing and identifying key criteria and other parameters to be tested [1]. Under Task 1, ORNL generated specifications for a total of 19 SCALE/TRITON [2,3] and GenPMAXS
[4,5] test cases. The final test coverage matrix can be found in Table 1. A total of 24 SCALE/TRITON input files are required for the text matrix. Some test cases require multiple depletion histories, and some cases are GenPMAXS-only cases, which do not require additional TRITON calculations, leading to a different number of input files than test cases. In addition to the TRITON test cases, University of Michigan (UM) staff have developed a number of CASMO and HELIOS test cases.
- 2. BASE MODELS A total of eight basic input files have been used to complete the test matrix. These include pin cell, mini-assemblies, full lattice, and reflector models for both BWRs and PWRs. Each of these models was utilized in one of the 19 test cases. Basic dimensions of the models (fuel pin dimensions, pin, pitch, assembly pitch, etc.) can be found in this section. In general, the thermal-hydraulic (TH) conditions change depending on the particular test case for which the model is being used, so these conditions are not included in this section. However, in the following section, a basic summary of the test case and the results of the test case can be found. In addition, all SCALE/TRITON and GenPMAXS input files will be provided to NRC staff.
2.1. PWR Pin Cell The PWR pin cell model was developed using the SCALE/TRITON (t-depl) Westinghouse 17x17 model available in the SCALE public release [2] under the ORIGEN-ARP templates folder (~/scale6.1/data/arplibs/templates/w17x17_template.input). The original model is a 1/4-lattice model, which was reduced to a single 1/4-pin cell model (Figure 1). The fuel, gap, and clad diameters are 0.805 cm, 0.822 cm, and 0.950 cm, respectively. The fuel pin pitch is 1.259 cm.
The material properties (moderator density, temperatures, soluble boron content) vary depending on particular test case for which the model is being used. The PWR pin cell model utilizes reflective boundary conditions.
Figure 1: SCALE/TRITON representation of the PWR pin cell model.
2.2. BWR Pin Cell The BWR pin cell model was developed using specifications in the Peach Bottom EPRI report
[6] and from previous SCALE/TRITON validation work [7]. The original model from previous work is a full 7x7 BWR lattice model that has been reduced to a single 1/4-pin cell model (Figure 2). Although the BWR pin cell looks identical to the PWR pin cell because of the coloring of the material, the dimensions of the model correspond to a BWR rather than a PWR. The fuel, gap, and clad diameters are 1.21158 cm, 1.24206 cm, and 1.43002 cm, respectively. The fuel pin pitch is 1.87452 cm. The material properties (moderator density, temperatures, etc.) vary depending on particular test case for which the model is being used. The BWR pin cell model utilizes reflective boundary conditions.
Figure 2: SCALE/TRITON representation of the BWR pin cell model.
2.3. PWR Mini-Lattice The PWR mini-lattice model utilizes the same dimensions as the PWR pin cell model (Sect. 2.1),
but is a construction of multiple pin cells plus a guide tube. The model is truly a 5x5 model with a guide tube in the center of the model, but only the northeast corner of the model is constructed (Figure 3). The guide tube has an inner and outer diameter of 1.1435 cm, and 1.2242 cm, respectively. The material inside the guide tube is a moderator mixture that is replaced with a control rod mixture for rodded calculations. The PWR mini-lattice model utilizes reflective boundary conditions.
Figure 3: SCALE/TRITON representation of the PWR mini-lattice model.
2.4. BWR Mini-Lattice The BWR mini-lattice model utilized pin cells the same size as the BWR pin cell model. The mini-lattice model is a 3x3 array of fuel pins where the southeastern fuel pin is a gadolinia-bearing fuel pin (Figure 4). The BWR mini-lattice model contains a region in the northwest corner that acts as a control blade. The BWR mini-lattice model utilizes reflective boundary conditions. Both the PWR and BWR mini-assembly models are referred to as 3x3 models throughout this document.
Figure 4: SCALE/TRITON representation of the BWR mini-lattice model.
2.5. PWR Lattice
The PWR lattice model is a Westinghouse 17x17 fuel lattice model that is constructed using the pin cell and guide tube from the previous sections. The northeast quadrant of the fuel lattice has been modeled (Figure 5). The dimensions of the central instrument tube are assumed equal to the guide tubes. No inter-gap has been modeled in this fuel assembly. The PWR lattice model utilizes reflective boundary conditions.
2.6. BWR Lattice The BWR lattice model is a GE-designed 7x7 fuel lattice that contains a number of gadolinia-bearing fuel pins and a channel (lattice type 3a of Ref. 6). The channel corners are assumed square rather than rounded. Also, a detector region has been added in the southeast corner of the fuel assembly in order to test detector response parameters. Assembly pitch is 15.24 cm and the inner and outer channel widths are 13.40612 cm and 13.81252 cm, respectively. The BWR lattice model utilizes reflective boundary conditions.
Figure 5: SCALE/TRITON representation of the PWR lattice model.
Figure 6: SCALE/TRITON representation of the BWR lattice model.
2.7. PWR Reflector The PWR reflector model is based off the PWR lattice model. In the reflector model, an additional region of water moderator is added to the east side of the model to act as the reflector region (Figure 7). In this case, the east boundary condition is vacuum and all other boundaries are reflective. The width of the reflector regions was arbitrarily chosen to be the width of three PWR pin cells (3.777 cm).
Figure 7: SCALE/TRITON representation of the PWR reflector model.
2.8. BWR Reflector Like the PWR reflector model, the BWR reflector model is based on the BWR lattice model with an additional region added to the east side of the model (Figure 8). In this case, the boundary conditions are the same as for the PWR reflector model: vacuum on the easy boundary and reflective on all other boundaries. The width of the reflector region was chosen to be half the assembly pitch (7.62 cm).
Figure 8: SCALE/TRITON representation of the BWR reflector model.
- 3. REGRESSION TESTING UTILITY A SCALE/TRITON - GenPMAXS regression testing utility has been developed in Perl (a scripting language) and tested on multiple operating systems (Windows, Linux, Mac). The regression testing utility produces pass/fail output in Perls standard Test Anything Protocol (TAP), which has many convenient test report formatters, such as interactive HTML. The testing framework was developed as a small set of single-purpose utilities where the regression test harness is just a small wrapper around a general comparison utility, which is in turn built on specific reader modules for different file formats, in this case txtfile16 and PMAXS readers.
Additionally, an xfile016 to txtfile16 converter was developed to allow xfile016 to be included in the testing framework. The current capability supports comparisons in two modes: i) a detailed (fine-grain) mode where comparisons are reported for every single value in the files or ii) an overview (coarse grain) mode where comparisons are reported in groups, e.g. changes in the list of burnups is reported instead of each individual burnup. The current capability allows comparison (and thus regression testing) of like files; i.e. txtfile16 to txtfile16 or PMAXS to PMAXS, but does not allow comparison of txtfile16 to PMAXS.
A screenshot of the interactive HTML report for the summary mode is shown in Figure 9 For each case, passing tests are shown as green boxes and failing tests as red ones. Clicking on a box, takes you to a description of the test performed.
Figure 9: Screenshot of the HTML comparison report in summary mode.
It is recommended all regression testing be initially performed in summary mode and if there are failures, they can be further investigated in the detailed mode, as shown in Figure 10.
Figure 10: Screenshot of the HTML comparison report in detailed mode.
The tool was actually developed to compare like files by design. In order to directly compare txtfile16 or xfile016 files to PMAXS files, the internal data structure storing txtfile16 and PMAXS data must be nearly identical and performing this conversion is basically the functionality of the GenPMAXS program. Thus in order to have txtfile16 to PMAXS comparisons, the GenPMAXS functionality would essentially have to be rewritten and embedded in this Perl framework, which is outside the scope of the project. In addition, direct comparison of txtfile16 or xfile016 data to PMAXS data only tests the capability of GenPMAXS to convert TRITON data to PMAXS format, which does not ensure that TRITON is producing correct or valid data. In order to test both TRITON and GenPMAXS capabilities, we have first verified that TRITON and GenPMAXS are producing valid results for all test cases. The files from those test cases are then considered blessed; i.e., provide valid and reasonable results for each test case. The blessed files (txtfile16 or xfile016 for TRITON or PMAXS for GenPMAXS) are then compared to any data generated using future versions of TRITON and GenPMAXS. By comparing to the blessed results, problem areas in either TRITON or GenPMAXS can be quickly identified.
In this project, ORNL was responsible for writing the overall framework for the regression testing utility and the TRITON xfile016 converter and txtfile16 file reader modules. University of Michigan (UM) staff was responsible for the PMAXS file reader. In addition, ORNL generated the SCALE/TRITON input files for the test cases, while UM staff generated the PMAXS input files, and test input files for CASMO and HELIOS.
- 4. TEST CASE RESULTS As previously mentioned, a total of 19 test TRITON-GenPMAXS cases have been developed.
The results of the test cases are summarized in this section. During this project, ORNL and UM staff coordinated to ensure that the data generated by TRITON was properly converted to PMAXS format by the current developmental version of GenPMAXS. All test cases have been reviewed by visual inspection to verify that data are being correctly converted from the TRITON xfile016 files to the PMAXS files.
One desirable feature of the test cases is quick run-time; as such, the TRITON cases have been developed using options that decrease CPU time but fully-test important functionality.
Generating the PMAXS files from the TRITON data requires an almost negligible amount of CPU, so the computational cost of running the test case matrix is almost entirely dependent on the time required for the TRITON calculations. Regenerating all the TRITON results on a single processor in Linux required ~3.5 hours5.787037e-5 days <br />0.00139 hours <br />8.267196e-6 weeks <br />1.9025e-6 months <br />. Once the TRITON and GenPMAXS outputs have been regenerated, the regression test suite takes less than 1 minute to perform the testing and produce an interactive HTML report. It is expected that similar runtimes would be observed for Windows and Mac operating systems.
For each test case in the following subsection, a basic description of the test case is given. The pass/fail criteria have been assessed and are signified with a pass of fail. If all tests in the major categories (Lattice Physics Parameters or Miscellaneous Parameters) have passed, then the major category alone is given an assessment. If any of the sub-categories fail, those are assessed as well. In the current version of TRITON and GenPMAXS, all tests pass the pass/fail criteria. This section is intended to be updated in the future to assess which tests or parts of tests pass or fail to facilitate efficient communication between the TRITON and GenPMAXS developers.
4.1. Test Case 01 - PWR pin cell depletion Description
- PWR pin cell (section 2.1) depletion model at HFP
- 700 ppm boron
- 4.95% enriched UO2
- 80 GWD/MTU burnup, 10 depletion steps (11 statepoints) o 0, 4, 12, 20, 28, 36, 44, 52, 60, 68, 76 GWD/MTU
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 11 statepoints) o Absorption (2 x 11) o Nu-fission (2x11) o Kappa-fission (2x11) o Fission (2x11) o Xe micro (2x11) o Sm micro (2x11) o Inverse velocity (2x11) o FP yields (Xe, I, and Pm) (3x11) o Betas/Lambdas group 1-6 (12x11) o Scatter Matrix (4x11) o Total: (35x11) 385 total
- Miscellaneous Parameters (pass) o Burnup Values o Visually inspect GenPMAXS.kinf file for errors/warnings
4.2. Test Case 02 - PWR pin cell depletion with branches Description
- Based on Westinghouse 17x17 assembly design
- 700 ppm boron
- 4.95% enriched UO2
- 20 GWD/MTU burnup, 3 depletion steps (4 statepoints) o 0, 4, 12, 18 GWD/MTU
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
- Reference + 6 Branches (7 total) o
Reference:
TF=900 DC=0.723 PC=700 CR=0 o Branch 1: DC: DC=0.500 o Branch 2: DC: DC=1.00 o Branch 3: PC: PC=2200 o Branch 4: TF: TF=293 o Branch 5: PC/TF: TF=293 PC=2200 o Branch 6: DC/PC/TF: TF=293 DC=1.0 PC=2200 Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4) o Total: (35x4x7) 980 total
- Miscellaneous Parameters (pass) o Burnup Values o Branch Conditions o Visually inspect GenPMAXS.kinf file for errors/warnings
4.3. Test Case 03 - BWR pin cell depletion with branches Description
- BWR pin cell (Sect. 2.2) depletion model with branches
- 40 void fraction (0.4572 g/cc)
- 4.95% enriched UO2
- 20 GWD/MTU burnup, 3 depletion steps (4 statepoints) o 0, 4, 12, 18 GWD/MTU
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
- Reference + 4 Branches o
Reference:
DC=0.4572 TF=900 (40 void) o Branch 1: DC: DC=0. 738079 (0 void) o Branch 2: DC: DC=0.176345 (80 void) o Branch 3: TF: TF=1200 o Branch 4: DC/TF: TF=293 DC=1.0 (CZP)
Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4) o Total: (35x5x4) 700 total
- Miscellaneous Parameters (pass) o Burnup Values o Branch Conditions o Visually inspect GenPMAXS.kinf file for errors/warnings
4.4. Test Case 04 - PWR mini lattice depletion with histories and branches Description
- PWR mini assembly (Sect. 2.3) with depletion histories and branches
- 4.95% enriched UO2
- 20 GWD/MTU burnup, 3 depletion steps (4 statepoints) o 0, 4, 12, 18 GWD/MTU
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
- Reference History o Depletion Condition: (PC=700 ppm, DC=0.7, CR=0, TF=900) o Branch 1: CR: CR=1 o Branch 2: PC: PC=2200 o Branch 3: DC: DC=0.9 o Branch 4: TF: TF=1200
- CR History o Depletion Condition: (PC=700 ppm, DC=0.7, CR=1, TF=900) o Branch 1: CR: CR=0 o Branch 2: PC: PC=2200 (with CR=0) o Branch 3: DC: DC=0.9 (with CR=0) o Branch 4: TF: TF=1200 (with CR=0)
- DC History o Depletion Condition: (PC=700 ppm, DC=0.9, CR=0, TF=900) o Branch 1: CR: CR=1 (with DC=0.7) o Branch 2: PC: PC=2200 (with DC=0.7) o Branch 3: DC: DC=0.7 o Branch 4: TF: TF=1200 (with DC=0.7)
- PC History o Nominal: (PC=2200 ppm, DC=0.7, CR=0, TF=900) o Branch 1: CR: CR=0 (with PC=700) o Branch 2: PC: PC=2200 o Branch 3: DC: DC=0.9(with PC=700) o Branch 4: TF: TF=1200(with PC=700)
Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4)
o East and North Face ADFs (2 x 4) o Total: (35x5x4x4) 3120 total
- Miscellaneous Parameters (pass) o Burnup Values o Branch Conditions o Visually inspect GenPMAXS.kinf file for errors/warnings
4.5. Test Case 05 - BWR mini lattice depletion with histories and branches Description
- BWR mini assembly model (Sect 3.4) with depletion histories and branches
- Modeling 2.93% UO2 pins and 1 Gd2O3 pin (2.93% 235U, 3% Gd2O3)
- 20 GWD/MTU burnup, 3 depletion steps o 0, 4, 12, 18 GWD/MTU
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
- Reference History o Depletion Condition: (DC=0. 457211, CR=0, TF=950) o Branch 1: DC1: DC=0. 738079 (0% void) o Branch 2: CR: CR=1 o Branch 3: DC2: DC=0. 176345 (80% void) o Branch 4: TF: TF=1200
- DC History o Depletion Condition: (DC=0.738079, CR=0, TF=950) (0%void) o Branch 1: DC1: DC=0. 457211 (40% void) o Branch 2: CR: CR=1 (with DC=0. 457211) o Branch 3: DC2: DC=0. 176345 (80% void) o Branch 4: TF: TF=1200 (with DC=0. 457211)
- DC History o Depletion Condition: (DC=0. 176345, CR=0, TF=950) (80%void) o Branch 1: DC1: DC=0. 457211 (40% void) o Branch 2: CR: CR=1 (with DC=0. 457211) o Branch 3: DC2: DC=0. 738079 (0% void) o Branch 4: TF: TF=1200 (with DC=0. 457211)
- CR History o Depletion Condition: (DC=0. 457211, CR=1, TF=950) o Branch 1: DC1: DC=0. 738079 (with CR=0) (0% void) o Branch 2: CR: CR=0 o Branch 3: DC2: DC=0. 176345 (with CR=0) (80% void) o Branch 4: TF: TF=1200 (with CR=0)
Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4)
o East and North Face ADFs (2 x 4) o Total: (35x5x4x4) 3120 total
- Miscellaneous Parameters (pass) o Burnup Values o Branch Conditions o Visually inspect GenPMAXS.kinf file for errors/warnings
4.6. Test Case 06 - PWR BOL full assembly with CDFs, PPFs, GFFs, and Det XS Description
- Westinghouse 17x17 assembly design, quarter symmetry (Sect. 3.5)
- 700 ppm boron
- 4.95% enriched UO2
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4) o North and East Face ADFs (2 groups) o PPFs (81 pins) o GFFs (81 pins by 2 groups) o CDFs (4 corners + 4 faces, by 2 groups) o Detector XS (2 groups) o Total: 300 total
- Miscellaneous Parameters (pass) o Visually inspect GenPMAXS.kinf file for errors/warnings
4.7. Test Case 07 - BWR BOL full assembly, with CDFs, PPFs, GFFs, and Det XS Description
- Lattice type 3a, Peach Bottom Cycle 1 model from EPRI report (Sect. 3.6)
- 40% void
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4) o North and East Face ADFs (2 groups) o PPFs (49 pins) o GFFs (49 pins by 2 groups) o CDFs (4 corners + 4 faces, by 2 groups) o Detector XS (2 groups) o Total: 204 total
- Miscellaneous Parameters (pass) o Visually inspect GenPMAXS.kinf file for errors/warnings
4.8. Test Case 08 - PWR assembly/reflector model Description
- Westinghouse 17x17 assembly design with reflector region (Sect. 2.7)
- 700 ppm boron
- 4.95% enriched UO2
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4) o Reflector ADFs (2 groups) o Total: 37 total
- Miscellaneous Parameters (pass) o Visually inspect GenPMAXS.kinf file for errors/warnings
4.9. Test Case 09 - BWR assembly/reflector model Description
- Lattice type 3a, Peach Bottom Cycle 1 model from EPRI report with reflector region (Sect. 3.8)
- 40% void
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4) o Reflector ADFs (2 groups) o Total: 37 total
- Miscellaneous Parameters (pass) o Visually inspect GenPMAXS.kinf file for errors/warnings
4.10. Test Case 10 - PWR assembly/reflector model (type-3 ADF)
Description
- Westinghouse 17x17 assembly design with reflector region (Sect. 2.7)
- 700 ppm boron
- 4.95% enriched UO2
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
- Test type-3 ADFs in TRITON (fluxes + currents, originally developed for HTGRs).
Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4) o Reflector fluxes (2 groups) o Reflector currents (2 groups) o Total: 39 total
- Miscellaneous Parameters (pass) o Visually inspect GenPMAXS.kinf file for errors/warnings
4.11. Test Case 11 - BWR assembly/reflector model Description
- Lattice type 3a, Peach Bottom Cycle 1 model from EPRI report with reflector region (Sect. 3.8)
- 40% void
- 44-group ENDF/B-V library collapsed to 2 group cross sections (E1=0.625 eV)
- Test type-3 ADFs in TRITON (fluxes + currents).
Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4) o Reflector fluxes (2 groups) o Reflector currents (2 groups) o Total: 37 total
- Miscellaneous Parameters (pass) o Visually inspect GenPMAXS.kinf file for errors/warnings
4.12. Test Case 12 - BWR pin cell depletion with branches + IUP option Description
- Identical TRITON input file as test case 03
- GenPMAXS IUP options is utilized Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4) o Total: (35x5x4) 700 total
- Miscellaneous Parameters (pass) o Burnup Values o Branch Conditions o Visually inspect GenPMAXS.kinf file for errors/warnings
4.13. Test Case 13 - BWR pin cell depletion with branches, 4G XS Description
- Same as test case 3, with the exception of the group structure
- 44-group ENDF/B-V library collapsed to 4 group cross sections (E1=900 keV, E2=8 eV, E3=0.15 eV)
Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (4 groups x 4 statepoints) o Absorption (4 x 4) o Nu-fission (4 x 4) o Kappa-fission (4 x 4) o Fission (4 x 4) o Xe micro (4 x 4) o Sm micro (4 x 4) o Inverse velocity (4 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (16 x 4) o Total: (63x5x4) 1260 total
- Miscellaneous Parameters (pass) o Burnup Values o Branch Conditions o Visually inspect GenPMAXS.kinf file for errors/warnings
4.14. Test Case 14 - BWR pin cell depletion with branches, 44G XS Description
- Same as test case 13, with the exception of the group structure
- 44-group cross sections whose group boundaries correspond to the 44-group SCALE XS library Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (44 groups x 4 statepoints) o Absorption (44 x 4) o Nu-fission (44 x 4) o Kappa-fission (44 x 4) o Fission (44 x 4) o Xe micro (44 x 4) o Sm micro (44 x 4) o Inverse velocity (44 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (1936 x 4) o Total: (2303x5x4) 46060 total
- Miscellaneous Parameters (pass) o Burnup Values o Branch Conditions o Visually inspect GenPMAXS.kinf file for errors/warnings
4.15. Test Case 15 - BWR mini lattice depletion with histories and branches Description
- Identical to test 5
- Included to test combining multiple PMAXS files into a single PMAXS file, rather than combining multiple xfile016 files into a single PMAXS file.
Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4) o East and North Face ADFs (2 x 4) o Total: (35x5x4x4) 3120 total
- Miscellaneous Parameters (pass) o Burnup Values o Branch Conditions o Visually inspect GenPMAXS.kinf file for errors/warnings
4.16. Test Case 16 - BWR mini lattice depletion with histories and branches Description
- Same as test case 05, but only the reference history (40% void) is modeled.
- The control blade is modeled in the northeast corner of the model
- Requires remapping of ADFs in GenPMAXS Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4) o East and South Face ADFs (2 x 4) o Total: (35x5x4x4) 3120 total
- Miscellaneous Parameters (pass) o Burnup Values o Branch Conditions o Visually inspect GenPMAXS.kinf file for errors/warnings
4.17. Test Case 17 - PWR BOL full assembly with CDFs, PPFs, GFFs, and Det XS Description
- Same as test 6
- The southwest quadrant of the fuel assembly has been modeled to test ADF remapping in GenPMAXS.
Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4) o North and East Face ADFs (2 groups) o PPFs (81 pins) o GFFs (81 pins by 2 groups) o CDFs (4 corners + 4 faces, by 2 groups) o Detector XS (2 groups) o Total: 300 total
- Miscellaneous Parameters (pass) o Visually inspect GenPMAXS.kinf file for errors/warnings
4.18. Test Case 18 - PWR pin cell depletion with branches Description
- Same as test case 02
- Moderator density branches are co-branched (temperature and moderator density modified simultaneously)
- The branch structure is input in GenPMAXS, rather than read from the TRITON xfile016 file.
- Reference + 6 Branches (7 total) o
Reference:
TF=900 DC=0.723 PC=700 CR=0 o Branch 1: DC: DC=0.500 TC=600K in TRITON o Branch 2: DC: DC=1.00 TC=293K in TRITON o Branch 3: PC: PC=2200 o Branch 4: TF: TF=293 o Branch 5: PC/TF: TF=293 PC=2200 o Branch 6: DC/PC/TF: TF=293 DC=1.0 PC=2200 TC=293K in TRITON Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4) o Total: (35x4x7) 980 total
- Miscellaneous Parameters (pass) o Burnup Values o Branch Conditions o Visually inspect GenPMAXS.kinf file for errors/warnings
4.19. Test Case 19 -BWR mini lattice depletion with histories and branches Description
- Same as test 5
- Only the reference history (40% void) is modeled
- Added a BWR boron branch with boron injected in-channel and out-channel at different concentrations.
- Utilizes the flexible branch block option in TRITON.
- Reference History o Depletion Condition: (DC=0. 457211, CR=0, TF=950) o Branch 1: CR: CR=1 o Branch 2: DC1: DC=0. 738079 (0% void) o Branch 3: PC: PC=600 ppm o Branch 4: DC2: DC=0. 176345 (80% void)
Pass/Fail Criteria:
- Lattice Physics Parameters (pass) o Transport cross section (2 groups x 4 statepoints) o Absorption (2 x 4) o Nu-fission (2 x 4) o Kappa-fission (2 x 4) o Fission (2 x 4) o Xe micro (2 x 4) o Sm micro (2 x 4) o Inverse velocity (2 x 4) o FP yields (Xe, I, and Pm) (3 x 4) o Betas/Lambdas group 1-6 (12 x 4) o Scatter Matrix (4 x 4) o East and North Face ADFs (2 x 4) o Total: (37x5x4) 740 total
- Miscellaneous Parameters (pass) o Burnup Values o Branch Conditions o Visually inspect GenPMAXS.kinf file for errors/warnings
Table 1: SCALE-GenPMAXS Test Matrix Coverage Test Case Reactor Model Groups BOL, Depletion Only, Branches, Histories+Branches Burnup Macros / D Kinetics Xe/Sm
>2G XS Fuel ADFs Reflector ADFs (Type 2)
Reflector ADFs (Type 3)
CDFs GFFs Det. XS CR Branch PC Branch PWR TH Branch BWR TH Branch CR History PC History PWR TH History BWR TH History PMAX Merge ADF Remap GENPMAXS Input of Case Matrix IUP Option 1
LWR Pin Cell 2
Depletion Only X X X X 2
PWR Pin Cell 2
Branches X X X X X
3 BWR Pin Cell 2
Branches X X X X X
4 PWR 3x3 2
H+B X X X X X
X X X X X X 5
BWR 3x3 2
H+B X X X X X
X X X X
6 PWR Assembly 2
BOL X X X X
X X X 7
BWR Assembly 2
BOL X X X X
X X X 8
PWR Assm/Refl 2
BOL X X X X
9 BWR Assm/Refl 2
BOL X X X X
10 PWR Assm/Refl 2
BOL X X X X
11 BWR Assm/Refl 2
BOL X X X X
12 BWR Pin Cell 2
Branches X X X X X
X 13 BWR Pin Cell 4
Branches X X X X X X
14 BWR Pin Cell
>4 Branches X X X X X X
15 BWR 3x3 2
H+B X X X X X
X X X X X 16 BWR 3x3 2
Branches X X X X X
X X X X
X 17 PWR Assembly 2
BOL X X X X
X X X X
18 PWR 3x3 2
Branches X X X X X
X 19 BWR 3 3 2
B h
X X X X X
X X
REFERENCES
- 1. Matthew A. Jessee, Brian J. Ade, and Andrew Ward, Test Requirement Specifications for the SCALE-GenPMAXS Unified Test Suite, ORNL Letter Report ORNL/LTR-2012/326, August 17, 2012.
- 2. Scale: A Comprehensive Modeling and Simulation Suite for Nuclear Safety Analysis and Design, ORNL/TM-2005/39, Version 6.1. Available from Radiation Safety Information Computational Center at Oak Ridge National Laboratory as CCC-785. (2011).
- 3. M. D. DeHart and S. M. Bowman, Reactor Physics Methods and Analysis Capabilities in Scale, Nuclear Technology, 174, pp. 196-213 (2011).
- 4. Y. Xu, and T. Downar, GenPMAXS-V6, Code for Generating the PARCS Cross Section Interface File PMAXS, User Manual, Department of Nuclear Engineering and Radiological Sciences, University of Michigan, Ann Arbor, MI (2012).
- 5. T. Downar, Y. Xu, and V. Seker, PARCS V3.0, U.S. NRC Core Neutronics Simulator, User Manual, Department of Nuclear Engineering and Radiological Sciences, UM-NERS-09-0001, University of Michigan, Ann Arbor, MI (2012).
- 6. Core Design and Operating Data for Cycles 1 and 2 of Peach Bottom 2, Technical Report EPRI NP-563, Electric Power Research Institute (1978).
- 7. Brian J. Ade, SCALE/TRITON-PARCS Code Validation with BWR Steady-State Plant Operating Data, ORNL/TM-2011/256, 2011.
ORNL/LTR-2013/8 Reactor and Nuclear Systems Division LETTER REPORT Unified Testing for SCALE and PARCS Development Work Benchmark Package William A. Wieselquist Brian J. Ade Matthew A. Jessee Andrew Ward, University of Michigan Date published: January 7, 2013 Prepared for Office of Nuclear Regulatory Research U.S. Nuclear Regulatory Commission Washington, D.C. 20555-0001 JCN F6028, Task 3 Prepared by OAK RIDGE NATIONAL LABORATORY Oak Ridge, Tennessee 37831-6285 managed by UT-BATTELLE, LLC for the U.S. DEPARTMENT OF ENERGY under contract DE-AC05-00OR22725
Maximum Extended Load Line Limit Application Plus (MELLLA+) - GE14 fuel H
Added a flexible branch structure capability in TRITON that allows modification of the in-channel and out-channel moderator separately, as well as the capability to model other complex phenomena H
Required a modification to GenPMAXS to read the new TRITON xfile016 file BWR Stability Analysis (Peach Bottom) - GE-7x7 fuel H
TRITON was modified to calculate more accurate kinetic parameters H
Issue was found in GenPMAXS with specification of the reference state H
Required changes to TRITON and GenPMAXS to maintain compatibility BWR Steady-State Depletion and Control Rod Drift (Hatch) - GE-7x7, GE-8x8 H
An issue was identified for reflector data calculations in which the order of a parameter in the TRITON input file results in incorrect data read by GenPMAXS H
Required a GenPMAXS code update to maintain compatibility Because of the short timeframe in most projects, using the standard quality assurance process for a major release of SCALE/TRITON or GenPMAXS was not feasible for these types of modifications. An easy-to-use tool to help verify consistency between TRITON and GenPMAXS, constantly and quickly as incremental changes are made to both codes, is needed.
One approach would be to verify that each value in the PMAXS file corresponds correctly to a value in a TRITON file. However, GenPMAXS has the capability to restructure the actual data points contained in the lattice physics data file, for example, interpolating to a different set of statepoints or removing unnecessary data, and thus such a one-to-one comparison cannot easily be made. Restructuring capabilities could also be added to the verification tool, but as more and more capabilities are added, such a tool eventually would become a complete re-write of GenPMAXS itself. Therefore, it was decided to focus on regression testing, which is comparing a set of verified TRITON and GenPMAXS files to new ones and reporting any differences.
The test cases were described in detail in the Task 2 letter report [2]. To summarize, the set of cases was chosen to test the major functionality of both codes thoroughly but run quickly enough for an overnight turnaround of all test cases on a single-CPU personal computer. The test cases can be categorized as
pin-cell cases used to test basic functionality;
mini-assembly (3x3) cases used to test depletion, branch conditions, history variables; and
full-assembly cases used to test pin power, group form factors, detector data, and reflector data generation.
- 3. REGRESSION FRAMEWORK The fundamental component of the regression-testing framework is the capability to compare two files and report the differences. With small, simple files, differencing utilities such as diff on Linux/Unix can be used effectively to compare files. However, appropriately handling fixed precision numbers and the potential for small but acceptable differences and reporting those differences in a useful way for these specific types of files required the creation of new utilities.
The utilities are written in Perl using object-oriented design. Perl has excellent file parsing,
regular expression matching, a built-in testing framework called Test Anything Protocol (TAP),
and is available on all major operating systems.
The comparison framework has the following main features:
H readers for both txtfile16 and PMAXS files, H
two comparison modes (detailed and summary),
H powerful command-line utilities to view/extract data in files, H
regression tool producing interactive HTML comparison reports, and H
simple drag-and-drop execution of test cases on Windows.
Each of these features will be described in the following sections. For readers who are unfamiliar with Perl, please refer to Appendix A.
3.1. File Readers Perl modules are provided to read the TRITON txtfile16 and the PARCS PMAXS files as Scale::File::T16::Reader and Parcs::File::PMAXS::Reader.
For example, from within a Perl script, one would instantiate a txtfile16 reader object as follows where $file is the txtfile16 name and $inp is the optional input file name. The input file name is provided optionally in order to extract extra information from the input file that may be needed to fully characterize the branch cases. As soon as the reader is instantiated with the new method, the file is parsed and errors are logged. The txtfile16 reader stores all branch data (cross sections, ADFS, etc.) in a hierarchical structure that mimics the actual txtfile16 structure. Care has been taken to ensure the reader does only minimal interpretation of data and in the Scale::File::T16::Reader object, only 5 simple methods are provided:
$errors=$t16reader->getErrors(), which returns a list of errors (as strings) as an array reference;
$num=$t16reader->numErrors(), which returns the number of errors;
$header=$t16reader->getHeader(), which returns the header information from the txtfile16;
$status=t16reader->getStatus(), which returns a hash reference indicating whether or not certain pieces of data exists in the file; and
$data=$t16reader->getData(), which returns the data extracted as a hash reference.
Note that changes to the references above will corrupt the $t16readers internal structure, and if this is necessary, a deep clone should be made.
use Scale::File::T16::Reader; my $t16reader = Scale::File::T16::Reader->new($file,$inp);
use Storable qw(dclone);
my $data = dclone($t16reader->getData());
The PMAXS reader, Parcs::File::PMAXS::Reader, operates in essentially the same way.
3.2. Comparison Modes In order to compare two files, first the file is read in using the appropriate reader and then the comparison is made on the internal data structure, a hash. Two comparison modes are currently available:
detailed mode, which compares every piece of data individually and
summary mode, which compares data in groups using signatures.
In detailed mode, two files are read into memory using the appropriate reader. Then the comparison function moves recursively through the stored data, comparing every value it finds, reporting the result. The modules Scale::File::Utils and Parcs::File::Utils provide the recursive comparison functions and other miscellaneous utility functions for txtfile16 and PMAXS comparisons, respectively.
When comparing many txtfile16 and PMAXS files, the detailed comparison produces too much output to be useful. For this reason, a summary mode has been implemented, which is the recommended mode for running regressions tests where many files are compared. The summary mode is based on breaking the data into logical chunks, creating signatures for these chunks, and comparing signatures. The txtfile16 comparison uses the signatures shown in Figure 2.
use Scale::File::PMAXS::Reader; my $pmaxsreader = Scale::File::PMAXS::Reader->new($file);
Figure 4: Screenshot of t16stat --help.
The t16stat utility by default produces a table of contents, as shown in Figure 5. The first column is the depletion index and the second column is the branch point index, which both begin at 0. The branch index 0 indicates nominal or depletion conditions, whereas a branch index greater than zero indicates an instantaneous change in one of the state parameters.
Figure 5: Screenshot of t16stat table of contents for the Explicit branch format.
Additionally, there are two types of branch data formats allowed by TRITON. The Explicit format, shown in Figure 5, has explicitly defined branch variables for the fuel temperature, moderator temperature, moderator density, boron concentration, and control rod state (out=0/in=1). The General format, shown in Figure 6, allows users to define branches in terms of density perturbations and material swaps. In this case, the input file is required by t16stat in order to supply the extra branch identification information shown.
Figure 6: Screenshot of t16stat table of contents for the General branch format.
The t16extract utility allows one to extract information from the txtfile16. For example, in order to see the macroscopic total cross section at all statepoints, one could use the following command.
The screen output for this extraction is shown in Figure 7: the total cross section at each statepoint in the file. In the matching expression, we have included the '[' to prevent matching the total_transfer cross section as well.
Figure 7: Screenshot of t16extract for matching "macros/total[".
For more complex matching, a regular expression option can be specified. For example, the fast group total cross section as a function of the base depletion could be extracted using a regular expression as t16extract --match "macros/total[" myfile.t16
where the brackets must be escaped as '\\[' and '\\]', as should any other special regular expression characters. The result of the extraction is shown in Figure 8.
Figure 8: Screenshot of t16extract for regular expression matching
/.*/0/regions/.*/macros/total\\[1\\].
The last command-line utilities to be discussed are the comparison utilities, which form the basis of the regression tool discussed in the next section. The default option for the comparison tools is to output in a style similar to the extraction tool, but instead of a single value on the right, it reports 4 comma-delimited values: the type of comparison performed, difference, old value, new value.
The TYPE can have values ABS, REL, STRING, INT indicating the type of the old variable. The following rules are used to assign the value of DIFF.
- 1. If the types do not match or one value is not present, then DIFF=1.
- 2. If two strings (STRING) or integers (INT) do not match exactly then DIFF=1 (otherwise DIFF=0).
- 3. If the OLD value is identically zero, then an absolute comparison is made with DIFF=NEW-OLD and indicated with TYPE=ABS.
- 4. Otherwise, a relative comparison is made with DIFF=NEW/OLD-1 and indicated with TYPE=REL.
A typical comparison command to compare k-eff would have the following syntax where the old file is specified with the --old flag, shown in Figure 9.
Figure 9: Screenshot of t16compare output in summary mode.
The first number in brackets indicates the signature number, in this case the string keff is only found in the data signatures that begin at signature 6 (see Figure 2). Note that summary mode is the default mode. To turn on the detailed mode, pass the --fine flag, t16extract --regex /.*/0/regions/.*/macros/total\\[1\\] myfile.t16
/path/to/new/file/variable=TYPE,DIFF,OLD,NEW t16compare --old /path/to/old.t16 new.t16 --match keff
in which case the output is shown as in Figure 10.
Figure 10: Screenshot of t16compare output in detailed mode.
The final aspect of the comparison tools is the capability to turn the output into a sequence of tests using Perls Test Anything Protocol (TAP) by passing the --test flag. In this case a tolerance is used to decide whether a test passes or fails. The tolerance defaults to 1e-5.
The output of the test is shown in Figure 11. The test fails in one of the subtests of the first region statepoint data.
Figure 11: Screenshot of t16compare test output in summary mode.
In Figure 12, the same test is shown in the detailed output mode, in which there are 1550 reported tests, as opposed to the summary modes 16. The failure can easily be identified as a change in the fast group fission cross section.
Figure 12: Screenshot of t16compare test output in detailed mode (truncated).
t16compare --old /path/to/old.t16 new.t16 --match keff --fine t16compare --old /path/to/old.t16 new.t16 --match keff --test --tol 1e-5
Figure 14: HTML regression report in summary mode.
Clicking on any box advances the screen to the actual TAP output line, as shown in Figure 15.
Figure 16 shows the detailed test output that can be generated by the html_report_harness_detailed.pl script. It is suggested to always initially run the regression tool in the summary mode and then for any failures, investigate further in detailed mode for a single case.
Figure 15: HTML regression report in summary mode after clicking on a red box.
Figure 16: HTML regression report in detailed mode.
3.5. Windows Drag-and-Drop Functionality On Microsoft Windows, the regression suite may simply be run by dragging a new directory or file onto the run.bat batch file included in the root directory of the suite (see Figure 1).
Figure 17: Root directory of the regression suite with run.bat highlighted.
The run.bat script is hard-coded to consider the directory BASELINE (in the root directory) the OLD directory for the regression test. The run_detailed.bat script simply runs in the detailed output mode.
To drag-and-drop from a more convenient location, e.g. the desktop, simply right-click and create a shortcut. Then rename and move this shortcut to the desired location.
REFERENCES
- 1. Matthew A. Jessee, Brian J. Ade, and Andrew Ward, Test Requirement Specifications for the SCALE-GenPMAXS Unified Test Suite, ORNL Letter Report ORNL/LTR-2012/326, August 17, 2012.
- 2. Brian J. Ade, Matthew A. Jessee, William A. Wieselquist, and Andrew Ward, The SCALE-GenPMAXS Unified Test Suite, ORNL Letter Report ORNL/LTR-2012/612, December 19, 2012.
- 3. SCALE: A Comprehensive Modeling and Simulation Suite for Nuclear Safety Analysis and Design, ORNL/TM-2005/39, Version 6.1. Available from Radiation Safety Information Computational Center at Oak Ridge National Laboratory as CCC-785. (2011).
- 4. M. D. DeHart and S. M. Bowman, Reactor Physics Methods and Analysis Capabilities in Scale, Nuclear Technology, 174, pp. 196-213 (2011).
- 5. Y. Xu, and T. Downar, GenPMAXS-V6, Code for Generating the PARCS Cross Section Interface File PMAXS, User Manual, Department of Nuclear Engineering and Radiological Sciences, University of Michigan, Ann Arbor, MI (2012).
- 6. T. Downar, Y. Xu, and V. Seker, PARCS V3.0, U.S. NRC Core Neutronics Simulator, User Manual, Department of Nuclear Engineering and Radiological Sciences, UM-NERS-09-0001, University of Michigan, Ann Arbor, MI (2012).
- 7. Core Design and Operating Data for Cycles 1 and 2 of Peach Bottom 2, Technical Report EPRI NP-563, Electric Power Research Institute (1978).
- 8. Brian J. Ade, SCALE/TRITON-PARCS Code Validation with BWR Steady-State Plant Operating Data, ORNL/TM-2011/256, 2011.
APPENDIX A: Perl Basics Perl is a very versatile scripting language with a large, active user community. The first thing to understand about Perl is the main data types: scalars, arrays, and hashes. A scalar is prefixed with $, an array with @, and a hash with %.
Accessing an element of an array or hash uses [] or {}.
Note that elements are prefixed with a $ because they are scalars and that Perl starts arrays at index 0. One of the most powerful data structures in Perl is the hash reference. Because the key and value in hashes must be scalars, a hierarchical structure may be easily constructed from hashes whose values are hash (or array) references. These types of hashes are used to store the data read from txtfile16 and PMAXS files. Accessing the data simply requires knowing the chain of keys to access a particular piece of data. For example, to print the first burnup in the file, where the -> is used to dereference at each level and note that at the final level the burnups are stored in an array.
The next thing to understand is that there are two types of Perl files: scripts and modules. Scripts are run from the command line using the Perl interpreter as and generally have a pl or no extension. To support code reuse and object-oriented programming, Perl uses modules, which have a pm extension. For example, the module File::Slurp, contains a function to read an entire file into a string, called slurp. The following complete Perl script would use that function to print out the contents of the script referenced above.
Almost everything one could want to do has already been done and packaged up in a Perl moduleit is just a question of finding it (or choosing between some) on the Comprehensive Perl Archive Network (http://www.cpan.org/).
$scalar=1;
$scalar=string;
@array=(1,2,3);
@array=qw(list of 1 2 3); #easy space-delimited list yields (list,of,1,2,3)
%hash=(color=>green,shape=>circle); #key/value pairs print $array[0]; #will print 1 print $hash{color}; #will print green print $t16reader->{header}->{burnups}->[0];
perl /path/to/myscript.pl use File::Slurp slurp;
$text = slurp(/path/to/myscript.pl);
print $text;
In order to use a module, the Perl interpreter must be able to find it. The name of the module, e.g. File::Slurp, actually translates to a file name File/Slurp.pm which should be available to the interpreter. There are numerous ways to tell the interpreter where this file is. The most common is to use the environmental variable $PERL5LIB which contains a list of colon-delimited paths. For example, if you exported the following $PERL5LIB, the interpreter would look to location mylib/File/Slurp.pm for the File::Slurp module. The alternative method, used in these utilities, is to use a module called lib which adds potential module locations.
The important thing to remember is that all the scripts provided use the lib method, which has the advantage that it doesnt require modifying any environmental variables. Additionally, if relative paths are used, it will work regardless of where one moves the root directory. The disadvantage is that scripts can only be run from specific places where the lib paths are valid. In these utilities, it is from outside their directory.
The final result is that to run the scripts from any directory on the computer, one must add not only the bin directory to $PATH, but the lib directory to $PERL5LIB.
export PERL5LIB=mylib:$PERL5LIB use lib mylib; #adds the directory mylib to the module search path use File::Slurp slurp;
$text = slurp(/path/to/myscript.pl);
print $text; perl bin/t16stat /path/to/txtfile16 export PATH=path/to/bin:$PATH export PERL5LIB=path/to/lib:$PERL5LIB
31310020D0007 / 31310023F0047 Attachment No. 7 1
Subpart 2009.5 Organizational Conflicts of Interest
§2009.500 Scope of subpart.
In accordance with 42 U.S.C. 2210a., NRC acquisitions are processed in accordance with
§2009.570, which takes precedence over FAR 9.5 with respect to organizational conflicts of interest. Where non-conflicting guidance appears in FAR 9.5, that guidance must be followed.
§2009.570 NRC organizational conflicts of interest.
§2009.570-1 Scope of policy.
(a) It is the policy of NRC to avoid, eliminate, or neutralize contractor organizational conflicts of interest. The NRC achieves this objective by requiring all prospective contractors to submit information describing relationships, if any, with organizations or persons (including those regulated by the NRC) which may give rise to actual or potential conflicts of interest in the event of contract award.
(b) Contractor conflict of interest determinations cannot be made automatically or routinely.
The application of sound judgment on virtually a case-by-case basis is necessary if the policy is to be applied to satisfy the overall public interest. It is not possible to prescribe in advance a specific method or set of criteria which would serve to identify and resolve all of the contractor conflict of interest situations that might arise. However, examples are provided in these regulations to guide application of this policy guidance. The ultimate test is as follows: Might the contractor, if awarded the contract, be placed in a position where its judgment may be biased, or where it may have an unfair competitive advantage?
(c) The conflict of interest rule contained in this subpart applies to contractors and offerors only. Individuals or firms who have other relationships with the NRC (e.g., parties to a licensing proceeding) are not covered by this regulation. This rule does not apply to the acquisition of consulting services through the personnel appointment process, NRC agreements with other Government agencies, international organizations, or state, local, or foreign Governments. Separate procedures for avoiding conflicts of interest will be employed in these agreements, as appropriate.
§2009.570-2 Definitions.
Affiliates means business concerns which are affiliates of each other when either directly or indirectly one concern or individual controls or has the power to control another, or when a third party controls or has the power to control both.
Contract means any contractual agreement or other arrangement with the NRC except as provided in §2009.570-1(c).
Contractor means any person, firm, unincorporated association, joint venture, co-sponsor, partnership, corporation, affiliates thereof, or their successors in interest, including their chief executives, directors, key personnel (identified in the contract), proposed consultants or subcontractors, which are a party to a contract with the NRC.
Evaluation activities means any effort involving the appraisal of a technology, process, product, or policy.
Offeror or prospective contractor means any person, firm, unincorporated association, joint venture, co-sponsor, partnership, corporation, or their affiliates or successors in interest,
31310020D0007 / 31310023F0047 Attachment No. 7 2
including their chief executives, directors, key personnel, proposed consultants, or subcontractors, submitting a bid or proposal, solicited or unsolicited, to the NRC to obtain a contract.
Organizational conflicts of interest means that a relationship exists whereby a contractor or prospective contractor has present or planned interests related to the work to be performed under an NRC contract which:
(1) May diminish its capacity to give impartial, technically sound, objective assistance and advice, or may otherwise result in a biased work product; or (2) May result in its being given an unfair competitive advantage.
Potential conflict of interest means that a factual situation exists that suggests that an actual conflict of interest may arise from award of a proposed contract. The term potential conflict of interest is used to signify those situations that (1) Merit investigation before contract award to ascertain whether award would give rise to an actual conflict; or (2) Must be reported to the contracting officer for investigation if they arise during contract performance.
Research means any scientific or technical work involving theoretical analysis, exploration, or experimentation.
Subcontractor means any subcontractor of any tier who performs work under a contract with the NRC except subcontracts for supplies and subcontracts in amounts not exceeding $10,000.
Technical consulting and management support services means internal assistance to a component of the NRC in the formulation or administration of its programs, projects, or policies which normally require that the contractor be given access to proprietary information or to information that has not been made available to the public. These services typically include assistance in the preparation of program plans, preliminary designs, specifications, or statements of work.
§2009.570-3 Criteria for recognizing contractor organizational conflicts of interest.
(a) General.
(1) Two questions will be asked in determining whether actual or potential organizational conflicts of interest exist:
(i) Are there conflicting roles which might bias an offeror's or contractor's judgment in relation to its work for the NRC?
(ii) May the offeror or contractor be given an unfair competitive advantage based on the performance of the contract?
(2) NRC's ultimate determination that organizational conflicts of interest exist will be made in light of common sense and good business judgment based upon the relevant facts. While it is difficult to identify and to prescribe in advance a specific method for avoiding all of the various situations or relationships that might involve potential organizational conflicts of interest, NRC personnel will pay particular attention to proposed contractual requirements that call for the
31310020D0007 / 31310023F0047 Attachment No. 7 3
rendering of advice, consultation or evaluation activities, or similar activities that directly lay the groundwork for the NRC's decisions on regulatory activities, future procurements, and research programs. Any work performed at an applicant or licensee site will also be closely scrutinized by the NRC staff.
(b) Situations or relationships. The following situations or relationships may give rise to organizational conflicts of interest:
(1) The offeror or contractor shall disclose information that may give rise to organizational conflicts of interest under the following circumstances. The information may include the scope of work or specification for the requirement being performed, the period of performance, and the name and telephone number for a point of contact at the organization knowledgeable about the commercial contract.
(i) Where the offeror or contractor provides advice and recommendations to the NRC in the same technical area where it is also providing consulting assistance to any organization regulated by the NRC.
(ii) Where the offeror or contractor provides advice to the NRC on the same or similar matter on which it is also providing assistance to any organization regulated by the NRC.
(iii) Where the offeror or contractor evaluates its own products or services, or has been substantially involved in the development or marketing of the products or services of another entity.
(iv) Where the award of a contract would result in placing the offeror or contractor in a conflicting role in which its judgment may be biased in relation to its work for the NRC, or would result in an unfair competitive advantage for the offeror or contractor.
(v) Where the offeror or contractor solicits or performs work at an applicant or licensee site while performing work in the same technical area for the NRC at the same site.
(2) The contracting officer may request specific information from an offeror or contractor or may require special contract clauses such as provided in §2009.570-5(b) in the following circumstances:
(i) Where the offeror or contractor prepares specifications that are to be used in competitive procurements of products or services covered by the specifications.
(ii) Where the offeror or contractor prepares plans for specific approaches or methodologies that are to be incorporated into competitive procurements using the approaches or methodologies.
(iii) Where the offeror or contractor is granted access to information not available to the public concerning NRC plans, policies, or programs that could form the basis for a later procurement action.
(iv) Where the offeror or contractor is granted access to proprietary information of its competitors.
(v) Where the award of a contract might result in placing the offeror or contractor in a conflicting role in which its judgment may be biased in relation to its work for the NRC or might result in an unfair competitive advantage for the offeror or contractor.
31310020D0007 / 31310023F0047 Attachment No. 7 4
(c) Policy application guidance. The following examples are illustrative only and are not intended to identify and resolve all contractor organizational conflict of interest situations.
(1)(i) Example. The ABC Corp., in response to a Request For Proposal (RFP), proposes to undertake certain analyses of a reactor component as called for in the RFP. The ABC Corp. is one of several companies considered to be technically well qualified. In response to the inquiry in the RFP, the ABC Corp. advises that it is currently performing similar analyses for the reactor manufacturer.
(ii) Guidance. An NRC contract for that particular work normally would not be awarded to the ABC Corp. because the company would be placed in a position in which its judgment could be biased in relationship to its work for the NRC. Because there are other well-qualified companies available, there would be no reason for considering a waiver of the policy.
(2)(i) Example. The ABC Corp., in response to an RFP, proposes to perform certain analyses of a reactor component that is unique to one type of advanced reactor. As is the case with other technically qualified companies responding to the RFP, the ABC Corp. is performing various projects for several different utility clients. None of the ABC Corp. projects have any relationship to the work called for in the RFP. Based on the NRC evaluation, the ABC Corp. is considered to be the best qualified company to perform the work outlined in the RFP.
(ii) Guidance. An NRC contract normally could be awarded to the ABC Corp. because no conflict of interest exists which could motivate bias with respect to the work. An appropriate clause would be included in the contract to preclude the ABC Corp. from subsequently contracting for work with the private sector that could create a conflict during the performance of the NRC contract. For example, ABC Corp. would be precluded from the performance of similar work for the company developing the advanced reactor mentioned in the example.
(3)(i) Example. The ABC Corp., in response to a competitive RFP, submits a proposal to assist the NRC in revising NRC's guidance documents on the respiratory protection requirements of 10 CFR Part 20. ABC Corp. is the only firm determined to be technically acceptable. ABC Corp.
has performed substantial work for regulated utilities in the past and is expected to continue similar efforts in the future. The work has and will cover the writing, implementation, and administration of compliance respiratory protection programs for nuclear power plants.
(ii) Guidance. This situation would place the firm in a role where its judgment could be biased in relationship to its work for the NRC. Because the nature of the required work is vitally important in terms of the NRC's responsibilities and no reasonable alternative exists, a waiver of the policy, in accordance with §2009.570-9 may be warranted. Any waiver must be fully documented in accordance with the waiver provisions of this policy with particular attention to the establishment of protective mechanisms to guard against bias.
(4)(i) Example. The ABC Corp. submits a proposal for a new system to evaluate a specific reactor component's performance for the purpose of developing standards that are important to the NRC program. The ABC Corp. has advised the NRC that it intends to sell the new system to industry once its practicability has been demonstrated. Other companies in this business are using older systems for evaluation of the specific reactor component.
(ii) Guidance. A contract could be awarded to the ABC Corp. if the contract stipulates that no information produced under the contract will be used in the contractor's private activities unless this information has been reported to the NRC. Data on how the reactor component performs, which is reported to the NRC by contractors, will normally be disseminated by the NRC to others to preclude an unfair competitive advantage. When the NRC furnishes information about the reactor component to the contractor for the performance of contracted work, the information may not be used in the contractor's private activities unless the information is generally available to others. Further, the contract will stipulate that the
31310020D0007 / 31310023F0047 Attachment No. 7 5
contractor will inform the NRC contracting officer of all situations in which the information, developed about the performance of the reactor component under the contract, is proposed to be used.
(5)(i) Example. The ABC Corp., in response to a RFP, proposes to assemble a map showing certain seismological features of the Appalachian fold belt. In accordance with the representation in the RFP and §2009.570-3(b)(1)(i), ABC Corp. informs the NRC that it is presently doing seismological studies for several utilities in the eastern United States, but none of the sites are within the geographic area contemplated by the NRC study.
(ii) Guidance. The contracting officer would normally conclude that award of a contract would not place ABC Corp. in a conflicting role where its judgment might be biased. Section 2052.209-72(c) Work for Others, would preclude ABC Corp. from accepting work which could create a conflict of interest during the term of the NRC contract.
(6)(i) Example. AD Division of ABC Corp., in response to a RFP, submits a proposal to assist the NRC in the safety and environmental review of applications for licenses for the construction, operation, and decommissioning of fuel cycle facilities. ABC Corp. is divided into two separate and distinct divisions, AD and BC. The BC Division performs the same or similar services for industry. The BC Division is currently providing the same or similar services required under the NRC's contract for an applicant or licensee.
(ii) Guidance. An NRC contract for that particular work would not be awarded to the ABC Corp.
The AD Division could be placed in a position to pass judgment on work performed by the BC Division, which could bias its work for NRC. Further, the Conflict of Interest provisions apply to ABC Corp. and not to separate or distinct divisions within the company. If no reasonable alternative exists, a waiver of the policy could be sought in accordance with §2009.570-9.
(7)(i) Example. The ABC Corp. completes an analysis for NRC of steam generator tube leaks at one of a utility's six sites. Three months later, ABC Corp. is asked by this utility to perform the same analysis at another of its sites.
(ii) Guidance. Section 2052.290-72(c)(3) would prohibit the contractor from beginning this work for the utility until one year after completion of the NRC work at the first site.
(8)(i) Example. ABC Corp. is assisting NRC in a major on-site analysis of a utility's redesign of the common areas between its twin reactors. The contract is for two years with an estimated value of $5 million. Near the completion of the NRC work, ABC Corp. requests authority to solicit for a $100K contract with the same utility to transport spent fuel to a disposal site. ABC Corp. is performing no other work for the utility.
(ii) Guidance. The Contracting Officer would allow the contractor to proceed with the solicitation because it is not in the same technical area as the NRC work; and the potential for technical bias by the contractor because of financial ties to the utility is slight due to the relative value of the two contracts.
(9)(i) Example. The ABC Corp. is constructing a turbine building and installing new turbines at a reactor site. The contract with the utility is for five years and has a total value of $100 million. ABC Corp. has responded to an NRC Request For Proposal requiring the contractor to participate in a major team inspection unrelated to the turbine work at the same site. The estimated value of the contract is $75K.
(ii) Guidance. An NRC contract would not normally be awarded to ABC Corp. because these factors create the potential for financial loyalty to the utility that may bias the technical judgment of the contractor.
31310020D0007 / 31310023F0047 Attachment No. 7 6
(d) Other considerations.
(1) The fact that the NRC can identify and later avoid, eliminate, or neutralize any potential organizational conflicts arising from the performance of a contract is not relevant to a determination of the existence of conflicts prior to the award of a contract.
(2) It is not relevant that the contractor has the professional reputation of being able to resist temptations which arise from organizational conflicts of interest, or that a follow-on procurement is not involved, or that a contract is awarded on a competitive or a sole source basis.
§2009.570-4 Representation.
(a) The following procedures are designed to assist the NRC contracting officer in determining whether situations or relationships exist which may constitute organizational conflicts of interest with respect to a particular offeror or contractor. The procedures apply to small purchases meeting the criteria stated in the following paragraph (b) of this section.
(b) The organizational conflicts of interest representation provision at §2052.209-71 must be included in solicitations and contracts resulting from unsolicited proposals. The contracting officer must also include this provision for task orders and contract modifications for new work for:
(1) Evaluation services or activities; (2) Technical consulting and management support services; (3) Research; and (4) Other contractual situations where special organizational conflicts of interest provisions are noted in the solicitation and would be included in the resulting contract. This representation requirement also applies to all modifications for additional effort under the contract except those issued under the "Changes" clause. Where, however, a statement of the type required by the organizational conflicts of interest representation provisions has previously been submitted with regard to the contract being modified, only an updating of the statement is required.
(c) The offeror may, because of actual or potential organizational conflicts of interest, propose to exclude specific kinds of work contained in a RFP unless the RFP specifically prohibits the exclusion. Any such proposed exclusion by an offeror will be considered by the NRC in the evaluation of proposals. If the NRC considers the proposed excluded work to be an essential or integral part of the required work and its exclusion would be to the detriment of the competitive posture of the other offerors, the NRC shall reject the proposal as unacceptable.
(d) The offeror's failure to execute the representation required by paragraph (b) of this section with respect to an invitation for bids is considered to be a minor informality. The offeror will be permitted to correct the omission.
§2009.570-5 Contract clauses.
(a) General contract clause. All contracts and simplified acquisitions of the types set forth in
§2009.570-4(b) must include the clause entitled, "Contractor Organizational Conflicts of Interest," set forth in §2052.209-72.
31310020D0007 / 31310023F0047 Attachment No. 7 7
(b) Other special contract clauses. If it is determined from the nature of the proposed contract that an organizational conflict of interest exists, the contracting officer may determine that the conflict can be avoided, or, after obtaining a waiver in accordance with §2009.570-9, neutralized through the use of an appropriate special contract clause. If appropriate, the offeror may negotiate the terms and conditions of these clauses, including the extent and time period of any restriction. These clauses include but are not limited to:
(1) Hardware exclusion clauses which prohibit the acceptance of production contracts following a related non-production contract previously performed by the contractor; (2) Software exclusion clauses; (3) Clauses which require the contractor (and certain of its key personnel) to avoid certain organizational conflicts of interest; and (4) Clauses which provide for protection of confidential data and guard against its unauthorized use.
§2009.570-6 Evaluation, findings, and contract award.
The contracting officer shall evaluate all relevant facts submitted by an offeror and other relevant information. After evaluating this information against the criteria of §2009.570-3, the contracting officer shall make a finding of whether organizational conflicts of interest exist with respect to a particular offeror. If it has been determined that real or potential conflicts of interest exist, the contracting officer shall:
(a) Disqualify the offeror from award; (b) Avoid or eliminate such conflicts by appropriate measures; or (c) Award the contract under the waiver provision of §2009.570-9.
§2009.570-7 Conflicts identified after award.
If potential organizational conflicts of interest are identified after award with respect to a particular contractor and the contracting officer determines that conflicts do exist and that it would not be in the best interest of the Government to terminate the contract, as provided in the clauses required by §2009.570-5, the contracting officer shall take every reasonable action to avoid, eliminate, or, after obtaining a waiver in accordance with §2009.570-9, neutralize the effects of the identified conflict.
§2009.570-8 Subcontracts.
The contracting officer shall require offerors and contractors to submit a representation statement from all subcontractors (other than a supply subcontractor) and consultants performing services in excess of $10,000 in accordance with §2009.570-4(b). The contracting officer shall require the contractor to include contract clauses in accordance with §2009.570-5 in consultant agreements or subcontracts involving performance of work under a prime contract.
§2009.570-9 Waiver.
(a) The contracting officer determines the need to seek a waiver for specific contract awards with the advice and concurrence of the program office director and legal counsel. Upon the
31310020D0007 / 31310023F0047 Attachment No. 7 8
recommendation of the Senior Procurement Executive, and after consultation with legal counsel, the Executive Director for Operations may waive the policy in specific cases if he determines that it is in the best interest of the United States to do so.
(b) Waiver action is strictly limited to those situations in which:
(1) The work to be performed under contract is vital to the NRC program; (2) The work cannot be satisfactorily performed except by a contractor whose interests give rise to a question of conflict of interest.
(3) Contractual and/or technical review and surveillance methods can be employed by the NRC to neutralize the conflict.
(c) The justification and approval documents for any waivers must be placed in the NRC Public Document Room.
§2009.570-10 Remedies.
In addition to other remedies permitted by law or contract for a breach of the restrictions in this subpart or for any intentional misrepresentation or intentional nondisclosure of any relevant interest required to be provided for this section, the NRC may debar the contractor from subsequent NRC contracts.