Search NASA⌕ Search

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 127 records · Page 7

Rapid Prototyping of an Aircraft Model in an Object-Oriented Simulation

A team was created to participate in the Mars Scout Opportunity. Trade studies determined that an aircraft provided the best opportunity to complete the science objectives of the team. A high fidelity six degree of freedom flight simulation was required to provide credible evidence that the aircraft design fulfilled mission objectives and to support the aircraft design process by providing performance evaluations. The team created the simulation using the Langley Standard Real-Time Simulation in C++ (LaSRS++) application framework. A rapid prototyping approach was necessary because the team had only three months to both develop the aircraft simulation model and evaluate aircraft performance as the design and mission parameters matured. The design of LaSRS++ enabled rapid-prototyping in several ways. First, the framework allowed component models to be designed, implemented, unit-tested, and integrated quickly. Next, the framework provides a highly reusable infrastructure that allowed developers to maximize code reuse while concentrating on aircraft and mission specific features. Finally, the framework reduces risk by providing reusable components that allow developers to build a quality product with a compressed testing cycle that relies heavily on unit testing of new components.

Kenney, P. Sean↗

Global Ecosystem Dynamics Investigation (GEDI) Structural Verification Unit (SVU) Vibration Test

This presentation describes the vibration test campaign of the Structural Verification Unit for the Global Ecosystem Dynamics Investigation (GEDI) mission The Structural Verification Unit test campaign served multiple purposes including the qualification of the instrument primary structure, verification of the structure's stiffness, Aperture Control Mechanism assembly level verification, and validation of the control approach for protoflight instrument vibration testing. Testing included three axes of sine burst, random, and sine vibration excitation. This test sequence required a high number of response instrumentation sensors that included tri-axial accelerometers and tri-axial force gauges. Multiple response limiting methods that included acceleration, force, and moment measurements were used to ensure the safety of the flight hardware. The lessons and specific test details learned on the structural verification unit test campaign will reduce test risks for the upcoming instrument-level vibration tests.

Structural Verification Unit↗

UnitTesterSG

UnitTesterSG is a unit testing framework that is designed for nested and/or scientific/engineering data structures. It is designed primarily for testing the outputs if a single function or simulation run by storing the expected results file such that comparisons to the stored output can be made with unit tests after the function or software has been edited. This module is designed to be able to unit test arrays, strings, as well as nested and deeply nested objects (including arrays with tuples inside, arrays with strings inside, etc.). The module is compatable with nested objects, and thus has a dependency on the nestedObjectsFunctions module within. The module takes *calculated* results and then compares them to *expected* results. If no expected results are available (or they do not match the calculated results) the module then offers to store the calculated results as expected results for next time.

Savara, Aditya [Oak Ridge National Lab. (ORNL), Oa↗

Streamlined Approach for Environmental Restoration (SAFER) Plan for Corrective Action Unit 572: Test Cell C Ancillary Building and Structures - Nevada National Security Site, Nevada with ROTC 1

This Streamlined Approach for Environmental Restoration (SAFER) Plan addresses the actions needed to achieve closure for Corrective Action Unit (CAU) 572, Test Cell C Ancillary Building and Structures, identified in the Federal Facility Agreement and Consent Order (FFACO). CAU 572 comprises the following corrective action sites (CASs) located in Area 25 of the Nevada National Security Site: CAS 25-33-01, Building 3220, Equipment Building; CAS 25-33-02, Building 3230, Motor Drive Building; CAS 25-33-03, Building 3231, Pump House; CAS 25-33-04, Building 3232, Cryogenic Evaluation Lab; CAS 25-99-22, Ancillary Facilities. This plan provides the methodology for field activities needed to gather the necessary information for closing CAU 572. There is sufficient information and process knowledge from historical documentation and investigations of similar sites regarding the expected nature and extent of potential contaminants to recommend closure of CAU 572 using the SAFER process. Additional information will be obtained by conducting a field investigation before selecting the appropriate corrective action. It is anticipated that the results of the field investigation and implementation of corrective actions will support a defensible recommendation that no further corrective action is necessary. The purpose of the corrective action investigation (CAI) will be to document and verify the adequacy of existing information; to affirm the decision for either clean closure, closure in place, or no further action; and to provide sufficient data to implement the corrective action. The actual corrective action selected will be based on characterization activities implemented under this SAFER Plan. If it is determined that complete clean closure cannot be accomplished during the CAI, then a hold point will have been reached and the Nevada Division of Environmental Protection (NDEP) will be consulted to determine whether the remaining contamination will be closed under the alternative corrective action of closure in place. This will be presented in a closure report that will be prepared and submitted to NDEP for review and approval.

54 ENVIRONMENTAL SCIENCES↗

Remote Software Application and Display Development

The era of the shuttle program has come to an end, but only to give rise to newer and more exciting projects. Now is the time of the Orion spacecraft, a work of art designed to exceed all previous endeavors of man. NASA is exiting the time of exploration and is entering a new period, a period of pioneering. With this new mission, many of NASAs organizations must undergo a great deal of change and development to support the Orion missions. The Spaceport Command and Control System (SCCS) is the new system that will provide NASA the ability to launch rockets into orbit and thus control Orion and other spacecraft as the goal of populating Mars becomes ever increasingly tangible. Since the previous control system, Launch Processing System (LPS), was primarily designed to launch the shuttles, SCCS was needed as Kennedy Space Center (KSC) reorganized to a multiuser spaceport for commercial flights, providing a more versatile control over rockets. Within SCCS, is the Launch Control System (LCS), which is the remote software behind the command and monitoring of flight and ground system hardware. This internship at KSC has involved two main components in LCS, including Remote Software Application and Display development. The display environment provides a graphical user interface for an operator to view and see if any cautions are raised, while the remote applications are the backbone that communicate with hardware, and then relay the data back to the displays. These elements go hand in hand as they provide monitoring and control over hardware and software alike from the safety of the Launch Control Center. The remote software applications are written in Application Control Language (ACL), which must undergo unit testing to ensure data integrity. This paper describes both the implementation and writing of unit tests in ACL code for remote software applications, as well as the building of remote displays to be used in the Launch Control Center (LCC).

ACL↗

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.↗

Molten salt to supercritical CO2 diffusion-bonded heat exchanger testing to support component certification for advanced nuclear power systems

Commercial utilization of the diffusion-bonded heat exchanger (DBHE) for high-temperature applications has prompted an ASME Boiler and Pressure Vessel Code Case development effort to employ these components in Section III (nuclear plant) applications. As part of this effort, a series of DBHE have been fabricated. These heat exchangers will be among the first printed-circuit geometries to be tested for functionality in a molten salt environment. These 15-25kW test specimens will be evaluated under steady-state conditions to compare pressure drop and terminal temperatures measurements with those predicted by existing flow and heat transfer correlations. The test units will then be subjected to thermal transients similar to those expected in Generation IV reactor systems by varying the hot and cold fluid mass flow rates and by changing inlet temperatures. Data collected from these tests will narrow the technical gaps related to two-fluid PCHE and identify special design requirements of compact heat exchangers containing primary reactor coolant. Descriptions of one of two test units and the testing plan are discussed here.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗

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.↗

Towards Ultra-high-resolution E3SM Land Modeling on Exascale Computers

Here we present an ultra-high-resolution E3SM land model (uELM) for high-fidelity land simulations targeting new Exascale computers. After considering modeling infrastructure compatibility and ELM software features, we designed a parallel model for the uELM development targeting hybrid architectures of new US Exascale computers. We also described a function unit test framework to expedite the piece-wise code porting (with compiler directives), verification, and global variable management. Furthermore, in this study, we report an early uELM model development using OpenACC within a function unit test framework on a pre-Exascale computer, demonstrate the performance of a uLEM submodel with a 3.0-time speedup, and summarize the code porting experience regarding global variable handling, deepcopy, memory reduction, and parallel loop reconstruction.

97 MATHEMATICS AND COMPUTING↗

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↗

DMTN-190: Consistent galaxy colors with Gaussian-Aperture and PSF photometry

Gaussian-Aperture and PSF photometry algorithm measures consistent colors for extended sources such as galaxies that are largely independent of seeing. This technote briefly presents the mathematical description of the algorithm and focuses on its implementation in the Rubin Science Pipelines. This document also serves as a reference for several of the analytical calculations that are tested in the unit tests.

79 ASTRONOMY AND ASTROPHYSICS↗