Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “User Interface Design”

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 1,459 records · Page 81
All sourcesNASA NTRSDOE OSTI
NASA NTRS1994

General purpose architecture for intelligent computer-aided training

An intelligent computer-aided training system having a general modular architecture is provided for use in a wide variety of training tasks and environments. It is comprised of a user interface which permits the trainee to access the same information available in the task environment and serves as a means for the trainee to assert actions to the system; a domain expert which is sufficiently intelligent to use the same information available to the trainee and carry out the task assigned to the trainee; a training session manager for examining the assertions made by the domain expert and by the trainee for evaluating such trainee assertions and providing guidance to the trainee which are appropriate to his acquired skill level; a trainee model which contains a history of the trainee interactions with the system together with summary evaluative data; an intelligent training scenario generator for designing increasingly complex training exercises based on the current skill level contained in the trainee model and on any weaknesses or deficiencies that the trainee has exhibited in previous interactions; and a blackboard that provides a common fact base for communication between the other components of the system. Preferably, the domain expert contains a list of 'mal-rules' which typifies errors that are usually made by novice trainees. Also preferably, the training session manager comprises an intelligent error detection means and an intelligent error handling means. The present invention utilizes a rule-based language having a control structure whereby a specific message passing protocol is utilized with respect to tasks which are procedural or step-by-step in structure. The rules can be activated by the trainee in any order to reach the solution by any valid or correct path.

Loftin, R. Bowen↗
NASA NTRS2008

Development of an Inline Urine Monitoring System for the International Space Station

Human exposure to microgravity during spaceflight causes bone loss. Calcium and other metabolic byproducts are excreted in urine voids. Frequent and accurate measurement of urine void volume and constituents is essential to determining crew bone loss and the effectiveness of countermeasures. Previous US Space Shuttle (SS) Urine Monitoring System (UMS) technology was unable to accurately measure urine void volumes due to cross contamination between users and fluid system instabilities. Currently, urine voids must be collected manually in a flexible plastic bag containing a known tracer quantity. The crew member must completely mix the bag then withdraw a representative syringe sample for later ground analysis. The current bag system accuracy is highly dependent on mixing technique. The International Space Station (ISS) UMS has been developed as an automated device that collects urine from the Waste and Hygiene Compartment (WHC) urinal funnel interface, separates the urine, measures the void volume, and allows for syringe sampling. After operations, the ISS UMS delivers the urine to the WHC for normal processing then flushes its plumbing with a small water volume. The current ISS UMS design incorporates an innovative rotary separator that minimizes foaming, greatly reduces cross contamination between urine voids (< 0.5 ml urine), and provides accurate volume measurements (< +/- 2% error for 100 to 1000 ml void volumes). The system performance has been validated with extensive ground tests and reduced gravity aircraft flights. The lockersized ISS UMS is currently being modified to interface with the ISS Node 3 WHC Russian ACY hardware. The operation principles, characteristics, and results are outlined in the paper.

Broyan, James Lee, Jr.↗
NASA NTRS1993

Vibration Pattern Imager (VPI): A control and data acquisition system for scanning laser vibrometers

The Vibration Pattern Imager (VPI) system was designed to control and acquire data from scanning laser vibrometer sensors. The PC computer based system uses a digital signal processing (DSP) board and an analog I/O board to control the sensor and to process the data. The VPI system was originally developed for use with the Ometron VPI Sensor, but can be readily adapted to any commercially available sensor which provides an analog output signal and requires analog inputs for control of mirror positioning. The sensor itself is not part of the VPI system. A graphical interface program, which runs on a PC under the MS-DOS operating system, functions in an interactive mode and communicates with the DSP and I/O boards in a user-friendly fashion through the aid of pop-up menus. Two types of data may be acquired with the VPI system: single point or 'full field.' In the single point mode, time series data is sampled by the A/D converter on the I/O board (at a user-defined sampling rate for a selectable number of samples) and is stored by the PC. The position of the measuring point (adjusted by mirrors in the sensor) is controlled via a mouse input. The mouse input is translated to output voltages by the D/A converter on the I/O board to control the mirror servos. In the 'full field' mode, the measurement point is moved over a user-selectable rectangular area. The time series data is sampled by the A/D converter on the I/O board (at a user-defined sampling rate for a selectable number of samples) and converted to a root-mean-square (rms) value by the DSP board. The rms 'full field' velocity distribution is then uploaded for display and storage on the PC.

Rizzi, Stephen A.↗
NASA NTRS2019

The Weather Analysis Display (WAND) Tool: Developing a Meteorological Data Display Tool for Situational Awareness During Day-Of-Launch of Space Launch Vehicles Using Python

Atmospheric conditions are an important driver in the design and operation of space launch vehicles. The Profile Envision and Splicing Tool (PRESTO) was developed by NASA’s Marshall Space Flight Center (MSFC) Natural Environments Branch (NE) to generate vertically complete atmospheric profiles from various data sources at NASA’s Kennedy Space Center (KSC), co-located on the United States Air Force (USAF) Eastern Range (ER), for NASA’s Space Launch System (SLS) day-of-launch (DOL) loads and trajectory analysis. PRESTO was designed solely to generate a vertically complete atmospheric profile (Orcutt et al., 2017). However, NE has also been tasked to provide a quality assessment of meteorological data examined on DOL, which goes beyond PRESTO’s utility. Thus, NE developed the Weather Analysis Display (WAND) to visualize data from all available observation systems in conjunction with climatological databases. WAND can display data from various sources in multiple ways, including Skew-T Log-P plots, time-height cross sections, and time series. WAND was developed in Python 3 taking advantage of common packages, such as NumPy for data handling, SciPy for mathematical functions, Matplotlib for data visualization, and Tkinter for the execution of the Graphical User Interface (GUI).

Orcutt, John M.↗
NASA NTRS1994

The Buffer Diagnostic Prototype: A fault isolation application using CLIPS

This paper describes problem domain characteristics and development experiences from using CLIPS 6.0 in a proof-of-concept troubleshooting application called the Buffer Diagnostic Prototype. The problem domain is a large digital communications subsystems called the real-time network (RTN), which was designed to upgrade the launch processing system used for shuttle support at KSC. The RTN enables up to 255 computers to share 50,000 data points with millisecond response times. The RTN's extensive built-in test capability but lack of any automatic fault isolation capability presents a unique opportunity for a diagnostic expert system application. The Buffer Diagnostic Prototype addresses RTN diagnosis with a multiple strategy approach. A novel technique called 'faulty causality' employs inexact qualitative models to process test results. Experimental knowledge provides a capability to recognize symptom-fault associations. The implementation utilizes rule-based and procedural programming techniques, including a goal-directed control structure and simple text-based generic user interface that may be reusable for other rapid prototyping applications. Although limited in scope, this project demonstrates a diagnostic approach that may be adapted to troubleshoot a broad range of equipment.

Porter, Ken↗
NASA NTRSDate not supplied

Usability Evaluation of Fleet Management Interface for High Density Vertiplex Environments

To meet the rising demand for an Advanced Air Mobility (AAM) (i.e. urban and rural unmanned aircraft systems) ecosystem, the NASA Aeronautics Research Mission Directorate (ARMD) is hosting a series of simulations and flight tests under the High Density Vertiplex sub-project (HDV) to prototype and study the effectiveness AAM capabilities under various operational contexts. HDV aims to develop an integrated automation architecture to support terminal area flight operations. The HDV simulations and flight tests address safety, integration, and operational challenges, while integrated systems and software demonstrate design readiness, robustness, and interoperability. During the initial HDV simulation in 2021, a prototype traffic management tool developed by NASA called the Fleet Management Interface (FMI) was tested. FMI was designed to introduce an advanced level of human-automation interaction to aid both Ground Control Station Operators (GCSOs) and Fleet Managers (FMs) in remotely managing flights under their ownership. In a human-in-the-loop simulation, a usability study was conducted with the FMI to identify optimal approaches for displaying information to human operators using subjective measures of usability, workload, situation awareness, risk, and trust, along with qualitative feedback. This study consisted of task analysis in which GCSO and FM subjects used an Urban Air Mobility (UAM) environment to develop and execute a plan for two different traffic scenarios of remotely controlled vehicles. In each scenario, a remotely controlled vehicle completed a takeoff, active flight, and landing sequence while simulated traffic flew in the background at a rate of 20 operations per hour. In the first scenario, the controlled vehicle flew a nominal route with takeoff and landing at the same vertiport. In the second scenario, the controlled vehicle started on the nominal route, then diverted to an unplanned location mid-flight. Results showed that self- reported performance, usability, trust, and situation awareness ratings of FMI were moderately to strongly high. There were small differences between scenarios, with Scenario 2 being perceived as more unstable, complex, variable, risky, and potentially harmful than Scenario 1. Furthermore, participants described improvements that could be made to create a better user experience. For example, users suggested customizable interfaces to accommodate information display preferences, and the ability to review routes before assigning them. The results from this study will inform future development of the FMI with the end goal of creating a reference automation tool for airspace management procedures in AAM. The FMI could serve to reduce dependency on traditional air navigation services through increased automation in high density vertiplex environments.

Fleet manager↗
NASA NTRS1982

XSECT: A computer code for generating fuselage cross sections - user's manual

A computer code, XSECT, has been developed to generate fuselage cross sections from a given area distribution and wing definition. The cross sections are generated to match the wing definition while conforming to the area requirement. An iterative procedure is used to generate each cross section. Fuselage area balancing may be included in this procedure if desired. The code is intended as an aid for engineers who must first design a wing under certain aerodynamic constraints and then design a fuselage for the wing such that the contraints remain satisfied. This report contains the information necessary for accessing and executing the code, which is written in FORTRAN to execute on the Cyber 170 series computers (NOS operating system) and produces graphical output for a Tektronix 4014 CRT. The LRC graphics software is used in combination with the interface between this software and the PLOT 10 software.

Ames, K. R.↗
NASA NTRSDate not supplied

Usability Evaluation of Fleet Management Interface for High Density Vertiplex Environments

To meet the rising demand for an Advanced Air Mobility (i.e. urban and rural unmanned aircraft systems) ecosystem, NASA Aeronautics Research Mission Directorate (ARMD) is hosting a series of simulations and flight tests under the High Density Vertiplex sub-project (HDV). HDV aims to develop an integrated automation architecture to support terminal area flight operations. The HDV simulations and flight tests address safety, integration, and operational challenges, while integrated systems and software demonstrate design readiness, robustness, and interoperability. During the initial HDV simulation in 2021, a prototype traffic management tool developed by NASA called Fleet Management Interface (FMI) was tested. FMI was designed to introduce an advanced level of human-automation interaction to aid both Ground Control Station Operators (GCSOs) and Fleet Managers (FMs) in remotely managing flights under their ownership. In a human-in-the-loop simulation, a usability study was conducted with FMI to identify optimal approaches for displaying information for human operators using subjective measures of usability, workload, situation awareness, risk, and trust, along with qualitative feedback. This study consisted of task analysis in which GCSO and FM subjects used an Urban Air Mobility (UAM) environment to develop and execute a plan for two different traffic scenarios of remotely controlled vehicles. In each scenario, a controlled vehicle completed a takeoff, active flight, and landing sequence while automated traffic flew in the background at a rate of 20 operations per hour. In the first scenario, the controlled vehicle flew a nominal route with takeoff and landing at the same vertiport. In the second scenario, the controlled vehicle started on the nominal route, then diverted to an unplanned location mid-flight. Results showed that self-reported performance, usability, trust, and situation awareness ratings of FMI were moderately to strongly high. There were small differences between scenarios, with Scenario 2 being perceived as more unstable, complex, variable, risky, and potentially harmful than Scenario 1. Furthermore, participants described improvements that could be made to create a better user experience. For example, users would like greater configurability of the interface based on their personal information requirements, and they would like the opportunity to review routes before assigning them. The results from this study will inform future development of the FMI with the end goal of creating a reference automation tool for airspace management procedures in AAM. The FMI could be introduced as a potential way to reduce dependency on traditional air navigation services through increased automation in high density vertiplex environments.

vertiplex↗
NASA NTRS1993

ASTEC and MODEL: Controls software development at Goddard Space Flight Center

The ASTEC (Analysis and Simulation Tools for Engineering Controls) software is under development at the Goddard Space Flight Center (GSFC). The design goal is to provide a wide selection of controls analysis tools at the personal computer level, as well as the capability to upload compute-intensive jobs to a mainframe or supercomputer. In the last three years the ASTEC (Analysis and Simulation Tools for Engineering Controls) software has been under development. ASTEC is meant to be an integrated collection of controls analysis tools for use at the desktop level. MODEL (Multi-Optimal Differential Equation Language) is a translator that converts programs written in the MODEL language to FORTRAN. An upgraded version of the MODEL program will be merged into ASTEC. MODEL has not been modified since 1981 and has not kept with changes in computers or user interface techniques. This paper describes the changes made to MODEL in order to make it useful in the 90's and how it relates to ASTEC.

Downing, John P.↗
NASA NTRS2007

Solving Equations of Multibody Dynamics

Darts++ is a computer program for solving the equations of motion of a multibody system or of a multibody model of a dynamic system. It is intended especially for use in dynamical simulations performed in designing and analyzing, and developing software for the control of, complex mechanical systems. Darts++ is based on the Spatial-Operator- Algebra formulation for multibody dynamics. This software reads a description of a multibody system from a model data file, then constructs and implements an efficient algorithm that solves the dynamical equations of the system. The efficiency and, hence, the computational speed is sufficient to make Darts++ suitable for use in realtime closed-loop simulations. Darts++ features an object-oriented software architecture that enables reconfiguration of system topology at run time; in contrast, in related prior software, system topology is fixed during initialization. Darts++ provides an interface to scripting languages, including Tcl and Python, that enable the user to configure and interact with simulation objects at run time.

Jain, Abhinandan↗
NASA NTRS2007

Collaborative Resource Allocation

Collaborative Resource Allocation Networking Environment (CRANE) Version 0.5 is a prototype created to prove the newest concept of using a distributed environment to schedule Deep Space Network (DSN) antenna times in a collaborative fashion. This program is for all space-flight and terrestrial science project users and DSN schedulers to perform scheduling activities and conflict resolution, both synchronously and asynchronously. Project schedulers can, for the first time, participate directly in scheduling their tracking times into the official DSN schedule, and negotiate directly with other projects in an integrated scheduling system. A master schedule covers long-range, mid-range, near-real-time, and real-time scheduling time frames all in one, rather than the current method of separate functions that are supported by different processes and tools. CRANE also provides private workspaces (both dynamic and static), data sharing, scenario management, user control, rapid messaging (based on Java Message Service), data/time synchronization, workflow management, notification (including emails), conflict checking, and a linkage to a schedule generation engine. The data structure with corresponding database design combines object trees with multiple associated mortal instances and relational database to provide unprecedented traceability and simplify the existing DSN XML schedule representation. These technologies are used to provide traceability, schedule negotiation, conflict resolution, and load forecasting from real-time operations to long-range loading analysis up to 20 years in the future. CRANE includes a database, a stored procedure layer, an agent-based middle tier, a Web service wrapper, a Windows Integrated Analysis Environment (IAE), a Java application, and a Web page interface.

Wang, Yeou-Fang↗
NASA NTRS1990

The NASA, Marshall Space Flight Center drop tube user's manual

A comprehensive description of the structural and instrumentation hardware and the experimental capabilities of the 105-meter Marshall Space Flight Center Drop Tube Facility is given. This document is to serve as a guide to the investigator who wishes to perform materials processing experiments in the Drop Tube. Particular attention is given to the Tube's hardware to which an investigator must interface to perform experiments. This hardware consists of the permanent structural hardware (with such items as vacuum flanges), and the experimental hardware (with the furnaces and the sample insertion devices). Two furnaces, an electron-beam and an electromagnetic levitator, are currently used to melt metallic samples in a process environment that can range from 10(exp -6) Torr to 1 atmosphere. Details of these furnaces, the processing environment gases/vacuum, the electrical power, and data acquisition capabilities are specified to allow an investigator to design his/her experiment to maximize successful results and to reduce experimental setup time on the Tube. Various devices used to catch samples while inflicting minimum damage and to enhance turnaround time between experiments are described. Enough information is provided to allow an investigator who wishes to build his/her own furnace or sample catch devices to easily interface it to the Tube. The experimental instrumentation and data acquisition systems used to perform pre-drop and in-flight measurements of the melting and solidification process are also detailed. Typical experimental results are presented as an indicator of the type of data that is provided by the Drop Tube Facility. A summary bibliography of past Drop Tube experiments is provided, and an appendix explaining the noncontact temperature determination of free-falling drops is provided. This document is to be revised occasionally as improvements to the Facility are made and as the summary bibliography grows.

Rathz, Thomas J.↗
NASA NTRS1990

Executing CLIPS expert systems in a distributed environment

This paper describes a framework for running cooperating agents in a distributed environment to support the Intelligent Computer Aided Design System (ICADS), a project in progress at the CAD Research Unit of the Design Institute at the California Polytechnic State University. Currently, the systems aids an architectural designer in creating a floor plan that satisfies some general architectural constraints and project specific requirements. At the core of ICADS is the Blackboard Control System. Connected to the blackboard are any number of domain experts called Intelligent Design Tools (IDT). The Blackboard Control System monitors the evolving design as it is being drawn and helps resolve conflicts from the domain experts. The user serves as a partner in this system by manipulating the floor plan in the CAD system and validating recommendations made by the domain experts. The primary components of the Blackboard Control System are two expert systems executed by a modified CLIPS shell. The first is the Message Handler. The second is the Conflict Resolver. The Conflict Resolver synthesizes the suggestions made by the domain experts, which can be either CLIPS expert systems, or compiled C programs. In DEMO1, the current ICADS prototype, the CLIPS domain expert systems are Acoustics, Lighting, Structural, and Thermal; the compiled C domain experts are the CAD system and the User Interface.

Taylor, James↗
NASA NTRS2016

UUI: Reusable Spatial Data Services in Unified User Interface at NASA GES DISC

Unified User Interface (UUI) is a next-generation operational data access tool that has been developed at Goddard Earth Sciences Data and Information Services Center(GES DISC) to provide a simple, unified, and intuitive one-stop shop experience for the key data services available at GES DISC, including subsetting (Simple Subset Wizard -SSW), granule file search (Mirador), plotting (Giovanni), and other legacy spatial data services. UUI has been built based on a flexible infrastructure of reusable web services self-contained building blocks that can easily be plugged into spatial applications, including third-party clients or services, to easily enable new functionality as new datasets and services become available. In this presentation, we will discuss our experience in designing UUI services based on open industry standards. We will also explain how the resulting framework can be used for a rapid development, deployment, and integration of spatial data services, facilitating efficient access and dissemination of spatial data sets.

EOSDIS↗
NASA NTRS2018

The Utilization Profiles of the CCSDS Unified Space Link Protocol (USLP)

The purpose of this paper is to identify the utilization profiles for interfacing the Data Protocol Sublayer using the Unified Space Link Protocols (USLP) (reference 1) with the space link coding procedures as specified in the CCSDS Coding & Synchronization Blue Books (references 2 through 5), used in both telecommand and telemetry applications. This paper describes how the USLP Protocol utilizes the coding and synchronization sublayer to support: a. Direct to Earth (DTE) telemetry links for engineering and science data b. Direct to Earth (DTE) telemetry links for very high rate science data c. Direct from Earth (DFE) command, sequencing and flight software loads d. Space to Space Links (Proximity) utilized by orbiters for data exchange to/from surface bound assets. The CCSDS has divided the functions of the Data Link Layer into two sublayers: the Data Link Protocol Sublayer (DLP-SL) and the Coding and Synchronization Sublayer (CS-SL). The Data Link Protocol Sublayer (DLP-SL) interfaces to the users, accepting the data that is to be transported, on the sending side of the link, and delivering that data on the receiving end. The Transfer Frame is the data unit that is transferred across the Data Link Protocol Sublayer and the Coding and Synchronization Sublayer boundary. The Coding and Synchronization Sublayer (CS-SL) provides the encoding, randomization, and frame synchronization functions that prepares the USLP Transfer Frame for transport across the space link. The CS-SL is divided into 2 processes: 1) The Frame Interface Processes (FIP) performs the interface functions required to prepare the data for delivery to the Coding/Decoding Process (CDP). This process includes prepending a Frame Start Marker to the provided frame, when management has designated that the frame is not to be aligned to the codeblock or when there is no block code used. 2) The Coding/Decoding Process (CDP) performs the forward error correction processes that are used to optimize the performance of the link and minimize the error rate. The CDP creates the symbol stream that is delivered to the Physical Layer. The transfer of the USLP transfer frames across different types of space links is the focus of this paper. The Protocol Data Unit (PDU) that is passed in both directions between the Data Link Protocol Sublayer (DLP-SL) and Coding and Synchronization Sublayer (CS-SL) is the transfer frame. The USLP frame structure provides flexibility that can be constrained by the functions utilized within the CS-SL that prepare the transfer frame for transit. For example, the USLP transfer frame contains a length field that enables the frame to be of variable length but CS-SL under certain conditions may constrain the frame to be fixed in length. This paper describes 5 operational modes available for use by the Data Link Layer to provide data exchange across the USLP space link. These modes are different because different operational requirements apply to vastly different types of space links and thus the communications implementation requirements differ. The environmental issues include the power or energy available, the distance between the end points of the link, the complexity of the equipment available at those end points, the atmospheric conditions and radiometric frequency selection. The CS-SL utilizes different forward error correcting codes supported by specific operational modes to configure the data for transit. This paper describes all of the operational modes in a series of data models which decompose the functionality between the Data Link Protocol Sublayer and the Coding and Synchronization sublayer. The operational modes described are: 1. Uncoded Mode: has been used for short links that contain significant available power to provide an acceptable frame error rate. The frames in this mode can be variable in length and typically use an error detection algorithm (i.e., CRC) to determine if there are errors in the received frame. 2. Convolutional Only Mode: is currently the prime forward error correction coding used for the proximity links. The frames in this mode can be variable in length and typically use an error detection algorithm (i.e., CRC) to determine if there are errors in the received frame. 3. Variable Length Frame Aligned to Variable Length Codeblock (TC): is used for Direct from Earth links were power levels are high and the simple, least complex code i.e., the BCH code is used. This mode has been in use since the early 1970s. The BCH code is a short code and the decoder is easy to implement. 4. Fixed Length Frame Aligned to Fixed Length Codeblock (AOS/TM): was introduced when the concatenated Convolutional and Reed-Solomon Code was formulated to provide significant reduction in link data error rate and the ability to determine if there was an error in the decoded codeblock. The frame is aligned to the codeblock so that there is a one to one relationship of frame errors to codeblock errors without additional error detection coding being added. This mode requires the protocol frames to be the exact size of the message portion of the codeblock. 5. Frames Unaligned to Fixed Length Codeblocks (Currently used for very high rates and space to space links): This mode is currently used for missions that have a very high data rate that can be controlled adaptively as the environment changes and as the next generation operating mode for the proximity link. This mode from a coded data stream point of view is exactly like that described in 4. above, except that the frame need not be aligned to the codeblock. There is no requirement on frame length when using this mode. Thus when using USLP it can be used to support links that require short or long frames. There is also no mandatory requirement that frames cannot be separated by idle data reducing the tight data rate connection requirements between the data link protocol sublayer and the coding & synchronization sublayer. In conclusion, how these operational modes can be put to use in mission operational scenarios is described for Direct from Earth links (DFE), Direct to Earth links (DTE), and Proximity links.

Greenberg, E.↗
NASA NTRS1995

A portable MPI-based parallel vector template library

This paper discusses the design and implementation of a polymorphic collection library for distributed address-space parallel computers. The library provides a data-parallel programming model for C++ by providing three main components: a single generic collection class, generic algorithms over collections, and generic algebraic combining functions. Collection elements are the fourth component of a program written using the library and may be either of the built-in types of C or of user-defined types. Many ideas are borrowed from the Standard Template Library (STL) of C++, although a restricted programming model is proposed because of the distributed address-space memory model assumed. Whereas the STL provides standard collections and implementations of algorithms for uniprocessors, this paper advocates standardizing interfaces that may be customized for different parallel computers. Just as the STL attempts to increase programmer productivity through code reuse, a similar standard for parallel computers could provide programmers with a standard set of algorithms portable across many different architectures. The efficacy of this approach is verified by examining performance data collected from an initial implementation of the library running on an IBM SP-2 and an Intel Paragon.

Sheffler, Thomas J.↗
NASA NTRS1995

A Portable MPI-Based Parallel Vector Template Library

This paper discusses the design and implementation of a polymorphic collection library for distributed address-space parallel computers. The library provides a data-parallel programming model for C + + by providing three main components: a single generic collection class, generic algorithms over collections, and generic algebraic combining functions. Collection elements are the fourth component of a program written using the library and may be either of the built-in types of c or of user-defined types. Many ideas are borrowed from the Standard Template Library (STL) of C++, although a restricted programming model is proposed because of the distributed address-space memory model assumed. Whereas the STL provides standard collections and implementations of algorithms for uniprocessors, this paper advocates standardizing interfaces that may be customized for different parallel computers. Just as the STL attempts to increase programmer productivity through code reuse, a similar standard for parallel computers could provide programmers with a standard set of algorithms portable across many different architectures. The efficacy of this approach is verified by examining performance data collected from an initial implementation of the library running on an IBM SP-2 and an Intel Paragon.

Sheffler, Thomas J.↗
NASA NTRS2020

Development of a Display Tool to Quality Control Weather Balloon Data for Space Launch Vehicles Using Python

Continuous atmospheric data analysis is an important factor for space launch vehicle design and operations. The balloon quality control tool was developed by NASA’s Marshall Space Flight Center (MSFC) Natural Environments Branch (NEB) for monitoring quality control processes and verifying the automated flags created on the balloon data sets analyzed. The data sets currently analyzed are comprised of high-resolution and low-resolution balloon data from NASA Kennedy Space Center (KSC), co-located on the United States Air Force’s Eastern range (ER) at the Cape Canaveral Air Force Station. The NEB was tasked to perform a quality assessment of these data sets and needed a tool to confirm the quality control (QC) flags produced from an automated process and add additional QC flags if necessary. This Graphical User Interface (GUI) was developed to visualize all of the data from these balloon sets, display any flags from the automated QC process, and add additional flags to variables if necessary. The GUI was developed in Python 3.6 utilizing different packages available such as pandas for data analysis and manipulation, NumPy for high-performance multidimensional array and tools to compute with and manipulate arrays, Matplotlib for plotting data and Tkinter to build the GUI.

Jessica K Headley↗