SEARCH · Engineering Papers
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.
Sea surface temperature data are contained in the following categories: tapefile format, raw file format, bin format, GRD format, MFM file format, SZM format, MRG file format, and DIF file format.
The M-9 Shock and Detonation Physics group executes experiments on gun and explosive platforms with large numbers of oscilloscopes used for data acquisition. The data acquisition from these oscilloscopes was automated many years ago using a custom piece of software called RunDig . The default save format from this software is a custom structure referred to as "NUM-DAT" format. This file format includes a text ".DAT" file which is a header file used to interpret the binary ".NUM" file which contains the oscilloscope data. The data save format was originally developed by John Vorthman and has been in use by M-9 personnel for over 20 years. This data format has been used for archiving data from experiments performed by M-9 personnel at TA-40, TA-39, and the TA-55 Impact Test Facility. Numerous custom analysis and visualization programs have also been developed, and continue to be used, that utilize this data format. This document describes the NUM-DAT format and provides code examples for reading the format and converting it to other formats.
A tessellated output file format describing a computer-aided design (CAD) model including a plurality of vertices, a plurality of curves, a plurality of surfaces, and at least one volume, the tessellated output file format comprising base polygon data, a vertex metadata container, a curve metadata container, and a surface metadata container. The base polygon data defines the CAD model for additive manufacturing and includes a plurality of connected polygons, each polygon including a plurality of nodes, a plurality of edges, and a face. The vertex metadata container includes a listing of CAD model vertices and one polygon node associated with each CAD model vertex. The curve metadata container includes a listing of CAD model curves and at least one polygon edge associated with each CAD model curve. The surface metadata container includes a listing of CAD model surfaces and at least one polygon face associated with each CAD model surface.
The historical NTS *.dig data formal is not widely known. I document the proper *.dig file format. I include the MATLAB code used to read *.dig files with the historical data analysis software, "eXreme Las Vegas".
The ICARTT (International Consortium for Atmospheric Research on Transport and Transformation) standards were developed to fulfill data management needs for the ICARTT campaign in 2004. The ICARTT file format is text-based and composed of a header with important data description information and the data section. The ICARTT format, built on the NASA Ames and GTE data formats, was created to facilitate data exchange and promote collaborations among the science teams for achieving the ICARTT campaign goals. Due to the success of the ICARTT campaign, the ICARTT file format was exposed to a broad range of airborne researchers and was adopted for use in many other field campaigns sponsored by NASA and other partner agencies. The ICARTT format standards became a NASA standard in 2010 and was amended in January 2017 providing many enhancements, including the requirement for variable standard names. Primarily designed for airborne field studies, ICARTT has been further utilized for ground-based studies. The ICARTT format can host metadata that is critical for proper use of the data, especially for in-situ measurements. However, the information that needs to be included is often in free text, meaning the information are human readable, but not machine interpretable. Furthermore, the amount and type of information provided can vary substantially between principal investigators and campaigns. To support interoperability and FAIR principles, further enhancements to the ICARTT standards are recommended. Possible recommendations include standardizing timestamps for easier data comparisons and analysis; potential use of controlled and consistent vocabulary for variable short name and certain common metadata elements; and providing guidance on variable measurement units and how they are reported.
Suborbital campaigns aim to accomplish a wide variety of goals and can include a variety of platforms, instruments, and parameters measured. In 2004, the ICARTT (International Consortium for Atmospheric Research on Transport and Transformation) standards were developed to fulfill data management needs for the ICARTT campaign. The ICARTT file format is text-based and composed of a header with important data description information and the data section. Built on the NASA Ames and GTE data formats, the ICARTT format was created to facilitate data exchange and promote collaborations among the science teams for achieving the ICARTT campaign goals. Due to its success and adaptation for use in many other field campaigns, the ICARTT file format became a NASA standard in 2010 and was amended in January 2017. These changes provided many enhancements, including the requirement for variable standard names. Primarily designed for airborne field studies, ICARTT has been further utilized for ground-based studies. NASA has made a commitment to build an inclusive open science community over the next decade. Open-source science strives to make publicly funded scientific research transparent, inclusive, accessible, and reproducible. The ICARTT format can host metadata that is critical for proper use of the data, particularly for in-situ measurements, and can enhance data discovery and accessibility. However, the required fields are often free text, meaning that the information is human readable, but not machine interpretable. Furthermore, the amount and type of information provided can vary significantly between principal investigators and campaigns. To support FAIR principles and interoperability, enhancements to the ICARTT standards are recommended. Possible recommendations include potential use of controlled and consistent vocabulary for variable standard name and certain common metadata elements; standardizing timestamps for easier data comparisons and analysis; and providing guidance on variable measurement units and how they are reported. Enhancing ICARTT metadata can further streamline the process to make suborbital data more readily available to the data user and improve variable-level metadata. Providing more variable-level metadata can enhance data searching and discovery, supporting NASA’s Open-Source Science Initiative (OSSI).
A method of generating a tessellated output file comprising receiving a computer-aided design (CAD) model file defining a CAD model including a plurality of vertices, a plurality of curves, a plurality of surfaces, and at least one volume; generating base polygon data defining the CAD model for additive manufacturing, the base polygon data including a plurality of connected polygons, each polygon including a plurality of nodes, a plurality of edges, and a face; generating data for a vertex metadata container including a listing of CAD model vertices and one polygon node associated with each CAD model vertex; generating data for a curve metadata container including a listing of CAD model curves and at least one polygon edge associated with each CAD model curve; and generating data for a surface metadata container including a listing of CAD model surfaces and at least one polygon face associated with each CAD model surface.
TOAD utilities machine-independent and require minimal central memory. Transferable Output ASCII Data (TOAD) file-format computer program facilitates transfer of data files from one computer installation to another. TOAD files preferred type and record length, easy to edit, read, and write on magnetic tape or transfer across communications networks. Applications programs write TOAD files directly and conform to all ANSI FORTRAN 77 standards.
At the NSF-DOE Vera C. Rubin Observatory we write data from the LSSTCam and LATISS instruments using FITS format with one file written per detector. Here we discuss the layout of those FITS files and describe the FITS headers.
Radiation portal monitors (RPMs) are widely used at border security checkpoints to detect the presence of radioactive materials in people, vehicles, and cargo. Typically, RPM detection systems consist of two pillars equipped with gamma and neutron detectors. To improve detection efficiency, RPMs employ techniques such as a limited energy window, dynamic alarm thresholds, and lead shielding. However, without continuous monitoring of background radiation, signal interpretation can be compromised, because environmental factors and mechanical failures can cause fluctuations. Here, we introduce a daily file format that logs gamma background and neutron background radiation levels continuously over a 24 h period; this format is different from traditional formats that record data only when the RPM is active or occupied. The approach enables RPM operators and analysts to (1) identify and diagnose malfunctioning components, (2) adjust system settings to account for dynamic environmental factors, and (3) use the recorded data to characterize outer space phenomena. Continuous background reporting is essential for identifying issues such as faulty connections, voltage divider failures, and errors in background updates. Continuous background reporting also enables the detection of external influences, including nearby X-ray scanners, temperature fluctuations, rainfall, cosmic radiation, and lunar phase changes. These data files are designed to be easily evaluated and parsed using common tools, and a quick review by an expert is often sufficient for problem diagnosis. We anticipate that continuous background radiation monitoring and these new strategies will significantly improve the accuracy and reliability of RPM systems, reducing the rate of false alarms and enhancing overall system performance.
To perform Micrometeoroid and Orbital Debris (MMOD) analyses, NASA describes the orbital debris particle environment using the ORDEM 3 tool and the micrometeoroid environment using the MEM 3 tool. Both output files that detail the flux of particles as a function of several parameters. European MMOD analyses use different tools to perform similar functions, including the Meteoroid And Space debris Terrestrial Environment Reference (MASTER) environment model, which outputs flux data in the Standard Environment Interface (STENVI) format. The NASA Johnson Space Center Hypervelocity Impact Technology Group was asked to create a converter to translate flux data from the output file formats used by ORDEM 3.x and MEM 3 into the STENVI file format. Validation was performed to ensure that the converter was reproducing the input data correctly. The Bumper 3 MMOD risk assessment tool has a capability for reading ORDEM 3.x, MEM 3, and STENVI environment file formats and was used to compare MMOD risk results generated using the converter’s output STENVI files to the risk results generated using the input ORDEM 3.x and MEM 3 igloo files. Specific point comparisons validated that the converter translated the environment data correctly, producing the intended output. However, realistic risk assessments showed that the bin methodology employed by Bumper for determining particle flux as a function of particle size when reading files in STENVI format produces much higher MMOD risk than the point-interpolation methodology used in Bumper risk assessments using ORDEM and MEM. Modifications to how Bumper 3 reads STENVI files during analyses are considered to improve Bumper’s ability to perform useful analyses with environment files in this format.
Often the Radar Cross-Section (RCS) of a target is incorrectly assumed to be a single number by those unfamiliar with electromagnetic scattering. In actuality, a target's RCS depends on many factors. These factors include radar signal frequency, radar observation angle, as well as target orientation. Another possible parameter (often not considered) is time. The RCS of targets may change over time due to movement, environmental changes, etc. In order to accurately represent the dynamic RCS of a target in a time-stepped analysis, the ability to interface with large RCS datasets efficiently is desired. To this end, a file format and API (written in C++) were developed and are described in this report.
Described is a format for writing ASCII data on a file to facilitate its transfer from one computer system to another. The TOAD format conforms to all ANSI FORTRAN 77 standards. There are two advantages in using the TOAD format. First, TOAD files are of the preferred type and record length to make them easy to edit, read from and write on magnetic tape, or transfer across communications networks. Secondly, application programs, using the TOAD format to write computational results, are more portable and the answer files easier to postprocess. TOAD utility software is listed in an appendix.
A new ASCII format for SESAME data is explicitly defined and dubbed ASCII2. This format fixes some of the onerous limitations of the legacy ASCII-styled format in addition to relaxing the FORTRAN style fixed-format layout of data tables. With the exception of the multi-tiered indexes of the legacy binary format, the new ASCII2 is more compatible with the binary in that it does not restrict the extent of various integer data (e.g., SESAME material and table numbers) to six digits nor does it restrict the extent or precision of the various floating point data. There will be very limited support of the legacy ASCII-styled formats in the future.
The Kepler space mission searches its time series data for periodic, transit-like signatures. The ephemerides of these events, called Threshold Crossing Events (TCEs), are reported in the TCE tables at the NASA Exoplanet Archive (NExScI). Those TCEs are then further evaluated to create planet candidates and populate the Kepler Objects of Interest (KOI) table, also hosted at the Exoplanet Archive. The search, evaluation and export of TCEs is performed by two pipeline modules, TPS (Transit Planet Search) and DV (Data Validation). TPS searches for the strongest, believable signal and then sends that information to DV to fit a transit model, compute various statistics, and remove the transit events so that the light curve can be searched for other TCEs. More on how this search is done and on the creation of the TCE table can be found in Tenenbaum et al. (2012), Seader et al. (2015), Jenkins (2002). For each star with at least one TCE, the pipeline exports a file that contains the light curves used by TPS and DV to find and evaluate the TCE(s). This document describes the content of these DV time series files, and this introduction provides a bit of context for how the data in these files are used by the pipeline.
We have recently reported MZA, a new and simple mass spectrometry data structure based on the broadly supported HDF5 format and created to facilitate software development. While this format is inherently supportive of application development, the availability of a core library with standard mass spectrometry utilities greatly facilitates fast software development. Here, we present a Python library, mzapy, for efficient extraction and processing of mass spectrometry data in the MZA format. In addition to raw data extraction, mzapy contains supporting utilities enabling tasks including calibration, signal processing, peak finding, and generating plots. Being implemented in pure Python with minimal and largely standardized dependencies makes mzapy uniquely suited to application development in the multi-omics domain. The free and open source mzapy is built with extensibility in mind, and future development will support cloud computing and artificial intelligence/machine learning applications. The software source code is freely available at https://github.com/PNNL-m-q/mzapy.
Explore the source record for details and available documents.
The target audience for this document is for SES_IO developers.