SEARCH · Engineering Papers

Results for “Software Porting”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 37 records · Page 2

All sources NASA NTRS DOE OSTI

DOE OSTI2024

FTTN: Feature-Targeted Testing for Numerical Properties of NVIDIA & AMD Matrix Accelerators

While NVIDIA has been the dominant provider of GPUs for HPC and ML, now AMD has several offerings of GPUs. This encourages programmers to try out AMD GPUs for new codes and also port existing codes over. Unfortunately, without understanding the floating-point differences between these GPU types, software development or porting can introduce bugs—and currently such an understanding is lacking. The magnitude of this open question becomes clear if one imagines the the number of floating-point precision choices (FP16, FP32, etc.), floating-point formats (standard floats, brain-float, etc.), and execution units available (elementary units, matrix/tensor cores, etc.) Questions such as rounding modes and subnormal support are also important. Most of these answers are unknown today or are hard to access. We provide the first testing-guided approach that answers a significant number of these questions. We also devise tests to reveal internal information (e.g., extra bits kept) to make sure that our findings are reliable. Many of our tests employ systematically generated random-programs, others apply fast-math flags and some involve fused multiplyadd. Especially for tensor/matrix cores, the tests have nontrivial logic that we present Our testing approach is reusable for the plethora of GPUs yet to be introduced. Our findings include up to 7 ulps of difference between NVIDIA and AMD for sin and cos at FP32 precision and 3 ulp at FP64. In our study of matrix cores (NVIDIA) and tensor cores (AMD), we have extensively characterized rounding modes (truncation versus round-to-nearest), the number of extra internal bits kept (whether 3 bits are kept or not), subnormal support for inputs and outputs across four different floating-point formats and across NVIDIA A100 and AMD MI250X GPUs. We believe that this wealth of data becoming available for the first time may help avoid significant porting bugs when migrating code across these platforms.

Li, Xinyi↗

NASA NTRS2005

Self port scanning tool : providing a more secure computing Environment through the use of proactive port scanning

Secure computing is a necessity in the hostile environment that the internet has become. Protection from nefarious individuals and organizations requires a solution that is more a methodology than a one time fix. One aspect of this methodology is having the knowledge of which network ports a computer has open to the world, These network ports are essentially the doorways from the internet into the computer. An assessment method which uses the nmap software to scan ports has been developed to aid System Administrators (SAs) with analysis of open ports on their system(s). Additionally, baselines for several operating systems have been developed so that SAs can compare their open ports to a baseline for a given operating system. Further, the tool is deployed on a website where SAs and Users can request a port scan of their computer. The results are then emailed to the requestor. This tool aids Users, SAs, and security professionals by providing an overall picture of what services are running, what ports are open, potential trojan programs or backdoors, and what ports can be closed.

nMap↗

NASA NTRS2013

GRC GSFC TDRSS Waveform Metrics Report

The report presents software metrics and porting metrics for the GGT Waveform. The porting was from a ground-based COTS SDR, the SDR-3000, to the CoNNeCT JPL SDR. The report does not address any of the Operating Environment (OE) software development, nor the original TDRSS waveform development at GSFC for the COTS SDR. With regard to STRS, the report presents compliance data and lessons learned.

Mortensen, Dale J.↗

NASA NTRS2018

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospace's command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for users to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS "App Store".. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

Computer Programming and Software↗

NASA NTRS1992

Visualization techniques to aid in the analysis of multi-spectral astrophysical data sets

This report describes our project activities for the period Sep. 1991 - Oct. 1992. Our activities included stabilizing the software system STAR, porting STAR to IDL/widgets (improved user interface), targeting new visualization techniques for multi-dimensional data visualization (emphasizing 3D visualization), and exploring leading-edge 3D interface devices. During the past project year we emphasized high-end visualization techniques, by exploring new tools offered by state-of-the-art visualization software (such as AVS3 and IDL4/widgets), by experimenting with tools still under research at the Department of Computer Science (e.g., use of glyphs for multidimensional data visualization), and by researching current 3D input/output devices as they could be used to explore 3D astrophysical data. As always, any project activity is driven by the need to interpret astrophysical data more effectively.

Domik, Gitta↗

NASA NTRS1994

Using Commercial Off-the-Shelf Software Tools for Space Shuttle Scientific Software

In October 1993, the Astronaut Science Advisor (ASA) was on board the STS-58 flight of the space shuttle. ASA is an interactive system providing data acquisition and analysis, experiment step re-scheduling, and various other forms of reasoning. As fielded, the system runs on a single Macintosh PowerBook 170, which hosts the six ASA modules. There is one other piece of hardware, an external (GW Instruments, Sommerville, Massachusetts) analog-to-digital converter connected to the PowerBook's SCSI port. Three main software tools were used: LabVIEW, CLIPS, and HyperCard: First, a module written in LabVIEW (National Instruments, Austin, Texas) controls the A/D conversion and stores the resulting data in appropriate arrays. This module also analyzes the numerical data to produce a small set of characteristic numbers or symbols describing the results of an experiment trial. Second, a forward-chaining inference system written in CLIPS (NASA) uses the symbolic information provided by the first stage with a static rule base to infer decisions about the experiment. This expert system shell is used by the system for diagnosis. The third component of the system is the user interface, written in HyperCard (Claris Inc. and Apple Inc., both in Cupertino, California).

Groleau, Nicolas↗

NASA NTRS2002

Wireless Temperature-Monitoring System

A relatively inexpensive instrumentation system that includes units that are connected to thermocouples and that are parts of a radio-communication network has been developed to enable monitoring of temperatures at multiple locations. Because there is no need to string wires or cables for communication, the system is well suited for monitoring temperatures at remote locations and for applications in which frequent changes of monitored or monitoring locations are needed. The system can also be adapted to monitoring of slowly varying physical quantities, other than temperature, that can be transduced by solid-state electronic sensors. electronic sensors. The system comprises any number of transmitting units and a single receiving unit. Each transmitting unit includes connections for as many as four external thermocouples, a signal-conditioning module, a control module, and a radio-communication module. The signal-conditioning module acts as an interface between the thermocouples and the rest of the transmitting unit and includes a built-in solid ambient temperature sensor that is in addition to the external thermocouples. The control module is a system-on-chip embedded processor that includes analog-to-digital converters, serial and parallel data ports, and an interface for local connection to an analog meter that is used during installation to verify correct operation. The radio-communication module contains a commercial spread-spectrum transceiver that operates in the 900-MHz industrial, scientific, and medical (ISM) frequency band. This transceiver transmits data to the receiving unit at a rate of 19,200 baud. The receiving unit includes a transceiver like that of a transmitting unit, plus a control module that contains a system-on-chip processor that includes serial data port for output to a computer that runs monitoring and/or control software, a parallel data port for output to a printer, and a seven-segment light-emitting-diode display. Each transmitting unit is battery-powered and can operate for at least seven days continuously while reporting temperatures every half hour. The receiving unit is powered by a wall-mounted transformer source. The receiving unit responds to each transmitting unit and reports the readings of each of the four thermocouples and of the ambient-temperature sensor of the transmitting unit. The end-to-end accuracy of the system is plus or minus 0.2 C over the temperature range from 0 to 100 C. The radio-communication range between the receiving and transmitting units is approximately equal to 0.5 mile (approximately equal to 0.8 km).

Solano, Wanda↗

NASA NTRS2003

Wireless Temperature-Monitoring System

A relatively inexpensive instrumentation system that includes units that are connected to thermocouples and that are parts of a radio-communication network has been developed to enable monitoring of temperatures at multiple locations. Because there is no need to string wires or cables for communication, the system is well suited for monitoring temperatures at remote locations and for applications in which frequent changes of monitored or monitoring locations are needed. The system can also be adapted to monitoring of slowly varying physical quantities, other than temperature, that can be transduced by solid-state electronic sensors. The system comprises any number of transmitting units and a single receiving unit (see figure). Each transmitting unit includes connections for as many as four external thermocouples, a signal-conditioning module, a control module, and a radio-communication module. The signal- conditioning module acts as an interface between the thermocouples and the rest of the transmitting unit and includes a built-in solid ambient-temperature sensor that is in addition to the external thermocouples. The control module is a "system-on-chip" embedded processor that includes analog-to-digital converters, serial and parallel data ports, and an interface for local connection to an analog meter that is used during installation to verify correct operation. The radio-communication module contains a commercial spread-spectrum transceiver that operates in the 900-MHz industrial, scientific, and medical (ISM) frequency band. This transceiver transmits data to the receiving unit at a rate of 19,200 baud. The receiving unit includes a transceiver like that of a transmitting unit, plus a control module that contains a system-on-chip processor that includes serial data port for output to a computer that runs monitoring and/or control software, a parallel data port for output to a printer, and a seven-segment light-emitting-diode display.

Solano, Wanda↗

DOE OSTI2021

Evaluation of AC optimal power flow on graphical processing units

This paper investigates the performance of alternating current optimal power flow (ACOPF) on hardware accelerators such as graphical processing units (GPUs). We describe the strategies employed and the software used to port the ACOPF application to GPU. Through reorganizing the flow of fundamental calculations, restructuring data organization for the GPUs, and using portability libraries, maximum utilization of GPU is attempted. We present details of our efforts with representative results on 200, 500, and 2000-bus networks.

Abhyankar, Shrirang G.↗

NASA NTRS1994

Open system environments

An open system is defined as a system that implements open specifications for interfaces, services, and supporting formats to enable properly engineered applications software to be ported with minimal changes across a wide range of systems; and to interact with users in a style which facilitates user portability. Based on that definition, a reference model for an open system environment is presented.

Schulz, Fritz↗

NASA NTRS1997

Solar-System Tests of Gravitational Theories

We are engaged in testing gravitational theory by means of observations of objects in the solar system. These tests include an examination of the Principle Of Equivalence (POE), the Shapiro delay, the advances of planetary perihelia, the possibility of a secular variation G in the "gravitational constant" G, and the rate of the de Sitter (geodetic) precession of the Earth-Moon system. These results are consistent with our preliminary results focusing on the contribution of Lunar Laser Ranging (LLR), which were presented at the seventh Marcel Grossmann meeting on general relativity. The largest improvement over previous results comes in the uncertainty for (eta): a factor of five better than our previous value. This improvement reflects the increasing strength of the LLR data. A similar analysis presented at the same meeting by a group at the Jet Propulsion Laboratory gave a similar result for (eta). Our value for (beta) represents our first such result determined simultaneously with the solar quadrupole moment from the dynamical data set. These results are being prepared for publication. We have shown how positions determined from different planetary ephemerides can be compared and how the combination of VLBI and pulse timing information can yield a direct tie between planetary and radio frames. We have continued to include new data in our analysis as they became available. Finally, we have made improvement in our analysis software (PEP) and ported it to a network of modern workstations from its former home on a "mainframe" computer.

Shapiro, Irwin↗

NASA NTRS1995

Software Transition Project Retrospectives and the Application of SEL Effort Estimation Model and Boehm's COCOMO to Complex Software Transition Projects

The Multimission Image Processing Subsystem (MIPS) at the Jet Propulsion Laboratory (JPL) has managed transitions of application software sets from one operating system and hardware platform to multiple operating systems and hardware platforms. As a part of these transitions, cost estimates were generated from the personal experience of in-house developers and managers to calculate the total effort required for such projects. Productivity measures have been collected for two such transitions, one very large and the other relatively small in terms of source lines of code. These estimates used a cost estimation model similar to the Software Engineering Laboratory (SEL) Effort Estimation Model. Experience in transitioning software within JPL MIPS have uncovered a high incidence of interface complexity. Interfaces, both internal and external to individual software applications, have contributed to software transition project complexity, and thus to scheduling difficulties and larger than anticipated design work on software to be ported.

SEL Boehm COCOMO↗

NASA NTRS2018

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospaceâ€"TM"s command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for userâ€"TM"s to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS 'App Store'. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

McComas, David↗

NASA NTRSDate not supplied

Propulsive trajectory optimization to minimize surface contamination

MOTIVATION: We present an optimization technique for propulsive vehicles that autonomously minimizes contamination during surface approach and landing. In addition to short-range hoppers, the optimization technique is also fully applicable to traditional orbit-to-surface landers. This study addresses scenarios where surface alterations from propulsion events are counterproductive or hazardous to the mission objectives. This is of immediate interest for landers (whether human or robotic), that may rely on pristine soils collected in the immediate vicinity of landing sites to accomplish science investigations, mining, or ISRU surface operations. Such missions are averse to various surface-plume interactions such as thermal scoring, physical agitation, and contamination. The capability can be applied with minimal impact to the baseline mission concept. METHODS: Optimization algorithms have been developed to calculate descent trajectories and maneuvers, thrust magnitude, and attitude for various mission cases. These parameters are determined as an optimal solution when minimizing either fuel consumption, contamination deposited at the landing site, or some weighted combination of both. Among constraints imposed on the solution, we examined pitch rate, vertical takeoff and vertical landing (VTVL) requirements, size of the contamination zone, and minimum ground clearance during flight. This tool provides unique, non-intuitive solutions and can be a valuable resource for mission planners. RESULTS: A variety of agile trajectory solutions were obtained, each yielding different reductions in landing site contamination and corresponding to only modest increases in fuel consumption. Several optimal trajectories were obtained by varying the contamination weight in the fitness function. As expected, when the contamination weight is zero, the trajectory appears close to parabolic since the optimization scheme only attempts to minimize for fuel utilization, yielding essentially, the expected ballistic trajectory. Notably for contamination weights greater than zero, trajectory inflections are observed in the descent phase, which manifests as hovering or additional, mini “pseudo hops” before the final touchdown. A trajectory inflection is characterized by arresting the majority of the spacecraft vertical velocity component at a coordinate outside of the landing target, and without violating ground clearance constraints. FUTURE WORK: Our optimization technique is ready for laboratory or field demonstrations to validate the sophisticated maneuvering solutions obtained for fuel optimization and surface preservation. An appropriate testbed would validate the optimal guidance algorithms, the navigation system, and sensor suite by emulating vehicle flight in closed loop robotic tests. Critically, these algorithms could then be ported to flight software for implementation.

surface contamination↗

NASA NTRS2008

Fault-Tolerant, Multiple-Zone Temperature Control

A computer program has been written as an essential part of an electronic temperature control system for a spaceborne instrument that contains several zones. The system was developed because the temperature and the rate of change of temperature in each zone are required to be maintained to within limits that amount to degrees of precision thought to be unattainable by use of simple bimetallic thermostats. The software collects temperature readings from six platinum resistance thermometers, calculates temperature errors from the readings, and implements a proportional + integral + derivative (PID) control algorithm that adjusts heater power levels. The software accepts, via a serial port, commands to change its operational parameters. The software attempts to detect and mitigate a host of potential faults. It is robust to many kinds of faults in that it can maintain PID control in the presence of those faults.

Granger, James↗

DOE OSTI2025

Using a Large Language Model as a Building Block to Generate Usable Validation and Verification Suite for OpenMP

In the HPC area, both hardware and software move quickly. Often new hardware is developed and deployed, the corresponding software stack, including compilers and other tools, are under active development while leading edge software developers are working to port and tune their applications, all at the same time. While the software ecosystem is in flux, one of the key challenges for users is obtaining insight into the state of implementation of key features in the programming languages and models their applications are using – whether they have been implemented, and whether the implementation conforms to the specification, especially for newly implemented features (less tested by widespread use). OpenMP is one of the most prominent shared memory programming models used for on-node programming in HPC. With the shift towards accelerators (such as GPUs and FPGAs) and heterogeneous programming OpenMP features are getting more complex. It is natural to ask whether generative AI approaches, and large language models (LLMs) in particular, can help in producing validation and verification test suites to allow users better and faster insights into the availability and correctness of OpenMP features of interest. In this work, we explore the use of ChatGPT-4 to generate a suite of tests for OpenMP features. We have chosen a set of directives and clauses, a total of 78 combinations, which first appeared in OpenMP 3.0 (released in May 2008) but are also relevant for accelerators. We prompted ChatGPT to generate tests in the C and Fortran languages, for both host (CPU) and device (accelerator). On the Summit super-computer using the GNU implementation, we found that, of the 78 generated tests 67 C tests and 43 Fortran tests compiled successfully and fewer than those executed to completion. On further analysis we show that not all generated tests are valid. We document the process, results, and provide detailed analysis regarding the quality of tests generated. With the aim of providing input to a production quality validation and verification suite, we manually implement the corrections required to make the tests valid according to the current OpenMP specification. We quantify this effort as small, medium, or large, and record the lines of code changed to correct the invalid tests. With the corrected tests we validate recent implementations from HPE, AMD, and GNU on the Frontier supercomputer. Our experiment and subsequent analysis show that although LLMs are capable of producing HPC specific codes, they are limited by their understanding of the deeper semantics and restrictions of programming models such as OpenMP. Unsurprisingly more commonly used features have better support, while some OpenMP 3.0 directives such as sections and tasking are not universally supported on accelerators. We demonstrate that successful compilation and execution to completion are inadequate metrics for evaluating generated code and that, at this time, commodity LLMs require expert intervention for code verification. This points to gaps in the training data that is currently available for HPC. We demonstrate that with "small" effort 37% of generated invalid C tests and 63% of generated invalid Fortran tests could be corrected. This improves productivity of test generation as we circumvent writing from scratch and the common programming errors associated with it.

Pophale, Swaroop [ORNL] (ORCID:0000000185446367)↗

NASA NTRS1991

Interface Circuit For Printer Port

Electronic circuit, called printer-port interface circuit (PPI) developed to overcome certain disadvantages of previous methods for connecting IBM PC or PC-compatible computer to other equipment. Has both reading and writing modes of operation. Very simple, requiring only six integrated circuits. Provides for moderately fast rates of transfer of data and uses existing unmodified circuit card in IBM PC. When used with appropriate software, circuit converts printer port on IBM PC, XT, AT, or compatible personal computer to general purpose, 8-bit-data, 16-bit address bus that connects to multitude of devices.

Tucker, Jerry H.↗

NASA NTRS2014

Empirical and Face Validity of Software Maintenance Defect Models Used at the Jet Propulsion Laboratory

At the Mission Design and Navigation Software Group at the Jet Propulsion Laboratory we make use of finite exponential based defect models to aid in maintenance planning and management for our widely used critical systems. However a number of pragmatic issues arise when applying defect models for a post-release system in continuous use. These include: how to utilize information from problem reports rather than testing to drive defect discovery and removal effort, practical model calibration, and alignment of model assumptions with our environment.

software reliability↗