SEARCH · Engineering Papers

Results for “IMPLEMENTATION”

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 325 records · Page 18

All sources NASA NTRS DOE OSTI

NASA NTRS2007

Systems Modeling to Implement Integrated System Health Management Capability

ISHM capability includes: detection of anomalies, diagnosis of causes of anomalies, prediction of future anomalies, and user interfaces that enable integrated awareness (past, present, and future) by users. This is achieved by focused management of data, information and knowledge (DIaK) that will likely be distributed across networks. Management of DIaK implies storage, sharing (timely availability), maintaining, evolving, and processing. Processing of DIaK encapsulates strategies, methodologies, algorithms, etc. focused on achieving high ISHM Functional Capability Level (FCL). High FCL means a high degree of success in detecting anomalies, diagnosing causes, predicting future anomalies, and enabling health integrated awareness by the user. A model that enables ISHM capability, and hence, DIaK management, is denominated the ISHM Model of the System (IMS). We describe aspects of the IMS that focus on processing of DIaK. Strategies, methodologies, and algorithms require proper context. We describe an approach to define and use contexts, implementation in an object-oriented software environment (G2), and validation using actual test data from a methane thruster test program at NASA SSC. Context is linked to existence of relationships among elements of a system. For example, the context to use a strategy to detect leak is to identify closed subsystems (e.g. bounded by closed valves and by tanks) that include pressure sensors, and check if the pressure is changing. We call these subsystems Pressurizable Subsystems. If pressure changes are detected, then all members of the closed subsystem become suspect of leakage. In this case, the context is defined by identifying a subsystem that is suitable for applying a strategy. Contexts are defined in many ways. Often, a context is defined by relationships of function (e.g. liquid flow, maintaining pressure, etc.), form (e.g. part of the same component, connected to other components, etc.), or space (e.g. physically close, touching the same common element, etc.). The context might be defined dynamically (if conditions for the context appear and disappear dynamically) or statically. Although this approach is akin to case-based reasoning, we are implementing it using a software environment that embodies tools to define and manage relationships (of any nature) among objects in a very intuitive manner. Context for higher level inferences (that use detected anomalies or events), primarily for diagnosis and prognosis, are related to causal relationships. This is useful to develop root-cause analysis trees showing an event linked to its possible causes and effects. The innovation pertaining to RCA trees encompasses use of previously defined subsystems as well as individual elements in the tree. This approach allows more powerful implementations of RCA capability in object-oriented environments. For example, if a pressurizable subsystem is leaking, its root-cause representation within an RCA tree will show that the cause is that all elements of that subsystem are suspect of leak. Such a tree would apply to all instances of leak-events detected and all elements in all pressurizable subsystems in the system. Example subsystems in our environment to build IMS include: Pressurizable Subsystem, Fluid-Fill Subsystem, Flow-Thru-Valve Subsystem, and Fluid Supply Subsystem. The software environment for IMS is designed to potentially allow definition of any relationship suitable to create a context to achieve ISHM capability.

Figueroa, Jorge F.↗

NASA NTRS2007

A One Chip Hardened Solution for High Speed SpaceWire System Implementations. Session: Components

An Application Specific Integrated Circuit (ASIC) that implements the SpaceWire protocol has been developed in a radiation hardened 0.25 micron CMOS technology. This effort began in March 2003 as a joint development between the NASA Goddard Space Flight Center (GSFC) and BAE Systems. The BAE Systems SpaceWire ASIC is comprised entirely of reusable core elements, many of which are already flight-proven. It incorporates a router with 4 SpaceWire ports and two local ports, dual PC1 bus interfaces, a microcontroller, 32KB of internal memory, and a memory controller for additional external memory use. The SpaceWire cores are also reused in other ASICs under development. The SpaceWire ASIC is planned for use on the Geostationary Operational Environmental Satellites (GOES)-R, the Lunar Reconnaissance Orbiter (LRO) and other missions. Engineering and flight parts have been delivered to programs and users. This paper reviews the SpaceWire protocol and those elements of it that have been built into the current and next SpaceWire reusable cores and features within the core that go beyond the current standard and can be enabled or disabled by the user. The adaptation of SpaceWire to BAE Systems' On Chip Bus (OCB) for compatibility with the other reusable cores will be reviewed and highlighted. Optional configurations within user systems and test boards will be shown. The physical implementation of the design will be described and test results from the hardware will be discussed. Application of this ASIC and other ASICs containing the SpaceWire cores and embedded microcontroller to Plug and Play and reconfigurable implementations will be described. Finally, the BAE Systems roadmap for SpaceWire developments will be updated, including some products already in design as well as longer term plans.

Marshall, Joseph R.↗

NASA NTRS2010

Integrated System Health Management: Pilot Operational Implementation in a Rocket Engine Test Stand

This paper describes a credible implementation of integrated system health management (ISHM) capability, as a pilot operational system. Important core elements that make possible fielding and evolution of ISHM capability have been validated in a rocket engine test stand, encompassing all phases of operation: stand-by, pre-test, test, and post-test. The core elements include an architecture (hardware/software) for ISHM, gateways for streaming real-time data from the data acquisition system into the ISHM system, automated configuration management employing transducer electronic data sheets (TEDS?s) adhering to the IEEE 1451.4 Standard for Smart Sensors and Actuators, broadcasting and capture of sensor measurements and health information adhering to the IEEE 1451.1 Standard for Smart Sensors and Actuators, user interfaces for management of redlines/bluelines, and establishment of a health assessment database system (HADS) and browser for extensive post-test analysis. The ISHM system was installed in the Test Control Room, where test operators were exposed to the capability. All functionalities of the pilot implementation were validated during testing and in post-test data streaming through the ISHM system. The implementation enabled significant improvements in awareness about the status of the test stand, and events and their causes/consequences. The architecture and software elements embody a systems engineering, knowledge-based approach; in conjunction with object-oriented environments. These qualities are permitting systematic augmentation of the capability and scaling to encompass other subsystems.

Figueroa, Fernando↗

NASA NTRS2010

Delay/Disruption Tolerance Networking (DTN) Implementation and Utilization Options on the International Space Station

The International Space Station (ISS) is in an operational configuration and nearing final assembly. With its maturity and diverse payloads onboard, the opportunity exists to extend the orbital lab into a facility to exercise and demonstrate Delay/Disruption Tolerant Networking (DTN). DTN is an end-to-end network service providing communications through environments characterized by intermittent connectivity, variable delays, high bit error rates, asymmetric links and simplex links. The DTN protocols, also known as bundle protocols, provide a store-and-forward capability to accommodate end-to-end network services. Key capabilities of the bundling protocols include: the Ability to cope with intermittent connectivity, the Ability to take advantage of scheduled and opportunistic connectivity (in addition to always up connectivity), Custody Transfer, and end-to-end security. Colorado University at Boulder and the Huntsville Operational Support Center (HOSC) have been developing a DTN capability utilizing the Commercial Generic Bioprocessing Apparatus (CGBA) payload resources onboard the ISS, at the Boulder Payload Operations Center (POC) and at the HOSC. The DTN capability is in parallel with and is designed to augment current capabilities. The architecture consists of DTN endpoint nodes on the ISS and at the Boulder POC, and a DTN node at the HOSC. The DTN network is composed of two implementations; the Interplanetary Overlay Network (ION) and the open source DTN2 implementation. This paper presents the architecture, implementation, and lessons learned. By being able to handle the types of environments described above, the DTN technology will be instrumental in extending networks into deep space to support future missions to other planets and other solar system points of interest. Thus, this paper also discusses how this technology will be applicable to these types of deep space exploration missions.

Holbrook, Mark↗

NASA NTRS2010

DTN Implementation and Utilization Options on the International Space Station

This slide presentation reviews the implementation and future uses of Delay/Disruption Tolerant Networking (DTN) for space communication, using the International Space Station as the primary example. The presentation includes: (1) A brief introduction of the current communications architecture of the ISS (2) How current payload operations are handled in the non-DTN environment (3) Making the case to implement DTN into the current payload science operations model (4) Phase I DTN Operations: early implementation with BioServe's CGBA Payload (5) Phase II DTN Operations: Developing the HOSC DTN Gateway

Nichols, Kelvin↗

NASA NTRS2009

Integrated System Health Management: Foundational Concepts, Approach, and Implementation

A sound basis to guide the community in the conception and implementation of ISHM (Integrated System Health Management) capability in operational systems was provided. The concept of "ISHM Model of a System" and a related architecture defined as a unique Data, Information, and Knowledge (DIaK) architecture were described. The ISHM architecture is independent of the typical system architecture, which is based on grouping physical elements that are assembled to make up a subsystem, and subsystems combine to form systems, etc. It was emphasized that ISHM capability needs to be implemented first at a low functional capability level (FCL), or limited ability to detect anomalies, diagnose, determine consequences, etc. As algorithms and tools to augment or improve the FCL are identified, they should be incorporated into the system. This means that the architecture, DIaK management, and software, must be modular and standards-based, in order to enable systematic augmentation of FCL (no ad-hoc modifications). A set of technologies (and tools) needed to implement ISHM were described. One essential tool is a software environment to create the ISHM Model. The software environment encapsulates DIaK, and an infrastructure to focus DIaK on determining health (detect anomalies, determine causes, determine effects, and provide integrated awareness of the system to the operator). The environment includes gateways to communicate in accordance to standards, specially the IEEE 1451.1 Standard for Smart Sensors and Actuators.

Figueroa, Fernando↗

NASA NTRS2009

Implementation and Comparison of Acoustic Travel-Time Measurement Procedures for the Helioseismic and Magnetic Imager Time-Distance Helioseismology Pipeline

The Helioseismic and Magnetic Imager (HMI) instrument on board the Solar Dynamics Observatory (SDO) satellite is designed to produce high-resolution Doppler velocity maps of oscillations at the solar surface with high temporal cadence. To take advantage of these high-quality oscillation data, a time-distance helioseismology pipeline has been implemented at the Joint Science Operations Center (JSOC) at Stanford University. The aim of this pipeline is to generate maps of acoustic travel times from oscillations on the solar surface, and to infer subsurface 3D flow velocities and sound-speed perturbations. The wave travel times are measured from cross covariances of the observed solar oscillation signals. For implementation into the pipeline we have investigated three different travel-time definitions developed in time-distance helioseismology: a Gabor wavelet fitting (Kosovichev and Duvall, 1997), a minimization relative to a reference cross-covariance function (Gizon and Birch, 2002), and a linearized version of the minimization method (Gizon and Birch, 2004). Using Doppler velocity data from the Michelson Doppler Imager (MDI) instrument on board SOHO, we tested and compared these definitions for the mean and difference travel-time perturbations measured from reciprocal signals. Although all three procedures return similar travel times in a quiet Sun region, the method of Gizon and Birch (2004) gives travel times that are significantly different from the others in a magnetic (active) region. Thus, for the pipeline implementation we chose the procedures of Kosovichev and Duvall (1997) and Gizon and Birch (2002). We investigated the relationships among these three travel-time definitions, their sensitivities to fitting parameters, and estimated the random errors they produce

Couvidat, S.↗

NASA NTRS2010

High-Performance CCSDS Encapsulation Service Implementation in FPGA

The Consultative Committee for Space Data Systems (CCSDS) Encapsulation Service is a convergence layer between lower-layer space data link framing protocols, such as CCSDS Advanced Orbiting System (AOS), and higher-layer networking protocols, such as CFDP (CCSDS File Delivery Protocol) and Internet Protocol Extension (IPE). CCSDS Encapsulation Service is considered part of the data link layer. The CCSDS AOS implementation is described in the preceding article. Recent advancement in RF modem technology has allowed multi-megabit transmission over space links. With this increase in data rate, the CCSDS Encapsulation Service needs to be optimized to both reduce energy consumption and operate at a high rate. CCSDS Encapsulation Service has been implemented as an intellectual property core so that the aforementioned problems are solved by way of operating the CCSDS Encapsulation Service inside an FPGA. The CCSDS En capsula tion Service in FPGA implementation consists of both packetizing and de-packetizing features

Clare, Loren P.↗

NASA NTRS2010

Design and Implementation of the Boundary Layer Transition Flight Experiment on Space Shuttle Discovery

In an effort to better the understanding of high speed aerodynamics, a series of flight experiments were installed on Space Shuttle Discovery during the STS-119 and STS-128 missions. This experiment, known as the Boundary Layer Transition Flight Experiment (BLTFE), provided the technical community with actual entry flight data from a known height protuberance at Mach numbers at and above Mach 15. Any such data above Mach 15 is irreproducible in a laboratory setting. Years of effort have been invested in obtaining this valuable data, and many obstacles had to be overcome in order to ensure the success of implementing an Orbiter modification. Many Space Shuttle systems were involved in the installation of appropriate components that revealed 'concurrent engineering' was a key integration tool. This allowed the coordination of all various parts and pieces which had to be sequenced appropriately and installed at the right time. Several issues encountered include Orbiter configuration and access, design requirements versus current layout, implementing the modification versus typical processing timelines, and optimizing the engineering design cycles and changes. Open lines of communication within the entire modification team were essential to project success as the team was spread out across the United States, from NASA Kennedy Space Center in Florida, to NASA Johnson Space Center in Texas, to Boeing Huntington Beach, California among others. The forum permits the discussion of processing concerns from the design phase to the implementation phase, which eventually saw the successful flights and data acquisition on STS-119 in March 2009 and on STS-128 in September 2009.

Spanos, Theodoros A.↗

NASA NTRS2004

Digital Radar-Signal Processors Implemented in FPGAs

High-performance digital electronic circuits for onboard processing of return signals in an airborne precipitation- measuring radar system have been implemented in commercially available field-programmable gate arrays (FPGAs). Previously, it was standard practice to downlink the radar-return data to a ground station for postprocessing a costly practice that prevents the nearly-real-time use of the data for automated targeting. In principle, the onboard processing could be performed by a system of about 20 personal- computer-type microprocessors; relative to such a system, the present FPGA-based processor is much smaller and consumes much less power. Alternatively, the onboard processing could be performed by an application-specific integrated circuit (ASIC), but in comparison with an ASIC implementation, the present FPGA implementation offers the advantages of (1) greater flexibility for research applications like the present one and (2) lower cost in the small production volumes typical of research applications. The generation and processing of signals in the airborne precipitation measuring radar system in question involves the following especially notable steps: The system utilizes a total of four channels two carrier frequencies and two polarizations at each frequency. The system uses pulse compression: that is, the transmitted pulse is spread out in time and the received echo of the pulse is processed with a matched filter to despread it. The return signal is band-limited and digitally demodulated to a complex baseband signal that, for each pulse, comprises a large number of samples. Each complex pair of samples (denoted a range gate in radar terminology) is associated with a numerical index that corresponds to a specific time offset from the beginning of the radar pulse, so that each such pair represents the energy reflected from a specific range. This energy and the average echo power are computed. The phase of each range bin is compared to the previous echo by complex conjugate multiplication to obtain the mean Doppler shift (and hence the mean and variance of the velocity of precipitation) of the echo at that range.

Berkun, Andrew↗

NASA NTRS2011

Asynchronous Message Service Reference Implementation

This software provides a library of middleware functions with a simple application programming interface, enabling implementation of distributed applications in conformance with the CCSDS AMS (Consultative Committee for Space Data Systems Asynchronous Message Service) specification. The AMS service, and its protocols, implement an architectural concept under which the modules of mission systems may be designed as if they were to operate in isolation, each one producing and consuming mission information without explicit awareness of which other modules are currently operating. Communication relationships among such modules are self-configuring; this tends to minimize complexity in the development and operations of modular data systems. A system built on this model is a society of generally autonomous, inter-operating modules that may fluctuate freely over time in response to changing mission objectives, modules functional upgrades, and recovery from individual module failure. The purpose of AMS, then, is to reduce mission cost and risk by providing standard, reusable infrastructure for the exchange of information among data system modules in a manner that is simple to use, highly automated, flexible, robust, scalable, and efficient. The implementation is designed to spawn multiple threads of AMS functionality under the control of an AMS application program. These threads enable all members of an AMS-based, distributed application to discover one another in real time, subscribe to messages on specific topics, and to publish messages on specific topics. The query/reply (client/server) communication model is also supported. Message exchange is optionally subject to encryption (to support confidentiality) and authorization. Fault tolerance measures in the discovery protocol minimize the likelihood of overall application failure due to any single operational error anywhere in the system. The multi-threaded design simplifies processing while enabling application nodes to operate at high speeds; linked lists protected by mutex semaphores and condition variables are used for efficient, inter-thread communication. Applications may use a variety of transport protocols underlying AMS itself, including TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and message queues.

Burleigh, Scott C.↗

NASA NTRS2011

Licklider Transmission Protocol Implementation

This software is an implementation of the Licklider Transmission Protocol (LTP), a communications protocol intended to support the Bundle Protocol in Delay-Tolerant Network (DTN) operations. LTP is designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times and/or frequent interruptions in connectivity. Communication in interplanetary space is the most prominent example of this sort of environment, and LTP is principally aimed at supporting long-haul reliable transmission over deep-space RF links. Like any reliable transport service employing ARQ (Automatic Repeat re-Quests), LTP is stateful. In order to assure the reception of a block of data it has sent, LTP must retain for possible retransmission all portions of that block which might not have been received yet. In order to do so, it must keep track of which portions of the block are known to have been received so far, and which are not, together with any additional information needed for purposes of retransmitting part, or all, of the block. Long round-trip times mean substantial delay between the transmission of a block of data and the reception of an acknowledgement from the block s destination, signaling arrival of the block. If LTP postponed transmission of additional blocks of data until it received acknowledgement of the arrival of all prior blocks, valuable opportunities to use what little deep space transmission bandwidth is available would be forever lost. For this reason, LTP is based in part on a notion of massive state retention. Any number of requested transmission conversations (sessions) may be concurrently in flight at various displacements along the link between two LTP engines, and the LTP engines must necessarily retain transmission status and retransmission resources for all of them. Moreover, if any of the data of a given block are lost en route, it will be necessary to retain the state of that transmission during an additional round trip while the lost data are retransmitted; even multiple retransmission cycles may be necessary. LTP's possible multiplicity of sessions per association makes it necessary for each segment of application data to include an additional demultiplexing token: a session ID that uniquely identifies the session in which the segment was issued and, implicitly, the block of data being conveyed by this session. This software comprises a prototype implementation developed by Johns Hopkins University APL in cooperation with JPL, together with adaptations that improve the robustness, correctness, and operability of that implementation.

Burleigh, Scott C.↗

NASA NTRS2012

Recursive Implementations of the Consider Filter

One method to account for parameters errors in the Kalman filter is to consider their effect in the so-called Schmidt-Kalman filter. This work addresses issues that arise when implementing a consider Kalman filter as a real-time, recursive algorithm. A favorite implementation of the Kalman filter as an onboard navigation subsystem is the UDU formulation. A new way to implement a UDU consider filter is proposed. The non-optimality of the recursive consider filter is also analyzed, and a modified algorithm is proposed to overcome this limitation.

Zanetti, Renato↗

NASA NTRS2011

Design and Implementation of a Mechanical Control System for the Scanning Microwave Limb Sounder

The Scanning Microwave Limb Sounder (SMLS) will use technological improvements in low noise mixers to provide precise data on the Earth's atmospheric composition with high spatial resolution. This project focuses on the design and implementation of a real time control system needed for airborne engineering tests of the SMLS. The system must coordinate the actuation of optical components using four motors with encoder readback, while collecting synchronized telemetric data from a GPS receiver and 3-axis gyrometric system. A graphical user interface for testing the control system was also designed using Python. Although the system could have been implemented with a FPGA-based setup, we chose to use a low cost processor development kit manufactured by XMOS. The XMOS architecture allows parallel execution of multiple tasks on separate threads-making it ideal for this application and is easily programmed using XC (a subset of C). The necessary communication interfaces were implemented in software, including Ethernet, with significant cost and time reduction compared to an FPGA-based approach. For these reasons, the XMOS technology is an attractive, cost effective, alternative to FPGA-based technologies for this design and similar rapid prototyping projects.

Mars Science Laboratory Robotics↗

NASA NTRS2011

An Examination of Selected Datacom Options for the Near-Term Implementation of Trajectory Based Operations

A primary feature of the Next Generation Air Transportation System (NextGen) is trajectory based operations (TBO). Under TBO, aircraft flight plans are known to computer systems on the ground that aid in scheduling and separation. The Future Air Navigation System (FANS) was developed to support TBO, but relatively few aircraft in the US are FANSequipped. Thus, any near-term implementation must provide TBO procedures for non-FANS aircraft. Previous research has explored controller clearances, but any implementation must also provide procedures for aircraft requests. The work presented here aims to surface issues surrounding TBO communication procedures for non-FANS aircraft and for aircraft requesting deviations around weather. Three types of communication were explored: Voice, FANS, and ACARS,(Aircraft Communications Addressing and Reporting System). ACARS and FANS are datacom systems that differ in that FANS allows uplinked flight plans to be loaded into the Flight Management System (FMS), while ACARS delivers flight plans as text that must be entered manually via the Control Display Unit (CDU). Sixteen pilots (eight two-person flight decks) and four controllers participated in 32 20-minute scenarios that required the flight decks to navigate through convective weather as they approached their top of descents (TODs). Findings: The rate of non-conformance was higher than anticipated, with aircraft off path more than 20% of the time. Controllers did not differentiate between the ACARS and FANS datacom, and were mixed in their preference for Voice vs. datacom (ACARS and FANS). Pilots uniformly preferred Voice to datacom, particularly ACARS. Much of their dislike appears to result from the slow response times in the datacom conditions. As a result, participants frequently resorted to voice communication. These results imply that, before implementing TBO in environments where pilots make weather deviation requests, further research is needed to develop communication procedures that integrate voice and datacom.

trajectory based operations↗

NASA NTRS2010

Implementation and Comparison of Acoustic Travel-Time Measurement Procedures for the Solar Dynamics Observatory-Helioseismic and Magnetic Imager Time-Distance Helioseismology Pipeline

The Helioseismic and Magnetic Imager (HMI) instrument onboard the Solar Dynamics Observatory (SDO) satellite is designed to produce high-resolution Doppler-velocity maps of oscillations at the solar surface with high temporal cadence. To take advantage of these high-quality oscillation data, a time - distance helioseismology pipeline (Zhao et al., Solar Phys. submitted, 2010) has been implemented at the Joint Science Operations Center (JSOC) at Stanford University. The aim of this pipeline is to generate maps of acoustic travel times from oscillations on the solar surface, and to infer subsurface 3D flow velocities and sound-speed perturbations. The wave travel times are measured from cross-covariances of the observed solar oscillation signals. For implementation into the pipeline we have investigated three different travel-time definitions developed in time - distance helioseismology: a Gabor-wavelet fitting (Kosovichev and Duvall, SCORE'96: Solar Convection and Oscillations and Their Relationship, ASSL, Dordrecht, 241, 1997), a minimization relative to a reference cross-covariance function (Gizon and Birch, Astrophys. J. 571, 966, 2002), and a linearized version of the minimization method (Gizon and Birch, Astrophys. J. 614, 472, 2004). Using Doppler-velocity data from the Michelson Doppler Imager (MDI) instrument onboard SOHO, we tested and compared these definitions for the mean and difference traveltime perturbations measured from reciprocal signals. Although all three procedures return similar travel times in a quiet-Sun region, the method of Gizon and Birch (Astrophys. J. 614, 472, 2004) gives travel times that are significantly different from the others in a magnetic (active) region. Thus, for the pipeline implementation we chose the procedures of Kosovichev and Duvall (SCORE'96: Solar Convection and Oscillations and Their Relationship, ASSL, Dordrecht, 241, 1997) and Gizon and Birch (Astrophys. J. 571, 966, 2002). We investigated the relationships among these three travel-time definitions, their sensitivities to fitting parameters, and estimated the random errors that they produce.

HMI↗

NASA NTRS2015

Real-Time Kennedy Space Center and Cape Canaveral Air Force Station High-Resolution Model Implementation and Verification

NASA's Launch Services Program, Ground Systems Development and Operations, Space Launch System and other programs at Kennedy Space Center (KSC) and Cape Canaveral Air Force Station (CCAFS) use the daily and weekly weather forecasts issued by the 45th Weather Squadron (45 WS) as decision tools for their day-to-day and launch operations on the Eastern Range (ER). Examples include determining if they need to limit activities such as vehicle transport to the launch pad, protect people, structures or exposed launch vehicles given a threat of severe weather, or reschedule other critical operations. The 45 WS uses numerical weather prediction models as a guide for these weather forecasts, particularly the Air Force Weather Agency (AFWA) 1.67 km Weather Research and Forecasting (WRF) model. Considering the 45 WS forecasters' and Launch Weather Officers' (LWO) extensive use of the AFWA model, the 45 WS proposed a task at the September 2013 Applied Meteorology Unit (AMU) Tasking Meeting requesting the AMU verify this model. Due to the lack of archived model data available from AFWA, verification is not yet possible. Instead, the AMU proposed to implement and verify the performance of an ER version of the high-resolution WRF Environmental Modeling System (EMS) model configured by the AMU (Watson 2013) in real time. Implementing a real-time version of the ER WRF-EMS would generate a larger database of model output than in the previous AMU task for determining model performance, and allows the AMU more control over and access to the model output archive. The tasking group agreed to this proposal; therefore the AMU implemented the WRF-EMS model on the second of two NASA AMU modeling clusters. The AMU also calculated verification statistics to determine model performance compared to observational data. Finally, the AMU made the model output available on the AMU Advanced Weather Interactive Processing System II (AWIPS II) servers, which allows the 45 WS and AMU staff to customize the model output display on the AMU and Range Weather Operations (RWO) AWIPS II client computers and conduct real-time subjective analyses.

Meteorology↗

NASA NTRS2015

Impact of Improvements in Volcanic Implementation on Atmospheric Chemistry and Climate in the GISS-E2 Model

The representation of volcanic eruptions in climate models introduces some of the largest errors when evaluating historical simulations, partly due to the crude model parameterizations. We will show preliminary results from the Goddard Institute for Space Studies (GISS)-E2 model comparing traditional highly parameterized volcanic implementation (specified Aerosol Optical Depth, Effective Radius) to deploying the full aerosol microphysics module MATRIX and directly emitting SO2 allowing us the prognosically determine the chemistry and climate impact. We show a reasonable match in aerosol optical depth, effective radius, and forcing between the full aerosol implementation and reconstructions/observations of the Mt. Pinatubo 1991 eruption, with a few areas as targets for future improvement. This allows us to investigate not only the climate impact of the injection of volcanic aerosols, but also influences on regional water vapor, O3, and OH distributions. With the skill of the MATRIX volcano implementation established, we explore (1) how the height of the injection column of SO2 influence atmospheric chemistry and climate response, (2) how the initial condition of the atmosphere influences the climate and chemistry impact of the eruption with a particular focus on how ENSO and QBO and (3) how the coupled chemistry could mitigate the climate signal for much larger eruptions (i.e. the 1258 eruption, reconstructed to be approximately 10x Pinatubo). During each sensitivity experiment we assess the impact on profiles of water vapor, O3, and OH, and assess how the eruption impacts the budget of each.

aerosols↗