Engineering PapersSearch

SEARCH · Engineering Papers

Results for “application programming interface 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.

30 records · Page 2

Nion Swift FY2021 phase I Final Technical Report DE-SC0021546

Phase I of the project is an on-going success. The enhanced and extended new application programming interface (API) developed in Phase I is in use at customer sites around the world: Berlin, UK, US, China, France, Austria. The modules developed to demonstrate the new API features are in daily use at these sites for acquiring, processing, and analyzing microscopy data from 4D- and 5D-STEM to single-point spectroscopy at highest resolution.

Lovejoy, Tracy

NEAMS Technical Area Support in MOOSE

The MOOSE framework is a foundational capability used by the NEAMS program to create over 15 different simulation tools for advanced nuclear reactors. Due to this ubiquity, improvements to the framework in support of modeling and simulation goals are critical to the program. These improvements can take many forms including optimization, improved user experience, streamlined application programming interfaces (APIs), parallelism, and other new capabilities. The work transcribed in this report was conducted in direct support of the simulation tools and has already been deployed. The capabilities outlined in this report include enabling selective polynomial basis refinement, implementing a custom convergence system, building a scalable preconditioner for saddle-point problems, and much more.

97 MATHEMATICS AND COMPUTING

OpenFacadeControl: enabling integration of automated facades with other building systems

Automated facades are, for the most part, still considered as separate from other building systems throughout the design, installation, commissioning, operation, and maintenance cycle. This takes place despite the fact that their energy and comfort performance are deeply interlinked with the operation of lighting and HVAC systems. Over the last two decades, research has shown that there are significant advantages from operating facades as an integrated system with the rest of the building. Nevertheless, significant barriers prevent this type of integration becoming more common. One of them is the lack of a platform that is inexpensive to implement and that easily allows the practical implementation of integrated control algorithms across fenestration and other building systems, using a variety of communications protocols. This is particularly challenging when automated facades are installed in existing buildings, where interaction with legacy building systems that were installed over the past lifetime of the building can require a high degree of interoperability. OpenFacadeControl (OFC) is an open-source controls framework aimed at unified control of facades and other building systems, including the sharing of third-party sensor information. Through leveraging the Volttron controls platform, it allows the integration of systems and sensors that are manufactured by different companies and that use different communications protocols into an ensemble that functions as a single system. OFC is designed to enable integrated control algorithms of varying degrees of complexity, ranging from simple, heuristic controls to more sophisticated approaches like model-predictive control. Use of a research version to test advanced lighting and shading strategies in a full-scale experimental testbed has demonstrated the ease of deploying advanced control solutions using OpenFacadeControl. This paper presents the structure of OpenFacadeControl and a demonstration case showing the use of OFC in laboratory tests of advanced lighting and fenestration controls that coordinated motorized shades communicating via the BACnet building communications standard and lights communicating via internet-protocol-based application programming interface (API), based on the readings of a shared light level sensor communicating via a different API.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI

Enterprise Artificial Intelligence Strategy for Los Alamos National Laboratory

In the 1984 martial arts drama film, The Karate Kid, a young Daniel LaRusso is unexpectedly placed in an adversarial environment unable to eYectively adapt to a series of new threats and limitations. Fortunately for the main character, once placed under the tutelage of a Mr. Miyagi, he finds resiliency not through the adoption of new tools, but a re-focused set of fundamentals. Much in the same way that Daniel learns waxing on and buYing oY car wax by hand has rewards for Karate, LANL is choosing the harder path of self-hosting Large Language Models (LLMs) for enterprise use instead of only relying on buying access to a hosted AI service like Azure’s OpenAI Application Programming Interface (API). We also are not willing to wait for software-as-a-service (SAAS) AI services to meet us where we need to be from a FedRAMP accreditation standpoint. Our operations regularly depend on access at CUI, UCNI, ITAR and other FIPS-199 moderate-impact data levels and hosting our own services gives us the right security and compliance posture to be useful across the broad range of our work at LANL. With the rise in threats to critical infrastructure, cloud service providers (CSPs), and supply chain attacks from both state and non-state actors, we are not placing the bet that SAAS hosted AI services will be available when we need them. Should a major event occur, we do not want our staY and operations left without a pathway for us to fix the problem and resume the use of AI tools.

42 ENGINEERING

An Overview of the Molten Salt Thermal Properties Database–Thermophysical, Version 4.0 (MSTDB-TP V.4.0)

A central repository of thermophysical and thermochemical properties of molten salt compositions of relevance to molten salt reactors (MSRs) is vital in supporting the broad community of MSR developers, who are at various stages of developing and deploying their reactor designs. In general, these MSR designs differ significantly from developer to developer (e.g., with respect to the hardness of the neutron spectra, level of fissile loading, target multicomponent temperatures and power levels, and moderating capabilities). Therefore, the fuel and coolant salts being considered vary greatly: they may be chlorides or fluorides, they utilize different actinides at different ratios, and the cations in the melt are selected based on perceived advantages and disadvantages. Considering the general need for thermal properties, and the vastness of the array of potential candidate salt mixtures, the Molten Salt Thermal Properties Database (MSTDB) was initiated in 2018 with the goal of providing thermophysical and thermochemical characterization of key molten salt compounds and mixtures across their temperature and compositional domains. The MSTDB is thus divided into the thermophysical arm (MSTDB-TP) and the thermochemical arm (MSTDB-TC). The MSTDB is an effort funded by the Department of Energy, Office of Nuclear Energy (DOE-NE) Nuclear Energy Advanced Modeling and Simulation (NEAMS) program, and the MSR Campaign. This report provides an overview of the MSTDB-TP v4.0 in terms of the data contained within, the state of the tools used to access the data, the availability of predictive models that leverage the raw data in the database, the preliminary status of developmental efforts that are currently underway, and an account of future goals for MSTDB-TP. The primary goal for the update from MSTDB-TP v.3.1 to v4.0 was the incorporation of surface tension data into the database; this property is important for thermal hydraulics modeling and species transport in other tools that have been developed under the NEAMS program. A breakdown of the surface tension data that have been added into MSTDB-TP v4.0 is provided herein, and the manner in which the quality of the data has been assessed is also documented. For MSTDB-TP v4.0, newly published thermophysical property data—primarily from collaborative experimental efforts under the MSR Campaign—have been incorporated into the database, and the resulting expansion is documented here. Because of the size to which MSTDB-TP has grown, the raw data format has now been recast into JavaScript Object Notation (JSON) format for easier connection with the MSTDB-TP application programming interface (API). Saline; the pre-existing comma-separated value (CSV) format has been deprecated but is still maintained, accessible, and up to date. As a final effort in packaging the MSTDB-TP v4.0 update, the graphical user interface (GUI) for MSTDB has been updated to allow full accessibility to the density and viscosity predictive models, which are based on Redlich-Kister expansions of MSTDB-TP raw data. Some other major aspects of this report, in terms of preliminary and future work, include: (1) documentation of the formalism and preliminary testing of a kinetic theory model that may act as a predictive model for thermal conductivity; (2) documentation of the candidate predictive models that may be considered in the future for surface tension, making use of the surface tension data now in MSTDB-TP v4.0; (3) a preliminary account of a data collection process that will enable the filling of additional gaps within MSTDB-TP, namely with data which have been collected computationally (e.g., through ab initio molecular dynamics).

22 GENERAL STUDIES OF NUCLEAR REACTORS

NEAMS Technical Area Support in MOOSE

The Multiphysics Object-Oriented Simulation Environment (MOOSE) framework is a foundational capability used by the Nuclear Energy Advanced Modeling and Simulation (NEAMS) program to create over 15 different simulation tools for advanced nuclear reactors. Due to this ubiquity, improvements to the framework in support of modeling and simulation goals are critical to the program. These improvements can take many forms, including optimization, improved user experience, streamlined application programming interfaces (APIs), parallelism, and other new capabilities. The work described in this report was conducted in direct support of the simulation tools and has already been deployed. The capabilities outlined in this report include implementing hash table matrix assembly for efficient sparsity pattern construction for contact in BISON, developing re-step testing infrastructure for ensuring the viability of overlapping domain coupling between SAM and Pronghorn, allowing unique preconditioners for single-input multi-system solves, supporting multi-system in MOOSE’s workhorse executioners, and many more smaller feature enhancements and bug fixes.

97 - MATHEMATICS AND COMPUTING

Analysis of Bis(trifluoromethylsulfonyl)imide Interactions with Metal Cations Through a Chemical Informatics Approach

Nominally weakly coordinating anions are useful for modulating the solubility and chemical properties of metal complexes, but identification and analysis of the systematics of the interactions of anions with cationic metal complexes has not received the attention it deserves. Here, a chemical informatics approach is demonstrated for identifying and quantitatively analyzing the ways that the bis(trifluoromethylsulfonyl)imide anion (TFSI) can interact with metal-containing species. An open access computer program (PyCIFTer) was developed to facilitate large-scale structural analysis of TFSI-containing species by utilization of experimental atomic coordinate data from single-crystal X-ray diffraction (XRD) studies obtained from the Cambridge Structural Database (CSD). PyCIFTer establishes a three-dimensional vector space from the raw atomic coordinates, generating acyclic, undirected graphs that are used to rapidly analyze the structural properties (bond lengths and angles) of TFSI in individual structures in sequential/batch fashion. The structures are sorted by PyCIFTer into groups based on pre-set and chemically sensible criteria, affording a comprehensive and systematic view of TFSI structural chemistry. This approach avoids tedious one-at-a-time interrogation of structures, a prospect unreasonable in this case, and many others of contemporary chemical relevance; there were over 1500 structures in the CSD containing TFSI as of November 2024. The results demonstrate that TFSI only rarely binds to cations in the solid state, favoring the formation of species in which TFSI is found in cations’ outer coordination spheres. The prospect of applying PyCIFTer to other moieties is also discussed. PyCIFTer is also schematically compared to the commercial CSD Python application programming interface (API). Taken together, this work demonstrates the usefulness of modular workflows for sequential/batch analysis of structural data from XRD, an approach that appears poised to accelerate the translation of legacy structural results into new chemical insights and hypotheses.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH

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

MontePy: a Python library for reading, editing, and writing MCNP input files.

The Monte Carlo N-Particle (MCNP) radiation transport code is a highly capable and accurate code with a long legacy. MCNP uses the Monte Carlo simulation process to simulate the path of particles (e.g., neutrons, photons, charged particles, etc.), and their interaction with materials. It is widely used in nuclear engineering, high-energy physics, and other fields. Its origins in the mid-twentieth century predate many modern software conventions. MCNP users provide an input file to MCNP, which it then uses to create an internal representation of the simulation problem. These input files originally had to be stored as punchcard decks, and the user manual still uses the terminology of cards and decks, despite moving beyond punchcards. MCNP predates nearly all modern human readable markup or data serialization languages, such as the extensible Markup Language (XML), the Standard Generalized Markup Language (SGML), YAML (YAML Ain’t Markup Language), and Javascript Object Notation (JSON). Due to this, MCNP uses an entirely custom defined syntax language for its input, making off-the-shelf libraries for XML, YAML, and JSON impossible to use for scripting various operations on MCNP input files (Kulesza et al., 2022).

97 - MATHEMATICS AND COMPUTING

cclib 2.0: An updated architecture for interoperable computational chemistry

Interoperability in computational chemistry is elusive, impeded by the independent development of software packages and idiosyncratic nature of their output files. The cclib library was introduced in 2006 as an attempt to improve this situation by providing a consistent interface to the results of various quantum chemistry programs. The shared API across programs enabled by cclib has allowed users to focus on results as opposed to output and to combine data from multiple programs or develop generic downstream tools. Initial development, however, did not anticipate the rapid progress of computational capabilities, novel methods, and new programs; nor did it foresee the growing need for customizability. Here, we recount this history and present cclib 2, focused on extensibility and modularity. We also introduce recent design pivots—the formalization of cclib’s intermediate data representation as a tree-based structure, a new combinator-based parser organization, and parsed chemical properties as extensible objects.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH

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

Bridging paradigms: Designing for HPC-Quantum convergence

Here, this paper presents a comprehensive software stack architecture for integrating quantum computing (QC) capabilities with High-Performance Computing (HPC) environments. While quantum computers show promise as specialized accelerators for scientific computing, their effective integration with classical HPC systems presents significant technical challenges. We propose a hardware-agnostic software framework that supports both current noisy intermediate-scale quantum devices and future fault-tolerant quantum computers, while maintaining compatibility with existing HPC workflows. The architecture includes a quantum gateway interface, standardized APIs for resource management, and robust scheduling mechanisms to handle both simultaneous and interleaved quantum–classical workloads. Key innovations include: (1) a unified resource management system that efficiently coordinates quantum and classical resources, (2) a flexible quantum programming interface that abstracts hardware-specific details, (3) A Quantum Platform Manager API that simplifies the integration of various quantum hardware systems, and (4) a comprehensive tool chain for quantum circuit optimization and execution. We demonstrate our architecture through implementation of quantum–classical algorithms, including the variational quantum linear solver, showcasing the framework’s ability to handle complex hybrid workflows while maximizing resource utilization. This work provides a foundational blueprint for integrating QC capabilities into existing HPC infrastructures, addressing critical challenges in resource management, job scheduling, and efficient data movement between classical and quantum resources.

97 MATHEMATICS AND COMPUTING