Search NASA⌕ Search

SEARCH · Search NASA

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 37 records · Page 2

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↗

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)↗

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)↗

2025 TEM Workshop

The TEM Data Management Workshop will take place on August 26 from 9 a.m. to 12 p.m. MT, and will be held virtually on TEAMS. The primary goal of this workshop is to engage NSUF users and stakeholders in discussions about the data needs for the utilization of AI and ML in the analysis of TEM data. Key topics to be covered include data storage, data sharing, data tagging, metadata inclusion, standardized data formats, data augmentation, and annotated training datasets. Additionally, the workshop will provide valuable insights into resources such as the Nuclear Research Data System (NRDS) for data storage and sharing, as well as open-source codes for data analysis.

Bachhav, Mukesh↗

ENDFtk: A robust tool for reading and writing ENDF-formatted nuclear data

ENDFtk is a recently developed C++ and Python interface to interact with ENDF-6 formatted nuclear data files. It provides a robust and complete interface, allowing the reading and writing of all formats currently part of the ENDF-6 formats manual, as well as some non-ENDF formats used by the NJOY processing code. It provides an interface that mimics the names in the ENDF-6 formats manual as well as an equivalent interface using human-readable attribute names. It is robust and powerful enogh for nuclear data experts to develop complex applications, while also simple enough to be used non-experts to retrieve and manipulate evaluated nuclear data. ENDFtk offers the ability to easily interrogate and manipulate data either in large-scale code projects or in simple Python scripts. Here, in this paper, a brief overview of the interface is given, as well as more substantial examples demonstrating plotting simple data, interacting with more complex data, and writing new data to files. ENDFtk is open source and available for download via GitHub (https://github.com/njoy/ENDFtk).

97 MATHEMATICS AND COMPUTING↗

Enabling FAIR data in Earth and environmental science with community-centric (meta)data reporting formats

Abstract Research can be more transparent and collaborative by using Findable, Accessible, Interoperable, and Reusable (FAIR) principles to publish Earth and environmental science data. Reporting formats—instructions, templates, and tools for consistently formatting data within a discipline—can help make data more accessible and reusable. However, the immense diversity of data types across Earth science disciplines makes development and adoption challenging. Here, we describe 11 community reporting formats for a diverse set of Earth science (meta)data including cross-domain metadata (dataset metadata, location metadata, sample metadata), file-formatting guidelines (file-level metadata, CSV files, terrestrial model data archiving), and domain-specific reporting formats for some biological, geochemical, and hydrological data (amplicon abundance tables, leaf-level gas exchange, soil respiration, water and sediment chemistry, sensor-based hydrologic measurements). More broadly, we provide guidelines that communities can use to create new (meta)data formats that integrate with their scientific workflows. Such reporting formats have the potential to accelerate scientific discovery and predictions by making it easier for data contributors to provide (meta)data that are more interoperable and reusable.

54 ENVIRONMENTAL SCIENCES↗

UPS XML Format and Data

This is the XML data and format for UPS supercomponent including subcomponents: Grid following inverter (GFL), Grid forming inverter (GFM), and dc-dc converter connected to the energy storage and the AI load.

Marthi, Phani Ratna Vanamali [ORNL] (ORCID:0000000↗

Radiation portal monitor data file format for comprehensive background radiation monitoring

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.

Background radiation monitoring↗

Isolated data processing modules

This disclosure relates to computer systems that isolate data processing modules and methods of operating the same. In one embodiment of a method, a computer system receives a first data processing request for a first data file. The computer system may determine that a first data type of the first data file is supported by an encapsulated data processing module and determine a first communication protocol from a set of communication protocols that can be used to receive the first data file. The computer system can then receive the first data file from the first storage location in accordance with the first communication protocol and the encapsulated data processing module may be executed to convert the first data file in the first data format into second data in a second data format.

Penton, Joshua Michael↗

High-Fidelity, Large-Scale, Realistic Dataset Development

The final report summarizes the work performed for supporting the ARPA-E Grid Optimization Competition (Challenge 2 and Challenge 3) within the stated period. Challenge 2 For the challenge period, the main responsibility of the team is to investigate, gen- erate, and deliver parts of the data sets for the competition, based on the competition model for Challenge 2, existing data sets from Challenge 1, and data source supplied by other data set teams. Challenge 3 For the challenge period, the main responsibility of the team is to propose, create, deliver, and maintain the data format during the competition period. The data format will specify how the benchmark data will be represented and communicated to competitors. It will also specify how competitors should report back the solutions. The data format will be closely aligned with the problem formulation (maintained by the formulation team) and the solution validation process (maintained by the validation team). Our team is also responsible in investigating, generating, and delivering parts of the data sets for the competition. The data sets will be created based on the competition model for Challenge 3, existing data sets from Challenge 1 and Challenge 2, and data source supplied by other data set teams.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗

Data from: “Enabling FAIR data in Earth and environmental science with community-centric (meta)data reporting formats”

This dataset contains supplementary information for a manuscript describing the ESS-DIVE (Environmental Systems Science Data Infrastructure for a Virtual Ecosystem) data repository's community data and metadata reporting formats. The purpose of creating the ESS-DIVE reporting formats was to provide guidelines for formatting some of the diverse data types that can be found in the ESS-DIVE repository. The 6 teams of community partners who developed the reporting formats included scientists and engineers from across the Department of Energy National Lab network. Additionally, during the development process, 247 individuals representing 128 institutions provided input on the formats. The primary files in this dataset are 10 data and metadata crosswalk for ESS-DIVE’s reporting formats (all files ending in _crosswalk.csv). The crosswalks compare elements used in each of the reporting formats to other related standards and data resources (e.g., repositories, datasets, data systems). This dataset also contains additional files recommended by ESS-DIVE’s file-level metadata reporting format. Each data file has an associated dictionary (files ending in _dd.csv) which provide a brief description of each standard or data resource consulted in the data reporting format development process. The flmd.csv file describes each file contained within the dataset.

54 ENVIRONMENTAL SCIENCES↗

Data from: "A guide to using GitHub for developing and versioning data standards and reporting formats"

These data are the results of a systematic review that investigated how data standards and reporting formats are documented on the version control platform GitHub. Our systematic review identified 32 data standards in earth science, environmental science, and ecology that use GitHub for version control of data standard documents. In our analysis, we characterized the documents and content within each of the 32 GitHub repositories to identify common practices for groups that version control their documents on GitHub.In this data package, there are 8 CSV files that contain data that we characterized from each repository, according to the location within the repository. For example, in 'readme_pages.csv' we characterize the content that appears across the 32 GitHub repositories included in our systematic review. Each of the 8 CSV files has an associated data dictionary file (names appended with '_dd.csv' and here we describe each content category within CSV files.There is one file-level metadata file (flmd.csv) that provides a description of each file within the data package.

54 ENVIRONMENTAL SCIENCES↗

Navigation and Meteorological Data from Multiple Sensors on Airborne Platform (NAVMET-AIR) Value-Added Product Report

The Navigation and Meteorological Data from Multiple Sensors on Airborne Platform (NAVMET-AIR) value-added product encompasses the aafnaviwg data set in the ARM Data Center (ADC), known as the IWG file, named for the Inter-Agency Working Group for Airborne Data and Telemetry Systems (IWGADTS). Its purpose is to produce a suite of tools to promote standardization of instrument interface, data format, and data processing. This data set’s contents are navigational and meteorological state variables at 1 Hz. It also contains higher-order data flags created by ARM Aerial Facility (AAF) scientists to aid analysis such as periods when the aircraft is flying level, operating in maneuvers, or flying through cloud. Due to the nature of research flights, the payload of the aircraft consists of many duplicate and overlapping instruments to ensure, in case of instrument failure, there is a backup to record the data. Measurements from multiple instruments are consolidated into a single file. Each variable of this data set is carefully chosen from the onboard instrumentation and quality checked by AAF scientists to create this wholistic and most accurate data set for airborne research. This document is intended to be a hub towards the individual “read me” files produced for each campaign. For reference about what instrument was used for calculations on specific days, the read me files are located in the ARM IOP archive at the addresses listed, or access the IOP (intensive operational period) database at https://www.archive.arm.gov/.

54 ENVIRONMENTAL SCIENCES↗

Combined Mesonet and Tracker

Title: Combined Mesonet and Trackers (UNL Mobile Mesonets) Authors University of Nebraska PI: Adam Houston, UNL Professor (ahouston2@unl.edu) Mailing Address: 126 Bessey Hall P.O. Box 880340 Lincoln, NE 68588-0340 CoMeT Overview The University of Nebraska-Lincoln operates three Combined Mesonet and Tracker (CoMeTs). CoMeTs are Ford Explorers (model years 2015, 2017, and 2019) with forward-mounted suites of meteorological sensors and dual moonroofs, combining the capability of a mobile mesonet to collect near-surface observations with the capability of an unmanned aircraft systems (UAS) tracker vehicle, which enables an observer in the second row of seats to see the aircraft and maintain compliance with Federal Aviation Administration policies on UAS operation. The CoMeTs collect observations of slow temperature and humidity at ~2 m above ground level (AGL) using a Vaisala HMP155A, fast temperature at ~2 m AGL using a Campbell Scientific 109SS-L thermistor, pressure at ~2.5 m AGL using a Vaisala PTB210, wind speed and direction at ~3.25 m AGL using an R.M. Young 05103 propeller anemometer, and vehicle heading using a KVH Industries C-100 fluxgate compass (Barbieri et al. 2019). The HMP155A and 109SS-L thermistor are shielded and aspirated within a U-tube (Waugh and Frederickson 2010; Houston et al. 2016). This list of sensors is also included in the CoMeT data file metadata. Manufacturer specifications for these instruments are given in Table 1 of Hanft and Houston (2018). The reported measured quantities are summarized below.CoMeT-3 was funded through an equipment allocation included in the NSF TORUS award (AGS-1824649). Instrument Description The specific sensors included on each CoMeT are summarized in the table at the end of this section. In general each CoMeT collects observations of slow temperature and humidity at ~2 m above ground level (AGL) using a Vaisala HMP155, fast temperature at ~2 m AGL using a Campbell Scientific 109SS-L thermistor, pressure at ~2.5 m AGL using a Vaisala PTB210 barometer with a Gill pressure port, wind speed and direction at ~3.25 m AGL using an R.M. Young 05103 propeller anemometer, position using a Garmin 19x HVS receiver, and vehicle heading using a KVH Industries C-100 fluxgate compass. The HMP155 and 109SS are shielded and aspirated within a U-tube (Waugh and Frederickson 2010; Houston et al. 2016). Fast temperature and corrected RH measurements (using sensors housed within the U-tube) have a time constant of 10-12 s based on data collected across a temperature and RH shock during the CLOUD-MAP 2017 calibration/validation tests on June 26, 2017. Vehicle speed was < 10 kts for this test. CoMeT-1 CoMeT-2 CoMeT-3 Slow Temperature Slow RH Vaisala HMP155A-L20-PT Part #: 22280-7 Vaisala HMP155E Part #: E1AA11A0B1A1A0A Vaisala HMP155E Part #: E1AA11A0B1A1A0A Fast temperature Campbell Scientific 109SS-L20-PT Part #: 21448-3 Campbell Scientific 109SS-L12-PW Part #: 21448-109 Campbell Scientific 109SS-L12-PW Part #: 21448-150 Pressure Vaisala PTB-210 Part #: A1A1B Gill Pressure Port Part #: 61002 Vaisala PTB-210 Part #: A1A1B Gill Pressure Port Part #: 61002 Vaisala PTB-210 Part #: A1A1B Gill Pressure Port Part #: 61002 Wind RM Young 05103-L20-PT Part #: 18435-310 RM Young 05103-L20-PW Part #: 18435-244 RM Young 05103-L20-PW Part #: 18435-244 GPS Garmin GPS 19x HVS (NMEA 0183) Part #: 010-01010-00 Garmin GPS 19x HVS (NMEA 0183) Part #: 010-01010-00 Garmin GPS 19x HVS (NMEA 0183) Part #: 010-01010-00 Compass KVH C-100 Part #: 01-0177-15 KVH C-100 Part #: 01-0177-15 KVH C-100 Part #: 01-0177-15 Logger Campbell Scientific CR6-NA-XT-SW Part #: 28385-9 Campbell Scientific CR6-WIFI-XT-SW Part #: 28385-6 Campbell Scientific CR6-WIFI-XT-SW Part #: 28385-6 Data Collection and Real-Time Processing The reported measured quantities are summarized in the table below. Quantity Units Source Epoch time Seconds GPS Latitude and longitude Degrees GPS Altitude m GPS Pressure hPa PTB210 Temperature (fast) deg C 109SS-L Temperature (slow) deg C HMP155 RH (slow) % HMP155 Vehicle speed m/s GPS Vehicle heading deg C-100 and GPS In addition to the measured variables, several derived variables are calculated. Corrected/fast relative humidity (%) Relative humidity is adjusted to the fast temperature following Richardson et al. (1998) and Houston et al. (2016). Water vapor mixing ratio (g/kg) Dew point temperature (&deg;C) Potential temperature (Kelvin) Virtual potential temperature (Kelvin) Equivalent potential temperature (Kelvin) Regular intercomparisons between all three CoMeTs were performed during TORUS 2019. Comparisons were also conducted between CoMeT-1 and CoMeT-2 during LAPSE-RATE (2018) on 14 July. In these intercomparisons, the vehicles were parked adjacent to each other aligned perpendicular to (and facing into) the wind. To minimize engine heating effects, intercomparisons were only conducted when the wind speed was >10 kts. Data Format Original data files for each deployment are saved as text files and then converted to NetCDF. NetCDF versions have units that are CF compliant and may not match the original units in the txt files. The naming convention for the NetCDF files is as follows: UNL.CoMeT3.{deployment date YYYYMMDD}.{start time of observation collection in UTC HHMM}.L2.{post-processing codes}.cdf example: UNL.CoMeT3.20190627.1931.L2.g1.f1.cdf Post-processing codes are included to track modifications to the raw data. These codes are closely connected to error flags associated with each record. Each letter corresponds to a particular instrument: g: GPS p: Barometer tf: Fast temperature ts: Slow temperature rh: Relative humidity f: Compass w: Wind monitor a: All instruments Each number corresponds to a particular post-processing action described more below. Measured and derived variables are included in the following table. Variable Heading Standard Name Units time Time seconds since 00:00:00, 01-01-1970 Alt Altitude meters lat Latitude degrees north lon Longitude degrees east fast_temp Air Temperature kelvin slow_temp Air Temperature kelvin pressure Air Pressure pascals logger_RH Relative Humidity percent calc_corr_RH Relative Humidity percent wind_speed Wind Speed meters per second wind_dir Wind From Direction degrees vehicle_dir Vehicle Direction degrees dewpoint Dew Point Temperature kelvin mixing_ratio Humidity Mixing Ratio g/g theta Air Potential Temperature kelvin theta_v Virtual Potential Temperature kelvin theta_e Equivalent Potential Temperature Kelvin error_flag The error_flag variable is a string that matches the post-processing codes listed above. All instruments will have an associated code, but will have a &ldquo;0&rdquo; if the datum is unchanged from the initial processed value. Error Codes The following table summarizes the error codes for data collected before 2020: Error Code Relevant CoMeT Description g1 1,2,3 Exact correction. GPS position and time reprocessed from raw data g2 1 As far as we can tell this is an exact correction to an error in the GPS time. During the correct time periods the time suddenly went backwards ~250s and stayed at this offset for 750s when it corrected itself. The offset was applied to the &ldquo;time warp&rdquo; period. p1 2 Approximate correction. Hole in the pressure tube connecting the pressure port to the barometer. Resulted in erroneously low air pressure measurements when the vehicle was in motion. Derived variables recalculated (dew point temperature [e depends on qv and p], water vapor mixing ratio, potential temperature, virtual potential temperature, equivalent potential temperature) a1 3 Exact correction. Missing data reprocessed from raw data a2 1 Bug fix to bias correction for ts1, ts2, and rh1: water vapor mixing ratio was off by a factor of 10 and virtual potential temperature was wrong because of this. f1 3 No correction, missing data. Fluxgate compass inoperable. Wind speed and direction calculated using GPS-derived vehicle heading instead. rh1 1 Approximate correction. Constant bias of +1.7% removed from relative humidity. Derived variables recalculated (corrected/fast relative humidity, dew point temperature, water vapor mixing ratio, virtual potential temperature, equivalent potential temperature) ts1 1 Approximate correction. Constant bias of +0.6 K removed from slow temperature. Derived variables recalculated (corrected/fast relative humidity, dew point temperature, water vapor mixing ratio, virtual potential temperature, equivalent potential temperature) ts2 1 Approximate correction. Constant bias of +1.0 K removed. Derived variables recalculated (corrected/fast relative humidity, dew point temperature, water vapor mixing ratio, virtual potential temperature, equivalent potential temperature) References Bolton, D., 1980: The Computation of Equivalent Potential Temperature. Mon. Wea. Rev., 108, 1046&ndash;1053, https://doi.org/10.1175/1520-0493(1980)108<1046:TCOEPT>2.0.CO;2. Hanft, W., and A. L. Houston, 2018: An Observational and Modeling Study of Mesoscale Air Masses with High Theta-E. Mon. Wea. Rev., 146, 2503&ndash;2524, https://doi.org/10.1175/MWR-D-17-0389.1.Wexler Houston, A. L., R. J. Laurence III, T. W. Nichols, S. Waugh, B. Argrow, and C. L. Ziegler, 2016: Intercomparison of unmanned aircraft-borne and mobile mesonet atmospheric sensors. Journal of Atmospheric and Oceanic Technology. 33, 1569-1582, doi: 10.1175/JTECH-D-15-0178.1. Lowe, P. R., 1977: An Approximating Polynomial for the Computation of Saturation Vapor Pressure. J. Applied Meteorology, 16, 100&ndash;103. Richardson, S. J., S. E. Frederickson, F. V. Brock, and J. A. Brotzge, 1998: Combination temperature and relative humidity probes: Avoiding large air temperature errors and associated relative humidity errors. Preprints, 10th Symp. On Meteorological Observations and Instrumentation, Phoenix, AZ, Amer. Meteor. Soc., 278&ndash;283. Waugh, S., and S. E. Frederickson, 2010: An improved aspirated temperature system for mobile meteorological observations, especially in severe weather. 25th Conf. on Severe Local Storms, Denver, CO, Amer. Meteor. Soc., P5.2. [Available online at https://ams.confex.com/ams/25SLS/techprogram/paper_176205.htm.]

54 ENVIRONMENTAL SCIENCES↗

LANL Nuclear Data Manager Format Specification v1.0

The LANL nuclear data manager tool is a Python utility that downloads nuclear data from the Nuclear Data Team’s website at https://nucleardata.lanl.gov, arranges it, and configures directory listings for nuclear codes such as the MCNP code to consume. In this document, the Version 1.0 API that this tool relies on will be discussed, which will show how an external provider of nuclear data could set up their website to provide a compatible implementation.

97 MATHEMATICS AND COMPUTING↗

A Guide to Using GitHub for Developing and Versioning Data Standards and Reporting Formats

Abstract Data standardization combined with descriptive metadata facilitate data reuse, which is the ultimate goal of the Findable, Accessible, Interoperable, and Reusable (FAIR) principles. Community data or metadata standards are increasingly created through an approach that emphasizes collaboration between various stakeholders. Such an approach requires platforms for collaboration on the development process that centers on sharing information and receiving feedback. Our objective in this study was to conduct a systematic review to identify data standards and reporting formats that use version control for developing data standards and to summarize common practices, particularly in earth and environmental sciences. Out of 108 data standards and reporting formats identified in our review, 32 used GitHub as the version control platform, and no other platforms were used. We found no universally accepted methodology for developing and publishing data standards. Many GitHub repositories did not use key features that could help developers to gather user feedback, or to create and revise standards that build on previous work. We provide guidance for community‐driven standard development and associated documentation on GitHub based on a systematic review of existing practices.

54 ENVIRONMENTAL SCIENCES↗