SEARCH · Engineering Papers

Results for “execution architecture”

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 649 records · Page 36

All sources NASA NTRS DOE OSTI

NASA NTRS2001

Photochemical Phenomenology Model for the New Millennium

The "Photochemical Phenomenology Model for the New Millennium" project tackles the issue of reengineering and extension of validated physics-based modeling capabilities ("legacy" computer codes) to application-oriented software for use in science and science-support activities. While the design and architecture layouts are in terms of general particle distributions involved in scattering, impact, and reactive interactions, initial Photochemical Phenomenology Modeling Tool (PPMT) implementations are aimed at construction and evaluation of photochemical transport models with rapid execution for use in remote sensing data analysis activities in distributed systems. Current focus is on the Composite Infrared Spectrometer (CIRS) data acquired during the CASSINI flyby of Jupiter. Overall, the project has stayed on the development track outlined in the Year 1 annual report and most Year 2 goals have been met. The issues that have required the most attention are: implementation of the core photochemistry algorithms; implementation of a functional Java Graphical User Interface; completion of a functional CORBA Component Model framework; and assessment of performance issues. Specific accomplishments and the difficulties encountered are summarized in this report. Work to be carried out in the next year center on: completion of testing of the initial operational implementation; its application to analysis of the CASSINI/CIRS Jovian flyby data; extension of the PPMT to incorporate additional phenomenology algorithms; and delivery of a mature operational implementation.

Bishop, James↗

NASA NTRS2004

Safe Agents in Space: Lessons from the Autonomous Sciencecraft Experiment

An Autonomous Science Agent is currently flying onboard the Earth Observing One Spacecraft. This software enables the spacecraft to autonomously detect and respond to science events occurring on the Earth. The package includes software systems that perform science data analysis, deliberative planning, and run-time robust execution. Because of the deployment to a remote spacecraft, this Autonomous Science Agent has stringent constraints of autonomy, reliability, and limited computing resources. We describe these constraints and how they are reflected in our agent architecture.

Eatth Observing One Spacecraft↗

NASA NTRS1997

Tolerant (parallel) Programming

In order to be truly portable, a program must be tolerant of a wide range of development and execution environments, and a parallel program is just one which must be tolerant of a very wide range. This paper first defines the term "tolerant programming", then describes many layers of tools to accomplish it. The primary focus is on F-Nets, a formal model for expressing computation as a folded partial-ordering of operations, thereby providing an architecture-independent expression of tolerant parallel algorithms. For implementing F-Nets, Cooperative Data Sharing (CDS) is a subroutine package for implementing communication efficiently in a large number of environments (e.g. shared memory and message passing). Software Cabling (SC), a very-high-level graphical programming language for building large F-Nets, possesses many of the features normally expected from today's computer languages (e.g. data abstraction, array operations). Finally, L2(sup 3) is a CASE tool which facilitates the construction, compilation, execution, and debugging of SC programs.

DiNucci, David C.↗

DOE OSTI2024

Compiling Quantum Circuits for Dynamically Field-Programmable Neutral Atoms Array Processors

Dynamically field-programmable qubit arrays (DPQA) have recently emerged as a promising platform for quantum information processing. In DPQA, atomic qubits are selectively loaded into arrays of optical traps that can be reconfigured during the computation itself. Leveraging qubit transport and parallel, entangling quantum operations, different pairs of qubits, even those initially far away, can be entangled at different stages of the quantum program execution. Such reconfigurability and non-local connectivity present new challenges for compilation, especially in the layout synthesis step which places and routes the qubits and schedules the gates. In this paper, we consider a DPQA architecture that contains multiple arrays and supports 2D array movements, representing cutting-edge experimental platforms. Within this architecture, we discretize the state space and formulate layout synthesis as a satisfiability modulo theories problem, which can be solved by existing solvers optimally in terms of circuit depth. For a set of benchmark circuits generated by random graphs with complex connectivities, our compiler OLSQ-DPQA reduces the number of two-qubit entangling gates on small problem instances by 1.7x compared to optimal compilation results on a fixed planar architecture. To further improve scalability and practicality of the method, we introduce a greedy heuristic inspired by the iterative peeling approach in classical integrated circuit routing. Using a hybrid approach that combined the greedy and optimal methods, we demonstrate that our DPQA-based compiled circuits feature reduced scaling overhead compared to a grid fixed architecture, resulting in 5.1X less two-qubit gates for 90 qubit quantum circuits. These methods enable programmable, complex quantum circuits with neutral atom quantum computers, as well as informing both future compilers and future hardware choices.

Physics↗

NASA NTRS2003

Design for Verification: Using Design Patterns to Build Reliable Systems

Components so far have been mainly used in commercial software development to reduce time to market. While some effort has been spent on formal aspects of components, most of this was done in the context of programming language or operating system framework integration. As a consequence, increased reliability of composed systems is mainly regarded as a side effect of a more rigid testing of pre-fabricated components. In contrast to this, Design for Verification (D4V) puts the focus on component specific property guarantees, which are used to design systems with high reliability requirements. D4V components are domain specific design pattern instances with well-defined property guarantees and usage rules, which are suitable for automatic verification. The guaranteed properties are explicitly used to select components according to key system requirements. The D4V hypothesis is that the same general architecture and design principles leading to good modularity, extensibility and complexity/functionality ratio can be adapted to overcome some of the limitations of conventional reliability assurance measures, such as too large a state space or too many execution paths.

Mehlitz, Peter C.↗

NASA NTRS2006

A Discussion of the Discrete Fourier Transform Execution on a Typical Desktop PC

This paper will discuss and compare the execution times of three examples of the Discrete Fourier Transform (DFT). The first two examples will demonstrate the direct implementation of the algorithm. In the first example, the Fourier coefficients are generated at the execution of the DFT. In the second example, the coefficients are generated prior to execution and the DFT coefficients are indexed at execution. The last example will demonstrate the Cooley- Tukey algorithm, better known as the Fast Fourier Transform. All examples were written in C executed on a PC using a Pentium 4 running at 1.7 Ghz. As a function of N, the total complex data size, the direct implementation DFT executes, as expected at order of N2 and the FFT executes at order of N log2 N. At N=16K, there is an increase in processing time beyond what is expected. This is not caused by implementation but is a consequence of the effect that machine architecture and memory hierarchy has on implementation. This paper will include a brief overview of digital signal processing, along with a discussion of contemporary work with discrete Fourier processing.

White, Michael J.↗

NASA NTRS2004

Preliminary results of the autonomous sciencecraft experiment

The Autonomous Sciencecraft Experiment (ASE) will operate onboard the Earth Orbiter 1 mission in 2003. The ASE software uses onboard continuous planning, robust task and goal-based execution, and onboard machine learning and pattern recognition to radically increase science return by enabling intelligent downlink selection and autonomous retargeting. In this paper we discuss how these AI technologies are synergistically integrated in multilayer control architecture to enable a virtual spacecraft science agent.

Rabideau, Gregg↗

NASA NTRS1996

Development of a Computer Architecture to Support the Optical Plume Anomaly Detection (OPAD) System

The NASA OPAD spectrometer system relies heavily on extensive software which repetitively extracts spectral information from the engine plume and reports the amounts of metals which are present in the plume. The development of this software is at a sufficiently advanced stage where it can be used in actual engine tests to provide valuable data on engine operation and health. This activity will continue and, in addition, the OPAD system is planned to be used in flight aboard space vehicles. The two implementations, test-stand and in-flight, may have some differing requirements. For example, the data stored during a test-stand experiment are much more extensive than in the in-flight case. In both cases though, the majority of the requirements are similar. New data from the spectrograph is generated at a rate of once every 0.5 sec or faster. All processing must be completed within this period of time to maintain real-time performance. Every 0.5 sec, the OPAD system must report the amounts of specific metals within the engine plume, given the spectral data. At present, the software in the OPAD system performs this function by solving the inverse problem. It uses powerful physics-based computational models (the SPECTRA code), which receive amounts of metals as inputs to produce the spectral data that would have been observed, had the same metal amounts been present in the engine plume. During the experiment, for every spectrum that is observed, an initial approximation is performed using neural networks to establish an initial metal composition which approximates as accurately as possible the real one. Then, using optimization techniques, the SPECTRA code is repetitively used to produce a fit to the data, by adjusting the metal input amounts until the produced spectrum matches the observed one to within a given level of tolerance. This iterative solution to the original problem of determining the metal composition in the plume requires a relatively long period of time to execute the software in a modern single-processor workstation, and therefore real-time operation is currently not possible. A different number of iterations may be required to perform spectral data fitting per spectral sample. Yet, the OPAD system must be designed to maintain real-time performance in all cases. Although faster single-processor workstations are available for execution of the fitting and SPECTRA software, this option is unattractive due to the excessive cost associated with very fast workstations and also due to the fact that such hardware is not easily expandable to accommodate future versions of the software which may require more processing power. Initial research has already demonstrated that the OPAD software can take advantage of a parallel computer architecture to achieve the necessary speedup. Current work has improved the software by converting it into a form which is easily parallelizable. Timing experiments have been performed to establish the computational complexity and execution speed of major components of the software. This work provides the foundation of future work which will create a fully parallel version of the software executing in a shared-memory multiprocessor system.

Katsinis, Constantine↗

NASA NTRS2018

The OpenSE Cookbook: A Practical, Recipe Based Collection of Patterns, Procedures, and Best Practices for Executable Systems Engineering for the Thirty Meter Telescope

The OpenSE Cookbook is an open-sourced collection of patterns, procedures, and best practices targeted for systems engineers who seek guidance on applying model-based and executable systems engineering (MBSE) using SysML. Its content has emerged from the system level modeling effort on the European Framework Program 6 (FP6) and the Thirty Meter Telescope (TMT). The TMT MBSE approach applied the Executable Systems Engineering Method (ESEM) and the open-source Engineering Environment (OpenMBEE) to specify, analyze, and verify requirements of TMT’s Alignment and Phasing System (APS) and the Narrow Field Infrared Adaptive Optics System (NFIRAOS). In these applications, implicit dependencies are made explicit in a formal model through the use of ESEM, OpenMBEE, and SysML modeling constructs. The value proposition for applying this MBSE approach was to establish precise requirements and fine-grained traceability to system designs, and to verify key requirements beginning early in development. The integration of ESEM and the OpenMBEE tooling infrastructure (providing linked-data and web-operability) is a significant added value for the MBSE approach. The APS is responsible for the overall pre-adaptive optics wavefront quality, using starlight to measure wavefront errors and align the TMT optics. In the formally integrated and executable SysML model, simulations are performed to analyze the impact of changed requirements and verify specified constraints for various operational scenarios. The APS team used several modeling patterns to capture information such as the requirements, the operational scenarios, involved subsystems and their interaction points, the estimated or required time durations, and the mass and power consumption. Adaptive optics systems are designed to sense real-time atmospheric turbulence and correct the telescope’s optical beam to remove its effect. The system model for the adaptive optics operational modes was developed to capture sequence behaviors and operational scenarios to run Monte-Carlo simulations for verifying acquisition time, observing efficiency, and operational behavior requirements. The model is particularly useful for investigating the effect of parallelization, identifying interface issues, and re-ordering sequence acquisition tasks. A former version of the Cookbook (which is now updated to MBSE challenges, goals, and lessons learned) included modeling guidelines and conventions for all system aspects, hierarchy levels, and views, which were developed during for the Active Phasing Experiment (APE), an opto-mechatronical system technology demonstrator for the Extremely Large Telescope (ELT). The Cookbook utilizes the above mentioned system models as real-world case-studies to demonstrate and document the applications of the recipes, providing also instructional examples and addressing the available tooling support. The Cookbook is accompanied by a number of SysML models and aodel libraries which facilitate model authoring and maintenance. The Cookbook covers the different aspects of Systems Engineering such as management of Requirements, Design (behavior and structure), Interfaces, Interdisciplinary Integration, Analysis, Trade Studies, and Technical Resources. This paper presents the background, motivation, architecture, and highlights some key content of the Cookbook. For example, interface management, error budget management, requirements verification, Monte Carlo driven analysis, and timing analysis of operational scenarios. The paper discusses how the capabilities of OpenMBEE contributed significantly to the adoption of executable systems engineering.

Brower, Eric↗

NASA NTRS2004

The Role of Ontologies in Schema-based Program Synthesis

Program synthesis is the process of automatically deriving executable code from (non-executable) high-level specifications. It is more flexible and powerful than conventional code generation techniques that simply translate algorithmic specifications into lower-level code or only create code skeletons from structural specifications (such as UML class diagrams). Key to building a successful synthesis system is specializing to an appropriate application domain. The AUTOBAYES and AUTOFILTER systems, under development at NASA Ames, operate in the two domains of data analysis and state estimation, respectively. The central concept of both systems is the schema, a representation of reusable computational knowledge. This can take various forms, including high-level algorithm templates, code optimizations, datatype refinements, or architectural information. A schema also contains applicability conditions that are used to determine when it can be applied safely. These conditions can refer to the initial specification, to intermediate results, or to elements of the partially-instantiated code. Schema-based synthesis uses AI technology to recursively apply schemas to gradually refine a specification into executable code. This process proceeds in two main phases. A front-end gradually transforms the problem specification into a program represented in an abstract intermediate code. A backend then compiles this further down into a concrete target programming language of choice. A core engine applies schemas on the initial problem specification, then uses the output of those schemas as the input for other schemas, until the full implementation is generated. Since there might be different schemas that implement different solutions to the same problem this process can generate an entire solution tree. AUTOBAYES and AUTOFILTER have reached the level of maturity where they enable users to solve interesting application problems, e.g., the analysis of Hubble Space Telescope images. They are large (in total around 100kLoC Prolog), knowledge intensive systems that employ complex symbolic reasoning to generate a wide range of non-trivial programs for complex application do- mains. Their schemas can have complex interactions, which make it hard to change them in isolation or even understand what an existing schema actually does. Adding more capabilities by increasing the number of schemas will only worsen this situation, ultimately leading to the entropy death of the synthesis system. The root came of this problem is that the domain knowledge is scattered throughout the entire system and only represented implicitly in the schema implementations. In our current work, we are addressing this problem by making explicit the knowledge from Merent parts of the synthesis system. Here; we discuss how Gruber's definition of an ontology as an explicit specification of a conceptualization matches our efforts in identifying and explicating the domain-specific concepts. We outline the dual role ontologies play in schema-based synthesis and argue that they address different audiences and serve different purposes. Their first role is descriptive: they serve as explicit documentation, and help to understand the internal structure of the system. Their second role is prescriptive: they provide the formal basis against which the other parts of the system (e.g., schemas) can be checked. Their final role is referential: ontologies also provide semantically meaningful "hooks" which allow schemas and tools to access the internal state of the program derivation process (e.g., fragments of the generated code) in domain-specific rather than language-specific terms, and thus to modify it in a controlled fashion. For discussion purposes we use AUTOLINEAR, a small synthesis system we are currently experimenting with, which can generate code for solving a system of linear equations, Az = b.

Bures, Tomas↗

NASA NTRS2013

Scheduling Operations for Massive Heterogeneous Clusters

High-performance computing (HPC) programming has become increasingly difficult with the advent of hybrid supercomputers consisting of multicore CPUs and accelerator boards such as the GPU. Manual tuning of software to achieve high performance on this type of machine has been performed by programmers. This is needlessly difficult and prone to being invalidated by new hardware, new software, or changes in the underlying code. A system was developed for task-based representation of programs, which when coupled with a scheduler and runtime system, allows for many benefits, including higher performance and utilization of computational resources, easier programming and porting, and adaptations of code during runtime. The system consists of a method of representing computer algorithms as a series of data-dependent tasks. The series forms a graph, which can be scheduled for execution on many nodes of a supercomputer efficiently by a computer algorithm. The schedule is executed by a dispatch component, which is tailored to understand all of the hardware types that may be available within the system. The scheduler is informed by a cluster mapping tool, which generates a topology of available resources and their strengths and communication costs. Software is decoupled from its hardware, which aids in porting to future architectures. A computer algorithm schedules all operations, which for systems of high complexity (i.e., most NASA codes), cannot be performed optimally by a human. The system aids in reducing repetitive code, such as communication code, and aids in the reduction of redundant code across projects. It adds new features to code automatically, such as recovering from a lost node or the ability to modify the code while running. In this project, the innovators at the time of this reporting intend to develop two distinct technologies that build upon each other and both of which serve as building blocks for more efficient HPC usage. First is the scheduling and dynamic execution framework, and the second is scalable linear algebra libraries that are built directly on the former.

Humphrey, John↗

DOE OSTI2020

CSRI Summer Proceedings 2020

The Computer Science Research Institute (CSRI) brings university faculty and students to Sandia for focused collaborative research on Department of Energy (DOE) computer and computational science problems. The institute provides an opportunity for university researchers to learn about problems in computer and computational science at DOE laboratories. Participants conduct leading-edge research, interact with scientists and engineers at the laboratories, and help transfer results of their research to programs at the labs. Some specific CSRI research interest areas are: scalable solvers, optimization, adaptivity and mesh refinement, graph-based, discrete, and combinatorial algorithms, uncertainty estimation, mesh generation, dynamic load-balancing, virus and other malicious-code defense, visualization, scalable cluster computers, data-intensive computing, environments for scalable computing, parallel input/output, advanced architectures, and theoretical computer science. The CSRI Summer Program is organized by CSRI and typically includes the organization of a weekly seminar series and the publication of a summer proceedings. In 2020, the CSRI summer program was executed completely virtually; all student interns worked from home, due to the COVID-19 pandemic.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS2001

Summary of ADTT Website Functionality and Features

This report summarizes development of the ADTT web-based design environment by the ELORET team in 2000. The Advanced Design Technology Testbed had been in development for several years, with demonstration applications restricted to aerodynamic analyses of subsonic aircraft. The key changes achieved this year were improvements in Web-based accessibility, evaluation of collaborative visualization, remote invocation of geometry updates and performance analysis, and application to aerospace system analysis. Significant effort was also devoted to post-processing of data, chiefly through comparison of similar data for alternative vehicle concepts. Such comparison is an essential requirement for designers to make informed choices between alternatives. The next section of this report provides more discussion of the goals for ADTT development. Section 3 provides screen shots from a sample session in the ADTT environment, including Login and navigation to the project of interest, data inspection, analysis execution and output evaluation. The following section provides discussion of implementation details and recommendations for future development of the software and information technologies that provide the key functionality of the ADTT system. Section 5 discusses the integration architecture for the system, which links machines running different operating systems and provides unified access to data stored in distributed locations. Security is a significant issue for this system, especially for remote access to NAS machines, so Section 6 discusses several architectural considerations with respect to security. Additional details of some aspects of ADTT development are included in Appendices.

Hawke, Veronica↗

NASA NTRS2006

Architecture for Control of the K9 Rover

Software featuring a multilevel architecture is used to control the hardware on the K9 Rover, which is a mobile robot used in research on robots for scientific exploration and autonomous operation in general. The software consists of five types of modules: Device Drivers - These modules, at the lowest level of the architecture, directly control motors, cameras, data buses, and other hardware devices. Resource Managers - Each of these modules controls several device drivers. Resource managers can be commanded by either a remote operator or the pilot or conditional-executive modules described below. Behaviors and Data Processors - These modules perform computations for such functions as planning paths, avoiding obstacles, visual tracking, and stereoscopy. These modules can be commanded only by the pilot. Pilot - The pilot receives a possibly complex command from the remote operator or the conditional executive, then decomposes the command into (1) more-specific commands to the resource managers and (2) requests for information from the behaviors and data processors. Conditional Executive - This highest-level module interprets a command plan sent by the remote operator, determines whether resources required for execution of the plan are available, monitors execution, and, if necessary, selects an alternate branch of the plan.

Bresina, John L.↗

NASA NTRS2016

Design and Execution of Dawn HAMO to LAMO Transfer at Ceres

On October 23, 2015, the Dawn spacecraft left the High Altitude Mapping Orbit (HAMO) around Ceres and began its final decent to the Low Altitude Mapping Orbit (LAMO), arriving on December 15. The transfer between the two science orbits, a tight spiraling trajectory with over 100 revolutions, required the operations team to perform weekly maneuver designs for a period of 50 days. While the first six weeks of the transfer executed as planned, unexpectedly the spacecraft incurred a multi-sigma delivery error to the final science orbit that was subsequently clean-up at the first orbit maintenance maneuver. In this paper we discuss the design architecture for the transfer in detail, including challenges the team faced in flying the transfer and lessons learned.

Grebow, Daniel J.↗

NASA NTRS2016

Design and Execution of Dawn HAMO to LAMO Transfer at Ceres

Grebow, Dan↗

NASA NTRSDate not supplied

NASA Gateway Refueling Architecture and Concept of Operation

The Lunar Gateway is a deep space orbiting outpost being developed by NASA in partnership with ESA and other domestic and international partners. It is a critical component of NASA’s Artemis program supporting long-term human exploration of the moon and is designed to be refueled, requiring the on-orbit transfer of propellants. The first two modules of Gateway to be launched will be the Power and Propulsion Element (PPE) and the Habitation and Logistics Outpost (HALO). The PPE contains the bipropellant chemical and electrical propulsion systems that will provide attitude control and orbit raising capability for Gateway. The reaction control system (RCS) utilizes monomethylhydrazine (MMH) and mixed oxides of nitrogen-3 (MON-3) as the fuel and oxidizer, respectively. Helium is used as a pressurant. The Advanced Electric Propulsion Systems (AEPS) and Busek hall thrusters that comprise the solar electric propulsion (SEP) system use xenon as the propellent. The ESPRIT Refueling Module, provided by ESA, will supply the propellant refueling function to Gateway’s propulsion systems. On-orbit refueling is a complex, technically challenging operation that is key to enabling sustainable crewed Lunar and Martian exploration. Numerous systems may be involved in the refueling operation. Also numerous systems are required to enable the successful ability for Gateway to refuel such as, SEP, RCS, Structure & Mechanisms (S&M), Guidance, Navigation and Control (GNC), Thermal, Software, Vehicle System Manager (VSM), Flight Ops, Extra Vehicular Robotics (EVR), Communication and Tracking (C&T), Avionics, and more. This paper will detail the design architecture, concept of operations, and challenges associated with the Gateway refueling system. The methodologies used in Gateway will be compared to those implemented in OSAM-1 and the best practices documented by AIAA and CONFERS (Consortium For Execution Of Rendezvous And Servicing Operations).

Brandie L. Rhodes↗

DOE OSTI2022

Snowmass Computational Frontier: Topical Group Report on Experimental Algorithm Parallelization

The substantial increase in data volume and complexity expected from future experiments will require significant investment to prepare experimental algorithms. These algorithms include physics object reconstruction, calibrations, and processing of observational data. In addition, the changing computing architecture landscape, which will be primarily composed of heterogeneous resources, will continue to pose major challenges with regard to algorithmic migration. Portable tools need to be developed that can be shared among the frontiers (e.g., for code execution on different platforms) and opportunities, such as forums or cross-experimental working groups, need to be provided where experiences and lessons learned can be shared between experiments and frontiers. At the same time, individual experiments also need to invest considerable resources to develop algorithms unique to their needs (e.g., for facilities dedicated to the experiment), and ensure that their specific algorithms will be able to efficiently exploit external heterogeneous computing facilities. Common software tools represent a cost-effective solution, providing ready-to-use software solutions as well as a platform for R&D work. These are particularly important for small experiments which typically do not have dedicated resources needed to face the challenges imposed by the evolving computing technologies. Workforce development is a key concern across frontiers and experiments, and additional support is needed to provide career opportunities for researchers working in the field of experimental algorithm development. Finally, cross-discipline collaborations going beyond high-energy physics are a key ingredient to address the challenges ahead and more support for such collaborations needs to be created. This report targets future experiments, observations and experimental algorithm development for the next 10-15 years.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗