Search NASA⌕ Search

SEARCH · Search NASA

Results for “JSON”

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 19 records

A simple json format for storing and exchanging code calculation and experimental results

Calculation codes and code systems give their results in a plethora of different formats and/or files. For instance, MCNP gives a user the MCNP specific output file, the mctal file, the ptrac file, etc. while PARTISN has a PARTISN specific output file and a number of binary files with various kinds of information about the calculation. However, the results we are interested in are always the same. These can be single values such as the effective multiplication factor k eff or the effective delayed neutron fraction β eff . It can be histogram data (such as particle spectra, reaction rates, sensitivity profiles, etc.) or even pointwise data (for example the nuclide composition as a function of time, etc.). It is also worthwhile to note that this would also apply to experimental data that we may wish to compare with as well. Calculation and experimental results can basically be split into two components: attributes (or metadata) and the actual result itself. Attributes represent information about the result that are not necessarily required for its’ interpretation but that are still good to have. Often, these attributes are what we will want to filter results on. This means that these attributes are often the answer to specific questions we may have about the result. The following is a non exhaustive list of such basic questions: what type of result is it: e.g. the effective multiplication factor k eff , the effective delayed neutron fraction β eff , etc.; which case does it relate to: e.g. a specific ICSBEP case such as PU-MET-FAST-001-001; which code and version produced this result: e.g. MCNP 6.2, etc.; which nuclear data library was used to obtain the result: e.g. ENDF/B-VIII.0 or JEFF 3.3; which nuclide and reaction does it apply to (for reaction rates and sensitivity profiles); which volume in the geometry was it calculated in? The second component of the calculation or experimental result is the actual numerical data of the result. It is this data that we want to compare, exchange, plot, interpret, etc. It consists of values with optional uncertainties and units. It also includes the underlying structure (if any structure is required to interpret the result). Depending on the type of result, it may be a single value (e.g. the effective multiplication factor), an array of values (e.g. a reaction rate or particle spectrum) or even a multidimensional array. In order to exchange results between different organisations, for instance for benchmarking, people often resort to spreadsheets or custom text files that need to be filled out. While this approach works well if little information is to be exchanged, it can become cumbersome when dealing with large amounts of data (like for instance particle spectra for thousands of cases). In addition, such an approach does not always capture the metadata we may be interested in to allow for automated processing of these files. The purpose of this report is to propose a standardised json structure to store any type of result and present an associated python interface to interact with these results directly. For such a structure to be useful, it must fulfill a specific set of functional requirements that we try to meet with this proposal. The format must allow for the calculation result to stand by itself. This means that we should not have to look in multiple places to be able to understand it. For example, if the result relates to a particle spectrum, the group structure in which the result is given should be stored with it. The format should be code agnostic. This means that we do not need to know where it came from to understand it. The format should be result type agnostic. This means that the format must be generic enough so that we can even use it for results we have not thought of yet. The format should be relatively easy to interact with through different scripting or programming languages (i.e. the machine interface) while still providing a clean structure that can be used directly by any human.

97 MATHEMATICS AND COMPUTING↗

Common Electric Power Transmission System Model JSON Schema Specification

The Common Electric Power Transmission System Model (CTM) is an intuitive, extensible, language-agnostic, and error-resistant specification of electric power network components parameter names and units, and relation between components, intended for use by the research community developing new computational methods for power systems operations and simulation. Power system datasets following the CTM specification can be read as dictionaries and manipulated in that form in most programming languages (e.g., Python, Julia, C++). This standard data structure in CTM makes it easy to work in multiple power systems domains (e.g., economic operation, reliability assessment, electricity markets, stability assessment, etc.) without requiring conversions between use-case-specific file formats with information loss in the process. This repository specifies CTM as a JSON Schema, provides documentation, derivate (code-generated) implementations of CTM, and example data and usage of the schema for important use cases.

Aravena Solis, Ignacio↗

Modelica-json: Transforming energy models to digitize the control delivery process

Building simulation models are typically not used to generate the documentation required for bidding and project delivery of commercial building systems, or for their semantic modeling and commissioning. This paper presents a software tool that aids in digitizing the control delivery process, spanning simulation during design to implementation and formal verification during commissioning. The tool can generate from Modelica models digital documentation of control sequences. This digital documentation, along with other project drawings and specifications can be used for project bidding. It can also be used for implementation of control sequences through machineto-machine translation to commercial legacy control products, for which we are currently developing the proposed ASHRAE Standard 231P based on the presented work. Moreover, as-installed control sequences can be formally verified against the design specification, and a semantic model in Brick can be exported to aid in configuration of building analytics and fault detection. The paper presents what we believe is the first translation of a Modelica-implemented control sequence to a native implementation on a commercial control platform, using the webCTRL product line from Automated Logic. The paper also shows how a webCTRL implementation can be formally verified against its Modelica specification. These use cases have all been demonstrated with a prototype implementation that is now being further developed.

Wetter, Michael↗

Generating SBoMs Utilizing Structured Threat Information Expression JSON bundles

With cyber-attacks on the rise, information is one of the first lines of defense. Now more than ever, security experts and developers need efficient ways to know if their software may be outdated or vulnerable to emerging threats. By generating a Software Bill of Material based on STIX2/JSON bundles, security experts and developers can ensure that they know where to find what can go wrong with their systems before the hackers do. As part of the Infrastructure Expression project, Idaho National Laboratory (INL) is currently working on ways that can aid in the development of efficient SBOMs using Structured Threat Information Expression (STIX). Doing so can provide an efficient first line of defense for detection and monitoring that can be easily used by cyber personnel from beginners to highly skilled experts.

97 MATHEMATICS AND COMPUTING↗

A decay database of coincident γ–γ and γ–X -ray branching ratios for in-field spectroscopy applications

Current fieldable spectroscopy techniques often use single detector systems heavily impacted by interferences from intense background radiation fields. These effects result in low-confidence measurements that can lead to misinterpretation of the collected spectrum. To help improve interpretation of the fission products and short-lived radionuclides produced in a composite sample, a coincidence-database is being developed in support of a robust portable and X-ray coincidence detector system concurrently under development at the Pacific Northwest National Laboratory for in-field deployment. Hitherto, no database exists containing coincident γ–γ and γ–X-ray branching-ratio intensities on an absolute scale that will greatly enhance isotopic identification for in-field applications. As part of this project, software has been developed to parse all radioactive-decay data sets from the Evaluated Nuclear Structure Data File (ENSDF) archive to enable translation into a more useful JavaScript Object Notation (JSON) formats that more readily supports query-based data manipulation. The coincident database described in this work is the first of its kind and contains coincidence γ–γ and γ–X-ray intensities and their corresponding uncertainties, together with auxiliary metadata associated with each decay data set. The new JSON format provides a convenient and portable means of data storage that can be imported into analysis frameworks with relatively low overhead allowing for meaningful comparison with measured data.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

Middleware for a Heterogeneous CAV Fleet

This paper introduces CAN to ROS, a model-based code generation tool used in development, testing, and deployment of a heterogeneous fleet of vehicles with robotic sensing in ROS. Code generation supports two main features: (1) self-configuration for deployment in a heterogeneous vehicle fleet, and (2) quick iteration for testing and development of reading vehicle sensors and robotic control. This tool features the ability to detect the vehicle it is in and regenerate and rebuild itself at runtime to provide the proper two-way bridge between ROS and the sensed on-board vehicle sensor network. Code generation relies on a per-model defined JSON to map a CAN database (DBC) to the desired ROS topic names and message types. The live ROS publishing of CAN messages allows for instant feedback, and the code regeneration allows for adjustments in DBC or vehicle JSON to iteratively hone in on new vehicle signals. Generated ROS nodes are written in C++ for runtime use in lightweight embedded computers. This has been tested in vehicles from three different Original Equipment Manufacturers (OEMs), and can be extended to support a wide array of vehicles. By using a unifying ROS specification, a heterogeneous set of vehicles can be unified into a fleet with abstracted model-specific details; this opens the door for developing cross-model software applications for vehicle control, connected vehicle applications, or fleet monitoring systems.

42 ENGINEERING↗

pyEGAF: Modernization of the EGAF database

One of the most comprehensive resources for thermal neutron-capture data is the Evaluated Gamma-ray Activation File (EGAF), containing data from prompt gamma activation analysis measurements carried out at the Budapest Research Reactor for 245 isotopes. Although these valuable datasets have been freely available for many years, the outdated and cryptic adopted format makes it difficult to utilize the data and it is not generally suitable for modern computational technologies. Furthermore, to help overcome these challenges, we have converted the datasets into an open standard JSON format. Additionally, we have developed a Python implementation of an open-source software package, pyEGAF, designed to interact with the JSON data structures for general purpose access, manipulation, and rapid assessment of the capture-gamma data in EGAF.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

pyEGAF: An open-source Python library for the Evaluated Gamma-ray Activation File

The Evaluated Gamma-ray Activation File (EGAF) is one of the most comprehensive resources for thermal neutron-capture data. This database contains data from prompt gamma activation analysis measurements carried out in a consistent manner using the same experimental configuration at the Budapest Research Reactor for 245 isotopes. Although these valuable datasets have been freely available for many years, one of the drawbacks is the outdated and cryptic Evaluated Nuclear Structure Data File (ENSDF) format that is currently adopted for dissemination, making it difficult for users unfamiliar with the format to access and utilize the data contained therein. Furthermore, the ENSDF format does not readily lend itself to modern computational technologies and a parser is required to interpret the complicated mixed-record format. To help overcome these challenges, we have developed a translator to convert the ENSDF-formatted datasets into an open standard JavaScript Object Notation (JSON) format enabling accessibility to applications using different programming languages running in different environments. To compliment this effort, we have also developed an open-source software package implemented in Python, pyEGAF, that is designed to interact with the JSON data structures for general purpose access, manipulation, and analysis of the neutron-capture $\gamma$-ray data in EGAF. The new format, together with the pyEGAF library, greatly enhances access to the wider applications community where EGAF data may be useful or is required.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

App2Net: Moving App Functions to Network & a Case Study on Low-latency Feedback

Recent advances in programmable networks enable custom processing of data at hundreds of gigabits per second. These advances can boost the performance of many distributed applications. Yet the high-level languages used by application developers are different from the data plane programming languages (such as P4 and NPL) used by network equipment. This language barrier slows innovation. Our hourglass-shaped architectural solution aims to lower this language barrier. This enables the application developer community to leverage programmable networks for achieving better performance. In this paper we propose a JSON-based intermediate representation to bridge the gap between applications and in-network computing. We demonstrate an instance of the solution in the context of a low-latency feedback application that enables SQL-based data filtering in a P4-based programmable environment. We also present a prototype compiler to convert an intermediate representation in JSON to P4 source.

Sankaran, Ganesh↗

Building Efficiency Targeting Tool for Energy Retrofits (BETTER) Application Programing Interface (API) (BETTER API) v1.0

The BETTER API allows advanced users and developers to access BETTER's analytical functionalities via HTTP requests from their own software platform without using the BETTER web-interface. API users prepare the input data and analysis configurations in a JSON format and send it to the web application via an HTTP request. The web application runs the analytical workflow on the back end and returns an HTTP response in JSON format. The user can then decide to render the results or further process it.

Szum, Carolyn↗

Generic Data Display (GD2)

SAND2023-11967O Generic Data Display (GD2) is a real-time data visualization application that can display user-defined input data. The open-source software is comprised of a back end system written in Python, and a front end user interface written in JavaScript. The back end system collects data from a variety of input sources, such as message queue, HTTP, XML, JSON, and others. The front end displays data in an Open MCT web interface, and users can configure the system by providing JSON formatted configuration files. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

Figueroa, Benjamin↗

Sandia Image Labeling Tool (SILT)

SAND2025-01840O Sandia Image Labeling Tool (SILT) is a Python tool that labels images for machine learning and other applications. SILT uploads JSON files to create a template for labeling an image. SILT can then upload images, including images that are tens of GB large and dynamically loads them in a manner that a user, with a very modest spec laptop, can handle. It then saves the label as a JSON using the template. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

Pitts, Todd↗

Classification of River Catchments in the Contiguous United States: Code, Dataset, Similarity Patterns, and Resulting Classes

This dataset serves as supplementary information for the paper by Ciulla F. and Varadharajan C. A Network Approach for Multiscale Catchment Classification using Traits (see reference 1). It contains environmental and physical catchment traits, such as temperatures, precipitation, land use and human interference, from 9067 sites across the contiguous United States (CONUS). The purpose of this dataset is to provide information for a better trait-based categorization of river catchments in the CONUS using networks as an analytical tool. The traits variables match the ones present in the GAGES-II dataset and the preprocessing steps are described in the Methods section (processed_dataset.csv). Additionally we include the topologies (nodes, edges and clusters, also referred as classes) of the catchment network and traits network generated by said dataset (csv and json files). A series of tables support the information carried by the network providing more detailed descriptions of cluster components (SI1.pdf). A summary of all the plots of clusters of catchments with at least 50 nodes is provided (SI2.pdf). The characteristic traits for each cluster of catchments is presented as z-score (traits_categories_zscores_per_catchment_class.csv). The link to the hydrological behavior of clusters of catchments is displayed by boxplots, each describing a particular river discharge index (SI3.pdf). Both csv and json files can be read by common text editors but the data contained into them can be better handled using programming languages like python and database oriented libraries like pandas. Pdf files can be read by any pdf reader software.[02-23-2024] Update: The code and datasets necessary to reproduce the results of the study are available as a zipped repository (code_datasets_catchments_similarity.zip).

54 ENVIRONMENTAL SCIENCES↗

CHESS 2025: Leaf Area Index (LAI) for meadow, shrub, tree, and understory vegetation

This dataset contains Leaf Area Index (LAI) measurements made as part of the Colorado Headwaters Ecological Spectroscopy Study (CHESS) during June and July of 2025. Data were collected in the Upper Gunnison Basin, Colorado, across three study domains: the Upper East River (CRBU), Almont Triangle (ALMO), and the Upper Taylor Basin (UPTA). Field observations of LAI were collected within 72 hours of airborne data collection by the National Ecological Observatory Network’s Aerial Observation Platform (NEON AOP). The NEON AOP collected waveform LiDAR (Light Detection and Ranging) and imaging spectrometer data in 426 spectral bands from the visible to shortwave infrared. LAI measurements were collected using the LICOR LAI-2200C Plant Canopy Analyzer following protocols outlined in the instrument manual (LI-COR 2019). Sampling targeted four distinct vegetation types: meadows, shrubs, trees, and aspen forest understory. We have archived data separately by site type because different field methods were used for each. At meadow sites, measurements were made at the four corners of 1m x 1m plots, with the instrument moving inward toward the center of the plot. At shrub sites, we measured the canopies of individual shrubs. At tree sites, we made measurements within a 10m x 10m subplot centered around a focal tree, with 30 observations taken on a regular grid. At aspen understory sites, we measured overstory trees following the tree protocol and understory herbaceous vegetation following the meadow protocol. All measurements included above-canopy (A) and below-canopy (B) readings, with specific protocols for scattering correction measurements in direct-sun conditions. Data were processed using the R package `rlai` (Worsham 2025). This package includes functions to calculate LAI, gap fraction, apparent clumping factor (Ω), scattering correction, and other canopy metrics. Package contents: Full file descriptions appear in ‘flmd.csv’. Files named according to the convention ‘lai_*_summary_data_cleaned.csv’ contain summary values of LAI, apparent clumping factor (Ωapp), and scattering correction factors for each site. These are the analysis-ready products that most data users will work with. Files named ‘lai_*_metadata_cleaned.csv’ contain additional site-level observations made during field collection. We have also archived intermediate and supplementary data for users who wish to check our processing approach or apply alternative methods. ‘raw_lai_2200C.zip’ contains the raw files as read from the LI-COR instrument, with no processing applied, in TXT format. The zip archive contains subdirectories by site type, which are further subdivided by sampling area. Filenames correspond to the sampling site number. ‘intermediate_results.zip’ contains detailed output from the processing routines, in JSON format. The zip archive contains subdirectories by site type; filenames correspond to the sampling site number. ‘scattering_correction_logs.zip’ contains logfiles from the implementation of Kobayashi et al.'s (2013) scattering correction algorithm. The logfiles report values of several parameters at each iteration of the algorithm, as the model converges toward a stable solution. They are intended for users who want to verify scattering correction performance. The zip archive contains subdirectories by site type; filenames correspond to the sampling site number. ‘spot_checks.csv’ reports LAI and other values for a small number of files processed with LI-COR FV2200 software (LI-COR 2013) using the same control parameters as in our R-based approach. Additional metadata are provided in a data dictionary describing column names and definitions (dd.csv), and in a file-level metadata file (flmd.csv). All zip files can be expanded with common archive utilities. TXT, CSV, and JSON files can be ingested into R or Python computing environments or read in common text editor utilities. Geospatial information: Geospatial data for mapping measurement site locations are in the files CHESS_polygons_lai_UTM.geojson, CHESS_polygons_shrub_UTM.geojson, and CHESS_polygons_meadow_UTM.geojson in the companion geospatial package for the 2025 CHESS campaign, ‘CHESS 2025: Location data for field observations and sampling’ (Henderson et al., 2026). CHESS Project Description: The Colorado Headwaters Ecological Spectroscopy Study (CHESS) comprised a multi-week airborne remote sensing and field observation campaign in the Upper Gunnison Basin, Colorado, conducted in June and July of 2025. Airborne remote sensing was conducted by the National Ecological Observatory Network Airborne Observation Platform (NEON AOP), concurrent with a field campaign run by the Rocky Mountain Biological Laboratory (RMBL), the Lawrence Berkeley National Laboratory (LBNL) and SLAC National Accelerator Laboratory Watershed Function Science Focus Area (SFA), and NASA-JPL (Jet Propulsion Laboratory) Earth Surface Mineral Dust Source Investigation (EMIT) program. Between June 10 and July 18, 2025, the NEON AOP flight team collected high-resolution aerial imaging spectroscopy and Light Detection and Ranging (LiDAR) data over three domains: the Upper East River (CRBU), Almont Triangle (ALMO), and the Upper Taylor Basin (UPTA). In coordination with the flights, a field campaign acquired ground-truth observations, including observations of vegetation composition, foliar traits, forest demography, and subsurface properties in 18 core sampling areas within the domains. Additional surface water observations were taken at over 380 point locations. All CHESS campaign datasets can be found within the CHESS ESS-DIVE data portal: https://data.ess-dive.lbl.gov/portals/chess. Funding Acknowledgement: Field and remote-sensing data acquisition was performed under a grant from the National Aeronautics and Space Administration (80NSSC24K1005). This work was also supported by the Watershed Function Science Focus Area at Lawrence Berkeley National Laboratory funded by the US Department of Energy, Office of Science, Biological and Environmental Research under Contract No. DE-AC02-05CH11231. * Todorov and Worsham are co–first authors.

2018 NEON and 2025 CHESS Campaigns↗

MontePy: a Python library for reading, editing, and writing MCNP input files.

The Monte Carlo N-Particle (MCNP) radiation transport code is a highly capable and accurate code with a long legacy. MCNP uses the Monte Carlo simulation process to simulate the path of particles (e.g., neutrons, photons, charged particles, etc.), and their interaction with materials. It is widely used in nuclear engineering, high-energy physics, and other fields. Its origins in the mid-twentieth century predate many modern software conventions. MCNP users provide an input file to MCNP, which it then uses to create an internal representation of the simulation problem. These input files originally had to be stored as punchcard decks, and the user manual still uses the terminology of cards and decks, despite moving beyond punchcards. MCNP predates nearly all modern human readable markup or data serialization languages, such as the extensible Markup Language (XML), the Standard Generalized Markup Language (SGML), YAML (YAML Ain’t Markup Language), and Javascript Object Notation (JSON). Due to this, MCNP uses an entirely custom defined syntax language for its input, making off-the-shelf libraries for XML, YAML, and JSON impossible to use for scripting various operations on MCNP input files (Kulesza et al., 2022).

97 - MATHEMATICS AND COMPUTING↗

Developing a Prototype Methodology to Rank CO2-EOR Wells and Assess Their Reuse Potential for Geologic Carbon Storage

This paper presents a prototype methodology to assess the possible transition of Class II carbon dioxide-enhanced oil recovery (CO2-EOR) wells to Class VI wells. The focus is on wellbore construction materials—casing, cement, tubing, and the packer—and includes comprehensive workflows to evaluate these materials, with primary emphasis on compliance with Environmental Protection Agency (EPA) Class VI well construction and conversion guidelines. These workflows systematically assess material properties and performance criteria to ensure regulatory compliance and optimize long-term wellbore integrity and functionality. Utilizing Python scripts and JavaScript Object Notation (JSON) representations, the study automates checks on digitized Texas Railroad Commission (TRRC) data to rank wells based on workflow criteria. By emphasizing critical factors such as casing integrity, cementing techniques, tubing compatibility, and packer selection, the methodology helps well owners and operators prioritize wells for potential reuse as CO2 injection wells. Given limitations in digitized data, manual user verification is required in some sections. Future improvements include integrating non-digitized data through web scraping and machine learning techniques. This research serves as a practical guide for stakeholders, supporting environmental compliance and sustainable well operations.

geologic carbon sequestration↗

Implementation of a Web Interface to Display Real-Time Statistics of a Dilution Refrigerator

The purpose of the project is to communicate with a Bluefors control unit and extract data. The Bluefors control unit is a piece of experimental equipment that measures various different data points in a dilution refrigerator and stores them. The goal was to access the control unit using the websockets library in Python. After accessing the control unit, the goal was to export the data to a web page in HTML/CSS. The tools that were used changed throughout the project. Python was used to communicate with the Bluefors unit via JSON requests and JSON objects, then the Python hosted its own websocket server to act as a proxy server to allow for the web page to access the data. This was done to bypass SSL verification. Then, the web page, which was created using JavaScript, React, Next.js, and NodeJS, accesses the proxy server to import the data from the dilution refrigerator and display the values in real time on the page.

Rasheed, Hammad↗