olcf/s3m-apis
Public protobuf definitions for the OLCF's S3M APIs
Ruckman, Arthur [Oak Ridge National Laboratory (OR↗
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.
BuildingSync® v.2.7.0 (released 9.11.2025) [SWR-18-28]
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!
Long, Nicholas [National Renewable Energy Lab. (NR↗
arco (Assembled Resource-Constrained Optimization) [SWR-26-030]
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
Sanchez Perez, Pedro Andres [National Laboratory o↗
ndi
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.
Saller, Thomas↗
GAT (Grid Analysis Toolkit) [SWR-25-41]
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.
Webb, Micah [National Laboratory of the Rockies (N↗
pySimpleMask
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.
Chu, Miaoqi [Argonne National Laboratory (ANL), Ar↗
HERO – Python SDK (Hybrid Environment Resources and Operations – Python SDK) [SWR-26-024]
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.
Wunder, Nicholas [National Laboratory of the Rocki↗
Energy Exascale Earth System Model v2.0.2
Second patch release of v2.0.0 Changes since v2.0.1 [Important change] Add and update SSP370 and SSP585 cases, add tests, fix use-case files, Change ocean and sea-ice IC for ARRM60to10. [EAM] allow thetaxx as a CAM_TARGET, enable northamericax4v1pg2_WC14to60E2r3 for AMIP, fix ndrop initialization, allow up to 15 history files. [EAMxx] allow use of readnl [EAM-MMF] allow transient SST case for C++ MMF, remove specific task/thread count for ESMT test, modify the variance transport diagnostic, reorg tests, [HOMME] Allow optional sponge layer. [ELM] add 2 land-atm compsets, update FATES to API 17.0.0, allow FATES sp mode, allow ELM harvest to drive FATES harvest, fix memleaks, reduce test build times, modified parameters for miscanthus and switchgrass based on calibration [MPAS-Ocean] turn on ocean BGC in BGC cases, fix interface locations for 60L PHC grid, add mode spec to conservation check streams, allow oRRS18to6v3 grid to run with JRA, update ocean and sea ice ICs for ARRM60to10 (needed for v2), GPU port of thickness tendency, add CMPASO-JRA1p4, [MPAS framework] Add new reproducible global sum module for MPAS components, Add mostRecentAccessTime attribute to streams [MPAS-landice] Update MALI version and Greenland mesh [MPAS-seaice] add single-cell test case, fix BGC restart, Adds omp critical directives for ice warnings seen on cori. [CIME] Fix component namelist creation bugs when NINST>1, add OpenACC, OpenMP and CXX GPU tests, fix nonBFB tests, stop using config_compilers, reduce ELM test build times with shared executable, update OpenMPI on Chrysalis. fix baseline handling, provenance handling with update to cime6.0.33, also use component-specific config_pes files and add the ones from master [Machine updates] cori modules after maint, Chrysalis to OpenMPI-4.1.3 [run_e3sm] replace default case name and group. [Externals] update SCORPIO to 1.3.2
ECP↗
A Novel and Practical Method to Quantify the Quality of Mobility: The Mobility Energy Productivity Metric: Preprint
Recent technology innovations are enabling fundamental improvements in mobility systems, including options for new travel modes, methods, and opportunities to connect people with goods, services, and employment. A desire to quantify and compare both existing and emerging transportation options motivated development of the mobility energy productivity (MEP) metric described herein. The MEP metric fundamentally measures the potential of a city's transportation system to connect a person to a variety of services and activities that define a high-quality of life, relative to the convenience, cost and energy needed to provide these connections. Fundamentally derived from accessibility theory, the MEP advances practice by using readily available travel time data (either from web-based application programming interfaces (APIs) or outputs from an urban transportation model) combined with established parameters that reflect the energy intensity and cost of various travel modes, and relative frequency of activity engagement. The construction of the MEP metric allows for aggregation and disaggregation to the appropriate spatial, modal, and trip purpose resolution, as analysis needs dictate. The MEP could be used to compare alternative futures related to technology, infrastructure investment, or policy, providing a much-needed tool for planners, researchers, and analysts.
33 ADVANCED PROPULSION SYSTEMS↗
Designing and prototyping extensions to the Message Passing Interface in MPICH
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.
97 MATHEMATICS AND COMPUTING↗
Varroa destructor mites vector and transmit pathogenic honey bee viruses acquired from an artificial diet
The ectoparasitic mite Varroa destructor is one of the most destructive pests of the honey bee (Apis mellifera) and the primary biotic cause of colony collapse in many regions of the world. These mites inflict physical injury on their honey bee hosts from feeding on host hemolymph and fat body cells/cellular components, and serve as the vector for deadly honey bee viruses, including Deformed wing virus (DWV) and the related Varroa destructor virus-1 (VDV-1) (i.e., DWV-like viruses). Studies focused on elucidating the dynamics of Varroa-mediated vectoring and transmission of DWV-like viruses may be confounded by viruses present in ingested host tissues or the mites themselves. Here we describe a system that includes an artificial diet free of insect tissue-derived components for maintaining Varroa mites for in vitro experimentation. Using this system, together with the novel engineered cDNA clone-derived genetically tagged VDV-1 and wild-type DWV, we demonstrated for the first time that Varroa mites provided an artificial diet supplemented with engineered viruses for 36 hours could acquire and transmit sufficient numbers of virus particles to establish an infection in virus-naïve hosts. While the in vitro system described herein provides for only up to five days of mite survival, precluding study of the long-term impacts of viruses on mite health, the system allows for extensive insights into the dynamics of Varroa-mediated vectoring and transmission of honey bee viruses.
59 BASIC BIOLOGICAL SCIENCES↗
Phenopacket-tools: Building and validating GA4GH Phenopackets
The Global Alliance for Genomics and Health (GA4GH) is a standards-setting organization that is developing a suite of coordinated standards for genomics. The GA4GH Phenopacket Schema is a standard for sharing disease and phenotype information that characterizes an individual person or biosample. The Phenopacket Schema is flexible and can represent clinical data for any kind of human disease including rare disease, complex disease, and cancer. It also allows consortia or databases to apply additional constraints to ensure uniform data collection for specific goals. We present phenopacket-tools, an open-source Java library and command-line application for construction, conversion, and validation of phenopackets. Phenopacket-tools simplifies construction of phenopackets by providing concise builders, programmatic shortcuts, and predefined building blocks (ontology classes) for concepts such as anatomical organs, age of onset, biospecimen type, and clinical modifiers. Phenopacket-tools can be used to validate the syntax and semantics of phenopackets as well as to assess adherence to additional user-defined requirements. The documentation includes examples showing how to use the Java library and the command-line tool to create and validate phenopackets. We demonstrate how to create, convert, and validate phenopackets using the library or the command-line application. Source code, API documentation, comprehensive user guide and a tutorial can be found at https://github.com/phenopackets/phenopacket-tools. The library can be installed from the public Maven Central artifact repository and the application is available as a standalone archive. The phenopacket-tools library helps developers implement and standardize the collection and exchange of phenotypic and other clinical data for use in phenotype-driven genomic diagnostics, translational research, and precision medicine applications.
59 BASIC BIOLOGICAL SCIENCES↗
Towards scalable dataframe systems
Dataframes are a popular abstraction to represent, prepare, and analyze data. Despite the remarkable success of dataframe libraries in R and Python, dataframes face performance issues even on moderately large datasets. Moreover, there is significant ambiguity regarding dataframe semantics. In this paper we lay out a vision and roadmap for scalable dataframe systems. To demonstrate the potential in this area, we report on our experience building Modin, a scaled-up implementation of the most widely-used and complex dataframe API today, Python's pandas. With pandas as a reference, we propose a simple data model and algebra for dataframes to ground discussion in the field. Given this foundation, we lay out an agenda of open research opportunities where the distinct features of dataframes will require extending the state of the art in many dimensions of data management. We discuss the implications of signature dataframe features including flexible schemas, ordering, row/column equivalence, and data/metadata fluidity, as well as the piecemeal, trial-and-error-based approach to interacting with dataframes.
97 MATHEMATICS AND COMPUTING↗
Keep CALM and CRDT On
Despite decades of research and practical experience, developers have few tools for programming reliable distributed applications without resorting to expensive coordination techniques. Conflict-free replicated datatypes (CRDTs) are a promising line of work that enable coordination-free replication and offer certain eventual consistency guarantees in a relatively simple object-oriented API. Yet CRDT guarantees extend only to data updates; observations of CRDT state are unconstrained and unsafe. We propose an agenda that embraces the simplicity of CRDTs, but provides richer, more uniform guarantees. We extend CRDTs with a query model that reasons about which queries are safe without coordination by applying monotonicity results from the CALM Theorem, and lay out a larger agenda for developing CRDT data stores that let developers safely and efficiently interact with replicated application state.
Computer Science↗
EGS Collab Experiment 1: 3D Seismic Velocity Model and Updated Microseismic Catalog Using Transfer-Learning Aided Double-Difference Tomography
This package contains a 3D Seismic velocity model and an updated microseismic catalog associated with a proceedings paper (Chai et al., 2020) published in the 45th Workshop on Geothermal Reservoir Engineering. The 3D_seismic_velocity_model text file contains x (m), y(m), z(m), P-wave velocity (km/s), P-wave velocity quality indicator (1 for well-constrained; 0 for poorly constrained), S-wave velocity (km/s), and S-wave velocity quality indicator (1 for well-constrained; 0 for poorly constrained). The Updated_MEQ_catalog text file contains event origin time, x(m), y(m), z(m), error in x (m), error in y (m), error in z (m), and RMS misfit (millisecond). The 3D_seismic_P-wave_velocity_model animation file shows slices of the 3D P-wave velocity model. The 3D_seismic_S-wave_velocity_model animation file shows slices of the 3D S-wave velocity model. The Interactive_MEQ_locations API file is an interactive visualization of the updated microseismic event locations. The visualization allows users to view the event locations by dragging, rotating, and zooming in. References: Chai, C., Maceira, M., Santos-Villalobos, H. J., Venkatakrishnan, S. V., Schoenball, M., and EGS Collab Team, 2020, Automatic Seismic Phase Picking Using Deep Learning for the EGS Collab Project, in PROCEEDINGS, 45th Workshop on Geothermal Reservoir Engineering, edited, Stanford University, Stanford, California, 45, 1266-1276.
15 GEOTHERMAL ENERGY↗
EGS Collab Experiment 1: 3D Seismic Velocity Model and Updated Microseismic Catalog from Double-Difference Seismic Tomography
This package contains a 3D Seismic velocity model and an updated microseismic catalog obtained for a double-difference seismic tomography study. The 3D_seismic_velocity_model text file contains x (m), y(m), z(m), P-wave velocity (km/s), P-wave velocity quality indicator (1 for well-constrained; 0 for poorly constrained), S-wave velocity (km/s), and S-wave velocity quality indicator (1 for well-constrained; 0 for poorly constrained). The Updated_MEQ_catalog text file contains event origin time, x(m), y(m), z(m), error in x (m), error in y (m), error in z (m), and RMS misfit (millisecond). The 3D_seismic_P-wave_velocity_model animation file shows slices of the 3D P-wave velocity model. The 3D_seismic_S-wave_velocity_model animation file shows slices of the 3D S-wave velocity model. The Interactive_MEQ_location_comparison API file is an interactive visualization of the updated microseismic event locations and the original seismic catalog. The visualization allows users to view and compare the event locations by dragging, rotating, and zooming in. An updated version of 3D_seismic_velocity_model and associated animations were included, which were calculated with a more strict assumption for quality indicators.
15 GEOTHERMAL ENERGY↗
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 is shared by API; a small sample of the vehicle and logger data has been extracted and is also available for download.
32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
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 is shared by API; a small sample of the vehicle battery and test data has been extracted and is also available for download.
32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗