Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “execution model”

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 145 records · Page 8

Lessons Learned from the Wide Field Camera 3 TV1 and TV2 Thermal Vacuum Test Campaigns

The Wide Field Camera 3 (WFC3) instrument has undergone two complete thermal vacuum tests (TV1 and TV2), during which valuable lessons were learned regarding test configuration, test execution, model capabilities, and modeling practices. The very complex thermal design of WFC3 produced a number of challenging aspects to ground testing with numerous ThermoElectric Coolers and heat pipes, not all of which were functional. Lessons learned during TV1 resulted in significant upgrades to the model capabilities and a change in the test environment approach for TV2. These upgrades proved invaluable during TV2 when pretest modeling assumptions proved to be false. Each of the lessons learned relate to one of two following broad statements: 1. Ensure the design can be tested and that the effect of non-flight like conditions is well understood, particularly with respect to non passive devices (TECs, Heat Pipes, etc) 2. Ensure that the model is sufficiently detailed and is capable of predicting off-nominal behavior and the power dissipation of any thermal devices, especially TECs This paper outlines a number of the lessons learned over these two test campaigns with respect to the thermal design, model, and test configuration and presents recommendations for future tests.

Peabody, Hume↗

Automated Generation and Assessment of Autonomous Systems Test Cases

This slide presentation reviews some of the issues concerning verification and validation testing of autonomous spacecraft routinely culminates in the exploration of anomalous or faulted mission-like scenarios using the work involved during the Dawn mission's tests as examples. Prioritizing which scenarios to develop usually comes down to focusing on the most vulnerable areas and ensuring the best return on investment of test time. Rules-of-thumb strategies often come into play, such as injecting applicable anomalies prior to, during, and after system state changes; or, creating cases that ensure good safety-net algorithm coverage. Although experience and judgment in test selection can lead to high levels of confidence about the majority of a system's autonomy, it's likely that important test cases are overlooked. One method to fill in potential test coverage gaps is to automatically generate and execute test cases using algorithms that ensure desirable properties about the coverage. For example, generate cases for all possible fault monitors, and across all state change boundaries. Of course, the scope of coverage is determined by the test environment capabilities, where a faster-than-real-time, high-fidelity, software-only simulation would allow the broadest coverage. Even real-time systems that can be replicated and run in parallel, and that have reliable set-up and operations features provide an excellent resource for automated testing. Making detailed predictions for the outcome of such tests can be difficult, and when algorithmic means are employed to produce hundreds or even thousands of cases, generating predicts individually is impractical, and generating predicts with tools requires executable models of the design and environment that themselves require a complete test program. Therefore, evaluating the results of large number of mission scenario tests poses special challenges. A good approach to address this problem is to automatically score the results based on a range of metrics. Although the specific means of scoring depends highly on the application, the use of formal scoring - metrics has high value in identifying and prioritizing anomalies, and in presenting an overall picture of the state of the test program. In this paper we present a case study based on automatic generation and assessment of faulted test runs for the Dawn mission, and discuss its role in optimizing the allocation of resources for completing the test program.

Testing challenges↗

Tiled WMS/KML Server V2

This software is a higher-performance implementation of tiled WMS, with integral support for KML and time-varying data. This software is compliant with the Open Geospatial WMS standard, and supports KML natively as a WMS return type, including support for the time attribute. Regionated KML wrappers are generated that match the existing tiled WMS dataset. Ping and JPG formats are supported, and the software is implemented as an Apache 2.0 module that supports a threading execution model that is capable of supporting very high request rates. The module intercepts and responds to WMS requests that match certain patterns and returns the existing tiles. If a KML format that matches an existing pyramid and tile dataset is requested, regionated KML is generated and returned to the requesting application. In addition, KML requests that do not match the existing tile datasets generate a KML response that includes the corresponding JPG WMS request, effectively adding KML support to a backing WMS server.

Plesea, Lucian↗

CometQuest: A Rosetta Adventure

This software is a higher-performance implementation of tiled WMS, with integral support for KML and time-varying data. This software is compliant with the Open Geospatial WMS standard, and supports KML natively as a WMS return type, including support for the time attribute. Regionated KML wrappers are generated that match the existing tiled WMS dataset. Ping and JPG formats are supported, and the software is implemented as an Apache 2.0 module that supports a threading execution model that is capable of supporting very high request rates. The module intercepts and responds to WMS requests that match certain patterns and returns the existing tiles. If a KML format that matches an existing pyramid and tile dataset is requested, regionated KML is generated and returned to the requesting application. In addition, KML requests that do not match the existing tile datasets generate a KML response that includes the corresponding JPG WMS request, effectively adding KML support to a backing WMS server.

Leon, Nancy J.↗

Trade Space Specification Tool (TSST) for Rapid Mission Architecture (Version 1.2)

Trade Space Specification Tool (TSST) is designed to capture quickly ideas in the early spacecraft and mission architecture design and categorize them into trade space dimensions and options for later analysis. It is implemented as an Eclipse RCP Application, which can be run as a standalone program. Users rapidly create concept items with single clicks on a graphical canvas, and can organize and create linkages between the ideas using drag-and-drop actions within the same graphical view. Various views such as a trade view, rules view, and architecture view are provided to help users to visualize the trade space. This software can identify, explore, and assess aspects of the mission trade space, as well as capture and organize linkages/dependencies between trade space components. The tool supports a user-in-the-loop preliminary logical examination and filtering of trade space options to help identify which paths in the trade space are feasible (and preferred) and what analyses need to be done later with executable models. This tool provides multiple user views of the trade space to guide the analyst/team to facilitate interpretation and communication of the trade space components and linkages, identify gaps in combining and selecting trade space options, and guide user decision-making for which combinations of architectural options should be pursued for further evaluation. This software provides an environment to capture mission trade space elements rapidly and assist users for their architecture analysis. This is primarily focused on mission and spacecraft architecture design, rather than general-purpose design application. In addition, it provides more flexibility to create concepts and organize the ideas. The software is developed as an Eclipse plug-in and potentially can be integrated with other Eclipse-based tools.

Wang, Yeou-Fang↗

Enhancing Cassini Operations & Science Planning Tools

The Cassini team uses a variety of software utilities as they manage and coordinate their mission to Saturn. Most of these tools have been unchanged for many years, and although stability is a virtue for long-lived space missions, there are some less-fragile tools that could greatly benefit from modern improvements. This report shall describe three such upgrades, including their architectural differences and their overall impact. Emphasis is placed on the motivation and rationale behind architectural choices rather than the final product, so as to illuminate the lessons learned and discoveries made.These three enhancements included developing a strategy for migrating Science Planning utilities to a new execution model, rewriting the team's internal portal for ease of use and maintenance, and developing a web-based agenda application for tracking the sequence of files being transmitted to the Cassini spacecraft. Of this set, the first two have been fully completed, while the agenda application is currently in the early prototype stage.

science planning↗

DEVELOP’s Approach to Experiential Learning

The NASA DEVELOP Program addresses environmental decision making needs and geoscience workforce development through 10-week feasibility studies that apply Earth observations to environmental issues at hand. The program builds capacity to use geospatial information in both its participants (students, recent graduates, early career professionals, and transitioning career professionals) and partner organizations (federal agencies, state & local governments, non-profits, and private industry). This is accomplished through a structured project execution model that provides opportunities for participants to have autonomy, learn “on the job,” and gain new skillsets for working with remote sensing data. A pipeline of leadership positions enhances opportunities for individuals engaged in the program to get hands-on experience conducting data analyses, communicating their work, leading technical projects, and building their knowledge bank of Earth-observing satellite capabilities. These skillsets and knowledge are then transferred to partners through the projects. This panel contribution will introduce the DEVELOP model, highlight experiences of participants, and share the program’s insights into good practices for effective experiential learning.

Capacity Building↗

Cathode Modeling of Solid-State Batteries

The search for safe, reliable, and compact high-capacity energy storage devices has led to increased interest in all-solid-state battery research. The use of solid electrolytes provides enhanced safety and durability due to their reduced flammability and increased mechanical strength compared to organic liquid electrolytes. Still, the use of solid electrolytes remains challenging. Computational modeling plays a substantial role in addressing these challenges. A particle dynamics electromechanical model for simulating electrochemical processes in a solid-state battery cathode will be presented. The model presents cathode microstructure at the particle level as a mixture of ionically conductive solid electrolyte particles, electrically conductive carbon additives, and cathodic reactant particles. After densification, the particle connectivity is analyzed to reconstruct the complex electric network connecting reactant particles with an anodic and cathodic current collectors through the electrolyte and carbon particles. The Kirchhoff’s matrix equation describing this electric network, is solved to obtain values of various critical parameters, such as the overall conductivity of the cathode for lithium ions and electrons, cathodic reactant material utilization, and the distribution of the electric current and voltages within the cathode. In addition, by representing the reactant particles as electrolyte or galvanic microcells governed by the Butler-Volmer electrochemical equation, the overall performance of battery cells during charge or discharge processes, respectively, can be predicted for a given cathodic powder composition. The presented model, executed on a high-performance computing architecture, essentially provides a valuable guidance in designing and developing future solid-state batteries.

solid-state battery↗

DUNE Software and High Performance Computing

DUNE, like other HEP experiments, faces a challenge related to matching execution patterns of our production simulation and data processing software to the limitations imposed by modern high-performance computing facilities. In order to efficiently exploit these new architectures, particularly those with high CPU core counts and GPU accelerators, our existing software execution models require adaptation. In addition, the large size of individual units of raw data from the far detector modules pose an additional challenge somewhat unique to DUNE. Here we describe some of these problems and how we begin to solve them today with existing software frameworks and toolkits. We also describe ways we may leverage these existing software architectures to attack remaining problems going forward. This whitepaper is a contribution to the Computational Frontier of Snowmass21.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗

Comparing LLC-Memory Traffic between CPU and GPU Architectures

The cache hierarchy in modern CPUs and GPUs is becoming increasingly complex, which makes understanding the handshake between the memory access patterns and the cache hierarchy difficult. Moreover, the details of different cache policies are not publicly available. Therefore, the research community relies on observation to understand the relationship between memory access patterns and cache hierarchy. Our previous studies delved into the different microarchitectures of Intel CPUs. In this study, GPUs from NVIDIA and AMD are considered. Even though the execution models in CPUs and GPUs are distinct, this study attempts to correlate the behavior of the cache hierarchy of CPUs and GPUs. Using the knowledge gathered from studying Intel CPUs, the similarities and dissimilarities between CPUs and GPUs are identified. Through model evaluation, this study provides a proof of concept that traffic between last-level cache and memory can be predicted for sequential streaming and strided access patterns on GPUs.

Monil, M. A. H.↗

Using Flexible Execution, Replanning, and Model Parameter Updates to Address Environmental Uncertainty for a Planetary Lander

When planning in unknown environments, a planner must ensure robustness to unknown phenomena and manage unpredictable variation in execution. Productivity in the face of these challenges requires an integrated approach to planning and execution that is capable of reacting to variation while still maximizing overall utility. We examine this problem in the context of the Europa Lander mission concept. We propose a planning and execution framework that responds to feedback using three techniques: (1) flexible execution, (2) periodic replanning, and (3) online model parameter and utility updates. The efficacy of each of these techniques is examined through simulation of the Europa Lander concept, showing higher utility achievement compared to baseline approaches.

Chien, Steve A.↗

State-based models for planning and execution coordination

Many traditional planners are built on top of existing execution engines that were not necessarily intended to be operated by a planner. The Mission Data System has been designed from the onset to have both an execution and planning engine and provides a framework for producing state-based models that can be used to coordinate planning and execution. The models provide a basis for ensuring the consistency of assumptions made by the execution engine and planner, and the frameworks provide a basis for run time communications between the planner and execution engines.

planning↗

Simulated execution of hybrid quantum computing systems

We use modeling and simulation to study the behavior and performance of hybrid quantum computing systems. Our approach is based on a layered design with abstract machine models, which identify the key components and interfaces for quantum processing units, quantum programming models, and hybrid execution models. We use discrete-event simulating to track the dynamical state of hierarchical abstract machine models while executing test programs, and we collect statistics on time and energy consumption to forecast the resources required by quantum processors for future scientific computation.

Humble, Travis↗

Tabulated pressure measurements on an executive-type jet transport model with a supercritical wing

A 1/9 scale model of an existing executive type jet transport refitted with a supercritical wing was tested on in the 8 foot transonic pressure tunnel. The supercritical wing had the same sweep as the original airplane wing but had maximum thickness chord ratios 33 percent larger at the mean geometric chord and almost 50 percent larger at the wing-fuselage juncture. Wing pressure distributions and fuselage pressure distributions in the vicinity of the left nacelle were measured at Mach numbers from 0.25 to 0.90 at angles of attack that generally varied from -2 deg to 10 deg. Results are presented in tabular form without analysis.

Bartlett, D. W.↗

Wake Vortex Inverse Model User's Guide

NorthWest Research Associates (NWRA) has developed an inverse model for inverting landing aircraft vortex data. The data used for the inversion are the time evolution of the lateral transport position and vertical position of both the port and starboard vortices. The inverse model performs iterative forward model runs using various estimates of vortex parameters, vertical crosswind profiles, and vortex circulation as a function of wake age. Forward model predictions of lateral transport and altitude are then compared with the observed data. Differences between the data and model predictions guide the choice of vortex parameter values, crosswind profile and circulation evolution in the next iteration. Iterations are performed until a user-defined criterion is satisfied. Currently, the inverse model is set to stop when the improvement in the rms deviation between the data and model predictions is less than 1 percent for two consecutive iterations. The forward model used in this inverse model is a modified version of the Shear-APA model. A detailed description of this forward model, the inverse model, and its validation are presented in a different report (Lai, Mellman, Robins, and Delisi, 2007). This document is a User's Guide for the Wake Vortex Inverse Model. Section 2 presents an overview of the inverse model program. Execution of the inverse model is described in Section 3. When executing the inverse model, a user is requested to provide the name of an input file which contains the inverse model parameters, the various datasets, and directories needed for the inversion. A detailed description of the list of parameters in the inversion input file is presented in Section 4. A user has an option to save the inversion results of each lidar track in a mat-file (a condensed data file in Matlab format). These saved mat-files can be used for post-inversion analysis. A description of the contents of the saved files is given in Section 5. An example of an inversion input file, with preferred parameters values, is given in Appendix A. An example of the plot generated at a normal completion of the inversion is shown in Appendix B.

Lai, David↗

SimApp 1.8.x

System for converting DESIRE (Direct Executing Simulation in Real Time) simulation models to executable code models (C# / C++). These converted models are used as the basis for 2 products, one of which is the focus of this review: an engineering design interface for Fissile Solution Systems. ModelConverter.exe (C#) converts DESIRE model inputs to a C++ plug-in subclass. SimApp.exe (C# / C++) has a C++ dll that is a numerical integration engine that the Converted models plug into. The engineering design interface is a C# GUI that calls on the C++ dll to execute a particular converted model. The GUI allows the user to specify the length of a simulation, run the simulation, view data plots and data tables. Stability plots may also be produced and manipulated. The engineering design interface will be released as source code and executable; the model converter source is also intended for release.

Determan, JohnC.↗

SimApp 1.8.x

System for converting DESIRE (Direct Executing Simulation in Real Time) simulation models to executable code models (C# / C++). These converted models are used as the basis for 2 products, one of which is the focus of this review: an engineering design interface for Fissile Solution Systems. ModelConverter.exe (C#) converts DESIRE model inputs to a C++ plug-in subclass. SimApp.exe (C# / C++) has a C++ dll that is a numerical integration engine that the Converted models plug into. The engineering design interface is a C# GUI that calls on the C++ dll to execute a particular converted model. The GUI allows the user to specify the length of a simulation, run the simulation, view data plots and data tables. Stability plots may also be produced and manipulated. The engineering design interface will be released as source code and executable; the model converter source is also intended for release.

Determan, John C.↗

Groundwater and Surface Water Flow (GSFLOW) model files to explore bedrock circulation depth and porosity in Copper Creek, Colorado

This data package contains integrated hydrological model input and output files for Copper Creek, Colorado (24 km2), a tributary of the East River located in the headwaters of the Upper Colorado River Basin. The model code is the U.S. Geological Survey (USGS) Groundwater and Surface Water Flow (GSFLOW) model. The model contains a 100-m grid resolution and a daily timestep. The land surface model is dynamically linked to a three-dimensional groundwater flow model that allows for streamflow gaining and losing conditions. The groundwater model contains 12 model layers and extends 400 m below land surface. The original Copper Creek model was modified to contain geologic layers representing saprolite, shallow bedrock, and deep bedrock. Endmember depth versus hydraulic conductivity relationships and porosity values for fractured crystalline rock are simulated. For the shallow case, median flow depths occur in the shallow saprolite at depths <8 m, while the deep case promotes a median groundwater flow depth of 100 m. With this modeling framework we compare streamflow response to a plausible worst-case drought lasting up to five years. Streamflow metrics of analysis include average streamflow, fraction of stream network that is dry, no-flow duration, average groundwater flow to streams and time to recovery following the drought. Results and implications are presented in a paper submitted to Geophysical Research Letters titled, "The role of bedrock circulation depth and porosity in mountain streamflow response to prolonged drought" by Rosemary WH. Carroll, Andrew H. Manning and Kenneth H Williams. A Readme.txt file provides instructions on how to download all model files and execute each model scenario. In addition to the GSFLOW output/prms/copper_drought.csv file containing daily basin water stores and fluxes (refer to GSFLOW manual) and the output/prms/copper_drought_statvar.dat file with output defined in the gsflow3.control file (refer to GSFLOW Manual), output files also include spatially distributed daily values of total evapotranspiration, canopy evaporation, precipitation, snowfall, infiltration, snow water equivalent, potential evapotranspiration, recharge, sublimation, soil moisture, contributing interflow, water table elevations, changes in groundwater storage, groundwater evapotranspiration, interbasin groundwater flow (limited to the alluvium below the stream outlet), and surface-groundwater exchanges within the river system.

54 ENVIRONMENTAL SCIENCES↗