SEARCH · Engineering Papers

Results for “API,”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 55 records · Page 3

All sources NASA NTRS DOE OSTI

DOE OSTI2026

The LCLStream Ecosystem for Multi-Institutional Dataset Exploration

We describe a new end-to-end experimental data streaming framework designed from the ground up to support new types of applications – AI training, extremely high-rate X-ray time-of-flight analysis, crystal structure determination with distributed processing, and custom data science applications and visualizers yet to be created. Throughout, we use design choices merging cloud microservices with traditional HPC batch execution models for security and flexibility. This project makes a unique contribution to the DOE Integrated Research Infrastructure (IRI) landscape. By creating a flexible, API-driven data request service, we address a significant need for high-speed data streaming sources for the X-ray science data analysis community. With the combination of data request API, mutual authentication web security framework, job queue system, high-rate data buffer, and complementary nature to facility infrastructure, the LCLStreamer framework has prototyped and implemented several new paradigms critical for future generation experiments.

Rogers, David [ORNL] (ORCID:0000000251871768)↗

DOE OSTI2025

omni-engineer-lbl (omni) v0.5

This is a fork of the omni-engineer software developed by Pietro Schirano. My collaborators and I are altering the software to work better with our LBNL infrastructure and requirements. The software is a coding agent wrapper around LLM model APIs, and can use any of the APIs provided by LBNL's CBorg service, or any service that uses an OpenAI endpoint(s).

Fong, Timothy [Lawrence Berkeley National Laborato↗

DOE OSTI2025

extapi-acsys

Provides public APIs to the Fermilab control system. This service exposes several GraphQL endpoints for various, logical APIs that clients may use to retrieve control system data and, in some cases, make changes to the control system. This service is currently running on acsys-proxy.fnal.gov on port 8000 with the development instance on port 8001. The middle layer of the control system uses gRPCs for communications. The GraphQL resolvers of this service use various gRPC services to obtain the information that is returned. This uses the async-graphql and warp crates to provide GraphQL over http support. The resolvers use the tonic crate for gRPC client support.

Neswold, Rich [Fermi National Accelerator Laborato↗

DOE OSTI2025

BATMODS-lite [SWR-25-108]

Battery Analysis and Training Models for Optimization and Design Studies (BATMODS) is a Python package with an API for pre-built battery models. The original purpose of the package was to quickly generate synthetic data for machine learning models to train with. However, the models are generally useful for any battery simulations or analysis. BATMODS-lite includes the following: 1) A library and API for pre-built battery models 2) Kinetic/transport properties for common battery materials

Randall, Corey [National Laboratory of the Rockies↗

DOE OSTI2026

AQDrop Quantum Service (AQDrop) v1.0

AQDrop is a job management system designed to streamline access to the Advanced Quantum Testbed (AQT) at NERSC (National Energy Research Scientific Computing Center). It serves as a centralized middleware layer between researchers and quantum processing hardware. Key Features: AQDrop provides a FastAPI-based server backed by PostgreSQL for job submission, queue management, and role-based access control (members, operators, and administrators). Users submit Qiskit circuits via JSON payloads, which are queued, dispatched to the QPU through the Qubic API, and returned as measurement counts. A Python client library and web dashboard round out the interface options. Primary Use: Researchers submit quantum circuit jobs from a laptop or login node; an operator client executes those jobs on the AQT's physical QPU and returns results — all coordinated through the central API. Advantages: Compared to ad-hoc or direct hardware access, AQDrop adds structured queue management, auditable job-status tracking and OAuth2 authentication — reducing scheduling conflicts and unauthorized access. Its containerized deployment also improves reproducibility and scalability. Overall, AQDrop functions as a purpose-built quantum job broker tailored to NERSC's specific hardware and institutional access requirements.

Caplinger, Evan [Lawrence Berkeley National Labora↗

DOE OSTI2026

Fact Inventory

API to store fact iA lightweight API service built with Litestar for collecting and storing system information from remote hosts. Designed to handle large-scale concurrency, the service receives HTTP submissions of system facts and package inventory from Ansible, curl, or other client tooling.nformation

Riehecky, Pat [Fermi National Accelerator Laborato↗

DOE OSTI2025

Exascale workflow applications and middleware: An ExaWorks retrospective

Exascale computers offer transformative capabilities to combine data-driven and learning-based approaches with traditional simulation applications to accelerate scientific discovery and insight. However, these software combinations and integrations are difficult to achieve due to the challenges of coordinating and deploying heterogeneous software components on diverse and massive platforms. Here, we present the ExaWorks project, which addresses many of these challenges. We developed a workflow Software Development Toolkit (SDK), a curated collection of workflow technologies that can be composed and interoperated through a common interface, engineered following current best practices, and specifically designed to work on HPC platforms. ExaWorks also developed PSI/J, a job management abstraction API, to simplify the construction of portable software components and applications that can be used over various HPC schedulers. The PSI/J API is a minimal interface for submitting and monitoring jobs and their execution state across multiple and commonly used HPC schedulers. We also describe several leading and innovative workflow examples of ExaWorks tools used on DOE leadership platforms. Furthermore, we discuss how our project is working with the workflow community, large computing facilities, and HPC platform vendors to address the requirements of workflows sustainably at the exascale.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2024

DE-FE0029488 - North Dakota Integrated Carbon Capture and Storage Complex Feasibility Study Public Data

Data from award DE-FE0029488 - North Dakota Integrated Carbon Capture and Storage Complex Feasibility Study performed by the Energy & Environmental Research Center including the following: - 2D Seismic {Input data, sgy files, maps, logs, and descriptors} - Core Petrophysics {Core analysis of plugs from the two stratigraphic test wells (Flemmer-1 [API 33-057-00039] and BNI-1 [API 33-065-00018])} - North Dakota Oil and Gas File No 37380 Files - North Dakota Oil and Gas File No 37672 Files - Well Testing Data {Summary of well testing methods and results from the stratigraphic test wells (Flemmer-1 and BNI-1)} Additional References: https://www.netl.doe.gov/sites/default/files/2017-12/Wesley-Peck-_Mastering-the-Subsurface_CarbonSAFE-Phase-II_August-2017-final.pdf Peck, W.D., Ayash, S.C., Klapperich, R.J., Gorecki, C.D. (2019) The North Dakota integrated carbon storage complex feasibility study, International Journal of Greenhouse Gas Control, Volume 84, 2019, Pages 47-53, https://doi.org/10.1016/j.ijggc.2019.03.001

Carbon Storage↗

DOE OSTI2024

IDAES-PSE 2.5.0 Release

The Institute for the Design of Advanced Energy Systems (IDAES) Integrated Platform is a versatile computational environment offering extensive process systems engineering (PSE) capabilities for optimizing the design and operation of complex, interacting technologies and systems. IDAES enables users to efficiently search vast, complex design spaces to discover the lowest cost, most environmentally sustainable solutions while supporting the full process modeling lifecycle, from conceptual design to dynamic optimization and control. The extensible, open platform empowers users to create models of novel processes and rapidly develop custom analyses, workflows, and end-user applications. IDAES-PSE 2.5.0 Release Highlights Upcoming Changes IDAES will be switching to the new Pyomo solver interface in the next release. Whilst this will hopefully be a smooth transition for most users, there are a few important changes to be aware of. The new solver interface uses a different version of the IPOPT writer (“ipopt_v2”) and thus any custom configuration options you might have set for IPOPT will not carry over and will need to be reset. By default, the new Pyomo linear presolver will be activated with ipopt_v2. Whilst are working to identify any bugs in the presolver, it is possible that some edge cases will remain. IDAES will begin deploying a new set of scaling tools and APIs over the next few releases that make use of the new solver writers. The old scaling tools and APIs will remain for backward compatibility but will begin to be deprecated. New Models, Tools and Features New diagnostics check for near-parallel variables and constraints. New diagnostics tools for identifying causes of infeasibility in models. New example for creating a custom model of a liquid-liquid extractor unit operation. Bug Fixes Fixed bug in Gibbs reactor that caused it to appear to have additional spurious degrees of freedom. Fixed bug in the Modular Property Framework that would cause errors when trying to use phase-based material balances with phase equilibria. Fixed bug in Modular Properties Framework that caused errors when initializing models with non-vapor-liquid phase equilibria. Testing and Robustness Deployed the IDAES Diagnostics Toolbox to confirm that there are no structural or numerical issues in the core model libraries. Additional robustness tests for core model, and some associated improvements in the converge tester class. Fixed a number of issues that were causing unexpected warnings to be emitted during testing. Deprecations and Removals Removed examples for RIPE tool which has not been supported for a number of releases.

AS↗

DOE OSTI2025

APOLLO: a facility-scale differentiable virtual accelerator at Fermilab FAST/IOTA

As the design complexity of modern accelerators grows, there is more interest in using advanced simulations that have fast execution time or yield additional insights like gradients. The FAST/IOTA facility has been working on implementing and experimentally validating an end-to-end digital twin that is both fast and gradient-aware, allowing for rapid prototyping of new software and experiments with minimal beam time costs. Our framework integrates physics and ML codes for linac and ring simulation through a set of generic interfaces between surrogate and physics-based sections. To reproduce device inputs and outputs, system state is exposed as a deterministic event loop in a specialized discrete event simulator architecture. Because Fermilab is undergoing control system transition, several APIs were implemented as final user interfaces - a fully asynchronous EPICS soft IOC, a gRPC-based Data Pool Manager (DPM), and legacy ACNET protocols. We discuss implementation details as well as challenges handling live data assimilation and future plans to extend modelling to main complex proton accelerators like PIPII and Booster.

Kuklev, Nikita [Fermilab]↗

DOE OSTI2024

Nion Swift FY2021 phase I Final Technical Report DE-SC0021546

Phase I of the project is an on-going success. The enhanced and extended new application programming interface (API) developed in Phase I is in use at customer sites around the world: Berlin, UK, US, China, France, Austria. The modules developed to demonstrate the new API features are in daily use at these sites for acquiring, processing, and analyzing microscopy data from 4D- and 5D-STEM to single-point spectroscopy at highest resolution.

Lovejoy, Tracy↗

DOE OSTI2024

OpenFacadeControl: enabling integration of automated facades with other building systems

Automated facades are, for the most part, still considered as separate from other building systems throughout the design, installation, commissioning, operation, and maintenance cycle. This takes place despite the fact that their energy and comfort performance are deeply interlinked with the operation of lighting and HVAC systems. Over the last two decades, research has shown that there are significant advantages from operating facades as an integrated system with the rest of the building. Nevertheless, significant barriers prevent this type of integration becoming more common. One of them is the lack of a platform that is inexpensive to implement and that easily allows the practical implementation of integrated control algorithms across fenestration and other building systems, using a variety of communications protocols. This is particularly challenging when automated facades are installed in existing buildings, where interaction with legacy building systems that were installed over the past lifetime of the building can require a high degree of interoperability. OpenFacadeControl (OFC) is an open-source controls framework aimed at unified control of facades and other building systems, including the sharing of third-party sensor information. Through leveraging the Volttron controls platform, it allows the integration of systems and sensors that are manufactured by different companies and that use different communications protocols into an ensemble that functions as a single system. OFC is designed to enable integrated control algorithms of varying degrees of complexity, ranging from simple, heuristic controls to more sophisticated approaches like model-predictive control. Use of a research version to test advanced lighting and shading strategies in a full-scale experimental testbed has demonstrated the ease of deploying advanced control solutions using OpenFacadeControl. This paper presents the structure of OpenFacadeControl and a demonstration case showing the use of OFC in laboratory tests of advanced lighting and fenestration controls that coordinated motorized shades communicating via the BACnet building communications standard and lights communicating via internet-protocol-based application programming interface (API), based on the readings of a shared light level sensor communicating via a different API.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗

DOE OSTI2025

Fitness For Service Assessment of a Corroded Heat Exchanger

Within the Fermi National Accelerator complex, there exist various water systems that support accelerator operations. One of these systems is extremely vital to the operation of the machine; that is the cooling system. The cooling system consists of nine relatively large heat exchangers that take untreated pond water and use it to cool the process fluid that further cools machine components. Over the 30 years these heat exchangers have been in operation, they have undergone significant material loss on the channels. This material loss, due to various forms of corrosion such as galvanic and microbiologically influenced corrosion (MIC) and possibly others, has deteriorated more than 80% of the nominal wall thickness of some of the exchangers and placed them in a questionable state. ASME FFS-1 (API 579) has been applied to address the condition of the heat exchangers due to their noncompliance with the governing code, BPVC Sec. VIII Div. 1. The assessments encompassed ASME FFS-1 parts 4: General Metal Loss and 9: Crack Like Flaw using level 1, 2, and 3 analysis techniques based on inspection data obtained by API 510 inspections. Level 1 and 2 assessments were deemed unfit for the corroded regions due to their location relative to a major structural discontinuity (channel to tube-sheet joint), so a level 3 analysis was conducted according to ASME Sec. VIII Div. 2 (design by analysis) rules for pressure vessels. Supplemental information included pond water tests to determine an accurate future corrosion allowance due to lacking inspection history. A leak before break (LBB) route was chosen to evaluate the possibility of leaking prior to the onset of failure. The analysis of one heat exchanger shows that the possibility the channel will develop a pinhole leak over 2.5 more years of operation should not be overlooked, but burst was unlikely from operation. The use of fracture mechanics show, that if a through-wall crack were to develop, it would not propagate further than the channel geometry and cause a leak not greater than 35 GPM. Using ASME Section XI Code Case N-705-1, allowing us to operate with a leak until the next outage given certain operating conditions and developing a leak mitigation procedure, this heat exchanger is deemed fit-for-service.

Humenik, Alex [Fermilab]↗

DOE OSTI2025

Design Basis Document / Owner’s Technical Specification for Nitrate Salt Systems in CSP Projects (Final Technical Report)

The number of commercial coal, gas, and nuclear projects built over the past 100 years number in the thousands. As such, there is a large database, available to a wide range of commercial engineering contractors, on proven designs. In essence, unsuccessful designs have, through generations of iterations, been identified and then deleted from further consideration. In contrast, the number of commercial parabolic trough projects using nitrate salt for the thermal storage media is perhaps 60. Further, the number of commercial central receiver projects using nitrate salt as the working fluid is on the order of 20, including estimates for China. Given the relative immaturity of salt technology, and commercial pressures to successfully bid new solar projects into a mature electricity market, solar projects often promise more than has been delivered. The Design Basis Document / Owner’s Technical Specification is a first step in the iteration process. The report describes the successful features of commercial projects, outlines a range equipment and system failures in projects that didn’t operate as intended, and provides a draft set of design changes intended to correct the known problems. The product of the study is 3 volumes of technical material; one volume is on parabolic trough technologies; a second is on central receiver technologies, and the third is on potential design changes to parabolic trough and central receiver projects. The 3 volumes, which total some 590 pages, can be found at https://www.solardynllc.com/csp-plant-technologies. One of the principal topics in the report is the use of functional or prescriptive specifications. Functional specifications describe what the equipment needs to do, consistent with the minimum legal requirements of the local jurisdictions. The details of how this is to be accomplished is developed by the engineering contractor. Prescriptive specifications, which are developed by the Owner, prescribe to the engineering contractor how the functional requirements are to be met. This arrangement ensures that the favorable experience from a previous project is repeated. One example is the design code for the hot salt tank in central receiver projects. The closest design basis is API Standard 650 Welded Steel Tanks for Oil Storage. However, the maximum design temperature in API 650 is 260 °C. As such, solar projects have typically adopted a hybrid Code approach, in which allowable material stresses are taken from ASME Section II Materials. Further, since the tanks experience daily changes in temperature and in (static) pressure, and since portions of the tank can operate at stresses beyond the elastic range, the low cycle fatigue life of the tank is conducted using the rules of Section VIII Division 2. However, in a recent study by NREL, the principal damage mechanism was identified as creep rather than fatigue. Further, design stresses permitted under Section VIII Division 2, corresponding to a fatigue life of 30 years, result in projected creep lifetimes of only 2 to 5 years. An alternate design approach, prescribed by the Owner, would be based on Code sections intended for high temperature service in the creep regime. A candidate is Section III Division 5. Granted, this is a nuclear code section, and it’s use would not likely be mandated by local jurisdictions. However, the effects of creep have been deemed to be of sufficient importance that one nuclear project developer, and one central receiver project developer, have stipulated in the tank design specification that the equipment be designed to the requirements of Section III Division 5.

14 SOLAR ENERGY↗

DOE OSTI2025

DeepDiagnostics: A Software Package for Streamlined Posterior Evaluation

Automated prediction techniques like simulation-based inference (SBI) are important tasks for science experiments that produce large amounts of complex, raw data. However, their development remains in its early stages because the uncertainties of these techniques lack sufficient trustworthiness and interpretability. Packages for SBI provide a growing set of diagnostics; however, the software requirements are substantial, as they are tied to the inference technology itself, and the APIs lack adaptability. We introduce the DeepDiagnostics package for diagnosing posteriors from analytic likelihood-based methods and SBI methods, such as neural posterior estimation. DeepDiagnostics produces a comprehensive set of high-quality visualizations and metrics in a highly accessible, easy-to-use, and flexible package. We address all of these goals by providing a command-line inference tool and a Python API that is controlled through a configuration file. The package includes common diagnostics, such as parity plots, corner (covariance) plots, simulation-based calibration (SBC) diagnostics (including posterior coverage and rank histograms), Lemos et al. s PQMass and TARP, Masserano et al. s WALDO, Linhart et al. s LC2ST, as well as credible region diagnostics developed by our group.

Voetberg, Maggie [Fermilab]↗

DOE OSTI2026

OES CO 2 Pipeline FEED Project Design Basis Memorandum

The OES CO₂ Pipeline project will move captured carbon dioxide from two ethanol facilities near Gibson City, Illinois, roughly 7.8 miles southeast to three injection wells outside Anchor, where it will be permanently stored underground. The system is designed to handle up to 4.5 million metric tonnes per year of dense-phase CO₂ at pressures up to 2,500 psig, using 16-inch mainline pipe and 10.750-inch laterals made from API 5L X-60 and X-65 steel. Wall thicknesses vary depending on location, with thinner pipe in open country, heavier wall at road crossings, and the heaviest where the pipe passes under highways or railroads via horizontal directional drill. The pipe gets a fusion-bonded epoxy coating, with an added abrasion-resistant layer wherever it's bored or drilled. Major water crossings will use HDD rather than open trenching. The pipeline will be cathodically protected, equipped with SCADA-compatible pressure and temperature instrumentation, and monitored for leaks using a computational pipeline monitoring system per API RP 1130. Hydrostatic testing will be performed at 1.25 times design pressure, and an ILI caliper run will follow to catch any construction defects. Several items, including fracture toughness requirements, specific NDE methods, and ILI tool selection, are left for the detailed design phase. The whole system falls under 49 CFR Part 195 and ASME B31.4, and Gulf Interstate Engineering prepared this document as the FEED-level design basis under the CarbonSAFE Phase III program.

09 BIOMASS FUELS↗

DOE OSTI2024

Atmospheric Ion Composition, SGP, April-May 2023

These files contain select ion count rates measured by an atmospheric pressure interface time-of-flight mass spectrometer (APi-ToF) at the Atmospheric Radiation Measurement Southern Great Plains site from April 28, 2023 to May 31, 2023. Files are in ICARTT format. The APi-ToF measures the chemical composition of naturally charged ions using mass spectrometry. Due to the nature of the measurements, time-series data are non-quantitative. This dataset contains time-series information for the ions that are typically the most intense ions observed.

54 ENVIRONMENTAL SCIENCES↗

DOE OSTI2025

NLR HPC Eagle Jobs Data and Additional Energy Metrics

Overview: Anonymized job-level records from the Eagle high-performance computing (HPC) system at the National Laboratory of the Rockies (NLR). Each record represents a Slurm batch job with scheduling metadata, resource requests, resource utilization, CPU/GPU energy consumption, and efficiency metrics. Sensitive fields (user, account, job name) are replaced with cryptographic hashes. System & Timeframe: Eagle was a 2,000-node, 8-petaflop system operated at NLR from 2019–2024. Data covers the full operational lifetime of the system. Slurm data was processed nightly; timestamps are in Mountain Time. Funding provided by the U.S. Department of Energy, EERE. Files: esif.hpc.eagle.job-anon.zip — Core anonymized job records (Hive-partitioned Parquet) esif.hpc.eagle.job-anon-energy-metrics.zip — Same records with additional iLO and Ganglia energy metrics datacard.md — Full dataset documentation ~13.8 million rows, 62 variables. Readable with PyArrow, pandas, DuckDB, Apache Spark, or any Parquet-compatible tool. Data Collection: Jobs collected via sacct through a pipeline: Eagle Jobs API → Redpanda → StreamSets → HPCMON API → PostgreSQL. Node-level power from iLO (HP Integrated Lights-Out); GPU power from Ganglia monitoring, joined to jobs via node lists and time ranges. Preprocessing: Anonymization of name, user, and account fields via cryptographic hashing Derived columns: queue_wait, cpu_eff, max_mem_eff Simplified job state mapping (e.g., "CANCELLED BY 12345" → "CANCELLED") QoS accounting rules (buy-in, standby, or Slurm QoS value) CPU energy estimated from TDP (200W, Intel Xeon Gold 6154, 18 cores) Timezone-aware columns (_tz) sourced from LEX accounting database to correctly handle DST transitions Key Variables: Scheduling: job_id, partition, state_simple, submit_time_tz, start_time_tz, end_time_tz, queue_waitResources: nodes_req/used, processors_req/used, memory_req, wallclock_req/used, gpus_requested Efficiency: cpu_eff, max_mem_eff Energy: cpu_energy_tdp_estimated_max/used_watt_hours, node_energy_total_watt_hours (iLO), gpu0/1_energy_total_watt_hours (Ganglia) Partitions: bigmem, bigmem-8600, bigscratch, csc, dav, ddn, debug, gpu, haswell, long, mono, short, standard Job States: CANCELLED, COMPLETED, FAILED, NODE_FAIL, OUT_OF_MEMORY, PENDING, RUNNING, TIMEOUT QoS Levels: Unknown, normal, buy-in, debug, penalty, high, standby Important Notes: Non-_tz timestamp columns may be off by one hour across DST boundaries; use _tz columns for time difference calculations Energy fields are null for jobs without monitoring coverage Job step records and raw Slurm JSONB fields are excluded from this extract Do not attempt to re-identify individuals from hashed fields

97 MATHEMATICS AND COMPUTING↗