Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “SQA”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 19 records
All sourcesNASA NTRSDOE OSTI
DOE OSTI2020

Overview of the MCNP6® SQA Plan and Requirements [Memorandum]

For all X Computational Physics Division (XCP) software under the Associate Laboratory Directorate for Weapons Physics (ALDX), the Weapons Research Services Secure Networks and Assurance Group (WRS-SNA) manages the software quality assurance (SQA) plan, requirements and guidance with respect to development processes and tools to meet the broader LANL SQA requirements. Each XCP software product is categorized into one of three software types: Safety Software, Non-Safety Risk Significant Software, and Non-Safety Commercially Controlled Software. In 2018, using LANL Form 2033, the MCNP6 code was categorized by the XCP division as Non-Safety Commercially Controlled Software, provided in Appendix A. Using WRSFORM- 0001U, the MCNP6 code was graded as a Medium Impact software product, provided in Appendix B. Given these determinations, the WRS-AD-0010U SQA plan is followed for all MCNP6 developments, documentation and code releases.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2015

Internal Indpendent Assessment Report - CASTLE-PX SQA

This IIA assessed the flow down of institutional 830 Software Quality Assurance requirements through three required document templates to the CASTLE-PX software effort and the implementation of those SQA requirements. The templates flow down the DOE O 414.1D consensus standard requirements for Safety Software. This assessment did not include the flow down of NAP-24, Weapon Quality Policy, requirements. The assessment focused on the CASTLE-PX project’s software development and release processes. It did not assess Pantex’s acceptance or usage of the software. The assessment resulted in 3 Deficiencies, 5 Observations, 1 Recommendation, and 3 Strengths. Overall the CASTLE-PX team demonstrated it values quality and has worked to integrate quality practices into its software development processes. Improvement in documentation will enhance their SQA implementation.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2016

Automating Nuclear-Safety-Related SQA Procedures with Custom Applications

Nuclear safety-related procedures are rigorous for good reason. Small design mistakes can quickly turn into unwanted failures. Researchers at Oak Ridge National Laboratory worked with COMSOL to define a simulation app that automates the software quality assurance (SQA) verification process and provides results in less than 24 hours.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2017

Status of SFR Codes and Methods QA Implementation

This report details development of the SAS4A/SASSYS-1 SQA Program and describes the initial stages of Program implementation planning. The provisional Program structure, which is largely focused on the establishment of compliant SQA documentation, is outlined in detail, and Program compliance with the appropriate SQA requirements is highlighted. Additional program activities, such as improvements to testing methods and Program surveillance, are also described in this report. Given that the programmatic resources currently granted to development of the SAS4A/SASSYS-1 SQA Program framework are not sufficient to adequately address all SQA requirements (e.g. NQA-1, NUREG/BR-0167, etc.), this report also provides an overview of the gaps that remain the SQA program, and highlights recommendations on a path forward to resolution of these issues. One key finding of this effort is the identification of the need for an SQA program sustainable over multiple years within DOE annual R&D funding constraints.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2021

Software Quality Assurance for EBR-II Fuels Irradiation and Physics Database (FIPD)

The Fuels Irradiation and Physics Database (FIPD) is an ongoing DOE project on archival of the EBR-II metal-alloy fuel irradiation experiments. As part of its use in support of license applications, the Quality Assurance Program Plan (QAPP) was drafted and endorsed by NRC in an effort to demonstrate its compliance with regulatory expectations. Software Quality Assurance (SQA) for the physics portion of FIPD is intended to qualify the calculated quantities such as fuel and cladding temperatures, neutron fluence and axially varying burnup estimates for irradiated fuel elements. This report covers the initial evaluation of SQA status of three neutron physics and thermo-fluid codes (REBUS, RCT and SE2RCT) that form the basis of calculated quantities for as-irradiated characteristics of the tested metallic fuel elements. The report also introduces an SQA plan to address the identified deficiencies. The REBUS, RCT, and SE2RCT codes are all part of the Argonne Reactor Code (ARC) code system. There is considerable knowledge and experience on REBUS and RCT but relatively less on SE2RCT. During FY2021, efforts focused on an assessment of how the data in the EBR-II Physics and Analysis DataBase (PADB) is generated with SE2RCT and used in FIPD. Additional tasks included considerations of uncertainties for power estimates in REBUS and RCT calculations and their impact on the combined RCT methodology. The RCT software usage in FIPD was assessed this year and the input/output details studied. A “requirements” document was created that identifies the key features of the RCT software being used in FIPD that need to have SQA documentation. A brief discussion on the history of RCT and its input is included in this report along with the basic SQA roadmap laid out in the requirements document. The SE2RCT software usage in FIPD is still being studied noting that there is no current manual. As part of the work done this year, two bugs were identified in the SE2RCT software which have a minor impact on the accuracy of the results it produces. No requirements document has been created, but one identified feature of SE2RCT being used that needs verification was its fuel pin temperature calculation. The work completed this year confirms that the approximations which will be included in the software verification report for SE2RCT are accurate. In addition to software quality assurance work for RCT and SE2RCT, an automated verification framework is proposed to simplify the software quality assurance process. The purpose of this framework is to streamline code verification and documentation while minimizing repetitive tasks for code developers and reviewers. The reduction of repeated input (between reference solution, software, and documentation input) throughout the SQA process reduces potential for human errors during the preparation of the supporting software quality records. The automation of the verification and documentation process proposed for this project leverages the existing verification structure already in place for the SAS4A/SASSYS-1 code.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗
DOE OSTI2025

Software Quality Assurance for the MOOSE-Based Open-Source Multiphysics Code Cardinal - An Expanded CI Testing Suite

Cardinal is a wrapping of the GPU-oriented spectral element Computational Fluid Dynamics (CFD) code NekRS and the Monte Carlo particle transport code OpenMC within the Multiphysics Object-Oriented Simulation Environment (MOOSE). Cardinal provides high-resolution thermal-hydraulics and/or radiation transport feedback to MOOSE multiphysics simulations. Multiphysics feedback is implemented in a geometry-agnostic manner which eliminates the need for rigid one-to-one mappings. A generic data transfer implementation also allows NekRS and OpenMC to couple to any MOOSE application, enabling a broad set of multiphysics capabilities. Cardinal simulations can also leverage combinations of MPI, OpenMP, and GPU resources. Cardinal continuous development and improvement efforts have led to the software being considered as a high-fidelity design and licensing tool for key areas of nuclear reactor relevant physics, including neutron transport, fluid flow, heat transfer, and mechanical processes. The fast development and expansion of the software from a pure R&D framework towards its application in the nuclear industry and regulation require a focus on developing, enhancing and, maintaining Cardinal’s software quality through strict adherence to a Software Quality Assurance (SQA) framework and SQA program. To facilitate compliance with SQA standards, the Cardinal SQA Program has been initiated during Fiscal Year 2023 (FY23). During the development of the Cardinal SQA Program, multiple gaps have been identified. These gaps are primarily related to model verification and code pedigree as they relate to the use of Cardinal as a safety analysis tool. These gaps have been captured in a report published in 2023. A second report highlighted the progress made during Fiscal Year 2024 (FY24) and described Argonne’s effort to document and integrate software verification within Cardinal’s software development process. This report documents a snapshot of the verification test cases currently available for Cardinal and NekRS in their assimilation into a Continuous Integration (CI) platform. Following the CI practice permits the integrating of source code changes frequently and ensuring that the integrated codebase clears the verification testing for the software. It should be noted that the SQA program itself, including the program plans, procedures, configuration management, and testing strategies, need to be developed in a future step of this task.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2025

Progress Towards NQA-1 for Cardinal in FY25

Cardinal is a wrapping of the GPU-oriented spectral element Computational Fluid Dynamics (CFD) code NekRS and the Monte Carlo particle transport code OpenMC within the Multiphysics Object-Oriented Simulation Environment (MOOSE). Cardinal provides high-resolution thermal-hydraulics and/or radiation transport feedback to MOOSE multiphysics simulations. Multiphysics feedback is implemented in a geometry-agnostic manner which eliminates the need for rigid one-to-one mappings. A generic data transfer implementation also allows NekRS and OpenMC to couple to any MOOSE application, enabling a broad set of multiphysics capabilities. Cardinal simulations can also leverage combinations of MPI, OpenMP, and GPU resources. Cardinal continuous development and improvement efforts have led to the software being considered as a high-fidelity design and licensing tool for key areas of nuclear reactor relevant physics, including neutron transport, fluid flow, heat transfer, and mechanical processes. The fast development and expansion of the software from a pure R&D framework towards its application in the nuclear industry and regulation require a focus on developing, enhancing,and maintaining Cardinal’s software quality through strict adherence to a Software Quality Assurance (SQA) framework and SQA program. To facilitate compliance with SQA standards, the Cardinal SQA Program was initiated during Fiscal Year 2023 (FY23). During the development of the Cardinal SQA Program, multiple gaps have been identified. These gaps are primarily related to model verification and code pedigree as they relate to the use of Cardinal as an analysis tool. These gaps were captured in a report published in 2023. A second report highlighted the progress made during Fiscal Year 2024 (FY24) and described Argonne’s effort to document and integrate software verification within Cardinal’s software development process. This report documents the progress made towards NQA-1 for Cardinal in the Fiscal Year 2025 (FY25). All cases in the expanded Continuous Integration (CI) suite of NekRS are included in this report which test the solvers and modules available in NekRS exhaustively. The NekRS tests are integrated with the Cardinal CI suite and made available in publicly accessible Github documentation. Following the CI practice permits integrating of source code changes frequently and ensuring that the integrated codebase clears the verification testing for the software. Also in this report is a brief overview of the development of the Cardinal Software Quality Assurance Plan (SQAP) that was done in FY25, though it should be noted that the rest of the documentation for the SQA program needs to be developed in a future step of this task.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2015

Reexamining classical and quantum models for the D-Wave One processor: The role of excited states and ground state degeneracy

We revisit the evidence for quantum annealing in the D-Wave One device (DW1) based on the study of random Ising instances. Using the probability distributions of finding the ground states of such instances, previous work found agreement with both simulated quantum annealing (SQA) and a classical rotor model. Thus the DW1 ground state success probabilities are consistent with both models, and a different measure is needed to distinguish the data and the models. Here in this paper we consider measures that account for ground state degeneracy and the distributions of excited states, and present evidence that for these new measures neither SQA nor the classical rotor model correlate perfectly with the DW1 experiments. We thus provide evidence that SQA and the classical rotor model, both of which are classically efficient algorithms, do not satisfactorily explain all the DW1 data. A complete model for the DW1 remains an open problem. Using the same criteria we find that, on the other hand, SQA and the classical rotor model correlate closely with each other. To explain this we show that the rotor model can be derived as the semiclassical limit of the spin-coherent states path integral. We also find differences in which set of ground states is found by each method, though this feature is sensitive to calibration errors of the DW1 device and to simulation parameters.

71 CLASSICAL AND QUANTUM MECHANICS, GENERAL PHYSIC↗
DOE OSTI2018

Implementation of Software QA for SAS4A/SASSYS-1 Rev. 1

In an effort to support closure of gaps in advanced reactor licensing pathways, a multi-year task to systematically develop sodium-cooled fast reactor (SFR) codes and methods for use in a licensing framework was launched as part of the DOE-NE Advanced Reactor Technologies (ART) Program’s Regulatory Technology Development Plan (RTDP). This report documents Phase 2 of this task, which was focused on the finalization and initial implementation of a software quality assurance (SQA) program for SAS4A/SASSYS-1 and completion of high-priority SQA-related technical activities. The ultimate goal of this ongoing RTDP task is to develop an SQA framework that satisfies the fundamental requirements of relevant SQA standards and guidance while still maintaining sufficient flexibility and efficiency such that the framework can be sustained with modest resources.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2023

Fiscal Year 2023 Software Quality Assurance Activities for the ARC Software

The Argonne Reactor Code (ARC) software suite [1-17] has been developed by Argonne researchers for fast reactor design and analysis since the 1970s. With the ARC software suite, a user can quickly build a model of a proposed or existing fast spectrum reactor and carry out fuel cycle, nominal thermal analysis and flow requirements, and assess, as is appropriate, whether the core design and constraint system yield an acceptable mechanical behavior. For transient reactor analysis with SAS4A [18], the ARC software suite can be used to generate reactivity coefficients and kinetics parameters at any modeled fuel cycle time point which forms part of the input to SAS4A. The ARC suite was consistently being developed until the 1990s and followed a software QA program which was an appropriate standard for the time. In the 1990s, the DOE funding to fast reactor research and development was all but eliminated and the ARC software was put into maintenance mode. In the early 2000s, the software quality assurance (SQA) program for ARC was still in place to define an official version, but by 2005 it all but was abandoned as there were insufficient staff to fill the work roles. Since 2005, there has been a considerable increase in research and design work on fast spectrum reactors. The ARC software as a whole has since been exported to many universities and commercial companies and ANL support has been given to the various projects over the years [19-23]. Further, MC 2 -3, PERSENT, and DASSH were all developed after 2005 without any adherence to a software standard. In recent time, the DOE VTR project [22] paid for verification work to be done on the ARC software as part of the goal of making it NQA-1 complaint. The VTR project was not considered the appropriate pathway to fund and maintain a SQA program for the ARC software and while software developments (DASSH) were made and several manuals were updated and software verification work was carried out, the ARC software is not NQA-1 compliant. More recently the Advanced Reactor Development Program (ARDP [23]) has funded the creation of manuals for some ARC utility programs and funded additional software verification work on DIF3D [6, 7] and MC 2 -3 [2-5] for the purpose of commercial grade dedication. Because of the VTR and ARDP projects, software verification work was completed on MC 2 -3 and DIF3D, and detailed reports were created for each piece of software, which discuss the inputs and outputs from the codes that are covered by the verification work and link various analytic, code-to-code, and hand calculation based verification work presented in the report with verification test problems provided with the software. This is a key part of the commercial grade dedication work and constitutes the bulk of the cost to get the ARC software to commercial grade. The ARC software suite is a valuable asset as a fast reactor design and analysis tool set that has been reasonably well verified and validated with various fast reactor benchmark problems and experiments over decades. Some or all of the ARC software suite has been utilized for designing the IFR [20], PGSFR [21], VTR [22], and Natrium [23] reactors and we can expect it to continue to be used for advanced fast reactor design and/or confirmatory calculation purposes in the future. Due to increased interest by commercial companies and regulatory bodies, it is becoming more important to make the ARC software suite complete and ready-to-use in terms of its SQA pedigree and commercial grade dedication needs. This report discusses the achievements made towards building a new SQA program for the ARC software and dealing with outstanding identified QA gaps.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

Implementation of Plot File Testing in the DYNA3D/ParaDyn Software Quality Assurance Suite

Automated testing of DYNA3D/ParaDyn plot files was added to the DYNA3D/ParaDyn software quality assurance (SQA) test suite. The new capability extracts select data from the plot files generated during each verification run and compares it to the same baseline answers used to verify the problem. Deviations between baseline answers and plot file values are reported in the same manner as solution discrepancies, and differences in precision levels between the baseline answers and plot file results are accounted for. The new testing leverages the existing SQA test suite framework and test problems and the Python Mili reader and minimally increases the overall run time (< 5%) of the SQA test suite. This new capability provides incremental end-toend testing of the most common DYNA3D/ParaDyn simulation workflows.

42 ENGINEERING↗
DOE OSTI2023

SAM Software Quality Assurance Plan Implementation and NQA-1 Assessment

The System Analysis Module (SAM) is an advanced and modern system analysis tool being developed at Argonne National Laboratory under the U.S. DOE Office of Nuclear Energy’s Nuclear Energy Advanced Modeling and Simulation (NEAMS) program. As a modern-day software, SAM development included efforts to follow best practices in software development. These best practices include version control using git, independent reviews of development activities, and detailed descriptions of developments and bug fixes using the GitLab issue and merge request system. In Fiscal Year 2023 (FY23), the SAM development team set out to formalize a Software Quality Assurance (SQA) program that allowed industry partners to credit the informal steps being taken by the SAM development team to ensure the quality of the software. As part of formalizing an SQA program, a SQA Plan (SQAP) was developed, implemented, and assessed. The SAM SQAP targets compliance with NQA-1-2008/2009 Addenda. The SQAP builds on the MOOSE SQAP and the Argonne SSQAPP while accounting for the needs of the multi-organization SAM development team. Modifications to the SAM repository structure, including a new testing system, updated test cases, and the development of an internal website, facilitate the implementation of the SAM SQAP. The initial assessment of the SAM SQAP indicated that the SAM SQAP was adequately and effectively implemented and additional work was required to improve the compliance of the SAM SQAP with NQA-1 2008/2009 Addenda. Several improvements to the SQAP have already been drafted to address these assessments and future work is planned to further improve the SAM SQAP in support of end-user needs.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2023

Software Quality Assurance, Software Requirements and Gap Analysis for the MOOSE-Based Open-Source Multiphysics Code Cardinal

Cardinal continuous development and improvement efforts have led to the software being considered as a high-fidelity design and licensing tool for key areas of nuclear reactor relevant physics, including neutron transport, fluid flow, heat transfer, and mechanical processes. The fast development and expansion of the software from a pure R&D framework towards its application in the nuclear industry and regulation require a focus on maintaining and enhancing Cardinal’s software quality through strict adherence to a Software Quality Assurance (SQA) framework. To facilitate compliance with SQA standards, the Cardinal SQA Program has been initiated during Fiscal Year 2023 (FY23).

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

ORNL Package Testing Program Software Quality Assurance Plan

The Oak Ridge National Laboratory (ORNL) Package Testing Program (PTP) uses commercial off-the-shelf (COTS) software in performing data collection of thermal test results for package designs that contain radioactive materials. Specifically, this software is used to collect temperature data from the furnace, packages, and ambient air to prepare and execute the thermal test specified in 10 CFR 71.73, “Thermal Test.” This software quality assurance (SQA) plan sets forth the guidelines, standards, and procedures that shall be used to provide SQA for PTP software applications. This is a living document that will be maintained for the lifecycle of the PTP program. The SQA plan follows the requirements set forth in ORNL Standards Based Management System (SBMS): Information Technology; Subject Area: Software Quality Assurance. When applicable to the requirements as described in ORNL SBMS, Software Quality Assurance, the software shall be listed in the ORNL Software Registration System (SRS). Exemptions to this SBMS are COTS and firmware that are not modified; spreadsheet applications and personal productivity tools that do not have a utility or safety application, research applications, legacy software, system software, vendor-supplied software used to interface with the vendor’s services, software used within the organization to facilitate processing or management of information, and software developed for applications not specific to the US Department of Energy (DOE).

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

Software Quality Assurance Plan: Cardinal

The Cardinal Software Quality Assurance (SQA) Program aims to provide the controls and processes necessary to enable continuous, high-quality software development while meeting user and program sponsor requirements. This SQA Plan (SQAP) delineates the SQA Program framework for Cardinal by describing the Program activities, organization, and documentation, and by clearly defining the interconnection of all Program items. It should be noted that this SQAP is aligned with the current version of the Argonne Quality Assurance Program Plan, which was designed to align with DOE O 414.1D. This SQAP is also aligned with the revision 10 of the SQAP for MOOSE and MOOSE-based applications.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2020

Assessment of Survey Results from Advanced Reactor Industry Domain Experts on Nonlinear Soil-Structure Interaction Analysis Software Verification and Validation

The seismic load case has a significant impact on the design and cost of nuclear power plants. Given the need to substantially reduce cost, advanced reactor designers are looking to leverage numerical tools that enable seismic analysis of an integrated vessel/support/structure/soil system. Modern nonlinear analysis tools provide a solution, capturing dynamic coupling between components (including soil-structure interaction (SSI)) concurrent with nonlinear behavior in one or more parts of the system. Although these methods have a rich history of technical development and implementation, software quality assurance (SQA) following nuclear industry standards remains a significant burden for those wishing to adopt such methods for advanced reactor design and licensing. To reduce the SQA burden, this project will develop the guidance for SQA verification and validation (V&V) of coupled nonlinear SSI analysis tools, to include a test matrix of software features and test problems to support commercial grade dedication (CGD). The guidance is intended to be technology-neutral: supporting designers of all advanced reactors. To maximize the value of the project to reactor designers, the project team performed focused surveys of and interviews with advanced reactor designers. Additionally, the project surveyed members of the broader industry involved in reactor design and licensing. The aggregated industry feedback consists of written survey responses, live polling responses, focused interviews, and informal feedback provided after outreach presentations, collectively referred to as “survey results”. Herein, the survey results are reported, reviewed, and assessed to inform follow-on project activities. The survey results confirmed the familiarity of the industry with the coupled nonlinear SSI analysis. They also affirm the project need based upon the expressed intent to (1) incorporate nonlinear features and (2) pursue the coupled nonlinear SSI analysis to reduce seismic demands and construction costs. All reactor designers indicated their intent to incorporate two or more nonlinear features, and all reactor designer respondents opined that the coupled nonlinear SSI analysis would allow for the optimization of the reactor design and construction. However, the programmatic challenges, whether real or perceived, present a significant barrier to reactor designers. The barrier most commonly identified by the reactor designer population was regulatory risk, with 70% citing this as a reason not to pursue the approach. The perceived regulatory risk identified by the reactor designers underscores the importance of regulator engagement and dialogue in this project. Additionally, half of the reactor designers identified cost and lack of guidance as a deterrent. The survey results also provide insights to tailor specific aspects of the guidance document and test matrix. The project plans to prepare both a formal referenceable guidance document and a collaborative, web-based test matrix and problem set. The project will focus on more complete test problem definitions for the prioritized nonlinear features over shallower problem descriptions for a larger set of features. The nonlinearities prioritized as high based upon survey feedback include fluid-structure interaction and seismic isolation and energy dissipation devices. The nonlinearities prioritized as intermediate include nonlinear geomaterials, nonlinear concrete, nonlinear steel, and interface/contact nonlinearity. Deep embedment and the associated nonlinear phenomena are assigned the lowest priority based upon survey feedback.

42 ENGINEERING↗