Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “application programming interface”

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 199 records · Page 11

ZPAL v.1.0.0

SAND2024-01003O ZPAL is a Python software development kit designed for use by network automation engineers. It is an application programming interface (API) wrapper that is compatible with ZPE System's Nodegrid API. ZPE produces networking equipment. ZPAL simplifies connections to the ZPE Nodegrid API and makes configuration changes on the associated networking equipment. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

Hill, Roscoe↗

Scribe Network API v.1.0.0

SAND2023-07864O Scribe Network API is an add-on tool for Scribe3D software. Scribe Network API documents tabletop exercises in trainings and plays back simulated videos of the scenarios and responses. Users can apply the software to compiled projects, or to a simple visual studio project solution package. The software runs a web application that relays information between computers using Scribe3D through a web application, or web app. The web app involves a representational state transfer (REST) application programming interface that handles sending and receiving Scribe save files and an SQL server that stores the save files. This follow-on package allows users to facilitate a networked tabletop exercise. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

Noel, Todd↗

pnnl/SHAD

Scalable High-performance Algorithms and Data-structures. Scalable High-performance Algorithms and Data-structures (SHAD) is an application programming interface based on a generic software library. It has a modular design that enables reuse of modules. The core of this software tool set is built on an Abstract Runtime interface and it's library includes the common data structures such as array, vector, map and set. It is designed to accommodate significant amount of data which can be accessed in massively parallel environments, and used as building blocks for SHAD extensions, i.e. higher level software libraries.

Castellana, Vito↗

pnnl/buildingid-js

Unique Building Identification (UBID) for JavaScript This is a line-for-line translation from the Python programming language to the JavaScript programming language of the UBID application programming interface (API): the "encode", "decode" and "isValid" UBID functions. No new functionality is introduced.

Borkum, Mark↗

Battery Lifecycle Framework

The Battery Lifecycle (BLC) Framework is an open-source platform that provides tools to visualize and share battery data from material characterization, cell testing, manufacturing, and field testing through the technology development cycle. BLC has three components: data importers, a front-end for querying the data and creating visualizations, and an application programming interface to provide access to the data from Python. BLC has been deployed for tracking the development of a battery from the lab to a manufacturing line and systems installed in the field and for comparing studies of multiple cells of the same battery chemistry and configuration. The code was developed around Redash, a robust open-source extract-transform-load engine. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525. SAND2021-4546 O

De Angelis, Valerio↗

Dispatch Optimization Variable Engine

The Dispatch Optimization Variable Engine (DOVE) is software tool written in python, developed at Idaho National Laboratory (INL) that provides an easily accessible application-programming-interface (API) to performing resource dispatch optimization analysis for integrated energy system (IES) configurations. DOVE is an integral part of the Framework for Optimization of Resources and Economics (FORCE) software suite and is leveraged by codes such as the Holistic Energy Resource Optimization Network (HERON) and the Optimization of Real-Time Capacity Allocation (ORCA). The philosophy behind DOVE is to provide a modular software solution to IES planning and operation by utilizing state-of-the-art algorithms and machine learning. The goal is to accurately capture the dispatching behavior of a complex energy system given varying time-dependent signals for demand and commodity pricing.

McDowell, DylanJ. [Idaho National Laboratory (INL)↗

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.↗

The SONATA data format for efficient description of large-scale network models

Increasing availability of comprehensive experimental datasets and of high-performance computing resources are driving rapid growth in scale, complexity, and biological realism of computational models in neuroscience. To support construction and simulation, as well as sharing of such large-scale models, a broadly applicable, flexible, and high-performance data format is necessary. To address this need, we have developed the Scalable Open Network Architecture TemplAte (SONATA) data format. It is designed for memory and computational efficiency and works across multiple platforms. The format represents neuronal circuits and simulation inputs and outputs via standardized files and provides much flexibility for adding new conventions or extensions. SONATA is used in multiple modeling and visualization tools, and we also provide reference Application Programming Interfaces and model examples to catalyze further adoption. SONATA format is free and open for the community to use and build upon with the goal of enabling efficient model building, sharing, and reproducibility.

59 BASIC BIOLOGICAL SCIENCES↗

Knowledge Beacons: Web services for data harvesting of distributed biomedical knowledge

The continually expanding distributed global compendium of biomedical knowledge is diffuse, heterogeneous and huge, posing a serious challenge for biomedical researchers in knowledge harvesting: accessing, compiling, integrating and interpreting data, information and knowledge. In order to accelerate research towards effective medical treatments and optimizing health, it is critical that efficient and automated tools for identifying key research concepts and their experimentally discovered interrelationships are developed. As an activity within the feasibility phase of a project called “Translator” (https://ncats.nih.gov/translator) funded by the National Center for Advancing Translational Sciences (NCATS) to develop a biomedical science knowledge management platform, we designed a Representational State Transfer (REST) web services Application Programming Interface (API) specification, which we call a Knowledge Beacon. Knowledge Beacons provide a standardized basic API for the discovery of concepts, their relationships and associated supporting evidence from distributed online repositories of biomedical knowledge. This specification also enforces the annotation of knowledge concepts and statements to the NCATS endorsed the Biolink Model data model and semantic encoding standards (https://biolink.github.io/biolink-model/). Implementation of this API on top of diverse knowledge sources potentially enables their uniform integration behind client software which will facilitate research access and integration of biomedical knowledge.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗

Stanford Thermal Earth Model for the Conterminous United States

Provided here are various forms of the Stanford Thermal Earth Model, as well as the data and methods used for its creation. The predictions produced by this model were visualized in two-dimensional spatial maps across the modeled depths (0-7 km) for the conterminous United States. The thermal earth model is made available as an application programming interface (API) and as feature layers on ArcGIS, which are both provided via links below. A data-driven spatial interpolation algorithm based on physics-informed graph neural networks was used to develop these national temperature-at-depth maps. The model satisfied the three-dimensional heat conduction law by predicting subsurface temperature, surface heat flow, and rock thermal conductivity. Many physical quantities, including bottomhole temperature, depth, geographic coordinates, elevation, sediment thickness, magnetic anomaly, gravity anomaly, gamma-ray flux of radioactive elements, seismicity, and electric conductivity were used as model inputs. Surface heat flow, temperature, and thermal conductivity predictions were constructed for depths of 0-7 km at an interval of 1 km with spatial resolution of 18 km2 per grid cell. The model showed superior temperature, surface heat flow and thermal conductivity mean absolute errors of 4.8C, 8.1 mW/m2 and 0.07 W/(C-m), respectively..

15 GEOTHERMAL ENERGY↗

Evi-Pro Lite API

This application programing interface provides output from NREL's EVI-Pro model and is used to power the EVI-Pro Lite tool at https://afdc.energy.gov/evi-pro-lite. These endpoints provide daily (24-hour) fleet-level charging load profiles for a variety of customizable scenarios.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗

Evi-Pro Lite API

This application programing interface provides output from NREL's EVI-Pro model and is used to power the EVI-Pro Lite tool at https://afdc.energy.gov/evi-pro-lite. These endpoints provide daily (24-hour) fleet-level charging load profiles for a variety of customizable scenarios.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗

Evi-Pro Lite API

This application programing interface provides output from NLR's EVI-Pro model and is used to power the EVI-Pro Lite tool at https://afdc.energy.gov/evi-pro-lite. These endpoints provide daily (24-hour) fleet-level charging load profiles for a variety of customizable scenarios.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗

DOE EV Data Collection - Vehicle Data

Vehicle data consist of electric vehicle performance data collected directly from the vehicle during standard operations. Data were collected using onboard data loggers that were either installed by the project team or preinstalled by the original equipment manufacturer. Data recorded by the data loggers were made accessible via an online web portal or an application programming interface. Different data loggers were used (HEM, ViriCiti, and Geotab), and the method for each vehicle is defined in the vehicle attributes file. Some systems collected data on a “trip-level” basis, in which each row of a table represents a single trip (the period between a key-on and key-off event), whereas other data were collected on a per-day basis, in which each row represents a single day of operation. Data were collected over a range of data collection periods, depending on the project. Data have been anonymized by removing information or decreasing information resolution as necessary so that fleets are not identifiable. Due to the wide range of vehicle types represented and variation in data collection, data parameters and frequencies differ between vehicles and fleets The **Performance Data Daily/Trip Data Dictionaries** contain definitions for each available parameter associated with a vehicle’s operations, aggregated at either a daily or trip level. The parameters available will vary from vehicle to vehicle, but every possible parameter will be defined. The **Vehicle Attributes Data Dictionary** contains definitions for each available parameter associated with a vehicle’s physical and functional attributes and fleet context. The **Vehicle Attributes** table contains specific vehicle characteristics, coded to an anonymous Vehicle ID. This Vehicle ID can be used as a key between vehicle data and vehicle attribute tables. The **Vehicle Data** tables contain the data from each vehicle’s operations, aggregated at either a daily or trip level, coded to an anonymous Vehicle ID. This Vehicle ID can be used as a key between vehicle data and vehicle attribute tables. Data is being uploaded quarterly through 2023 and subject to change until the conclusion of the project.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗

The Livewire Data Platform

The Livewire Data Platform makes it easy to search and share transportation and mobility-related data. The Livewire Data Platform supports the U.S. Department of Energy’s Office of Energy Efficiency and Renewable Energy’s Energy Efficient Mobility Systems (EEMS) Program goal of providing an affordable, efficient, safe, and accessible transportation future where mobility is decoupled from energy consumption. The Livewire Data Platform will function as a repository for all EEMS data and will support the following objectives: (1) EEMS partners with relevant data can catalog, document, and share project datasets via file-based sharing or Application Programming Interface (API) and can provides access management and usage auditing for those resources. (2) EEMS partners can securely search, discover and access shared datasets, their metadata, and available API’s. (3) External partners and researchers can discover EEMS capabilities and collaborate with EEMS partners.

99 GENERAL AND MISCELLANEOUS↗

ESS-DIVE Reporting Format for Dataset Package Metadata

ESS-DIVE’s (Environmental Systems Science Data Infrastructure for a Virtual Ecosystem) dataset metadata reporting format is intended to compile information about a dataset (e.g., title, description, funding sources) that can enable reuse of data submitted to the ESS-DIVE data repository. The files contained in this dataset include instructions (dataset_metadata_guide.md and README.md) that can be used to understand the types of metadata ESS-DIVE collects. The data dictionary (dd.csv) follows ESS-DIVE’s file-level metadata reporting format and includes brief descriptions about each element of the dataset metadata reporting format. This dataset also includes a terminology crosswalk (dataset_metadata_crosswalk.csv) that shows how ESS-DIVE’s metadata reporting format maps onto other existing metadata standards and reporting formats.Data contributors to ESS-DIVE can provide this metadata by manual entry using a web form or programmatically via ESS-DIVE’s API (Application Programming Interface). A metadata template (dataset_metadata_template.docx or dataset_metadata_template.pdf) can be used to collaboratively compile metadata before providing it to ESS-DIVE.Since being incorporated into ESS-DIVE’s data submission user interface, ESS-DIVE’s dataset metadata reporting format, has enabled features like automated metadata quality checks, and dissemination of ESS-DIVE datasets onto other data platforms including Google Dataset Search and DataCite.

54 ENVIRONMENTAL SCIENCES↗

CROCUS Low Cost All-in-One Weather Station AMB-004 Data Argonne National Laboratory Prairie Site

The Ambient Weather WS-2902D (AMB) is a low cost weather station that has become very useful for filling data gaps in harder to deploy locations. These low cost weather stations collect 13 second data, which is averaged to a five minute data output available to users through an Application Programming Interface (API) key. The data files contain measurements for precipitation, temperature, wind chill/heat index, relative humidity, dew point, UV index, solar radiation, wind speed, wind direction, wind gust, and with an external particulate matter 2.5 (PM 2.5) sensor. Having all of these measurements in one condense system allows for fast deploying and dense network capabilities. Three of the AMB weather stations were deployed at the Argonne Testbed for Multiscale Observational Science (ATMOS), a 20-acre prairie site at Argonne National Laboratory in Lemont, Illinois. The instruments are denoted by their three digit identifier (CMS-AMB-xxx) format. The data is presented as daily NetCDF (.nc) files, each containing approximately 24 hours of observations. Files follow the naming convention of: the project (CROCUS), location (atmos), instrument name (CMS-AMB-004), data level (raw, a1), and date (year, month, day). The NetCDF format can be accessed using common scientific software such as Python using xarray, netCDF4 or ACT-DOE.

EARTH SCIENCE > ATMOSPHERE > AEROSOLS > PARTICULAT↗

CMinx: A CMake Documentation Generator

This manuscript introduces CMinx, a program for generating application programming interface (API) documentation written in the CMake language, and CMake modules in particular. Since most of CMinx’s intended audience is comprised of C/C++ developers, CMinx is designed to operate similar to Doxygen, the de facto C/C++ API documentation tool. Specifically, developers annotate their CMake source with “documentation” comments, which are traditional CMake block comments starting with an extra “[” character. The documentation comments, written in reST, describe to the reader how the functions, parameters, and variables should be used. Running CMinx on the annotated source code generates reST files containing the API documentation. The reST files can then be converted into static websites with tools such as Sphinx or easily converted to another format via Pandoc.

97 MATHEMATICS AND COMPUTING↗