Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “A CODES”

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 19 records

Code-to-code comparison and validation of the radiation-hydrodynamics capabilities of the FLASH code using a laboratory astrophysical jet

The potential for laser-produced plasmas to yield fundamental insights into high energy density physics (HEDP) and deliver other useful applications can sometimes be frustrated by uncertainties in modeling the properties and behavior of these plasmas using radiation-hydrodynamics codes. In an effort to overcome this and to corroborate the accuracy of the HEDP capabilities in the publicly available FLASH radiation-hydrodynamics code, we present detailed code-to-code comparisons between FLASH and the HYDRA code developed at Lawrence Livermore National Laboratory using previously published HYDRA simulations from Grava et al. [Phys. Rev. E 78, 016403 (2008)]. That study describes a laser experiment that produced a jet-like feature that the authors compare to astrophysical jets. Importantly, the Grava et al. [Phys. Rev. E 78, 016403 (2008)] experiment included detailed x-ray interferometric measurements of electron number densities and a time-integrated measurement of the soft x-ray spectrum. Despite markedly different methods for treating the computational mesh, and different equations of state and opacity models, the FLASH results resemble the results from HYDRA and, most importantly, the experimental measurements of electron density. Having validated the FLASH code in this way, we use the code to further investigate and understand the formation of the jet seen in the Grava et al. [Phys. Rev. E 78, 016403 (2008)] experiment and discuss its relation to the Wan et al. [Phys. Rev. E 55, 6293 (1997)] experiment at the NOVA laser.

Orban, Chris (ORCID:0000000312004538)↗

Cross-Cap Defects and Fault-Tolerant Logical Gates in the Surface Code and the Honeycomb Floquet Code

We consider the Z 2 toric code, surface code, and Floquet code defined on a nonorientable surface, which can be considered as families of codes extending Shor’s nine-qubit code. We investigate the fault-tolerant logical gates of the Z 2 toric code in this setup, which corresponds to e ↔ m exchanging symmetry of the underlying Z 2 gauge theory. We find that nonorientable geometry provides a new way for the emergent symmetry to act on the code space, and discover the new realization of the fault-tolerant Hadamard gate of the two-dimensional surface code with a single cross cap connecting the vertices nonlocally along a slit, dubbed a nonorientable surface code. This Hadamard gate can be realized by a constant-depth local unitary circuit modulo nonlocality caused by a cross cap. Via folding, the nonorientable surface code can be turned into a bilayer local quantum code, where the folded cross cap is equivalent to a bilayer twist terminated on a gapped boundary and the logical Hadamard only contains local gates with intralayer couplings when being away from the cross cap, as opposed to the interlayer couplings on each site needed in the case of the folded surface code. We further obtain the complete logical Clifford gate set for a stack of nonorientable surface codes and similarly for codes defined on Klein-bottle geometries. We then construct the honeycomb Floquet code in the presence of a single cross cap, and find that the period of the sequential Pauli measurements acts as a H Z logical gate on the single logical qubit, where the cross cap enriches the dynamics compared with the orientable case. We find that the dynamics of the honeycomb Floquet code is precisely described by a condensation operator of the Z 2 gauge theory, and illustrate the exotic dynamics of our code in terms of a condensation operator supported at a nonorientable surface. Published by the American Physical Society 2024

Physics↗

Qubit-Oscillator Concatenated Codes: Decoding Formalism and Code Comparison

Concatenating bosonic error-correcting codes with qubit codes can substantially boost the errorcorrecting power of the original qubit codes. It is not clear how to concatenate optimally, given that there are several bosonic codes and concatenation schemes to choose from, including the recently discovered Gottesman-Kitaev-Preskill (GKP) – stabilizer codes [Phys. Rev. Lett. 125, 080503 (2020)] that allow protection of a logical bosonic mode from fluctuations of the conjugate variables of the mode. We develop efficient maximum-likelihood decoders for and analyze the performance of three different concatenations of codes taken from the following set: qubit stabilizer codes, analog or Gaussian stabilizer codes, GKP codes, and GKP-stabilizer codes. We benchmark decoder performance against additive Gaussian white noise, corroborating our numerics with analytical calculations. We observe that the concatenation involving GKP-stabilizer codes outperforms the more conventional concatenation of a qubit stabilizer code with a GKP code in some cases. We also propose a GKP-stabilizer code that suppresses fluctuations in both conjugate variables without extra quadrature squeezing and formulate qudit versions of GKP-stabilizer codes.

71 CLASSICAL AND QUANTUM MECHANICS, GENERAL PHYSIC↗

Code conversion with the quantum Golay code for a universal transversal gate set

The [[7,1,3]] Steane code and [[23,1,7]] quantum Golay code have been identified as good candidates for fault-tolerant quantum computing via code concatenation. These two codes have transversal implementations of all Clifford gates but require some other scheme for fault-tolerant T gates. Using magic states, Clifford operations, and measurements is one common scheme, but magic-state distillation can have a large overhead. Code conversion is one avenue for implementing a universal gate set fault tolerantly without the use of magic-state distillation. Analogously to how the [[7,1,3]] Steane code can be fault tolerantly converted to and from the [[15,1,3]] Reed-Muller code which has a transversal T gate, the [[23,1,7]] Golay code can be converted to a [[95,1,7]] triorthogonal code with a transversal T gate. Further, a crucial ingredient of this procedure is the [[49,1,5]] triorthogonal code, which can itself be seen as being related to the self-dual [[17,1,5]] two-dimensional color code. Additionally, a method for code conversion based on a transversal CNOT between the codes, rather than stabilizer measurements, is described.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗

CG-Kit: Code Generation Toolkit for performant and maintainable variants of source code applied to Flash-X hydrodynamics simulations

CG-Kit is a new Code Generation tool-Kit that we have developed as a part of the solution for portability and maintainability for multiphysics computing applications. The development of CG-Kit is rooted in the urgent need created by the shifting landscape of high-performance computing platforms and the algorithmic complexities of a particular large-scale multiphysics application: Flash-X. To efficiently use computing resources on a heterogeneous node, an application must have a map of computation to resources and a mechanism to move the data and computation to the resources according to the map. Most existing performance portability solutions are focussed on abstracting the expression of computations so that a unified source code can be specialized to run on different resources. However, such an approach is insufficient for a code like Flash-X, which has a multitude of code components that can be assembled in various permutations and combinations to form different instances of applications. Similar challenges apply to any code that has composability, where a single specified way of apportioning work among devices may not be optimal. Additionally, use cases arise where the optimal control flow of computation may differ for different devices while the underlying numerics remain identical. This combination leads to unique challenges including handling an existing large code base in Fortran and/or C/C++, subdivision of code into a great variety of units supporting a wide range of physics and numerical methods, different parallelization techniques for distributed and shared memory systems and accelerator devices, and heterogeneity of computing platforms requiring coexisting variants of parallel algorithms. All of these challenges demand that scientific software developers apply existing knowledge about domain applications, algorithms, and computing platforms to determine custom abstractions and granularity for code generation. There is a critical lack of tools to tackle those problems. CG-Kit is designed to fill this gap by providing a user with the ability to express their desired control flow and computation-to-resource map in the form a pseudocode-like recipe. It consists of standalone tools that can be combined into highly specific and, we argue, highly effective portability and maintainability toolchains. Here we present the design of our new tools: parametrized source trees, control flow graphs, and recipes. The tools are implemented in Python. They are agnostic to the programming language of the source code targeted for code generation. In conclusion, we demonstrate the capabilities of the toolkit with two examples, first, multithreaded variants of the basic AXPY operation, and second, variants of parallel algorithms within a hydrodynamics solver, called Spark, from Flash-X that operates on block-structured adaptive meshes.

Algorithmic portability↗

Code Coverage Status of the ARC Code RCT

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. REBUS plays a pivotal role in the ARC system as the primary fuel cycle analysis capability for fast reactor problems. Over its 60 year history, ARC software usage with REBUS has been applied to numerous fast and thermal spectrum reactor analysis projects with good to excellent comparison against experiments. The RCT code is a later addition and uses the REBUS restart files to define its input. The RCT code was built to provide pin depletion details on EBR-II models and thus many features of RCT were specifically tailored to the needs of EBR-II models. Additional approximations were invoked which are likely only valid for the EBR-II reactor and the particular fuel management that was done for it. The purpose of the present work is to identify a set of test problems for RCT and assess the code coverage for those test problems. The goal is to document what parts of the existing RCT code are touched by the set of test problems and which are not. Because no detailed verification work has been done on RCT, the existing regression testing suite was chosen for the code coverage assessment. The code coverage analysis of RCT was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of RCT. The detailed coverage tables are given for each part of RCT. As will be discussed and shown, some parts of the RCT capability that are known to be used by the EBR-II analysis work are not tested by the regression testing suite. These aspects should be resolved before major source code changes are taken for the RCT software. Because REBUS and DIF3D are not subroutines of RCT, the coverage changes in both of those codes is not altered by RCT. The same is true for all of the modules of DIF3D that are used by RCT such as SYSLIB and SEGLIB.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Code Coverage Status of the ARC Code PERSENT

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. PERSENT fulfills the role of generating reactivity coefficients for a given time point of a REBUS calculation usable in a point kinetics based safety analysis capability. PERSENT also provides a sensitivity coefficient capability on eigenvalue, reactivity worth, and several other key coefficients that are used in the follow-on safety analysis. Given a co-variance matrix, PERSENT can carry out the uncertainty quantification to indicate the amount of error in the reactivity coefficients derived from the errors in the cross section measurements. With continued improvement of computational resources, many of the geometry modeling capabilities in DIF3D that were primarily used in low order schemes are not really needed anymore. Today, the diffusion and transport capabilities of DIF3D-VARIANT are primarily used in the reactor design process with some scattered usage of DIF3D-FD and DIF3D-Nodal. PERSENT is part of the ARC code system and is built around DIF3D-VARIANT and the flux solution it provides. The purpose of the present work is to identify a set of test problems for PERSENT and assess the code coverage of PERSENT for those test problems. PERSENT treats the DIF3D executable as an external executable and thus the code coverage considerations only need to focus on the PERSENT source code and only a fraction of the connected modules in the existing ARC software library. The goal is to document what parts of the existing PERSENT code are touched by the set of test problems and which are not. Because the verification work done on PERSENT was focused on the most common uses of PERSENT for fast reactor analysis, the code coverage assessment of those capabilities is the highest priority. This will ensure that nothing is being missed by the existing verification test problems that users of PERSENT rely upon. The code coverage analysis of PERSENT was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of PERSENT. The detailed coverage tables are given for each submodule of PERSENT. Most of the uncovered parts/files could be easily ignored because they are either for error message and debugging output or not needed by PERSENT today. Only a few uncovered parts of PERSENT deserve extending the verification test suite.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Code Coverage Status of the ARC code GAMSRC

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. GAMSOR serves as procedure to obtain the neutron and gamma power distribution information in the ARC code system. GAMSOR is a specially modified version of DIF3D (dif3d.x becomes dif3d_gamsor.x). After some work, it was determined that carrying out software on GAMSOR was impractical and would not fit well with commercial grade dedication. GAMSRC was written in the last decade to replace GAMSOR such that the user can rely soley upon the verified DIF3D (dif3d.x) code and GAMSRC to obtain the neutron and gamma power distribution information. GAMSRC is also fully verified and ready for commercial grade dedication. In the coming years, GAMSOR will be deprecated and GAMSRC will fully take over in the ARC code system. This document identifies the set of test problems used to assess the code coverage for GAMSRC. The goal is to document what parts of the existing GAMSRC code are touched by the set of test problems and which are not. The code coverage analysis of GAMSRC was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of GAMSRC. The code coverage tables are given for each submodule of GAMSRC. Because GAMSRC links to modules in DIF3D, some details on coverage changes to the DIF3D lined files is provided. As will be seen, most of the uncovered parts/files can be ignored because they are either for error message and debugging output or obviously not needed by GAMSRC today.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

User’s Manual for RESRAD-RDD&IND Code Version 2: Vol. 2—User’s Guide for RESRAD-RDD&IND Code

Version 2.0 of the RESRAD-RDD&IND computer code is designed to support the implementation of protective action guides (PAGs) after a nuclear emergency incident including a radiological dispersal device (RDD) and/or an improvised nuclear device (IND) incident (EPA 2017). Eight different group types, addressing various decisions, are available for selection. The RESRAD-RDD&IND code calculates radiological doses, stay times, etc., for the selected group that the user wishes to focus on. (That is, the results for all the groups are not calculated simultaneously, and the input for those other groups do not matter, although some parameter values are shared between groups.) Version 2.0 has a user-friendly interface so that the RESRAD-RDD&IND code can be used with minimal training. For example, the user can select the major characteristics of the problem-event type, source term, and decision type from the left side of the interface and then calculate the results with the default assumptions for the exposure scenarios. More in-depth analysis would include specifying site-specific exposure scenario characteristics in the right side of the interface. The procedures for data entry and results viewing are self-explanatory. This is because common window maneuvering features and text instructions were incorporated in the interface design. General and context-specific help are available to aid users entering parameter values, as well. The RESRAD-RDD&IND computer code gives the user the option to select either an RDD or IND incident for analysis. For an RDD event analysis, 11 radionuclides (Am-241, Cf-252, Cm-244, Co-60, Cs-137, Ir-192, Po-210, Pu-238, Pu-239, Ra-226, and Sr-90) are included. These 11 radionuclides are the radionuclides most likely used for an RDD. More than 90 radionuclides can be selected for an IND event analysis. Initial default concentrations are provided for 44 radionuclides for a uranium-fueled IND event. These 44 radionuclides are those that would contribute significantly to the radiation dose associated with a uranium-fueled bomb detonation. The radionuclides generated from ingrowth of these 44 initial radionuclides are also automatically included in the analysis. Pu-239, Cs-134m, Ru-105, and Rb-89 and their progeny can be selected for analysis if they are detected and their concentrations are determined. This user’s guide, which is Volume 2 of the User’s Manual for RESRAD-RDD&IND Code Version 2, provides instructions to users on how to install the RESRAD-RDD&IND code, navigate the interface, and use the various features, including those discussed above, to set up an analysis and view/print the results in text outputs. Volume 1 of the User’s Manual for RESRAD-RDD&IND Code Version 2 (Yu et al. 2026), which contains descriptions of the methodology and theoretical basis for dose modeling and the mathematical equations implemented in the code, can be accessed and viewed through the Help menu in the code or can be downloaded from the RESRAD website (https://resrad.evs.anl.gov).

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Non-local transport in radiation-hydrodynamics codes for ICF by efficient coupling to an external Vlasov–Fokker–Planck code

Accurately incorporating non-local transport into radiation-hydrodynamics codes, and indeed any fluid system, has long been elusive. To date, a simplified and accurate theory that can be easily integrated has not been available. This limitation affects modeling in inertial confinement fusion (ICF) and magnetic confinement fusion systems, among others, where non-local transport is well-known to be present. Here, we present a coupling methodology between a full Vlasov–Fokker–Planck (VFP) electron kinetic code and radiation-hydrodynamics (rad-hydro) codes. The VFP code is used to adjust native electron transport in the rad-hydro code, thus enabling improved transport without the need to integrate a full electron VFP solver into the rad-hydro code. This approach necessitates only occasional invocation of the VFP code, reducing computational intensity compared to following the dynamic evolution entirely with the VFP code on fluid time scales. We illustrate that the methodology is more accurate than other simplified methods in thermal decay systems relevant to ICF and can replicate standard theoretical results with high accuracy.

Electronic transport↗

Code Coverage Status of ARC Code-DIF3D

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. DIF3D plays a pivotal role in the ARC system as the primary homogenized assembly neutronic calculation methodology for fast reactor problems. Over its 40 years history, ARC software usage with DIF3D has been applied to numerous fast and thermal spectrum reactor analysis projects with good to excellent comparison against experiments. With continued improvement of computation resources, many of the geometry modeling capabilities in DIF3D that were primarily used in low order schemes are not really needed anymore. Today, the diffusion and transport capabilities of DIF3D-VARIANT are primarily used in the reactor design process with some scattered usage of DIF3D-FD and DIF3D-Nodal. In recent work, the DIF3D software verification was completed for DIF3D-FD and DIF3D-VARIANT on the geometry options used in the Versatile Test Reactor project. While we can be confident that these capabilities of DIF3D are well used and thus trusted, it does not demonstrate that all possible input options of DIF3D are actually working, but just those that were tested as part of VTR are and that they are correct. Thus, the purpose of the present work is to identify a set of test problems for DIF3D and assess the code coverage of DIF3D for those test problems. The goal is to document what parts of the existing DIF3D code are touched by the set of test problems and which are not. Because the verification work done on DIF3D-VARIANT and DIF3D-FD was focused on the most common uses of DIF3D for fast reactor analysis, the code coverage assessment of those capabilities is the highest priority. This will ensure that nothing is being missed by the existing verification test problems that DIF3D relies upon. The DIF3D-Nodal capability will also be inspected for code coverage as part of this work to further ensure that regular regression testing of DIF3D will trap any likely errors the end user might experience with the DIF3D software. The code coverage analysis of DIF3D was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of DIF3D. The detailed coverage tables are given for each submodule of DIF3D separately, and for the submodules which are primarily developed for DIF3D, most of the source files could be at least partially touched. Most of the uncovered parts/files could be easily ignored, because they are either for error message and debugging output or obviously not needed by DIF3D. Out of the entire source codes of DIF3D, only a few uncovered modules deserve further investigation.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Code Coverage Status of the ARC Code DIF3D

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. DIF3D plays a pivotal role in the ARC system as the primary homogenized assembly neutronic calculation methodology for fast reactor problems. Over its 40 years history, ARC software usage with DIF3D has been applied to numerous fast and thermal spectrum reactor analysis projects with good to excellent comparison against experiments. With continued improvement of computation resources, many of the geometry modeling capabilities in DIF3D that were primarily used in low order schemes are not really needed anymore. Today, the diffusion and transport capabilities of DIF3D-VARIANT are primarily used in the reactor design process with some scattered usage of DIF3D-FD and DIF3D-Nodal. In recent work, the DIF3D software verification was completed for DIF3D-FD and DIF3D-VARIANT on the geometry options used in the Versatile Test Reactor project. While we can be confident that these capabilities of DIF3D are well used and thus trusted, it does not demonstrate that all possible input options of DIF3D are actually working, but just those that were tested as part of VTR are and that they are correct. Thus, the purpose of the present work is to identify a set of test problems for DIF3D and assess the code coverage of DIF3D for those test problems. The goal is to document what parts of the existing DIF3D code are touched by the set of test problems and which are not. Because the verification work done on DIF3D-VARIANT and DIF3D-FD was focused on the most common uses of DIF3D for fast reactor analysis, the code coverage assessment of those capabilities is the highest priority. This will ensure that nothing is being missed by the existing verification test problems that DIF3D relies upon. The DIF3D-Nodal capability will also be inspected for code coverage as part of this work to further ensure that regular regression testing of DIF3D will trap any likely errors the end user might experience with the DIF3D software. The code coverage analysis of DIF3D was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of DIF3D. The detailed coverage tables are given for each submodule of DIF3D separately, and for the submodules which are primarily developed for DIF3D, most of the source files could be at least partially touched. Most of the uncovered parts/files could be easily ignored, because they are either for error message and debugging output or obviously not needed by DIF3D. Out of the entire source codes of DIF3D, only a few uncovered modules deserve further investigation.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Code Coverage Status of the ARC Code DASSH-F

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. DASSH-F serves as a steady state thermal hydraulic capability within the ARC system and replaces the SE2-ANL software that preceded it. This document identifies the set of test problems used to assess the code coverage for DASSH-F. The goal is to document what parts of the existing DASSH-F code are touched by the set of test problems and which are not. Because the verification work remains to be done on DASSH-F, one can assume that most of these issues will be resolved as part of that work. The code coverage analysis of DASSH-F was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of DASSH-F. The code coverage tables are given for each submodule of DASSH-F. Because DASSH-F links to modules in DIF3D, some details on coverage changes to the DIF3D linked files is provided. As will be seen, most of the uncovered parts/files can be ignored because they are either for error message and debugging output or obviously not needed by DASSH-F today. Seven features of the DASSH-F code were identified to not be covered by the existing testing suite and thus additional verification test problems are suggested to fully cover these sections.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Code Verification and Solution Verification framework in pin-resolved neutron transport code MPACT

Program verification in scientific computing encompasses the application of formal and mathematical techniques to a scientific computing code for its credibility, accuracy, and validity. Code Verification identifies bugs and performance issues in the software development stage. Solution Verification assesses the applicability of the code and the accuracy of the solution to problems of interest. Both activities utilize application cases and quantify the error against prescribed acceptance criteria. However, simply executing more application cases does not guarantee stronger or more comprehensive credibility. Here, we establish a verification framework that involves Code Verification and Solution Verification, both of which work together such that the overarching goal of “converge to the correct answer for the intended application” can be reasonably inferred. The application of such a verification framework is demonstrated using the pin-resolved neutron transport code MPACT, where standard unit tests and regression tests are covered, and where the Method of Exact Solutions and the Method of Manufactured Solutions are successfully used. Additionally, the applicability of Method of Manufactured Solutions is extended to the OECD/NEA C5G7 benchmark problems of practical material and geometric configurations. Solution Verification activities are demonstrated on a practical hierarchy of application models of increasing complexity ranging from 2D pin cell problems to 3D assembly problems. The convergence behavior and rate of convergence with respect to each individual variable are studied and provided. This framework can be adapted broadly to other fields involving scientific computing codes.

97 MATHEMATICS AND COMPUTING↗

Portable C++ Code that can Look and Feel Like Fortran Code with Yet Another Kernel Launcher (YAKL)

This paper introduces the Yet Another Kernel Launcher (YAKL) C++ portability library, which strives to enable user-level code with the look and feel of Fortran code. The intended audience includes both C++ developers and Fortran developers unfamiliar with C++. The C++ portability approach is briefly explained, YAKL’s main features are described, and code examples are given that demonstrate YAKL’s usage. YAKL fills a niche capability important particularly to scientific applications seeking to port Fortran code quickly to a portable C++ library. YAKL places heavy emphasis on simplicity, readability, and productivity with performance mainly emphasizing Graphics Processing Units (GPUs). Central to YAKL’s ability to allow Fortran-like user-level code are three features: (1) a multi-dimensional Array class that allows Fortran behavior; (2) a limited library of Fortran intrinsic functions; and (3) an efficient pool allocator that transparently enables cheap frequent allocations and deallocations of YAKL Arrays. While YAKL allows Fortran-style code, it also allows Arrays that exhibit C-like behavior as well, including row-major index ordering and lower bounds of “0”. YAKL currently supports CPUs, CPU threading, and Nvidia, AMD, and Intel GPUs.

97 MATHEMATICS AND COMPUTING↗

Fuel cycle depletion validation and code-to-code verification studies for High Flux Isotope Reactor highly and low-enriched uranium fuel designs

Here, this paper documents fuel cycle depletion validation and code-to-code verification studies for the High Flux Isotope Reactor (HFIR) highly enriched uranium (HEU) and proposed low-enriched uranium (LEU) fuel designs. In support of HFIR’s world-leading performance, transport and depletion simulations are performed to ensure safe operations, design and qualify irradiation experiments, enhance core components and irradiation facilities, and design and characterize LEU fuel designs. Identifying well-validated, computationally efficient codes is required for the success of these efforts. The HFIR Controller, Shift, and VESTA codes were deployed to simulate HEU uranium–oxide dispersion fuel cycles at 85, 95, and 100 MW operations, as well as LEU fuel cycles operating at 95 MW with uranium–silicide dispersion and uranium–molybdenum monolithic alloy fuel forms. Excellent agreement between the codes and with experimentally obtained 235 U enrichment distributions provides increased confidence in the ability of these codes to model and simulate HFIR’s unique core design.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

Exploring code portability solutions for HEP with a particle tracking test code

Traditionally, high energy physics (HEP) experiments have relied on x86 CPUs for the majority of their significant computing needs. As the field looks ahead to the next generation of experiments such as DUNE and the High-Luminosity LHC, the computing demands are expected to increase dramatically. To cope with this increase, it will be necessary to take advantage of all available computing resources, including GPUs from different vendors. A broad landscape of code portability tools—including compiler pragma-based approaches, abstraction libraries, and other tools—allow the same source code to run efficiently on multiple architectures. In this paper, we use a test code taken from a HEP tracking algorithm to compare the performance and experience of implementing different portability solutions. While in several cases portable implementations perform close to the reference code version, we find that the performance varies significantly depending on the details of the implementation. Achieving optimal performance is not easy, even for relatively simple applications such as the test codes considered in this work. Several factors can affect the performance, such as the choice of the memory layout, the memory pinning strategy, and the compiler used. The compilers and tools are being actively developed, so future developments may be critical for their deployment in HEP experiments.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗

ASME Code Revisions to Incorporate 316H and Alloy 617 Viscoplastic Constitutive Models to Section III, Division 5 and Code Case N-898

This report provides a final status update on work to develop and implement two new constitutive models for 316H stainless steel and the Ni-based Alloy 617 in Nonmandatory Appendix Z to the Section III, Division 5, Subsection HB, Subpart B ASME Boiler & Pressure Vessel Code rules covering the design and construction of Class A high temperature nuclear reactor components. This report summarizes the objections of the overall project and provides the final versions of the constitutive models proposed for incorporation into the ASME Code. The report also provides an update on the balloting status at ASME of the two proposed constitutive models. As of the time of writing (July 2022) the models are on-track to be approved by ASME after the August 2022 Code Week. If so, this will mean the 316H model will be published in the 2023 edition of the Code and the A617 model available as part of a revised Code Case immediately

36 MATERIALS SCIENCE↗