Engineering Papers⌕ Search

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.

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

At least 19 records
All sourcesNASA NTRSDOE OSTI
DOE OSTI2025

ComPort: Rigorous Testing Methods to Safeguard Software Porting (Final UW Report)

This report summarizes the University of Washington’s contributions to the ComPort project, Rigorous Testing Methods to Safeguard Software Porting, funded under the U.S. Department of Energy, Office of Science, Office of Advanced Scientific Computing Research (ASCR), award number DE-SC0022081. UW’s work addressed numerics-driven correctness challenges arising in heterogeneous and rapidly evolving computing environments. Our efforts focused on developing interactive analysis tools, correctness-preserving rewriting systems, semantic-aware code-transformation infrastructure, and multi-language support for reproducible numerical experiments.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

ComPort: Rigorous Testing Methods to Safeguard Software Porting (Final Technical Report)

This is a technical report from the lead institution – University of Utah, Kahlert School of Computing – funded under the Department of Energy, Office of Science, Office of Advanced Scientific Computing Research under award number DE-SC0022252. We summarize our work done over the three years of funding received. The relevant papers and software have already been uploaded at the DOE site.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2001

PiVoT GPS Receiver

NASA Goddard Space Flight Center has built an open architecture, 24 channel spaceflight Global Positioning System (GPS) receiver. The compact PCI PiVoT GPS receiver card is based on the Mitel/GEC Plessey Builder 2 board. PiVoT uses two Plessey 2021 correlators to allow tracking of up to 24 separate GPS SV's on unique channels. Its four front ends can support four independent antennas, making it a useful card for hosting GPS attitude determination algorithms. It has been built using space quality, radiation tolerant parts. The PiVoT card works at a lower signal to noise ratio than the original Builder 2 board. It also hosts an improved clock oscillator. The PiVoT software is based on the original Piessey Builder 2 software ported to the Linux operating system. The software is posix compliant and can be easily converted to other posix operating systems. The software is open source to anyone with a licensing agreement with Plessey. Additional tasks can be added to the software to support GPS science experiments or attitude determination algorithms. The next generation PiVoT receiver will be a single radiation hardened compact PCI card containing the microprocessor and the GPS receiver optimized for use above the GPS constellation.

Wennersten, Miriam↗
NASA NTRS2001

PiVoT GPS Receiver

NASA Goddard Space Flight Center has built an open architecture, 24 channel space flight GPS receiver. The CompactPCI PiVoT GPS receiver card is based on the Mitel/GEC Plessey Builder-2 board. PiVoT uses two Plessey 2021 correlators to allow tracking of up to 24 separate GPS SV's on unique channels. Its four front ends can support four independent antennas, making it a useful card for hosting GPS attitude determination algorithms. It has been built using space quality, radiation tolerant parts. The PiVoT card will track a weaker signal than the original Builder 2 board. It also hosts an improved clock oscillator. The PiVoT software is based on the original Plessey Builder 2 software ported to the Linux operating system. The software is POSIX complaint and can easily be converted to other POSIX operating systems. The software is open source to anyone with a licensing agreement with Plessey. Additional tasks can be added to the software to support GPS science experiments or attitude determination algorithms. The next generation PiVoT receiver will be a single radiation hardened CompactPCI card containing the microprocessor and the GPS receiver optimized for use above the GPS constellation. PiVoT was flown successfully on a balloon in July, 2001, for its first non-simulated flight.

Wennersten, Miriam Dvorak↗
NASA NTRS1990

Attitude Determination and Control System (ADCS) and Maintenance and Diagnostic System (MDS): A maintenance and diagnostic system for Space Station Freedom

The Maintenance and Diagnostic System (MDS) that is being developed at Honeywell to enhance the Fault Detection Isolation and Recovery system (FDIR) for the Attitude Determination and Control System on Space Station Freedom is described. The MDS demonstrates ways that AI-based techniques can be used to improve the maintainability and safety of the Station by helping to resolve fault anomalies that cannot be fully determined by built-in-test, by providing predictive maintenance capabilities, and by providing expert maintenance assistance. The MDS will address the problems associated with reasoning about dynamic, continuous information versus only about static data, the concerns of porting software based on AI techniques to embedded targets, and the difficulties associated with real-time response. An initial prototype was built of the MDS. The prototype executes on Sun and IBM PS/2 hardware and is implemented in the Common Lisp; further work will evaluate its functionality and develop mechanisms to port the code to Ada.

Toms, David↗
DOE OSTI2021

Enhancements supporting IC usage of PEM libraries on next-gen platforms

This milestone reports on the culmination of several years of effort by multiple PEM support software development teams to provide capabilities for use in LLNL-developed integrated codes on next-gen ASC platforms, including GPU support. We will provide a survey of relevant Application Program Interfaces (API) that are required to support LLNL IC code capability on relevant architectures, with a focus on Sierra and El Capitan. We will identify and summarize all dependencies between PEM supported libraries and IC supported physics codes. We will provide an assessment of algorithmic improvements that have been deployed, as well as future developments that are required to complete the GPU porting efforts. This assessment will include a description of programming models adopted by each of the PEM projects, distinct algorithmic challenges for each of the capabilities, and information about sharing GPU memory between the APIs and host codes. We will develop targeted test problems to assess computational performance. Finally, this milestone will result in identification of gaps in our effort to assist the LLNL ASC program in prioritization of effort for porting software to El Capitan.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2006

PVM Enhancement for Beowulf Multiple-Processor Nodes

A recent version of the Parallel Virtual Machine (PVM) computer program has been enhanced to enable use of multiple processors in a single node of a Beowulf system (a cluster of personal computers that runs the Linux operating system). A previous version of PVM had been enhanced by addition of a software port, denoted BEOLIN, that enables the incorporation of a Beowulf system into a larger parallel processing system administered by PVM, as though the Beowulf system were a single computer in the larger system. BEOLIN spawns tasks on (that is, automatically assigns tasks to) individual nodes within the cluster. However, BEOLIN does not enable the use of multiple processors in a single node. The present enhancement adds support for a parameter in the PVM command line that enables the user to specify which Internet Protocol host address the code should use in communicating with other Beowulf nodes. This enhancement also provides for the case in which each node in a Beowulf system contains multiple processors. In this case, by making multiple references to a single node, the user can cause the software to spawn multiple tasks on the multiple processors in that node.

Springer, Paul↗
DOE OSTI2022

SPEL: Software tool for Porting E3SM Land Model with OpenACC in a Function Unit Test Framework

Most high-end computers adopt hybrid architecture, porting a large-scale scientific code onto accelerators is necessary. The paper presents a generic method for porting large-scale scientific code onto accelerators using compiler directives within a modularized function unit test platform. We have implemented the method and designed a software tool (SPEL) to port the E3SM Land Model (ELM) onto the GPUs in the Summit computer. SPEL automatically generates GPU-ready test modules for all ELM functions, such as CanopyFlux, SoilTemperature, and EcosystemDynamics. SPEL breaks the ELM into a collection of standalone unit test programs for easy code verification and further performance improvement. We further optimize several ELM test modules with advanced techniques, including memory reduction, reconstructed parallel loops, and asynchronous GPU kernel launch. We hope our study will inspire new toolkit developments that expedite large-scale scientific code porting with compiler directives.

Schwartz, Peter↗
DOE OSTI2021

Port and optimize the CEED software stack to Aurora/Frontier EA (ECP Milestone Report)

The goal of this milestone was to port the CEED software stack, including Nek, MFEM and libCEED to the Frontier and Aurora early access hardware, work on optimizing the performance on AMD and Intel GPUs, and demonstrate impact in CEED-enabled ECP applications. As part of this milestone, we also performed a number of other activities, including continued optimizations for CEED applications at scale on Summit, performance evaluation on non-ECP hardware, including the Fugaku’s A64FX chip and the NVIDIA A100 GPU architecture, exploring the use of just-in-time compilations in applications at scale and potential of mixed precision optimizations in the CEED discretization and solver algorithms, and more. During the milestone period, the CEED team released new versions of 6 of its packages, including major releases of MFEM, NekRS and OCCA. We also organized the fifth CEED Annual meeting (CEED5AM) which included nearly 100 researchers from national labs, universities and industry.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1993

Clementine Sensor Processing System

The design of the DSPSE Satellite Controller (DSC) is baselined as a single-string satellite controller. The DSC performs two main functions: health and maintenance of the spacecraft; and image capture, storage, and playback. The DSC contains two processors: a radiation-hardened Mil-Std-1750, and a commercial R3000. The Mil-Std-1750 processor performs all housekeeping operations, while the R3000 is mainly used to perform the image processing functions associated with the navigation functions, as well as performing various experiments. The DSC also contains a data handling unit (DHU) used to interface to various spacecraft imaging sensors and to capture, compress, and store selected images onto the solid-state data recorder. The development of the DSC evolved from several key requirements; the DSPSE satellite was to do the following: (1) have a radiation-hardened spacecraft control system and be immune to single-event upsets (SEU's); (2) use an R3000-based processor to run the star tracker software that was developed by SDIO (due to schedule and cost constraints, there was no time to port the software to a radiation-hardened processor); and (3) fly a commercial processor to verify its suitability for use in a space environment. In order to enhance the DSC reliability, the system was designed with multiple processing paths. These multiple processing paths provide for greater tolerance to various component failures. The DSC was designed so that all housekeeping processing functions are performed by either the Mil-Std-1750 processor or the R3000 processor. The image capture and storage is performed either by the DHU or the R3000 processor.

Feldstein, A. A.↗
NASA NTRS1992

EOS workstation

This final report summarizes the work done from mid-1989 until January 1992 to develop a prototype set of tools for the analysis of EOS-type images. Such images are characterized by great multiplicity and quantity. A single 'snapshot' of EOS-type imagery may contain several hundred component images so that on a particular pixel, one finds multiple gray values. A prototype EOS-sensor, AVIRIS, has 224 gray values at each pixel. The work focused on the ability to utilize very large images and continuously roam through those images, zoom and be able to hold more than one black and white or color image, for example for stereo viewing or for image comparisons. A second focus was the utilization of so-called 'image cubes', where multiple images need to be co-registered and then jointly analyzed, viewed, and manipulated. The target computer platform that was selected was a high-performance graphics superworkstation, Stardent 3000. This particular platform offered many particular graphics tools such as the Application Visualization System (AVS) or Dore, but it missed availability of commercial third-party software for relational data bases, image processing, etc. The project was able to cope with these limitations and a phase-3 activity is currently being negotiated to port the software and enhance it for use with a novel graphics superworkstation to be introduced into the market in the Spring of 1993.

Leberl, Franz↗
NASA NTRS1991

Mark 4A antenna control system data handling architecture study

A high-level review was conducted to provide an analysis of the existing architecture used to handle data and implement control algorithms for NASA's Deep Space Network (DSN) antennas and to make system-level recommendations for improving this architecture so that the DSN antennas can support the ever-tightening requirements of the next decade and beyond. It was found that the existing system is seriously overloaded, with processor utilization approaching 100 percent. A number of factors contribute to this overloading, including dated hardware, inefficient software, and a message-passing strategy that depends on serial connections between machines. At the same time, the system has shortcomings and idiosyncrasies that require extensive human intervention. A custom operating system kernel and an obscure programming language exacerbate the problems and should be modernized. A new architecture is presented that addresses these and other issues. Key features of the new architecture include a simplified message passing hierarchy that utilizes a high-speed local area network, redesign of particular processing function algorithms, consolidation of functions, and implementation of the architecture in modern hardware and software using mainstream computer languages and operating systems. The system would also allow incremental hardware improvements as better and faster hardware for such systems becomes available, and costs could potentially be low enough that redundancy would be provided economically. Such a system could support DSN requirements for the foreseeable future, though thorough consideration must be given to hard computational requirements, porting existing software functionality to the new system, and issues of fault tolerance and recovery.

Briggs, H. C.↗
DOE OSTI2023

Hydroscanner: Instrumentation for Water Ingress Imaging in Photovoltaic Module Packaging Materials

A new iteration of the Hydroscanner prototype was designed and built during the execution of the contract. Compared to the previous designs, the communication port was changed from ethernet to USB C, since it provides a more seamless integration as a peripheral unit. An additional advantage is that one single port can be used for both communication and power up of the infrared camera. Although the power requirements are higher than the typical amount provided by a laptop computer, the camera can be run as a peripheral from a docking station when connected to a thunderbolt charging port. The software interface was modified to accommodate two imaging modes, an 8-bit and 14-bit image display. The 8-bit images use a custom colorization scheme that divides all pixels in the image into bins of equal width, such that images containing a wide range of brightness display the intermediate pixel intensities in greyscale values that enhance the contrast. The 14-bit images provide the direct readout from the focal plane array of the camera and can be saved as a text file for later processing in other software packages (MATLAB, Python).

47 OTHER INSTRUMENTATION↗
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.↗