Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “computer bugs”

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 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS1992

Simulation of cryogenic turbopump annular seals

The goal of the current work is to develop software that can accurately predict the dynamic coefficients, forces, leakage and horsepower loss for annular seals which have a potential for affecting the rotordynamic behavior of the pumps. The fruit of last year's research was the computer code SEALPAL which included capabilities for linear tapered geometry, Moody friction factor and inlet pre-swirl. This code produced results which in most cases compared very well with check cases presented in the literature. TAMUSEAL Icode, which was written to improve SEALPAL by correcting a bug and by adding more accurate integration algorithms and additional capabilities, was then used to predict dynamic coefficients and leakage for the NASA/Pratt and Whitney Alternate Turbopump Development (ATD) LOX Pump's seal.

Palazzolo, Alan B.↗
DOE OSTI2022

MCNP6.3: A Year in Review [Slides]

This presentation discusses the past year and the many accomplishments of the MCNP6.3 team. It states that the MCNP6.3 release is imminent and that the approved, final documents have been making their way to the website. The code executables and source are already packaged up for distribution and the new installer is being finalized and tested now, for all platforms. The package will be sent to RSICC before the end of October 2022. Additionally, the presentation discusses some things to think about as MCNP6.3 is requested and/or used. For example, many of the recent efforts have been focused on making development, updates, and distribution of the code and documents more robust and streamlined. They will be revising/updating documents more frequently than ever before and they will be exploring avenues to distribute official patches to MCNP6.3. As they explain, this allows them to be more responsive to bugs and issues that are identified. In conclusion, the application of a patch to MCNP6.3 will require having the source code.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗
NASA NTRS1986

Improvements to the adaptive maneuvering logic program

The Adaptive Maneuvering Logic (AML) computer program simulates close-in, one-on-one air-to-air combat between two fighter aircraft. Three important improvements are described. First, the previously available versions of AML were examined for their suitability as a baseline program. The selected program was then revised to eliminate some programming bugs which were uncovered over the years. A listing of this baseline program is included. Second, the equations governing the motion of the aircraft were completely revised. This resulted in a model with substantially higher fidelity than the original equations of motion provided. It also completely eliminated the over-the-top problem, which occurred in the older versions when the AML-driven aircraft attempted a vertical or near vertical loop. Third, the requirements for a versatile generic, yet realistic, aircraft model were studied and implemented in the program. The report contains detailed tables which make the generic aircraft to be either a modern, high performance aircraft, an older high performance aircraft, or a previous generation jet fighter.

Burgin, George H.↗
NASA NTRS2016

Thomas Leps Internship Abstract

An optical navigation system is being flown as the backup system to the primary Deep Space Network telemetry for navigation and guidance purposes on Orion. This is required to ensure Orion can recover from a loss of communication, which would simultaneously cause a loss of DSN telemetry. Images taken of the Moon and Earth are used to give range and position information to the navigation computer for trajectory calculations and maneuver execution. To get telemetry data from these images, the size and location of the moon need to be calculated with high accuracy and precision. The reentry envelope for the Orion EM-1 mission requires the centroid and radius of the moon images to be determined within 1/3 of a pixel 3 sigma. In order to ensure this accuracy and precision can be attained, I was tasked with building precise dot grid images for camera calibration as well as building a hardware in the loop test stand for flight software and hardware proofing. To calibrate the Op-Nav camera a dot grid is imaged with the camera, the error between the image dot location and the actual dot location can be used to build a distortion map of the camera and lens system so that images can be fixed to display truth locations. To build the dot grid images I used the Electro Optics Lab optical bench Bright Object Simulator System, and gimbal. The gimbal was slewed to a series of elevations and azimuths. An image of the collimated single point light source was then taken at each position. After a series of 99 images were taken at different locations the single light spots were extracted from each image and added to a composite image containing all 99 points. During the development of these grids it was noticed that an intermittent error in the artificial "star" locations occurred. Prior to the summer this error was attributed to the gimbal having glitches in it's pointing direction and was going to be replaced, however after further examining the issue I determined it to be a software issue. I have since narrowed the likely source of the error down to a Software Development Kit released by the camera supplier PixeLink. I have since developed a workaround in order to build star grids for calibration until the software bug can be isolated and fixed. I was also tasked with building a Hardware in the Loop test stand in order to test the full Op-Nav system. A 4k screen displays simulated Lunar and Terrestrial images from a possible Orion trajectory. These images are then projected through a collimator and then captured with an Op-Nav camera controlled by an Intel NUC computer running flight software. The flight software then analyzes the images to determine attitude and position, this data is then reconstructed into a trajectory and matched to the simulated trajectory in order to determine the accuracy of the attitude and position estimates. In order for the system to work it needs to be precisely and accurately aligned. I developed an alignment procedure that allows the screen, collimator and camera to be squared, centered and collinear with each other within a micron spatially and 5 arcseconds in rotation. I also designed a rigid mount for the screen that was machined on site in Building 10 by another intern. While I was working in the EOL we received a $500k Orion startracker for alignment procedure testing. Due to my prior experience in electronics development, as an ancillary duty, I was tasked with building the cables required to operate and power the startracker. If any errors are made building these cables the startracker would be destroyed, I was honored that the director of the lab entrusted such a critical component with me. This internship has cemented my view on public space exploration. I always preferred public sector to privatization because, as a scientist, the most interesting aspects of space for me are not necessarily the most profitable. I was concerned that the public sector was faltering however, and that in order to improve human space exploration I would be forced into private sector. I now know that, at least at JSC, human spaceflight is still progressing, and exciting work is still being done. I am now actively seeking employment at JSC after I complete my Ph.D and have met with my branch chiefs and mentor to discuss transitioning to a grad Co-op position.

Leps, Thomas↗
DOE OSTI2025

Verification of the REBUS Software

Ongoing design activities at Argonne National Laboratory are requiring a thorough verification of the Argonne Reactor Computation codes be performed. REBUS is central to this system. The driver for this effort requires the Triangular-Z and hexagonal-Z core geometry options of REBUS to be verified. Previous work identified the REBUS features required to be verified to support current design activities, features of which are generally applicable to hexagonal-Z fast reactor designs. The scope of this verification effort includes verifying REBUS’s ability to correctly intepret the user input model, verifying that the features identified yield the intended results, and verifying the correctness of the REBUS output tables. The REBUS software verification relies heavily upon the accuracy of the embedded DIF3D software, the verification of which was completed and documented elsewhere. Given that DIF3D produces an accurate solution, the primary focus of the verification in the REBUS software is to ensure that it properly uses the DIF3D solution and that the depletion system (Bateman equations) are correctly implemented. This manuscript reiterates the verification tasks and displays results with respect to the features needed for current design activities. Analytic solutions of the Batemen equations are displayed and the results calculated with REBUS are displayed demonstrating the accuracy. Since coupled Bateman and neutron diffusion/transport solutions are extremely difficult to obtain, much of the focus is placed on how REBUS uses a given DIF3D solution assuming the accuracy of the DIF3D solution. The verification effort identified no issues that are debilitating or otherwise impactful to the design usage of REBUS, and thus REBUS version 11.0, release 3012 is considered verified. It is important to note that several outputs of REBUS are identified to be inaccurate, such as burnup in MWD/MT. Most of the relevant ones for VTR are generally accurate with 10-20% errors which is not impactful as all regular REBUS users are aware of this issue and know how to hand calculate the results. The REBUS manual further makes it clear that these values are consistent with the methodology being used by REBUS and thus the “errors” are more of an inconsistent definition with respect to what a user would expect given a definition in literature. Other issues that were identified included unclear documentation and software bugs all of which were inconsequential to the final results.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRS1995

Lattice gas methods for computational aeroacoustics

This paper presents the lattice gas solution to the category 1 problems of the ICASE/LaRC Workshop on Benchmark Problems in Computational Aeroacoustics. The first and second problems were solved for Delta t = Delta x = 1, and additionally the second problem was solved for Delta t = 1/4 and Delta x = 1/2. The results are striking: even for these large time and space grids the lattice gas numerical solutions are almost indistinguishable from the analytical solutions. A simple bug in the Mathematica code was found in the solutions submitted for comparison, and the comparison plots shown at the end of this volume show the bug. An Appendix to the present paper shows an example lattice gas solution with and without the bug.

Sparrow, Victor W.↗
DOE OSTI2021

FAST-1.0.1 User Installation and Verification Guide

The purpose of this document is to provide the user information about the installation of FAST-1.0.1 on their computers or servers. General information about the code and supported operating systems is described in Section 1.0.1. Self-service oriented FAST-1.0.1 software licensing steps are described in Section 2.0. An installation verification test suite is provided with FAST-1.0.1 and described in Section 3.0. A convenience script for converting FRAPCON to FAST inputs is discussed in Section 4.0. FAST-1.0.1 was developed and released under a software quality assurance program based upon NQA-1-2017. FAST-1.0.1 is the latest baseline code and the result of a bug fixes to FAST-1.0 with other software and methodology developments. The installation verification test suite contains both steady state and transient Anticipated Operation Occurrences (AOOs). Capability to model accident conditions, such as Reactivity Initiated Accidents (RIAs) and Loss Of Coolant Accidents (LOCAs), are targeted for a later release of FAST. FRAPTRAN-2.0 will continue to be used for accident conditions until the release of FAST with accident condition modeling capabilities.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2021

TOUGHREACT V4.12

TOUGHREACT V4.12 is a 3-D reactive transport code that handles to non-isothermal, multiphase/multicomponent fluid flow, heat transport, aqueous and gaseous species advection-diffusion, and equilibrium/kinetic water-gas-rock-biological reactions. TOUGHREACT V4.12 is based on TOUGHREACT V3.3, with several new features including: an option to compute activity coefficients using the Pitzer ion interaction model; implementation of ECO2N V2.0 for temperatures up to 300 C; options to simulate forward and reverse osmosis, including 2D Poiseuille flow; addition of EOS8 and revisions for EOS5 and EWASG with H2(g); addition of gas species decay, various new output formats and time step control options; many bug fixes.

Spycher, Nicolas↗
DOE OSTI2026

MCNP® Code Version 6.3.2 Theory & User Manual (Rev. 1)

This document acts as a repository of knowledge for the Monte Carlo N-Particle (MCNP) transport computer code. It is maintained alongside the source code and attempts to introduce new users and re-familiarize experienced users with the theory and practices of using the MCNP code for the wide range of particle transport analyses that it is appropriate for. The latest version of the MCNP code, version 6.3.2, provides the Monte Carlo particle transport community with the latest feature developments and bug fixes in the MCNP code. The MCNP code version 6.0 and later is also known as the MCNP6 code.

42 ENGINEERING↗
DOE OSTI2024

SCALE Activities in FY23 [Slides]

This presentation shows that the SCALE 6.3 is available from RSICC. The lecture touches on new features including the new ENDF/B-VIII.0 data including covariances. It shows that the updated parallel infrastructure enables parallel capability on Windows. Production release with maintenance until 2026 at minimum addressing Code or data bugs, Performance, Ease of installation. There is a New Government Use Agreement (GUA) for SCALE 7.0 beta access. With site licenses available for non-commercial testing and feedback, handled through ORNL technology transfer.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1993

Performance of the engineering analysis and data system 2 common file system

The Engineering Analysis and Data System (EADS) was used from April 1986 to July 1993 to support large scale scientific and engineering computation (e.g. computational fluid dynamics) at Marshall Space Flight Center. The need for an updated system resulted in a RFP in June 1991, after which a contract was awarded to Cray Grumman. EADS II was installed in February 1993, and by July 1993 most users were migrated. EADS II is a network of heterogeneous computer systems supporting scientific and engineering applications. The Common File System (CFS) is a key component of this system. The CFS provides a seamless, integrated environment to the users of EADS II including both disk and tape storage. UniTree software is used to implement this hierarchical storage management system. The performance of the CFS suffered during the early months of the production system. Several of the performance problems were traced to software bugs which have been corrected. Other problems were associated with hardware. However, the use of NFS in UniTree UCFM software limits the performance of the system. The performance issues related to the CFS have led to a need to develop a greater understanding of the CFS organization. This paper will first describe the EADS II with emphasis on the CFS. Then, a discussion of mass storage systems will be presented, and methods of measuring the performance of the Common File System will be outlined. Finally, areas for further study will be identified and conclusions will be drawn.

Debrunner, Linda S.↗
DOE OSTI2024

Development of Hydropower Biological Evaluation Toolset (HBET): V2.1.9 Release Notes for HBET

The following release notes reflect changes made to HBET for proposed changes to be released in July 2024. Notes are broken up into three sections: 1) Key Improvements, 2) Bug Fixes, and 3) Data Changes • Key Improvements: primary features added and changes to existing features that affect the user experience. • Bug Fixes: Issues discovered or reported that were fixed in the proposed work to be released. • Data Changes: Any work done on the databases directly or the process to calculate data for the system.

13 HYDRO ENERGY↗
NASA NTRS2010

Modeling Regular Replacement for String Constraint Solving

Bugs in user input sanitation of software systems often lead to vulnerabilities. Among them many are caused by improper use of regular replacement. This paper presents a precise modeling of various semantics of regular substitution, such as the declarative, finite, greedy, and reluctant, using finite state transducers (FST). By projecting an FST to its input/output tapes, we are able to solve atomic string constraints, which can be applied to both the forward and backward image computation in model checking and symbolic execution of text processing programs. We report several interesting discoveries, e.g., certain fragments of the general problem can be handled using less expressive deterministic FST. A compact representation of FST is implemented in SUSHI, a string constraint solver. It is applied to detecting vulnerabilities in web applications

Fu, Xiang↗
NASA NTRS1971

Direct modeling parameter signature analysis and failure mode prediction of physical systems using hybrid computer optimization

High speed automated identification and design of dynamic systems, both linear and nonlinear, are discussed. Special emphasis is placed on developing hardware and techniques which are applicable to practical problems. The basic modeling experiment and new results are described. Using the improvements developed successful identification of several systems, including a physical example as well as simulated systems, was obtained. The advantages of parameter signature analysis over signal signature analysis in go-no go testing of operational systems were demonstrated. The feasibility of using these ideas in failure mode prediction in operating systems was also investigated. An improved digital controlled nonlinear function generator was developed, de-bugged, and completely documented.

Drake, R. L.↗
DOE OSTI2024

CI/CD Efforts for Validation, Verification and Benchmarking OpenMP Implementations

Software developers must adapt to keep up with the changing capabilities of platforms so that they can utilize the power of High-Performance Computers (HPC), including exascale systems. OpenMP, a directive-based parallel programming model, allows developers to include directives to existing C, C++, or Fortran code to allow node level parallelism without compromising performance. This paper describes our CI/CD efforts to provide easy evaluation of the support of OpenMP across different compilers using existing testsuites and benchmark suites on HPC platforms. Our main contributions include (1) the set of a Continuous Integration (CI) and Continuous Development (CD) workflow that captures bugs and provides faster feedback to compiler developers, (2) an evaluation of OpenMP (offloading) implementations supported by AMD, HPE, GNU, LLVM, and Intel, and (3) evaluation of the quality of compilers across different heterogeneous HPC platforms. With the comprehensive testing through the CI/CD workflow, we aim to provide a comprehensive understanding of the current state of OpenMP (offloading) support in different compilers and heterogeneous platforms consisting of CPUs and GPUs from NVIDIA, AMD, and Intel.

Jarmusch, Aaron↗
NASA NTRS2019

Recent Enhancements to NASA’s PCBoom Sonic Boom Propagation Code

This paper presents the recent updates the author has made to PCBoom sonic boom propagation code on its computational efficiency, predictive capability, and file operations. The updated version has recently been released and has a Burgers’ equation solver, which is computationally more efficient than that in the older version by 2 to 3 orders of magnitude. The updated version also enhances the accuracy of the sonic boom propagation prediction by accounting for the full wind effects on the shock wave propagation. Predictions from the updated PCBoom are compared with predictions from the older version and with data from flight tests. Other upgrades and changes that have been made in the latest version include support for Unix-like operating systems, bug fixes, and generation of new types of output files that allow for better manipulation of PCBoom-generated data.

Lonzaga, Joel B.↗
DOE OSTI2024

StructuredFuzzer: Fuzzing Structured Text-Based Control Logic Applications

Rigorous testing methods are essential for ensuring the security and reliability of industrial controller software. Fuzzing, a technique that automatically discovers software bugs, has also proven effective in finding software vulnerabilities. Unsurprisingly, fuzzing has been applied to a wide range of platforms, including programmable logic controllers (PLCs). However, current approaches, such as coverage-guided evolutionary fuzzing implemented in the popular fuzzer American Fuzzy Lop Plus Plus (AFL++), are often inadequate for finding logical errors and bugs in PLC control logic applications. They primarily target generic programming languages like C/C++, Java, and Python, and do not consider the unique characteristics and behaviors of PLCs, which are often programmed using specialized programming languages like Structured Text (ST). Furthermore, these fuzzers are ill suited to deal with complex input structures encapsulated in ST, as they are not specifically designed to generate appropriate input sequences. This renders the application of traditional fuzzing techniques less efficient on these platforms. To address this issue, this paper presents a fuzzing framework designed explicitly for PLC software to discover logic bugs in applications written in ST specified by the IEC 61131-3 standard. The proposed framework incorporates a custom-tailored PLC runtime and a fuzzer designed for the purpose. We demonstrate its effectiveness by fuzzing a collection of ST programs that were crafted for evaluation purposes. We compare the performance against a popular fuzzer, namely, AFL++. The proposed fuzzing framework demonstrated its capabilities in our experiments, successfully detecting logic bugs in the tested PLC control logic applications written in ST. On average, it was at least 83 times faster than AFL++, and in certain cases, for example, it was more than 23,000 times faster.

47 OTHER INSTRUMENTATION↗
NASA NTRS1999

Practical Application of Model Checking in Software Verification

This paper presents our experiences in applying the JAVA PATHFINDER (J(sub PF)), a recently developed JAVA to SPIN translator, in the finding of synchronization bugs in a Chinese Chess game server application written in JAVA. We give an overview of J(sub PF) and the subset of JAVA that it supports and describe the abstraction and verification of the game server. Finally, we analyze the results of the effort. We argue that abstraction by under-approximation is necessary for abstracting sufficiently smaller models for verification purposes; that user guidance is crucial for effective abstraction; and that current model checkers do not conveniently support the computational models of software in general and JAVA in particular.

Havelund, Klaus↗