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 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↗
DOE OSTI2025

Proposed Classifications of Remote Operations for Nuclear Reactors Based on Physical and Cybersecurity Considerations

The incorporation of remote operations into reactor operations is a topic of high interest among advanced and small modular reactor (A/SMR) vendors, with some considering it essential to the success of their business models. However, remote operations are a concept novel to the nuclear industry. While various technical aspects of remote operations have been explored, a significant gap remains in understanding the security implications of integrating remote operations into reactor designs, particularly concerning the security requirements for remote-operations facilities and infrastructure. This report aims to address this gap by first defining classes of remote operation based on the extent of remote access to reactor control systems and grounded in the existing regulatory framework with compatible terminology. Secondly, the report outlines the physical and cybersecurity requirements applicable to remote-operations facilities and infrastructure at each defined class. These requirements are based on existing licensing frameworks provided by 10 Code of Federal Regulations (CFR) Part 50 and 10 CFR Part 52, as well as the upcoming A/SMR licensing framework in the proposed Part 53. The assessment focuses specifically on security regulations, such as 10 CFR Part 73, which includes provisions for both cybersecurity (§ 73.54) and physical security (§ 73.55). This report proposes five classes of remote reactor operations. Class 1 involves remote monitoring only, with no control over reactor systems. Class 2 allows for the remote issuance of allowlisted commands to the reactor facility. Class 3 extends control to non-safety-significant, non-safety-related, or not important to safety systems and equipment. Class 4 permits remote control of safety-significant systems. Finally, Class 5 allows remote control of safety-related systems. It is important to note that these classes were defined purely with functionality in mind, without considering the practicality or feasibility of implementation for each class under current or upcoming regulatory guidance. The intention behind this approach is to enable an assessment of which security requirements apply to each class, allowing readers to evaluate the implementation possibilities for their specific use cases. Following the definition of remote-operation classes, the report assesses the specific physical and cybersecurity requirements applicable to the remote-operations facility and infrastructure within each defined class. This includes defining the types and locations of operators that are possible at each class of operation and, based on operator type and location, as well as functionality within each class, outlining the physical and cybersecurity requirements. By detailing the security requirements by class, the report provides readers with the information needed to determine the type of security program they may need to implement for their desired concept of operation. The next contribution of this report was to assess the practicality of implementing each proposed class of remote operations based upon the security requirement assessment. In short, three of the five proposed remote-operation classes were found to possibly have a practical path forward to implementation under the U.S. regulatory framework. Class 1 remote operations are currently in use in the U.S. while Class 2 and 3 remote operations may be logistically possible to implement under the U.S. regulatory framework. The final two Classes, 4 and 5, would likely be logistically difficult, if not infeasible to implement within the current U.S. physical- and cybersecurity regulatory framework. Given the results of the feasibility assessment, an example architecture is proposed for both Class 2, remote allowlisted commands, and Class 3, remote control of non-safety systems as well as security implication assessments of each architecture. These example implementations are not meant to be prescriptive in terms of how Class 2 or Class 3 remote operations should be deployed; instead, they are intended to be informative to stakeholders on how Class 2 or Class 3 could potentially be applied in order to inform their system design. An example architecture for Class 1 remote monitoring was not provided as Class 1 in already in use in U.S. nuclear operations. Example architectures for Class 4 and Class 5 were not provided due to their assessment of being likely infeasible to implement. The final contribution is an assessment of the physical- and cybersecurity implications of introducing autonomous operations into an A/SMR. What was found was that the security implications can be separated into two cases. Autonomous operations supported by SSCs located only at the reactor site, and autonomous operations supported by SSCs outside of the reactor site. For the first case, the introduction of autonomous systems will likely not change the facility’s requirement to comply with existing cyber and physical security regulation

22 - GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2022

Towards Digital and Performance-Based Supervisory HVAC Control Delivery

Upgrading supervisory HVAC control in commercial buildings is one of the most attractive decarbonization tools at our disposal. Modern controls are software programs and can in theory be deployed at scale and with a low up-front carbon "pulse". In practice, however, control delivery is a disjointed and inefficient process, dominated by manual handoffs of imprecise English language documents. A particularly high barrier exists between control implementation and building energy modeling (BEM) which results in control sequences typically not being tested for correctness or performance before implementation. Together with industry partners, DOE and the national labs are developing an ecosystem of tools and standards that can support fully digital performance-based control delivery workflows. This paper describes this ecosystem, which consists of three mutually supportive efforts. Semantic models of buildings and their systems enable automatic configuration and installation of control software. Platform-neutral control descriptions separate control algorithms from control platforms and enable the creation of libraries of reference control implementations. Dynamic whole-building energy-control simulation that can execute physically realistic control sequences makes it possible to test and evaluate the performance of control sequences and then directly compile them for installation and execution in control systems. In addition to digitizing and streamlining project-level control delivery, these standards and related software support benchmarking of control algorithms, both rule-based and optimization-based, and help to both advance the state of the art and to implement ratings and programs that encourage the adoption of high-performance control.

building controls↗
DOE OSTI2020

EVALUATION OF CONTROLLED END GAS AUTO IGNITION WITH EXHAUST GAS RECIRCULATION IN A STOICHIOMETRIC, SPARK IGNITED, NATURAL GAS ENGINE

Many stationary and heavy-duty on-road natural gas fueled engines today operate under stoichiometric conditions with a three-way catalyst. The disadvantage of stoichiometric natural gas engines compared to lean-burn natural gas and diesel engines is lower efficiency, resulting primarily from lower power density and compression ratio. Exhaust gas recirculation (EGR) coupled with advanced combustion controls can enable operation with higher compression ratio and power density, which yields higher efficiency. This also results in engine operation between the limits of knock and misfire. Operation between these limits has been named controlled end gas auto-ignition (C-EGAI) and can be used to improve the brake efficiency of the engine. Various methods of cylinder pressure-based knock quantification were explored to implement C-EGAI. The indicated quantification methods are used for the implementation of a control scheme for C-EGAI with a relation to the fractional heat release due to auto-ignition. A custom EGR system was built and the effect of EGR on the performance of a stochiometric, spark ignited, natural gas engine is evaluated. C-EGAI is implemented and the optimal parameters are determined for peak performance under EGR and C-EGAI conditions. In this study, knock detection is used for the recognition, magnitude, and location of the auto-ignition events. Cylinder pressure-based knock detection was the primary method for determining the occurrence and location of knock but was also used for implementing the ignition control scheme for controlled end gas auto-ignition. The combustion intensity metric (CIM) enabled parametric ignition timing control which allowed for the creation of a relationship between fractional heat release due to auto-ignition and CIM. Many stationary and heavy-duty on-road natural gas fueled engines today operate under stoichiometric conditions with a three-way catalyst. The disadvantage of stoichiometric natural gas engines compared to lean-burn natural gas and diesel engines is lower efficiency, resulting primarily from lower power density and compression ratio. Exhaust gas recirculation (EGR) coupled with advanced combustion controls can enable operation with higher compression ratio and power density, which yields higher efficiency. This also results in engine operation between the limits of knock and misfire. Operation between these limits has been named controlled end gas auto-ignition (C-EGAI) and can be used to improve the brake efficiency of the engine. Various methods of cylinder pressure-based knock quantification were explored to implement C-EGAI. The indicated quantification methods are used for the implementation of a control scheme for C-EGAI with a relation to the fractional heat release due to auto-ignition. A custom EGR system was built and the effect of EGR on the performance of a stochiometric, spark ignited, natural gas engine is evaluated. C-EGAI is implemented and the optimal parameters are determined for peak performance under EGR and C-EGAI conditions. In this study, knock detection is used for the recognition, magnitude, and location of the auto-ignition events. Cylinder pressure-based knock detection was the primary method for determining the occurrence and location of knock but was also used for implementing the ignition control scheme for controlled end gas auto-ignition. The combustion intensity metric (CIM) enabled parametric ignition timing control which allowed for the creation of a relationship between fractional heat release due to auto-ignition and CIM. Both exhaust gas recirculation and controlled end gas auto-ignition were analyzed with a cooperative fuel research (CFR) engine modified for boosted fuel/air intake. The data was interpreted to provide a proper evaluation of unique analytical methods to quantify the results of C_EGAI and characterize the live auto-ignition events. The control variables for this method of C-EGAI were optimized with EGR conditions to generate the point of peak performance on the CFR engine under stoichiometric, spark ignited, natural gas conditions.

Bayliff, Scott Michael↗
DOE OSTI2025

Fully implicit crystal plasticity models representing orientations with modified Rodrigues parameters

Here, this work describes a crystal plasticity formulation combining several mathematical, numerical, and implementation choices to produce a highly efficient model. Specifically, the key choices in the implementation are (1) representing orientations with modified Rodrigues parameters, (2) implementing a fully coupled implicit time integration for the elastic stretch, the crystal orientations, and the model internal variables, (3) implementing the model in the NEML2 constitutive modeling framework, based on PyTorch, to vectorize the calculations and port the computation to GPUs and other hardware accelerators, and (4) an exact implementation of the consistent tangent matrix, even for arbitrary coupling to other field variables beyond the displacements, like temperature, neutron fluence, etc. The first two features of the model are, to our knowledge, novel. The paper considers each of these choices individually as well as the final model as a whole. This includes a full description of modified Rodrigues parameters, their advantages over other representations of orientations, the mathematical formulae and tools required to implement a model with modified Rodrigues parameters, and a detailed description of the geometry of the space of modified Rodrigues parameters (in an appendix). It also includes a description of a fully implicit time integration scheme for the orientations and the advantages in representing orientations with modified Rodrigues parameters in implementing such a model. The work then assess, via numerical examples, the advantages of fully coupled implicit time integration versus more common decoupled and explicit time integration schemes. These studies demonstrate the computational advantages of fully coupled integration versus other time integration algorithms, though the performance of the competing models depends on the complexity of the underlying single crystal model. The study concludes by demonstrating that the choice of time integration method affects the sharpness of the predicted texture, with explicit methods for integrating the orientations overestimating texture sharpness and implicit methods underestimating texture sharpness.

Crystal plasticity↗
DOE OSTI2025

Using a Large Language Model as a Building Block to Generate Usable Validation and Verification Suite for OpenMP

In the HPC area, both hardware and software move quickly. Often new hardware is developed and deployed, the corresponding software stack, including compilers and other tools, are under active development while leading edge software developers are working to port and tune their applications, all at the same time. While the software ecosystem is in flux, one of the key challenges for users is obtaining insight into the state of implementation of key features in the programming languages and models their applications are using – whether they have been implemented, and whether the implementation conforms to the specification, especially for newly implemented features (less tested by widespread use). OpenMP is one of the most prominent shared memory programming models used for on-node programming in HPC. With the shift towards accelerators (such as GPUs and FPGAs) and heterogeneous programming OpenMP features are getting more complex. It is natural to ask whether generative AI approaches, and large language models (LLMs) in particular, can help in producing validation and verification test suites to allow users better and faster insights into the availability and correctness of OpenMP features of interest. In this work, we explore the use of ChatGPT-4 to generate a suite of tests for OpenMP features. We have chosen a set of directives and clauses, a total of 78 combinations, which first appeared in OpenMP 3.0 (released in May 2008) but are also relevant for accelerators. We prompted ChatGPT to generate tests in the C and Fortran languages, for both host (CPU) and device (accelerator). On the Summit super-computer using the GNU implementation, we found that, of the 78 generated tests 67 C tests and 43 Fortran tests compiled successfully and fewer than those executed to completion. On further analysis we show that not all generated tests are valid. We document the process, results, and provide detailed analysis regarding the quality of tests generated. With the aim of providing input to a production quality validation and verification suite, we manually implement the corrections required to make the tests valid according to the current OpenMP specification. We quantify this effort as small, medium, or large, and record the lines of code changed to correct the invalid tests. With the corrected tests we validate recent implementations from HPE, AMD, and GNU on the Frontier supercomputer. Our experiment and subsequent analysis show that although LLMs are capable of producing HPC specific codes, they are limited by their understanding of the deeper semantics and restrictions of programming models such as OpenMP. Unsurprisingly more commonly used features have better support, while some OpenMP 3.0 directives such as sections and tasking are not universally supported on accelerators. We demonstrate that successful compilation and execution to completion are inadequate metrics for evaluating generated code and that, at this time, commodity LLMs require expert intervention for code verification. This points to gaps in the training data that is currently available for HPC. We demonstrate that with "small" effort 37% of generated invalid C tests and 63% of generated invalid Fortran tests could be corrected. This improves productivity of test generation as we circumvent writing from scratch and the common programming errors associated with it.

Pophale, Swaroop [ORNL] (ORCID:0000000185446367)↗