Search NASA⌕ Search

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.

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 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 OSTI2016

Early Experiences Porting the NAMD and VMD Molecular Simulation and Analysis Software to GPU-Accelerated OpenPOWER Platforms, In: ISC High Performance 2016: High Performance Computing

All-atom molecular dynamics simulations of biomolecules provide a powerful tool for exploring the structure and dynamics of large protein complexes within realistic cellular environments. Unfortunately, such simulations are extremely demanding in terms of their computational requirements, and they present many challenges in terms of preparation, simulation methodology, and analysis and visualization of results. We describe our early experiences porting the popular molecular dynamics simulation program NAMD and the simulation preparation, analysis, and visualization tool VMD to GPU-accelerated OpenPOWER hardware platforms. We report our experiences with compiler-provided autovectorization and compare with hand-coded vector intrinsics for the POWER8 CPU. We explore the performance benefits obtained from unique POWER8 architectural features such as 8-way SMT and its value for particular molecular modeling tasks. Finally, we evaluate the performance of several GPU-accelerated molecular modeling kernels and relate them to other hardware platforms.

Computer Science↗
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↗
NASA NTRS2016

Staffing Strategies for Maintenance of Critical Software Systems at the Jet Propulsion Laboratory

The Mission Design and Navigation Software Group at the Jet Propulsion Laboratory (JPL) maintains mission critical software systems. We have good empirical data and models for maintenance demand—when defects will occur, how many and how severe they will be, and how much effort is needed to address them. However, determining the level of staffing needed to address maintenance issues is an ongoing challenge and is often done ad-hoc. There are two common strategies are (1) reactive – add/remove staff as needed to respond to maintenance issues, and (2) capacitive – retain a given staff size to address issues as they occur, proactively address issues and prevent defects.

software maintenance↗
DOE OSTI2016

Safeguards Technology Factsheet - Unattended Dual Current Monitor (UDCM)

The UDCM is a low-current measurement device designed to record sub-nano-amp to micro-amp currents from radiation detectors. The UDCM is a two-channel device that incorporates a Commercial-Off-The-Shelf (COTS) processor enabling both serial over USB as well as Ethernet communications. The instrument includes microSD and USB flash memory for data storage as well as a programmable High Voltage (HV) power supply for detector bias. The UDCM is packaged in the same enclosure, employs the same processor and has a similar user interface as the UMSR. A serial over USB communication line to the UDCM allows the use of existing versions of MIC software, while the Ethernet port is compatible with the new IAEA RAINSTORM communication protocol.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗
DOE OSTI2018

Video Compression Routines Final Report CRADA No. TSB-1183-95

The purpose of this CRADA was to establish a framework for LLNL and NOVA Management, Inc. to Cooperatively develop video compression routines to be used to condense maintenance documentation provided on computers issued to Army mechanics to help them diagnose and repair equipment faults. In the past, paper technical manuals were the only means of communicating fault isolation, diagnostics and repair action information to maintenance personnel. The need for this information was at the weapon system itself as well as at the maintenance depot. This project addressed the need for means of efficient storage and retrieval of video (bandwidth issue) by maintenance personnel as they moved through the diagnostic procedures. Several research and development projects have employed interactive stored video as a means of providing maintenance information to the soldier. The problem with this approach was the massive data storage requirement. The overall objective of the project was to develop fast decompression and playback routines for full motion, coIor video. A survey was done of existing standards and potential new routines and techniques for video compression and playback to determine which were suitable for use on the CTS. Playback speeds were preferred to beat 30 frames per second on the target architecture. Compression ratios were expected to store several minutes of synchronized video in 1 MB. Playback routines were Windows 3.1 compatible. Identification of any hardware upgrades associated with playback were made when necessary. A demonstration of existing LLNL algorithms for still frame decompression which represented a current benchmark of data compression performance was completed. NOVA Management and LLNL used some of the compression technologies developed or currently being developed at LLNL to address the requirements of this SBIR. LLNL started by evaluating current compression technologies or combinations thereof to estimate the best compression ratio LLNL could achieve at this stage. LLNL ported some of our software from the SUN workstation environment to the PC or equivalent environment (e.g., MAC) so as to closely match the computer environment suggested by the Army. Finally, LLNL designed and outlined new algorithms to meet the desired video compression of CTS.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

pvplr-python: Python package implementation of PVplr for Performance Loss Rate (PLR) analysis

Due to software fragmentation, PV system modeling teams can be limited to language specific packages, preventing cross-sectional analysis of different modeling techniques and workflows. To this end, PVplr, a popular PV performance modeling R software package, has been ported to the Python programming language. To verify and test the robustness of the port, NSRDB data has been used to simulated PV installations at native resolution (~2 million Sites), with a variety of degradation rates, degradation patterns, and modules. Performance Ratios were calculated using the ported functions from pvplr-python and compared against Rdtools YoY values. Due to the complicated nature of degradation, a new metric has been proposed to quantify the performance loss of a system. The cumulative production loss, is the total amount of energy lost due to the degrading performance of the system. Cumulative production loss alleviates the problems with fitting linear functions to non-linear degradation. Cumulative Production loss was shown to better estimate the total lost revenue for non-linear degradation patterns. $XbX + UTC$ was found to most accurately predict the total lost revenue in simulated systems.

Kumar, Suraj↗
NASA NTRS2012

Plug-in Plan Tool v3.0.3.1

The role of PLUTO (Plug-in Port UTilization Officer) and the growth of the International Space Station (ISS) have exceeded the capabilities of the current tool PiP (Plug-in Plan). Its users (crew and flight controllers) have expressed an interest in a new, easy-to-use tool with a higher level of interactivity and functionality that is not bound by the limitations of Excel. The PiP Tool assists crewmembers and ground controllers in making real-time decisions concerning the safety and compatibility of hardware plugged into the UOPs (Utility Outlet Panels) onboard the ISS. The PiP Tool also provides a reference to the current configuration of the hardware plugged in to the UOPs, and enables the PLUTO and crew to test Plug-in locations for constraint violations (such as cable connector mismatches or amp limit violations), to see the amps and volts for an end item, to see whether or not the end item uses 1553 data, and the cable length between the outlet and the end item. As new equipment is flown or returned, the database can be updated appropriately as needed. The current tool is a macroheavy Excel spreadsheet with its own database and reporting functionality. The new tool captures the capabilities of the original tool, ports them to new software, defines a new dataset, and compensates for ever-growing unique constraints associated with the Plug-in Plan. New constraints were designed into the tool, and updates to existing constraints were added to provide more flexibility and customizability. In addition, there is an option to associate a "Flag" with each device that will let the user know there is a unique constraint associated with it when they use it. This helps improve the safety and efficiency of real-time calls by limiting the amount of "corporate knowledge" overhead that has to be trained and learned through use. The tool helps save time by automating previous manual processes, such as calculating connector types and deciding which cables are required and in what order.

Andrea-Liner, Kathleen E.↗
DOE OSTI2017

Unattended Multiplicity Shift Register

The Unattended Multiplicity Shift Register (UMSR) is a specialized pulse counter used primarily to count neutron events originating in neutron detection instruments. While the counter can be used to count any TTL input pulses, its unique ability to record time correlated events and the multiplicity distributions of these events makes it an ideal instrument for counting neutron events in the nuclear fields of material safeguards, waste assay and process monitoring and control. The UMSR combines the Los Alamos National Laboratory (LANL) simple and robust shift register design with a Commercial-Off-The-Shelf (COTS) processor and Ethernet communications. The UMSR is fully compatible with existing International Atomic Energy Agency (IAEA) neutron data acquisition instruments such as the Advance Multiplicity Shift Register (AMSR) and JSR-15. The UMSR has three input channels: a multiplicity shift register input and two auxiliary inputs. The UMSR provides 0V to 2kV of programmable High Voltage (HV) bias and both a 12V and a 5V detector power supply output. A serial over USB communication line to the UMSR allows the use of existing versions of INCC or MIC software while the Ethernet port is compatible with the new IAEA RAINSTORM communication protocol.

Newell, Matt↗
NASA NTRS1990

A study of the portability of an Ada system in the software engineering laboratory (SEL)

A particular porting effort is discussed, and various statistics on analyzing the portability of Ada and the total staff months (overall and by phase) required to accomplish the rehost, are given. This effort is compared to past experiments on the rehosting of FORTRAN systems. The discussion includes an analysis of the types of errors encountered during the rehosting, the changes required to rehost the system, experiences with the Alsys IBM Ada compiler, the impediments encountered, and the lessons learned during this study.

Jun, Linda O.↗
DOE OSTI2024

The ATLAS experiment software on ARM

With an increased dataset obtained during the Run 3 of the LHC at CERN and the even larger expected increase of the dataset by more than one order of magnitude for the HL-LHC, the ATLAS experiment is reaching the limits of the current data processing model in terms of traditional CPU resources based on x86_64 architectures and an extensive program for software upgrades towards the HL-LHC has been set up. The ARM architecture is becoming a competitive and energy efficient alternative. Some surveys indicate its increased presence in HPCs and commercial clouds, and some WLCG sites have expressed their interest. Chip makers are also developing their next generation solutions on ARM architectures, sometimes combining ARM and GPU processors in the same chip. Consequently it is important that the ATLAS software embraces the change and is able to successfully exploit this architecture. We report on the successful porting to ARM of the Athena software framework, which is used by ATLAS for both online and offline computing operations. Furthermore we report on the successful validation of simulation workflows running on ARM resources. For this we have set up an ATLAS Grid site using ARM compatible middleware and containers on Amazon Web Services (AWS) ARM resources. The ARM version of Athena is fully integrated in the regular software build system and distributed in the same way as other software releases. In addition, the workflows have been integrated into the HEPscore benchmark suite which is the planned WLCG wide replacement of the HepSpec06 benchmark used for Grid site pledges. In the overall porting process we have used resources on AWS, Google Cloud Platform (GCP) and CERN. A performance comparison of different architectures and resources will be discussed.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗
DOE OSTI2022

Porting a fast-running wildfire plume model for use in national security and climate applications

In this project, the code for the fast-running Freitas wildfire plume model was successfully ported into the NARAC system, creating an operations-ready capability for predicting the transport of hazardous smoke from large wildfires. “Porting” refers to copying a section of code from one software package to another while accounting for unique dependencies in each software package. In this case, the code was ported from the Weather Research and Forecasting (WRF) Model, which is used extensively by the project team. To verify correct implementation, model results from the updated NARAC system were compared to those from WRF and the High-Resolution Rapid Refresh (HRRR) forecast model, which also employs the Freitas scheme. The NARAC User Interface (UI) and code documentation were also updated to include the new wildfire plume option, and a wildfire case was added to the NARAC test suite. The code was used in a real-time, semi-operational setup to predict smoke transport during the Cerro Pelado fire near Los Alamos National Laboratory in May 2022. The Freitas plume model was also tested for LLNL climate applications. Although the code was not ported into the Energy Exascale Earth System Model (E3SM), it was tested offline using E3SM atmospheric inputs, and results were compared to existing high-resolution plume predictions from large-eddy simulations in WRF. The code implementation and testing completed during this project will enable future work predicting smoke transport from large wildfires in LLNL national security and climate mission spaces.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS2006

CCSDS Time-Critical Onboard Networking Service

The Consultative Committee for Space Data Systems (CCSDS) is developing recommendations for communication services onboard spacecraft. Today many different communication buses are used on spacecraft requiring software with the same basic functionality to be rewritten for each type of bus. This impacts on the application software resulting in custom software for almost every new mission. The Spacecraft Onboard Interface Services (SOIS) working group aims to provide a consistent interface to various onboard buses and sub-networks, enabling a common interface to the application software. The eventual goal is reusable software that can be easily ported to new missions and run on a range of onboard buses without substantial modification. The system engineer will then be able to select a bus based on its performance, power, etc and be confident that a particular choice of bus will not place excessive demands on software development. This paper describes the SOIS Intra-Networking Service which is designed to enable data transfer and multiplexing of a variety of internetworking protocols with a range of quality of service support, over underlying heterogeneous data links. The Intra-network service interface provides users with a common Quality of Service interface when transporting data across a variety of underlying data links. Supported Quality of Service (QoS) elements include: Priority, Resource Reservation and Retry/Redundancy. These three QoS elements combine and map into four TCONS services for onboard data communications: Best Effort, Assured, Reserved, and Guaranteed. Data to be transported is passed to the Intra-network service with a requested QoS. The requested QoS includes the type of service, priority and where appropriate, a channel identifier. The data is de-multiplexed, prioritized, and the required resources for transport are allocated. The data is then passed to the appropriate data link for transfer across the bus. The SOIS supported data links may inherently provide the quality of service support requested by the intra-network layer. In the case where the data link does not have the required level of support, the missing functionality is added by SOIS. As a result of this architecture, re-usable software applications can be designed and used across missions thereby promoting common mission operations. In addition, the protocol multiplexing function enables the blending of multiple onboard networks. This paper starts by giving an overview of the SOIS architecture in section 11, illustrating where the TCONS services fit into the overall architecture. It then describes the quality of service approach adopted, in section III. The prototyping efforts that have been going on are introduced in section JY. Finally, in section V the current status of the CCSDS recommendations is summarized.

Parkes, Steve↗
NASA NTRS2013

Towards Efficient Scientific Data Management Using Cloud Storage

A software prototype allows users to backup and restore data to/from both public and private cloud storage such as Amazon's S3 and NASA's Nebula. Unlike other off-the-shelf tools, this software ensures user data security in the cloud (through encryption), and minimizes users operating costs by using space- and bandwidth-efficient compression and incremental backup. Parallel data processing utilities have also been developed by using massively scalable cloud computing in conjunction with cloud storage. One of the innovations in this software is using modified open source components to work with a private cloud like NASA Nebula. Another innovation is porting the complex backup to- cloud software to embedded Linux, running on the home networking devices, in order to benefit more users.

He, Qiming↗