Search NASA⌕ Search

SEARCH · Search NASA

Results for “Separation Service”

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.

754 records · Page 42
All sourcesNASA NTRSDOE OSTI
NASA NTRS1995

Prototype development and test results of a continuous ambient air monitoring system for hydrazine at the 10 ppb level

A Hydrazine Vapor Area Monitor (HVAM) system is currently being field tested as a detector for the presence of hydrazine in ambient air. The MDA/Polymetron Hydrazine Analyzer has been incorporated within the HVAM system as the core detector. This analyzer is a three-electrode liquid analyzer typically used in boiler feed water applications. The HVAM system incorporates a dual-phase sample collection/transport method which simultaneously pulls ambient air samples containing hydrazine and a very dilute sulfuric acid solution (0.0001 M) down a length of 1/4 inch outside diameter (OD) tubing from a remote site to the analyzer. The hydrazine-laden dilute acid stream is separated from the air and the pH is adjusted by addition of a dilute caustic solution to a pH greater than 10.2 prior to analysis. Both the dilute acid and caustic used by the HVAM are continuously generated during system operation on an "as needed" basis by mixing a metered amount of concentrated acid/base with dilution water. All of the waste water generated by the analyzer is purified for reuse by Barnstead ion-exchange cartridges so that the entire system minimizes the generation of waste materials. The pumping of all liquid streams and mixing of the caustic solution and dilution water with the incoming sample are done by a single pump motor fitted with the appropriate mix of peristaltic pump heads. The signal to noise (S/N) ratio of the analyzer has been enhanced by adding a stirrer in the MDA liquid cell to provide mixing normally generated by the high liquid flow rate designed by the manufacturer. An onboard microprocessor continuously monitors liquid levels, sample vacuum, and liquid leak sensors, as well as handles communications and other system functions (such as shut down should system malfunctions or errors occur). The overall system response of the HVAM can be automatically checked at regular intervals by measuring the analyzer response to a metered amount of calibration standard injected into the dilute acid stream. The HVAM system provides two measurement ranges (threshold limit value (TLV): 10 to 1000 parts per billion (ppb)/LEAK: 100 ppb to 10 parts per million (ppm)). The LEAK range is created by dilution of the sulfuric acid/hydrazine liquid sample with pure water. This dual range capability permits the analyzer to quantify ambient air samples whose hydrazine concentrations range from 10 ppb to as high as 10 ppm. The laboratory and field prototypes have demonstrated total system response times on the order of 10 to 12 minutes for samples ranging from 10 to 900 ppb in the lLV mode and is greater than 2 minutes for samples ranging from 100 to 1300 ppb in the LEAK mode. Service intervals of over 3 months have been demonstrated for continuous 24 hour/day, 7 day/week usage. The HVAM is made up of a purged cabinet that contains power supplies, RS422 signal transmission capabilities, a UPS, an on-site warning system, and a Line Replaceable Unit (LRU). The LRU includes all of the liquid flow system, the analyzer, the control/data system microprocessor and assorted flow and liquid-level sensors. The LRU is mounted on a track slide system so it can be serviced inplace or totally removed and quickly exchanged with another calibrated unit, thus minimizing analyzer downtime. Once an LRU is removed from an analyzer enclosure, it can be brought to a laboratory facility for complete calibration and periodic maintenance.

Meneghelli, Barry↗
NASA NTRS2008

NASA's Ares I and Ares V Launch Vehicles -- Effective Space Operations Through Efficient Ground Operations

The United States (U.S.) plans to return to the Moon by 2020, with the development of a new human-rated space transportation system to replace the Space Shuttle, which is due for retirement in 2010 after it completes its missions of building the International Space Station and servicing the Hubble Space Telescope. Powering the future of space-based scientific exploration will be the Ares I Crew Launch Vehicle, which will transport the Orion Crew Exploration Vehicle to orbit where it will rendezvous with the Lunar Lander. which will be delivered by the Ares V Cargo Launch Vehicle. This new transportation infrastructure, developed by the National Aeronautics and Space Administration (NASA), will allow astronauts to leave low-Earth orbit for extended lunar exploration and preparation for the first footprint on Mars. All space-based operations begin and are controlled from Earth. NASA's philosophy is to deliver safe, reliable, and cost-effective solutions to sustain a multi-billion-dollar program across several decades. Leveraging 50 years of lessons learned, NASA is partnering with private industry, while building on proven hardware experience. This paper will discuss how the Engineering Directorate at NASA's Marshall Space Flight Center is working with the Ares Projects Office to streamline ground operations concepts and reduce costs. Currently, NASA's budget is around $17 billion, which is less than 1 percent of the U.S. Federal budget. Of this amount, NASA invests approximately $4.5 billion each year in Space Shuttle operations, regardless of whether the spacecraft is flying or not. The affordability requirement is for the Ares I to reduce this expense by 50 percent, in order to allow NASA to invest more in space-based scientific operations. Focusing on this metric, the Engineering Directorate provides several solutions-oriented approaches, including Lean/Six Sigma practices and streamlined hardware testing and integration, such as assembling major hardware elements before shipping to the Kennedy Space Center for launch operations. This paper provides top-level details for several cost saving initiatives, including both process and product improvements that will result in space transportation systems that are designed with operations efficiencies in mind. The Engineering Directorate provides both the intellectual capital embodied in an experienced workforce and unique facilities in which to validate the information technology tools that allow a nationwide team to collaboratively connect across miles that separate them and the engineering disciplines that integrate various piece parts into a whole system. As NASA transforms ground-based operations, it also is transitioning its workforce from an era of intense hands-on labor to a new one of mechanized conveniences and robust hardware with simpler interfaces. Ensuring that space exploration is on sound footing requires that operations efficiencies be designed into the transportation system and implemented in the development stage. Applying experience gained through decades of ground and space op'erations, while using value-added processes and modern business and engineering tools, is the philosophy upon which a new era of exploration will be built to solve some of the most pressing exploration challenges today -- namely, safety, reliability, and affordability.

Dumbacher, Daniel L.↗
DOE OSTI2025

A tale of two towers: comparing NEON and AmeriFlux data streams at Bartlett Experimental Forest

Long-term ecological data are essential for detecting impacts of climate change and other global change factors, and for making informed predictions about future change. However, long-term measurements are rarely replicated at the site level, which raises questions about their representativeness. We used a multiscale approach to evaluate the agreement of parallel observations from AmeriFlux and NEON (National Ecological Observatory Network) towers at Bartlett Experimental Forest, New Hampshire, USA. The two towers are separated by a horizontal distance of 93 m. Here, we focused our analysis on standard meteorological variables; fluxes of CO 2 , sensible heat, and latent heat measured by eddy covariance; and phenology derived from PhenoCam imagery. Results suggest excellent agreement between AmeriFlux and NEON in meteorology and phenology, and good agreement in fluxes at the half-hourly scale. However, large disagreements in CO 2 and latent heat fluxes occurred at the annual scale, with implications especially for the forest carbon balance. The AmeriFlux tower measurements indicate a site that is close to carbon-neutral (-8 ± 65 g C m -2 y -1 , mean ± 1 SD), whereas the NEON tower measurements indicate a forest that is a carbon sink (-137 ± 10 g C m -2 y -1 ). Causes of this disagreement may include measurement height (26 m vs. 35 m), which resulted in different flux footprints being measured by the two towers, and differences in the flux measurement systems. Our results suggest the need for caution when attempting to merge long-term flux data from two different measurement platforms, and when using measurements from any one measurement platform to inform decision-making on issues related to carbon accounting or natural climate solutions.

Carbon cycle↗
NASA NTRS2008

Orbital Express Advanced Video Guidance Sensor

In May 2007 the first US fully autonomous rendezvous and capture was successfully performed by DARPA's Orbital Express (OE) mission. Since then, the Boeing ASTRO spacecraft and the Ball Aerospace NEXTSat have performed multiple rendezvous and docking maneuvers to demonstrate the technologies needed for satellite servicing. MSFC's Advanced Video Guidance Sensor (AVGS) is a primary near-field proximity operations sensor integrated into ASTRO's Autonomous Rendezvous and Capture Sensor System (ARCSS), which provides relative state knowledge to the ASTRO GN&C system. This paper provides an overview of the AVGS sensor flying on Orbital Express, and a summary of the ground testing and on-orbit performance of the AVGS for OE. The AVGS is a laser-based system that is capable of providing range and bearing at midrange distances and full six degree-of-freedom (6DOF) knowledge at near fields. The sensor fires lasers at two different frequencies to illuminate the Long Range Targets (LRTs) and the Short Range Targets (SRTs) on NEXTSat. Subtraction of one image from the other image removes extraneous light sources and reflections from anything other than the corner cubes on the LRTs and SRTs. This feature has played a significant role for Orbital Express in poor lighting conditions. The very bright spots that remain in the subtracted image are processed by the target recognition algorithms and the inverse-perspective algorithms, to provide 3DOF or 6DOF relative state information. Although Orbital Express has configured the ASTRO ARCSS system to only use AVGS at ranges of 120 m or less, some OE scenarios have provided opportunities for AVGS to acquire and track NEXTSat at greater distances. Orbital Express scenarios to date that have utilized AVGS include a berthing operation performed by the ASTRO robotic arm, sensor checkout maneuvers performed by the ASTRO robotic arm, 10-m unmated operations, 30-m unmated operations, and Scenario 3-1 anomaly recovery. The AVGS performed very well during the pre-unmated operations, effectively tracking beyond its 10-degree Pitch and Yaw limit-specifications, and did not require I-LOAD adjustments before unmated operations. AVGS provided excellent performance in the 10-m unmated operations, effectively tracking and maintaining lock for the duration of this scenario, and showing good agreement between the short and long range targets. During the 30-m unmated operations, the AVGS continuously tracked the SRT to 31.6 m, exceeding expectations, and continuously tracked the LRT from 8.8 m out to 31.6 m, with good agreement between these two target solutions. After this scenario was aborted at a 10-m separation during remate operations, the AVGS tracked the LRT out 54.3 m, until the relative attitude between the vehicles was too large. The vehicles remained apart for eight days, at ranges from 1 km to 6 km. During the approach to remate in this recovery operation, the AVGS began tracking the LRT at 150 m, well beyond the OE planned limits for AVGS ranges, and functioned as the primary sensor for the autonomous rendezvous and docking.

Howard, Ricky↗
DOE OSTI2021

Creep-fatigue Behavior and Damage Accumulation of a Candidate Structural Material for Concentrating Solar Power Solar Thermal Receiver (Final Technical Report)

Creep-fatigue deformation is an important consideration for a thermal receiver in Concentrating Solar Power systems due to the constant static stress or pressure, diurnal cycling, and elevated service temperatures required for efficient operation. An accurate description of the creep-fatigue behavior, not available for five of the six candidate materials, is important for assessment of preliminary designs. This project has provided a detailed analysis of the creep-fatigue behavior and damage accumulation of Alloy 740H, a candidate structural material for a CSP solar thermal receiver to address a critical knowledge barrier for receiver designs identified in the CSP Gen3 Demonstration Roadmap. This project was divided in to three tasks, split between two general categories: Experimental and design methodology. Tasks 1 and 3, relating to the collection of data on Alloy 740H plate and sheet forms, respectively, were performed at the Idaho National Laboratory and used as input to Task 2, the development of design methodology performed at Argonne National Laboratory. Experimental work covered limited tensile and creep testing to fill gaps in available data that is currently available and to demonstrate how the plate of Alloy 740H tested in this work compared to historical data. A more substantial testing program for fatigue and creep-fatigue was performed, with particular emphasis on creep-fatigue as there is little available data and it is necessary to understand the creep-fatigue interaction and develop related design models. This effort includes the development of rules for the design of solar receiver components against high temperature creep-fatigue and ratcheting failure modes. The ASME Code rules for high temperature nuclear components was used to the basis of the method but adjustments will be made to reflect the generally shorter, diurnal operating cycles of thermal receivers and the relative consequences of failure, comparing nuclear to solar components. This work has provided guidance for the design of components for concentrating power facilities operating at high temperatures and undergoing high, secondary thermal stresses relative to the applied primary pressure stress. The design rules were developed for the design of Generation 3 CSP tubular receivers manufactured from Alloy 740H, but are generally applicable to a wide range of component types undergoing similar loads. Procedural design rules for components to be used in conjunction with the 2019 edition of the ASME Boiler & Pressure Vessel Code and the corresponding design data for Alloy 740H have been developed. A commentary describing the rationale behind the design rules and the data underlying the design material properties, as well as an extensive set of worked sample problems detailing the application of the rules to CSP components were developed as a part of this project, with a separate report covering these aspects in detail and included in the Appendix of this report.

14 SOLAR ENERGY↗
DOE OSTI2019

Estimation of full-field, full-order experimental modal model of cable vibration from digital video measurements with physics-guided unsupervised machine learning and computer vision

Cables are critical components for a variety of structures such as stay cables and suspenders of cable-stayed bridges and suspension bridges. When in operational service, they are vulnerable to cumulative fatigue damage induced by dynamic loads (e.g., the cyclic vehicle loads and wind excitation). To accurately analyze and predict their dynamics behaviors and performance that could be spatially local and temporal transient, it is essential to perform high-resolution vibration measurements, from which their dynamics properties are identified and, subsequently, a high spatial resolution, full-modal-order dynamics model of cable vibration can be established. In this study, we develop a physics-guided, unsupervised machine learning-based video processing approach that can blindly and efficiently extract the full-field (as many points as the pixel number of the video frame) modal parameters of cable vibration using only the video of an operating (output-only) cable. In particular, by incorporating the physics of cable vibration (taut string model), a novel automated modal motion filtering method is proposed to enable autonomous identification of full-order (as many modes as possible) dynamic parameters, including those weakly excited modes that used to be challenging to identify in operational modal analysis. Therefore, a full-field, full-order modal model of cable vibration is established by the proposed method. Furthermore, this new approach provides a low-cost and noncontact technique to estimate the cable tension using only the video of the vibrating cable where the fundamental frequency is automatically and efficiently estimated to compute the cable tension according to the taut string equation. Laboratory experiments on a bench-scale cable are conducted to validate the developed approach.

42 ENGINEERING↗
NASA NTRS2014

The ISS 2B PVTCS Ammonia Leak: An Operational History

In 2006, the Photovoltaic Thermal Control System (PVTCS) for the International Space Station's 2B power channel began leaking ammonia at a rate of approximately 1.5lbm/year (out of a starting approximately 53lbm system ammonia mass). Initially, the operations strategy was "feed the leak," a strategy successfully put into action via Extra Vehicular Activity during the STS‐134 mission. During this mission the system was topped off with ammonia piped over from a separate thermal control system. This recharge was to have allowed for continued power channel operation into 2014 or 2015, at which point another EVA would have been required. Without these periodic EVAs to refill the 2B coolant system, the channel would eventually leak enough fluid as to risk pump cavitation and system failure, resulting in the loss of the 2B power channel - the most critical of the Space Station's 8 power channels. In mid‐2012, the leak rate increased to approximately 5lbm/year. Once discovered, an EVA was planned and executed within a 5 week timeframe to drastically alter the architecture of the PVTCS via connection to a dormant thermal control system not intended to be utilized as anything other than spare components. The purpose of this rerouting of the TCS was to increase system volume and to isolate the photovoltaic radiator, thought to be the likely leak source. This EVA was successfully executed on November 1st, 2012 and left the 2B PVTCS in a configuration where the system was now being adequately cooled via a totally different radiator than what the system was designed to utilize. Unfortunately, data monitoring over the next several months showed that the isolated radiator was not leaking, and the system itself continued to leak steadily until May 9th, 2013. It was on this day that the ISS crew noticed the visible presence of ammonia crystals escaping from the 2B channel's truss segment, signifying a rapid acceleration of the leak from 5lbm/year to 5lbm/day. Within 48 hours of the crew noticing the leak, an EVA was in progress to replace the coolant pump - the only other replaceable leak source. This paper will explore the management of the 2B PVTCS leak from the operations perspective. It will discuss the methodology of performing the STS‐134 refill, the considerations and contingency plans which went into the architectural overhaul of the system in 2012, and the unprecedented effort which went into the EVA response to the visible leak of May 2013. In particular the paper will focus on the techniques utilized by flight controllers to monitor the system health and to respond to such instances as the rapid May 2013 leak by putting the electrical system in a safe configuration for loss of cooling, and will use recorded telemetry of these events to describe system response to EVA crew and ground actions. It will discuss the innovative design for redundancy of the integrated truss structure's cooling systems which allowed for this leak to be managed with minimal impact to other ISS operations and electrical services, contrasted against the real unintended operations consequences of utilizing the flexibility of the spacecraft's design in this manner. The paper will discuss how the training of the crew and flight controller personnel has adapted to the changing architecture of the power system and the unpredictable nature of the 2B leak.

Vareha, Anthony↗
NASA NTRS2013

NASA Software Engineering Benchmarking Study

To identify best practices for the improvement of software engineering on projects, NASA's Offices of Chief Engineer (OCE) and Safety and Mission Assurance (OSMA) formed a team led by Heather Rarick and Sally Godfrey to conduct this benchmarking study. The primary goals of the study are to identify best practices that: Improve the management and technical development of software intensive systems; Have a track record of successful deployment by aerospace industries, universities [including research and development (R&D) laboratories], and defense services, as well as NASA's own component Centers; and Identify candidate solutions for NASA's software issues. Beginning in the late fall of 2010, focus topics were chosen and interview questions were developed, based on the NASA top software challenges. Between February 2011 and November 2011, the Benchmark Team interviewed a total of 18 organizations, consisting of five NASA Centers, five industry organizations, four defense services organizations, and four university or university R and D laboratory organizations. A software assurance representative also participated in each of the interviews to focus on assurance and software safety best practices. Interviewees provided a wealth of information on each topic area that included: software policy, software acquisition, software assurance, testing, training, maintaining rigor in small projects, metrics, and use of the Capability Maturity Model Integration (CMMI) framework, as well as a number of special topics that came up in the discussions. NASA's software engineering practices compared favorably with the external organizations in most benchmark areas, but in every topic, there were ways in which NASA could improve its practices. Compared to defense services organizations and some of the industry organizations, one of NASA's notable weaknesses involved communication with contractors regarding its policies and requirements for acquired software. One of NASA's strengths was its software assurance practices, which seemed to rate well in comparison to the other organizational groups and also seemed to include a larger scope of activities. An unexpected benefit of the software benchmarking study was the identification of many opportunities for collaboration in areas including metrics, training, sharing of CMMI experiences and resources such as instructors and CMMI Lead Appraisers, and even sharing of assets such as documented processes. A further unexpected benefit of the study was the feedback on NASA practices that was received from some of the organizations interviewed. From that feedback, other potential areas where NASA could improve were highlighted, such as accuracy of software cost estimation and budgetary practices. The detailed report contains discussion of the practices noted in each of the topic areas, as well as a summary of observations and recommendations from each of the topic areas. The resulting 24 recommendations from the topic areas were then consolidated to eliminate duplication and culled into a set of 14 suggested actionable recommendations. This final set of actionable recommendations, listed below, are items that can be implemented to improve NASA's software engineering practices and to help address many of the items that were listed in the NASA top software engineering issues. 1. Develop and implement standard contract language for software procurements. 2. Advance accurate and trusted software cost estimates for both procured and in-house software and improve the capture of actual cost data to facilitate further improvements. 3. Establish a consistent set of objectives and expectations, specifically types of metrics at the Agency level, so key trends and models can be identified and used to continuously improve software processes and each software development effort. 4. Maintain the CMMI Maturity Level requirement for critical NASA projects and use CMMI to measure organizations developing software for NASA. 5.onsolidate, collect and, if needed, develop common processes principles and other assets across the Agency in order to provide more consistency in software development and acquisition practices and to reduce the overall cost of maintaining or increasing current NASA CMMI maturity levels. 6. Provide additional support for small projects that includes: (a) guidance for appropriate tailoring of requirements for small projects, (b) availability of suitable tools, including support tool set-up and training, and (c) training for small project personnel, assurance personnel and technical authorities on the acceptable options for tailoring requirements and performing assurance on small projects. 7. Develop software training classes for the more experienced software engineers using on-line training, videos, or small separate modules of training that can be accommodated as needed throughout a project. 8. Create guidelines to structure non-classroom training opportunities such as mentoring, peer reviews, lessons learned sessions, and on-the-job training. 9. Develop a set of predictive software defect data and a process for assessing software testing metric data against it. 10. Assess Agency-wide licenses for commonly used software tools. 11. Fill the knowledge gap in common software engineering practices for new hires and co-ops.12. Work through the Science, Technology, Engineering and Mathematics (STEM) program with universities in strengthening education in the use of common software engineering practices and standards. 13. Follow up this benchmark study with a deeper look into what both internal and external organizations perceive as the scope of software assurance, the value they expect to obtain from it, and the shortcomings they experience in the current practice. 14. Continue interactions with external software engineering environment through collaborations, knowledge sharing, and benchmarking.

Rarick, Heather L.↗
DOE OSTI2023

WHONDRS River Corridor Sediment and Water Geochemistry and In Situ Sensor Data from Machine-Learning-Informed Sites across the Contiguous United States (v6)

This dataset supports a broader study examining hyporheic zone respiration rates to improve predictive models at a contiguous United States (CONUS) scale. The CONUS-Scale Model-Sample Study (CM) was designed following ICON (integrated, coordinated, open, and networked) principles to facilitate a model-experiment (ModEx) iteration approach, leveraging crowdsourced sampling across the CONUS. New machine learning models were created every month to guide sampling locations. Data from the resulting samples were used to test and rebuild the machine learning models for the next round of sampling guidance. Sampling began in April 2022 and ended in October 2023. In addition to the widely distributed CONUS sites, a more spatially focused sampling occurred in the Yakima River Basin, WA in summer 2022. Data from this more spatially intensive sampling occurred under the label “Second Spatial Study (SSS)” and were also included in the machine learning models. Other data types collected from SSS that were not part of CM were published in a separate data package (https://data.ess-dive.lbl.gov/view/doi:10.15485/1969566). This data package was originally published in February 2023. It was updated in June 2023 (v2; new and modified files); December 2023 (v3; new and modified files); June 2024 (v4; new and modified files); April 2024 (v5; new and modified files); and September 2025 (v6; modified files). See the change history section in the readme for more details. For details on how to navigate data packages generated by this project, see https://data.ess-dive.lbl.gov/portals/PNNLRiverCorridorSFA/About. This dataset is comprised of two folders of field photos and videos, one folder of raw Fourier transform ion cyclotron resonance mass spectrometry (FTICR-MS) data and one main data folder containing (1) file-level metadata; (2) data dictionary; (3) field metadata; (4) readme; (5) international generic sample number (IGSN) mapping file; (6) field protocols; (7) a subfolder with sample data; and (8) a subfolder with sensor data. The sample data subfolder contains (1) surface water and sediment dissolved organic carbon (DOC, measured as non-purgeable organic carbon, NPOC) data and averages; (2) surface water and sediment total nitrogen data and averages; (3) surface water major cations and anions and averages; (4) sediment grain size data; (5) sediment iron (II) data and averages; (6) wet sediment mass, dry sediment mass, water mass, and wet sediment volume in incubation and sediment ICR vials; (7) sediment incubation respiration rate data and averages; (8) normalized respiration rate data and averages; (9) methods codes; (10) sediment specific surface area; (11) sediment percent carbon and nitrogen; (12) sediment gravimetric moisture and averages; (15) sediment X-ray diffraction (XRD) data; (16) sediment adenosine triphosphate (ATP) and averages; (17) a subfolder with sediment incubation respiration data, scripts, and plots; (18) surface water and sediment FTICR methods; and (19) a subfolder of 9.4 Tesla (9.4T) FTICR-MS data. This folder contains five subfolders, one containing the sediment .xml data files, one containing the water .xml files, one containing the sediment CoreMS output files, one containing the water CoreMS output files, and the other containing instructions and scripts for processing the files in CoreMS (https://github.com/EMSL-Computing/CoreMS).The sensor data subfolder contains (1) a subfolder with miniDOT dissolved oxygen and temperature data and plots; (2) miniDOT dissolved oxygen and temperature summary data; and (3) miniDOT installation methods. All files are .csv, .pdf, .R, .xml, .d, .html, .Rmd, .py, .cal, .json, .jpg, .jpeg, .png, .mov, or .mp4. CORRECTION: Carbon and nitrogen content are reported as percentages. The current column headers "01395_C_percent_per_mg" and "01397_N_percent_per_mg" are incorrect. These should read "01395_C_percent" and "01397_N_percent" and will be corrected in the next version of this data package. We thank the United States Forest Service, Washington Department of Fish and Wildlife, Washington Department of Natural Resources, Cowiche Canyon Conservatory, Washington State Parks and Recreation Commission (Scientific Research Permit #210901), and the Confederated Tribes and Bands of the Yakama Nation for access to field locations where the samples labeled “SSS” were collected. We also thank the Yakama Nation Tribal Council and Yakama Nation Fisheries for working with us to facilitate sample collection and optimization of data usage according to their values and worldview. WHONDRS consortium members were asked to provide any acknowledgments for the collection of samples labeled “CM” and the following is a list of acknowledgments that were submitted with their corresponding Site IDs: (MART) Research activities were conducted in part on the Wind River Experimental Forest within the Gifford Pinchot National Forest; (MP- 100379) Philadelphia is part of Lenapehoking, the ancestral homelands of the Lenape peoples; (MP-102398) Land surveyed is the ancestral homelands of the Nookhose'iinenno (Arapaho), Tsis tsis'tas (Cheyenne), and Nuuchu (Ute); (MP-100749 and MP- 100747) Georgia Coastal Ecosystem LTER, OCE-1832178; (SP-70 and SP-72) Eastern Shoshone, Shoshone-Bannock; (MP- 102944) Funded by Oregon Watershed Enhancement Board. On the traditional lands of the Confederated Tribes of the Siletz, Confederated Tribes of the Grand Rhonde, and the Clatsop-Nehalem Confederated Tribe; (MP- 100607) Holiday Creek is located on the traditional territory of the Monacan Indian Nation; (SP-45) Lafayette Blue Springs State Park; (MP-102420) NSF DEB-2016749; (MP-100019) New Hampshire Agriculture Experiment Station; (SP-35) Rayonier (land owner; https://www.rayonier.com/); (MP- 101276) US Department of Energy, Office of Science, Biological and Environmental Research, Subsurface Biogeochemical Research, Watershed Dynamics and Evolution SFA at ORNL; (MP- 103224) Watershed Dynamics and Evolution SFA at ORNL; (MP- 101584) Traditional lands of the Oceti Sakowin (Dakota, Lakota, Nakoda) and Anishinaabe Peoples.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS2013

Planetary Protection Bioburden Analysis Program

This program is a Microsoft Access program that performed statistical analysis of the colony counts from assays performed on the Mars Science Laboratory (MSL) spacecraft to determine the bioburden density, 3-sigma biodensity, and the total bioburdens required for the MSL prelaunch reports. It also contains numerous tools that report the data in various ways to simplify the reports required. The program performs all the calculations directly in the MS Access program. Prior to this development, the data was exported to large Excel files that had to be cut and pasted to provide the desired results. The program contains a main menu and a number of submenus. Analyses can be performed by using either all the assays, or only the accountable assays that will be used in the final analysis. There are three options on the first menu: either calculate using (1) the old MER (Mars Exploration Rover) statistics, (2) the MSL statistics for all the assays, or This software implements penetration limit equations for common micrometeoroid and orbital debris (MMOD) shield configurations, windows, and thermal protection systems. Allowable MMOD risk is formulated in terms of the probability of penetration (PNP) of the spacecraft pressure hull. For calculating the risk, spacecraft geometry models, mission profiles, debris environment models, and penetration limit equations for installed shielding configurations are required. Risk assessment software such as NASA's BUMPERII is used to calculate mission PNP; however, they are unsuitable for use in shield design and preliminary analysis studies. The software defines a single equation for the design and performance evaluation of common MMOD shielding configurations, windows, and thermal protection systems, along with a description of their validity range and guidelines for their application. Recommendations are based on preliminary reviews of fundamental assumptions, and accuracy in predicting experimental impact test results. The software is programmed in Visual Basic for Applications for installation as a simple add-in for Microsoft Excel. The user is directed to a graphical user interface (GUI) that requires user inputs and provides solutions directly in Microsoft Excel workbooks. This work was done by Shannon Ryan of the USRA Lunar and Planetary Institute for Johnson Space Center. Further information is contained in a TSP (see page 1). MSC- 24582-1 Micrometeoroid and Orbital Debris (MMOD) Shield Ballistic Limit Analysis Program Lyndon B. Johnson Space Center, Houston, Texas Commercially, because it is so generic, Enigma can be used for almost any project that requires engineering visualization, model building, or animation. Models in Enigma can be exported to many other formats for use in other applications as well. Educationally, Enigma is being used to allow university students to visualize robotic algorithms in a simulation mode before using them with actual hardware. This work was done by David Shores and Sharon P. Goza of Johnson Space Center; Cheyenne McKeegan, Rick Easley, Janet Way, and Shonn Everett of MEI Technologies; Mark Manning of PTI; and Mark Guerra, Ray Kraesig, and William Leu of Tietronix Software, Inc. For further information, contact the JSC Innovation Partnerships Office at (281) 483-3809. MSC-24211-1 Spitzer Telemetry Processing System NASA's Jet Propulsion Laboratory, Pasadena, California The Spitzer Telemetry Processing System (SirtfTlmProc) was designed to address objectives of JPL's Multi-mission Image Processing Lab (MIPL) in processing spacecraft telemetry and distributing the resulting data to the science community. To minimize costs and maximize operability, the software design focused on automated error recovery, performance, and information management. The system processes telemetry from the Spitzer spacecraft and delivers Level 0 products to the Spitzer Science Center. SirtfTlmProc is a unique system with automated error notification and recovery, with a real-time continuous service that can go quiescent after periods of inactivity. The software can process 2 GB of telemetry and deliver Level 0 science products to the end user in four hours. It provides analysis tools so the operator can manage the system and troubleshoot problems. It automates telemetry processing in order to reduce staffing costs. This work was done by Alice Stanboli, Elmain M. Martinez, and James M. McAuley of Caltech for NASA's Jet Propulsion Laboratory. For more information, contact iaoffice @jpl.nasa.gov. This software is available for commercial licensing. Please contact Dan Broderick at Daniel.F. Broderick@jpl.nasa.gov. Refer to NPO-47803. NASA Tech Briefs, September 2013 29 This rapid response computer program predicts Orbiter Wing Leading Edge (WLE) damage caused by ice or foam impact during a Space Shuttle launch (Program "IMPACT2"). The program was developed after the Columbia accident in order to assess quickly WLE damage due to ice, foam, or metal impact (if any) during a Shuttle launch. IMPACT2 simulates an impact event in a few minutes for foam impactors, and in seconds for ice and metal impactors. The damage criterion is derived from results obtained from one sophisticated commercial program, which requires hours to carry out simulations of the same impact events. The program was designed to run much faster than the commercial program with prediction of projectile threshold velocities within 10 to 15% of commercial-program values. The mathematical model involves coupling of Orbiter wing normal modes of vibration to nonlinear or linear springmass models. IMPACT2 solves nonlinear or linear impact problems using classical normal modes of vibration of a target, and nonlinear/ linear time-domain equations for the projectile. Impact loads and stresses developed in the target are computed as functions of time. This model is novel because of its speed of execution. A typical model of foam, or other projectile characterized by material nonlinearities, impacting an RCC panel is executed in minutes instead of hours needed by the commercial programs. Target damage due to impact can be assessed quickly, provided that target vibration modes and allowable stress are known. This work was done by Robert Clark, Jr., Paul Cotter, and Constantine Michalopoulos of The Boeing Company for Johnson Space Center. For further information, contact the JSC Innovation Partnerships Office at (281) 483-3809. MSC-24988-1 Wing Leading Edge RCC Rapid Response Damage Prediction Tool (IMPACT2) Lyndon B. Johnson Space Center, Houston, Texas (3) the MSL statistics for only the accountable assays. Other options on the main menu include a data editing form and utility programs that produce various reports requested by the microbiologists and the project, and tools to generate the groupings for the final analyses. The analyses can be carried out in three ways: Each assay can be treated separately, the assays can be collectively treated for the whole zone as a group, or the assays can be collected in groups designated by the JPL Planetary Protection Manager. The latter approach was used to generate the final report because assays on the same equipment or similar equipment can be assumed to have been exposed to the same environment and cleaning. Thus, the statistics are improved by having a larger population, thereby reducing the standard deviation by the square root of N. For each method mentioned above, three reports are available. The first is a detailed report including all the data. This version was very useful in verifying the calculations. The second is a brief report that is similar to the full detailed report, but does not print out the data. The third is a grand total and summary report in which each assay requires only one line. For the first and second reports, most of the calculations are performed in the report section itself. For the third, all the calculations are performed directly in the query bound to the report. All the numerical results were verified by comparing them with Excel templates, then exporting the data from the Planetary Protection Analysis program to Excel.

Beaudet, Robert A.↗
DOE OSTI2025

IM3 Open Source Data Center Atlas

IM3 Open Source Data Center Atlas Description This dataset contains locations of existing data center facilities in the United States. Data center locations were derived from OpenStreetMap (OSM), a crowd-sourced database. Data points from OSM are processed in various ways to determine additional variables provided in the data including: facility area (square feet), associated US county, and US state. This dataset can be used to identify areas of concentrated data center development and inform government and private sector planning strategies for future buildout of data centers and the infrastructure necessary to support it. Usage Notes Validation of OSM-derived data center locations is an ongoing development under the IM3 project, and the database will be updated as new information becomes available. In some instances, both the data center area (e.g., campus) and individual data center buildings are included as overlapping areas in the database. Both values are retained. Data center points, buildings, and campus areas are provided as separate layers in the downloadable data package. Note that data items are not necessarily complete across layers. That is, a specific data center may only be present as a single point geometry in the "point" layer while other data centers are represented in both the campus and building layers. In some cases, data center campuses and/or buildings straddle a county boundary line. Mappings to both counties are retained in the database as separate rows. These data rows will have the same data center id information, but each will have different county information. Crowd-sourced data, by nature, relies on individuals and communities to provide information. As a result, some data may be missing where it has not yet been reported. As we collect information on additional data center locations and as OSM receives additional contributions, the database will be updated to capture additional data points not yet shown. Technical Information Data is available for download under the following formats: GeoPackage (GPKG) CSV Geospatial data is provided in the WGS84 (EPSG:4326) coordinate reference system. The GeoPackage download contains the following layers. See usage notes for more information. "point" "building" "campus" The "point" layer includes all data from OSM that had POINT geometry type (i.e., individual coordinates). The "building" layer includes all OSM data that did not have POINT geometry and where the building tag in the OSM export was neither equal to "no" or null. Data that did not meet the "point" or "building" qualification was assumed to be a facility campus and included in the "campus" layer. The dataset contains the following parameters. Variables provided by OSM are labeled with (OSM-provided). id - unique identification number (OSM-provided with prefix of "node/", "relation/" and similar attributes removed) state - name of US state state_abb - two letter US state abbreviation state_id - state ID number county - name of US county county_id - county ID number ref - reference numbers or codes (OSM-provided) operator - the name of the company, corporation, or person in charge facility (OSM-provided) name - name of facility (OSM-provided) sqft - surface area of facility polygon, measured in square feet. Only available for "building" and "campus" layers lat - latitude of data centroid point lon - longitude of data centroid point type – represented spatial information. One of "point", "building", or "campus". geometry – POLYGON geometry of area footprint (in "campus" and "building" layers) or POINT geometry of locations (in "point" layer). This parameter is not included in the csv download. Attribution Data center locations were derived from OpenStreetMap, which is made available at openstreetmap.org under the Open Database License (ODbL). US state and county boundary information was collected from the US Census Bureau for the year 2024, which is made publicly available at https://www.census.gov/geographies/mapping-files.html Acknowledgment IM3 is a multi-institutional effort led by Pacific Northwest National Laboratory and supported by the U.S. Department of Energy's Office of Science as part of research in MultiSector Dynamics, Earth and Environmental Systems Modeling Program. License The IM3 Open Source Data Center Atlas is made available under the Open Database License: http://opendatacommons.org/licenses/odbl/1.0/. Disclaimer This material was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the United States Department of Energy, nor the Contractor, nor any or their employees, nor any jurisdiction or organization that has cooperated in the development of these materials, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness or any information, apparatus, product, software, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or any agency thereof, or Battelle Memorial Institute. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof. PACIFIC NORTHWEST NATIONAL LABORATORYoperated byBATTELLEfor theUNITED STATES DEPARTMENT OF ENERGYunder Contract DE-AC05-76RL01830

Mongird, Kendall [Pacific Northwest National Labor↗
NASA NTRS2011

Landsat Data Continuity Mission

The Landsat Data Continuity Mission (LDCM) is currently under development and is on schedule to launch the 8th satellite in the Landsat series in December of 2012. LDCM is a joint project between the National Aeronautics and Space Administration (NASA) and the United States Geological Survey (USGS). NASA is responsible for developing and launching the flight hardware and on-orbit commissioning and USGS is responsible for developing the ground system and operating the system onorbit after commissioning. Key components of the flight hardware are the Operational Land Imager (OLI), nearing completion by Ball Aerospace & Technologies Corp in Boulder, CO, the Thermal Infrared Sensor (TIRS), being built by NASA's Goddard Space Flight Center and the spacecraft, undergoing integration at Orbital Sciences Corp in Gilbert, Arizona. The launch vehicle will be an Atlas-5 with launch services provided by NASA's Kennedy Space Center. Key ground systems elements are the Mission Operations Element, being developed by the Hammers Corporation, and the Collection Activity Planning Element, Ground Network Element, and Data Processing and Archive System, being developed internally by the USGS Earth Resources Observations and Science (EROS) Center. The primary measurement goal of LDCM is to continue the global coverage of moderate spatial resolution imagery providing continuity with the existing Landsat record. The science goal for this imagery is to monitor land use and land cover, particularly as it relates to global climate change. Together the OLI and TIRS instruments on LDCM replace the ETM+ instrument on Landsat-7 with significant enhancements. The OLI is a pushbroom design instrument where the scanning mechanism of the ETM+ is effectively replaced by a long line of detectors. The OLI has 9 spectral bands with similar spatial resolution to ETM+: 7 of them similar to the reflective spectral bands on ETM+ and two new bands. The two new bands cover (1) the shorter wavelength blue part of the spectrum to help with coastal studies and aerosol analyses/atmospheric correction and (2) an atmospheric water absorption band, where the Earth surface is generally not visible, but Cirrus clouds are, to aid in cloud detection and screening. The radiometry of OLI benefits from improved SNR, dynamic range and quantization. OLI is undergoing system testing with a delivery scheduled for Spring 2011. The TIRS is also a pushbroom design and used QWIPS detectors that require cooling to 43K using a cryocooler. It.has two spectral bands, effectively splitting the ETM+ band 6 in half, that can be used as a split window to aid in atmospheric correction. It has nominally 100 m spatial resolution as opposed to the 60 m of Landsat-7 ETM+: TIRS has commenced integration and test, with a delivery to the spacecraft vendor scheduled for Winter 2011-2012. The Orbital spacecraft currently being integrated for LDCM will have improved capabilities for pointing over previous missions. These capabilities will allow the OLI and TIRS instruments to point off-nadir the equivalent of one WRS-2 path to increase the chances of coverage for high priority targets, particularly in the event of natural disasters. Also, the pointing capability will allow the calibration of the OLI using the sun (roughly weekly), the moon (monthly), stars (during commissioning) and the Earth (at 90 deg from normal orientation, a.k.a., side slither) quarterly. The solar calibration will be used for OLI absolute and relative calibration, the moon for trending the stability of the OLI response, the stars will be used for Line of Sight determination and the side slither will be an alternate OLI and relative gain determination methodology. The spacecraft is scheduled to begin integration with the OLI instrument in Summer 2011. The LDCM data processing and archive system (DPAS), located at USGS EROS, generates the products for distribution to users. Like Landsat-7 this includes an image assessment system for characrizing instrument performance and updating calibration parameters. Products will be generated that include the spectral bands from both instruments, terrain corrected and registered to the geoid. Also, like Landsat-7, data products will be distributed at no charge to the user. The current status and plans of the space and ground segments of the LDCM project will be presented along with performance predictions as available. More detailed information on the two instruments is intended to be presented in separate papers.

Markham, Brian↗
DOE OSTI2026

IM3 Open Source Data Center Atlas

IM3 Open Source Data Center Atlas Description This dataset contains locations of existing data center facilities in the United States. Data center locations were derived from OpenStreetMap (OSM), a crowd-sourced database. Data points from OSM are processed in various ways to determine additional variables provided in the data including: facility area (square feet), associated US county, and US state. This dataset can be used to identify areas of concentrated data center development and inform government and private sector planning strategies for future buildout of data centers and the infrastructure necessary to support it. Usage Notes Validation of OSM-derived data center locations is an ongoing development under the IM3 project, and the database will be updated as new information becomes available. In some instances, both the data center area (e.g., campus) and individual data center buildings are included as overlapping areas in the database. Both values are retained. Data center points, buildings, and campus areas are provided as separate layers in the downloadable data package. Note that data items are not necessarily complete across layers. That is, a specific data center may only be present as a single point geometry in the "point" layer while other data centers are represented in both the campus and building layers. In some cases, data center campuses and/or buildings straddle a county boundary line. Mappings to both counties are retained in the database as separate rows. These data rows will have the same data center id information, but each will have different county information. Crowd-sourced data, by nature, relies on individuals and communities to provide information. As a result, some data may be missing where it has not yet been reported. As we collect information on additional data center locations and as OSM receives additional contributions, the database will be updated to capture additional data points not yet shown. Data items will occasionally be removed from OSM if they are misidentified, if they no longer exist, if they are duplicates of another item, or similar. For that reason, updated versions of this database may not contain all data center locations included in previous versions. Technical Information Data is available for download under the following formats: GeoPackage (GPKG) CSV Geospatial data is provided in the WGS84 (EPSG:4326) coordinate reference system. The GeoPackage download contains the following layers. See usage notes for more information. "point" "building" "campus" The "point" layer includes all data from OSM that had POINT geometry type (i.e., individual coordinates). The "building" layer includes all OSM data that did not have POINT geometry and where the building tag in the OSM export was neither equal to "no" or null. Data that did not meet the "point" or "building" qualification was assumed to be a facility campus and included in the "campus" layer. The dataset contains the following parameters. Variables provided by OSM are labeled with (OSM-provided). id - unique identification number (OSM-provided with prefix of "node/", "relation/" and similar attributes removed) state - name of US state state_abb - two letter US state abbreviation state_id - state ID number county - name of US county county_id - county ID number ref - reference numbers or codes (OSM-provided) operator - the name of the company, corporation, or person in charge facility (OSM-provided) name - name of facility (OSM-provided) sqft - surface area of facility polygon, measured in square feet. Only available for "building" and "campus" layers lat - latitude of data centroid point lon - longitude of data centroid point type – represented spatial information. One of "point", "building", or "campus". geometry – POLYGON geometry of area footprint (in "campus" and "building" layers) or POINT geometry of locations (in "point" layer). This parameter is not included in the csv download. Attribution Data center locations were derived from OpenStreetMap, which is made available at openstreetmap.org under the Open Database License (ODbL). US state and county boundary information was collected from the US Census Bureau for the year 2024, which is made publicly available at https://www.census.gov/geographies/mapping-files.html Acknowledgment IM3 is a multi-institutional effort led by Pacific Northwest National Laboratory and supported by the U.S. Department of Energy's Office of Science as part of research in MultiSector Dynamics, Earth and Environmental Systems Modeling Program. License The IM3 Open Source Data Center Atlas is made available under the Open Database License: http://opendatacommons.org/licenses/odbl/1.0/. Disclaimer This material was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the United States Department of Energy, nor the Contractor, nor any or their employees, nor any jurisdiction or organization that has cooperated in the development of these materials, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness or any information, apparatus, product, software, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or any agency thereof, or Battelle Memorial Institute. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof. PACIFIC NORTHWEST NATIONAL LABORATORYoperated byBATTELLEfor theUNITED STATES DEPARTMENT OF ENERGYunder Contract DE-AC05-76RL01830

Mongird, Kendall [Pacific Northwest National Labor↗
DOE OSTI2025

A U.S. Scientific Community Vision for Sustained Earth Observations of Greenhouse Gases to Support Local to Global Action

Managing carbon stocks in the land, ocean, and atmosphere under changing climate requires a globally‐integrated view of carbon cycle processes at local and regional scales. The growing Earth Observation (EO) record is the backbone of this multi‐scale system, providing local information with discrete coverage from surface measurements and regional information at global scale from satellites. Carbon flux information, anchored by inverse estimates from spaceborne Greenhouse Gas (GHG) concentrations, provides an important top‐down view of carbon emissions and sinks, but currently lacks global continuity at assessment and management scales (<100 km). Partial‐column data can help separate signals in the boundary layer from the overlying atmosphere, providing an opportunity to enhance surface sensitivity and bring flux resolution down from that of column‐integrated data (100–500 km). Based on a workshop held in September 2024, the carbon cycle community envisions a carbon observation system leveraging GHG partial columns in the lower and upper troposphere to weave together information across scales from surface and satellite EO data, and integration of top‐down/bottom‐up analyses to link process understanding to global assessment.

Parazoo, Nicholas C. [California Institute of Tech↗
NASA NTRSDate not supplied

Trajectory Engineering with Modular Patched Conics for Entry Systems and TPS (TEMPEST)

Brief Presenter Biography (35 word limit): Bohdan Wesely is an Aerospace Engineer in the Entry Systems and Technology Division at Ames. He has worked on a variety of projects for NASA including integrated TPS (thermal protection system) flight hardware deliveries and testing services for commercial partners. Introduction: TEMPEST is a new trajectory analysis framework that is designed to fill the gap between dedicated flight mechanics tools and aerothermal and TPS sizing tools. The project started as an SJSU master’s thesis and has since evolved into a general conceptual design tool capable of studying a wide variety of entry problems. Development is ongoing in the Entry Systems and Technology Division at NASA ARC. Why TEMPEST: Space missions involving entry into a planetary atmosphere involve a series of unique requirements across multiple disciplines. Whether it is traditional entry descent and landing (EDL), or aerocapture, the vehicle must navigate to its target landing location or orbit state, and the TPS must protect the payload during entry. The design process typically involves iterative handoffs between various flight mechanics, flow solver, and material response level tools. During the early conceptual phase, a wide variety of feasible trajectories are simulated in a Monte Carlo scenario which broadly satisfy the mission or landing requirements. Next, computational fluid dynamics (CFD), direct simulation Monte Carlo (DSMC), and other flow solver analyses are performed at various key trajectory points to generate an aero-database, heating and TPS design requirements also emerge at this stage. At this point, with updated aerodynamics from the various flow solvers, trajectories can be re-run, this in turn can change the required freestream conditions for the CFD tools, and as a project progresses, these analyses converge, and uncertainty is reduced. However, there is always a “hand-off” occurring between two inherently coupled phenomena. Analysis Description: One of the goals with TEMPEST is to use a variety of first principles estimation methods coupled with an atmosphere model to predict vehicle aerothermodynamics across the entire flight regime while propagating a 3 or 6 degree of freedom (DoF) trajectory. Aerodynamics methods include modified Newtonian, Maxwell and Cercignani- Lampis-Lord (CLL) for continuum, transitional, and free molecular flow regimes. Aerothermodynamics include boundary layer and reference enthalpy methods, and Mutation++ for non-equilibrium chemistry modeling. TEMPEST is also capable of stitching multiple trajectory segments together to study mission scenarios like multi-pass aerocapture and aero-gravity assists. Most of the program is implemented in MATLAB using modern system objects, it relies on several C++ shared libraries for supporting tools like Gmsh, the Global Reference Atmospheric Model (GRAM), and Mutation++. The various first principles aerothermal estimation methods are discretized across either a structured axisymmetric panel mesh or an unstructured tri-mesh generated from an open-source tool such as Gmsh, this allows solutions on the same mesh to be compared across tools such as CB-Aero. CFD Coupling. A physics-aware, gaussian process CFD anchoring scheme is proposed to adjust the various first principles methods as a CFD database is populated. One goal for this anchoring module is to inform the project where CFD should be run. Full knowledge of the entire trajectory, atmosphere, and aerothermodynamics allows for easier identification of high sensitivity areas and uncertainty quantification. While the first principles effects are well known and proven accurate in existing tools such as CB- Aero and Cart3D, a physics aware CFD anchoring scheme increases tool credibility across a project lifecycle. Material Response Modeling. Correct TPS sizing is critical for optimizing mass for science payloads and ensuring mission success. The process typically involves a thermal analysis along the trajectory with surface heating environments as a boundary condition. Several design constraints are maximum bondline temperature and maximum recession with various margining techniques. The material response tool FIAT, developed out of NASA Ames, is currently being integrated into the TEMPEST environment. TPS recession, shape change, mass loss, and mass property alteration are all factors that can perturb an entry trajectory. For missions like Mars 2020, recession was minimal and was safely handled separately as a post process. For missions such as Jupiter Galileo with a high TPS mass fraction or asteroid entries, recession plays a major role. The proposed fully coupled scheme is to use an epoch-based approach where the trajectory integration is halted after a recession threshold, the energy balance and FIAT are solved at each panel, the mesh, aerodynamics, and mass properties are updated, and the trajectory continues. Several computational tradeoffs have been made during the development of TEMPEST to limit the cost of a single trajectory and preserve its utility as a conceptual, rapid iteration tool. Conclusion: Development of TEMPEST is ongoing and the project is still in its infancy. This talk aims to showcase its unique capabilities to support future NASA entry systems missions.

Bohdan O Wesely↗
NASA NTRS2011

Solar Dynamics Observatory Guidance, Navigation, and Control System Overview

The Solar Dynamics Observatory (SDO) was designed and built at the Goddard Space Flight Center, launched from Cape Canaveral on February 11, 2010, and reached its final geosynchronous science orbit on March 16, 2010. The purpose of SDO is to observe the Sun and continuously relay data to a dedicated ground station. SDO remains Sun-pointing throughout most of its mission for the instruments to take measurements of the Sun. The SDO attitude control system (ACS) is a single-fault tolerant design. Its fully redundant attitude sensor complement includes sixteen coarse Sun sensors (CSSs), a digital Sun sensor (DSS), three two-axis inertial reference units (IRUs), and two star trackers (STs). The ACS also makes use of the four guide telescopes included as a part of one of the science instruments. Attitude actuation is performed using four reaction wheels assemblies (RWAs) and eight thrusters, with a single main engine used to provide velocity-change thrust for orbit raising. The attitude control software has five nominal control modes, three wheel-based modes and two thruster-based modes. A wheel-based Safehold running in the attitude control electronics box improves the robustness of the system as a whole. All six modes are designed on the same basic proportional-integral-derivative attitude error structure, with more robust modes setting their integral gains to zero. This paper details the final overall design of the SDO guidance, navigation, and control (GN&C) system and how it was used in practice during SDO launch, commissioning, and nominal operations. This overview will include the ACS control modes, attitude determination and sensor calibration, the high gain antenna (HGA) calibration, and jitter mitigation operation. The Solar Dynamics Observatory mission is part of the NASA Living With a Star program, which seeks to understand the changing Sun and its effects on the Solar System, life, and society. To this end, the SDO spacecraft carries three Sun-observing instruments: Helioseismic and Magnetic Imager (HMI), led by Stanford University; Atmospheric Imaging Assembly (AIA), led by Lockheed Martin Space and Astrophysics Laboratory; and Extreme Ultraviolet Variability Experiment (EVE), led by the University of Colorado. The basic mission is to observe the Sun for a very high percentage of the 5-year mission (10-year goal) with long stretches of uninterrupted observations and with constant, high-data-rate transmission to a dedicated ground station to be located in White Sands, New Mexico. These goals guided the design of the spacecraft bus that will carry and service the three-instrument payload. Overarching design goals for the bus are geosynchronous orbit, near-constant Sun observations with the ability to fly through eclipses, and constant HGA contact with the dedicated ground station. A three-axis stabilized ACS is needed both to point at the Sun accurately and to keep the roll about the Sun vector correctly positioned with respect to the solar north pole. This roll control is especially important for the magnetic field imaging of HM I. The mission requirements have several general impacts on the ACS design. Both the AIA and HMI instruments are very sensitive to the blurring caused by jitter. Each has an image stabilization system (ISS) with some ability to filter out high frequency motion, but below the bandwidth of the ISS the control system must compensate for disturbances within the ACS bandwidth or avoid exciting jitter at higher frequencies. Within the ACS bandwidth, the control requirement imposed by AIA is to place the center of the solar disk no more than 2 arc sec, 3 , from a body-defined target based on one of the GTs that accompany the instrument. This body-defined target, called the science reference boresight (SRB), was determined from the postlaunch orientation of the GTs by averaging the bounding telescope boresights for pitch to get a pitch SRB coordinate, and by averaging the bounding boresights for yaw toet the yaw SRB coordinate. The location of this SRB in the 0.5-deg field-of-view for each GT then becomes the central target for each telescope; one GT is selected for use as the ACS controlling guide telescope (CGT) at any given time. Fine Sun-pointing is effected based on this SRB for all three instruments when the Sun is within the linear range of the CGT. In addition to limiting jitter, HMI science requires averaging several observations, making the instrument sensitive to low frequency motion that induces differential motion between each observation. This requires the spacecraft attitude to be stable about the roll axis to approximately 10 arcsec over a ten-minute period. Instrument calibrations require that the spacecraft point the SRB up to 2.5 degrees in pitch and yaw away from the center of the Sun, placing the Sun outside the field-of-view of the guide telescopes. In such instances, when the GTs cannot provide the definitive target for the ACS, on-board attitude determination combined with ephemeris prediction of the Sun direction must provide the definitive target. EVE is capable of observing the Sun with less dependence on attitude control. However, the ground data processing needs for calibrations result in the most strict attitude knowledge requirements for the mission: [35,70,70] arcsec, 3 , of knowledge with respect to the center of the solar disk. In addition to driving the ACS sensor selection, the knowledge requirements, which have their effect primarily during Inertial mode calibrations, drive the accuracy requirements for the solar ephemeris. The need to achieve and maintain geosynchronous orbit (GEO) drove the need for high-efficiency propulsive systems and appropriate attitude control. The main engine provided high specific impulse for the maneuvers to attain GEO, while the smaller ACS thrusters managed the disturbance torques of the larger engine and provided the capability for much smaller adjustment burns on orbit. SDO s large solar profile means that solar radiation pressure is a large torque disturbance, and the momentum buildup from this disturbance and the GEO altitude drives the ACS to use thrusters to manage vehicle momentum. The demanding data capture budget for the mission, however, requires SDO to avoid frequent thruster maneuvers, while concerns about on-orbit jitter restrict the maximum desired wheel speeds desired from the RWAs. The plan for on-orbit wheel speed and momentum management will be discussed as well as what is now being done in operation after the jitter environment was characterized. The SDO ACS hardware complement is single-fault tolerant. Two main processors carry virtually identical copies of the command and data handling and ACS software, and two identical attitude control electronics (ACE) boxes carry Coldfire processors with contingency ACS software and other hardware interface cards; the ACE structure allows reaction wheels to be commanded by the Sun-pointing Safehold independent of the Mil Std 1553 data bus. The sixteen Adcole CSSs are grouped into primary and backup sets of eight sensors, each set providing the ability to calculate a sun vector. Each set of eight eyes provides full 4 -steradian coverage. The Adcole DSS comprises an optics head and a separate electronics box providing a 1553 data interface. The electronics box is mounted inside the Faraday cage created by the spacecraft bus module. The DSS head with its 32- deg square FOV is mounted on the instrument module with its boresight along the spacecraft X axis, nearly aligned with the Sun during observations. Adcole has designed the DSS calibration parameters so that the accuracy is 0.24 arcminutes within 10 deg of the boresight, and diminishes to 3 arcminutes as the Sun moves towards the edges of its FOV . This DSS calibration scheme provides higher accuracy attitude determination over the range of the instrument calibration maneuvers.

Morgenstern, Wendy M.↗