Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “implementation”

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 1,063 records · Page 59
All sourcesNASA NTRSDOE OSTI
DOE OSTI2026

Fermilab PIP II machine protection system digitized data noise elimination scheme and its FPGA implementation

In Fermilab's PIP-II machine protection system, beam loss signals from various detectors are digitized at 125 MS/s. Noise from both high-frequency sources and low-frequency 60 Hz AC power equipment can contaminate the data. To suppress noise across these ranges especially 60 Hz and its harmonics, which overlap with beam loss signal frequencies advanced digital processing beyond standard filtering is required. Several real-time functional blocks were simulated and tested on an FPGA: (1) a dual time-constant discharging integrator filter, (2) a de-ripple baseline extraction and storage block, and (3) a fast-recovery discharging integrator. The nonlinear IIR integrator filter removes high-frequency noise and feeds into the baseline extractor. Upon detecting abrupt beam loss, it switches to a longer time constant to prevent baseline distortion. The de-ripple block calculates a valid baseline by averaging over multiple 60 Hz periods, storing results in a 4096-word FPGA RAM. This baseline is subtracted from raw data before integration by the fast-recovery block, which resets quickly after use. All blocks achieved expected performance.

Wu, J. [Fermilab] (ORCID:0000000344329521)↗
DOE OSTI2025

Implementation of fuel management multi-cycle optimization capabilities in RAVEN optimization framework

Optimization in nuclear fuel-management assists the core reload engineer with finding optimal out-of-core and in-core strategies. RAVEN is INL’s open source software that is equipped with fuel-management optimization capabilities including single-cycle, single- and multi-objective optimization of pressurized water reactors (PWRs) loading patterns (LP) of a fresh core using genetic algorithm (GA) and non-dominated sorting genetic algorithm (NSGA-II). In practice, however, medium and long term planning of fuel-management needs a multi-cycle approach, where the history and availability of fuel assemblies is considered in the optimization process. In this paper, we present a description of an initial expansion of RAVEN fuel-management optimization capabilities for a multi-cycle optimization framework. N-th cycle optimization capabilities that account for the unique history of recycled fuel assembly in the core were added. The multi-cycle optimization approach taken is formulated as a cycle-wise optimization problem where out-of-core decisions are used to onset each cycle optimization. Out-of-core decisions are managed externally to the in-core optimization by a fuel inventory management module. A proof-of-concept optimization problem is also presented.

42 - ENGINEERING↗
DOE OSTI2025

Implementing Environmental Considerations to Molten Chloride Reactor Experiment Equipment Removal and Disposal Plan

The Molten Chloride Reactor Experiment (MCRE) will be the first operational advanced nuclear experiment to utilize molten chloride salt mixed with fissile material as both a fuel and coolant source. The MCRE experiment will investigate the instillation, operation, and removal of small fast molten salt reactors and will involve unique requirements for Equipment Removal and Disposal (ERD).

21 - SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLAN↗
DOE OSTI2020

Improving the performance of medical imaging applications using SYCL

As opposed to the Open Computing Language (OpenCL) programming model, in which host and device codes are generally written in different programming languages, SYCL can combine host and device codes for an application in a type-safe way to improve development productivity and performance portability. Hence, this report shows the experimental results of applying the SYCL programming model to medical imaging applications for a study on performance portability and programming productivity between OpenCL and SYCL. Rodinia is a widely used open-source benchmark suite for heterogeneous computing. We choose two medical imaging applications (Heart Wall and Particle Filter) in the benchmark suite, migrate the OpenCL implementations of the applications to the SYCL implementations, and evaluate their performance and productivity on Intel® microprocessors that contain a central processing unit (CPU) and an integrated graphics processing unit (GPU). The maturing SYCL compilers, which are based on a conformant implementation of the SYCL 1.2.1 Khronos specification, have been actively optimized for Intel® computing platforms. The experimental results are promising in terms of the raw performance and productivity. Although the SYCL implementation of the Heart Wall application does not execute successfully on a CPU, the SYCL implementations of the application can achieve comparable or better performance than the OpenCL implementation on Intel® integrated GPUs. For the Particle Filter application, the performance difference between the SYCL and OpenCL implementations is comparable on the GPUs for most cases, but the SYCL implementations are on average 4X faster than the OpenCL implementations on Intel® Xeon® CPUs. For programming productivity, we arguably use lines of code as a way to measure programming productivity in software. The SYCL programs reduce the lines of code of the OpenCL programs by 52% and 38% for the Heart Wall and Particle Filter, respectively. The results indicate that SYCL is a promising programming model for heterogeneous computing with the maturing compilers. We organize the remainder of the report as follows. Section II introduces the SYCL programming model, compares the major differences between an OpenCL program and a SYCL program, and describes the characteristics of the two applications. Section III describes the SYCL programming model in more details, and shows the SYCL implementation of a kernel function in the Particle Filter application as an example. In Section IV, we evaluate the performance of the applications on the CPUs and GPUs. Section V concludes the report.

59 BASIC BIOLOGICAL SCIENCES↗
DOE OSTI2022

Autonomous System Subversion Tactics: Prototypes and Recommended Countermeasures

One of the fielding requirements for Advanced and Small Modular Reactors (AR/SMR) is the ability to support remote and autonomous operations. Autonomous Control Systems (ACS) are found on platforms such as Autonomous Space Vehicles, Cruise Missiles, and advanced driver-assistance systems. Each of these ACS implementations depends upon a set of decision support subsystems responsible for supporting Autonomous Mission Managers (names vary based upon field and author preferences). These Autonomous Mission Managers receive inputs from system sensors (e.g., LIDAR collection from an automobile travelling down a street; transients from a nuclear reactor), and perform a set of classifications (e.g., Red Traffic Light; Small Pedestrian at 10m; Load Rejection; Single Coolant Pump Trip), and then use these classifications in combination with recommendation algorithms to achieve platform goals (e.g., Stop the Vehicle at the Traffic Light, Avoid the Small Pedestrian; Trip the Reactor to prevent a Safety Event). The design, implementation, and fielding of an ACS capability will alter the cyber-attack surface such that existing risk management plans will need to be updated to include how to protect and defend against data-science and decision-support-system attack classes. These attack classes would include protection of the design and training environments where algorithm selection and testing and training data would be obvious attack vectors. These attack classes would also require an informed set of detection and response procedures to identify anomalous behaviors and document best practices for anomaly assessment and vulnerability mitigation and remediation. Last year we published a Cyber Threat Assessment Methodology for Autonomous and Remote Operations for AR/SMRs along with a companion publication on Cyber Attack and Defense Use Cases. The focus of the methodology was on describing and enumerating ACS processes, components, and functions such that security engineers could: evaluate subversion options against the target; identify threat actor attributes and capabilities derived from each subversion option; and identify security controls and response countermeasures. The Use Cases document offered detailed methodology examples including an assessment of a Military Base SMR, an Autonomous System Decision Loop, and implementation of AR/SMR Machine Learning algorithms. Our proposal at the end of last year was to focus on implementation of subversion prototypes related to the last Use Case area: AR/SMR Machine Learning (ML) Algorithms. We included six attack scenarios in our Use Cases paper: a Poisoning Attack against ML functions implemented using an FPGA; a Trojaning Attack against ML classifiers exploiting the excitability of Nuclear Engineers; a Backdooring Attack against ML Training environments to ensure persistence of an attack vector; a False Positive Evasion Attack against multi-factor Access Control Systems using clever inputs; an Inference Attack against ML models by an Insider with access to the Operational environment; and an Adversarial Reprogramming Attack against a Material Access Control Video Surveillance System. At the beginning of this year these six attack scenarios were provided to our research teams at Georgia Tech and Idaho State University and each team successfully implemented a subversion attack against a ML implementation to include transient misclassifications. While this is a notable outcome from this type of research, this paper offers the reader insight into not only how to structure and execute these types of attacks, but into the thought process behind how the researcher investigated the problem space, performed initial algorithm implementation, and the trial-and-error behind arriving at the successful subversion prototypes. We include in this paper a set of associated Scenarios on how these subversion prototypes could be implemented and an initial set of guidance for AR/SMR architects, Nuclear Regulators, and Cyber Defenders to implement awareness and defense capabilities into their current operational portfolios.

42 ENGINEERING↗
DOE OSTI2023

Overcoming persistent challenges in putting environmental flow policy into practice: a systematic review and bibliometric analysis

The implementation of environmental flows (e-flows) aims to reduce the negative impacts of hydrological alteration on freshwater ecosystems. Despite the growing attention to the importance of e-flows since the 1970s, actual implementation has lagged. Therefore, we explore the limitations in e-flows implementation, their systemic reasons, and solutions. We conducted a systematic review and a bibliometric analysis to identify peer-reviewed articles published on the topic of e-flows implementation research in the last two decades, resulting in 68 research and review papers. Co-occurrence of terms, and geographic and temporal trends were analyzed to identify the gaps in environmental water management and propose recommendations to address limitations on e-flows implementation. We identify the underlying causes and potential solutions to such challenges in environmental water management. The limitations to e-flow implementation identified were categorized into 21 classes. The most recognized limitation was the competing priorities of human uses of water (n = 29). Many secondary limitations, generally co-occurring in co-causation, were identified as limiting factors, especially for implementing more nuanced and sophisticated e-flows. The lack of adequate hydrological data (n = 24) and ecological data (n = 28) were among the most mentioned, and ultimately lead to difficulties in starting or continuing monitoring/adaptive management (n = 28) efforts. The lack of resource/capacity (n = 21), experimentation (n = 19), regulatory enforcement (n = 17), and differing authorities involved (n = 18) were also recurrent problems, driven by the deficiencies in the relative importance given to e-flows when facing other human priorities. In order to provide a clearer path for successful e-flow implementation, system mapping can be used as a starting point and general-purpose resource for understanding the sociohydrological problems, interactions, and inherited complexity of river systems. Secondly, we recommend a system analysis approach to address competing demands, especially with the use of coupled water-energy modeling tools to support decision-making when hydropower generation is involved. Such approaches can better assess the complex interactions among the hydrologic, ecological, socioeconomic, and engineering dimensions of water resource systems and their effective management. Lastly, given the complexities in environmental water allocation, implementation requires both scientific rigor and proven utility. Consequently, and where possible, we recommend a move from simplistic flow allocations to a more holistic approach informed by hydroecological principles. To ease conflicts between competing water demands, water managers can realize more 'pop per drop' by supporting key components of a flow regime that include functional attributes and processes that enhance biogeochemical cycling, structural habitat formation, and ecosystem maintenance.

54 ENVIRONMENTAL SCIENCES↗
DOE OSTI2024

The Transactive Energy Network Template Metamodel

While transactive energy, which is defined as an allocation of electricity based on dynamically discovered values or prices, has been extensively studied, its uptake and use has been slow. This report describes a tool, the transactive network template, which should hasten the creation and uptake of transactive energy networks. Some basic principles of transactive energy are familiar from existing wholesale electricity markets. Locational prices are calculated today for zones within bulk electric transmission systems. Locational prices differ while accounting for the locational costs of electricity generation and the losses and constraints incurred when electricity is transmitted from generators and distributed to consumers. A transactive energy network might include these transmission zones. However, current research strives to apply transactive energy also in electricity distribution circuits, buildings, and even for individual generating and consuming devices. At the same time, researchers explore how to apply transactive energy in real time during increasingly shorter time intervals. Automated computational agents become necessary as transactive energy becomes applied to smaller circuit zones and at faster dynamic timescales. A transactive energy network is an example of a multi-agent system. Each zone in the network is represented by its transactive agent, which makes decisions for and acts on behalf of a business entity that is responsible for and manages one of the circuit regions. A transactive energy network is also an example of a decentralized, distributed control system. Control decisions and responsibilities are distributed among the network’s transactive agents. The transactive agents are independent; that is, there typically is no centralized authority or oversight function. Instead, transactive agents exchange transactive signals and thereby negotiate the prices and quantities of electricity that they will exchange. Initially, the circuit regions and responsibilities of transactive agents appear to be very dissimilar. Each circuit region may comprise transmission, distribution, or building-level circuits. Each has a unique position and electrical connectivity within the transactive energy network. Each possesses unique assets that either generate or consume electricity, and these (e.g., renewable energy generator, diesel generator, aggregate utility load, building load, space conditioning, refrigerator, etc.) may further differ in their price flexibility and in their strategies for responding to dynamic electricity prices. Given such diversity, an implementer’s first inclination might be to start from scratch to define all these devices and to engineer their seemingly unique interactions. Given that each implementer’s perspective may be narrow within a transactive energy network, it is unlikely that uniquely engineered systems would interact well. This is where the transactive network template is applicable. The transactive network template is a metamodel that has been developed to guide implementers as they configure their own transactive agent within a network of such agents. The object-oriented design of the transactive network template provides basic code object types that may be used and extended by implementers to represent each of the assets in their circuit region. These objects further facilitate the transactive agent’s necessary computations, which are divided among responsibilities to schedule power usage, balance electric supply and demand, and coordinate the exchange of electricity with the other transactive agents. This report addresses the conceptual transactive network template design. Implementers are directed to more formal design documents and reference implementations. A Python™-based1 reference implementation of the transactive network template has been coded, and three implementations have been configured to represent a national laboratory and two university campuses. Version 2 of the transactive node template generalizes the market class and its methods to facilitate multiple, and more diverse market coordination mechanisms than were facilitated by and demonstrated using Version 1. Version 3 includes new Appendix B, which addresses the designs of methods that would make dynamic prices track approved electricity rates. In the future, the author wishes to make the transactive network template more generally applicable to networks that require more accurate power flow. Development of the transactive network template is jointly funded by the U.S. Department of Energy (DOE) Energy Efficiency and Renewable Energy and the DOE Office of Electricity. In late 2015, one of the first projects to be funded by the DOE Grid Laboratory Modernization Laboratory Consortium was the Clean Energy and Transactive Campus project, led by Pacific Northwest National Laboratory. DOE funds were matched by an investment by the Washington Department of Commerce through its Clean Energy Fund. The transactive network template was developed to guide the implementation of transactive energy networks within this project’s scope.

24 POWER TRANSMISSION AND DISTRIBUTION↗
DOE OSTI2025

Experiences with SYCL on AMD GPUs with Kokkos

With the recent diversification of the hardware landscape in the high-performance computing (HPC) community, performance-portability solutions are becoming more and more important. One of the most popular choices is Kokkos, which recently became a Linux Foundation project. Most of its development is supported by the US Department of Energy and the French Alternative Energies and Atomic Energy Commission. Kokkos is implemented as a C++ library with multiple backends to support CPUs as well as various GPU architectures. These backends include OpenMP, CUDA, HIP, and also SCYL. This approach enables users to leverage the preferred vendor toolchain for the respective platform (e.g. CUDA, ROCm, OneAPI). The SYCL backend is used to target Intel GPUs, in particular to support the Aurora exascale supercomputer. However, SYCL itself also offers a large degree of portability, and in fact Kokkos’ CI for SYCL has been running on NVIDIA hardware due to a lack of access to Intel GPUs. In this report, we describe our experience with using Kokkos SYCL backend on AMD GPUs targeting the Frontier supercomputer at Oak Ridge National Laboratory. The two major SYCL implementations are DPC++ and AdaptiveCpp. While the Kokkos SYCL backend has been implemented using the former, the latter was the first implementation to target AMD GPUs. We will discuss the experience with both of these SYCL implementations in terms of functionality and performance. Using Kokkos to evaluate SYCL toolchains has a number of benefits. Kokkos’ use of SYCL is fairly complex, exercising features such as graphs, relocatable device functions, atomics – including for non-arithmetic types, as well as pinned and page migratable memory allocations. Kokkos also needs to implement capabilities such as Kokkos’ hierarchical parallelism that are not a straight-forward mapping to SYCL capabilities. Furthermore, a large number of libraries and applications that represent diverse use cases are implemented in Kokkos, providing readily available test cases for a toolchain evaluation. Preliminary results show that support for AMD GPUs in DPC++ is much less mature than for NVIDIA GPUs or Intel GPUs. While the situation has improved significantly over the last year, we still encounter many runtime failures, dispatching problems, and code generation issues. With AdaptiveCpp the challenges arise even earlier in the evaluation process. Since Kokkos’ SYCL implementation is largely focused on supporting Intel GPUs, we opted to leverage SYCL extensions which are available in DPC++ but not in AdaptiveCpp. Furthermore, AdaptiveCpp appears to be less conformant with the SYCL2020 standard which Kokkos relies on. In some cases, we are able to work around the lack of feature support, in other cases we have to disable certain Kokkos capabilities to evaluate the toolchain. Our evaluation will leverage Kokkos’ unit tests to establish basic functionality and feature completeness. We then use simple benchmarks for components of a CG implementation as a measure of usability and performance of the SYCL toolchains.

97 MATHEMATICS AND COMPUTING↗