TILED-EXPORT
SF-25-094 A client for the Bluesky Tiled API that allows bulk export of files.
SEARCH · Engineering Papers
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.
SF-25-094 A client for the Bluesky Tiled API that allows bulk export of files.
Memento Aggregator is a Java service that federates web archives worldwide: given an Original-URL and optional datetime, it discovers mementos and exposes standards-compliant Memento TimeGate and TimeMap APIs.
HygroThermFEM is a Finite Element Method-based numerical calculation engine for solving 2-D heat and moisture transfer problems. This numerical engine is used in the THERM software tool, and its primary purpose is for the analysis of building envelopes (e.g., windows, walls, roofs, foundations, etc.). However, the engine can also be used for any heat and moisture transfer problems that require solving fundamental 2-D energy and mass transfer equations. Fluid flow solutions (Navier-Stokes momentum equations) are not included, but the correlations for various convection heat transfer situations are provided, including the translation of complex cavity geometries into those for which correlations are applicable. The calculation engine is written in C++ and includes an API for connecting to third-party tools.
Processing event or streaming data presents several technological challenges. A variety of technologies are often used by scientific user facilities. ZMQ is used to stream data and messages in a peer-to-peer fashion. Message brokers like Kafka, Redis Pubsub, EPICS PVA and RabbitMQ are often employed to route and pass messages from instruments to processing workflows. Arroyopy provides an API and structure to flexibly integrate with these tools and incorporate arbitrarily complex processing workflows, letting the hooks to the workflow code be independent of the connection code and hence reusable at a variety of instruments.
SAND2025-14389O CEC Quest is a Python tool with a user interface designed to analyze the greenhouse gas impacts of long-duration energy storage projects in California. The tool automates data collection from public sources and uses an Application Programming Interface (API) to enable users to download photovoltaic resource availability, marginal operating emissions rate, and utility rate data. It guides users in inputting parameters for a battery energy storage model and uploading site electrical load data, while also prompting for relevant analysis parameters like timestep and grid limits. CEC Quest performs monthly optimization of one year of data to assess impacts on the site’s electrical bill and the grid’s greenhouse gas emissions. Finally, it conducts a lifecycle analysis to evaluate changes over a defined quantification period, with results aggregated through automated report generation. 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.
A library and APIs for fast access to binary reference data compiled for X-ray and neutron interaction with materials.
The code is written in Python and consists of the following pipeline that is implemented in Apache Airflow. This pipeline intends to understand the companies that are directly or indirectly involved with a type of critical infrastructure system at some point in that system's lifecycle. The pipeline takes a configuration file that specifies a list of initial companies to consider, a geographic region of interest, and a set of SEC form types as well as other data sources (e.g. CrunchBase) from which to extract entities and relations. There are four main components to this pipeline as currently implemented: Entity Extraction, Network Construction, Analysis, and Visualization. First, Entity Extraction, is implemented as the `topear-extract_organizations` Apache Airflow workflow. Given an initial query that specifies a geographic region of interest and a time interval, the software will extract CI facilities of interest and organizations that have a direct influence relationship to those facilities (e.g. ownership). During the course of the LDRD, we focused on Electric Vehicle charging stations and this information is available via the Department of Energy (DOE) database on fueling stations maintained by NREL. Within the context of the DOE CESER project, we have focused on Battery Energy Storage Systems (BESS). Second, the Network Extraction component will iteratively construct a social network graph given the set of organizations and people extracted in the previous step. Organizations (and eventually People if desired) are then fed as a query to the `topgear-construct_social_network` Apache Airflow workflow which given a set of initial companies and data sets (e.g. SEC EDGAR form types, OpenCorporates, Crunchbase). This Airflow workflow will iteratively query such data sources to discover relationships with new organizations and people. For example, this module can iteratively query SEC EDGAR for metadata that documents the number of each type of form for the given set of companies and their location. This forms metadata represents a catalog of data sources from SEC EDGAR for the extracted social network knowledge graph. The pipeline then downloads these forms from the website and saves them in a build directory for further processing. These documents are then parsed for entities and relations. Again, we note that in additional to SEC data sources, this step can also pull in information on organizations via API services such as CrunchBase and OpenCorporates or bulk data sources. At the end of this step, the resultant social network, the Critical Infrastructure network, and the edges that encode relationships between organizations and CI facilities, form the Adversarial Socio-Technical Network (ASTN) that informs the analysis. Third, the Analysis component processes these generated ASTN. Previously, that has included the ability to compare prevalence of different vendors for a given infrastructure component type across different regions as well as identify common public and private investors across those vendors. This was demonstrated for EV Charging Stations across several different metropolitan areas within an IEEE PES GridEdge publication. More recently, we have looked at ways to identify infrastructure owners and operators of BESS with the most nameplate capacity across different states as well as other indictors of risk resulting from changes in ownership over time. Finally, the Visualization component consists of an HTML/CSS/JS framework by which users can interact geospatial, operational, and organizational relationships across a given portfolio of Critical Infrastructure facilities. The objective is to provide a library of UI/UX modules that can be repurposed for stakeholder-specific dashboards. All of the modules are related via a common event model that enables UI actions in one view to percolate across the other views.
Monitoring and analyzing the frequency response performance of power generation units is essential for maintaining reliable and secure power system operation. To address this need, an automation tool has been developed to provide a pipeline for processing historical power plant generation data, including large-scale SCADA archives. The tool performs end-to-end processing, including event detection, frequency response (FR) analysis in accordance with NERC standards, and estimation of speed governor droop characteristics. The tool is designed with a modular architecture, allowing individual components of the workflow to be extended, customized, or deployed independently. In addition, the tool provides an API that enables seamless integration with other production systems and operational analytics platforms.
Public protobuf definitions for the OLCF's S3M APIs
BuildingSync® is a building data exchange schema to better enable integration between software tools and building data workflows. The schema's original use case was focused on commercial building energy audits; however, several additional use cases have been realized including building energy modeling and more high-level generic building data exchange. Version 2.7.0 adds new elements for file attachment feature and FederalBuilding, and generalizes usage of Optional Elements (e.g. EquipmentCondition, EquipmentID) to all assets/systems. BuildingSync helps streamline the data exchange process, improving the value of the data, minimizing duplication of effort for subsequent building data collection efforts (including audits), and facilitating the achievement of greater energy efficiency. This in done in part by standardizing on (a) reporting audits in an electronic format, (b) tracking proposed, implemented, and discarded energy conservation measures, and (c) storing building characteristics (at multiple levels) for audits, benchmarking, and building energy analysis. BuildingSync has several documents and tools available to help users understand how to best leverage BuildingSync. The list below are only a subset of the resources available. If new resources are discovered, then feel free to create a new pull request with the additions. Generic BuildingSync information is available on the DOE website and the project website. BuildingSync Examples - These examples are kept up to date and show a wide range of implementations. Any new update to BuildingSync is required to pass validation on these example files. BuildingSync Use Case Validator allows for users to determine if their instance complies with a specific use case for BuildingSync by checking if the required elements are implemented in an uploaded instance. An API is also provided for automated integration into other tools. Also, the website contains an easy way to view the entirety of the schema and how elements relate to the Building Exchange Data Exchange Specification. The Validator is open sourced here Use Case TestSuite provides a Python package for easier generation of BuildingSync use cases. BuildingSync use cases depend on the generation of schematron documents, which is time-consuming and difficult to implement well. The TestSuite allows users to define a use case using a more palatable CSV template, which it then turns into a Schematron document. The source code is available here. BuildingSync to OpenStudio/EnergyPlus. The translator is open sourced here. This project will translate a Level 1 (and partial Level 2) ASHRAE Energy Audit to a fully defined OpenStudio and EnergyPlus model. This project is in early Beta testing and any feedback is welcome!
Arco (Assembled Resource-Constrained Optimization) is a memory-smart optimization DSL and solver for LP and MIP problems on constrained hardware. The software is an optimization framework built around a KDL-based domain-specific language and a CLI compiler/solver. You write optimization models in .kdl files, and the arco CLI compiles, validates, inspects, and solves them. Language bindings (Python today, more planned) provide programmatic access to the same engine. Built for harder optimization problems on constrained resources, Arco is intentional about every allocation, careful with stack and heap behavior, and relentless about minimizing memory usage so more systems can run real workloads. Arco is built primarily for internal use within our organization. You are welcome to try it, but we make no guarantees about API stability or robustness at this stage
The Nuclear Data Interface (NDI) is an application programming interface (API) that allows access to standard nuclear data parameters while hiding the underlying details of the data libraries and their storage. It allows access to multigroup transport data (neutron and gamma), thermonuclear burn data, dosimetry data, production/depletion chain data, radiochemistry data, and secondary neutron multiplicity data. The name NDI refers to both the code and data formats supported by the code.
Grid Analysis Toolkit (GAT) is a unified Python API and plotting for power system PCM and CEM results (Sienna, PLEXOS, ReEDS™). It's a toolkit for wrangling data for Bulk Grid Dispatch and Transmission Analysis. GAT aims to provide simplified access to PCM and CEM results in a standard format while also allowing raw data access to underlying datasets specific to the model. This software can also be found on PyPI at For plotting, GAT defaults to standard National Lab of the Rockies (NLR) color schemes and standard styles while allowing customization.
SF-26-118 pySimpleMask is a tool for creating masks and Q-partition maps for X-ray scattering patterns, supporting SAXS, WAXS, and XPCS data reduction. It ships both a desktop GUI and a headless Python API that can drive the full pipeline from scripts.
Hybrid Environment Resources and Operations (HERO) is a system of common web services for mission driven research projects; the HERO Python software development kit (SDK) is a tool to programmatically interact with the HERO APIs.
As HPC system architectures and the applications running on them continue to evolve, the MPI standard itself must evolve. The trend in current and future HPC systems toward powerful nodes with multiple CPU cores and multiple GPU accelerators makes efficient support for hybrid programming critical for applications to achieve high performance. However, the support for hybrid programming in the MPI standard has not kept up with recent trends. The MPICH implementation of MPI provides a platform for implementing and experimenting with new proposals and extensions to fill this gap and to gain valuable experience and feedback before the MPI Forum can consider them for standardization. Here, in this work, we detail six extensions implemented in MPICH to increase MPI interoperability with other runtimes, with a specific focus on heterogeneous architectures. First, the extension to MPI generalized requests lets applications integrate asynchronous tasks into MPI’s progress engine. Second, the iovec extension to datatypes lets applications use MPI datatypes as a general-purpose data layout API beyond just MPI communications. Third, a new MPI object, MPIX_Stream, can be used by applications to identify execution contexts beyond MPI processes, including threads and GPU streams. MPIX stream communicators can be created to make existing MPI functions thread-aware and GPU-aware, thus providing applications with explicit ways to achieve higher performance. Fourth, MPIX Streams are extended to support the enqueue semantics for offloading MPI communications onto a GPU stream context. Fifth, thread communicators allow MPI communicators to be constructed with individual threads, thus providing a new level of interoperability between MPI and on-node runtimes such as OpenMP. Lastly, we present an extension to invoke MPI progress, which lets users spawn progress threads with fine-grained control to adapt the communication performance to their application designs. We describe the design and implementation of these extensions, provide usage examples, and highlight their expected benefits with performance results.
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 is shared by API; a small sample of the vehicle and logger data has been extracted and is also available for download.
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 is shared by API; a small sample of the vehicle battery and test data has been extracted and is also available for download.