Results for “execution time” — Page 89

NASA NTRS1998

Martian Meteorology: Determination of Large Scale Weather Patterns from Surface Measurements

We employed numerical modelling of the martian atmosphere, and our expertise in understanding martian atmospheric processes, to better understand the coupling between lower and upper atmosphere processes. One practical application of this work has been our involvement with the ongoing atmospheric aerobraking which the Mars Global Surveyor (MGS) spacecraft is currently undergoing at Mars. Dr. Murphy is currently a member of the Mars Global Surveyor (MGS) Aerobraking Atmospheric Advisory Group (AAG). He was asked to participate in this activity based upon his knowledge of martian atmospheric dynamical processes. Aerobraking is a process whereby a spacecraft, in an elliptical orbit, passes through the upper layers of the atmosphere (in this instance Mars). This passage through the atmosphere 'drags' upon the spacecraft, gradually reducing its orbital velocity. This has the effect, over time, of converting the elliptical orbit to a circular orbit, which is the desired mapping orbit for MGS. Carrying out aerobraking eliminates the need for carrying large amounts of fuel on the spacecraft to execute an engine burn to achieve the desired orbit. Eliminating the mass of the fuel reduces the cost of launch. Damage to one of MGS's solar panels shortly after launch has resulted in a less aggressive extended in time aerobraking phase which will not end until March, 1999. Phase 1 extended from Sept. 1997 through March 1998. During this time period, Dr. Murphy participated almost daily in the AAG meetings, and beginning in December 1997 lead the meeting several times per week. The leader of each of the daily AAG meetings took the results of that meeting current state of the atmosphere, identification of any time trends or spatial patterns in upper atmosphere densities, etc.) forward to the Aerobraking Planning Group (APG) meeting, at which time the decision was made to not chance MGS orbit, to lower the orbit to reach higher densities (greater 'drag'), or raise the orbit to avoid experiencing excessive, possibly damaging densities.

Murphy, James R.↗

NASA NTRS1998

Martian Meteorology: Determination of Large Scale Weather Patterns from Surface Measurements

We employed numerical modelling of the martian atmosphere, and our expertise in understanding martian atmospheric processes, to better understand the coupling between lower and upper atmosphere processes. One practical application of this work has been our involvement with the ongoing atmospheric aerobraking which the Mars Global Surveyor (MGS) spacecraft is currently undergoing at Mars. Dr. Murphy is currently a member of the Mars Global Surveyor (MGS) Aerobraking Atmospheric Advisory Group (AAG). He was asked to participate in this activity based upon his knowledge of martian atmospheric dynamical processes. Aerobraking is a process whereby a spacecraft, in an elliptical orbit, passes through the upper layers of the atmosphere (in this instance Mars). This passage through the atmosphere 'drags'upon the spacecraft, gradually reducing its orbital velocity. This has the effect, over time, of converting the elliptical orbit to a circular orbit, which is the desired mapping orbit for MGS. Carrying out aerobraking eliminates the need for carrying large amounts of fuel on the spacecraft to execute an engine burn to achieve the desired orbit. Eliminating the mass of the fuel reduces the cost of launch. Damage to one of MGS's solar panels shortly after launch has resulted in a less aggressive extended in time aerobraking phase which will not end until March, 1999. Phase I extended from Sept. 1997 through March 1998. During this time period, Dr. Murphy participated almost daily in the AAG meetings, and beginning in December 1997 lead the meeting several times per week. The leader of each of the daily AAG meetings took the results of that meeting (current state of the atmosphere, identification of any time trends or spatial patterns in upper atmosphere densities, etc.) forward to the Aerobraking Planning Group (APG) meeting, at which time the decision was made to not change MGS orbit, to lower the orbit to reach higher densities (greater 'drag'), or raise the orbit to avoid experiencing excessive, possibly damaging densities.

Murphy, James R.↗

DOE OSTI2023

Dancing the Quantum Waltz: Compiling Three-Qubit Gates on Four Level Architectures

Superconducting quantum devices are a leading technology for quantum computation, but they face several challenges. Gate errors, coherence errors and a lack of connectivity all contribute to low fidelity results. In particular, connectivity restrictions enforce a gate set that requires three-qubit gates to be decomposed into one- or two-qubit gates. This substantially increases the number of two-qubit gates that need to be executed. However, many quantum devices have access to higher energy levels. We can expand the qubit abstraction of |0〉 and |1〉 to a ququart which has access to the |2〉 and |3〉 state, but with shorter coherence times. This allows for two qubits to be encoded in one ququart, enabling increased virtual connectivity between physical units from two adjacent qubits to four fully connected qubits. This connectivity scheme allows us to more efficiently execute three-qubit gates natively between two physical devices.We present direct-to-pulse implementations of several three-qubit gates, synthesized via optimal control, for compilation of three-qubit gates onto a superconducting-based architecture with access to four-level devices with the first experimental demonstration of four-level ququart gates designed through optimal control. We demonstrate strategies that temporarily use higher level states to perform Toffoli gates and always use higher level states to improve fidelities for quantum circuits. We find that these methods improve expected fidelities with increases of 2x across circuit sizes using intermediate encoding, and increases of 3x for fully-encoded ququart compilation.

Litteken, Andrew↗

DOE OSTI2017

Divide and Conquer (DC) BLAST: fast and easy BLAST execution within HPC environments

Bioinformatics is currently faced with very large-scale data sets that lead to computational jobs, especially sequence similarity searches, that can take absurdly long times to run. For example, the National Center for Biotechnology Information (NCBI) Basic Local Alignment Search Tool (BLAST and BLAST+) suite, which is by far the most widely used tool for rapid similarity searching among nucleic acid or amino acid sequences, is highly central processing unit (CPU) intensive. While the BLAST suite of programs perform searches very rapidly, they have the potential to be accelerated. In recent years, distributed computing environments have become more widely accessible and used due to the increasing availability of high-performance computing (HPC) systems. Therefore, simple solutions for data parallelization are needed to expedite BLAST and other sequence analysis tools. However, existing software for parallel sequence similarity searches often requires extensive computational experience and skill on the part of the user. In order to accelerate BLAST and other sequence analysis tools, Divide and Conquer BLAST (DCBLAST) was developed to perform NCBI BLAST searches within a cluster, grid, or HPC environment by using a query sequence distribution approach. Scaling from one (1) to 256 CPU cores resulted in significant improvements in processing speed. Thus, DCBLAST dramatically accelerates the execution of BLAST searches using a simple, accessible, robust, and parallel approach. DCBLAST works across multiple nodes automatically and it overcomes the speed limitation of single-node BLAST programs. DCBLAST can be used on any HPC system, can take advantage of hundreds of nodes, and has no output limitations. Thus, this freely available tool simplifies distributed computation pipelines to facilitate the rapid discovery of sequence similarities between very large data sets.

59 BASIC BIOLOGICAL SCIENCES↗

DOE OSTI2017

Build and Execute Environment

At exascale, the challenge becomes to develop applications that run at scale and use exascale platforms reliably, efficiently, and flexibly. Workflows become much more complex because they must seamlessly integrate simulation and data analytics. They must include down-sampling, post-processing, feature extraction, and visualization. Power and data transfer limitations require these analysis tasks to be run in-situ or in-transit. We expect successful workflows will comprise multiple linked simulations along with tens of analysis routines. Users will have limited development time at scale and, therefore, must have rich tools to develop, debug, test, and deploy applications. At this scale, successful workflows will compose linked computations from an assortment of reliable, well-defined computation elements, ones that can come and go as required, based on the needs of the workflow over time. We propose a novel framework that utilizes both virtual machines (VMs) and software containers to create a workflow system that establishes a uniform build and execution environment (BEE) beyond the capabilities of current systems. In this environment, applications will run reliably and repeatably across heterogeneous hardware and software. Containers, both commercial (Docker and Rocket) and open-source (LXC and LXD), define a runtime that isolates all software dependencies from the machine operating system. Workflows may contain multiple containers that run different operating systems, different software, and even different versions of the same software. We will run containers in open-source virtual machines (KVM) and emulators (QEMU) so that workflows run on any machine entirely in user-space. On this platform of containers and virtual machines, we will deliver workflow software that provides services, including repeatable execution, provenance, checkpointing, and future proofing. We will capture provenance about how containers were launched and how they interact to annotate workflows for repeatable and partial re-execution. We will coordinate the physical snapshots of virtual machines with parallel programming constructs, such as barriers, to automate checkpoint and restart. We will also integrate with HPC-specific container runtimes to gain access to accelerators and other specialized hardware to preserve native performance. Containers will link development to continuous integration. When application developers check code in, it will automatically be tested on a suite of different software and hardware architectures.

Guan, Qiang↗

DOE OSTI2017

Build and Execute Environment

At exascale, the challenge becomes to develop applications that run at scale and use exascale platforms reliably, efficiently, and flexibly. Workflows become much more complex because they must seamlessly integrate simulation and data analytics. They must include down-sampling, post-processing, feature extraction, and visualization. Power and data transfer limitations require these analysis tasks to be run in-situ or in-transit. We expect successful workflows will comprise multiple linked simulations along with tens of analysis routines. Users will have limited development time at scale and, therefore, must have rich tools to develop, debug, test, and deploy applications. At this scale, successful workflows will compose linked computations from an assortment of reliable, well-defined computation elements, ones that can come and go as required, based on the needs of the workflow over time. We propose a novel framework that utilizes both virtual machines (VMs) and software containers to create a workflow system that establishes a uniform build and execution environment (BEE) beyond the capabilities of current systems. In this environment, applications will run reliably and repeatably across heterogeneous hardware and software. Containers, both commercial (Docker and Rocket) and open-source (LXC and LXD), define a runtime that isolates all software dependencies from the machine operating system. Workflows may contain multiple containers that run different operating systems, different software, and even different versions of the same software. We will run containers in open-source virtual machines (KVM) and emulators (QEMU) so that workflows run on any machine entirely in user-space. On this platform of containers and virtual machines, we will deliver workflow software that provides services, including repeatable execution, provenance, checkpointing, and future proofing. We will capture provenance about how containers were launched and how they interact to annotate workflows for repeatable and partial re-execution. We will coordinate the physical snapshots of virtual machines with parallel programming constructs, such as barriers, to automate checkpoint and restart. We will also integrate with HPC-specific container runtimes to gain access to accelerators and other specialized hardware to preserve native performance. Containers will link development to continuous integration. When application developers check code in, it will automatically be tested on a suite of different software and hardware architectures.

Guan, Qiang↗

NASA NTRS2009

Cooperative Three-Robot System for Traversing Steep Slopes

Teamed Robots for Exploration and Science in Steep Areas (TRESSA) is a system of three autonomous mobile robots that cooperate with each other to enable scientific exploration of steep terrain (slope angles up to 90 ). Originally intended for use in exploring steep slopes on Mars that are not accessible to lone wheeled robots (Mars Exploration Rovers), TRESSA and systems like TRESSA could also be used on Earth for performing rescues on steep slopes and for exploring steep slopes that are too remote or too dangerous to be explored by humans. TRESSA is modeled on safe human climbing of steep slopes, two key features of which are teamwork and safety tethers. Two of the autonomous robots, denoted Anchorbots, remain at the top of a slope; the third robot, denoted the Cliffbot, traverses the slope. The Cliffbot drives over the cliff edge supported by tethers, which are payed out from the Anchorbots (see figure). The Anchorbots autonomously control the tension in the tethers to counter the gravitational force on the Cliffbot. The tethers are payed out and reeled in as needed, keeping the body of the Cliffbot oriented approximately parallel to the local terrain surface and preventing wheel slip by controlling the speed of descent or ascent, thereby enabling the Cliffbot to drive freely up, down, or across the slope. Due to the interactive nature of the three-robot system, the robots must be very tightly coupled. To provide for this tight coupling, the TRESSA software architecture is built on a combination of (1) the multi-robot layered behavior-coordination architecture reported in "An Architecture for Controlling Multiple Robots" (NPO-30345), NASA Tech Briefs, Vol. 28, No. 10 (October 2004), page 65, and (2) the real-time control architecture reported in "Robot Electronics Architecture" (NPO-41784), NASA Tech Briefs, Vol. 32, No. 1 (January 2008), page 28. The combination architecture makes it possible to keep the three robots synchronized and coordinated, to use data from all three robots for decision- making at each step, and to control the physical connections among the robots. In addition, TRESSA (as in prior systems that have utilized this architecture) , incorporates a capability for deterministic response to unanticipated situations from yet another architecture reported in Control Architecture for Robotic Agent Command and Sensing (NPO-43635), NASA Tech Briefs, Vol. 32, No. 10 (October 2008), page 40. Tether tension control is a major consideration in the design and operation of TRESSA. Tension is measured by force sensors connected to each tether at the Cliffbot. The direction of the tension (both azimuth and elevation) is also measured. The tension controller combines a controller to counter gravitational force and an optional velocity controller that anticipates the motion of the Cliffbot. The gravity controller estimates the slope angle from the inclination of the tethers. This angle and the weight of the Cliffbot determine the total tension needed to counteract the weight of the Cliffbot. The total needed tension is broken into components for each Anchorbot. The difference between this needed tension and the tension measured at the Cliffbot constitutes an error signal that is provided to the gravity controller. The velocity controller computes the tether speed needed to produce the desired motion of the Cliffbot. Another major consideration in the design and operation of TRESSA is detection of faults. Each robot in the TRESSA system monitors its own performance and the performance of its teammates in order to detect any system faults and prevent unsafe conditions. At startup, communication links are tested and if any robot is not communicating, the system refuses to execute any motion commands. Prior to motion, the Anchorbots attempt to set tensions in the tethers at optimal levels for counteracting the weight of the Cliffbot; if either Anchorbot fails to reach its optimal tension level within a specified time, it sends message to the other robots and the commanded motion is not executed. If any mechanical error (e.g., stalling of a motor) is detected, the affected robot sends a message triggering stoppage of the current motion. Lastly, messages are passed among the robots at each time step (10 Hz) to share sensor information during operations. If messages from any robot cease for more than an allowable time interval, the other robots detect the communication loss and initiate stoppage.

Stroupe, Ashley↗

NASA NTRS1988

Automatic programming for critical applications

The important phases of a software life cycle include verification and maintenance. Usually, the execution performance is an expected requirement in a software development process. Unfortunately, the verification and the maintenance of programs are the time consuming and the frustrating aspects of software engineering. The verification cannot be waived for the programs used for critical applications such as, military, space, and nuclear plants. As a consequence, synthesis of programs from specifications, an alternative way of developing correct programs, is becoming popular. The definition, or what is understood by automatic programming, has been changed with our expectations. At present, the goal of automatic programming is the automation of programming process. Specifically, it means the application of artificial intelligence to software engineering in order to define techniques and create environments that help in the creation of high level programs. The automatic programming process may be divided into two phases: the problem acquisition phase and the program synthesis phase. In the problem acquisition phase, an informal specification of the problem is transformed into an unambiguous specification while in the program synthesis phase such a specification is further transformed into a concrete, executable program.

Loganantharaj, Raj L.↗

NASA NTRS2004

Spacecraft Attitude Maneuver Planning Using Genetic Algorithms

A key enabling technology that leads to greater spacecraft autonomy is the capability to autonomously and optimally slew the spacecraft from and to different attitudes while operating under a number of celestial and dynamic constraints. The task of finding an attitude trajectory that meets all the constraints is a formidable one, in particular for orbiting or fly-by spacecraft where the constraints and initial and final conditions are of time-varying nature. This approach for attitude path planning makes full use of a priori constraint knowledge and is computationally tractable enough to be executed onboard a spacecraft. The approach is based on incorporating the constraints into a cost function and using a Genetic Algorithm to iteratively search for and optimize the solution. This results in a directed random search that explores a large part of the solution space while maintaining the knowledge of good solutions from iteration to iteration. A solution obtained this way may be used as is or as an initial solution to initialize additional deterministic optimization algorithms. A number of representative case examples for time-fixed and time-varying conditions yielded search times that are typically on the order of minutes, thus demonstrating the viability of this method. This approach is applicable to all deep space and planet Earth missions requiring greater spacecraft autonomy, and greatly facilitates navigation and science observation planning.

Kornfeld, Richard P.↗

NASA NTRS2014

Re-Engineering the ISS Payload Operations Control Center During Increased Utilization and Critical Onboard Events

With an increase in utilization and hours of payload operations being executed onboard the International Space Station (ISS), upgrading the NASA Marshall Space Flight Center (MSFC) Huntsville Operations Support Center (HOSC) ISS Payload Control Area (PCA) was essential to gaining efficiencies and assurance of current and future payload health and science return. PCA houses the Payload Operations Integration Center (POIC) responsible for the execution of all NASA payloads onboard the ISS. POIC Flight Controllers are responsible for the operation of voice, stowage, command, telemetry, video, power, thermal, and environmental control in support of ISS science experiments. The methodologies and execution of the PCA refurbishment were planned and performed within a four-month period in order to assure uninterrupted operation of ISS payloads and minimal impacts to payload operations teams. To vacate the PCA, three additional HOSC control rooms were reconfigured to handle ISS real-time operations, Backup Control Center (BCC) to Mission Control in Houston, simulations, and testing functions. This involved coordination and cooperation from teams of ISS operations controllers, multiple engineering and design disciplines, management, and construction companies performing an array of activities simultaneously and in sync delivering a final product with no issues that impacted the schedule. For each console operator discipline, studies of Information Technology (IT) tools and equipment layouts, ergonomics, and lines of sight were performed. Infusing some of the latest IT into the project was an essential goal in ensuring future growth and success of the ISS payload science returns. Engineering evaluations led to a state of the art Video Wall implementation and more efficient ethernet cabling distribution providing the latest products and the best solution for the POIC. These engineering innovations led to cost savings for the project. Constraints involved in the management of the project included executing over 450 crew-hours of ISS real-time payload operations including a major onboard communications upgrade, SpaceX un-berth, a Soyuz launch, roll-out of ISS live video and interviews from the POIC, annual BCC certification and hurricane season, and ISS simulations and testing. Continuous ISS payload operations were possible during the PCA facility modifications with the reconfiguration of four control rooms and standup of two temporary control areas. Another major restriction to the project was an ongoing facility upgrade that included a NASA Headquarters mandated replacement of all electrical and mechanical systems and replacement of an external generator. These upgrades required a facility power outage during the PCA upgrades. The project also encompassed console layout designs and ordering, amenities selections and ordering, excessing of old equipment, moves, disposal of old IT equipment, camera installations, facility tour re-schedules, and contract justifications. These were just some of the tasks needed for a successful project. This paper describes the logistics and lessons learned in upgrading a control center capability in the middle of complex real-time operations. Combining the efficiencies of controller interaction and new technology infusion were prime drivers for this upgrade to handle the increased utilization of science research on ISS. The success of this project could not jeopardize the current operations while these facility upgrades occurred.

Dudley, Stephanie R. B.↗

NASA NTRS1991

Rule-based simulation models

Procedural modeling systems, rule based modeling systems, and a method for converting a procedural model to a rule based model are described. Simulation models are used to represent real time engineering systems. A real time system can be represented by a set of equations or functions connected so that they perform in the same manner as the actual system. Most modeling system languages are based on FORTRAN or some other procedural language. Therefore, they must be enhanced with a reaction capability. Rule based systems are reactive by definition. Once the engineering system has been decomposed into a set of calculations using only basic algebraic unary operations, a knowledge network of calculations and functions can be constructed. The knowledge network required by a rule based system can be generated by a knowledge acquisition tool or a source level compiler. The compiler would take an existing model source file, a syntax template, and a symbol table and generate the knowledge network. Thus, existing procedural models can be translated and executed by a rule based system. Neural models can be provide the high capacity data manipulation required by the most complex real time models.

Nieten, Joseph L.↗

DOE OSTI2016

NEAMS-IPL MOOSE Framework Activities

The Multiapp Picard iteration Milestone’s purpose was to support a framework level “tight-coupling” method within the hierarchical Multiapp’s execution scheme. This new solution scheme gives developers new choices for running multiphysics applications, particularly those with very strong nonlinear effects or those requiring coupling across disparate time or spatial scales. Figure 1 shows a typical Multiapp setup in MOOSE. Each node represents a separate simulation containing a separate equation system. MOOSE solves the equation system on each node in turn, in a user-controlled manner. Information can be aggregated or split and transferred from parent to child or child to parent as needed between solves. Performing a tightly coupled execution scheme using this method wasn’t possible in the original implementation. This is was due to the inability to back up to a previous state once a converged solution was accepted at a particular Multiapp level.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS2024

Analysis of Hybrid Electric Aircraft Operations in the National Airspace System

This paper investigates the fuel burn and flight time impacts of hybrid electric aircraft operating in the National Airspace System. Future scenarios with hybrid electric flights and the same passenger travel capacity between city pairs as a baseline scenario, taken from historical data, were created. Aircraft that serviced select flights in the baseline scenario were replaced with hybrid electric aircraft based on the flight’s range and seat capacity. Additional hybrid electric flights were added to future scenarios when necessary to keep the future scenario passenger capacity equal or greater to that of the baseline scenario. The baseline and future scenarios were simulated in the NAS Digital Twin, a live, virtual, and constructive environment for building and executing simulations of the Nation Airspace System. Results showed that the future scenarios with hybrid electric flights saved fuel burn, but increased flight time. In the future scenarios, the additional hybrid electric flights did not cause any airports to exceed their operational capacity.

Simulation↗

NASA NTRSDate not supplied

Operating Hybrid Electric Aircraft in the National Airspace System

This paper investigates the fuel burn and flight time impacts of hybrid electric aircraft operating in the National Airspace System. Future scenarios with hybrid electric flights and the same passenger travel capacity between city pairs as a baseline scenario, taken from historical data, were created. Aircraft that serviced select flights in the baseline scenario were replaced with hybrid electric aircraft based on the flight’s range and seat capacity. Additional hybrid electric flights were added to future scenarios when necessary to keep the future scenario passenger capacity equal or greater to that of the baseline scenario. The baseline and future scenarios were simulated in the NAS Digital Twin, a live, virtual, and constructive environment for building and executing simulations of the Nation Airspace System. Results showed that the future scenarios with hybrid electric flights saved fuel burn, but increased flight time. In the future scenarios, the additional hybrid electric flights did not cause any airports to exceed their operational capacity.

hybrid electric aircraft↗

DOE OSTI2018

Planning of distributed data production for High Energy and Nuclear Physics

Modern experiments in High Energy and Nuclear Physics heavily rely on distributed computations using multiple computational facilities across the world. One of the essential types of the computations is a distributed data production where petabytes of raw files from a single source has to be processed once (per production campaign) using thousands of CPUs at distant locations and the output has to be transferred back to that source. The data distribution over a large system does not necessary match the distribution of storage, network and CPU capacity. Therefore, bottlenecks may appear and lead to increased latency and degraded performance. In this paper we propose a new scheduling approach for distributed data production which is based on the network flow maximization model. In our approach a central planner defines how much input and output data should be transferred over each network link in order to maximize the computational throughput. Such plans are created periodically for a fixed planning time interval using up-to-date information on network, storage and CPU resources. The centrally created plans are executed in a distributed manner by dedicated services running at participating sites. In conclusion, our simulations based on the log records from the data production framework of the experiment STAR (Solenoid Tracker at RHIC) have shown that the proposed model systematically provides a better performance compared to the simulated traditional techniques.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

DOE OSTI2023

Quantum Noise Mitigation: Introducing the Robust Quantum Circuit Scheduler for Enhanced Fidelity and Throughput

Undoubtedly, quantum computing offers valuable acceleration for solving intricate problems. One of the primary hurdles lies in executing large-scale quantum applications on backend machines. Qubit noise, among other factors, dramatically influences the execution process. Implementing effective scheduling techniques for quantum circuits is crucial for practical quantum computing and preventing excessive waiting times. The quantum realm is distinct from classical computing in terms of optimization, performance, utilization, and waiting periods. Consequently, the parameters and components of quantum circuit scheduling diverge from those of classical computing. This paper presents Quantum Noise Mitigation: Introducing the Robust Quantum Circuit Scheduler for Enhanced Fidelity and Throughput, a straightforward yet effective scheduling framework and policy that enhances noise resilience, throughput, and the fidelity of quantum circuits. Drawing inspiration from classical methods, our scheduling approach incorporates additional constraints tailored for quantum logic. The outcome demonstrates a substantial improvement in fidelity and resource management, which is vital for real-world quantum applications.

Baheri, Betis↗

DOE OSTI2019

Hawaii Play Fairway: Preliminary Core Box Photos, Lanai Island, Hawaii

Photos of core samples from Lanai Island. During the third phase of the Hawaii Play Fairway project, further exploration involved drilling a groundwater well in Lanai's Palawai Basin and performing more geophysical surveys. The project deepened an existing water well on Lanai. Drilling occurred 24/7 the entire month of June 2019 over which time Lanai Well 10 was deepened from 427 m to 1057 m, with continuous core collected. The roughly linear temperature gradient was an average of 42 degC/km, and a maximum bottom hole temperature, 66 degC. This gradient is more than twice the background for Hawaii and within a range of gradients measured in this depth range for some exploration wells within KERZ. The Hawaii Play Fairway project seeks to explore the geologic structures that exist in the caldera region of Hawaiian volcanoes; how those structures influence groundwater storage and flow; and how the magmatic heat from Hawaiian shield volcanoes cools over time. The Hawaii Groundwater and Geothermal Resources Center (Hawaii Institute of Geophysics and Planetology, University of Hawaii at Manoa) executed the Hawaii Play Fairway project. For more information, go to HGGRC's website that is linked in the resources.

15 GEOTHERMAL ENERGY↗

NASA NTRS1971

Lunar mission safety and rescue: Executive summary

An executive summary is presented of the escape/rescue and the hazards analyses for manned missions and operations in the 1980 time frame. The method of approach, basic data generated, and significant results are outlined, and highlights of the two analyses are given. Areas in which research or technical development efforts could improve mission safety, and specific suggestions for additional effort studies on safety analyses are listed.

Source record↗