Research data supporting article on "Point containment algorithms for constructive solid geometry with unbounded primitives"

<p>This file contains an archive of all research data that supports the article on "Point containment algorithms for constructive solid geometry with unbounded primitives".</p><p>This work is supported by the U.S. Department of Energy Office of Fusion Energy Sciences under award number DE-SC0022033.</p&gt

Research data supporting article on implementation and validation of OpenMC cell-based R2S shutdown dose rate capabilities

This file contains an archive of all research data that supports the article on implementation and validation of a cell-based R2S shutdown dose rate workflow in OpenMC.This work is supported by the U.S. Department of Energy Office of Fusion Energy Sciences under award number DE-SC0022033

TOWARDS CAD-BASED GEOMETRY MODELLING WITH THE RANDOM RAY METHOD

The Advanced Random Ray Code (ARRC) is a high performance computing application capable of high-fidelity simulations of full core nuclear reactor models. ARRC leverages a recently developed stochastic method for neutron transport, known as The Random Ray Method (TRRM), which offers a variety of computational and numerical advantages as compared to existing methods. In particular, TRRM has been shown to be capable of efficient simulation of explicit three dimensional geometry representations without assumptions about axial homogeneity. To date, ARRC has utilized Constructive Solid Geometry (CSG) combined with a nested lattice geometry which works well for typical pressurized water reactors, but is not performant for the general case featuring arbitrary geometries. To facilitate simulation of arbitrarily complex geometries in ARRC efficiently, we propose performing transport directly on Computer-Aided Design (CAD) models of the geometry. In this study, we utilize the Direct-Accelerated Geometry Monte Carlo (DAGMC) toolkit which tracks particles on tessellated CAD geometries using a bounding volume hierarchy to accelerate the process, as a replacement for ARRC’s current lattice-based accelerations. Additionally, we present a method for automatically subdividing the large CAD regions in the DAGMC model into smaller mesh cells required by random ray to achieve high accuracy. We test the new DAGMC geometry implementation in ARRC on several test problems, including a 3D pincells, 3D assemblies, and an axial section of the Advanced Test Reactor. We show that DAGMC allows for simulation of complex geometries in ARRC that would otherwise not be possible using the traditional approach while maintaining solution accuracy

Particle tracking acceleration via signed distance fields in direct-accelerated geometry Monte Carlo

Computer-aided design (CAD)-based Monte Carlo radiation transport is of value to the nuclear engineering community for its ability to conduct transport on high-fidelity models of nuclear systems, but it is more computationally expensive than native geometry representations. This work describes the adaptation of a rendering data structure, the signed distance field, as a geometric query tool for accelerating CAD-based transport in the direct-accelerated geometry Monte Carlo toolkit. Demonstrations of its effectiveness are shown for several problems. The beginnings of a predictive model for the data structure's utilization based on various problem parameters is also introduced

TOWARDS CAD-BASED GEOMETRY MODELLING WITH THE RANDOM RAY METHOD

The Advanced Random Ray Code (ARRC) is a high performance computing application capable of high-fidelity simulations of full core nuclear reactor models. ARRC leverages a recently developed stochastic method for neutron transport, known as The Random Ray Method (TRRM), which offers a variety of computational and numerical advantages as compared to existing methods. In particular, TRRM has been shown to be capable of efficient simulation of explicit three dimensional geometry representations without assumptions about axial homogeneity. To date, ARRC has utilized Constructive Solid Geometry (CSG) combined with a nested lattice geometry which works well for typical pressurized water reactors, but is not performant for the general case featuring arbitrary geometries. To facilitate simulation of arbitrarily complex geometries in ARRC efficiently, we propose performing transport directly on Computer-Aided Design (CAD) models of the geometry. In this study, we utilize the Direct-Accelerated Geometry Monte Carlo (DAGMC) toolkit which tracks particles on tessellated CAD geometries using a bounding volume hierarchy to accelerate the process, as a replacement for ARRC’s current lattice-based accelerations. Additionally, we present a method for automatically subdividing the large CAD regions in the DAGMC model into smaller mesh cells required by random ray to achieve high accuracy. We test the new DAGMC geometry implementation in ARRC on several test problems, including a 3D pincells, 3D assemblies, and an axial section of the Advanced Test Reactor. We show that DAGMC allows for simulation of complex geometries in ARRC that would otherwise not be possible using the traditional approach while maintaining solution accuracy

Performance Portable Monte Carlo Particle Transport on Intel, NVIDIA, and AMD GPUs

OpenMC is an open source Monte Carlo neutral particle transport application that has recently been ported to GPU using the OpenMP target offloading model. We examine the performance of OpenMC at scale on the Frontier, Polaris, and Aurora supercomputers, demonstrating that performance portability has been achieved by OpenMC across all three major GPU vendors (AMD, NVIDIA, and Intel). OpenMC's GPU performance is compared to both the traditional CPU-based version of OpenMC as well as several other state-of-the-art CPU-based Monte Carlo particle transport applications. We also provide historical context by analyzing OpenMC's performance on several legacy GPU and CPU architectures. This work includes some of the first published results for a scientific simulation application at scale on a supercomputer featuring Intel's Max series "Ponte Vecchio" GPUs. It is also one of the first demonstrations of a large scientific production application using the OpenMP target offloading model to achieve high performance on all three major GPU platforms

DESIGN OF A CODE-AGNOSTIC DRIVER APPLICATION FOR HIGH-FIDELITY COUPLED NEUTRONICS AND THERMAL-HYDRAULIC SIMULATIONS

While the literature has numerous examples of Monte Carlo and computational fluid dynamics (CFD) coupling, most are hard-wired codes intended primarily for research rather than as standalone, general-purpose codes. In this work, we describe an open source application, ENRICO, that allows coupled neutronic and thermal-hydraulic simulations between multiple codes that can be chosen at runtime (as opposed to a coupling between two specific codes). In particular, we outline the class hierarchy in ENRICO and show how it enables a clean separation between the logic and data required for a coupled simulation (which is agnostic to the individual solvers used) from the logic/data required for individual physics solvers. ENRICO also allows coupling between high-order (and generally computationally expensive) solvers to low-order “surrogate” solvers; for example, Nek5000 can be swapped out with a subchannel solver. ENRICO has been designed for use on distributed-memory computing environments. The transfer of solution fields between solvers is performed in memory rather than through file I/O.We describe the process topology among the different solvers and how it is leveraged to carry out solution transfers. We present results for a coupled simulation of a single light-water reactor fuel assembly using Monte Carlo neutron transport and CFD

DESIGN OF A CODE-AGNOSTIC DRIVER APPLICATION FOR HIGH-FIDELITY COUPLED NEUTRONICS AND THERMAL-HYDRAULIC SIMULATIONS

While the literature has numerous examples of Monte Carlo and computational fluid dynamics (CFD) coupling, most are hard-wired codes intended primarily for research rather than as standalone, general-purpose codes. In this work, we describe an open source application, ENRICO, that allows coupled neutronic and thermal-hydraulic simulations between multiple codes that can be chosen at runtime (as opposed to a coupling between two specific codes). In particular, we outline the class hierarchy in ENRICO and show how it enables a clean separation between the logic and data required for a coupled simulation (which is agnostic to the individual solvers used) from the logic/data required for individual physics solvers. ENRICO also allows coupling between high-order (and generally computationally expensive) solvers to low-order “surrogate” solvers; for example, Nek5000 can be swapped out with a subchannel solver. ENRICO has been designed for use on distributed-memory computing environments. The transfer of solution fields between solvers is performed in memory rather than through file I/O.We describe the process topology among the different solvers and how it is leveraged to carry out solution transfers. We present results for a coupled simulation of a single light-water reactor fuel assembly using Monte Carlo neutron transport and CFD

openmc-dev/openmc: OpenMC 0.14.0

<p>This release of OpenMC includes many bug fixes, performance improvements, and several notable new features. Some of the highlights include projection plots, pulse height tallies for photons, weight window generation, and an ability to specify continuous removal or feed of nuclides/elements during depletion. Additionally, one of the longstanding annoyances of depletion calculations, namely the need to include initial "dilute" nuclides, has been eliminated. There are also a wide array of general improvements in the Python API.</p> <h1>Compatibility Notes and Deprecations</h1> <ul> <li>The <code>openmc.deplete.MicroXS</code> class has been completely redesigned and improved. See further comments below under "New Features". (#2572, #2579, #2595, #2700)</li> <li>The <code>rectangular_prism</code> function has been replaced by the <code>openmc.model.RectangularPrism</code> class and the <code>hexagonal_prism</code> function has been replaced by the <code>openmc.model.HexagonalPrism</code> class. Note that whereas the <code>rectangular_prism</code> and <code>hexagonal_prism</code> functions returned a region representing the interior of the prism, the new <code>openmc.model.RectangularPrism</code> and <code>openmc.model.HexagonalPrism</code> classes return composite surfaces, so you need to use the unary <code>-</code> or <code>+</code> operators to obtain a region that can be assigned to a cell. (#2739)</li> <li>The <code>Source</code> class has been refactored and split up into three separate classes: <code>openmc.IndependentSource</code>, <code>openmc.FileSource</code>, and <code>openmc.CompiledSource</code>. (#2524)</li> <li>The <code>vertices</code> and <code>centroids</code> attributes on mesh classes now always return Cartesian coordinates and the shape of the returned arrays has changed to allow <code>ijk</code> indexing using a tuple (i.e., <code>xyz = vertices[i, j, k]</code>). (#2711)</li> <li>The <code>openmc.Material.decay_photon_energy</code> attribute has been replaced by the <code>openmc.Material.get_decay_photon_energy</code> method. (#2715)</li> </ul> <h1>New Features</h1> <ul> <li>A new <code>openmc.ProjectionPlot</code> class enables the generation of orthographic or perspective projection plots. (#1926)</li> <li>The <code>openmc.model.RightCircularCylinder</code> class now supports optional filleted edges. (#2309)</li> <li>Continuous removal or feed of nuclides/elements between materials can now be modeled during depletion via the <code>openmc.deplete.abc.Integrator.add_transfer_rate</code> method. (#2358, #2564, #2626)</li> <li>The MAGIC method for global weight window generation has been implemented as part of the C++ API. (#2359)</li> <li>A new capability for pulse height tallies (currently limited to photons) has been added and can be used via the "pulse-height" tally score. (#2452)</li> <li>A <code>openmc.model.CruciformPrism</code> class has been added that provides a generalized cruciform prism composite surface. (#2457)</li> <li>Type hints have been added in various places throughout the Python API. (#2462 , #2467, #2468, #2470, #2471, #2601)</li> <li>Voxel plots can now be generated through the <code>openmc.Plot.to_vtk</code> method. (#2464)</li> <li>The <code>openmc.mgxs.EnergyGroups</code> class now allows you to alternatively pass a string of the group structure name (e.g., "CCFE-709") instead of the energy group boundaries. (#2466)</li> <li>Several enhancements have been made to the <code>openmc.Universe.plot</code> method (addition of axis labels with units, ability to show legend and/or outlines, automatic determination of origin/width, ability to pass total number of pixels). (#2472 , #2482, #2483, #2492, #2513, #2575)</li> <li>Functionality in the Python API dealing with bounding boxes now relies on a new <code>openmc.BoundingBox</code> class. (#2475)</li> <li>Users now have more flexibility in specifying nuclides and reactions in the <code>openmc.plot_xs</code> function. (#2478)</li> <li>The import time of the <code>openmc</code> Python module has been improved by deferring the import of matplotlib. (#2488)</li> <li>Mesh clases in the Python API now support a <code>bounding_box</code> property. (#2507, #2620, #2621)</li> <li>The <code>Source</code> class has been refactored and split up into three separate classes: <code>openmc.IndependentSource</code>, <code>openmc.FileSource</code>, and <code>openmc.CompiledSource</code>. (#2524)</li> <li>Support was added for curvilinear elements when exporting cylindrical and spherical meshes to VTK. (#2533)</li> <li>The <code>openmc.Tally</code> class now has a <code>openmc.Tally.multiply_density</code> attribute that indicates whether reaction rate tallies should include the number density of the nuclide of interest. (#2539)</li> <li>The <code>openmc.wwinp_to_wws</code> function now supports <code>wwinp</code> files with cylindrical or spherical meshes. (#2556)</li> <li>Depletion no longer relies on adding initial "dilute" nuclides to each depletable material in order to compute reaction rates. (#2559, #2568)</li> <li>The <code>openmc.deplete.Results</code> class now has <code>openmc.deplete.Results.get_mass</code> (#2565), <code>openmc.deplete.Results.get_activity</code> (#2617), and <code>openmc.deplete.Results.get_decay_heat</code> (#2625) methods.</li> <li>The <code>openmc.deplete.StepResult.save</code> method now supports a <code>path</code> argument. (#2567)</li> <li>The <code>openmc.deplete.MicroXS</code> has been completely redesigned and improved. First, it no longer relies on the <code>openmc.mgxs</code> module, no longer subclasses <code>pandas.DataFrame</code>, and doesn't require adding initial "dilute" nuclides into material compositions. It now enables users to specify an energy group structure to collect multigroup cross sections, specify nuclides/reactions, and works with mesh domains in addition to the existing domains. A new <code>openmc.deplete.get_microxs_and_flux</code> function was added that improves the workflow for calculating microscopic cross sections along with fluxes. Altogether, these changes make it straightforward to switch between coupled and independent operators for depletion/activation calculations. (#2572, #2579 , #2595, #2700)</li> <li>The <code>openmc.Geometry</code> class now has <code>merge_surfaces</code> and <code>surface_precision</code> arguments. (#2602)</li> <li>Several predefined energy group structures have been added ("MPACT-51", "MPACT-60", "MPACT-69", "SCALE-252"). (#2614)</li> <li>When running a depletion calculation, you are now allowed to include nuclides in the initial material compositions that do not have neutron cross sections (decay-only nuclides). (#2616)</li> <li>The <code>openmc.CylindricalMesh</code> and <code>openmc.SphericalMesh</code> classes can now be fully formed using the constructor. (#2619)</li> <li>A time cutoff can now be specified in the <code>openmc.Settings.cutoff</code> attribute. (#2631)</li> <li>The <code>openmc.Material.add_element</code> method now supports a <code>cross_sections</code> argument that allows a cross section data source to be specified. (#2633 )</li> <li>The <code>openmc.Cell</code> class now has a <code>plot</code> method. (#2648)</li> <li>The <code>openmc.Geometry</code> class now has a <code>plot</code> method. (#2661)</li> <li>When weight window checks are performed can now be explicitly specified with the <code>openmc.Settings.weight_window_checkpoints</code> attribute. (#2670)</li> <li>The <code>openmc.Settings</code> class now has a <code>max_write_lost_particles</code> attribute that can limit the number of lost particle files written. (#2688)</li> <li>The <code>openmc.deplete.CoupledOperator</code> class now has a <code>diff_volume_method</code> argument that specifies how the volume of new materials should be determined. (#2691)</li> <li>The <code>openmc.DAGMCUniverse.bounding_region</code> method now has a <code>padding_distance</code> argument. (#2701)</li> <li>A new <code>openmc.Material.get_decay_photon_energy</code> method replaces the <code>decay_photon_energy</code> attribute and includes an ability to eliminate low-importance points. This is facilitated by a new <code>openmc.stats.Discrete.clip</code> method. (#2715)</li> <li>The <code>openmc.model.Model.differentiate_depletable_mats</code> method allows depletable materials to be differentiated independent of the depletion calculation itself. (#2718)</li> <li>Albedos can now be specified on surface boundary conditions. (#2724)</li> </ul> <h1>Bug Fixes</h1> <ul> <li>Enable use of NCrystal materials in plot_xs (#2435)</li> <li>Avoid segfault from extern "C" std::string (#2455)</li> <li>Fix several issues with the Model class (#2465)</li> <li>Provide alternative batch estimation message (#2479)</li> <li>Correct index check for remove_tally (#2494)</li> <li>Support for NCrystal material in from_xml_element (#2496)</li> <li>Fix compilation with gcc 5 (#2498)</li> <li>Fixed in the Tally::add_filter method (#2501)</li> <li>Fix meaning of "masking" for plots (#2510)</li> <li>Fix description of statepoint.batches in Settings class (#2514)</li> <li>Reorder list initialization of Plot constructor (#2519)</li> <li>Added mkdir to cwd argument in Model.run (#2523)</li> <li>Fix export of spherical coordinates in SphericalMesh (#2538)</li> <li>Add virtual destructor on PlottableInterface (#2541)</li> <li>Ensure parent directory is created during depletion (#2543)</li> <li>Fix potential out-of-bounds access in TimeFilter (#2532)</li> <li>Remove use of sscanf for reading surface coefficients (#2574)</li> <li>Fix torus intersection bug (#2589)</li> <li>Multigroup per-thread cache fixes (#2591)</li> <li>Bank surface source particles in all active cycles (#2592)</li> <li>Fix for muir standard deviation (#2598)</li> <li>Check for zero fission cross section (#2600)</li> <li>XML read fixes in Plot classes (#2623)</li> <li>Added infinity check in VolumeCalculation (#2634)</li> <li>Fix sampling issue in Mixture distributions (#2658)</li> <li>Prevent segfault in distance to boundary calculation (#2659)</li> <li>Several CylindricalMesh fixes (#2676, #2680, #2684, #2710)</li> <li>Add type checks on Intersection, Union, Complement (#2685)</li> <li>Fixed typo in CF4Integrator docstring (#2704)</li> <li>Ensure property setters are used in CylindricalMesh and SphericalMesh (#2709)</li> <li>Fix sample_external_source bug (#2713)</li> <li>Fix localization issue affecting openmc-plotter (#2723)</li> <li>Correct openmc.lib wrapper for evaluate_legendre (#2729)</li> <li>Bug fix in Region.from_expression during tokenization (#2733)</li> <li>Fix bug in temperature interpolation (#2734)</li> <li>Check for invalid domain IDs in volume calculations (#2742)</li> <li>Skip boundary condition check for volume calculations (#2743)</li> <li>Fix loop over coordinates for source domain rejection (#2751)</li> </ul> <h1>Contributors</h1> <ul> <li>@aprilnovak</li> <li>@bam241</li> <li>@bscollin</li> <li>@caderache2014</li> <li>@cfichtlscherer</li> <li>@christinacai123</li> <li>@church89</li> <li>@dubway420</li> <li>@ecasglez</li> <li>@ebknudsen</li> <li>@eepeterson</li> <li>@egor1abs</li> <li>@gonuke</li> <li>@gridley</li> <li>@HunterBelanger</li> <li>@j-fletcher</li> <li>@johvincau</li> <li>@joshmay1</li> <li>@jtramm</li> <li>@kevinm387</li> <li>@kingyue737</li> <li>@lewisgross1296</li> <li>@LukeLabrie</li> <li>@myerspat</li> <li>@nicriz</li> <li>@nutcasev15</li> <li>@paulromano</li> <li>@pshriwise</li> <li>@rlbarker</li> <li>@Shimwell</li> <li>@stchaker</li> <li>@tjlaboss</li> <li>@XinyanBradley</li> <li>@yardasol</li> <li>@zoeprieto</li> </ul&gt

PyNE Progress Report

<p>Talk given to the ANS Winter Meeting 2014</p