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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
DOE OSTI2022

RouteE API

This is the API endpoint for RouteE energy prediction, which can be used to get both single vehicle link or route energy estimates and transportation network-wide energy consumption estimates for a variety of vehicles. This enables external researchers and transportation engineers to access and utilize NREL's growing library of pre-trained vehicle models for prediction of transportation energy consumption. This API provides three endpoints: - /route: Energy estimation of a vehicle over a planning link or sequence of links (route). - /network: Network-wide estimation of energy consumption for all vehicle traffic in the desired area. - /compass: Energy-optimal “eco-routing” between input origin and destination coordinates (Currently in beta for Denver metro area only).

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
DOE OSTI2026

RouteE API

This is the API endpoint for RouteE energy prediction, which can be used to get both single vehicle link or route energy estimates and transportation network-wide energy consumption estimates for a variety of vehicles. This enables external researchers and transportation engineers to access and utilize NLR's growing library of pre-trained vehicle models for prediction of transportation energy consumption. This API provides three endpoints: - /route: Energy estimation of a vehicle over a planning link or sequence of links (route). - /network: Network-wide estimation of energy consumption for all vehicle traffic in the desired area. - /compass: Energy-optimal “eco-routing” between input origin and destination coordinates (Currently in beta for Denver metro area only).

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
DOE OSTI2025

Evaluation of Maximum Allowable Working Pressure and Svensson Burst Pressure Recommended in API 579-1 2021 Edition

ABSTRACT API 579-1/ASME FFS-1 2021 Edition provides the minimum wall thickness, the maximum allowable working pressure (MAWP), and the membrane stress equations for thin and thick-walled cylindrical shells subject to internal pressure in Section 2C.3.3.1 of Appendix 2C – Thickness, MAWP, and Stress Equations for an FFS Assessment. The minimum wall thickness and MAWP are determined using the hoop stress and the Tresca yield criterion. Section 2C.7 – Estimation of Burst Pressure newly added the Svensson method for calculating burst pressure of cylindrical shells under internal pressure, where the plastic yielding is characterized by the von Mises yield criterion. For thin-walled cylinders, the von Mises flow solution of burst pressure in Equation (2C.179) was recommended. For thick-walled cylinders, an implicit burst pressure solution in an integral equation (2C.176) was recommended. But this integral equation is inconvenient to use in practice. It is well known that the classic plasticity theory includes the Tresca and von Mises yield criteria, with the Tresca criterion predicting a lower bound solution and the von Mises criteria predicting an upper bound solution. In addition, the present author developed an average shear stress yield criterion that can determine more accurate limit and burst pressures for thin and thick-walled cylinders. This work uses these three yield criteria to evaluate the minimum required wall thickness, MAWP and Svensson burst pressure recommended in the API 579 code.

burst pressure↗
DOE OSTI2021

Demonstrating SolarPILOT’s Python API Through Heliostat Optimal Aimpoint Strategy Use Case

SolarPILOT is a software package that generates solar field layouts and characterizes the optical performance of concentrating solar power (CSP) tower systems. SolarPILOT was developed by the National Renewable Energy Laboratory (NREL) as a stand-alone desktop application but has also been incorporated into NREL’s1 System Advisor Model (SAM) in a simplified format. Prior means for user interaction with SolarPILOT have included the application’s graphical interface, the SAM routines with limited configurability, and through a built-in scripting language called “LK.” This paper presents a new, full-featured, Python-based application programmable interface (API) for SolarPILOT, which we hereafter refer to as CoPylot. CoPylot provides access to all SolarPILOT’s capabilities to generate and characterize power tower CSP systems seamlessly through Python. Supported capabilities include (i) creating and destroying a model instance with message reporting tools; (ii) accessing and setting any SolarPILOT variable including custom land boundaries for field layouts; (iii) programmatically managing receiver and heliostat objects with varied attributes for systems with multiple receiver or heliostat types; (iv) generating, assigning, and modifying solar field layouts including the ability to set individual heliostat locations, aimpoints, soiling rates, and reflectivity levels; (v) simulating solar field performance; (vi) returning detailed results describing performance of individual heliostats, the aggregate field, and receiver flux distribution; and, (vii) exporting Python-based model instances to multiple file formats. CoPylot enables Python users to perform detailed CSP tower analysis utilizing either the Hermite expansion technique (analytical) or the SolTrace ray-tracing engine. In addition to CoPylot’s functionality, Python users have access to the over 100,000 open-source libraries to develop, analyze, optimize, and visualize power tower CSP research. This enables CSP researchers to perform analysis that was previously not possible through SolarPILOT’s existing interfaces. This paper discusses the capabilities of CoPylot and presents a use case wherein we demonstrate optimal solar field aiming strategies.

41 EE - Solar Energy Technologies Office (EE-4S)↗
DOE OSTI2021

Demonstrating SolarPILOT's Python API Through Heliostat Optimal Aimpoint Strategy Use Case: Preprint

SolarPILOT is a software package that generates heliostat field layouts and characterizes the optical performance of concentrating solar power (CSP) tower systems. SolarPILOT was developed by the National Renewable Energy Laboratory (NREL) as a stand-alone desktop application but has also been incorporated into NREL's System Advisor Model (SAM) in a simplified format. Prior means for user interaction with SolarPILOT have included the application's graphical interface, the SAM routines with limited configurability, and through a built-in scripting language called "LK." This paper presents a new, full-featured Python-based application programmable interface (API) for SolarPILOT, which we hereafter refer to as CoPylot. CoPylot provides access to all SolarPILOT's capabilities to generate and characterize power tower CSP systems seamlessly through Python. Supported capabilities include (i) creating and destroying a model instances with message reporting tools; (ii) accessing and setting any SolarPILOT variable including custom land boundaries for field layout; (iii) programmatically managing receiver and heliostat objects with varied attributes for systems with multiple receiver or heliostat types; (iv) generating, assigning, and modifying heliostat field layouts including the ability to set individual heliostat locations, aimpoints, soiling rates, and reflectivity levels; (v) simulating heliostat field performance; (vi) returning detailed results describing performance of individual heliostats, the aggregate field, and receiver flux; and, (vii) exporting Python-based model instances to multiple file formats. CoPylot enables Python users to perform detailed tower CSP analysis utilizing either the Hermite expansion technique (analytical) or the SolTrace ray-tracing engine. In addition to CoPylot's functionality, Python users have access to the over 100,000 open-source libraries to develop, analyze, optimize, and visualize CSP tower research.

41 EE - Solar Energy Technologies Office (EE-4S)↗
DOE OSTI2021

SPEARS: A Database-Invariant Spectral modeling API

The Spectral Physics Environment for Advanced Remote Sensing (SPEARS) application programming interface (API) is a Python-based, line-by-line, local thermal equilibrium (LTE) spectral modeling code which is optimized for simultaneously synthesizing optical spectra from any combination of fundamental spectroscopic databases. In this article, we contribute two novel spectral modeling techniques to the scientific literature. First we describe how SPEARS integrates a physics-based collisional model for calculating pressure broadening in the absence of available broadening coefficients. With this collisional model implementation, a generalized approach to fundamental spectroscopic databases can be achieved across multiple databases. We also detail our adaptive grid mesh algorithm developed to make the code scalable for simulating large spectral bandwidths at high spectral fidelity using intuitive grid parameters. Here, we present comparisons to other modeling tools, experiments, and provide a discussion on the SPEARS user interface.

47 OTHER INSTRUMENTATION↗
DOE OSTI2024

Reinforcement expectation in the honeybee ( Apis mellifera ): Can downshifts in reinforcement show conditioned inhibition?

When animals learn the association of a conditioned stimulus (CS) with an unconditioned stimulus (US), later presentation of the CS invokes a representation of the US. When the expected US fails to occur, theoretical accounts predict that conditioned inhibition can accrue to any other stimuli that are associated with this change in the US. Empirical work with mammals has confirmed the existence of conditioned inhibition. But the way it is manifested, the conditions that produce it, and determining whether it is the opposite of excitatory conditioning are important considerations. Invertebrates can make valuable contributions to this literature because of the well-established conditioning protocols and access to the central nervous system (CNS) for studying neural underpinnings of behavior. Nevertheless, although conditioned inhibition has been reported, it has yet to be thoroughly investigated in invertebrates. Here, we evaluate the role of the US in producing conditioned inhibition by using proboscis extension response conditioning of the honeybee (Apis mellifera). Specifically, using variations of a “feature-negative” experimental design, we use downshifts in US intensity relative to US intensity used during initial excitatory conditioning to show that an odorant in an odor–odor mixture can become a conditioned inhibitor. We argue that some alternative interpretations to conditioned inhibition are unlikely. However, we show variation across individuals in how strongly they show conditioned inhibition, with some individuals possibly revealing a different means of learning about changes in reinforcement. We discuss how the resolution of these differences is needed to fully understand whether and how conditioned inhibition is manifested in the honeybee, and whether it can be extended to investigate how it is encoded in the CNS. It is also important for extension to other insect models. In particular, work like this will be important as more is revealed of the complexity of the insect brain from connectome projects.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2025

Secure API-Driven Research Automation to Accelerate Scientific Discovery

The Secure Scientific Service Mesh (S3M) provides API-driven infrastructure to accelerate scientific discovery through automated research workflows. By integrating near real-time streaming capabilities, intelligent workflow orchestration, and fine-grained authorization within a service mesh architecture, S3M enables secure and flexible programmatic access to high performance computing (HPC) resources. This framework allows intelligent agents and experimental facilities to dynamically provision resources and execute complex workflows, accelerating experimental lifecycles, and enabling AI-augmented autonomous science. S3M establishes a modern foundation for scientific computing infrastructure that significantly reduces traditional barriers between researchers, computational resources, and experimental facilities.

Skluzacek, Tyler [ORNL] (ORCID:0000000322424931)↗
DOE OSTI2022

api-umbrella-cookbook [SWR-12-16]

This is the repository for api-umbrella-cookbook developed at National Renewable Energy Laboratory. This repository has been archived by the owner, as it is no longer used. The files are now available as read-only.

Muerdter, Nick↗
DOE OSTI2023

Python package for machine-readable access to PDG data (PDG Python API) v0.1

This Python package implements a high-level interface to access the data published by the Particle Data Group (PDG) in the Review of Particle Physics (the "Review"). The Particle Data Group is an international collaboration led by the PDG group at LBNL. The PDG summarizes the established knowledge in the field of particle physics in a single publication, the Review of Particle Physics. The Review is published and updated online (see https://pdg.lbl.gov) each year, and published in a scientific journal every other year. It is currently licensed under a CC BY-NC 4.0 license. In 2021 PDG was designated by the Office of Science as a SC PuRe Data Resource. The Review is one of the most highly cited publications in the field of particle physics. The PDG Python API is part of PDG's efforts to make all data provided in the Review available in machine-readable format. This data includes the PDG world averages (or best limits) on particle masses, widths or lifetimes, branching fractions, magnetic moments, form factors, coupling constant ratios, and searches, as well as particle quantum numbers. It also includes detailed information on how PDG arrived at its averages, such as e.g. tables of published measurements with comments and footnotes, information on the consistency of published measurements, and detailed fit information.

Beringer, Juerg↗
DOE OSTI2020

OpenSNAPI: Toward a Unified API for SmartNICs

The end of Moore’s Law and Dennard Scaling has produced a renaissance in the field of computer architecture. Unable to continue leveraging silicon-level processor improvements to further enhance performance and scalability, system architects have been forced to explore other options. In this new era of heterogeneous architectures and hardware/software codesign, a new class of devices known as “accelerators” has emerged. Independently designed for optimized execution of distinct workloads, these devices have proven critical to the continued advancement of application performance. SmartNICs, accelerator devices integrated with a network controller, have conventionally been utilized to offload low-level networking functionality. However, newer SmartNIC variants, which incorporate a system-on-chip (SoC) with traditional designs, are challenging this precedent. Leveraging significantly augmented resources, these new devices offer increased versatility and the potential to more effectively complement a given architecture’s CPU. In this talk, we introduce the motivation underlying acceleration, explore the fundamentals of SmartNICs, and discuss traditional use cases. We also detail our initial efforts to investigate the feasibility and benefits of SmartNICs as general-purpose accelerators. We present the OpenSNAPI project created to define a uniform application programming interface (API) for this emerging class of devices. Finally, we provide a brief tutorial regarding development of SmartNIC-accelerated applications on Los Alamos National Laboratory’s SmartNIC-enabled platforms.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2020

A File Format and API for Dynamic Radar Cross Section Data

Often the Radar Cross-Section (RCS) of a target is incorrectly assumed to be a single number by those unfamiliar with electromagnetic scattering. In actuality, a target's RCS depends on many factors. These factors include radar signal frequency, radar observation angle, as well as target orientation. Another possible parameter (often not considered) is time. The RCS of targets may change over time due to movement, environmental changes, etc. In order to accurately represent the dynamic RCS of a target in a time-stepped analysis, the ability to interface with large RCS datasets efficiently is desired. To this end, a file format and API (written in C++) were developed and are described in this report.

42 ENGINEERING↗
DOE OSTI2021

Secure Communications Concept and API Concept for Integrating XENDEE Positronix with TESLA PowerPack System at Site 300 (Final Deliverable)

The CleanStart DERMS project focuses on the management of Distributed Energy Resources (DER) for enhanced distribution grid resilience. The demonstration site has changed from Riverside Public Utility to the LLNS Site 300 DERS demonstration site. This project has so far focused only on device level controllers and local area controllers. These controllers potentially lack the ability to perform supervisory control and grid interactive control functions, essential for grid-level optimal DER management. This project seeks to close that gap in development of secure communication concept and appropriate Application Programming Interfaces (API) to enable integration with DERs, device level and local area controllers, such as Distributed Energy Resources Management System (DERMS).

24 POWER TRANSMISSION AND DISTRIBUTION↗
DOE OSTI2025

Risks Associated with Sharing the MOSSAIC APIs

The MOSSAIC APIs contain two files which, in theory, could be used to discover information about the pathology report data from the SEER registries on which the AI models were trained. In this document, we explain the contents of these files and assess the associated risk. APPENDIX A contains a set of slides to aid in the dissemination of this information.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

Petrographic and Advanced Geologic Characterization Report on One Earth Energy #1 (API# 1211325373)

The One Earth Energy #1 (OEE1, API 1211325373) well was drilled to a depth of 7,099 feet from the Pennsylvanian bedrock to the Precambrian granite. In total, 99 thin sections were taken from Rotary Sidewall Core (RSWC) from 2,275 feet to 6,903 feet; 59 thin sections were taken from Whole Core (WC) from 4,311.5 to 6,519.2 feet for this report. This report details specifically thin section point-counting analysis that includes mineralogical and pore space analysis, including grain size analysis annotated thin section photomicrographs, scanning electron microscopy (SEM) with energy dispersive X-ray spectroscopy (EDS), and statistics of grain size analysis on Mount Simon thin sections from OEE1. Characterized units include the St. Peter Sandstone, Eminence Formation, Potosi Dolomite, Franconia Formation, Davis Member, Ironton Sandstone, Galesville Sandstone, Eau Claire Formation, Elmhurst Sandstone, Mt. Simon Sandstone, and Argenta Formation.

09 BIOMASS FUELS↗
DOE OSTI2025

Petrographic and Advanced Geologic Characterization Report on Lively Grove #1 (API# 1218924947)

Lively Grove #1 (LG1 API number 1218924947) well was drilled to a depth of 5,758 feet, from the Glen Dean Limestone to the top of the Precambrian unit. In total, 49 thin sections were taken from Rotary Sidewall Core (RSWC), and one thin section was taken from Whole Core (2,918 feet, New Albany Shale) from 1,700 to 5,872 feet for this report. This report details specifically thin section point-counting analysis that includes mineralogical and pore space analysis, including grain size analysis annotated thin section photomicrographs, scanning electron microscopy (SEM) with Energy Dispersive x-ray Spectroscopy (EDS), X-ray Diffraction (XRD), statistics of grain size analysis on St. Peter Sandstone thin sections, and Argon-Argon (Ar-Ar) dating on Precambrian samples from LG1. Characterized units include the Salem Limestone, New Albany Shale, Trenton Group, Joachim Dolomite, St. Peter Sandstone, Everton Formation, Eminence Formation, Davis Member, Eau Claire Formation, and Precambrian Basement.

01 COAL, LIGNITE, AND PEAT↗
DOE OSTI2025

Redesign of the Timeline Generator at Fermilab using a web-based Flutter Application, GraphQL API and an IOC

Redesign of the Timeline Generator at Fermilab using a web-based Flutter application, GraphQL API and an IOC ABSTRACT = The control system at Fermilab is undergoing an evolution with a shift towards web-based applications with connections to the EPICS infrastructure. The Timeline Generator (TLG) is an application that serves to coordinate events across the lab using different timing links. These links include the Tevatron clock (TCLK), a 10 MHz serial link with events encoded at 20Hz and Ma-chine Data (MDAT), a communication link with states encoded at 720Hz. This paper covers the redesign of the major components of the TLG. This includes a web-based Flutter application for building timelines. A placement service is in use that has a GraphQL interface and uses a timeline input to compute a schedule of events and states. The Flutter application sends this computed schedule to the TLG IOC via a GraphQL interface to the Data Pool Manager (DPM). The TLG IOC runs on an Arria FPGA, the Accelerator Clock Generator (ACLK-GEN), which is responsible for writing the events and states on to the different timing links.

Carmichael, Linden [Fermilab]↗