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 1,117 records · Page 62
All sourcesNASA NTRSDOE OSTI
NASA NTRS2000

General Purpose Fortran Program for Discrete-Ordinate-Method Radiative Transfer in Scattering and Emitting Layered Media: An Update of DISORT

This update reports a state-of-the-art discrete ordinate algorithm for monochromatic unpolarized radiative transfer in non-isothermal, vertically inhomogeneous, but horizontally homogeneous media. The physical processes included are Planckian thermal emission, scattering with arbitrary phase function, absorption, and surface bidirectional reflection. The system may be driven by parallel or isotropic diffuse radiation incident at the top boundary, as well as by internal thermal sources and thermal emission from the boundaries. Radiances, fluxes, and mean intensities are returned at user-specified angles and levels. DISORT has enjoyed considerable popularity in the atmospheric science and other communities since its introduction in 1988. Several new DISORT features are described in this update: intensity correction algorithms designed to compensate for the 8-M forward-peak scaling and obtain accurate intensities even in low orders of approximation; a more general surface bidirectional reflection option; and an exponential-linear approximation of the Planck function allowing more accurate solutions in the presence of large temperature gradients. DISORT has been designed to be an exemplar of good scientific software as well as a program of intrinsic utility. An extraordinary effort has been made to make it numerically well-conditioned, error-resistant, and user-friendly, and to take advantage of robust existing software tools. A thorough test suite is provided to verify the program both against published results, and for consistency where there are no published results. This careful attention to software design has been just as important in DISORT's popularity as its powerful algorithmic content.

Tsay, Si-Chee↗
DOE OSTI2026

Computational capacity in hydrodynamic real-time hybrid simulation applied to simulate the dynamic response of floating offshore wind turbines

Real-time hybrid simulation (RTHS) mitigates similitude distortions in model-scale tests of floating offshore wind turbines (FOWTs) by coupling physical experiments with numerical models in real time. The coupling requires faster-than-real-time numerical computations to satisfy temporal similitude with the physical experiment, presenting a bottleneck for using more complex numerical models in RTHS. This paper presents a hydrodynamic-RTHS (hydro-RTHS) framework for FOWTs that simulates the hydrodynamics physically and the aerodynamics numerically with sensor feedback from the physical testing. The framework adapts the three-loop hardware architecture to leverage greater computational resources and mitigate strict temporal requirements, enabling more computationally demanding numerical analyses in hydro-RTHS. The three-loop hardware architecture integrates multiple machines, each dedicated to either numerical analysis or RTHS controls, with a rate-transition algorithm to synchronize the tasks executed across the different machine processors. Virtual and physical tests verified and validated the hydro-RTHS framework, respectively. The ”virtual” tests, which approximates the physical domain numerically, verified the RTHS framework with respect to a numerical full-scale complete FOWT model simulated in the open-source software, OpenFAST. The virtual tests were able to maintain comparable control signals while enabling greater computational resources for the numerical calculations. Real-world physical tests demonstrated that the hydro-RTHS framework computes aerodynamic forces similar to the complete OpenFAST model, validating the hydro-RTHS framework using the three-loop hardware architecture. Findings show that the hydro-RTHS framework with the three-loop hardware architecture is computationally efficient, with reserve capacity to simulate more complex problems due to the customized software, hardware, and rate-transition algorithm.

17 WIND ENERGY↗
DOE OSTI2021

BeeSwarm: Enabling Parallel Scaling Performance Measurement in Continuous Integration for HPC Applications

Testing is one of the most important steps in software development–it ensures the quality of software. Continuous Integration (CI) is a widely used testing standard that can report software quality to the developer in a timely manner during development progress. Performance, especially scalability, is another key factor for High Performance Computing (HPC) applications. There are many existing profiling and performance tools for HPC applications, but none of these are integrated into CI tools. In this work, we propose BeeSwarm, an HPC container based parallel scaling performance system that can be easily applied to the current CI test environments. BeeSwarm is mainly designed for HPC application developers who need to monitor how their applications can scale on different compute resources. We demonstrate BeeSwarm using a multi-physics HPC application with Travis CI, GitLab CI and GitHub Actions while using ChameleonCloud and Google Compute Engine as the compute backends. Finally, our results show that BeeSwarm can be used for scalability and performance testing of HPC applications.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2016

SU-G-BRB-02: An Open-Source Software Analysis Library for Linear Accelerator Quality Assurance

Purpose: Routine linac quality assurance (QA) tests have become complex enough to require automation of most test analyses. A new data analysis software library was built that allows physicists to automate routine linear accelerator quality assurance tests. The package is open source, code tested, and benchmarked. Methods: Images and data were generated on a TrueBeam linac for the following routine QA tests: VMAT, starshot, CBCT, machine logs, Winston Lutz, and picket fence. The analysis library was built using the general programming language Python. Each test was analyzed with the library algorithms and compared to manual measurements taken at the time of acquisition. Results: VMAT QA results agreed within 0.1% between the library and manual measurements. Machine logs (dynalogs & trajectory logs) were successfully parsed; mechanical axis positions were verified for accuracy and MLC fluence agreed well with EPID measurements. CBCT QA measurements were within 10 HU and 0.2mm where applicable. Winston Lutz isocenter size measurements were within 0.2mm of TrueBeam’s Machine Performance Check. Starshot analysis was within 0.2mm of the Winston Lutz results for the same conditions. Picket fence images with and without a known error showed that the library was capable of detecting MLC offsets within 0.02mm. Conclusion: A new routine QA software library has been benchmarked and is available for use by the community. The library is open-source and extensible for use in larger systems.

43 PARTICLE ACCELERATORS↗
DOE OSTI2014

SU-E-J-266: A Pitfall of a Deformable Image Registration in Lung Cancer

Purpose: For four-dimensional (4D) planning and adaptive radiotherapy, deformable image registration (DIR) is needed and the accuracy is essential. We evaluated the accuracy of one free-downloadable DIR software library package (NiftyReg) and one commercial DIR software (MIM) in lung SBRT cancer patients. Methods: A rigid and non-rigid registrations were implemented to our in-house software. The non-rigid registration algorithm of the NiftyReg and MIM was based on the free-form deformation. The accuracy of the two software was evaluated when contoured structures to peak-inhale and peak-exhale 4DCT image data sets were measured using the dice similarity coefficient (DSC). The evaluation was performed in 20 lung SBRT patients. Results: In our visual evaluation, the eighteen cases show good agreement between the deformed structures for the peak-inhale phase and the peak-exhale phase structures (more than 0.8 DSC value). In the evaluation of the DSC in-house software, averaged DSC values of GTV and lung, heart, spinal cord, stomach and body were 0.862 and 0.979, 0.932, 0.974, 0.860, 0.998, respectively. As the Resultof the registration using the MIM program in the two cases which had less than 0.7 DSC value when analyzed using the in-house software, the DSC value were improved to 0.8. The CT images in a case with low DSC value shows the tumor was surrounded by the structure with the similar CT values, which were the chest wall or the diaphragm. Conclusion: Not only a free-downloadable DIR software but also a commercial software may provide unexpected results and there is a possibility that the results would make us misjudge the treatment planning. Therefore, we recommend that a commissioning test of any DIR software should be performed before clinical use and we should understand the characteristics of the software.

60 APPLIED LIFE SCIENCES↗
NASA NTRS1984

Finding Open Faults In CMOS Circuits

Algorithm specifies sequence of input test signals and interpretation of resulting output signals for identifying stuck-open faults in complementary metal-oxide semiconductor (CMOS) integrated logic circuits. Incorporated in software for online production testing of CMOS circuits.

Chandramouli, R.↗
NASA NTRS2021

An Innovative Approach to Modeling VIPER Rover Software Life Cycle Cost

NASA’s “Volatiles Investigating Polar Exploration Rover” (VIPER) will be the first robotic mission to prospect for water ice near the south pole of the Moon in late 2023 on a 100-Earth-day mission. The information that the VIPER rover provides will help improve understanding of the composition, distribution, and accessibility of Lunar polar volatiles and will help determine how the Moon’s resources can support future human space exploration. VIPER, however, represents a radical departure from the way that NASA has traditionally developed planetary robotic missions. A key consequence of these differences is that estimating the cost of VIPER’s rover software is challenging and complex.For example, VIPER is being developed using management procedures typically applied to NASA research and technology projects, rather than space flight programs. In addition, key portions of the rover’s software are being designed as ground software to run on mission control computers (rather than on-board the rover as flight software as with prior planetary missions) taking advantage of continuous, interactive data communications between the Moon and Earth and higher performance computing available on the ground. Moreover, the rover’s software is being engineered using Agile software development practices and incorporates a significant amount of open-source, rather than following traditional (spiral, waterfall, etc.) development methods and in-house code. In this paper, we present an innovative process to estimate the life cycle cost of VIPER’s rover software. We first describe how we modeled the architecture and code counts for three software elements: Rover Flight Software (RFSW), Rover Ground Software (RGSW), and Rover Simulation Software (RSIM). We then discuss key challenges and unique aspects of our approach, such as the lack of Lunar rover analogies, the need to integrate and test large open source software, and the strategies developed to account for use of non-space flight management practices and the impact of the COVID-19 pandemic. We conclude with a summary of our results, including cumulative distribution, nearest neighbors and cluster analysis, as well as heuristics used to confirm the reasonableness of the cost estimate.

Utz, Hans↗
NASA NTRS2014

Test Driven Development of Scientific Models

Test-Driven Development (TDD), a software development process that promises many advantages for developer productivity and software reliability, 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.After a brief overview of the TDD process and my experience in applying the methodology for development activities at Goddard, I will delve more deeply into some of the challenges that are posed by numerical and scientific software as well as tools and implementation approaches that should address those challenges.

Overview of TDD Process↗
NASA NTRS2006

LiveView3D: Real Time Data Visualization for the Aerospace Testing Environment

This paper addresses LiveView3D, a software package and associated data visualization system for use in the aerospace testing environment. The LiveView3D system allows researchers to graphically view data from numerous wind tunnel instruments in real time in an interactive virtual environment. The graphical nature of the LiveView3D display provides researchers with an intuitive view of the measurement data, making it easier to interpret the aerodynamic phenomenon under investigation. LiveView3D has been developed at the NASA Langley Research Center and has been applied in the Langley Unitary Plan Wind Tunnel (UPWT). This paper discusses the capabilities of the LiveView3D system, provides example results from its application in the UPWT, and outlines features planned for future implementation.

Schwartz, Richard J.↗
NASA NTRS1997

Lessons Learned from the Clementine Mission

According to BMDO, the Clementine mission achieved many of its technology objectives during its flight to the Moon in early 1994 but, because of a software error, was unable to test the autonomous tracking of a cold target. The preliminary analyses of the returned lunar data suggest that valuable scientific measurements were made on several important topics but that COMPLEX's highest-priority objectives for lunar science were not achieved. This is not surprising given that the rationale for Clementine was technological rather than scientific. COMPLEX lists below a few of the lessons that may be learned from Clementine. Although the Clementine mission was not conceived as a NASA science mission exactly like those planned for the Discovery program, many operational aspects of the two are similar. It is therefore worthwhile to understand the strengths and faults of the Clementine approach. Some elements of the Clementine operation that led to the mission's success include the following: (1) The mission's achievements were the responsibility of a single organization and its manager, which made that organization and that individual accountable for the final outcome; (2) The sponsor adopted a hands-off approach and set a minimum number of reviews (three); (3) The sponsor accepted a reasonable amount of risk and allowed the project team to make the trade-offs necessary to minimize the mission's risks while still accomplishing all its primary objectives; and (4) The development schedule was brief and the agreed-on funding (and funding profile) was adhered to. Among the operational shortcomings of Clementine were the following: (1) An overly ambitious schedule and a slightly lean budget (meaning insufficient time for software development and testing, and leading ultimately to human exhaustion); and (2) No support for data calibration, reduction, and analysis. The principal lesson to be learned in this category is that any benefits from the constructive application of higher risk for lower cost and faster schedule will be lost if the schedule does not allow adequate time for the development of all essential systems or makes no allowance for human frailties. Another lesson to be drawn is that despite its limitations, if judged strictly as a science mission, Clementine attested that significant scientific information can be gathered during a technology-demonstration mission. In the current era of limited funds, when science missions will be infrequent, the opportunity to fly scientific instruments aboard missions whose objectives might be other than science must be seized and, indeed, encouraged. During such opportunities it would be inexcusable to do second-class science. Thus the scientific community must be actively involved in such projects from their initiation.

Source record↗
NASA NTRS2007

Expanding Hardware-in-the-Loop Formation Navigation and Control with Radio Frequency Crosslink Ranging

The Formation Flying Testbed (FFTB) at the National Aeronautics and Space Administration (NASA) Goddard Space Flight Center (GSFC) provides a hardware-in-the-loop test environment for formation navigation and control. The facility continues to evolve as a modular, hybrid, dynamic simulation facility for end-to-end guidance, navigation, and control (GN&C) design and analysis of formation flying spacecraft. The core capabilities of the FFTB, as a platform for testing critical hardware and software algorithms in-the-loop, are reviewed with a focus on recent improvements. With the most recent improvement, in support of Technology Readiness Level (TRL) 6 testing of the Inter-spacecraft Ranging and Alarm System (IRAS) for the Magnetospheric Multiscale (MMS) mission, the FFTB has significantly expanded its ability to perform realistic simulations that require Radio Frequency (RF) ranging sensors for relative navigation with the Path Emulator for RF Signals (PERFS). The PERFS, currently under development at NASA GSFC, modulates RF signals exchanged between spacecraft. The RF signals are modified to accurately reflect the dynamic environment through which they travel, including the effects of medium, moving platforms, and radiated power.

Mitchell, Jason W.↗
NASA NTRS1994

Test/score/report: Simulation techniques for automating the test process

A Test/Score/Report capability is currently being developed for the Transportable Payload Operations Control Center (TPOCC) Advanced Spacecraft Simulator (TASS) system which will automate testing of the Goddard Space Flight Center (GSFC) Payload Operations Control Center (POCC) and Mission Operations Center (MOC) software in three areas: telemetry decommutation, spacecraft command processing, and spacecraft memory load and dump processing. Automated computer control of the acceptance test process is one of the primary goals of a test team. With the proper simulation tools and user interface, the task of acceptance testing, regression testing, and repeatability of specific test procedures of a ground data system can be a simpler task. Ideally, the goal for complete automation would be to plug the operational deliverable into the simulator, press the start button, execute the test procedure, accumulate and analyze the data, score the results, and report the results to the test team along with a go/no recommendation to the test team. In practice, this may not be possible because of inadequate test tools, pressures of schedules, limited resources, etc. Most tests are accomplished using a certain degree of automation and test procedures that are labor intensive. This paper discusses some simulation techniques that can improve the automation of the test process. The TASS system tests the POCC/MOC software and provides a score based on the test results. The TASS system displays statistics on the success of the POCC/MOC system processing in each of the three areas as well as event messages pertaining to the Test/Score/Report processing. The TASS system also provides formatted reports documenting each step performed during the tests and the results of each step. A prototype of the Test/Score/Report capability is available and currently being used to test some POCC/MOC software deliveries. When this capability is fully operational it should greatly reduce the time necessary to test a POCC/MOC software delivery, as well as improve the quality of the test process.

Hageman, Barbara H.↗
DOE OSTI2021

Validating Intra-Plate Power Distributions in the Advanced Test Reactor

We report that the neutronics software, HELIOS, was validated in 2015 for performing core reload design and safety analysis of the Advanced Test Reactor. However, when HELIOS was benchmarked against historic fission-wire measurements (i.e., zero-power full-core measurements) a statistically resolved calculation-to-measurement bias was discovered. The azimuthal power along each fuel plate computed by HELIOS has consistently shown to under-predict measurements made by fission-wires in historic zero-power tests near the fuel element side-plates. It was hypothesized during the HELIOS software validation work, that this bias is attributable to local moderation in coolant vents in the side-plates axially just above and below the fission-wires on the fuel-plate edges. This work used detailed MCNP and MC21 models of the side-plate vents to test this hypothesis. By comparing the average azimuthal biases between HELIOS, and 2D and 3D MCNP models, and a 3D MC21 model, it was found that the HELIOS azimuthal bias is not due to the measurement.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗
NASA NTRS1971

Graphic displays for large aerodynamic test facilities

A combination of software and hardware for a time-sharing computer is described which allows the user to obtain an on-line data display in the control room of a large research facility. Display and hard copy of alphanumeric data as well as graphical data can be obtained as desired by the user. In addition, a number of utility programs provide for on-line graphic editing, program control, data manipulation, and off-line microfilm processing.

Whipple, D. L.↗
NASA NTRS1974

ASTEP user's guide and software documentation

The Algorithm Simulation Test and Evaluation Program (ASTEP) is a modular computer program developed for the purpose of testing and evaluating methods of processing remotely sensed multispectral scanner earth resources data. ASTEP is written in FORTRAND V on the UNIVAC 1110 under the EXEC 8 operating system and may be operated in either a batch or interactive mode. The program currently contains over one hundred subroutines consisting of data classification and display algorithms, statistical analysis algorithms, utility support routines, and feature selection capability. The current program can accept data in LARSC1, LARSC2, ERTS, and Universal formats, and can output processed image or data tapes in Universal format.

Gliniewicz, A. S.↗
NASA NTRS1980

Improved definition of crustal anomalies for Magsat data

Ongoing efforts to define and model external magnetic field activities are summarized. Data were obtained and plotted for the five international quiet days of each month Magsat was in orbit. The values of the magnetic field at midnight were also plotted for each of the quiet days. Results show that the zero level of the field fluctuates over the time interval considered. Statistical studies were made for the Kp and Ap indices and more sunspot numbers were obtained for the Magsat period. Satellite data are being thinned and reformatted to make them more amenable to testing the Dst and Sq corrections. The software for processing Magsat tapes is being tested with intermediate attitude data.

Source record↗
DOE OSTI2024

FORCE Regression Testing

Via programs including the Light Water Reactor Sustainability and Integrated Energy Systems, the U.S. Department of Energy has invested in the Framework for Optimization of ResourCes and Economics (FORCE) software framework (Idaho National Laboratory 2024a) for the technical and economic analysis of nuclear-integrated energy systems (IES). Nuclear IES expand the use of nuclear from traditional baseload electricity generation to a flexible and adaptive source of combined heat and power. Nuclear heat can be used in the production of a variety of energy currencies such as hydrogen and ammonia as well as other heat applications including water desalination and district heating. FORCE is designed with the intent to provide interconnected analysis tools that enable the accurate technical and economic assessment of specific nuclear IES configurations for individual energy markets. FORCE consists of three main analysis pathways: HYBRID (Idaho National Laboratory 2024b), which contains high-resolution physical models for IES; Holistic Energy Resource Optimization Network (HERON) (Idaho National Laboratory 2024c), which analyzes IES long-term economic viability; and Optimization of Real-time Capacity Allocation (ORCA) (Idaho National Laboratory 2024d), designed for real-time control of IES via digital twins and optimal decision making, including autonomous and remote operation research. Development of the FORCE ecosystem is guided by three pillars: capability, which assures that the computational requirements of IES analysis are met by the software tools; reliability, which provides for consistent code performance and expected behaviors; and accessibility, which lowers the barrier to entry for using the software and accelerates analysis by users beyond the FORCE primary developers. Reliability of the FORCE ecosystem is established according to the American Nuclear Society?s Nuclear Quality Assurance (NQA-1) program [American Society of Mechanical Engineers 1982], with specific levels of software quality assurance (SQA) within NQA-1 applied to each software tool in FORCE. As the tools within FORCE have matured, some integration algorithms to accurately connect the software tools for holistic analysis have been developed and deployed within the FORCE software repository. In accordance with NQA-1 standards, regression tests are required to guarantee the software performs consistently even when new capabilities are added to the software. In this report, we document the deployment of both unit tests, which test the consistent behavior of small pieces of the FORCE code base, as well as integration tests, which test the consistent performance of full use cases for the FORCE integration algorithms. We further document the encapsulation of these tests within a test harness, which collectively checks for each successful test completion on demand. Finally, we document the automation of the test harness using GitHub Actions [GitHub 2024], which require all tests succeed before any new capability or other changes can be added to the FORCE integration software

97 MATHEMATICS AND COMPUTING↗