Search NASASearch

SEARCH · Search NASA

Results for “Unit 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 109 records · Page 6

Ultrawideband Electromagnetic Interference to Aircraft Radios: Results of Limited Functional Testing With United Airlines and Eagles Wings Incorporated, in Victorville, California

On February 14, 2002, the FCC adopted a FIRST REPORT AND ORDER, released it on April 22, 2002, and on May 16, 2002 published in the Federal Register a Final Rule, permitting marketing and operation of new products incorporating UWB technology. Wireless product developers are working to rapidly bring this versatile, powerful and expectedly inexpensive technology into numerous consumer wireless devices. Past studies addressing the potential for passenger-carried portable electronic devices (PEDs) to interfere with aircraft electronic systems suggest that UWB transmitters may pose a significant threat to aircraft communication and navigation radio receivers. NASA, United Airlines and Eagles Wings Incorporated have performed preliminary testing that clearly shows the potential for handheld UWB transmitters to cause cockpit failure indications for the air traffic control radio beacon system (ATCRBS), blanking of aircraft on the traffic alert and collision avoidance system (TCAS) displays, and cause erratic motion and failure of instrument landing system (ILS) localizer and glideslope pointers on the pilot horizontal situation and attitude director displays. This report provides details of the preliminary testing and recommends further assessment of aircraft systems for susceptibility to UWB electromagnetic interference.

Ely, Jay J.

Testing Fortran Software with pFunit

Over the past two decades, the emergence of highly effective software testing frameworks has greatly simplified the development and use of unit tests and has led to new software development paradigms such as test driven development (TDD). However, technical computing introduces a number of unique testing challenges, including distributed parallelism and numerical accuracy. This webinar will begin with a basic introduction to the use of pFUnit (parallel Fortran Unit testing framework) to develop tests for Message Passing Interface (MPI) plus Fortran (MPI+Fortran) software and then present some of the new capabilities in the latest release. We will also discuss some specialized methodologies for testing numerical algorithms and speculate about future framework capabilities that may improve our ability to test at exascale.

Clune, Tom

Orbital flight simulation utility software unit specifications, revision 1

The HP PASCAL source code defines the specifications for a Utility Software Unit (USU) designed to support orbital flight simulators such as MANHANDLE and GREAS (General Research and Engineering Analysis Simulator). Besides providing basic input/output, mathematical, matrix, quaternion, and statistical routines for such simulators, one of the primary functions of the USU is to isolate all system-dependent codes in one well-defined compartment, thereby facilitating transportation of the simulations from one computer to another. Directives are given for the PASCAL compilers of the HP-9000 Series 200 Pascal 3.0 and the HP-9000 Series 500 HP-UX 5.0 operating systems that produce a single file of relocatable code from four separate files of source code. Three of the source code files are common to both operating systems. The fourth source code file (utilspif.I) contains all of the system-dependent PASCAL code for the USU. A fifth file of source code written in C is required to interface utilspif.I with the HP-UX I/O package. The Pascal 3.0 compiler directives and the driver source code for a unit rest program and counterparts for the HP-UX 5.0 operating system are given. The major portion of the unit test program source code is common to both operating systems. Unit test results from the Pascal 3.0 operating system and results from the HP-UX operating system are given.

Wilson, S. W.

pFUnit 3.0 Tutorial Advanced

This tutorial will introduce Fortran developers to unit-testing and test-driven development (TDD) using pFUnit. As with other unit-testing frameworks, pFUnit, simplifies the process of writing, collecting, and executing tests while providing clear diagnostic messages for failing tests. pFUnit specifically targets the development of scientific-technical software written in Fortran and includes customized features such as: assertions for multi-dimensional arrays, distributed (MPI) and thread-based (OpenMP) parallellism, and flexible parameterized tests.These sessions will include numerous examples and hands-on exercises that gradually build in complexity. Attendees are expected to have working knowledge of F90, but familiarity with object-oriented syntax in F2003 and MPI will be of benefit for the more advanced examples. By the end of the tutorial the audience should feel comfortable in applying pFUnit within their own development environment.

Test Driven using pFUnit

Experiments in fault tolerant software reliability

Twenty functionally equivalent programs were built and tested in a multiversion software experiment. Following unit testing, all programs were subjected to an extensive system test. In the process sixty-one distinct faults were identified among the versions. Less than 12 percent of the faults exhibited varying degrees of positive correlation. The common-cause (or similar) faults spanned as many as 14 components. However, a majority of these faults were trivial, and easily detected by proper unit and/or system testing. Only two of the seven similar faults were difficult faults, and both were caused by specification ambiguities. One of these faults exhibited variable identical-and-wrong response span, i.e. response span which varied with the testing conditions and input data. Techniques that could have been used to avoid the faults are discussed. For example, it was determined that back-to-back testing of 2-tuples could have been used to eliminate about 90 percent of the faults. In addition, four of the seven similar faults could have been detected by using back-to-back testing of 5-tuples. It is believed that most, if not all, similar faults could have been avoided had the specifications been written using more formal notation, the unit testing phase was subject to more stringent standards and controls, and better tools for measuring the quality and adequacy of the test data (e.g. coverage) were used.

Mcallister, David F.

Initial Field Deployment Results of Green PCB Removal from Sediment Systems (GPRSS)

The goal of this task order was to complete optimization and development of the Green PCB Remediation from Sediment Systems(GPRSSs) technology, culminating in the production of functioning demonstration test units which would be deployed at a suitable demonstration location. This location would be selected in conjunction with Toxicological & Ecological Associates who have entered into a SAA with NASA to partner with and further develop this technology. The GPRSSs technology was initially developed under ESC Task Order 83 with the purpose of providing a green remediation technology capable of in-situ removal and remediation of polychlorinated biphenyls (PCBs) from contaminated sediments. The core concept of the technology, a polymeric blanket capable of absorbing PCBs when in contact with contaminated sediments was then transitioned to Task Order 165 where the primary objective was to fully design and optimize a functioning test unit capable of testing the theoretical and laboratory scale concepts in a real world situation. Results from both task orders are included in this report for completeness, although Task Order 165 focused on the blanket design and the small scale field demonstration in which is currently still ongoing in Altavista, VA.

Deployment

CSI computer system/remote interface unit acceptance test results

The validation tests conducted on the Control/Structures Interaction (CSI) Computer System (CCS)/Remote Interface Unit (RIU) is discussed. The CCS/RIU consists of a commercially available, Langley Research Center (LaRC) programmed, space flight qualified computer and a flight data acquisition and filtering computer, developed at LaRC. The tests were performed in the Space Structures Research Laboratory (SSRL) and included open loop excitation, closed loop control, safing, RIU digital filtering, and RIU stand alone testing with the CSI Evolutionary Model (CEM) Phase-0 testbed. The test results indicated that the CCS/RIU system is comparable to ground based systems in performing real-time control-structure experiments.

Sparks, Dean W., Jr.

AI Model Benchmarking for Nonproliferation Applications: Steel Thread Benchmarking Task Force Technical Report (Rev. 2)

Steel Thread is a NA-22 venture that seeks to build trustworthy, reliable AI models that can be used in a wide variety of nonproliferation tasks. A key aspect of building these models is developing appropriate benchmarks and evaluation methods, which will enable the venture to identify and adapt models to provide the most value in the nonproliferation domain. Benchmarks must be relevant to key tasks in this domain, such as question answering, information retrieval, document summarization and classification, consensus analysis, and image and data analysis. This report 1) provides an overview of benchmark design, evaluation, and challenges; 2) reviews a variety of open benchmarks, with a focus on language models and tasks; and 3) identifies benchmarks that are most relevant to Steel Thread. This report is intended to serve as a basis for further efforts to classify and evaluate benchmarks and their correlation with success on nonproliferation-specific tasks. The Steel Thread venture has defined benchmarks to be a particular combination of a dataset (or datasets) and a metric (or metrics) conceptualized as representing one or more specific tasks or sets of abilities for a specific modality. It is adopted by a research community as a shared framework for comparing methods.1 It includes 1) Data: Labeled (a designated subset not used for training, which could be all the data), 2) Metric: A way to quantify performance, 3) Task/Ability: What the benchmark is testing, 4) Protocol: A structured and repeatable evaluation process, 5) Baseline/Reference Model: For comparison; could be statistical, rule-based, SME-derived, or another model, and 6) Maintenance Plan: to update with new information over time; important for long-term utility. For further clarity, the definition includes what a benchmark, in this context, is not. It is not a corpus of training data, specific to a model (it is intended to apply to a range of models), a universal evaluation of performance, a guarantee that the ‘top’ model on the leaderboard will be the best fit for every specific use case, an all-encompassing proof of a model’s universal quality, nor is it a one-size-fits-all measure of success. It does not cover every real-world constraint (like operational, ethical, or cost considerations), a systems integration test, or a unit test. This definition was inspired by and resulted from discussions within the Steel Thread Benchmarking Task Force. This group was formed to define what we would mean as a benchmark within Steel Thread but persisted as the need to develop a thorough understanding of the large and expanding existing benchmarking space. This technical report is a result of the group’s divide and conquer approach to exploring this space. The release of benchmarks might not be progressing as quickly as model development, but it is moving very fast, as many benchmarks quickly become saturated, when state-of-the-art models score so close to the benchmark’s ceiling that their results are virtually indistinguishable. At that point, the test no longer differentiates between new systems, so researchers usually stop reporting scores as the benchmark no longer informs about improvements from the next generation of models. In the OpenAI announcement of GPT-5, they reported results on six flagship public benchmarks (AIME 2025, SWE-bench Verified, Aider Polyglot, MMMU, HealthBench Hard, GPQA) but the full system-card covers roughly thirty-five separate evaluations, comprising hundreds of test task items in total. There have been some efforts to summarize benchmarks in specific fields, like for text-to-image generation, but these surveys have had a narrow methodology scope. Therefore, a comprehensive survey of all benchmarks or even all benchmarks that could be relevant to Steel Thread is outside of the scope of this report. We chose some specific benchmarks to investigate in detail.

97 MATHEMATICS AND COMPUTING

LLM Benchmarking with LLaMA2: Evaluating Code Development Performance Across Multiple Programming Languages

The rapid evolution of large language models (LLMs) has opened new possibilities for automating various tasks in software development. This paper evaluates the capabilities of the LLaMA 2-70B model in automating these tasks for scientific applications written in commonly used programming languages. Using representative test problems, we assess the model's capacity to generate code, documentation, and unit tests, as well as its ability to translate existing code between commonly used programming languages. Our comprehensive analysis evaluates the compilation, runtime behavior, and correctness of the generated and translated code. Additionally, we assess the quality of automatically generated code, documentation, and unit tests. Here, our results indicate that while LLaMA 2-70B frequently generates syntactically correct and functional code for simpler numerical tasks, it encounters substantial difficulties with more complex, parallelized, or distributed computations, requiring considerable manual corrections. We identify key limitations and suggest areas for future improvements to better leverage AI-driven automation in scientific computing workflows.

97 MATHEMATICS AND COMPUTING

Performance Results on CPU/GPU Exascale Architectures for OMEGA: The Ocean Model for E3SM Global Applications

The US Department of Energy (DOE) conducts climate simulations on some of the world’s largest supercomputers. These exascale machines use heterogeneous architectures with both CPUs and GPUs, and scientific codes must adapt to make full use of this computing power. Los Alamos National Lab is developing Omega: The Ocean Model for E3SM Global Applications, which is specifically designed for modern exascale computers. It uses external libraries that have been optimized for a variety of architectures to run on different supercomputers. Omega is an unstructured-mesh ocean model based on TRiSK numerical methods. It will be the new ocean component of the DOE’s Energy Exascale Earth System Model (E3SM). The algorithms in Omega follow those of the current ocean component, MPAS-Ocean, but it will be written in C++ rather than Fortran to take advantage of the Kokkos performance portability library. Omega spatial operators are written as Kokkos kernels to run efficiently on both CPUs and GPUs. Work on Omega began in 2023 with a new C++ framework for unstructured mesh partitioning, halo exchanges, parallel IO, and Kokkos interfaces. The current version, Omega-0, is being developed to solve the shallow water equations and at present includes all of the tendency terms but not time stepping. Here we share the results of Omega-0 verification and performance testing. Verification includes unit tests implemented with CTest as well as convergence tests in Polaris, an in-house python package with a large suite of test problems. Performance tests compare simulations conducted on CPUs versus GPUs and across different architectures: tests are run on Frontier, which has AMD “Optimized 3rd Gen EPYC” CPUs and AMD MI250X GPUs, as well as Perlmutter, which is composed of AMD EPYC 7763 CPUs and NVIDIA A100 GPUs.

58 GEOSCIENCES

Laser Processed Heat Exchangers

The Laser Processed Heat Exchanger project will investigate the use of laser processed surfaces to reduce mass and volume in liquid/liquid heat exchangers as well as the replacement of the harmful and problematic coatings of the Condensing Heat Exchangers (CHX). For this project, two scale unit test articles will be designed, manufactured, and tested. These two units are a high efficiency liquid/liquid HX and a high reliability CHX.

Hansen, Scott

A High-power Electric Propulsion Test Platform in Space

This paper will describe the results of the preliminary phase of a NASA design study for a facility to test high-power electric propulsion systems in space. The results of this design study are intended to provide a firm foundation for subsequent detailed design and development activities leading to the deployment of a valuable space facility. The NASA Exploration Systems Mission Directorate is sponsoring this design project. A team from the NASA Johnson Space Center, Glenn Research Center, the Marshall Space Flight Center and the International Space Station Program Office is conducting the project. The test facility is intended for a broad range of users including government, industry and universities. International participation is encouraged. The objectives for human and robotic exploration of space can be accomplished affordably, safely and effectively with high-power electric propulsion systems. But, as thruster power levels rise to the hundreds of kilowatts and up to megawatts, their testing will pose stringent and expensive demands on existing Earth-based vacuum facilities. These considerations and the human access to near-Earth space provided by the International Space Station (ISS) have led to a renewed interest in space testing. The ISS could provide an excellent platform for a space-based test facility with the continuous vacuum conditions of the natural space environment and no chamber walls to modify the open boundary conditions of the propulsion system exhaust. The test platform could take advantage of the continuous vacuum conditions of the natural space environment. Space testing would provide open boundary conditions without walls, micro-gravity and a realistic thermal environment. Testing on the ISS would allow for direct observation of the test unit, exhaust plume and space-plasma interactions. When necessary, intervention by on-board personnel and post-test inspection would be possible. The ISS can provide electrical power, a location for diagnostic instruments, data handling and thermal control. The platform will be designed to accommodate the side-by-side testing of multiple types of electric thrusters. It is intended to be a permanent facility in which different thrusters can be tested over time. ISS crews can provide maintenance for the platform and change out thruster test units as needed. The primary objective of this platform is to provide a test facility for electric propulsion devices of interest for future exploration missions. These thrusters are expected to operate in the range of hundreds of kilowatts and above. However, a platform with this capability could also accommodate testing of thrusters that require much lower power levels. Testing at the higher power levels would be accomplished by using power fiom storage devices on the platform, which would be gradually recharged by the ISS power generation system. This paper will summarize the results of the preliminary phase of the study with an explanation of the user requirements and the initial conceptual design. The concept for test operations will also be described. The NASA project team is defining the requirements but they will also reflect the inputs of the broader electric propulsion community including those at universities, commercial enterprises and other government laboratories. As a facility on the International Space Station, the design requirements are also intended to encompass the needs of international users. Testing of electric propulsion systems on the space station will help advance the development of systems needed for exploration and could also serve the needs of other customers. Propulsion systems being developed for commercial and military applications could be tested and certification testing of mature thrusters could be accomplished in the space environment.

Petro, Andrew J.

Thermal mechanical analysis of sprag clutches

Work done at Case Western Reserve University on the Thermal Mechanical analysis of sprag helicopter clutches is reported. The report is presented in two parts. The first part is a description of a test rig for the measurement of the heat generated by high speed sprag clutch assemblies during cyclic torsional loading. The second part describes a finite element modeling procedure for sliding contact. The test rig provides a cyclic torsional load of 756 inch-pounds at 5000 rpm using a four-square arrangement. The sprag clutch test unit was placed between the high speed pinions of the circulating power loop. The test unit was designed to have replaceable inner ad outer races, which contain the instrumentation to monitor the sprag clutch. The torque loading device was chosen to be a water cooled magnetic clutch, which is controlled either manually or through a computer. In the second part, a Generalized Eulerian-Lagrangian formulation for non-linear dynamic problems is developed for solid materials. This formulation is derived from the basic laws and axioms of continuum mechanics. The novel aspect of this method is that we are able to investigate the physics in the spatial region of interest as material flows through it without having to follow material points. A finite element approximation to the governing equations is developed. Iterative Methods for the solution of the discrete finite element equations are explored. A FORTRAN program to implement this formulation is developed and a number of solutions to problems of sliding contact are presented.

Mullen, Robert L.

Closure Report for Corrective Action Unit 572: Test Cell C Ancillary Building and Structures, Nevada National Security Site, Nevada, Revision 0

The purpose of this CR is to provide documentation supporting the completed corrective actions and data confirming that the closure objectives for CAU 572 were met. To achieve this, the following actions were performed: • Corrective action investigation (CAI) activities were performed from August 2020 through May 2023, as set forth in the SAFER Plan for CAU 572; and in accordance with the Soils Activity Quality Assurance Plan, which establishes requirements, technical planning, and general quality practices. • Corrective actions were completed during decontamination and demolition (D&D) and disposal activities, and were performed from August 2022 through September 2025.

54 ENVIRONMENTAL SCIENCES

Improved CPAS Photogrammetric Capabilities for Engineering Development Unit (EDU) Testing

This paper focuses on two key improvements to the photogrammetric analysis capabilities of the Capsule Parachute Assembly System (CPAS) for the Orion vehicle. The Engineering Development Unit (EDU) system deploys Drogue and Pilot parachutes via mortar, where an important metric is the muzzle velocity. This can be estimated using a high speed camera pointed along the mortar trajectory. The distance to the camera is computed from the apparent size of features of known dimension. This method was validated with a ground test and compares favorably with simulations. The second major photogrammetric product is measuring the geometry of the Main parachute cluster during steady-state descent using onboard cameras. This is challenging as the current test vehicles are suspended by a single-point attachment unlike earlier stable platforms suspended under a confluence fitting. The mathematical modeling of fly-out angles and projected areas has undergone significant revision. As the test program continues, several lessons were learned about optimizing the camera usage, installation, and settings to obtain the highest quality imagery possible.

Ray, Eric S.

Test Driven Development of Scientific Models

Test-Driven Development (TDD) is a software development process that promises many advantages for developer productivity and has become widely accepted among professional software engineers. As the name suggests, TDD practitioners alternate between writing short automated tests and producing code that passes those tests. Although this overly simplified description will undoubtedly sound prohibitively burdensome to many uninitiated developers, the advent of powerful unit-testing frameworks greatly reduces the effort required to produce and routinely execute suites of tests. By testimony, many developers find TDD to be addicting after only a few days of exposure, and find it unthinkable to return to previous practices. Of course, scientific/technical software differs from other software categories in a number of important respects, but I nonetheless believe that TDD is quite applicable to the development of such software and has the potential to significantly improve programmer productivity and code quality within the scientific community. After a detailed introduction to TDD, I will present the experience within the Software Systems Support Office (SSSO) in applying the technique to various scientific applications. This discussion will emphasize the various direct and indirect benefits as well as some of the difficulties and limitations of the methodology. I will conclude with a brief description of pFUnit, a unit testing framework I co-developed to support test-driven development of parallel Fortran applications.

Clune, Thomas L.

Evaluation and characterization of the methane-carbon dioxide decomposition reaction

A program was conducted to evaluate and characterize the carbon dioxide-methane (CO2-CH4) decomposition reaction, i.e., CO2 + CH4 = 2C + 2H2O. The primary objective was to determine the feasibility of applying this reaction at low temperatures as a technique for recovering the oxygen (O2) remaining in the CO2 which exits mixed with CH4 from a Sabatier CO2 reduction subsystem (as part of an air revitalization system of a manned spacecraft). A test unit was designed, fabricated, and assembled for characterizing the performance of various catalysts for the reaction and ultraviolet activation of the CH4 and CO2. The reactor included in the test unit was designed to have sufficient capacity to evaluate catalyst charges of up to 76 g (0.17 lb). The test stand contained the necessary instrumentation and controls to obtain the data required to characterize the performance of the catalysts and sensitizers tested: flow control and measurement, temperature control and measurement, product and inlet gas analysis, and pressure measurement. A product assurance program was performed implementing the concepts of quality control and safety into the program effort.

Davenport, R. J.