Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “program processors”

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.

1,196 records · Page 67
All sourcesNASA NTRSDOE OSTI
NASA NTRS2002

Multi-Zone Liquid Thrust Chamber Performance Code with Domain Decomposition for Parallel Processing

Computational Fluid Dynamics (CFD) has considerably evolved in the last decade. There are many computer programs that can perform computations on viscous internal or external flows with chemical reactions. CFD has become a commonly used tool in the design and analysis of gas turbines, ramjet combustors, turbo-machinery, inlet ducts, rocket engines, jet interaction, missile, and ramjet nozzles. One of the problems of interest to NASA has always been the performance prediction for rocket and air-breathing engines. Due to the complexity of flow in these engines it is necessary to resolve the flowfield into a fine mesh to capture quantities like turbulence and heat transfer. However, calculation on a high-resolution grid is associated with a prohibitively increasing computational time that can downgrade the value of the CFD for practical engineering calculations. The Liquid Thrust Chamber Performance (LTCP) code was developed for NASA/MSFC (Marshall Space Flight Center) to perform liquid rocket engine performance calculations. This code is a 2D/axisymmetric full Navier-Stokes (NS) solver with fully coupled finite rate chemistry and Eulerian treatment of liquid fuel and/or oxidizer droplets. One of the advantages of this code has been the resemblance of its input file to the JANNAF (Joint Army Navy NASA Air Force Interagency Propulsion Committee) standard TDK code, and its automatic grid generation for JANNAF defined combustion chamber wall geometry. These options minimize the learning effort for TDK users, and make the code a good candidate for performing engineering calculations. Although the LTCP code was developed for liquid rocket engines, it is a general-purpose code and has been used for solving many engineering problems. However, the single zone formulation of the LTCP has limited the code to be applicable to problems with complex geometry. Furthermore, the computational time becomes prohibitively large for high-resolution problems with chemistry, two-equation turbulence model, and two-phase flow. To overcome these limitations, the LTCP code is rewritten to include the multi-zone capability with domain decomposition that makes it suitable for parallel processing, i.e., enabling the code to run every zone or sub-domain on a separate processor. This can reduce the run time by a factor of 6 to 8, depending on the problem.

Homayun K. Navaz↗
NASA NTRS2015

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASAs Space Launch System

The engineering development of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS) requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The nominal and off-nominal characteristics of SLS's elements and subsystems must be understood and matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large and complex systems engineering challenge, which is being addressed in part by focusing on the specific subsystems involved in the handling of off-nominal mission and fault tolerance with response management. Using traditional model-based system and software engineering design principles from the Unified Modeling Language (UML) and Systems Modeling Language (SysML), the Mission and Fault Management (M&FM) algorithms for the vehicle are crafted and vetted in Integrated Development Teams (IDTs) composed of multiple development disciplines such as Systems Engineering (SE), Flight Software (FSW), Safety and Mission Assurance (S&MA) and the major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GNC), Thrust Vector Control (TVC), and liquid engines. These model-based algorithms and their development lifecycle from inception through FSW certification are an important focus of SLS's development effort to further ensure reliable detection and response to off-nominal vehicle states during all phases of vehicle operation from pre-launch through end of flight. To test and validate these M&FM algorithms a dedicated test-bed was developed for full Vehicle Management End-to-End Testing (VMET). For addressing fault management (FM) early in the development lifecycle for the SLS program, NASA formed the M&FM team as part of the Integrated Systems Health Management and Automation Branch under the Spacecraft Vehicle Systems Department at the Marshall Space Flight Center (MSFC). To support the development of the FM algorithms, the VMET developed by the M&FM team provides the ability to integrate the algorithms, perform test cases, and integrate vendor-supplied physics-based launch vehicle (LV) subsystem models. Additionally, the team has developed processes for implementing and validating the M&FM algorithms for concept validation and risk reduction. The flexibility of the VMET capabilities enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the developed algorithms utilizing actual subsystem models such as MPS, GNC, and others. One of the principal functions of VMET is to validate the M&FM algorithms and substantiate them with performance baselines for each of the target vehicle subsystems in an independent platform exterior to the flight software test and validation processes. In any software development process there is inherent risk in the interpretation and implementation of concepts from requirements and test cases into flight software compounded with potential human errors throughout the development and regression testing lifecycle. Risk reduction is addressed by the M&FM group but in particular by the Analysis Team working with other organizations such as S&MA, Structures and Environments, GNC, Orion, Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission (LOM) and Loss of Crew (LOC) probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and associated detection and responses to be tested in VMET to ensure reliable failure detection, and confirm responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - the ARINC 6535-partitioned Operating System, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM such as telemetry packing and processing. The baseline plan for use of VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by FSW. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure their effectiveness and performance in the exterior FSW development and test processes. This paper is outlined in a systematic fashion analogous to a lifecycle process flow for engineering development of algorithms into software and testing. Section I describes the NASA SLS M&FM context, presenting the current infrastructure, leading principles, methods, and participants. Section II defines the testing philosophy of the M&FM algorithms as related to VMET followed by section III, which presents the modeling methods of the algorithms to be tested and validated in VMET. Its details are then further presented in section IV followed by Section V presenting integration, test status, and state analysis. Finally, section VI addresses the summary and forward directions followed by the appendices presenting relevant information on terminology and documentation.

Trevino, Luis↗
NASA NTRSDate not supplied

The Genesis Non-flight Implant Sample Archive

Introduction: For the past 20 years the Genesis science community has been analyzing solar wind captured in sample collectors now curated at Johnson Space Center (JSC). Non-flown flight like collector materials (non-flight) considered reference material was always allocated by the JSC Genesis team for testing experimental procedures. However, to expedite Genesis science, distribution of non-flown reference materials were also provided by, D. S. Burnett (Genesis PI, Caltech) and A. J. G. Jurewicz (ASU) who were funded to aid all Genesis PIs by providing engineering test materials archived at Caltech pre-flight as well as ion implants into these materials [1]. Implanted materials (non-flight reference, flight-like semiconductor materials, and NIST SRM glass) received from the Caltech collection during a pilot project are being used to develop an accession procedure for the purpose of making these materials available to researchers in the future. These implant samples are important because they can be utilized as measurement standards [2]. This is a work in progress and this work reports progress in documentation and imaging. The pilot program received 63 implanted reference materials with known implanted ions. Genesis Non-Flight Database: The existing non-flight material database was modified to allow for the description of implant sessions and to allow correlation of the implant information to individual specimens. An implant session has three main components: a known ion, a known dose (ion/cm2), and a known energy (keV). Procedure: Laboratory Procedure. Upon receiving non-flight analytical standards (independently calibrated implants), or implant samples (nominally calibrated implants), they will be imaged in their current containers to capture any information written before being brought into the Genesis Sample Laboratory. Documentation is provided by the donor and used for correlating the data between the implant sessions and implant samples. This information is not verified by Genesis Curation. The microscope used to image samples in the laboratory has an automated stage with a stainless-steel plate to hold samples and a camera that utilizes the software Surveyor to take photomosaic images of the implant samples. The camera attached to the microscope is a QICAM High Performance IEEE 1394 FireWire Digital CCD Camera. This setup, shown in Fig. 1, allows for photomosaics of small-scale samples with a 10x objective or 25x objective. Examples of images taken with this microscope setup are shown in Fig.2 and Fig. 3. After imaging, samples get stored in a clean fluoroware container or polypropylene vial depending on sample size for long term storage. Database Procedure. The Genesis Non-Flight Database currently allows for the addition of implant sessions. The required fields for adding an implant session are the implant session ion, the implant session dose, and the implant session energy. There are also fields for the date and vendor of the sessions as well as a field for if the session was calibrated or not. Once an implant session has been inserted into the database, additional documentation from the session can be attached. The database will automatically assign an Implant Session Number. After inserting an implant session, the implanted samples can be inserted. The fields required for an implant sample are the material of the sample and the size of the sample. The Generic name for the implant sample with be automatically generated by the database once it has been inserted. Implant sample numbers begin with 3X to distinguish from flown Genesis sample numbers. There are also fields for processors to add the location (room, cabinet, tray) and container type (fluoroware, polypropylene vial). Once an implant session and an associated sample(s) have been inserted into the database the sample can be then tied to all associated implant sessions. An implant sample can be tied to multiple implant sessions. Future work: For curation, future work consists of creating an online catalogue for implant samples as well as updating the database with more samples as we receive them. For the scientific community these implant samples have many potential uses. For Genesis research, they are directly applicable for testing and, in some cases, as analytical standards. For non-Genesis research, implants (especially calibrated implants) could be used for calibrating other, unique planetary materials [1].

C D Calva↗
DOE OSTI2020

Evaluation of Graph Analytics Frameworks Using the GAP Benchmark Suite

The analysis of connected data is an increasingly important application in high-performance computing. Such analyses can reveal fraudulent patterns in financial transactions, optimize telecommunications networks, predict information flow in social networks, etc. However, the landscape of graph analytics is highly diverse. Graph algorithms stress processor architectures differently, and no one graph can represent all topologies. Consequently, no single approach or framework is expected to be optimal for all graph analytics problems. To help make sense of this diverse landscape, we evaluated four approaches to graph analytics: GraphBLAS, Galois, BGL17, GraphIt; and compare them against hand-tuned implementations that take advantage of hardware features on our test platform. Graph- BLAS formulates graph analytics as sparse linear algebra. Galois provides syntactic constructs for data parallelism over irregular data structures. BGL17 is a generic C++ template library for implementing graph algorithms. GraphIt provides a domain- specific language to describe and optimize graph algorithms. We use the GAP Benchmark Suite to establish baseline performance and guide the side-by-side evaluation of each framework. GAP consists of 30 tests: six graph analytics algorithms (breadth- first search, single-source shortest path, PageRank, betweenness centrality, connected components, and triangle counting) run on five graphs, each with different topological characteristics (e.g., high diameter, skewed degree distribution, high average degree). High-performance reference implementations are included for each benchmark algorithm. Because a graph can be loaded into memory a number of ways (e.g., flat file on disk, compressed sparse format, data frames, retrieved from SQL or NoSQL databases), our evaluation focused on computational performance rather than I/O. Our results show the relative strengths of each framework.

Graph algorithms, Benchmarking, shared-memory prog↗
DOE OSTI2026

pyRMG: A framework for high-throughput, large-cell DFT calculations on supercomputers

Exascale computing delivers the raw power to simulate ever larger and more chemically realistic systems, but realizing this potential requires codes that can efficiently use thousands of processors. Our real-space multigrid (RMG) density functional theory (DFT) code’s grid-decomposition approach scales nearly linearly with the number of graphics processing units (GPUs), even for simulations exceeding thousands of atoms. This scalability makes RMG a compelling tool for high-throughput DFT studies of materials that would otherwise be bottlenecked in other codes (for example, by global fast Fourier transforms in plane-wave DFT). However, the limited workflow infrastructure for RMG has thus far constrained its adoption to a small user community. In this work, we present pyRMG, a Python package designed to streamline the setup and execution of RMG DFT calculations. Built on the pymatgen and ASE (Atomic Simulation Environment) computational materials science Python packages, pyRMG automates input generation and convergence checking, and it integrates with modern job schedulers (e.g., Flux) on leadership-class platforms such as Frontier and Perlmutter. Here, we demonstrate pyRMG for a high-throughput study of strain effects in 2D 2L-Bi 2 Se 3 /2L-NbSe 2 heterostructures, which offers chemical insights into this system and shows that RMG-based workflows can converge with limited user intervention.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗
NASA NTRSDate not supplied

X-Ray Computed Tomography During Preliminary Examination of Apollo Drive Tube 73001

Introduction: Starting in 2019, the Apollo Next Generation Sample Analysis (ANGSA) Program has enabled consortium studies of specially curated Apollo samples that were previously unstudied (or under studied). This began with unsealed core tube 73002 [1,2] that is the upper part of a station 3 double drive tube. More recently the pro-gram extended to the study of a variety of frozen Apollo 17 samples [3], as well as the gas extraction [4] and dis-section [5] of 73001, the lower half of the station 3 double drive tube, that was sealed under vacuum on the Moon. In this abstract we will examine the role of X-ray Computed Tomography (XCT) during the preliminary examination process for sealed core 73001, including: (1) engineering scans to aid in understanding the gas extraction process, whole-core scanning prior to opening to inform extrusion and dissection work, and (3) individual particle scanning to characterize rock fragment lithologies for follow on studies. Methodology: Sample 73001 is a 33 cm long, 4 cm diameter regolith sample collected inside a drive tube (~1 mm aluminum walls). That drive tube was sealed inside a 0.5 mm thick stainless steel (SS) Core Sample Vacuum Container (CSVC). XCT scans for engineering purposes were done on the Nikon XTH 320 system at Johnson Space Center using the 225 kV multi-metal reflection source at 215 kV, 179 A, and a 38.49 m voxel size. Individual >4 mm particles separated from the core during processing (then triply sealed in Teflon bags) were also scanned at JSC using the 180 kV source at 90 kV, 33 A, and a 2.98 – 10.65 m voxel size. Whole-core scans were done at the University of Texas High-Resolution X-ray Computed Tomography Facility (UTCT) on the 225 kV reflection source on the North Star Imaging cabinet XCT system. These scans included: (1) a series of 9 overlapping super-resolution scans each covering a ~4 cm length of the tube at 190 kV, 180 µA, and a 12.9 µm voxel size and (2) a lower resolution continuous helical scan of the entire core at 190 kV, 180 µA, and a 51.8 µm voxel size. Progress and Results: Before piercing and extracting the gas from sample 73001, an XCT scan of the bottom portion of the CSVC was used to confirm the location of the Teflon cap on the inner drive tube, to ensure it was not accidentally pierced during gas extraction. Similarly, after piercing, the bottom and top portions of the CSVC were scanned in order to capture engineering knowledge about the results of the piercing process, as well as the metal knife edge vacuum seal (SS into In-Ag alloy). Both scans will provide constraints on future work of this type, particularly for samples collected during the Artemis mission. Another finding from these "engineering" scans was that the device in the drive tube that immobilizes the regolith (the keeper) was not seated in the tube properly. This meant that (1) the drive tube could not be removed from the CSVC for the trip to UTCT, and (2) the procedure for opening and extruding the drive tube had to be modified. Had either of these things not been known prior to opening the CSVC, it could have led to an inability to XCT scan the whole core at high resolution and/or potential disruption of the core stratigraphy during extrusion. At UTCT, the entire length of the core was scanned at high resolution (12.9 microns per voxel). This scan serves multiple purposes: (1) A lower resolution (and uncorrected) version of these scans stitched together was used to help inform the processors of potential pitfalls during extrusion and dissection; and (2) the full resolution corrected data will serve as the permanent in situ record of the stratigraphy of the sample and will enable future researchers to perform a variety of analyses. So far, 92 of the 121 >4 mm particles separated during dissection pass 1 of sample 73001 have been individually scanned. These scans clearly show the lithology of each particle while keeping the particles in pristine condition. Because of the dust adhering to particle exteriors it would otherwise be impossible to determine lithologies in a non-contaminating way. Thus far the types of lithologies seen in sample 73001 (e.g., regolith breccias, impact-melt breccias, agglutinates, and basalts) are similar to those previously identified in sample 73002 [2]. By the time of the meeting, all particles from all 3 dissection passes will have been scanned and statistics on the different lithologies in 73001 compiled. References: [1] Shearer et al. (2020) 51st LPSC, abstract 1181. [2] Zeigler et al. (2020) 51st LPSC, abstract 3023. [3] Kent et al. (2022) This Volume. [4] McDonald et al. (2022) European Lunar Symposium. [5] Gross et al (2022) This volume.

Moon↗
NASA NTRSDate not supplied

X-Ray Computed Tomography of Apollo Drive Tube 73001 as Part of the Apollo Next Generation Sample Analysis Program

Introduction: Starting in 2019, the Apollo Next Generation Sample Analysis (ANGSA) Program has enabled consortium studies of specially curated Apollo samples that were previously unstudied (or under studied). This program was intended as a participating scientist program for these Apollo samples, as well as a preparation for upcoming lunar sample return missions (e.g., Artemis). The work began with studies of unsealed core tube 73002 [1,2] that is the upper ~35 cm of an Apollo 17 double drive tube (~70 cm total depth) collected on the landslide deposit near Lara Crater at Station 3 in the Taurus Littrow Valley. More recently the program extended to the study of a variety of frozen Apollo 17 samples [3], as well as the gas extraction [4] and dissection [5] of 73001, the lower half of the station 3 double drive tube. Sample 73001 was sealed under vacuum on the Moon in a Core Sample Vacuum Container (CSVC). In this abstract we will examine the role of X-ray Computed Tomography (XCT) during the preliminary examination process for sealed core 73001, including: (1) engineering scans to aid in understanding the gas extraction process, (2) whole-core scanning prior to opening to inform extrusion and dissection work, and (3) individual particle scanning to characterize rock fragment lithologies for follow on studies. Methodology: Sample 73001 is a 33 cm long, 4 cm diameter regolith sample collected inside a lunar drive tube (~1 mm aluminum walls). That drive tube was sealed inside a 0.5 mm thick stainless steel (SS) CSVC. XCT scans for engineering purposes were done on the Nikon XTH 320 system at Johnson Space Center using the 225 kV multi-metal reflection source at 215 kV, 179 A, and a 38.49 m voxel size. Individual >4 mm particles separated from the core during processing (then triply sealed in Teflon bags) were also scanned at JSC using the 180 kV source at 90 kV, 33 A, and a 2.98 – 10.65 m voxel size. Whole-core scans were done at the University of Texas High-Resolution X-ray Computed Tomography Facility (UTCT) on the 225 kV reflection source on the North Star Imaging cabinet XCT system. These scans included: (1) a series of 9 overlapping super-resolution scans each covering a ~4 cm length of the tube at 190 kV, 180 µA, and a 12.9 µm voxel size and (2) a lower resolution continuous helical scan of the entire core at 190 kV, 180 µA, and a 51.8 µm voxel size. Progress and Results: Before piercing and extracting the gas from sample 73001, an XCT scan of the bottom portion of the CSVC was used to confirm the location of the Teflon cap on the inner drive tube and whether there was an “air” gap between the Teflon cap and the CSVC. This was to ensure the Teflon cap (which immobilized the soil inside the drive tube) was not accidentally pierced during gas extraction. Similarly, after piercing, the bottom and top portions of the CSVC were scanned in order to capture engineering knowledge about the results of the piercing process, as well as the metal knife edge vacuum seal (SS into an In-Ag alloy). Both scans will provide constraints on future work of this type, both for the design of tools used on the lunar surface during Artemis, as well as how we open future samples of this type. An unexpected finding from these engineering scans was that the device in the drive tube that immobilizes the regolith (the keeper) was not seated in the tube properly. This meant that (1) the drive tube could not be removed from the CSVC for the trip to UTCT, and (2) the procedure for opening and extruding the drive tube had to be modified. Had either of these things not been known prior to opening the CSVC, it could have led to an inability to XCT scan the whole core at high resolution and/or potential disruption of the core stratigraphy during extrusion. At UTCT, the entire length of the core was scanned at high resolution (12.9 microns per voxel). This scan serves multiple purposes: (1) A lower resolution (and uncorrected) version of these scans stitched together was used to help inform the processors of potential pitfalls during extrusion and dissection (voids, angular fragments at the edges of the sample, etc.); and (2) the full resolution corrected data will serve as the permanent in situ record of the stratigraphy of the sample and will enable future researchers to perform a variety of analyses. All 121 >4 mm particles separated during dissection pass 1 of sample 73001 have been individually scanned. These scans clearly show the lithology of each particle while keeping the particles in pristine condition (they are individually triply bagged in Teflon within our N2 purged processing cabinets). Because of the dust adhering to particle exteriors, it would otherwise be impossible to determine lithologies in a non-contaminating way. Thus far the types of lithologies seen in sample 73001 (e.g., regolith breccias, impact-melt breccias, agglutinates, and bas-alts) are similar to those previously identified in sample 73002 [2]. By the time of the meeting, all particles from all 3 dissection passes will have been scanned and statistics on the different lithologies in 73001 compiled. References: [1] Shearer et al. (2020) 51st LPSC, abstract 1181. [2] Zeigler et al. (2020) 51st LPSC, abstract 3023. [3] Kent et al. (2022) This Volume. [4] McDonald et al. (2022) European Lunar Symposium. [5] Gross et al (2022) This volume.

Moon↗
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.↗