Engineering Papers⌕ Search

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.

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

At least 145 records · Page 8
All sourcesNASA NTRSDOE OSTI
DOE OSTI2021

Archparse

Archparse is a Python package that holds the purpose and capability of converting the contents of a text file to a functioning neural network based on the Tensorflow 2.X framework. This is able to be done with minimal written Python code and next to no knowledge of how to build models with Tensorflow directly. More specifically Archparse parses a text file with extension ".arch" which contains neural network architecture information that corresponds to either the Tensorflow 2.X API or custom code written with the Tensorflow 2.X API. Included in the initial version is the capacity to easily produce sequential autoencoders and sequential neural networks.

Vander Wal, MichaelD.↗
DOE OSTI2022

pnnl/NWHypergraph

NWHypergraph is a C++ hypergraph processing framework for shared-memory architecture. NWHypergraph provides efficient algorithms to construct s-line graphs, a lower-order approximation of a given hypergraph, and computes different graph metrics of a s-line graph such as s-connected components, s-betweenness centrality, s-closeness centrality, etc. It also provides Python APIs for s-line graph computation. The Python APIs are provided using Pybind11

Lumsdaine, Andrew↗
DOE OSTI2022

pnnl/portfoliomanager-rb

This invention is a Ruby "gem" (library) that provides clients for ENERGY STAR Portfolio Manager (ESPM) Web Services, Inventive features: 100% coverage of version 18.0 of the ESPM API. Automated mapping between ESPM XML schemas and Ruby objects. Clients for both the "live" and "test" ESPM API environments. Debugging mode with HTTP request/response logging.

Borkum, Mark↗
DOE OSTI2023

OCHRE™ Gymnasium (ochre_gym) [SWR-23-47]

OCHRE™ Gymnasium is a Python framework for conducting reinforcement learning research on residential building energy management problems. It is a lightweight wrapper around OCHRE, a Python-based thermal-electric residential building simulator developed in-house at NREL. OCHRE Gymnasium adheres to the standard OpenAI Gym API for a reinforcement learning environment. Detailed Sphinx documentation will be auto-generated and accompany this codebase. This documentation will detail the API, provide examples of how to use the code, etc.

Emami, Patrick↗
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 OSTI2022

kynema-fmb [SWR-23-07]

Kynema-FMB (FKA: Kynema) is an open-source performance portable flexible multibody (FMB) dynamics solver designed for time-domain simulations. While originally tailored for wind turbine structural dynamics, the formulation and implementation are those of a general flexible-multidbody dynamics solver that can readily be applied to a wide range of systems. Kynema was designed with a narrow focus, namely to provide a lightweight, fast, accurate FMD solver for coupling to computational-fluid-dynamics (CFD) codes, especially the CFD codes in the Kynema suite, for fluid-structure-interaction (FSI) simulations. Kynema-FMB is equipped to model systems that can be represented as a collection of beams and rigid bodies that are connected through constraints. Degrees of freedom are defined in the inertial/global frame of reference and include displacements and rotations (formally as rotation matrices, but stored as quaternions). The underlying formulation is built on a Lie-group time integrator designed for index-3 differential-algebraic equations, which is second-order accurate in time (Bruls et al., 2012). Beam models are based on geometrically exact beam theory and are discretized as high-order spectral finite elements similar to those in BeamDyn (Wang et al., 2017). The governing equations for a FMD system like a wind turbine constitute a highly nonlinear system of constrained partial-differential equations. Kynema-FMB uses analytical Jacobians in the nonlinear-system solves in each time step. Linear systems use sparse storage and several third-party sparse-linear-system solvers are enabled. Ill conditioning of linear systems is mitigated with preconditioning described in Bottasso et al, 2008. Kynema-FMB is integrated with a simple open-source controller (ROSCO). There is an application programming interface (API) for coupling to geometry-resolved CFD (like that in Sharma et al., 2023) and actuator-force CFD (like that in Kuhn et al., 2025). In the latter, for actuator-line models, Kynema-FMB includes an internal blade-element solver that depends on user-provided lookup tables for coefficients of lift and drag, i.e., aerodynamic polars. Kynema-FMB is written in C++ and leverages Kokkos and Kokkos-Kernels (KokkosEcosystem) as its performance portability layer enabling simulations on both CPU and GPU systems. The repository is equipped with extensive automated testing at the unit and regression/system levels. The following describes the high-level development objectives conceived for Kynema: *Kynema will follow modern software development best practices, including test-driven development (TDD), version control, hierarchical automated testing, and continuous integration (CI) for a robust development environment. *The core data structures are memory efficient and enable vectorization and parallelization at multiple levels. *Data structures are data-oriented to exploit methods for accelerated computing including high utilization of chip resources (e.g., single instruction multiple data (SIMD) instruction sets) and parallelization using GP-GPUs. *The computational algorithms incorporate robust open-source libraries for mathematical operations, resource allocation, and data management. *The API design considers multiple stakeholder needs and ensure integration with existing and future ecosystems for data science, machine learning, and AI. *Kynema-FMB is written in modern C++ and leverages Kokkos as its performance-portability library with inspiration from the kynema stack.

Sprague, MichaelA.↗
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 OSTI2020

Locating Methyl-Etherified and Methyl-Esterified Uronic Acids in the Plant Cell Wall Pectic Polysaccharide Rhamnogalacturonan II

Rhamnogalacturonan II (RG-II) is a structurally complex pectic polysaccharide that exists as a borate ester cross-linked dimer in the cell walls of all vascular plants. The glycosyl sequence of RG-II is largely conserved, but there is evidence that galacturonic acid (GalA) methyl etherification and glucuronic acid (GlcA) methyl esterification vary in the A sidechain across plant species. Methyl esterification of the galacturonan backbone has also been reported but not confirmed. Here we describe a new procedure, utilizing aq. sodium borodeuteride (NaBD4)-reduced RG-II, to identify the methyl esterification status of backbone GalAs. Our data suggest that up to two different GalAs are esterified in the RG-II backbone. We also adapted a procedure based on methanolysis and NaBD4 reduction to identify 3-, 4-, and 3,4-O-methyl GalA in RG-II. These data, together with matrix-assisted laser desorption/ionization–time-of-flight mass spectrometry (MALDI-TOF) MS analysis of sidechain A generated from selected RG-IIs and their NaBD4-reduced counterparts, suggest that methyl etherification of the ß-linked GalA and methyl esterification of the GlcA are widespread. Nevertheless, the extent of these modifications varies between plant species. Our analysis of the sidechain B glycoforms in RG-II from different dicots and nonpoalean monocots suggests that this sidechain has a minimum structure of an O-acetylated hexasaccharide (Ara-[MeFuc]-Gal-AceA-Rha-Api-). To complement these studies, we provide further evidence showing that dimer formation and stability in vitro is cation and borate dependent. Taken together, our data further refine the primary sequence and sequence variation of RG-II and provide additional insight into dimer stability and factors controlling dimer self-assembly.

BASIC BIOLOGICAL SCIENCES↗
DOE OSTI2022

High-Mileage Courier Fleet Vehicle On-road Logger Data

This dataset describes the performance and fuel efficiency of AVTA test vehicles operating in commercial courier fleets the Phoenix, AZ metro area between 2010 and 2016. Aftermarket data loggers were installed in two to four vehicles of each of 30+ distinct year/make/models (see reference ["INL Advanced Vehicle Testing Activity: On-road Logger and Laboratory Battery Pack Testing Vehicle List"](https://avt.inl.gov/sites/default/files/pdf/reports/DatasetVehicleList.pdf) for full list of vehicles). Loggers recorded vehicle operation as they were driven up to 160,000 miles in up to three years of fleet testing. Parameters were logged at 1-second intervals, including - vehicle speed, - engine and/or electric motor speed, - fuel and/or electricity consumption, and - ambient temperature. This dataset includes both raw second-by-second data and trip-level metrics. (This dataset will be shared by API; a small sample of the vehicle and logger data has been extracted and is available for download while the API is being developed.)

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
DOE OSTI2022

High-Mileage Courier Fleet Vehicle Laboratory Battery Pack Testing

For one of each of the AVTA's plug-in hybrid electric vehicles, battery electric vehicles, and some hybrid electric vehicles tested in high-mileage courier fleets, the high-voltage traction battery packs were removed from the vehicle and tested at the beginning and end of fleet testing. For some vehicles, batteries also were tested at periodic intervals during fleet testing. Standard reference performance tests were conducted to characterize battery degradation over time. This dataset contains results from two or more rounds of battery tests for 21 distinct year/make/model vehicles (see reference ["INL Advanced Vehicle Testing Activity: On-road Logger and Laboratory Battery Pack Testing Vehicle List"](https://avt.inl.gov/sites/default/files/pdf/reports/DatasetVehicleList.pdf) for full list of vehicles). Each round of battery testing included the "Static Capacity Test" and the "Hybrid Pulse Power Characterization (HPPC) Test", conducted according to test procedures published in the United States Advanced Battery Consortium ["Battery Test Manual For Power-Assist Hybrid Electric Vehicles"](https://www.uscar.org/commands/files_download.php?files_id=57), ["Battery Test Manual For Plug-In Hybrid Electric Vehicles"](https://www.uscar.org/commands/files_download.php?files_id=168), and ["Electric Vehicle Battery Test Procedures Manual"](https://www.uscar.org/commands/files_download.php?files_id=5) prior to the time of testing. These tests were performed by Intertek Testing Services, North America. (This dataset will be shared by API; a small sample of the vehicle battery and test data has been extracted and is available for download while the API is being developed.)

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
DOE OSTI2020

Multi-Scale Lithofacies and Chemostratigraphic Analysis of Two Middle Devonian Marcellus Shale Wells in Northern West Virginia, USA

The Marcellus Shale Energy and Environmental Laboratory (MSEEL) consists of two project areas within the dry gas producing region of the Marcellus shale play in Monongalia County, West Virginia. MSEEL is a collaborative field project led by West Virginia University, with Northeast Natural Energy LLC, several industrial partners, and sponsored by the US Department of Energy National Energy Technology Laboratory. The study areas are drilled approximately 8.5 miles apart to better understand the vertical and lateral changes in stratigraphy over a short distance. Two vertical pilot wells, MIP-3H and Boggess 17H were drilled in the fall of 2015 and spring of 2019, respectively. Core was recovered from the MIP-3H (API: 47-061-01707-00-00) 112 feet (34m) between depths of 7445 to 7557 feet, and from the Boggess 17H (API: 47-061-01812-00-00) 139 feet (42m) between depths of 7908 and 8012 ft. A full suite of triple combo (gamma ray, neutron, density logs), image logs, and advanced logging tools were run in both wells and calibrated to core analysis. Core analysis includes medical computed tomography (CT) scans, mineralogy and chemostratigraphy determined from handheld X-Ray fluorescence (hhXRF) and X-Ray powder diffraction (XRD) measurements, and determination of total organic content (TOC). Lithofacies were determined at core-scale using traditional core description techniques and medical CT-scan images. Log-scale facies are based on mineralogy and TOC data and developed using petrophysical logging data calibrated to core data (XRD and pyrolysis data). Chemostratigraphic analysis utilized hhXRF data to determine the major and trace element trends in the cores. In the two wells six shale lithofacies were recognized at the core and log scale. Both wells show organic-rich facies (TOC > 6.5%) primarily in the middle and lower Marcellus, with a slight decrease in thickness of this interval in the Boggess 17H. This interval is interpreted as an increase in paleo-productivity (increased Ni, Zn, and V), decreased sedimentation (decreased detrital proxies), and anoxic to euxinic conditions (increased Mo and chalcophile elements). Paleo-redox conditions in both wells are dynamic throughout deposition transitioning between euxinic/anoxic to dysoxic/oxic. This trend is seen through elemental proxies and calcite/pyrite concretion distributions.

03 NATURAL GAS↗
DOE OSTI2023

WELLS Database

The Wellbore Exploration and Location Logistic System (WELLS) is a living national wellbore database - created and maintained by the National Energy Technology Laboratory (NETL). This resource contains more than seven million public wellbore records from state, federal, and tribal resources. Sourced from over 65 authoritative, yet disparate resources, the WELLS Database combines and synthesizes well data from oil, gas, underground injection, research, geothermal, geotechnical, groundwater and other types of wells in a single, unified system. This resource can be explored and visualized through the WELLS Interactive Application, also on EDX: https://edx.netl.doe.gov/dataset/wells-interactive-application The WELLS Database (formerly titled CO2-Locate) is an integrated national well dataset, representing open-source wellbore data from disparate state, tribal, and federal entities. The database provides publicly available well header data with key attributes such as well age, depth, and status. The database contains a fully integrated CSV file with all values in numerical columns, such as depth, converted into numbers. This version has a NETL derived API (American Petroleum Institute) number column and has been handled for redundancies, resulting in one record for every unique API number. The database also contains a fully integrated CSV file, where all original data are kept as text values. Additionally, the database includes a shapefile containing key attributes and coordinates from the integrated dataset, reformatted public wells CSV files, and a proprietary well density grid shapefile. Notes for consideration: The WELLS Database will be updated periodically with new datasets and information. A field dictionary with field (i.e., attribute) coverage across acquired public well resources, and the resulting integrated public well datasets are available in the spreadsheet, WELLS_Field_Dictionary.xlsx. Summary layers provided in this database are derived from proprietary layers and do not always contain key features (status, type, true vertical depth, or spud year) and therefore might not be shown when data are queried for those features.

AS↗
DOE OSTI2023

IDAES-PSE 2.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.0.0 Release Highlights Removal of deprecated features from IDAES v1 Update to Pyomo v6.5 – this required a number of updates to support the new NL solver writer and to address some changes in Pyomo Creation of new testing suite for backward compatibility, model robustness and verification More general implementation of the Helmholtz EoS. This brings some new features like standard property diagrams, choice of mass or mole basis, and new state variable options Standardizing names in Heat Exchanger models (breaking change from v2.0.0a2): Control Volumes named hot_side and cold_side Ports names hot_side_inlet, hot_side_outlet, cold_side_inlet and cold_side_outlet Config Blocks names hot_side_config and cold_side_config Config arguments for user provided names for each side: hot_side_name and cold_side_name. Updating Keras surrogate tool to use v1.1 of OMLT New prototype API for model initialization (idaes.core.initialization) The new API uses "Model Initializer" objects instead of class methods, allowing for the definition of multiple initialization routines for a single model A number of common, model agnostic initialization routines have also been defined, including initialization from data, block-decomposition and a general hierarchical approach equivalent to the existing method for common unit models New metadata for thermophysical properties – valid_range This can be used to record the range of values over which a property value can be trusted, such as the range of experimental data used to regress parameters A number of new utility functions have been added to check for properties with values outside the valid range and to set bounds based on this metadata Updated construction of balance expressions in Control Volumes to remove unneeded terms In the past, unneeded terms were added as a constant 0 term, however they will now be dropped entirely from the expression This was necessary due to more strict unit checking in the new Pyomo solver writer which no longer ignores 0 terms Updates to metadata for thermophysical properties to better define known properties and units of measurement This results in more strict enforcement of standard naming for thermophysical and reaction properties Users can still define custom properties, but these must be done explicitly using the define_custom_properties() method instead of being implicitly created by add_property() Updated convergence tester utility tool to support definition of benchmark files (JSON format) and comparison of performance to benchmarks Set default iteration limit for IPOPT in IDAES config to 200 iterations Update scaling of example models to work with new Pyomo NL solver writer Improve testing of extensions and examples infrastructure to avoid need for downloading files Updated distillation column to centralize common functionality and remove a number of Pyomo warnings

IDAES↗