Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “data formats”

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.

At least 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRS2005

The Hierarchical Data Format for EOS (HDF-EOS)

HDF is a file format and a software library for data storage, management, exchange, and archiving. It is written and maintained by the National Center for Supercomputing Applications (NCSA). HDF5 has a very simple but versatile data model which is compatible with most competing formats. Through its grouping and linking mechanisms, the HDF5 data model enables complex data relationships and dependencies. HDF5 accommodates the inclusion of many common types of metadata and arbitrary types and quantities of user-defined metadata.

Ullman, Richard↗
NASA NTRS1982

LANDSAT-D data format control book. Volume 2: Telemetry

The formats used for the transmission of LANDSAT-D and LANDSAT-D Prime spacecraft telemetry data through either the TDRS/GSTDN via the NASCOM Network to the CSF are described as well as the telemetry flow from the command and data handling subsystem, a telemetry list and telemetry matrix assignment for the mission and engineering formats. The on-board computer (OBC) controlled format and the dwell format are also discussed. The OBCs contribution to telemetry, and the format of the reports, are covered. The high rate data channel includes the payload correction data format, the narrowband tape recorder and the OBC dump formats.

Talipsky, R.↗
DOE OSTI2025

mzPeak: Designing a Scalable, Interoperable, and Future-Ready Mass Spectrometry Data Format

Advances in mass spectrometry (MS) instrumentation, such as higher resolution, faster scan speeds, and improved sensitivity, have significantly increased the volume and complexity of data. The growing adoption of imaging and ion mobility further amplifies these challenges across MS-based omics fields, including proteomics, metabolomics, and lipidomics. While these technologies unlock new possibilities, they also present significant challenges in data management, storage, and accessibility. Existing open formats, such as the XML-based community standards mzML and imzML, struggle to meet the demands of modern MS workflows due to their large file sizes, slow data access, and limited metadata support. Vendor-specific formats, while optimized for proprietary instruments, lack interoperability, comprehensive metadata support and long-term archival reliability. This white paper lays the groundwork for mzPeak, a next-generation community data format designed to address these challenges and support high-throughput, multi-dimensional MS workflows. By adopting a hybrid model that combines efficient binary storage for numerical data and both human and machine-readable metadata storage, mzPeak will reduce file sizes, accelerate data access, and offer a scalable, adaptable solution for evolving MS technologies. For researchers, mzPeak will enable enhanced interoperability across platforms, seamless support for complex workflows including ion mobility and MS imaging, and faster data access compared to existing community formats such as mzML. Its design will ensure data is managed in compliance with regulatory standards, essential for applications such as precision medicine and chemical safety, where long-term data integrity and accessibility are critical. For vendors, mzPeak provides a streamlined, open alternative to proprietary formats, reducing the burden of regulatory compliance while aligning with the industry's push for transparency and standardization. By offering a high-performance, interoperable solution, mzPeak positions vendors to meet customer demands for sustainable data management tools which will be able to handle emerging and future data types and workflows. mzPeak aspires to become the cornerstone of MS data management, empowering researchers, vendors, and developers to innovate and collaborate more effectively.

data formats↗
NASA NTRS1995

Exchange, interpretation, and database-search of ion mobility spectra supported by data format JCAMP-DX

To assist peak assignment in ion mobility spectrometry it is important to have quality reference data. The reference collection should be stored in a database system which is capable of being searched using spectral or substance information. We propose to build such a database customized for ion mobility spectra. To start off with it is important to quickly reach a critical mass of data in the collection. We wish to obtain as many spectra combined with their IMS parameters as possible. Spectra suppliers will be rewarded for their participation with access to the database. To make the data exchange between users and system administration possible, it is important to define a file format specially made for the requirements of ion mobility spectra. The format should be computer readable and flexible enough for extensive comments to be included. In this document we propose a data exchange format, and we would like you to give comments on it. For the international data exchange it is important, to have a standard data exchange format. We propose to base the definition of this format on the JCAMP-DX protocol, which was developed for the exchange of infrared spectra. This standard made by the Joint Committee on Atomic and Molecular Physical Data is of a flexible design. The aim of this paper is to adopt JCAMP-DX to the special requirements of ion mobility spectra.

Baumback, J. I.↗
DOE OSTI2024

Bridging the Gap Between LLMs and LNS with Dynamic Data Format and Architecture Codesign

Deep neural networks (DNNs) have achieved tremendous success in the past few years. However, their training and inference demand exceptional computational and memory resources. Quantization has been shown as an effective approach to mitigate the cost, with the mainstream data types reduced from FP32 to FP16/BF16 and recently FP8 in the latest NVIDIA H100 GPUs. With increasingly aggressive quantization, however, the conventional floating-point formats suffer from limited precision in representing numbers around zero. Recently, NVIDIA demonstrated the potential of using a Logarithmic Number System (LNS) for the next generation of tensor cores. While LNS mitigates the hurdles in representing small numbers, in this work we observed a mismatch between LNS and the emerging Large Language Models (LLM), where LLM exhibits significant outliers when directly adopting the LNS format. In this paper, we present a data-format/architecture codesign to bright this gap. On the format side, we propose a dynamic LNS format to flexibly represent outliers at a higher precision, by exploiting asymmetry in the LNS representation and identifying outliers through a per-vector basis. On the architecture side, for demonstration, we realize the dynamic LNS format in a systolic array, which can handle the irregularity of the outliers at runtime. We implement our approach on an Alveo U280 FPGA as a prototype. Experimental results show that our design can effectively handle the outliers and resolve the mismatch between LNS and LLM, contributing to an accuracy improvement of 15.4% and 16% over the floating-point and the original LNS baselines, using four state-of-the-art LLM models. Our observation and design lay a solid foundation for the large-scale adoption of the LNS format in the next-generation deep learning hardware.

Haghi, Pouya↗
NASA NTRS2024

PACE Technical Report Series, Volume 12: The PACE Level 1C data format

NASA's Plankton, Aerosol, Cloud, ocean Ecosystem (PACE) mission will make global ocean color and atmospheric measurements to provide extended data records of ocean ecology and global biogeochemistry, along with polarimetric measurements for advanced observations of aerosols, clouds and the ocean. PACE will contain three instruments: the primary Ocean Color Instrument (OCI), and two multi-angle polarimeters (MAPs). The latter instruments are contributed under a ‘Do-No-Harm’ (to the rest of the PACE mission) principle, and the PACE Science Data Processing System (SDPS) is only required to produce Level-1b (geolocated radiances with calibration applied) data without performance requirements. However, there is a strong desire to produce data in a format that merges the disparate spatial resolutions, viewing geometry and sampling nature of the three instruments. Our terminology for this format is Level 1c (L1C). This format will be an input to Level 2 algorithms produced from standalone MAP instrument observations, or from algorithms employing multi-sensor fusion. Creating the L1C format has several components. This includes choice of projection method, the means by which multi-angle views are properly incorporated into that projection (‘aggregation’) the means to represent wavelength and light polarization state, the selection of data to be included within the L1C file, and the handling of ancillary data either required for L1C file generation or needed in that format for L2 processing.

PACE↗
DOE OSTI2026

Precision of ENDF and ENDL Formatted Data Files

The purpose is to ensure that today’s processing codes produced output to meet today’s accuracy needs. Since 1958 ENDL and about 1965 ENDF have each used a text format to define nuclear and atomic data in 11 columns for each data field. When these formats originated this was judged to be adequate to reproduce the accuracy of data at the time and to meet the needs of our applications. When these formats originated the dominant computer language of the day was FORTRAN and if written using an E11.4 format it would include only 4 or 5 digits of precision, e.g., 0.1234E-03 or 1.2345E-02, varying from one computer/system to another the result was not even unique. In the case of ENDF the 4 digit precision was not even adequate to uniquely define the atomic weight of the target, e.g., U238 = 92238 = 0.9224E+5 = WRONG! From its inceptions the ENDF format had a precision problem. One of my first tasks when in 1967 fresh out of graduate school I joined what later became the National Nuclear Data Center (NNDC), was to address this precision problem. By working with ENDF producers and users throughout the U.S. we verified, 1) E or D is not required to define FORTRAN readable numbers, e.g., E+4 or +4 are both o.k. 2) With ENDF energy eV and cross section in barns, 2 digit exponents are almost never required. 3) Since energy is never negative we could use the first of the 11 columns for a digit. Knowing this allowed us to produce ENDF/B-II to 6 or 7 digit precision, e.g., blank, decimal point, 2 or 3 digit exponent, e.g., ^1.23456-12 or ^1.234567-3. Below is an example of the actual ENDF/B-II data released. Note, the date 1970 and the atomic weight, ZA, uniquely defined to 6-digit accuracy, ^9.22350+ 4.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
NASA NTRS2001

TAXI Direct-to-Disk Interface Demultiplexes Proprietarily Formatted Data

The TAXI Direct-to-Disk interface is a special-purpose interface circuit for demultiplexing of data from a Racal Storeplex (or equivalent) multichannel recorder onto one or more hard disks that reside in, and/or are controlled by, a personal computer (PC). (The name TAXI as used here is derived from the acronym TAXI, which signifies transparent asynchronous transceiver interface.) The TAXI Direct-to-Disk interface was developed for original use in capturing data from instrumentation on a test stand in a NASA rocket-testing facility. The control, data-recording, and data-postprocessing equipment of the facility are located in a control room at a safe distance from the test stand. Heretofore, the transfer of data from the instrumentation to the postprocessing equipment has entailed post-test downloading via software, requiring many hours to days of post-test reduction before the data could be viewed in a channelized format. The installation of the TAXI Direct-to-Disk interface, in conjunction with other modifications, causes the transfer of data to take place in real time, so that the data are immediately available for review during or after the test. The instrumentation is connected to the input terminals of the signal-processing unit of multichannel recorder by standard coaxial cables. The coaxial output of the signal processing unit is converted to fiber-optic output by means of a commercial coaxial-cable/fiber-optic converter (that is, a fiber-optic transceiver) designed specifically for this application. The fiber-optic link carries the data signals to an identical fiber-optic transceiver in the control room. On the way to the TAXI Direct-to-Disk interface that is the focus of this article, the data signals are processed through a companion special purpose circuit denoted by the similar name parallel TAXI interface.

Newnan, Bruce G.↗
NASA NTRS1982

LANDSAT-D data format control book. Volume 6, appendix A: Partially processed thematic mapper High Density Tape (HDT-AT)

One of the outputs of the data management system being developed to provide a variety of standard image products from the thematic mapper and the multispectral band scanners on LANDSAT 4, is the partially processed TM data (radiometric corrections applied and geometric correction matrices for two projections appended) which is recorded on a 28-track high density tape. Specifications are presented for the format of the recorded data as well as for the time code and the major and minor frames of the tape. Major frame types, formats, and field definitions are included.

Jai, A.↗
NASA NTRS1990

General-Purpose Data-Formatting Input/Output System

Multiplexable input/output (I/O) system developed as interface between host computer and real-time, fixed-base simulator cockpit. Unit designed to be general-purpose interface and operated through virtually any 8- or 16-bit, transistor/transistor-logic-level, parallel-I/O port with or without handshaking. Accepts byte-coded data in form of data blocks from host computer and routes data to various system I/O modules like discrete outputs, lamp drivers, and seven-segment-display drivers. Formats and routes data from input modules back to host computer. Other modules designed to drive alphanumeric displays and communications interfaces and to serve as analog-to-digital and digital-to-analog converter modules.

Busquets, Anthony M.↗
NASA NTRS1981

LANDSAT-D data format control book. Volume 6, appendix K: Unprocessed multispectral scanner high density tape (HDT-RM/HDT-GM)

Unprocessed MSS data which is recorded on HDT-RM (a 28 track, high density tape) and on HDT-GM (a 14 track, nonbias recorded, high density tape) are inputs for the LANDSAT 4 data management system. All MSS data initially recorded on HDT-GM are copied to HDT-RM prior to processing. This specification establishes the requirements for the format of the LANDSAT D HDT-RM/HDT-GM.

Andersen, K. E.↗
NASA NTRS1978

Variable length data formats

The purpose of this paper is to discuss a number of variable length floating point and integer formats and to give the various advantages and disadvantages of their use. Often it is known in advance that a given integer will not exceed a certain magnitude or that a particular floating point number is accurate to only 'n' places of accuracy. Faced with this, it is good engineering to choose variable length floating point and integer formats which require the least amount of hardware or the minimum amount of software or which have some other dominant advantage. The formats discussed have the advantage that length change algorithms are invariant with respect to data types (unsigned, signed, floating point, integers, and complex numbers). The STARAN associative array processor, which uses a completely variable fixed point and floating point formats, is described.

Brakefield, J. C.↗
NASA NTRS1981

LANDSAT-D data format control book. Volume 6: (Products)

Four basic product types are generated from the raw thematic mapper (TM) and multispectral scanner (MSS) payload data by the NASA GSFC LANDSAT 4 data management system: (1) unprocessed data (raw sensor data); (2) partially processed data, which consists of radiometrically corrected sensor data with geometric correction information appended; (3) fully processed data, which consists of radiometrically and geometrically corrected sensor data; and (4) inventory data which consists of summary information about product types 2 and 3. High density digital recorder formatting and the radiometric correction process are described. Geometric correction information is included.

Kabat, F.↗
DOE OSTI2015

Active Management of Integrated Geothermal-CO2 Storage Reservoirs in Sedimentary Formations: Data used in Geosphere Journal Article

This data submission is for Phase 2 of Active Management of Integrated Geothermal-CO2 Storage Reservoirs in Sedimentary Formations, which focuses on multi-fluid (CO2 and brine) geothermal energy production and diurnal bulk energy storage in geologic settings that are suitable for geologic CO2 storage. This data submission includes all data used in the Geosphere Journal article by Buscheck et al (2016). All assumptions are discussed in that article.

15 GEOTHERMAL ENERGY↗
DOE OSTI2024

SG50 Data-format Requirement Document for an Automatically Readable, Comprehensive and Curated Experimental Reaction Database MEDUSA

This report constitutes the requirement document that guides the development of the experimental reaction database, MEDUSAL (Machine-readable Experimental Data User App & Library), created by OECD/NEA/WPEC SubGroup 50. Experimental reaction data are usually stored in the EXFOR library in EXFOR format. With MEDUSAL, the WPEC sub-group 50 wants to go beyond the EXFOR format and database to generate a library that is (a) automatically readable, (b) comprehensive, and (c) curated.

Nuclear Criticality Safety Program (NCSP)↗
DOE OSTI2024

SG50 Data-format Specifications Document for the Automatically Readable, Comprehensive, and Curated Experimental Reaction Database MEDUSAL

The aim of this document is to lay out a first draft of the specifications for the MEDUSAL database (Machine-readable Experimental Data User App & Library) that is being described by OECD/NEA/WPEC SG-50. The EXFOR database (Otuka et al., 2014) has a format that is based on code-value pairs, and a significant portion of the information in the EXFOR entry is contained in free text sections. Several high-level requirements for the MEDUSAL database, as laid out in the Use Cases and Requirements Working Paper (citation), relate to the definition of the specifications

Nuclear Criticality Safety Program (NCSP)↗