SEARCH · Search NASA

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

NASA NTRS1986

A preliminary design for flight testing the FINDS algorithm

This report presents a preliminary design for flight testing the FINDS (Fault Inferring Nonlinear Detection System) algorithm on a target flight computer. The FINDS software was ported onto the target flight computer by reducing the code size by 65%. Several modifications were made to the computational algorithms resulting in a near real-time execution speed. Finally, a new failure detection strategy was developed resulting in a significant improvement in the detection time performance. In particular, low level MLS, IMU and IAS sensor failures are detected instantaneously with the new detection strategy, while accelerometer and the rate gyro failures are detected within the minimum time allowed by the information generated in the sensor residuals based on the point mass equations of motion. All of the results have been demonstrated by using five minutes of sensor flight data for the NASA ATOPS B-737 aircraft in a Microwave Landing System (MLS) environment.

Caglayan, A. K.↗

NASA NTRS1986

Methods of downloading to user institutions

The Pilot Climate Data System (PCDS) not only supports the ability to output data in a uniform structure via the Common Data Format (CDF, but also supports the ability to provide data in native format for any data set supported by the PCDS. Methods are discussed for acquiring data in either format from the PCDS for further work at remote sites. Four levels of remote utilization are defined, based on the extent of offloading the National Space Science Data Center (NSSDC) computer and local PCDS processing. Characteristics of each level are thoroughly explained, including details of information and data transfers, downloading, uploading, and offloading of the NSSDC computer. Only the levels themselves are specified here. The first level defined is that of a network-based distributed PCDS. A subset of the PCDS software is ported to another VAX and made available on a network (i.e., SPAN) node. There is no subset of the PCDS at the second level, but it is also network based. Non-network utilization of the PCDS, requiring dial-up log on, is denoted as a third level. Finally, at the fourth level, personal computer utilization of the PCDS through dial-up log on with proper terminal emulation is defined.

Treinish, L.↗

NASA NTRS1995

A software bus for thread objects

The authors have implemented a software bus for lightweight threads in an object-oriented programming environment that allows for rapid reconfiguration and reuse of thread objects in discrete-event simulation experiments. While previous research in object-oriented, parallel programming environments has focused on direct communication between threads, our lightweight software bus, called the MiniBus, provides a means to isolate threads from their contexts of execution by restricting communications between threads to message-passing via their local ports only. The software bus maintains a topology of connections between these ports. It routes, queues, and delivers messages according to this topology. This approach allows for rapid reconfiguration and reuse of thread objects in other systems without making changes to the specifications or source code. A layered approach that provides the needed transparency to developers is presented. Examples of using the MiniBus are given, and the value of bus architectures in building and conducting simulations of discrete-event systems is discussed.

Callahan, John R.↗

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↗

DOE OSTI2016

STAR-CCM+ Verification and Validation Plan

The commercial Computational Fluid Dynamics (CFD) code STAR-CCM+ provides general purpose finite volume method solutions for fluid dynamics and energy transport. This document defines plans for verification and validation (V&V) of the base code and models implemented within the code by the Consortium for Advanced Simulation of Light water reactors (CASL). The software quality assurance activities described herein are port of the overall software life cycle defined in the CASL Software Quality Assurance (SQA) Plan [Sieger, 2015]. STAR-CCM+ serves as the principal foundation for development of an advanced predictive multi-phase boiling simulation capability within CASL. The CASL Thermal Hydraulics Methods (THM) team develops advanced closure models required to describe the subgrid-resolution behavior of secondary fluids or fluid phases in multiphase boiling flows within the Eulerian-Eulerian framework of the code. These include wall heat partitioning models that describe the formation of vapor on the surface and the forces the define bubble/droplet dynamic motion. The CASL models are implemented as user coding or field functions within the general framework of the code. This report defines procedures and requirements for V&V of the multi-phase CFD capability developed by CASL THM. Results of V&V evaluations will be documented in a separate STAR-CCM+ V&V assessment report. This report is expected to be a living document and will be updated as additional validation cases are identified and adopted as part of the CASL THM V&V suite.

97 MATHEMATICS AND COMPUTING↗

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↗

DOE OSTI2017

Supplement to the NUBOW-3D Manual

The NUBOW-3D code (NUBOW) developed in 1978 is a custom FORTRAN analysis code that models the complex mechanical interaction of the fuel assemblies and the core restraint system in response to the effects of thermal expansion and irradiation swelling and creep. NUBOW-3D models the fuel assembly ducts as beams with springs representing the contact between ducts. The core temperature profile and neutron flux profiles are provided at various times during the planned operation of the reactor. NUBOW then calculates the changing shapes of the fuel assemblies and their equilibrium positions within the core restraints. An optional post-processing step calculates the reactivity changes based on new positions of the fuel assemblies using input displacement reactivity WORTHS. Understanding this reactivity change is a key feature to the inherent safety of a fast reactor core. NUBOW was developed to support the design of limited free bow core restraint systems. The NUBOW software was modified in 1987 but the documentation of the upgrades was not completed due to abrupt funding cuts. In the last few years, the software has been ported to a Windows platform using a current FORTRAN compiler and additional changes have been made including consolidating the code to a single executable. While the original NUBOW manual [1] written in 1978 provides an excellent description of the code and input parameters, it lacks the additional features added in the upgrades and in some cases describes features that are no longer operable. This report attempts to bridge the information gap between the original manual and the current state of the software.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

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 OSTI2014

NSTX-U Control System Upgrades

The National Spherical Tokamak Experiment (NSTX) is undergoing a wealth of upgrades (NSTX-U). These upgrades, especially including an elongated pulse length, require broad changes to the control system that has served NSTX well. A new fiber serial Front Panel Data Port input and output (I/O) stream will supersede the aging copper parallel version. Driver support for the new I/O and cyber security concerns require updating the operating system from Redhat Enterprise Linux (RHEL) v4 to RedHawk (based on RHEL) v6. While the basic control system continues to use the General Atomics Plasma Control System (GA PCS), the effort to forward port the entire software package to run under 64-bit Linux instead of 32-bit Linux included PCS modifications subsequently shared with GA and other PCS users. Software updates focused on three key areas: (1) code modernization through coding standards (C99/C11), (2) code portability and maintainability through use of the GA PCS code generator, and (3) support of 64-bit platforms. Central to the control system upgrade is the use of a complete real time (RT) Linux platform provided by Concurrent Computer Corporation, consisting of a computer (iHawk), an operating system and drivers (RedHawk), and RT tools (NightStar). Strong vendor support coupled with an extensive RT toolset influenced this decision. The new real-time Linux platform, I/O, and software engineering will foster enhanced capability and performance for NSTX-U plasma control.

70 PLASMA PHYSICS AND FUSION TECHNOLOGY↗

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↗