SEARCH · Engineering Papers

Results for “GdS”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

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

At least 37 records · Page 2

All sources NASA NTRS DOE OSTI

DOE OSTI2020

GPU Direct I/O with HDF5

Exascale HPC systems are being designed with accelerators, such as GPUs, to accelerate parts of applications. In machine learning workloads as well as large-scale simulations that use GPUs as accelerators, the CPU (or host) memory is currently used as a buffer for data transfers between GPU (or device) memory and the file system. If the CPU does not need to operate on the data, then this is sub-optimal because it wastes host memory by reserving space for duplicated data. Furthermore, this “bounce buffer” approach wastes CPU cycles spent on transferring data. A new technique, NVIDIA GPUDirect Storage (GDS), can eliminate the need to use the host memory as a bounce buffer. Thereby, it becomes possible to transfer data directly between the device memory and the file system. This direct data path shortens latency by omitting the extra copy and enables higher-bandwidth. To take full advantage of GDS in existing applications, it is necessary to provide support with existing I/O libraries, such as HDF5 and MPI-IO, which are heavily used in applications. In this paper, we describe our effort of integrating GDS with HDF5, the top I/O library at NERSC and at DOE leadership computing facilities. We design and implement this integration using a HDF5 Virtual File Driver (VFD). The GDS VFD provides a file system abstraction to the application that allows HDF5 applications to perform I/O without the need to move data between CPUs and GPUs explicitly. We compare performance of the HDF5 GDS VFD with explicit data movement approaches and demonstrate superior performance with the GDS method.

Ravi, J↗

NASA NTRS2012

Cost-Effective Telemetry and Command Ground Systems Automation Strategy for the Soil Moisture Active Passive (SMAP) Mission

Soil Moisture Active Passive (SMAP) is an Earth-orbiting, remote-sensing NASA mission slated for launch in 2014. The ground data system (GDS) being developed for SMAP is composed of many heterogeneous subsystems, ranging from those that support planning and sequencing to those used for real-time operations, and even further to those that enable science data exchange. A full end-to-end automation of the GDS may result in cost savings during mission operations, but it would require a significant upfront investment to develop such a comprehensive automation. As demonstrated by the Jason-1 and Wide-field Infrared Survey Explorer (WISE) missions, a measure of "lights-out" automation for routine, orbital pass, ground operations can still reduce mission costs through smaller staffing of operators and limiting their working hours. The challenge, then, for the SMAP GDS engineering team, is to formulate an automated operations strategy--and corresponding system architecture -- to minimize operator intervention during routine operations, while balancing the development costs associated with the scope and complexity of automation. This paper discusses the automated operations approach being developed for the SMAP GDS. The focus is on automating the activities involved in routine passes, which limits the scope to real-time operations. A key subsystem of the SMAP GDS -- NASA's AMMOS Mission Data Processing and Control System (AMPCS) -- provides a set of capabilities that enable such automation. Also discussed are the lights-out pass automations of the Jason-1 and WISE missions and how they informed the automation strategy for SMAP. The paper aims to provide insights into what is necessary in automating the GDS operations for Earth satellite missions.

soil moisture↗

NASA NTRS2012

Cost-Effective Telemetry and Command Ground Systems Automation Strategy for the Soil Moisture Active Passive (SMAP) Mission

Soil Moisture Active Passive (SMAP) is an Earth-orbiting, remote-sensing NASA mission slated for launch in 2014.[double dagger] The ground data system (GDS) being developed for SMAP is composed of many heterogeneous subsystems, ranging from those that support planning and sequencing to those used for real-time operations, and even further to those that enable science data exchange. A full end-to-end automation of the GDS may result in cost savings during mission operations, but it would require a significant upfront investment to develop such comprehensive automation. As demonstrated by the Jason-1 and Wide-field Infrared Survey Explorer (WISE) missions, a measure of "lights-out" automation for routine, orbital pass ground operations can still reduce mission cost through smaller staffing of operators and limited work hours. The challenge, then, for the SMAP GDS engineering team is to formulate an automated operations strategy--and corresponding system architecture--to minimize operator intervention during operations, while balancing the development cost associated with the scope and complexity of automation. This paper discusses the automated operations approach being developed for the SMAP GDS. The focus is on automating the activities involved in routine passes, which limits the scope to real-time operations. A key subsystem of the SMAP GDS--NASA's AMMOS Mission Data Processing and Control System (AMPCS)--provides a set of capabilities that enable such automation. Also discussed are the lights-out pass automations of the Jason-1 and WISE missions and how they informed the automation strategy for SMAP. The paper aims to provide insights into what is necessary in automating the GDS operations for Earth satellite missions.

remote-sensing↗

DOE OSTI2020

Real-Time Coupling of Geographically Distributed Research Infrastructures: Taxonomy, Overview, and Real-World Smart Grid Applications

Novel concepts enabling a resilient future power system and their subsequent experimental evaluation are experiencing a steadily growing challenge: large scale complexity and questionable scalability. The requirements on a research infrastructure (RI) to cope with the trends of such a dynamic system therefore grow in size, diversity and costs, making the feasibility of rigorous advancements questionable by a single RI. Analysis of large scale system complexity has been made possible by the real-time coupling of geographically separated RIs undertaking geographically distributed simulations (GDS), the concept of which brings the equipment, models and expertise of independent RIs, in combination, to optimally address the challenge. This article presents the outputs of IEEE PES Task Force on Interfacing Techniques for Simulation Tools towards standardization of GDS as a concept. First, the taxonomy for setups utilized for GDS is established followed by a comprehensive overview of the advancements in real-time couplings reported in literature. The overview encompasses fundamental technological design considerations for GDS. The article further presents four application oriented case studies (real-world implementations) where GDS setups have been utilized, demonstrating their practicality and potential in enabling the analysis of future complex power systems.

distributed laboratories↗

NASA NTRS2008

Moving Away from Ones and Zeros, Designing a Ground Data System Based on Higher Levels of Abstraction

Previous JPL ground systems have been designed with the Ground Data System (GDS) engineer in mind. The focus on these systems has been on packaging and delivery of low level information (frames, packets, telemetry values) to the end user. It was not that long ago when project teams would be huddled over a workstation, examining crude displays of telemetry bits organized in various ways, trying to determine the status of a spacecraft. Understanding the data often required additional levels of GDS expertise, or worse, transformation of the raw data into alternative formats followed by ingestion into other tools so that the data became meaningful. The primary focus was often to answer these types of questions: "Why did this particular frame fail Reed-Solomon decode? Why did this packet get marked as invalid? Why am I missing a block of telemetry from my query?" -- which are completely valid questions to ask from a GDS Engineer's point of view, and large families of tools have been designed to help answer these questions. But these are not the questions that most users care about - which are more like: "Why is the battery state of charge trending down? Show me a summary image report for the last traverse to the target. Show me a data accountability summary for the last DSN pass." Answers to these questions, which are what users are looking for, requires a higher level of abstraction and supporting tools than mining through ones and zeros. JPL has created a next generation capability called the Mission Data Processing and Control System (MPCS) which is designed to support this higher level of abstraction by providing customizable views of the ground system combining collections of lower level information into more meaningful ways. Instead of examining frames, packets, and individual telemetry data points -- MPCS is capable of providing comprehensive summary reports, product status, overall flight/ground event status, as well as payload health summaries. Based on these higher level views, end users can make tactical or strategic decisions, or drop into detailed analysis as needed. System designers need to continue building systems that support low level GDS troubleshooting - but the basic design of a GDS should be geared towards what end users actually need to see. This paper will describe the capabilities of MPCS that directly support these higher levels of abstraction, and which are being used today in missions such as the Mars Science Laboratory and other NASA missions.

MPCS↗

NASA NTRS2020

Toward More Realistic Simulation and Prediction of Dust Storms on Mars

Major (regional and global)dust storms dominate weather and climate variability on present-day Mars. Absorption and scattering of visible and IR radiation by dust strongly affect the thermal state of the thin Mars atmosphere, while dust provides condensation nuclei for water and CO2 cloud particles, which also affect radiative fluxes. Global dust storms (GDS) occur ~three times per Mars decade and to date have been observed in only northern fall and winter,when the global circulation is strongest. Tenfold increases in column dust opacity are typical during GDS, with intense vertical motions transporting dust to far higher altitudes than usual. The key processes and feedbacks that produce GDS remain poorly understood, hence current atmospheric models fail to self-consistently simulate observed dust storm activity. This means we have no predictive capability for when GDS may occur, either now or in Mars’s past. And crucially, due to the huge impact of GDS on the atmosphere and surface, our lack of ability to simulate realistic dust storms has major implications for Mars science and exploration: from understanding the present climate (§2.1),to modeling past climates and water cycles (§2.2), to exploring how wind, water, and dust cycles varied over time to interpret geology and assess potential habitability(§2.3), to quantifying and mitigating risks posed to Mars missions (§2.4)

Claire E Newman↗

NASA NTRS2006

From Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challenge

The Dawn GDS Team met the SC Sim integration challenge in eight months. The GDS System Engineering approach in response to the SC Simintegration challenge, focused on a set of key practices: decomposition of project request into manageable requirements; integration of multiple ground disciplines and experts into a focused team effort; risk management thru management of expectations; and aggregation of intermediate products into a final product. By maintaining a a system-level focus, the overall systems engineering process unified team GDS Team members with a common goal: the success of the ground system as a whole and not just the success of their individual expert contributions. Incorporation of Agile-type development efforts were aligned with a risk strategy based on team-oriented principles and expectations management, thus achieving a more stable baseline solution without compromising the integrity of the GDS design.

Dawn Mission↗

NASA NTRS2006

Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challange

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), responsible for project management and flight operations; Orbital Sciences Corporation (OSC), spacecraft builder and responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), responsible for science planning and operations. As a cost-capped mission, one of Dawn s implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL s ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL s GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project s commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to an overall systems engineering process and fundamental systems engineering practices: decomposition of the project request into manageable requirements; definition of a structured yet flexible development process; integration of multiple ground disciplines and experts into a focused team effort; in-process risk management; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

systems engineering↗

NASA NTRS2008

The Interim: Until You Achieve an Operationally Responsive Ground System

Everyone wants to achieve a 'Responsive' Ground Data System (GDS), but that takes time. What do you do in the interim? Our group, called the Integration, Test and Deployment Team (ITD), is a group of responsive engineers whose primary focus is to assist JPL projects to successfully adapt, test, integrate and deploy their ground data system. The team configures and adapts the GDS for a project, so that analysts, engineers and scientist do not need to be experts in the GDS to operate it. The team has developed a human interface to accommodate all types of users. It provides Graphical User Interfaces (GUI's) for those that want GUI's, command line interfaces for those that want control, and selection button interfaces for other users. The cornerstone of a responsive Ground Data System is responsive people. Without individuals who can be aware of a project's changing needs and requirements, how can the GDS become responsive?.

Ground Data System (GDS)↗

NASA NTRS2008

The Interim : until you achieve an operationally responsive ground system

ground data system (GDS)↗

NASA NTRS2006

Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challenge

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), manages the project and is responsible for flight operation; Orbital Sciences Corporation (OSC), is the spacecraft builder and is responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), is responsible for science planning and operations. As a cost-capped mission, one of Dawn's implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL's ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL's GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project's commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to fundamental systems engineering practices: decomposition of the project request into manageable requirements; integration of multiple ground disciplines and experts into a focused team effort; definition of a structured yet flexible development process; definition of an in-process risk reduction plan; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

Ground Data System (GDS)↗

DOE OSTI2025

Optimizing fused silica debris shield use in the National Ignition Facility

The National Ignition Facility (NIF) deliberately and routinely operates with its final optics exposed to fluences likely to induce and grow damage. This choice has enabled the NIF to operate at energies previously unachievable at the expense of limitations to delivered power and energy contingent on the ability to repair damage on the final optics. Prior to the introduction of the fused silica debris shield (FSDS), the grating debris shield (GDS) was the optic type on the NIF most prone to damage and hence a primary limiter to the delivered energy. The introduction of the FSDS has reduced the damage initiation rate on the GDS by about two orders of magnitude to date. Despite the FSDS being a disposable optic, it is important to understand how the FSDS damages and when its damage requires it to be exchanged to maximize the FSDS lifetime while still protecting the GDS from damage. We will define the FSDS exchange criteria and evaluate the damage initiation mechanisms of the FSDS. The surface damage morphologies provide insight into the impact of the various damage mechanisms that limit the FSDS lifetime. These results are utilized in our analysis to optimize the FSDS exchange criteria to further extend the GDS lifetime.

42 ENGINEERING↗

NASA NTRSDate not supplied

Astrobee Operations on the Iss: Gui’S Impact on the Operators’ Cognitive Load

The Astrobee free-flying robots have completed their fifth successful year of operations housed in the Japanese Experimental Module (JEM) on the International Space Station (ISS). In this paper, we introduce two Graphical User Interfaces (GUI) used to operate and monitor in real-time the Astrobee free-flying robots onboard the ISS and report on the impact these GUIs have in the operator’s cognitive load. A review of the state-of-the-art GUI design for remotely teleoperated scenarios with minimal time delay is presented and the study’s conclusion used to determine the elements and recommendations to create an interface that minimizes its impact on the overall performance of an operator during an activity at the ISS. The Ground Data System (GDS) is one of the two GUIs in the study: it contains several tabs, each of which displays a different set of controls for specific tasks e.g. Overview, Run Plan, Teleoperate, Guest Science; some also display video and a three-dimensional (3D) representation of the ISS and robot based on the Astrobee’s telemetry. Most tabs enable a single operator-robot connection, however some of its tabs are capable to monitor and control up to three Astrobees simultaneously. The GDS Helper is a text-based user interface created to facilitate commanding and monitoring of an Astrobee robot directly from an SSH session. In full interactive mode it displays a maximum of 5 sections: general commanding, feedback/ack, telemetry, guest science commanding, and data, all in one view. In batch mode, it enables complex command scripting while retaining some interactive capabilities. A comparative analysis between these GUIs is carried out at an analogous ISS environment at the NASA Ames Research Center’s Granite Lab and its results presented. While GDS is able to provide an operator with control and situational awareness via its video and 3D displays, its several tabs may introduce an overwhelming amount of information confusing and delaying the operator especially during time-sensitive maneuvers where the operator may need to switch back and forth between them. GDS helper in the other hand does not provide video or 3D displays thus not allowing an operator to attain situational awareness, however it provides the operator with a design displaying commonly used data in a single window, enabling the operator to understand the state of the robot at a glance and control it through a commands entered via keyboard instead of a combination of mouse clicks and keyboard input. The results of the experiments measure the cognitive load across several operators maneuvering Astrobee to accomplish tasks ranging from fully manual to supervised activities. A GUI combining a single window displaying data along video and a 3D display is expected to reduce the operator’s cognitive load.

Astrobee↗

NASA NTRS1973

System design of the Pioneer Venus spacecraft. Volume 8: Command/data handling subsystems studies

Study tasks for the command and data handling subsystems have been directed to: (1) determining ground data systems, (GDS) interfaces and deep space network (DSN) changes, if required, (2) defining subsystem requirements, (3) surveying existing hardware that could be used or modified to meet subsystem requirements, and (4) establishing a baseline design. Study of the existing GDS led to the conclusion that the Viking configuration GDS can be used with only minor changes required for the Pioneer Venus baseline. Those changes required are associated with providing a predetection recording capability used during probe entry and descent. Subsystem requirements were first formulated with sufficient latitude so that surveys of existing hardware could lead to low cost hardware which, in turn, could modify more narrowly defined subsystem requirements.

Vesely, D. D.↗

NASA NTRS2006

A Whale of a Tale: Creating Spacecraft Telemetry Data Analysis Products for the Deep Impact Mission

This paper describes some of the challenges and lessons learned from the Deep Impact (DI) Mission Ground Data System's (GDS) telemetry data processing and product generation tool, nicknamed 'Whale.' One of the challenges of any mission is to analyze testbed and operational telemetry data. Methods to retrieve this data to date have required spacecraft subsystem members to become experts in the use of a myriad of query and plot tools. As budgets shrink, and the GDS teams grow smaller, more of the burden to understand these tools falls on the users. The user base also varies from novice to expert, and requiring them to become GDS tool experts in addition to spacecraft domain experts is an undue burden. The "Whale" approach is to process all of the data for a given spacecraft test, and provide each subsystem with plots and data products 'automagically.'.

Deep Impact↗

NASA NTRS2016

Use of a Small Unmanned Aircraft System for Autonomous Fire Spotting at the Great Dismal Swamp

This paper describes the results of a set of experiments and analyses conducted to evaluate the capability of small unmanned aircraft systems (sUAS) to spot nascent fires in the Great Dismal Swamp (GDS) National Wildlife Refuge. This work is the result of a partnership between the National Aeronautics and Space Administration and the US Fish and Wildlife service specifically to investigate sUAS usage for fire-spotting. The objectives of the current effort were to: 1) Determine suitability and utility of low-cost Small Unmanned Aircraft Systems (sUAS) to detect nascent fires at GDS; 2) Identify and assess the necessary National Airspace System (NAS) integration issues; and 3) Provide information to GDS and the community on system requirements and concepts-of-operation (CONOPS) for conducting fire detection/support mission in the National Airspace and (4) Identify potential applications of intelligent autonomy that would enable or benefit this high-value mission. In addition, data on the ability of various low-cost sensors to detect smoke plumes and fire hot spots was generated during the experiments as well as identifying a path towards a future practical mission utility by using sUAS in beyond visual-line-of-sight operation in the National Airspace System (NAS).

Logan, Michael J.↗

NASA NTRS2021

Automated Data Accountability for Missions in Mars Rover Data

As the Mars Curiosity Rover transmits data to the JPL Ground Data System (GDS), it frequently observes data loss and corruption, requiring re-transmits from the rover and Ground Data System Analysts (GDSA) to monitor the downlink process. As new missions are launched, the GDSA team redistributes analysts to these new missions, causing shortages in previous missions. The GDSA team can significantly benefit from the automation and optimization of the downlink process of telemetry data. In fact, there is a need for a better understanding of why the data is corrupted, so that the GDSA team can best determine the root cause of the issues in the GDS. This paper presents machine learning and deep learning based approaches to automate and optimize the detection of data loss. We first created a pipeline to automatically accumulate data from the telemetry databases (MAROS, Telemetry Data Storage, and GDS Elastic Search Database) in the downlink process. With our newly created datasets, we perform feature selection to supplement the GDSA understanding of the downlink process and provide supplemental analysis on the importance of different features. We implement various machine learning and deep learning based models, including support vector machines, ensemble methods, and deep neural networks and evaluate their accuracies in identifying whether a downlink process is complete or incomplete. We utilize fast hyperparameter optimization methods that allow our models to quickly be re-trained, allowing them to quickly be tuned and optimized on daily incoming data in real time. This hyperparameter optimization also allows our methods to be quickly integrated into other JPL missions. Our results show that our best-performing machine learning and deep learning based models outperform the existing GDSA detection software by 6 accuracy points and can aid analysts by providing insights into the data accountability problem. Since these various machine learning and deep learning approaches vary significantly in interpretability, we provide a discussion on the tradeoffs between their performance and trustworthiness in helping detect issues in data transmission.

Divsalar, Dariush↗

NASA NTRS2024

Pressure Deficit in Gale Crater and a Larger Northern Polar Cap After the MY34 Global Dust Storm

We describe the model-independent analysis technique of Mars Science Laboratory (MSL) pressure and Mars Climate Sounder (MCS) data in de la Torre Juárez et al. (2019, https://doi.org/10.22541/essoar.169945479.90436599/v1) that compared multiple years of surface pressures on Gale before, during, and after the Global Dust Storm of Mars Year 34. The analysis found (a) representative pressure scale heights over Gale; (b) that the storm was followed by a pressure deficit at Gale; (c) the following C storms did not eliminate the deficit; (d) changes in the duration of the polar caps condensation seasons, with an early start of the North Polar (NP) ice cap growing season the year before the Great Dust Storm (GDS) and a late signature of the end of the expansion season thereafter, changes consistent with a larger growth phase of the NP cap; (e) MCS observed a larger than usual NP cap; and (f) cold temperature anomalies over the NP and warm over the Southern Pole after the storm. We also show that the analysis of observed MSL pressure data alone filters out effects on the pressure signal that are attributable to dynamical and orographic processes in a recent model analysis that makes similar interpretations as our 2019 study. One additional Mars year of observations is included to eliminate early concerns about sensor drifts. Noting that a similar NP anomaly was observed with MCS data after the last early GDS in MY25, and not the later GDS of MY27, the results suggest a possible unique effect of early GDSs.

Manuel de la Torre Juárez↗