SEARCH · Engineering Papers
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.
This document presents the software test plan for MPACT. The software requirements and software test report are provided in the appendices. The test platform hardware and software are described herein. Appendix A provides a list of the tests that were run and their acceptability as a test report. Appendix B provides the list of low-level software requirements as a requirements traceability matrix.
Explore the source record for details and available documents.
This report discusses the importance of software testing, referencing two examples that illustrate setbacks and losses without adequate testing. The report also highlights various levels of testing and provides guiding questions to help with the process.
Science ecosystems are being built by federating computing systems and instruments located at geographically distributed sites over wide-area networks. These computing-instrument ecosystems are expected to support complex workflows that incorporate remote, automated AI-driven science experiments. Their realization, however, requires various designs to be explored and software components to be developed, in order to support the orchestration of distributed computations and experiments. It is often too expensive, infeasible, or disruptive for the entire ecosystem to be available during the typically long software development and testing periods. We propose a Virtual Infrastructure Twin (VIT) of the ecosystem that emulates its network and computing components, and incorporates its instrument software simulators. It provides a software environment nearly identical to the ecosystem to support early development and testing, and design space exploration. We present a brief overview of previous digital infrastructure twins that culminated in the VIT concept, including (i) the virtual science network environment for developing software-defined networking solutions, and (ii) the virtual federated science instrument environment for testing the federation software stack and remote instrument control software. We briefly describe VITs for Nion microscope steering and access to GPU systems.
Science ecosystems are being built by federating computing systems and instruments located at geographically distributed sites over wide-area networks. These computing-instrument ecosystems are expected to support complex workflows that incorporate remote, automated AI-driven science experiments. Their realization, however, requires various designs to be explored and software components to be developed, in order to support the orchestration of distributed computations and experiments. It is often too expensive, infeasible, or disruptive for the entire ecosystem to be available during the typically long software development and testing periods. We propose a Virtual Infrastructure Twin (VIT) of the ecosystem that emulates its network and computing components, and incorporates its instrument software simulators. It provides a software environment nearly identical to the ecosystem to support early development and testing, and design space exploration. We present a brief overview of previous digital infrastructure twins that culminated in the VIT concept, including (i) the virtual science network environment for developing software-defined networking solutions, and (ii) the virtual federated science instrument environment for testing the federation software stack and remote instrument control software. We briefly describe VITs for Nion microscope steering and access to GPU systems.
This is a user manual of the software being developed at Brookhaven National Laboratory to test deep learnings algorithms. (YOLO) You Only Look Once. V1.4 added new features, including Display metric average recall, early termination option and display filename/image.
Savannah River Mission Completion (SRMC) currently manages the risk for retained hydrogen in the Defense Waste Processing Facility (DWPF) vessels by implementing a Retained Hydrogen Program. The current program relies on Sludge Batch (SB) 8 Gas Chromatograph data and on conservative assumptions concerning gas release and retention to determine allowable vessel Quiescent time (Q-time). The authors identified M-Star ® CFD as a software that could simulate processes such as fluid flow, heat transfer, species transport, chemical reactions, particle transport, and retained hydrogen gas release. Preliminary simulation results suggest that more realistic assumptions on gas retention and release may be feasible for the DWPF retained hydrogen program. Because of the desire to use the M-Star ® software to perform analyses that support nuclear safety, SRMC has requested Savannah River National Laboratory (SRNL) to upgrade the software classification level of M-Star ® CFD from level D to level A to perform analyses that support nuclear safety.
Abstract not provided.
Before a sample of the Slurry Mix Evaporator (SME) can be taken, the SME product sampling procedure requires that the agitator power be stable between 20 and 30 kW for at least one hour. The SME transfer to Melter Feed Tank (MFT) procedure also requires the SME agitator power be stabilized between 20 and 30 kW prior to transfer. These requirements are specified to ensure samples are homogeneous, as discussed in the Waste Form Qualification Report. During SME Batch 804, the agitator power dropped to 19 kW and struggled to achieve and maintain 20 kW. It was later discovered that the cause of the power drop was due to one of the bottom blades of the agitator breaking off. Both the sample and the transfer occurred without the power stabilizing between 20 and 30 kW. Therefore, the quality of SME Batch 804 is indeterminate, and homogeneity was questionable.
Abstract not provided.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
This document describes the software test plan for VERAIn and provides appendices for the software requirements and software test report. In this document, the test platform hardware and software are described. Appendix A provides a list of the tests run and their acceptability as a test report, and Appendix B provides the list of low-level software requirements as a requirements traceability matrix.
This document details the software requirements, test plan, and test results for VERAView. In this document, the test platform hardware and software are described. Section 2 provides a list of the tests run and their acceptability as a test report. Section 3 provides the step-by-step execution of these tests and their results.
The purpose of this document is to detail the software testing of FAST-1.0 through unit, integration, and assessment tests. More than 400 tests were designed to provide coverage of the requirements for FAST-1.0. These requirements were developed in the NRC Statement of Work (SOW) for NRC Agreement Number NRC-HQ-25-14-D-001 and are transcribed to this document as part of the Software Quality Assurance Plan for the FAST Code System, PNNL-28767. FAST 1.0 represents the merger of the FRAPCON and FRAPTRAN codes and as such FAST-1.0 performs steady state and transient fuel performance calculations described below. FAST-1.0 calculates the steady state response of light-water reactor fuel rods during long-term burnup. The code calculates temperature, pressure, and deformation of a fuel rod as functions of time-dependent fuel rod power and coolant boundary conditions. The phenomena modeled by the code include: 1) heat conduction through fuel and cladding to the coolant; 2) cladding elastic and plastic deformation; 3) fuel-cladding mechanical interaction; 4) fission gas release from the fuel and rod internal pressure; and 5) cladding oxidation. FAST is used to perform independent calculations for regulatory evaluations of fuel performance under normal operation and anticipated operational occurrences (AOOs). FAST calculates the temperature and deformation history of a fuel rod as a function of time-dependent fuel rod power and coolant boundary conditions. The phenomena modeled by FAST include: 1) heat conduction; 2) heat transfer from cladding to coolant; 3) elastic-plastic fuel and cladding deformation; 4) cladding oxidation; 5) fission gas release; and 6) fuel rod gas pressure. FAST code assessment, development and maintenance drive a significant portion of the NRC fuel research activities and the tools are used in a substantial number of regulatory products. Given the centrality of the FAST code to the effectiveness of fuel research, it is critical to assess, develop and maintain this tool.
This report summarizes the performance testing for the Software upgrade for the Savannah River National Laboratory (SRNL) Controlled Potential Coulometry (CPC) instrument. This upgrade is specifically to meet the needs of the Nuclear Material Laboratory, Office of Safeguards Analytical Services, International Atomic Energy Agency at Seibersdorf, Austria. The instrument hardware was upgraded in 2010, but the software continued to operate on a Windows platform using a High Tech Basic (HT Basic) application. HT Basic usage is declining. The IAEA requested an upgrade to the existing coulometer software to Laboratory Virtual Instrument Engineering Workbench (LabVIEW), an object-oriented programming language in wide use and one the NML staff is familiar with. The software was developed by SRNL Software Engineer, with assistance from Electrical Engineer and Scientist. Once developed, the new LabVIEW software was validated, tested with Iron (surrogate for plutonium) and plutonium. Once testing was completed, the software was installed at the International Atomic Energy Agency Nuclear Material Laboratory (IAEA NML) coulometer, and SRNL provided hands on training to NML staff on using the new software.
Metamorphic and differential testing have been proposed as best practices for testing software that is difficult to test, such as for programs in scientific domains. An assumption is that these approaches can be easily customized and applied to almost any domain. However, scientific software is often data-driven, and metamorphic relations may require significant domain knowledge to develop. In addition, tools are often written for ad-hoc experimentation by the scientists and often embed many assumptions about the importance and representation of different natural phenomena. In this paper, we present our experience applying both metamorphic and differential testing to a set of four computational biology tools that predict the growth of an organism. While our original goal was to evaluate these techniques to improve our system-level testing, we encountered multiple roadblocks along the way. Although we did find faults (some confirmed by developers), we also uncovered a set of challenges, including the considerable manual effort required for (a) defining domain-specific tests, (b) validating correctness, and (c) distinguishing between issues stemming from poor data and those arising from incorrect software.
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).