Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software testing”

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 OSTI2022

MPACT Software Test Plan, Requirements, and Test Report (V.4.3)

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.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2022

Software Testing – An Overview [Slides]

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.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2019

Increasing Software Testing Coverage and Portability with Spack

Adequate testing coverage is critical for successful scientific software development. For numerically intensive codes, the test matrix should cover a variety of machines, compilers, third-party library dependencies, as well as possible other features such as memory testing, parallelization paradigms, and application options that may be enabled or disabled, as some examples. Such coverage can be a major burden on developers without powerful methods for managing the matrix. Spack is a great tool developed by Lawrence Livermore National Lab for managing software on a Unix-based system and in addition to this, we are leveraging Spack to simplify application testing development and management. Here we demonstrate exploiting many of Spack's features to orchestrate the test coverage for the Nalu-Wind application we are developing under the Exascale Computing Project. By using Spack underneath our testing infrastructure, we have increased our testing coverage, portability, robustness, and software quality. While we use our Nalu-Wind application as an example, the benefits of exploiting Spack for application testing can be had for other applications as well.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2022

Virtual Infrastructure Twins: Software Testing Platforms for Computing-Instrument Ecosystems

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.

Rao, Nageswara↗
DOE OSTI2023

Virtual Infrastructure Twins: Software Testing Platforms for Computing-Instrument Ecosystems

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.

Rao, Nageswara↗
DOE OSTI2020

YOLO Test Software v1.4

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.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

M-Star ® Software Test and Verification

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.

08 HYDROGEN↗
DOE OSTI2022

M-Star® Software Test and Verification for Impeller Mixing in a Tank

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.

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗
DOE OSTI2018

Virtual Environment for Testing Software-Defined Networking Solutions for Scientific Workflows

Recent developments in software-defined infrastructures promise that scientific workflows utilizing supercomputers, instruments, and storage systems will be dynamically composed and orchestrated using software at unprecedented speed and scale in the near future. Testing of the underlying networking software, particularly during initial exploratory stages, remains a challenge due to potential disruptions, and resource allocation and coordination needed over the multi-domain physical infrastructure. To overcome these challenges, we develop the Virtual Science Network Environment (VSNE) that emulates the multi-site host, storage, and network infrastructure using Virtual Machines (VMs), wherein the production and nascent software can be tested. Within each VM, which represents a site, the hosts and local-area networks are emulated using Mininet, and the Software-Defined Network (SDN) controllers and service daemon codes are natively run to support dynamic provisioning of network connections. Additionally, Lustre filesystem support at the sites and an emulation of the long-haul network using Mininet, are provided using separate VMs. As case studies, we describe Lustre file transfers using XDD, Red5 streaming service demonstration, and an emulated experiment with remote monitoring and steering modules, all supported over dynamically configured connections using SDN controllers.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2022

VERAIn Software Requirements, Test Plan, and Test Report

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.

97 MATHEMATICS AND COMPUTING↗