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 235 records · Page 13

An Approach to DevOps and Microservices

This report presents work performed in 2017 and is a reissue of the end-of-year report SAND2018-0240, A Proof-of-Concept Approach to DevOps and Microservices, January 2018, modified for unlimited release. This report describes the approach, investigation, and prototyping efforts to create an API management solution and automated deployment pipeline for REST-based microservices. Additionally, it reviews: the microservices created for testing purposes; our experiences and results in using an open-source API management tool; and future plans.

97 MATHEMATICS AND COMPUTING↗

Integrating System to Edge-of-Network Architecture and Management for SHINES (SEAMS) Technologies of High Penetration Grids

Consistent with the U.S. DOE’s EERE SHINES FOA objectives, the goal of this project was to enable integration from EMS to variable DER in a way that delivered visibility and opportunities for managing and controlling distributed resources using SEAMS technologies. This project implemented several SHINES technologies, which included: (1) three Stem battery systems; (2) six ConnectDER PV collars; (3) two E-Gear PV/Battery storage interfaces; and (4) eight Kitu smart inverter emulators. A Siemens Energy IP DEMS was deployed in a development environment and integrated with the SHINES technologies via OpenADR and IEEE 2030.5 protocols with documented architecture. In the case of IEEE 2030.5, a suite of technologies including a gateway, an API, software and a server from Kitu Systems (the Citadel, Convoy, Kitu Crosslink API, and Kitu Spark) were used to demonstrate that the utility could achieve visibility of distributed energy resources (DER) and control of single and multiple DER systems with a single command. The project also included a LCOE analysis of SHINES technologies compared to traditional system and circuit mitigation measures.

14 SOLAR ENERGY↗

Accessing Microsoft Access Databases Using ODBC and RODBC

ODBC (Open Database Connectivity) is an industry-standard API (Application Program Interface) that provides a standard interface, based on SQL (Structured Query Language) between applications and databases. This insulates applications from specific details of different database management systems (DBMS). Microsoft Windows TM provides an implementation of ODBC, which, along with drivers for various databases, supports the API. Windows also provides a driver for Access databases.

97 MATHEMATICS AND COMPUTING↗

RAVEN User Manual

RAVEN is a generic software framework to perform parametric and probabilistic analysis based on the response of complex system codes. The initial development was aimed to provide dynamic risk analysis capabilities to the Thermo-Hydraulic code RELAP-7, currently under development at the Idaho National Laboratory (INL). Although the initial goal has been fully accomplished, RAVEN is now a multi-purpose probabilistic and uncertainty quantification platform, capable to agnostically communicate with any system code. This agnosticism includes providing Application Programming Interfaces (APIs). These APIs are used to allow RAVEN to interact with any code as long as all the parameters that need to be perturbed are accessible by inputs files or via python interfaces. RAVEN is capable of investigating the system response, and investigating the input space using Monte Carlo, Grid, or Latin Hyper Cube sampling schemes, but its strength is focused to- ward system feature discovery, such as limit surfaces, separating regions of the input space leading to system failure, using dynamic supervised learning techniques. The development of RAVEN has started in 2012, when, within the Nuclear Energy Advanced Modeling and Simulation (NEAMS) program, the need to provide a modern risk evaluation framework became stronger. RAVEN principal assignment is to provide the necessary software and algorithms in order to employ the concept developed by the Risk Informed Safety Margin Characterization (RISMC) program. RISMC is one of the pathways defined within the Light Water Reactor Sustainability (LWRS) program. In the RISMC approach, the goal is not just the individuation of the frequency of an event potentially leading to a system failure, but the closeness (or not) to key safety-related events. Hence, the approach is interested in identifying and increasing the safety margins related to those events. A safety margin is a numerical value quantifying the probability that a safety metric (e.g. for an important process such as peak pressure in a pipe) is exceeded under certain conditions. The initial development of RAVEN has been focused on providing dynamic risk assessment capability to RELAP-7, currently under development at the INL and, likely, future replacement of the RELAP5-3D code. Most the capabilities that have been implemented having RELAP-7 as principal focus are easily deployable for other system codes. For this reason, several side activates are currently ongoing for coupling RAVEN with soft- ware such as RELAP5-3D, etc. The aim of this document is the explanation of the input requirements, focalizing on the input structure.

97 MATHEMATICS AND COMPUTING↗

Enhancements supporting IC usage of PEM libraries on next-gen platforms

This milestone reports on the culmination of several years of effort by multiple PEM support software development teams to provide capabilities for use in LLNL-developed integrated codes on next-gen ASC platforms, including GPU support. We will provide a survey of relevant Application Program Interfaces (API) that are required to support LLNL IC code capability on relevant architectures, with a focus on Sierra and El Capitan. We will identify and summarize all dependencies between PEM supported libraries and IC supported physics codes. We will provide an assessment of algorithmic improvements that have been deployed, as well as future developments that are required to complete the GPU porting efforts. This assessment will include a description of programming models adopted by each of the PEM projects, distinct algorithmic challenges for each of the capabilities, and information about sharing GPU memory between the APIs and host codes. We will develop targeted test problems to assess computational performance. Finally, this milestone will result in identification of gaps in our effort to assist the LLNL ASC program in prioritization of effort for porting software to El Capitan.

97 MATHEMATICS AND COMPUTING↗

Exploring OpenSNAPI Use Cases and Evolving Requirements [Slides]

Emerging system architectures are rapidly transforming in order to meet shifting requirements. Motivated by expanding data volumes, energy efficiency concerns, and the omnipresent need to improve performance, architectures are increasingly adopting a data-centric approach. At the core of this concept is the goal of minimizing data motion and instead processing data in-situ to the greatest degree possible. Therefore, data-centric designs, in contrast to conventional CPU-centric models, typically distribute compute capabilities throughout the architecture. As part of this paradigm shift, a novel class of devices known as data processing units (DPUs), alongside CPUs and GPUs, are quickly forming a third pillar of data-centric systems. These devices, which include smart network adapters and switches, seek to offload computation on data at the network edge as well as in-flight within the network fabric. The Open Smart Network API (OpenSNAPI) project seeks to develop a unified API for DPU devices. In our previous talks, we introduced the OpenSNAPI project and detailed our investigations regarding the viability of offloading compute intensive kernels to BlueField DPUs. In contrast, in this talk we detail our efforts to offload application-level file I/O to the DPU. We also discuss plans and early efforts to explore in-network compute capabilities. Finally, we describe our observations with respect to the evolving design of OpenSNAPI.

97 MATHEMATICS AND COMPUTING↗

VERAView Programmer’s Manual

VERAView’s component-based design facilitates its extension and integration into other applications and systems. In addition to describing VERAView’s architecture and components, this document provides details on the component application programming interfaces (APIs), illustrates how to use the APIs independently of VERAView itself, and explains how to extend VERAView with custom visualizations.

97 MATHEMATICS AND COMPUTING↗

Crosslink V.0.11.x User Manual

CrossLink is a novel two-dimensional and three-dimensional geometry and mesh generation software package developed by the Simulation Tools team at Los Alamos National Laboratory. This software represents the third generation of topology-based mesh generation technology developed by the Department of Defense and the Department of Energy with a special focus on complex multi-material hydrodynamic applications, mesh scalability, and high-order element mesh generation. The topology-based meshing approach offered by CrossLink enables users to quickly and easily mesh complex geometries in a repeatable and robust manner. CrossLink’s topology-based meshing approach is well-suited for parametric design studies, parametric design optimization, damage scenario assessment, and iterative design modification (i.e. feature addition and/or removal). CrossLink’s python API allows workflow scripting of the geometry creation and mesh generation process for traceability, repeatability, data provenance, and version control. CrossLink consists of three main components: a graphical user interface (GUI), a geometry creation and mesh generation engine, and a python API that provides a workflow scripting interface to the geometry and meshing functions.

97 MATHEMATICS AND COMPUTING↗

System Response Characterization for a d–t Neutron Radiography System

We report the system response of a pixelated associated particle imaging (API) neutron radiography system. The detector readout currently consists of a 2x2 array of organic glass scintillator detectors, each with an 8x8 array of optically isolated pixels that match the size and pitch of the ARRAYJ-60035-64P-PCB Silicon Photomultiplier (SiPM) array from SensL/onsemi with 6x6 mm 2 SiPMs. The alpha screen of the API deuterium-tritium neutron generator is read out with the S13361-3050AE-08 from Hamamatsu, which is an 8x8 array of 3x3 mm 2 SiPMs. Data from the 320 channel system is acquired with the TOFPET2-based readout system. We present the predicted imaging capability of an eventual 5x5 detector array, the waveform-based energy and pulse shape characterization of the individual detectors, and the timing and energy response from the TOFPET2 system.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

Tools for Assessing Performance: FY23-Q1 Report [Slides]

LANL was tasked with working with NREL to implement QUIC within the TAP API by the end of Q1, FY2023. If QUICURB cannot be implemented in a way that it can be run outside of the QUIC platform, there will be no further R&D funding for QUIC development. QUIC includes a graphical user interface that imports and preprocesses the various input data streams (3D building databases, ambient wind, vegetation, etc.) and writes them in a format that the QUICURB Fortran executable requires. In order to interface with the TAP API, a Python script was developed that would replace the functionality previously only available within QUICGUI. LANL worked with NREL to test the Python script to ensure that it was operation and fulfilled the requirements.

58 GEOSCIENCES↗

Failure Analysis for Molten Salt Thermal Energy Storage Tanks for In-Service CSP Plants

Thermal Energy Storage (TES) is a fundamental component in concentrating solar power (CSP) plants to increase the plant's dispatchability, capacity factor, while reducing the levelized cost of electricity. In central receivers CSP plants, nitrate molten salts have been used for several years for operation temperatures of up to 565 degrees C. Despite many efforts to advance nitrate salt to higher operation temperatures (even considering a replacement with molten chloride salts) to achieve higher energy conversion efficiencies, the 565 degrees C temperature is currently considered the state-of-the art. Although molten salt tanks have been broadly deployed in commercial CSP plants worldwide, several failures have been reported in these tanks after a few months or years of operation, causing significant economic loss and mistrust in CSP technologies. Most of these failures are associated with the infancy of the technology and multiple issues related to tank design, fabrication, commissioning, and aggressive operation. A technical standard dedicated to the design and fabrication of molten nitrate TES tanks does not exist today. Current in-service molten salt tanks have been generally designed based on the American Petroleum Institute's (API) 650 and ASME Section II standards. The API 650 code provides guidelines for dimensions and fabrication for oil storage tanks up to 260 degrees C. The ASME standard provides allowable stress values for various materials at a range of temperatures and conditions. Both standards seem to be limited for molten salt TES tanks where high temperatures, thermal cycling, and transient conditions are expected. In 2020, NREL released the Concentrating Solar Power Best Practices Study (NREL/TP-5500-75763) that summarized multiple issues in CSP plants, along with potential alternatives and recommendations to address those issues based on information collected from participants representing about 80% of operating CSP plants in the world. One of the recommendations from this study was the development of accurate and validated models to evaluate the plant's transient operation, capable of capturing the effect of short-term clouds and operator response, while being flexible in being adapted to various spatial and temporal resource data. The "Failure Analysis for Molten Salt Thermal Energy Tanks for In-Service CSP Plants" project was inspired on this recommendation and was focused on (1) the development and validation of a physics-based model for a representative, commercial-scale molten salt tank, (2) performing simulations to evaluate the behavior of the tank as a function of typical plant operation conditions, (3) understanding tank failures mechanisms, (4) determining the residual stress and distortion in the tank floor after welding fabrication and evaluating their impact in the stresses developed in the tank during operation, (5) assessing the impact of key operation parameters on the temperature and stress distribution, (6) conduct a preliminary evaluation of design features to reduce stress and improve tank's reliability, and (7) estimate the tank's service life based on the stress developed under diverse operation scenarios. From the analysis conducted in the project and presented in this report, it was found that maximum stresses surpassing the yield strength point of the stainless steel (SS) 347H are developed on the tank floor near the perimeter. These large stresses are strongly influenced by the initial residual stresses and distortion of the tank floor after welding fabrication. During operation, large stresses are developed in the tank floor at high operation temperatures with large salt inventory levels during transient operation. High stresses are also related to elevated temperature gradients in the tank floor that could be attributed to insufficient mixing within the salt inflow and the salt inventory. Based on the analysis, creep is the predominant failure mechanism. However, the large stress levels could favor the plastic deformation into buckles, and crack formation due to stress relaxation cracking during cycle operation. A lifetime below 3 years was estimated for the typical plant operation conditions and a specific initial residual stress and deformation distribution of the tank floor. The estimated life agrees with the service time to failure reported in several commercial molten salt tanks. Desing and operation guidelines can be extracted from the analysis presented in this report, which could be adopted by tank manufacturers and CSP operators to advance toward an ultimate solution for tank failures by reducing residual and operational stresses to achieve a tank service life of more than 30 years. Addressing failures in molten salt TES tanks is fundamental for the CSP industry's survivability, but it is also important for other industrial and power generation applications using this technology, including nuclear and concentrating solar thermal.

14 SOLAR ENERGY↗

Domain Aware Deep-learning Algorithms Integrated with Scientific-computing Technologies (DADAIST)

This technical report summarized the contribution of the DADAIST project funded by the Data Model Convergence Initiative via the Laboratory Directed Research and Development (LDRD) investments at Pacific Northwest National Laboratory (PNNL). Specifically, we report the development of the NeuroMANCER (Neural Modules with Adaptive Nonlinear Constraints and Efficient Regularizations), a new open-source Scientific Machine Learning library for formulating and solving parametric constrained optimization problems, physics-informed system identification, and parametric optimal control problems. NeuroMANCER is using differentiable programming to combine modern data-driven models and optimization modeling language into a coherent algorithmic and software framework. NeuroMANCER is a Pytorch-based framework and adopts much of its philosophy focused on research and development, rapid prototyping, and streamlined deployment. Strong emphasis is given to extensibility, interoperability with the PyTorch ecosystem, and quick adaptability to custom domain problems. Neuromancer repository contains a comprehensive library of differentiable modules, including custom activation functions, matrix factorizations, deep learning architectures, neural differential equations, differential equation solvers, implicit layers such as iterative solvers, high-level API for symbolic expressions, API for modeling and control of dynamical systems, and extensive set of tutorial code examples in the form of python scripts and jupyter notebooks.

97 MATHEMATICS AND COMPUTING↗

Agilent CRADA (Abstract)

The CRADA between Agilent Technologies Inc. and Battelle will focus on five software components as listed below: Prototype 4D Feature Finding functionality with a particular focus on recovering low level features and extending the bottom end dynamic range of IM-MS technology. Compare and contrast developments to current 4D Feature Finding capabilities. Highlight important algorithmic aspects employed. Implement the PNNL saturation correction algorithm. Agilent will give PNNL the needed data file access API and assistance in understanding it implementation and any needed instrumental aspects. Supported high resolution products to include Agilent’s TOF, QTOF and IM-QTOF mass spectrometers. PNNL will then work with Agilent to benchmark performance. Implementation of the PNNL Hadamard de-multiplexing algorithm. Agilent will give provide PNNL the needed date file access API access and as needed assistance in understanding the current Agilent multiplexed IM offering. PNNL will then work with Agilent on benchmark performance. Add ion mobility collision cross sections to existing and new metabolomic libraries for data analysis with Agilent’s informatics program MPP/ID Browser. PNNL will work with Agilent to create a software pipeline that takes data from chemical and metabolic standards and properly formats it for inclusion in MPP accessible libraries, using the collision cross section as a new separation dimension. Improvements of MPP multidimensional matching to identify metabolomic features using multiple characteristics beyond retention time and accurate mass. Most significantly matching will include analyte collision cross section with proposed support for sample fraction or RapidFire cartridge and fragmentation spectra. PNNL will work with Agilent to modify and improve the current MPP analysis pipeline to allow for creating, aligning, and identifying MS features defined by accurate mass, collision cross section and chromatographic retention time. As additional criteria such as fraction or RapidFire cartridge type are supported in the identification process, then they also will become part of the automation workflow. This includes the automation of said system to work with command line program (i.e. not a GUI) sufficient for programmatic execution in a pipeline.

97 MATHEMATICS AND COMPUTING↗

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↗

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↗

Fitness For Service Assessment of a Corroded Heat Exchanger

Within the Fermi National Accelerator complex, there exist various water systems that support accelerator operations. One of these systems is extremely vital to the operation of the machine; that is the cooling system. The cooling system consists of nine relatively large heat exchangers that take untreated pond water and use it to cool the process fluid that further cools machine components. Over the 30 years these heat exchangers have been in operation, they have undergone significant material loss on the channels. This material loss, due to various forms of corrosion such as galvanic and microbiologically influenced corrosion (MIC) and possibly others, has deteriorated more than 80% of the nominal wall thickness of some of the exchangers and placed them in a questionable state. ASME FFS-1 (API 579) has been applied to address the condition of the heat exchangers due to their noncompliance with the governing code, BPVC Sec. VIII Div. 1. The assessments encompassed ASME FFS-1 parts 4: General Metal Loss and 9: Crack Like Flaw using level 1, 2, and 3 analysis techniques based on inspection data obtained by API 510 inspections. Level 1 and 2 assessments were deemed unfit for the corroded regions due to their location relative to a major structural discontinuity (channel to tube-sheet joint), so a level 3 analysis was conducted according to ASME Sec. VIII Div. 2 (design by analysis) rules for pressure vessels. Supplemental information included pond water tests to determine an accurate future corrosion allowance due to lacking inspection history. A leak before break (LBB) route was chosen to evaluate the possibility of leaking prior to the onset of failure. The analysis of one heat exchanger shows that the possibility the channel will develop a pinhole leak over 2.5 more years of operation should not be overlooked, but burst was unlikely from operation. The use of fracture mechanics show, that if a through-wall crack were to develop, it would not propagate further than the channel geometry and cause a leak not greater than 35 GPM. Using ASME Section XI Code Case N-705-1, allowing us to operate with a leak until the next outage given certain operating conditions and developing a leak mitigation procedure, this heat exchanger is deemed fit-for-service.

Humenik, Alex [Fermilab]↗

Design Basis Document / Owner’s Technical Specification for Nitrate Salt Systems in CSP Projects (Final Technical Report)

The number of commercial coal, gas, and nuclear projects built over the past 100 years number in the thousands. As such, there is a large database, available to a wide range of commercial engineering contractors, on proven designs. In essence, unsuccessful designs have, through generations of iterations, been identified and then deleted from further consideration. In contrast, the number of commercial parabolic trough projects using nitrate salt for the thermal storage media is perhaps 60. Further, the number of commercial central receiver projects using nitrate salt as the working fluid is on the order of 20, including estimates for China. Given the relative immaturity of salt technology, and commercial pressures to successfully bid new solar projects into a mature electricity market, solar projects often promise more than has been delivered. The Design Basis Document / Owner’s Technical Specification is a first step in the iteration process. The report describes the successful features of commercial projects, outlines a range equipment and system failures in projects that didn’t operate as intended, and provides a draft set of design changes intended to correct the known problems. The product of the study is 3 volumes of technical material; one volume is on parabolic trough technologies; a second is on central receiver technologies, and the third is on potential design changes to parabolic trough and central receiver projects. The 3 volumes, which total some 590 pages, can be found at https://www.solardynllc.com/csp-plant-technologies. One of the principal topics in the report is the use of functional or prescriptive specifications. Functional specifications describe what the equipment needs to do, consistent with the minimum legal requirements of the local jurisdictions. The details of how this is to be accomplished is developed by the engineering contractor. Prescriptive specifications, which are developed by the Owner, prescribe to the engineering contractor how the functional requirements are to be met. This arrangement ensures that the favorable experience from a previous project is repeated. One example is the design code for the hot salt tank in central receiver projects. The closest design basis is API Standard 650 Welded Steel Tanks for Oil Storage. However, the maximum design temperature in API 650 is 260 °C. As such, solar projects have typically adopted a hybrid Code approach, in which allowable material stresses are taken from ASME Section II Materials. Further, since the tanks experience daily changes in temperature and in (static) pressure, and since portions of the tank can operate at stresses beyond the elastic range, the low cycle fatigue life of the tank is conducted using the rules of Section VIII Division 2. However, in a recent study by NREL, the principal damage mechanism was identified as creep rather than fatigue. Further, design stresses permitted under Section VIII Division 2, corresponding to a fatigue life of 30 years, result in projected creep lifetimes of only 2 to 5 years. An alternate design approach, prescribed by the Owner, would be based on Code sections intended for high temperature service in the creep regime. A candidate is Section III Division 5. Granted, this is a nuclear code section, and it’s use would not likely be mandated by local jurisdictions. However, the effects of creep have been deemed to be of sufficient importance that one nuclear project developer, and one central receiver project developer, have stipulated in the tank design specification that the equipment be designed to the requirements of Section III Division 5.

14 SOLAR ENERGY↗

DeepDiagnostics: A Software Package for Streamlined Posterior Evaluation

Automated prediction techniques like simulation-based inference (SBI) are important tasks for science experiments that produce large amounts of complex, raw data. However, their development remains in its early stages because the uncertainties of these techniques lack sufficient trustworthiness and interpretability. Packages for SBI provide a growing set of diagnostics; however, the software requirements are substantial, as they are tied to the inference technology itself, and the APIs lack adaptability. We introduce the DeepDiagnostics package for diagnosing posteriors from analytic likelihood-based methods and SBI methods, such as neural posterior estimation. DeepDiagnostics produces a comprehensive set of high-quality visualizations and metrics in a highly accessible, easy-to-use, and flexible package. We address all of these goals by providing a command-line inference tool and a Python API that is controlled through a configuration file. The package includes common diagnostics, such as parity plots, corner (covariance) plots, simulation-based calibration (SBC) diagnostics (including posterior coverage and rank histograms), Lemos et al. s PQMass and TARP, Masserano et al. s WALDO, Linhart et al. s LC2ST, as well as credible region diagnostics developed by our group.

Voetberg, Maggie [Fermilab]↗