SEARCH · Search NASA
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.
Parallel algorithm developed on multiple-microprocessor computer. Program initiated to develop computer codes capable of directly simulating and mathematically modeling transition process at mach numbers ranging from subsonic to hypersonic. Parallel computers potentially offer reduction of processing time; processing time inversely proportional to number of available processors.
Methods for controlling states of interacting superconducting flux qubits using power-efficient devices of fast single-quantum logic (Josephson nonlinearity cavities) are studied. One- and two-qubit quantum logical operations performed within the conventional control technique using Rabi pulses and using picosecond single unipolar magnetic field pulses are comparatively analyzed. It is shown that all main operations can be implemented with an accuracy of better than 97% due to optimization of the shape and parameters of unipolar control pulses (associated with, e.g., propagation of fluxons in transmission lines). The efficiency of the developed technique for programming a two-qubit quantum processor implementing the simplest Deutsch–Jozsa algorithm is demonstrated.
This paper discusses the use of Ada on distributed systems in which failure of processors has to be tolerated. It is assumed that communication between tasks on separate processors will take place using the facilities of the Ada language, primarily the rendezvous. It is shown that there are numerous aspects of the language which make its use on a distributed system very difficult. The issues are raised from the desire to be able to recover, reconfigure, and provide continued service in the presence of hardware failure. For example, if a rendezvous takes place between two tasks on different processors, failure of the processor executing the serving task will cause the calling task to be permanently suspended because the rendezvous will never end. Extensive modifications to the execution support required for Ada are proposed which provide all the necessary facilities for programs written in Ada to withstand arbitrary processor failure. Mechanisms are suggested to allow processor failure to be detected and for tasks which would be permanently suspended to be released. Provided the required program structures are used, continued processing can be provided.
Writing efficient parallel programs is complicated by the need to select the right data structure alignments and distributions, which determine the nature and volume of inter-processor communications. A large number of performance tools for parallel programs have been developed recently to expose these inter-processor communications. However, none of them support performance views or provide statistics in terms of inter-processor data structure interactions. A performance tool that tracks the interaction between individual data structures and the context of these interactions is essential for understanding the performance of both explicit message passing programs and data-parallel languages such as HPF. In this paper we discuss the use of compiler front end tools for automatically tracking data structure movements in message passing programs, and low-overhead monitoring and postprocessing of such codes. We demonstrate that robust instrumentation and low overhead monitoring of inter-processor data structure movements is possible, with the use of a number of NAS benchmark codes, run on the i860 hypercube. We also show that the data so collected can be used effectively by post processing tools that expose performance bottlenecks using graphical displays and performance statistics.
Improving programming capability of onboard processing system and reducing control circuitry of computer processing unit
Phxtelemproc is a C/C++ based telemetry processing program that processes SFDU telemetry packets from the Telemetry Data System (TDS). It generates Experiment Data Records (EDRs) for several instruments including surface stereo imager (SSI); robotic arm camera (RAC); robotic arm (RA); microscopy, electrochemistry, and conductivity analyzer (MECA); and the optical microscope (OM). It processes both uncompressed and compressed telemetry, and incorporates unique subroutines for the following compression algorithms: JPEG Arithmetic, JPEG Huffman, Rice, LUT3, RA, and SX4. This program was in the critical path for the daily command cycle of the Phoenix mission. The products generated by this program were part of the RA commanding process, as well as the SSI, RAC, OM, and MECA image and science analysis process. Its output products were used to advance science of the near polar regions of Mars, and were used to prove that water is found in abundance there. Phxtelemproc is part of the MIPL (Multi-mission Image Processing Laboratory) system. This software produced Level 1 products used to analyze images returned by in situ spacecraft. It ultimately assisted in operations, planning, commanding, science, and outreach.
The applicability of a parallel computing architecture to the solution of a large-scale moment-method code is investigated. Specifically, the NEC (Numerical Electromagnetics Code) method-of-moments scattering program is implemented on a hypercube parallel processor. The accuracy and the increase in the speed of execution on this parallel architecture are demonstrated. The results show a very large reduction in execution time for large problems. The great potential of this parallel processor is shown for interactive solution of large NEC problems as well as other moment-method techniques such as the finite-element method.
This report gives the result from the Phase-1 work on demonstrating greater than 10x speedup of the Barracuda computer program using parallel methods and GPU processors (General-Purpose Graphics Processing Unit or Graphics Processing Unit). Phase-1 demonstrated a 12x speedup on a typical Barracuda function using the GPU processor. The problem test case used about 5 million particles and 250,000 Eulerian grid cells. The relative speedup, compared to a single CPU, increases with increased number of particles giving greater than 12x speedup. Phase-1 work provided a path for reformatting data structure modifications to give good parallel performance while keeping a friendly environment for new physics development and code maintenance. The implementation of data structure changes will be in Phase-2. Phase-1 laid the ground work for the complete parallelization of Barracuda in Phase-2, with the caveat that implemented computer practices for parallel programming done in Phase-1 gives immediate speedup in the current Barracuda serial running code. The Phase-1 tasks were completed successfully laying the frame work for Phase-2. The detailed results of Phase-1 are within this document. In general, the speedup of one function would be expected to be higher than the speedup of the entire code because of I/O functions and communication between the algorithms. However, because one of the most difficult Barracuda algorithms was parallelized in Phase-1 and because advanced parallelization methods and proposed parallelization optimization techniques identified in Phase-1 will be used in Phase-2, an overall Barracuda code speedup (relative to a single CPU) is expected to be greater than 10x. This means that a job which takes 30 days to complete will be done in 3 days. Tasks completed in Phase-1 are: Task 1: Profile the entire Barracuda code and select which subroutines are to be parallelized (See Section Choosing a Function to Accelerate) Task 2: Select a GPU consultant company and jointly parallelize subroutines (CPFD chose the small business EMPhotonics for the Phase-1 the technical partner. See Section Technical Objective and Approach) Task 3: Integrate parallel subroutines into Barracuda (See Section Results from Phase-1 and its subsections) Task 4: Testing, refinement, and optimization of parallel methodology (See Section Results from Phase-1 and Section Result Comparison Program) Task 5: Integrate Phase-1 parallel subroutines into Barracuda and release (See Section Results from Phase-1 and its subsections) Task 6: Roadmap of Phase-2 (See Section Plan for Phase-2) With the completion of Phase 1 we have the base understanding to completely parallelize Barracuda. An overview of the work to move Barracuda to a parallelized code is given in Plan for Phase-2.
A finite element based programming system for minimum weight design of a truss-type structure subjected to displacement, stress, and lower and upper bounds on design variables is presented. The programming system consists of a number of independent processors, each performing a specific task. These processors, however, are interfaced through a well-organized data base, thus making the tasks of modifying, updating, or expanding the programming system much easier in a friendly environment provided by many inexpensive personal computers. The proposed software can be viewed as an important step in achieving a 'dummy' finite element for optimization. The programming system has been implemented on both large and small computers (such as VAX, CYBER, IBM-PC, and APPLE) although the focus is on the latter. Examples are presented to demonstrate the capabilities of the code. The present programming system can be used stand-alone or as part of the multilevel decomposition procedure to obtain optimum design for very large scale structural systems. Furthermore, other related research areas such as developing optimization algorithms (or in the larger level: a structural synthesis program) for future trends in using parallel computers may also benefit from this study.
The issues involved in the use of the programming language Ada on distributed systems are discussed. The effects of Ada programs on hardware failures such as loss of a processor are emphasized. It is shown that many Ada language elements are not well suited to this environment. Processor failure can easily lead to difficulties on those processors which remain. As an example, the calling task in a rendezvous may be suspended forever if the processor executing the serving task fails. A mechanism for detecting failure is proposed and changes to the Ada run time support system are suggested which avoid most of the difficulties. Ada program structures are defined which allow programs to reconfigure and continue to provide service following processor failure.
USMC6 is a Fortran 90 computer program for post-processing in support of visualization of flows simulated by computational fluid dynamics (CFD). The name "USMC6" is partly an abbreviation of "TetrUSS - USM3D Solution Cutter," reflecting its origin as a post-processor for use with USM3D - a CFD program that is a component of the Tetrahedral Unstructured Software System and that solves the Navier-Stokes equations on tetrahedral unstructured grids. "Cutter" here refers to a capability to acquire and process solution data on (1) arbitrary planes that cut through grid volumes, or (2) user-selected spheroidal, conical, cylindrical, and/or prismatic domains cut from within grids. Cutting saves time by enabling concentration of post-processing and visualization efforts on smaller solution domains of interest. The user can select from among more than 40 flow functions. The cut planes can be trimmed to circular or rectangular shape. The user specifies cuts and functions in a free-format input file using simple and easy-to-remember keywords. The USMC6 command line is simple enough that the slicing process can readily be embedded in a shell script for assembly-line post-processing. The output of USMC6 is a data file ready for plotting.
This paper presents a transputer-based binary tree eigensolver for the solution of the generalized eigenproblem in linear elastic finite element analysis. The algorithm is based on the method of recursive doubling, which parallel implementation of a number of associative operations on an arbitrary set having N elements is of the order of o(log2N), compared to (N-1) steps if implemented sequentially. The hardware used in the implementation of the binary tree consists of 32 transputers. The algorithm is written in OCCAM which is a high-level language developed with the transputers to address parallel programming constructs and to provide the communications between processors. The algorithm can be replicated to match the size of the binary tree transputer network. Parallel and sequential finite element analysis programs have been developed to solve for the set of the least-order eigenpairs using the modified subspace method. The speed-up obtained for a typical analysis problem indicates close agreement with the theoretical prediction given by the method of recursive doubling.
The National Aeronautics and Space Administrations (NASA) Constellation Program is currently designing a new transportation system to replace the Space Shuttle, support human missions to both the International Space Station (ISS) and the Moon, and enable the eventual establishment of an outpost on the lunar surface. The present Constellation architecture is designed to meet nominal capability requirements and provide flexibility sufficient for handling a host of contingency scenarios including (but not limited to) launch delays at the Earth. This report summarizes a body of work performed in support of the Review of U.S. Human Space Flight Committee. It analyzes three lunar orbit rendezvous dual-launch architecture options which incorporate differing methodologies for mitigating the effects of launch delays at the Earth. NASA employed the recently-developed Mission Assessment Post Processor (MAPP) tool to quickly evaluate vehicle performance requirements for several candidate approaches for conducting human missions to the Moon. The MAPP tool enabled analysis of Earth perturbation effects and Earth-Moon geometry effects on the integrated vehicle performance as it varies over the 18.6-year lunar nodal cycle. Results are provided summarizing best-case and worst-case vehicle propellant requirements for each architecture option. Additionally, the associated vehicle payload mass requirements at launch are compared between each architecture and against those of the Constellation Program. The current Constellation Program architecture assumes that the Altair lunar lander and Earth Departure Stage (EDS) vehicles are launched on a heavy lift launch vehicle. The Orion Crew Exploration Vehicle (CEV) is separately launched on a smaller man-rated vehicle. This strategy relaxes man-rating requirements for the heavy lift launch vehicle and has the potential to significantly reduce the cost of the overall architecture over the operational lifetime of the program. The crew launch occurs first, four days prior to the optimal trans-lunar injection (TLI) departure window. This is done to allow for launch delays in the Altair/EDS launch. During this time, the Orion vehicle is required to conduct orbit maintenance while loitering in low Earth orbit (LEO). The alternative architectures presented aim to eliminate the need for costly orbit maintenance maneuvers while loitering in LEO. In all of the alternative architectures considered, it is assumed that the Altair and Orion vehicles are nominally launched 90 minutes apart, depart the Earth separately, and complete the rendezvous and docking sequence at the Moon. In this lunar orbit rendezvous (LOR) strategy, both the Altair and Orion vehicles will require separate EDS stages, and each will be required to perform lunar orbit insertion (LOI). This has the effect of balancing payload requirements between the two launch vehicles at the Earth. In this case, the overall payload mass is increased slightly, but the increased mission costs could potentially be offset by requiring the construction of two rockets similar in size and nature, unlike the current Constellation architecture. Three dual-launch architecture options with LOR were evaluated, which incorporate differing methodologies for mitigating the effects of launch delays at the Earth. Benefits and drawbacks of each of the dual-launch architecture options with LOR are discussed and the overall mission performance is compared with that of the existing Constellation Program lunar architecture.
The Planetary Observer Planning Software (POPS) comprises four computer programs for use in designing orbits of spacecraft about planets. These programs are the Planetary Observer High Precision Orbit Propagator (POHOP), the Planetary Observer Long-Term Orbit Predictor (POLOP), the Planetary Observer Post Processor (POPP), and the Planetary Observer Plotting (POPLOT) program. POHOP and POLOP integrate the equations of motion to propagate an initial set of classical orbit elements to a future epoch. POHOP models shortterm (one revolution) orbital motion; POLOP averages out the short-term behavior but requires far less processing time than do older programs that perform long-term orbit propagations. POPP postprocesses the spacecraft ephemeris created by POHOP or POLOP (or optionally can use a less accurate internal ephemeris) to search for trajectory-related geometric events including, for example, rising or setting of a spacecraft as observed from a ground site. For each such event, POPP puts out such user-specified data as the time, elevation, and azimuth. POPLOT is a graphics program that plots data generated by POPP. POPLOT can plot orbit ground tracks on a world map and can produce a variety of summaries and generic ordinate-vs.-abscissa plots of any POPP data.
The characteristics of power processors strongly impact the overall performance and cost of electric propulsion systems. A program was initiated to evaluate simplifications of the thruster-power processor interface requirements. The power processor requirements are mission dependent with major differences arising for those missions which require a nearly constant thruster operating point (typical of geocentric and some inbound planetary missions) and those requiring operation over a large range of input power (such as outbound planetary missions). This paper describes the results of tests which have indicated that as many as seven of the twelve power supplies may be eliminated from the present Functional Model Power Processor used with 30-cm diameter Hg ion thrusters.
Collector-Output Analysis Program (COAP) programmer's aid for analyzing output produced by UNIVAC collector (MAP processor). COAP developed to aid in design of segmentation structures for programs with large memory requirements and numerous elements but of value in understanding relationships among components of any program. Crossreference indexes and supplemental information produced. COAP written in FORTRAN 77.
We present massively parallel high energy electromagnetic particle transportation through a finely segmented detector on a Graphics Processing Unit (GPU). Simulating events of energetic particle decay in a general-purpose high energy physics (HEP) detector requires intensive computing resources, due to the complexity of the geometry as well as physics processes applied to particles copiously produced by primary collisions and secondary interactions. The recent advent of hardware architectures of many-core or accelerated processors provides the variety of concurrent programming models applicable not only for the high performance parallel computing, but also for the conventional computing intensive application such as the HEP detector simulation. The components of our prototype are a transportation process under a non-uniform magnetic field, geometry navigation with a set of solid shapes and materials, electromagnetic physics processes for electrons and photons, and an interface to a framework that dispatches bundles of tracks in a highly vectorized manner optimizing for spatial locality and throughput. Core algorithms and methods are excerpted from the Geant4 toolkit, and are modified and optimized for the GPU application. Program kernels written in C/C++ are designed to be compatible with CUDA and OpenCL and with the aim to be generic enough for easy porting to future programming models and hardware architectures. To improve throughput by overlapping data transfers with kernel execution, multiple CUDA streams are used. Issues with floating point accuracy, random numbers generation, data structure, kernel divergences and register spills are also considered. Performance evaluation for the relative speedup compared to the corresponding sequential execution on CPU is presented as well.
Apollo network remote site computer systems