Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “CoTe”

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.

70 records · Page 4

Flagging and Correction of Pattern Noise in the Kepler Focal Plane Array

In order for Kepler to achieve its required less than 20 PPM photometric precision for magnitude 12 and brighter stars, instrument-induced variations in the CCD readout bias pattern (our "2D black image"), which are either fixed or slowly varying in time, must be identified and the corresponding pixels either corrected or removed from further data processing. The two principle sources of these readout bias variations are crosstalk between the 84 science CCDs and the 4 fine guidance sensor (FGS) CCDs and a high frequency amplifier oscillation on less than 40% of the CCD readout channels. The crosstalk produces a synchronous pattern in the 2D black image with time-variation observed in less than 10% of individual pixel bias histories. We will describe a method of removing the crosstalk signal using continuously-collected data from masked and over-clocked image regions (our "collateral data"), and occasionally-collected full-frame images and reverse-clocked readout signals. We use this same set to detect regions affected by the oscillating amplifiers. The oscillations manifest as time-varying moir pattern and rolling bands in the affected channels. Because this effect reduces the performance in only a small fraction of the array at any given time, we have developed an approach for flagging suspect data. The flags will provide the necessary means to resolve any potential ambiguity between instrument-induced variations and real photometric variations in a target time series. We will also evaluate the effectiveness of these techniques using flight data from background and selected target pixels.

Kolodziejczak, Jeffery J.↗

The Kepler Science Operations Center Pipeline Framework Extensions

The Kepler Science Operations Center (SOC) is responsible for several aspects of the Kepler Mission, including managing targets, generating on-board data compression tables, monitoring photometer health and status, processing the science data, and exporting the pipeline products to the mission archive. We describe how the generic pipeline framework software developed for Kepler is extended to achieve these goals, including pipeline configurations for processing science data and other support roles, and custom unit of work generators that control how the Kepler data are partitioned and distributed across the computing cluster. We describe the interface between the Java software that manages the retrieval and storage of the data for a given unit of work and the MATLAB algorithms that process these data. The data for each unit of work are packaged into a single file that contains everything needed by the science algorithms, allowing these files to be used to debug and evolve the algorithms offline.

Klaus, Todd C.↗

A Framework for Propagation of Uncertainties in the Kepler Data Analysis Pipeline

The Kepler space telescope is designed to detect Earth-like planets around Sun-like stars using transit photometry by simultaneously observing 100,000 stellar targets nearly continuously over a three and a half year period. The 96-megapixel focal plane consists of 42 charge-coupled devices (CCD) each containing two 1024 x 1100 pixel arrays. Cross-correlations between calibrated pixels are introduced by common calibrations performed on each CCD requiring downstream data products access to the calibrated pixel covariance matrix in order to properly estimate uncertainties. The prohibitively large covariance matrices corresponding to the ~75,000 calibrated pixels per CCD preclude calculating and storing the covariance in standard lock-step fashion. We present a novel framework used to implement standard propagation of uncertainties (POU) in the Kepler Science Operations Center (SOC) data processing pipeline. The POU framework captures the variance of the raw pixel data and the kernel of each subsequent calibration transformation allowing the full covariance matrix of any subset of calibrated pixels to be recalled on-the-fly at any step in the calibration process. Singular value decomposition (SVD) is used to compress and low-pass filter the raw uncertainty data as well as any data dependent kernels. The combination of POU framework and SVD compression provide downstream consumers of the calibrated pixel data access to the full covariance matrix of any subset of the calibrated pixels traceable to pixel level measurement uncertainties without having to store, retrieve and operate on prohibitively large covariance matrices. We describe the POU Framework and SVD compression scheme and its implementation in the Kepler SOC pipeline.

Clarke, Bruce D.↗

The Kepler End-to-End Model: Creating High-Fidelity Simulations to Test Kepler Ground Processing

The Kepler mission is designed to detect the transit of Earth-like planets around Sun-like stars by observing 100,000 stellar targets. Developing and testing the Kepler ground-segment processing system, in particular the data analysis pipeline, requires high-fidelity simulated data. This simulated data is provided by the Kepler End-to-End Model (ETEM). ETEM simulates the astrophysics of planetary transits and other phenomena, properties of the Kepler spacecraft and the format of the downlinked data. Major challenges addressed by ETEM include the rapid production of large amounts of simulated data, extensibility and maintainability.

Bryson, Stephen T.↗

The Kepler DB, a Database Management System for Arrays, Sparse Arrays and Binary Data

The Kepler Science Operations Center stores pixel values on approximately six million pixels collected every 30-minutes, as well as data products that are generated as a result of running the Kepler science processing pipeline. The Kepler Database (Kepler DB) management system was created to act as the repository of this information. After one year of ight usage, Kepler DB is managing 3 TiB of data and is expected to grow to over 10 TiB over the course of the mission. Kepler DB is a non-relational, transactional database where data are represented as one dimensional arrays, sparse arrays or binary large objects. We will discuss Kepler DB's APIs, implementation, usage and deployment at the Kepler Science Operations Center.

McCauliff, Sean↗

Kepler Science Operations Center Pipeline Framework

The Kepler mission is designed to continuously monitor up to 170,000 stars at a 30 minute cadence for 3.5 years searching for Earth-size planets. The data are processed at the Science Operations Center (SOC) at NASA Ames Research Center. Because of the large volume of data and the memory and CPU-intensive nature of the analysis, significant computing hardware is required. We have developed generic pipeline framework software that is used to distribute and synchronize the processing across a cluster of CPUs and to manage the resulting products. The framework is written in Java and is therefore platform-independent, and scales from a single, standalone workstation (for development and research on small data sets) to a full cluster of homogeneous or heterogeneous hardware with minimal configuration changes. A plug-in architecture provides customized control of the unit of work without the need to modify the framework itself. Distributed transaction services provide for atomic storage of pipeline products for a unit of work across a relational database and the custom Kepler DB. Generic parameter management and data accountability services are provided to record the parameter values, software versions, and other meta-data used for each pipeline execution. A graphical console allows for the configuration, execution, and monitoring of pipelines. An alert and metrics subsystem is used to monitor the health and performance of the pipeline. The framework was developed for the Kepler project based on Kepler requirements, but the framework itself is generic and could be used for a variety of applications where these features are needed.

Klaus, Todd C.↗

Selecting Pixels for Kepler Downlink

The Kepler mission monitors > 100,000 stellar targets using 42 2200 1024 pixel CCDs. Bandwidth constraints prevent the downlink of all 96 million pixels per 30-minute cadence, so the Kepler spacecraft downlinks a specified collection of pixels for each target. These pixels are selected by considering the object brightness, background and the signal-to-noise of each pixel, and are optimized to maximize the signal-to-noise ratio of the target. This paper describes pixel selection, creation of spacecraft apertures that efficiently capture selected pixels, and aperture assignment to a target. Diagnostic apertures, short-cadence targets and custom specified shapes are discussed.

Bryson, Stephen T.↗

Transiting Planet Search in the Kepler Pipeline

The Kepler Mission simultaneously measures the brightness of more than 160,000 stars every 29.4 minutes over a 3.5-year mission to search for transiting planets. Detecting transits is a signal-detection problem where the signal of interest is a periodic pulse train and the predominant noise source is non-white, non-stationary (1/f) type process of stellar variability. Many stars also exhibit coherent or quasi-coherent oscillations. The detection algorithm first identifies and removes strong oscillations followed by an adaptive, wavelet-based matched filter. We discuss how we obtain super-resolution detection statistics and the effectiveness of the algorithm for Kepler flight data.

Jenkins, Jon M.↗

Data Validation in the Kepler Science Operations Center Pipeline

We present an overview of the Data Validation (DV) software component and its context within the Kepler Science Operations Center (SOC) pipeline and overall Kepler Science mission. The SOC pipeline performs a transiting planet search on the corrected light curves for over 150,000 targets across the focal plane array. We discuss the DV strategy for automated validation of Threshold Crossing Events (TCEs) generated in the transiting planet search. For each TCE, a transiting planet model is fitted to the target light curve. A multiple planet search is conducted by repeating the transiting planet search on the residual light curve after the model flux has been removed; if an additional detection occurs, a planet model is fitted to the new TCE. A suite of automated tests are performed after all planet candidates have been identified. We describe a centroid motion test to determine the significance of the motion of the target photocenter during transit and to estimate the coordinates of the transit source within the photometric aperture; a series of eclipsing binary discrimination tests on the parameters of the planet model fits to all transits and the sequences of odd and even transits; and a statistical bootstrap to assess the likelihood that the TCE would have been generated purely by chance given the target light curve with all transits removed. Keywords: photometry, data validation, Kepler, Earth-size planets

Wu, Hayley↗

Kepler Science Operations Center Architecture

We give an overview of the operational concepts and architecture of the Kepler Science Data Pipeline. Designed, developed, operated, and maintained by the Science Operations Center (SOC) at NASA Ames Research Center, the Kepler Science Data Pipeline is central element of the Kepler Ground Data System. The SOC charter is to analyze stellar photometric data from the Kepler spacecraft and report results to the Kepler Science Office for further analysis. We describe how this is accomplished via the Kepler Science Data Pipeline, including the hardware infrastructure, scientific algorithms, and operational procedures. The SOC consists of an office at Ames Research Center, software development and operations departments, and a data center that hosts the computers required to perform data analysis. We discuss the high-performance, parallel computing software modules of the Kepler Science Data Pipeline that perform transit photometry, pixel-level calibration, systematic error-correction, attitude determination, stellar target management, and instrument characterization. We explain how data processing environments are divided to support operational processing and test needs. We explain the operational timelines for data processing and the data constructs that flow into the Kepler Science Data Pipeline.

Middour, Christopher↗

Physical State and Distribution of Materials at the Surface of Pluto from New Horizons LEISA Imaging Spectrometer

From Earth based observations Pluto is known to be the host of N2, CH4 and CO ices and also a dark red material. Very limited spatial distribution information is available from rotational visible and near-infrared spectral curves obtained from hemispheric measurements. In July 2015 the New Horizons spacecraft reached Pluto and its satellite system and recorded a large set of data. The LEISA spectro-imager of the RALPH instruments are dedicated to the study of the composition and physical state of the materials composing the surface. In this paper we report a study of the distribution and physical state of the ices and non-ice materials on Pluto's illuminated surface and their mode and degree of mixing. Principal Component analysis as well as various specific spectral indicators and correlation plots are used on the first set of 2 high resolution spectro-images from the LEISA instrument covering the whole illuminated face of Pluto at the time of the New Horizons encounter. Qualitative distribution maps have been obtained for the 4 main condensed molecules, N2, CH4, CO, H2O as well as for the visible-dark red material. Based on specific spectral indicators, using either the strength or the position of absorption bands, these 4 molecules are found to indicate the presence of 3 different types of ices: N2-rich:CH4:CO ices, CH4-rich(:CO:N2?) ices and H2O ice. The mixing lines between these ices and with the dark red material are studied using scatter plots between the various spectral indicators. CH4 is mixed at the molecular level with N2, most probably also with CO, thus forming a ternary molecular mixture that follows its phase diagram with low solubility limits. The occurrence of a N2-rich - CH4-rich ices mixing line associated with a progressive decrease of the CO/CH4 ratio tells us that a fractionation sublimation sequence transforms one type of ice to the other forming either a N2-rich - CH4-rich binary mixture at the surface or an upper CH4-rich ice crust that may hide the N2-rich ice below. The strong CH4-rich - H2O mixing line witnesses the subsequent sublimation of the CH4-rich ice lag left behind by the N2:CO sublimation (N spring-summer), or a direct condensation of CH4 ice on the cold H2O ice (S autumn). The weak mixing line between CH4-containing ices and the dark red material and the very sharp spatial transitions between these ices and this non-volatile material are probably due to thermal incompatibility. Finally the occurrence of a H2O ice - red material mixing line advocates for a spatial mixing of the red material covering H2O ice, with possibly a small amount intimately mixed in water ice. From this analysis of the different materials distribution and their relative mixing lines, H2O ice appears to be the substratum on which other ices condense or non-volatile organic material is deposited from the atmosphere. N2-rich ices seem to evolve to CH4-dominated ices, possibly still containing traces of CO and N2, as N2 and CO sublimate away. The spatial distribution of these materials is very complex. The high spatial definition of all these composition maps, as well as those at even higher resolution that will be soon available, will allow us to compare them with Pluto's geologic features observed by LORRI panchromatic and MVIC multispectral imagers to better understand the geophysical processes in action at the surface of this astonishingly active frozen world.

Schmitt, B.↗

The Kepler Science Data Processing Pipeline Source Code Road Map

We give an overview of the operational concepts and architecture of the Kepler Science Processing Pipeline. Designed, developed, operated, and maintained by the Kepler Science Operations Center (SOC) at NASA Ames Research Center, the Science Processing Pipeline is a central element of the Kepler Ground Data System. The SOC consists of an office at Ames Research Center, software development and operations departments, and a data center which hosts the computers required to perform data analysis. The SOC's charter is to analyze stellar photometric data from the Kepler spacecraft and report results to the Kepler Science Office for further analysis. We describe how this is accomplished via the Kepler Science Processing Pipeline, including, the software algorithms. We present the high-performance, parallel computing software modules of the pipeline that perform transit photometry, pixel-level calibration, systematic error correction, attitude determination, stellar target management, and instrument characterization.

Kepler pipeline software↗

Pixel-Level Calibration in the Kepler Science Operations Center Pipeline

We present an overview of the pixel-level calibration of flight data from the Kepler Mission performed within the Kepler Science Operations Center Science Processing Pipeline. This article describes the calibration (CAL) module, which operates on original spacecraft data to remove instrument effects and other artifacts that pollute the data. Traditional CCD data reduction is performed (removal of instrument/detector effects such as bias and dark current), in addition to pixel-level calibration (correcting for cosmic rays and variations in pixel sensitivity), Kepler-specific corrections (removing smear signals which result from the lack of a shutter on the photometer and correcting for distortions induced by the readout electronics), and additional operations that are needed due to the complexity and large volume of flight data. CAL operates on long (~30 min) and short (~1 min) sampled data, as well as full-frame images, and produces calibrated pixel flux time series, uncertainties, and other metrics that are used in subsequent Pipeline modules. The raw and calibrated data are also archived in the Multi-mission Archive at Space Telescope at the Space Telescope Science Institute for use by the astronomical community.

Calibration↗

Data Validation in the Kepler Science Operations Center Pipeline

We present an overview of the Data Validation (DV) software component and its context within the Kepler ScienceOperations Center (SOC) pipeline and overall Kepler Science mission. The SOC pipeline performs a transiting planetsearch on the corrected light curves for over 150,000 targets across the focal plane array. We discuss the DV strategy forautomated validation of Threshold Crossing Events (TCEs) generated in the transiting planet search. For each TCE, atransiting planet model is fitted to the target light curve. A multiple planet search is conducted by repeating the transitingplanet search on the residual light curve after the model flux has been removed; if an additional detection occurs, aplanet model is fitted to the new TCE. A suite of automated tests are performed after all planet candidates have beenidentified. We describe a centroid motion test to determine the significance of the motion of the target photocenterduring transit and to estimate the coordinates of the transit source within the photometric aperture; a series of eclipsingbinary discrimination tests on the parameters of the planet model fits to all transits and the sequences of odd and eventransits; and a statistical bootstrap to assess the likelihood that the TCE would have been generated purely by chancegiven the target light curve with all transits removed.

photometry↗

Semi-Weekly Monitoring of the Performance and Attitude of Kepler Using a Sparse Set of Targets

The Kepler spacecraft is in a heliocentric Earth-trailing orbit, continuously observing ~160,000 select stars over ~115 square degrees of sky using its photometer containing 42 highly sensitive CCDs. The science data from these stars, consisting of ~6 million pixels at 29.4-minute intervals, is downlinked only every ~30 days. Additional low-rate Xband communications contacts are conducted with the spacecraft twice a week to downlink a small subset of the science data. This paper describes how we assess and monitor the performance of the photometer and the pointing stability of the spacecraft using such a sparse data set.

Attitude reconstruction↗

Development Testing and Analysis of the Integrated Gateway-ESPRIT Bipropellant Refuelling System

The Gateway will be humanity’s first space station orbiting the Moon completed by NASA in partnership with ESA and other US and international partners. The Gateway will provide critical support to sustainable human exploration on the moon through the Artemis program. To enable the Lunar Gateway to complete its mission, on orbit refuelling is essential. The ESPRIT Refuelling Module (ERM) will provide the capability to transfer propellants, MMH and MON-3, through the Habitation and Logistics Outpost (HALO) to the Power and Propulsion Element (PPE). The transfer of these propellants carries known risks and hazards. These hazards include overpressure of the propellant lines during priming sequences between modules and during refuelling pause operations. To support the early system development and to mitigate these risks, a collaborative test program between NASA, ESA and Thales Alenia Space was completed at the Thales Alenia Space test facility in Harwell, UK. This test program integrated fluidic breadboards of the ERM, HALO and PPE modules. The objectives of the test program were to demonstrate and characterise critical performance and transient operations, inform refuelling concept of operations and to calibrate and validate numerical models of the refuelling subsystem in EcosimPro. To support the completion of this final objective a detailed model of the integrated breadboard was developed in EcosimPro and key steady-state and transient test cases were simulated. As an industry first, a National Institute of Standards and Technology (NIST) database correlation for Hydrofluoroether (HFE-7000) was used as a mixed oxides of nitrogen (MON-3) simulant with EcosimPro and European Space Propulsion System Simulation (ESPSS) libraries to result in a more accurate analysis for transient phenomenon such as priming. The test and simulation data showed good agreement validating the model for further system analysis as the ERM design progresses.

Refuelling↗