Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “function 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 19 records
All sourcesNASA NTRSDOE OSTI
DOE OSTI2022

SPEL: Software tool for Porting E3SM Land Model with OpenACC in a Function Unit Test Framework

Most high-end computers adopt hybrid architecture, porting a large-scale scientific code onto accelerators is necessary. The paper presents a generic method for porting large-scale scientific code onto accelerators using compiler directives within a modularized function unit test platform. We have implemented the method and designed a software tool (SPEL) to port the E3SM Land Model (ELM) onto the GPUs in the Summit computer. SPEL automatically generates GPU-ready test modules for all ELM functions, such as CanopyFlux, SoilTemperature, and EcosystemDynamics. SPEL breaks the ELM into a collection of standalone unit test programs for easy code verification and further performance improvement. We further optimize several ELM test modules with advanced techniques, including memory reduction, reconstructed parallel loops, and asynchronous GPU kernel launch. We hope our study will inspire new toolkit developments that expedite large-scale scientific code porting with compiler directives.

Schwartz, Peter↗
NASA NTRS1973

CIT photoheliograph functional verification unit test program

Tests of the 2/3-meter photoheliograph functional verification unit FVU were performed with the FVU installed in its Big Bear Solar Observatory vacuum chamber. Interferometric tests were run both in Newtonian (f/3.85) and Gregorian (f/50) configurations. Tests were run in both configurations with optical axis horizontal, vertical, and at 45 deg to attempt to determine any gravity effects on the system. Gravity effects, if present, were masked by scatter in the data associated with the system wavefront error of 0.16 lambda rms ( = 6328A) apparently due to problems in the primary mirror. Tests showed that the redesigned secondary mirror assembly works well.

Source record↗
DOE OSTI2022

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↗
DOE OSTI2025

Portable Software Environment for Ultrahigh-Resolution ELM Development on GPUs

This paper presents our endeavors in developing the large-scale, ultra-high-resolution E3SM Land Model (uELM), specifically designed for exascale computers furnished with accelerators such as Nvidia GPUs. The uELM is a sophisticated code that substantially relies on High-Performance Computing (HPC) environments, necessitating particular machine and software configurations. To facilitate community-based uELM developments employing GPUs, we have created a portable, standalone software environment preconfigured with uELM input datasets, simulation cases, and source code. This environment, utilizing Docker, encompasses all essential code, libraries, and system software for uELM development on GPUs. It also features a functional unit test framework and an offline model testbed for comprehensive numerical experiments. From a technical perspective, the paper discusses GPU-ready container generations, uELM code management, and input data distribution across computational platforms. Lastly, the paper demonstrates the use of environment for functional unit testing, end-to-end simulation on CPUs and GPUs, and collaborative code development.

E3SM Land Model↗
NASA NTRS2002

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

Software error data collection and categorization

Software errors detected during development of an interactive special purpose editor system were studied. This product was followed during nine months of coding, unit testing, function testing, and system testing. A new error categorization scheme was developed.

Ostrand, T. J.↗
NASA NTRS1995

Stress Prediction System

NASA wanted to know how astronauts' bodies would react under various gravitational pulls and space suit weights. Under contract to NASA, the University of Michigan's Center for Ergonomics developed a model capable of predicting what type of stress and what degree of load a body could stand. The algorithm generated was commercialized with the ISTU (Isometric Strength Testing Unit) Functional Capacity Evaluation System, which simulates tasks such as lifting a heavy box or pushing a cart and evaluates the exertion expended. It also identifies the muscle group that limits the subject's performance. It is an effective tool of personnel evaluation, selection and job redesign.

Source record↗
NASA NTRS2014

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↗
DOE OSTI2020

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↗
NASA NTRS1972

End-to-end test of the electron-proton spectrometer

A series of end-to-end tests were performed to demonstrate the proper functioning of the complete Electron-Proton Spectrometer (EPS). The purpose of the tests was to provide experimental verification of the design and to provide a complete functional performance check of the instrument from the excitation of the sensors to and including the data processor and equipment test set. Each of the channels of the EPS was exposed to a calibrated beam of energetic particles, and counts were accumulated for a predetermined period of time for each of several energies. The counts were related to the known flux of particles to give a monodirectional response function for each channel. The measured response function of the test unit was compared to the response function determined for the calibration sensors from the data taken from the calibration program.

Cash, B. L.↗
NASA NTRS1989

Detection and avoidance of errors in computer software

The acceptance test errors of a computer software project to determine if the errors could be detected or avoided in earlier phases of development. GROAGSS (Gamma Ray Observatory Attitude Ground Support System) was selected as the software project to be examined. The development of the software followed the standard Flight Dynamics Software Development methods. GROAGSS was developed between August 1985 and April 1989. The project is approximately 250,000 lines of code of which approximately 43,000 lines are reused from previous projects. GROAGSS had a total of 1715 Change Report Forms (CRFs) submitted during the entire development and testing. These changes contained 936 errors. Of these 936 errors, 374 were found during the acceptance testing. These acceptance test errors were first categorized into methods of avoidance including: more clearly written requirements; detail review; code reading; structural unit testing; and functional system integration testing. The errors were later broken down in terms of effort to detect and correct, class of error, and probability that the prescribed detection method would be successful. These determinations were based on Software Engineering Laboratory (SEL) documents and interviews with the project programmers. A summary of the results of the categorizations is presented. The number of programming errors at the beginning of acceptance testing can be significantly reduced. The results of the existing development methodology are examined for ways of improvements. A basis is provided for the definition is a new development/testing paradigm. Monitoring of the new scheme will objectively determine its effectiveness on avoiding and detecting errors.

Kinsler, Les↗
NASA NTRS1999

Vacuum Plasma Spray (VPS) Forming of Solar Thermal Propulsion Components Using Refractory Metals

The Thermal Spray Laboratory at NASA's Marshall Space Flight Center has developed and demonstrated a fabrication technique using Vacuum Plasma Spray (VPS) to form structural components from a tungsten/rhenium alloy. The components were assembled into an absorber cavity for a fully-functioning, ground test unit of a solar then-nal propulsion engine. The VPS process deposits refractory metal onto a graphite mandrel of the desired shape. The mandrel acts as a male mold, forming the required contour and dimensions of the inside surface of the deposit. Tungsten and tungsten/25% rhenium were used in the development and production of several absorber cavity components. These materials were selected for their high temperature (greater than 25000 C [greater than 4530 F]) strength. Each absorber cavity comprises 3 coaxial shells with two, double-helical flow passages through which the propellant gas flows. This paper describes the processing techniques, design considerations, and process development associated with forming these engine components.

Zimmerman, Frank R.↗
NASA NTRS1998

Vacuum Plasma Spray (VPS) Forming of Solar Thermal Propulsion Components Using Refractory Metals

The Thermal Spray Laboratory at NASA's Marshall Space Flight Center has developed and demonstrated a fabrication technique using Vacuum Plasma Spray (VPS) to form structural components from a tungsten/rhenium alloy. The components were assembled into an absorption cavity for a fully-functioning, ground test unit of a solar thermal propulsion engine. The VPS process deposits refractory metal onto a graphite mandrel of the desired shape. The mandrel acts as a male mold, forming the required contour and dimensions of the inside surface of the deposit. Tungsten and tungsten/25% rhenium were used in the development and production of several absorber cavity components. These materials were selected for their high temperature (less than 2500 C) strength. Each absorber cavity comprises 3 coaxial shells with two, double-helical flow passages through which the propellant gas flows. This paper describes the processing techniques, design considerations, and process development associated with forming these engine components.

Zimmerman, Frank↗
NASA NTRS2014

Unit Testing and Remote Display Development

The Kennedy Space Center is currently undergoing an extremely interesting transitional phase. The final Space Shuttle mission, STS-135, was completed in July of 2011. NASA is now approaching a new era of space exploration. The development of the Orion Multi- Purpose Crew Vehicle (MPCV) and the Space Launch System (SLS) launch vehicle that will launch the Orion are currently in progress. An important part of this transition involves replacing the Launch Processing System (LPS) which was previously used to process and launch Space Shuttles and their associated hardware. NASA is creating the Spaceport Command and Control System (SCCS) to replace the LPS. The SCCS will be much simpler to maintain and improve during the lifetime of the spaceflight program that it will support. The Launch Control System (LCS) is a portion of the SCCS that will be responsible for launching the rockets and spacecraft. The Integrated Launch Operations Applications (ILOA) group of SCCS is responsible for creating displays and scripts, both remote and local, that will be used to monitor and control hardware and systems needed to launch a spacecraft. It is crucial that the software contained within be thoroughly tested to ensure that it functions as intended. Unit tests must be written in Application Control Language (ACL), the scripting language used by LCS. These unit tests must ensure complete code coverage to safely guarantee there are no bugs or any kind of issue with the software.

LCS↗
NASA NTRS1979

Electrical Characterization of the RCA CDP1822SD Random Access Memory, Volume 1, Appendix a

Electrical characteristization tests were performed on 35 RCA CDP1822SD, 256-by-4-bit, CMOS, random access memories. The tests included three functional tests, AC and DC parametric tests, a series of schmoo plots, rise/fall time screening, and a data retention test. All tests were performed on an automated IC test system with temperatures controlled by a thermal airstream unit. All the functional tests, the data retention test, and the AC and DC parametric tests were performed at ambient temperatures of 25 C, -20 C, -55 C, 85 C, and 125 C. The schmoo plots were performed at ambient temperatures of 25 C, -55 C, and 125 C. The data retention test was performed at 25 C. Five devices failed one or more functional tests and four of these devices failed to meet the expected limits of a number of AC parametric tests. Some of the schmoo plots indicated a small degree of interaction between parameters.

Klute, A.↗
NASA NTRS2019

Command and Control System Automated Testing

The Kennedy Space Center (KSC) has developed its own Command and Control System for the launch of the Space Launch System (SLS) and Orion capsule. The Command and Control System (CCS) is used by console engineers for the launch and system checkout of aerospace vehicles. The CCS allows console engineers to read data from the flight hardware on the launch pad and from the ground control systems and allows console engineers to issue commands, like opening a valve, to the flight hardware and ground control systems. The CCS needs to interact with thousands of devices and hardware controllers for the spacecraft and ground systems, receive data from these devices, distribute the data to console engineers in real-time, and allow console engineers to issue commands to manipulate hardware on the launch pad. The system needs to be robust, fault tolerant, responsive, and fast. In order to keep up with the pace of development of the CCS, a Test Automation System (TAS) is needed to validate the integrity of the system as a whole along with its individual components. Automated tests allow for faster development time, since tests can be ran through a Continuous Integration system and allow developers to check their code faster. Currently, the different modules, classes, and functions that make up the CCS are tested at the unit level, and the system level, with all the modules working together. My project was to implement a system for the data protocol layer of the Command Control System to be tested as a complete functional unit, with all of its classes and functions working together, but independent of the other modules of the CCS.

Automated TestingTest Automation↗
NASA NTRS2000

Environmental Test Screening Procedure

This procedure describes the methods to be used for environmental stress screening (ESS) of the Lightning Mapper Sensor (LMS) lens assembly. Unless otherwise specified, the procedures shall be completed in the order listed, prior to performance of the Acceptance Test Procedure (ATP). The first unit, S/N 001, will be subjected to the Qualification Vibration Levels, while the remainder will be tested at the Operational Level. Prior to ESS, all units will undergo Pre-ESS Functional Testing that includes measuring the on-axis and plus or minus 0.95 full field Modulation Transfer Function and Back Focal Length. Next, all units will undergo ESS testing, and then Acceptance testing per PR 460.

Zeidler, Janet↗