Engineering topics

Riley, Christopher

Publications and source records attributed to Riley, Christopher.

4 records

NASA NTRS2020

Operational Techniques for Dealing with Long Eclipses During the MMS Extended Mission

Launch window design for the Magnetospheric Multiscale (MMS) mission ensured that no excessive eclipses would be encountered during the prime mission. However, no orbit solutions exist that satisfy the eclipse constraints indefinitely: most extended mission years contain 1-3 eclipses long enough to potentially damage either the spacecraft or its scientific instruments. Two steps were taken to improve the situation. Firstly, raising apogee radius from 25 to 29.34 Earth radii altered the Sun-Earth-MMS phasing, so efficiently achieving reductions in the long eclipse durations. These maneuvers were performed early this year, in preparation for the first pair of long eclipses in August 2019. Secondly, a set of operational steps were taken around the time of the eclipses to help maintain spacecraft and instrument temperatures while preventing power load shedding. These operational steps included raising key onboard temperatures through adjusting the spacecraft attitude to tilt the instrument deck towards the Sun, and engaging select heaters prior to going into eclipses. In addition, all scientific instruments were turned off, as well as high-power, non-critical spacecraft systems, to conserve energy.These steps each came with trade-offs which will be discussed in the paper. Finally, the results that were obtained when the spacecraft experienced the first extremely long eclipses will be discussed, as will lessons learned for future long eclipses.

Williams, Trevor↗

NASA NTRS2011

Space Transportation System Liftoff Debris Mitigation Process Overview

Liftoff debris is a top risk to the Space Shuttle Vehicle. To manage the Liftoff debris risk, the Space Shuttle Program created a team with in the Propulsion Systems Engineering & Integration Office. The Shutt le Liftoff Debris Team harnesses the Systems Engineering process to i dentify, assess, mitigate, and communicate the Liftoff debris risk. T he Liftoff Debris Team leverages off the technical knowledge and expe rtise of engineering groups across multiple NASA centers to integrate total system solutions. These solutions connect the hardware and ana lyses to identify and characterize debris sources and zones contribut ing to the Liftoff debris risk. The solutions incorporate analyses sp anning: the definition and modeling of natural and induced environmen ts; material characterizations; statistical trending analyses, imager y based trajectory analyses; debris transport analyses, and risk asse ssments. The verification and validation of these analyses are bound by conservative assumptions and anchored by testing and flight data. The Liftoff debris risk mitigation is managed through vigilant collab orative work between the Liftoff Debris Team and Launch Pad Operation s personnel and through the management of requirements, interfaces, r isk documentation, configurations, and technical data. Furthermore, o n day of launch, decision analysis is used to apply the wealth of ana lyses to case specific identified risks. This presentation describes how the Liftoff Debris Team applies Systems Engineering in their proce sses to mitigate risk and improve the safety of the Space Shuttle Veh icle.

Mitchell, Michael↗

NASA NTRS2011

Space Shuttle Systems Engineering Processes for Liftoff Debris Risk Mitigation

This slide presentation reviews the systems engineering process designed to reduce the risk from debris during Space Shuttle Launching. This process begins the day of launch from the tanking to the vehicle tower clearance. Other debris risks (i.e., Ascent, and micrometeoroid orbital debit) are mentioned) but are not the subject of this presentation. The Liftoff debris systems engineering process and an example of how it works are reviewed (i.e.,STS-119 revealed a bolt liberation trend on the Fixed Service Structure (FSS) 275 level elevator room). The process includes preparation of a Certification of Flight Readiness (CoFR) that includes (1) Lift-off debris from previous mission dispositioned, (2) Flight acceptance rationale has been provided for Lift-off debris sources/causes (3) Lift-off debris mission support documentation, processes and tools are in place for the up-coming mission. The process includes a liftoff debris data collection that occurs after each launch. This includes a post launch walkdown, that records each liftoff debris, and the entry of the debris into a database, it also includes a review of the imagery from the launch, and a review of the instrumentation data. There is also a review of the debris transport analysis process, that includes temporal and spatial framework and a computational fluid dynamics (CFD) analysis. which incorporates a debris transport analyses (DTA), debris materials and impact tests, and impact analyses.

Mitchell, Michael↗

NASA NTRS2001

High-Performance Java Codes for Computational Fluid Dynamics

The computational science community is reluctant to write large-scale computationally -intensive applications in Java due to concerns over Java's poor performance, despite the claimed software engineering advantages of its object-oriented features. Naive Java implementations of numerical algorithms can perform poorly compared to corresponding Fortran or C implementations. To achieve high performance, Java applications must be designed with good performance as a primary goal. This paper presents the object-oriented design and implementation of two real-world applications from the field of Computational Fluid Dynamics (CFD): a finite-volume fluid flow solver (LAURA, from NASA Langley Research Center), and an unstructured mesh adaptation algorithm (2D_TAG, from NASA Ames Research Center). This work builds on our previous experience with the design of high-performance numerical libraries in Java. We examine the performance of the applications using the currently available Java infrastructure and show that the Java version of the flow solver LAURA performs almost within a factor of 2 of the original procedural version. Our Java version of the mesh adaptation algorithm 2D_TAG performs within a factor of 1.5 of its original procedural version on certain platforms. Our results demonstrate that object-oriented software design principles are not necessarily inimical to high performance.

Riley, Christopher↗