Engineering Papers⌕ Search

SEARCH · Engineering Papers

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 109 records · Page 6

Electricity Baseline 2020 Background Data and Log File

The ElectricityLCI v2 Python package (https://github.com/USEPA/ElectricityLCI/tree/v2.0) was used to generate the 2020 electricity baseline: a regionalized life cycle inventory model of U.S. electricity generation, consumption, and distribution using standardized facility and generation data. ElectricityLCI implements a local data store for downloading and accessing public data on an individual's computer. The data store follows the folder definition provided by USEPA's esupy Python package (https://github.com/USEPA/esupy), which utilizes the appdirs Python dependency (https://pypi.org/project/appdirs/). An overview of the ElectricityLCI data stores may be found on the README (https://github.com/USEPA/ElectricityLCI/blob/v2.0/README.md#data-store). This submission includes the background data used to generate the 2020 electricity baseline inventory. Each zip archive stores the source files as found in their data stores. Sub-folders in each of the data stores are archived separately. For example, stewi.zip contains the JSON files, while stewi.facility.zip is the 'facility' sub-folder of stewi data store that stores the parquet files. To reproduce the data store, extract each zip file and drag-and-drop sub-folders in to their appropriate root folders to recreate the data stores, then copy the root folders to your data store folder (as returned by running the following on the command line: python -c "import appdirs; print(appdirs.user_data_dir())"). The main five data stores include: 'electricitylci', 'facilitymatcher', 'fedelemflowlist', 'stewi', and 'stewicombo'. The log file generated by the 2020 model run is also included, which contains the statements at the DEBUG level and above.

Electricity; LCA; LCI; Life Cycle; data inventory↗

Electricity Baseline 2020

The Electricity Baseline (2020) is a regionalized life cycle inventory model of U.S. electricity generation, consumption, and distribution using standardized facility and generation data and was created using the ElectricityLCI v2 Python package (https://github.com/USEPA/ElectricityLCI/tree/v2.0). The Python package used the "ELCI_2020" model configuration to set the facility and generation data sources and years that were used to create this life cycle inventory, which were taken from publicly accessible datasets and automatically curated into a local data store. An archive of the data stores used in this model is available online: https://doi.org/10.18141/2569605. This model is presented in GreenDelta's openLCA schema v2 JSON-LD format (https://greendelta.github.io/olca-schema/).

Electricity; LCA; LCI; data inventory↗

Genesis Data Card Schema, Template and Supporting Tools

Genesis Data Cards provide a standardized template and schema for documenting scientific datasets in support of discovery, access, interoperability, reusability, governed use, and AI usability. This release of the Genesis Data Card repository includes a versioned Markdown template, a LinkML schema with generated Pydantic and JSON artifacts, schema documentation, and example completed data cards. Validation tooling is provided to ensure that completed data cards conform to the schema prior to submission. Accompanying documentation for the structured metadata is provided as a Field Reference Guide. The schema and accompanying template provided in this repository address the call for actionable context that enables humans and AI systems to find, access, interpret, cite, and reuse data, and, when appropriate, integrate it into AI and machine learning workflows. The data card is intended to serve as a common metadata artifact intended to support standardized, cross-program dataset documentation across Department of Energy (DOE)-aligned efforts, including but not limited to Genesis Mission-related implementations, the Office of Science, National Nuclear Security Administration (NNSA), and Advanced Simulation and Computing (ASC) data governance and stewardship initiatives.

data card↗

Deployment of ADTimePix3 areaDetector Driver at Neutron and X-ray User Facilities

TimePix3 is a 65k hybrid pixel readout chip with simultaneous Time-of-Arrival (ToA) and Time-over-Threshold (ToT) recording in each pixel*. The chip operates without a trigger signal with a sparse readout where only pixels containing events are read out. The flexible architecture allows 40 MHits/s/cm² readout throughput, using simultaneous readout and acquisition by sharing readout logic with transport logic of superpixel matrix formed using 2x4 structure. The chip ToA records 1.5625 ns time resolution. The X-ray and charged particle events are counted directly. However, indirect neutron counts use 6Li fission in a scintillator matrix, such as ZnS(Ag). The fission space-charge region is limited to 5-9 um. A photon from scintillator material excites a photocathode electron, which is further multiplied in dual-stack MCP. The neutron count event is a cluster of electron events at the chip. We report on the EPICS areaDetector** ADTimePix3 driver that controls Serval*** using json commands. The driver directs data to storage and to a real-time processing pipeline and configures the chip. The time-stamped data are stored in raw .tpx3 file format and passed through a socket where the clustering software identifies individual neutron events. The conventional 2D images are available as images for each exposure frame, and a preview is useful for sample alignment. The areaDetector driver allows integration of time-enhanced capabilities of this detector into SNS beamlines controls and unprecedented time resolution.

Gofron, Kaz↗

Preliminary API design to access SG-50 database [Slides]

This presentation details the design and use of a rudimentary example API. The example API reads JSON; eventually it needs to operate with the database. It demonstrates ease in applying powerful, publicly available tools.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

Universal Utility Data Exchange (UUDEX): Information Exchange Models for Solar DER (Rev. 1)

This report describes how the Universal Utility Data Exchange (UUDEX) can encapsulate and exchange information about distributed energy resources (DER) within UUDEX-formatted JSON documents. It proposes to use the existing extensible markup language (XML) information exchange format described in IEEE Std 2030.5, IEEE Standard for Smart Energy Profile Application Protocol but not other information exchange provisions of IEEE 2030.5, rather, relying on equivalent mechanisms in UUDEX. This will allow adoption of the UUDEX exchanges with minimal changes to the structure of the information exchanged and will not require a modification to the UUDEX documentation if IEEE 2030.5 makes changes to the information models.

14 SOLAR ENERGY↗

Universal Utility Data Exchange (UUDEX): Information Exchange Models for Solar DER

This report describes how the Universal Utility Data Exchange (UUDEX) can encapsulate and exchange information about distributed energy resources (DER) within UUDEX-formatted JSON documents. It proposes to use the existing extensible markup language (XML) information exchange format described in IEEE Std 2030.5, IEEE Standard for Smart Energy Profile Application Protocol but not other information exchange provisions of IEEE 2030.5, rather, relying on equivalent mechanisms in UUDEX. This will allow adoption of the UUDEX exchanges with minimal changes to the structure of the information exchanged and will not require a modification to the UUDEX documentation if IEEE 2030.5 makes changes to the information models.

42 ENGINEERING↗

U.S. Average Corn Ethanol Production Baseline for 45Q Life Cycle Analysis Version 1.0 (2018-2022)

U.S. Average Benchmark life cycle inventory documentation for ethanol production for calendar years 2018 - 2022. The documentation includes a technical report describing data sources and statistical methods used and an Excel file showing calculations. The calculations performed are used in the 45Q benchmark json-ld dataset, compatible with the NETL CO2U LCA Guidance Toolkit. Summary impact results will be included in the NETL CO2U LCA Documentation Spreadsheet within the Toolkit. To access the model referenced in the report, please visit https://www.netl.doe.gov/energy-analysis/details?id=55ab21f1-9238-4b63-9a7a-ae1a4cfa7b05.

09 BIOMASS FUELS↗

U.S. Average Market Carbon Dioxide Production Baseline Documentation For 45Q Life Cycle Analysis: Version 1.0 (2018-2022)

U.S. Average Benchmark life cycle inventory documentation for market carbon dioxide production for calendar years 2018 - 2022. The documentation includes a technical report describing data sources and statistical methods used and an Excel file showing calculations. The calculations performed are used in the 45Q benchmark json-ld dataset, compatible with the NETL CO2U LCA Guidance Toolkit. Summary impact results will be included in the NETL CO2U LCA Documentation Spreadsheet within the Toolkit. To access the model referenced in the report, please visit https://www.netl.doe.gov/energy-analysis/details?id=21915ba8-d2cf-43ea-b9b2-1d76363a46a7

29 ENERGY PLANNING, POLICY, AND ECONOMY↗

U.S. Average Nitrogen Fertilizer Production Baseline Documentation For 45Q Life Cycle Analysis: Version 1.0 (2018-2022)

U.S. Average Benchmark life cycle inventory documentation for nitrogenous fertilizer production for calendar years 2018 - 2022. The documentation includes a technical report describing data sources and statistical methods used and an Excel file showing calculations. The calculations performed are used in the 45Q benchmark json-ld dataset, compatible with the NETL CO2U LCA Guidance Toolkit. Summary impact results will be included in the NETL CO2U LCA Documentation Spreadsheet within the Toolkit. https://www.netl.doe.gov/energy-analysis/details?id=7c0db05a-231e-40a5-b5fd-112a7c001834

09 BIOMASS FUELS↗

AI in Science Communication

Generative AI has brought innovations across multiple fields, offering great tools for enhanced communication and efficiency. This project focused on developing a custom AI chatbot using OpenAI's Chat GPT (GPT-4o) to support the Fermilab communications team. An analysis identified Chat GPT as the optimal choice, leading to the adoption of its team version and the implementation of a real-time JSON schema for website scanning. Four distinct personas were created to tailor responses to specific audiences, and Fermilab's published content was uploaded to ensure tone consistency. The training involved iterative prompt trials, resulting in a responsive and effective communication assistant. Initial evaluations indicate that the custom GPT shows promise.

Valle, Diego↗

Improving Self-Driving Labs: Quantifying System-Level Experiment Repeatability and Broadening Instrument-Level Compatibility

Modular Autonomous Research System (MARS) is a self-driving laboratory (SDL) which performs wet-lab science with peptide-lanthanide combinations in an automated and, ultimately, an autonomous manner to aid in soil analysis for domestic lithium mining. Autonomous experimentation involves automated experimentation, experiment planning, and active learning. MARS consists of a 6-axis robotic arm (UR5e) on a linear rail, pipette robots (Opentrons 2), and microplate readers. These components transport, operate on, and collect data with chemical solutions in standard labware. For effective autonomy, MARS must perform system-level labware operations repeatably, plan experiments autonomously, and be portable between research-domains. Repeatability is evaluated by labware placement precision, such that future operations can properly locate labware, as well as the elapsed time, so that low variance mean estimates of experiment duration can inform high-level researcher decision making. Autonomous experiment planning is the next step to decouple experimentation from human management; however, there is a conflict between the ideal system-level experiment goals and the constraints imposed by instruments’ limitations. Sub-domain portability is a long-term goal to extend MARS’ research beyond the chemistry of peptide-lanthanide binding to other sub-domains without having to invest significant overhead to system retrofitting. To address these goals, we manually trained the robotic arm labware placement and modelled statistical failurerate and uncertainty Additionally, we benchmarked the duration and variance of each experiment sub-operation as a heuristic for research decision making. Next, we use a parameterized geometric program (PGP) approach to design experiments that optimize system-level objectives and satisfy instrument-level constraints. Lastly, we proposed a Python framework to maximize MARS’ extensibility to other scientific sub-domains through a JSON-based experiment specification.

36 MATERIALS SCIENCE↗

Fermilab s Transition to Token Authentication

Fermilab is the first High Energy Physics institution to transition from X.509 user certificates to authentication tokens in production systems. All of the experiments that Fermilab hosts are now using JSON Web Token (JWT) access tokens in their grid jobs. Many software components have been either updated or created for this transition, and most of the software is available to others as open source. The tokens are defined using the WLCG Common JWT Profile. Token attributes for all the tokens are stored in the Fermilab FERRY system which generates the configuration for the CILogon token issuer. High security-value refresh tokens are stored in Hashicorp Vault configured by htvault-config, and JWT access tokens are requested by the htgettoken client through its integration with HTCondor. The Fermilab job submission system jobsub was redesigned to be a lightweight wrapper around HTCondor. For automated job submissions a managed tokens service was created to reduce duplication of effort and knowledge of how to securely keep tokens active. The existing Fermilab file transfer tool ifdh was updated to work seamlessly with tokens, as well as the Fermilab POMS (Production Operations Management System) which is used to manage automatic job submission and the RCDS (Rapid Code Distribution System) which is used to distribute analysis code via the CernVM FileSystem. The dCache storage system was reconfigured to accept tokens for authentication in place of X.509 proxy certificates. As some services and sites have not yet implemented token support, proxy certificates are still sent with jobs for backwards compatibility but some experiments are beginning to transition to stop using them. There have been some glitches and learning curve issues but in general the system has been performing well and is being improved as operational problems are addressed.

Dykstra, David↗

A Managed Tokens Service for Securely Keeping and Distributing Grid Tokens

Fermilab is transitioning authentication and authorization for grid operations to using bearer tokens based on the WLCG Common JWT (JSON Web Token) Profile. One of the functionalities that Fermilab experimenters rely on is the ability to automate batch job submission, which in turn depends on the ability to securely refresh and distribute the necessary credentials to experiment job submit points. Thus, with the transition to using tokens for grid operations, we needed to create a service that would obtain, refresh, and distribute tokens for experimenters’ use. This service would avoid the need for experimenters to be experts in obtaining their own tokens and would better protect the most sensitive long-lived credentials. Further, the service needed to be widely scalable, as we are currently keeping credentials active for approximately 15 experiments, each with 1-3 different credentials, and distributing those credentials to 2-20 submit points per experiment, with those numbers steadily increasing. To address these issues, we created and deployed a Managed Tokens service. The service is written in Go, taking advantage of that language’s native concurrency primitives to easily be able to scale operations as we onboard experiments. The service uses as its first credentials a set of kerberos keytabs, stored on the same secure machine that the Managed Tokens service runs on. These kerberos credentials allow the service to use htgettoken via condor_vault_storer to store vault tokens in the HTCondor credential managers (credds) that run on the batch system scheduler machines (HTCondor schedds); as well as downloading a local, shorter-lived copy of the vault token. The kerberos credentials are then also used to distribute copies of the locally-stored vault tokens to experiment submit points. When experimenters schedule jobs to be submitted, these distributed vault tokens are used to access a Hashicorp Vault instance (run separately from the Managed Tokens service), and previously-stored refresh tokens there are used to obtain the bearer token that is submitted with the job. We will discuss here the design of the Managed Tokens service, including elaborating on certain choices we made with regards to concurrent operations, configuration, monitoring, and deployment.

Bhat, Shreyas↗

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

This study presents a prototype methodology for evaluating the reuse potential of Class II CO₂-enhanced oil recovery (CO₂-EOR) wells as Class VI wells for geologic carbon sequestration. The approach focuses on assessing wellbore construction materials—casing, cement, tubing, and packers—based on U.S. Environmental Protection Agency (EPA) Class VI well conversion guidelines. Utilizing Python scripts and JSON representations, the methodology automates checks on digitized Texas Railroad Commission (TRRC) data to rank wells based on regulatory and integrity criteria. Key factors include casing integrity, cementing techniques, tubing compatibility, and packer selection. Due to limitations in digitized data, manual verification is required for certain sections. Future enhancements include incorporating non-digitized data via web scraping and machine learning. This research provides a practical framework for well owners and regulators, supporting informed decision-making for sustainable CO₂ storage.

carbon sequestration↗

Compilation of Experimental Yield Data for Spontaneous Fission of 252 Cf

We present a comprehensive compilation and curation of experimental fission yield (FY) data for the spontaneous fission of 252 Cf, extracted from the EXFOR database. The compilation follows a structured methodology developed for prior compilations of neutron-induced fission yields, and incorporates both independent (IFY) and cumulative (CFY) yields. A total of 62 datasets were reviewed, with entries spanning from 1955 to 2021. A significant portion of the literature reports pre-neutron emission yields, which were excluded from the present compilation due to limitations in format compatibility. Each accepted dataset was processed into a standardized JSON format, including metadata, uncertainties, and bibliographic references. Where available, decay radiation information was used to update the FY data using the latest ENSDF evaluations; 237 data points were corrected accordingly. These corrections are fully traceable and preserve original values. The result is a curated dataset suitable for use in nuclear data evaluations. This work is part of an ongoing effort to modernize the handling of FY data and provide evaluators with high-quality, machine-readable experimental inputs

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

Benchmark Tracking System for Performance Monitoring

Benchmarking is essential for high-performance software development, particularly for monitoring performance across code iterations. This project focused on enhancing the benchmarking process for Lamellar, an asynchronous runtime for High-Performance Computing (HPC) systems developed at Pacific Northwest National Laboratory. Prior to this work, benchmark results were difficult to track and compare across code versions, presenting significant challenges in identifying performance regressions and long-term trends. The primary objective was to establish a systematic, reproducible approach for measuring performance and detecting regressions following code commits. Our methodology involved three key components: standardizing benchmark outputs, implementing data versioning, and developing analysis tools. We standardized the benchmark output format to JSON Line records containing specific fields (execution time, hardware specifications, and environmental variables). To address data management challenges, we evaluated several options and eventually chose a git repository dedicated to benchmark data. We developed a suite of Python tools that processed benchmark results, enriched them with metadata, and facilitated search in the repository. The resulting system enables more efficient filtering and comparison of performance metrics across commit histories, hardware configurations, and benchmark variants through a unified query interface. Our implementation reduces computational overhead by first checking for existing results through configuration matching before initiating new benchmark runs, thereby conserving resources. The system has been validated by Lamellar developers. It organizes results by benchmark type and build configurations for efficient retrieval. Future developments include a planned Large Language Model interface for predicting benchmark performance, incorporating the criterion package for statistical analysis, which will enable automated detection of statistically significant performance changes, and integration with continuous integration pipelines. Despite these enhancements being reserved for future work, this project has successfully provided the Lamellar development team with a framework for maintaining consistent performance standards and identifying optimization opportunities across workloads and hardware environments.

97 MATHEMATICS AND COMPUTING↗

An Overview of the Molten Salt Thermal Properties Database–Thermophysical, Version 4.0 (MSTDB-TP V.4.0)

A central repository of thermophysical and thermochemical properties of molten salt compositions of relevance to molten salt reactors (MSRs) is vital in supporting the broad community of MSR developers, who are at various stages of developing and deploying their reactor designs. In general, these MSR designs differ significantly from developer to developer (e.g., with respect to the hardness of the neutron spectra, level of fissile loading, target multicomponent temperatures and power levels, and moderating capabilities). Therefore, the fuel and coolant salts being considered vary greatly: they may be chlorides or fluorides, they utilize different actinides at different ratios, and the cations in the melt are selected based on perceived advantages and disadvantages. Considering the general need for thermal properties, and the vastness of the array of potential candidate salt mixtures, the Molten Salt Thermal Properties Database (MSTDB) was initiated in 2018 with the goal of providing thermophysical and thermochemical characterization of key molten salt compounds and mixtures across their temperature and compositional domains. The MSTDB is thus divided into the thermophysical arm (MSTDB-TP) and the thermochemical arm (MSTDB-TC). The MSTDB is an effort funded by the Department of Energy, Office of Nuclear Energy (DOE-NE) Nuclear Energy Advanced Modeling and Simulation (NEAMS) program, and the MSR Campaign. This report provides an overview of the MSTDB-TP v4.0 in terms of the data contained within, the state of the tools used to access the data, the availability of predictive models that leverage the raw data in the database, the preliminary status of developmental efforts that are currently underway, and an account of future goals for MSTDB-TP. The primary goal for the update from MSTDB-TP v.3.1 to v4.0 was the incorporation of surface tension data into the database; this property is important for thermal hydraulics modeling and species transport in other tools that have been developed under the NEAMS program. A breakdown of the surface tension data that have been added into MSTDB-TP v4.0 is provided herein, and the manner in which the quality of the data has been assessed is also documented. For MSTDB-TP v4.0, newly published thermophysical property data—primarily from collaborative experimental efforts under the MSR Campaign—have been incorporated into the database, and the resulting expansion is documented here. Because of the size to which MSTDB-TP has grown, the raw data format has now been recast into JavaScript Object Notation (JSON) format for easier connection with the MSTDB-TP application programming interface (API). Saline; the pre-existing comma-separated value (CSV) format has been deprecated but is still maintained, accessible, and up to date. As a final effort in packaging the MSTDB-TP v4.0 update, the graphical user interface (GUI) for MSTDB has been updated to allow full accessibility to the density and viscosity predictive models, which are based on Redlich-Kister expansions of MSTDB-TP raw data. Some other major aspects of this report, in terms of preliminary and future work, include: (1) documentation of the formalism and preliminary testing of a kinetic theory model that may act as a predictive model for thermal conductivity; (2) documentation of the candidate predictive models that may be considered in the future for surface tension, making use of the surface tension data now in MSTDB-TP v4.0; (3) a preliminary account of a data collection process that will enable the filling of additional gaps within MSTDB-TP, namely with data which have been collected computationally (e.g., through ab initio molecular dynamics).

22 GENERAL STUDIES OF NUCLEAR REACTORS↗