Solid and Fluid Coupling of OpenMC and MOOSE
In this tutorial, you will learn how to:
Couple OpenMC to 2 separate MOOSE applications solving for the solid and fluid thermal-fluids
Couple OpenMC to mixed-dimension feedback with 3-D heat conduction and 1-D fluid flow
Establish coupling between OpenMC and MOOSE for nested universe OpenMC models
Apply homogenized temperature feedback to heterogeneous OpenMC cells
To access this tutorial:
This tutorial also requires you to download an OpenMC XML file from Box. Please download the files from the gas_assembly
folder here and place these files within the same directory structure in tutorials/gas_assembly
.
In this tutorial, we couple OpenMC to the MOOSE heat transfer module and the Thermal Hydraulics Module (THM) , a set of 1-D systems-level thermal-hydraulics kernels. OpenMC will receive temperature feedback from both the MOOSE heat transfer module (for the solid regions) and from THM (for the fluid regions). Density feedback will be provided by THM for the fluid regions. This tutorial models a full-height Tri-Structural Isotropic (TRISO)-fueled prismatic gas reactor fuel assembly, and is an extension of an earlier tutorial which coupled OpenMC and MOOSE heat conduction (i.e. without an application providing fluid feedback) for a unit cell version of the same geometry. In this tutorial, we add fluid feedback and also describe several nuances associated with setting up feedback in OpenMC lattices.
This tutorial was developed with support from the NEAMS Thermal Fluids Center of Excellence. A paper Novak et al. (2021) describing the physics models and mesh refinement studies provides additional context beyond the scope of this tutorial.
Due to the tall height of the full assembly (about 6 meters), the converged results shown in Novak et al. (2021) and in the figures in this tutorial used a finer mesh and more particles than in the input files we set up for this tutorial - the input files in this tutorial still require parallel resources to run, but should be faster-running. Parameters that have been set to coarser values are noted where applicable.
Geometry and Computational Model
The geometry consists of a TRISO-fueled gas reactor assembly INL (2016). A top-down view of the geometry is shown in Figure 1. The assembly is a graphite prismatic hexagonal block with 108 helium coolant channels, 210 fuel compacts, and 6 poison compacts. Each fuel compact contains TRISO particles dispersed in a graphite matrix with a packing fraction of 15%. All channels and compacts are ordered in a triangular lattice with pitch . Due to irradiation- and temperature-induced swelling of graphite, small helium gaps exist between assemblies. In this tutorial, rather than explicitly model the inter-assembly flow, we treat the gap regions as solid graphite. There are also graphite reflectors above and below the assembly.

Figure 1: TRISO-fueled gas reactor fuel assembly
The TRISO particles use a conventional design that consists of a central fissile uranium oxycarbide kernel enclosed in a carbon buffer, an inner Pyrolitic Carbon (PyC) layer, a silicon carbide layer, and finally an outer PyC layer. The geometric specifications for the assembly dimensions are shown in Figure 1, while dimensions for the TRISO particles are summarized in Table 1.
Table 1: Geometric specifications for the TRISO particles
Parameter | Value (cm) |
---|---|
TRISO kernel radius | 214.85e-4 |
Buffer layer radius | 314.85e-4 |
Inner PyC layer radius | 354.85e-4 |
Silicon carbide layer radius | 389.85e-4 |
Outer PyC layer radius | 429.85e-4 |
Heat is produced in the TRISO particles to yield a total power of 16.7 MWth. This heat is removed by helium flowing downwards through the coolant channels with a total mass flowrate of 9.775 kg/s, which is assumed to be uniformly distributed among the coolant channels. The outlet pressure is 7.1 MPa.
Heat Conduction Model
The MOOSE heat transfer module is used to solve for steady-state heat conduction,
(1)
where is the solid thermal conductivity, is the solid temperature, and is a volumetric heat source in the solid.
To greatly reduce meshing requirements, the TRISO particles are homogenized into the compact regions by volume-averaging material properties. The solid mesh is shown in Figure 2. The only sideset in the domain is the coolant channel surface, which is named fluid_solid_interface
. The solid geometry uses a length unit of meters. The solid mesh is created using the MOOSE reactor module Shemon et al. (2021), which provides easy-to-use mesh generators to programmatically construct reactor core meshes as building blocks of bundle and pincell meshes.

Figure 2: Converged mesh for the solid heat conduction model (with 300 axial layers); to make the tutorial run faster, our mesh will only use 100 axial layers
The file used to generate the solid mesh is shown below. The mesh is created by first building pincell meshes for a fuel pin, a coolant pin, a poison pin, and a graphite "pin" (to represent the central graphite region). The pin meshes are then combined together into a bundle pattern and extruded.
(tutorials/gas_assembly/solid_mesh.i)You can create this mesh by running:
which will create a mesh named solid_mesh_in.e
. Note that the above command takes advantage of a MOOSE feature for combining input files together by placing some common parameters used by the other applications into a file named common_input.i
.
The temperature on the fluid-solid interface is provided by Thermal Hydraulics Module (THM), while the heat source is provided by OpenMC. Because MOOSE heat conduction will run first in the coupled case, the initial fluid temperature is set to an axial distribution given by bulk energy conservation () given the inlet temperature , mass flowrate , and fluid isobaric specific heat . The initial heat source distribution is assumed uniform in the radial direction with a sinusoidal dependence in the axial direction.
OpenMC Model
The OpenMC model is built using Constructive Solid Geometry (CSG). The TRISO positions are sampled using the Random Sequential Addition (RSA) algorithm in OpenMC. OpenMC's Python Application Programming Interface (API) is used to create the model with the script shown below. First, we define materials for the various regions. Next, we create a single TRISO particle universe consisting of the five layers of the particle and an infinite extent of graphite filling all other space. We then pack uniform-radius spheres into a cylindrical region representing a fuel compact, setting each sphere to be filled with the TRISO universe.
Next, we loop over 50 axial layers and create a unique hexagonal lattice for each layer. This hexagonal lattice defines the fuel assembly structure, and consists of four different universes:
A fuel pin plus surronding matrix (
f
),A coolant channel plus surrounding matrix (
c
),A boron carbide poision pin plus surrounding matrix (
p
), andA homogeneous graphite hexagonal pincell to fill the "boundaries" and centermost region (
g
).
In each layer we set up the lattice structure by listing the universes in each "ring" of the lattice, with ring0
being the centermost ring and ring11
being the outermost ring.
Recall that temperatures in OpenMC can be set directly on the cell, but that fluid densities can only be set on materials. For this reason, we need to create 108 unique coolant materials for each axial plane if we want to be able to set unique densities in each coolant channel region. Rather than creating 108 materials in a loop, we use the clone()
feature in OpenMC to clone an existing coolant material 108 times per layer. This duplicates the material properties (densities and isotopic composition), but assigns a new ID that allows individual tracking of density. The Python script used to create the OpenMC model is shown below.
The level on which we will apply feedback from MOOSE is 1, because the geometry consists of a hexagonal lattice (level 0), and we want to apply individual cell feedback within that lattice (level 1). For the solid phase, this selection is equivalent to applying a single temperature (per compact and per layer) for a compact region - all TRISO particles and the surrounding matrix in each compact receives a uniform temperature. Finally, to accelerate the particle tracking, we:
Repeat the same TRISO universe in each axial layer and within each compact
Superimpose a Cartesian search lattice in the fuel channel regions.
The OpenMC geometry, colored by either cell ID or instance, is shown in Figure 3. Not shown are the axial reflectors on the top and bottom of the assembly. The lateral faces are periodic, while the top and bottom boundaries are vacuum. The Cartesian search lattice in the fuel compact regions is also visible in Figure 3.

Figure 3: OpenMC model, colored by cell ID or instance
Cardinal applies uniform temperature and density feedback to OpenMC for each unique cell ID instance combination. For this setup, OpenMC receives on each axial plane a total of 721 temperatures and 108 densities (one density per coolant channel). With references to the colors shown in Figure 3, the 721 cell temperatures correspond to:
The solid temperature is provided by the MOOSE heat transfer module, while the fluid temperature and density are provided by THM. Because we will run OpenMC second, the initial fluid temperature is set to the same initial condition that is imposed in the MOOSE solid model. The fluid density is then set using the ideal gas Equation of State (EOS) at a fixed pressure of 7.1 MPa given the imposed temperature, i.e. .
To create the XML files required to run OpenMC, run the script:
You can also use the XML files checked in to the tutorials/gas_assembly
directory; if you use these already-existing files, you will also need to download the geometry.xml
file from Box; this file is large due to the saved TRISO geometry information.
THM Model
The Thermal Hydraulics Module (THM) solves for conservation of mass, momentum, and energy with 1-D area averages of the Navier-Stokes equations,
(2)
(3)
(4)
where is the coordinate along the flow length, is the channel cross-sectional area, is the fluid density, is the -component of velocity, is the average pressure on the curve boundary, is the fluid total energy, is the friction factor, is the wall heat transfer coefficient, is the heat transfer area density, is the wall temperature, and is the area average bulk fluid temperature.
In this tutorial, we use 50 elements for each channel. The mesh is constructed automatically within THM. To simplify the specification of material properties, the fluid geometry uses a length unit of meters. The heat flux imposed in the THM elements is obtained by area averaging the heat flux from the heat conduction model in 50 layers along the fluid-solid interface. For the reverse transfer, the wall temperature sent to MOOSE heat conduction is set to a uniform value along the fluid-solid interface according to a nearest-node mapping to the THM elements.
Because THM will run last in the coupled case, initial conditions are only required for pressure, fluid temperature, and velocity, which are set to uniform distributions.
Multiphysics Coupling
A summary of the data transfers between the three applications is shown in Figure 4. The inset describes the 1-D/3-D data transfers with THM.

Figure 4: Summary of data transfers between OpenMC, MOOSE, and THM
Solid Input Files
The solid phase is solved with the MOOSE heat transfer module, and is described in the solid.i
input. We define a number of constants at the beginning of the file and set up the mesh from a file.
Next, we define the temperature variable, T
, and specify the governing equations and boundary conditions we will apply.
The MOOSE heat transfer module will receive power from OpenMC in the form of an AuxVariable, so we define a receiver variable for the fission power, as power
. The MOOSE heat conduction module will also receive a fluid wall temperature from THM as another AuxVariable which we name thm_temp
. Finally, the MOOSE heat transfer module will send the heat flux to THM, so we add a variable named flux
that we will use to compute the heat flux using the DiffusionFluxAux auxiliary kernel.
We use functions to define the thermal conductivities. The material properties for the TRISO compacts are taken as volume averages of the various constituent materials. We will evaluate the thermal conductivity for the boron carbide as a function of temperature by using t
(which usually is interpeted as time) as a variable to represent temperature. This is syntax supported by the HeatConductionMaterials used to apply these functions to the thermal conductivity.
We define a number of postprocessors for querying the solution as well as for normalizing the fission power and heat flux, to be described at greater length in Neutronics Input Files .
(tutorials/gas_assembly/solid.i)For visualization purposes only, we add LayeredAverages for the fuel and block temperatures. These will average the temperature in layers oriented in the direction, which we will use for plotting axial temperature distributions. We output the results of these userobjects to CSV using SpatialUserObjectVectorPostprocessors and by setting csv = true
in the output.
Finally, we specify a Transient executioner. Because there are no time-dependent kernels in this input file, this is equivalent in practice to using a Steady executioner, but allows you to potentially sub-cycle the MOOSE heat conduction solve relative to the OpenMC solve (such as if you wanted to converge the CHT fully inbetween data exchanges with OpenMC).
(tutorials/gas_assembly/solid.i)Fluid Input Files
The fluid phase is solved with THM, and is described in the thm.i
input. This input file is built using syntax specific to THM - we will only briefly cover this syntax, and instead refer users to the THM documentation for more information. First we define a number of constants at the beginning of the file and apply some global settings. We set the initial conditions for pressure, velocity, and temperature and indicate the fluid EOS object using IdealGasFluidProperties.
Next, we define the "components" in the domain. These components essentially consist of the physics equations and boundary conditions solved by THM, but expressed in THM-specific syntax. These components define single-phase flow in a pipe, an inlet mass flowrate boundary condition, an outlet pressure boundary condition, and heat transfer to the pipe wall.
(tutorials/gas_assembly/thm.i)Associated with these components are a number of closures, defined as materials. We set up the Churchill correlation for the friction factor and the Dittus-Boelter correlation for the convective heat transfer coefficient. Additional materials are created to represent dimensionless numbers and other auxiliary terms, such as the wall temperature. As can be seen here, the Material system is not always used to represent quantities traditionally thought of as "material properties."
(tutorials/gas_assembly/thm.i)THM computes the wall temperature to apply a boundary condition in the MOOSE heat transfer module. To convert the T_wall
material into an auxiliary variable, we use the ADMaterialRealAux.
Finally, we set the preconditioner, a Transient executioner, and set an Exodus output. The steady_state_detection
and steady_state_tolerance
parameters will automatically terminate the THM solution once the relative change in the solution is less than .
As you may notice, this THM input file only models a single coolant flow channel. We will leverage a feature in MOOSE that allows a single application to be repeated multiple times throughout a main application without having to merge input files or perform other transformations. We will run OpenMC as the main application; the syntax needed to achieve this setup is covered next.
Neutronics Input Files
The neutronics physics is solved with OpenMC over the entire domain. The OpenMC wrapping is described in the openmc.i
file. We begin by defining a number of constants and by setting up the mesh mirror on which OpenMC will receive temperature and density from the coupled applications, and on which OpenMC will write the fission heat source. Because the coupled MOOSE applications use length units of meters, the mesh mirror must also be in units of meters in order to obtain correct data transfers. For simplicity, we use the same solid mesh as used by the solid heat conduction solution, but this is not required. For the fluid region, we use MOOSE mesh generators to construct a mesh for a single coolant channel, and then repeat it for the 108 coolant channels.
Before progressing further, we first need to describe the multiapp structure connecting OpenMC, MOOSE heat conduction, and THM. We set the main application to OpenMC, and will have both MOOSE heat conduction and THM as "sibling" sub-applications.
At the time of writing, the MOOSE framework does not support "sibling" multiapp transfers, meaning that the data to be communicated between MOOSE heat conduction and THM (the heat flux and wall temperature data transfers in Figure 4) must go "up a level" to their common main application. This has since been relaxed.
Therefore, we will see in the OpenMC input file information related to data transfers between MOOSE heat conduction and THM. The auxiliary variables defined for the OpenMC model are shown below.
(tutorials/gas_assembly/openmc.i)For visualization purposes, we use a CellTemperatureAux to view the temperature set in each OpenMC cell and a CellDensityAux to view the density set in each fluid OpenMC cell. To understand how the OpenMC model maps to the [Mesh]
, we also include CellMaterialIDAux. Cardinal will also automatically output a variable named cell_id
(CellIDAux) and a variable named cell_instance
( CellInstanceAux) to show the spatial mapping. Next, we add a receiver flux
variable that will hold the heat flux received from MOOSE (and sent to THM) and another receiver variable thm_temp_wall
that will hold the wall temperature received from THM (and sent to MOOSE).
Finally, to reduce the number of transfers from THM, we will receive fluid temperature from THM, but re-compute the density locally in the OpenMC wrapping using a FluidDensityAux with the same EOS as used in the THM input files.
(tutorials/gas_assembly/openmc.i)Next, we set initial conditions for the fluid wall temperature, the fluid bulk temperature, and the heat source. We set these initial conditions in the OpenMC wrapper because the very first time that the transfers to the MOOSE heat conduction module and to THM occur, these initial conditions will be passed.
(tutorials/gas_assembly/openmc.i)The [Problem]
and [Tallies]
blocks are then used to specify settings for the OpenMC wrapping. We define the total power for normalization, indicate that blocks 1, 2, and 4 are solid (graphite, compacts, and poison) while block 101 is fluid. We add a CellTally to block 2, the fuel compacts. Because OpenMC solves in units of centimeters, we specify a scaling
of 100, i.e. a multiplicative factor to apply to the [Mesh]
to get into OpenMC's centimeter units.
Other features we use include an output of the fission tally standard deviation in units of W/m to the [Mesh]
by setting output = 'unrelaxed_tally_std_dev'
. This is used to obtain uncertainty estimates of the heat source distribution from OpenMC in the same units as the heat source. We also leverage a helper utility in CellTally by setting check_equal_mapped_tally_volumes = true
. This parameter will throw an error if the tallied OpenMC cells map to different volumes in the MOOSE domain. Because we know a priori that the equal-volume OpenMC tally cells should all map to equal volumes, this will help ensure that the volumes used for heat source normalization are also all equal. For further discussion of this setting and a pictorial description of the possible effect of non-equal mapped vlumes, please see the OpenMCCellAverageProblem documentation.
We also set identical_cell_fills
to the set of subdomains for which OpenMC's cells have identical fills. This is an optimization that greatly reduces the initialization time for large TRISO problems. During setup of an OpenMC wrapping, we need to cache all the cells contained within the TRISO compacts so that we know all the contained cells to set the temperatures for. This process can be quite time-consuming if the search needs to be repeated for every single TRISO compact cell (210 compacts times 50 axial layers = 10,500 contained cell searches). The identical_cell_fills
option is used to indicate whether your problem can leverage a speedup that applies to models where every lattice/universe-filled tally cell has exactly the same filling lattice/universe. In other words, we set up our problem to use the same TRISO universe in each layer of each fuel compact. This means that the cells filling each TRISO compact can be deduced by following a pattern based on the first two fuel compacts, letting us omit 10,498 of the contained cell searches.
When first using this optimization for a new problem, we recommend setting check_identical_cell_fills = true
so that you can do an exact comparison against the "rigorous" approach to be sure that your problem setup has the necessary prerequisites to use this feature. After you verify that no errors are thrown during setup, set check_identical_cell_fills
to false
(the default) to use this initialization speedup feature.
Because the blocks in the OpenMC mesh mirror receive temperatures from different applications, we use the temperature_variables
and temperature_blocks
parameters of OpenMCCellAverageProblem to automatically create separate variables for OpenMC to read temperature from in different parts of the domain. The temperature_blocks
and temperature_variables
parameters allow you to customize exactly the variable names from which to read temperature.
Finally, we apply a constant relaxation model to the heat source. A constant relaxation will compute the heat source in iteration as an average of the heat source from iteration and the most-recently-computed heat source, indicated here as a generic operator which represents the Monte Carlo solve:
(5)
In Eq. (5), is the relaxation factor, which we set here to 0.5. In other words, the heat source in iteration is an average of the most recent Monte Carlo solution and the previous iterate. This is necessary to accelerate the fixed point iterations and achieve convergence in a reasonable time - otherwise oscillations can occur in the coupled physics.
We run OpenMC as the main application, so we next need to define MultiApps to run the solid heat conduction model and the THM fluid model as the sub-applications. We also require a number of transfers both for 1) sending necessary coupling data between the three applications and 2) visualizing the combined THM output. To couple OpenMC to MOOSE heat conduction, we use four transfers:
MultiAppShapeEvaluationTransfer to transfer:
power from OpenMC to MOOSE (with conservation of total power)
MultiAppGeometricInterpolationTransfer to transfer:
solid temperature from MOOSE to OpenMC
wall temperature from OpenMC (which doesn't directly compute the wall temperature, but instead receives it from THM through a separate transfer) to MOOSE
MultiAppGeneralFieldNearestLocationTransfer to transfer and conserve heat flux from MOOSE to OpenMC (which isn't used directly in OpenMC, but instead gets sent later to THM through a separate transfer)
To couple OpenMC to THM, we require three transfers:
MultiAppGeneralFieldUserObjectTransfer to send the layer-averaged wall heat flux from OpenMC (which computes the layered-average heat flux from the heat flux received from MOOSE heat conduction) to THM
MultiAppGeneralFieldNearestLocationTransfer to transfer:
fluid wall temperature from THM to OpenMC (which isn't used directly in OpenMC, but instead gets sent to MOOSE heat conduction in a separate transfer)
fluid bulk temperature from THM to OpenMC
For visualization purposes, we also send the pressure and velocity computed by THM to the OpenMC mesh mirror.
(tutorials/gas_assembly/openmc.i)To compute the layer-averaged heat flux on the surface of each coolant channel (which is used as a boundary condition in THM), we use a NearestPointLayeredSideAverage user object, where by providing the center points of each of the coolant channels, we can get a unique heat flux along each channel wall. We also add several LayeredAverage user objects in order to compute radially-averaged power, temperatures, pressures, and velocities that we will use later in making axial plots of the solution. We can automatically output these user objects into CSV format by translating the user objects into SpatialUserObjectVectorPostprocessors. A number of postprocessors are included related to the Monte Carlo solution, as well as inlet pressure and pressure drop. See the next section for further description.
(tutorials/gas_assembly/openmc.i)Finally, we use a Transient executioner and specify Exodus and CSV output formats. Note that the time step size is inconsequential in this case, but instead represents the Picard iteration. We will run for 10 "time steps," which represent fixed point iterations.
(tutorials/gas_assembly/openmc.i)Execution and Postprocessing
To run the coupled calculation,
This will run with 4 MPI processes and 2 OpenMP threads per rank. This tutorial uses quite large meshes due to the 6 meter height of the domain - if you wish to run this tutorial with fewer computational resources, you can reduce the height and the various mesh parameters (number of extruded layers and elements in the THM domain) and then recreate the OpenMC model and meshes. Recall that all results shown in this section correspond to the same input files but with 300 extrusion layers in the solid, 150 THM elements per channel, 2000 particles per batch, 500 inactive batches, and 2000 active batches - to get a faster-running tutorial, we reduced all of these parameters to coarser values.
When the simulation has completed, you will have created a number of different output files:
openmc_out.e
, an Exodus file with the OpenMC solution and the data that was ultimately transferred in/out of OpenMCopenmc_out_bison0.e
, an Exodus file with the solid solutionopenmc_out_thm<n>.e
, Exodus files with each of the<n>
THM solutionsopenmc_out.csv
, a CSV file with the results of the postprocessors in the OpenMC wrapping input file for each time stepopenmc_out_bison0.csv
, a CSV file with the results of the postprocessors in the solid heat conduction input file for each time stepopenmc_out_bison0_block_axial_avg_<n>
.csv, a CSV file with the layer-averaged block temperature at time step<n>
openmc_out_bison0_flux_axial_avg_<n>
.csv, a CSV file with the layer-averaged fluid-solid interface heat flux at time step<n>
openmc_out_bison0_fuel_axial_avg_<n>
.csv, a CSV file with the layer-averaged compact temperature at time step<n>
openmc_out_fluid_avg_<n>.csv
, a CSV file with the layer-averaged fluid bulk temperature at time step<n>
openmc_out_power_avg_<n>
.csv, a CSV file with the layer-averaged heat source at time step<n>
openmc_out_pressure_avg_<n>
.csv, a CSV file with the layer-averaged pressure at time step<n>
openmc_out_velocity_avg_<n>.csv
, a CSV file with the layer-average axial fluid velocity at time step<n>
Coupled convergence is defined at the point when 1) the eigenvalue is within the uncertainty band of the previous iteration and 2) there is less than 2 K absolute change in maximum fuel, block, and fluid temperatures. Convergence is obtained in 6 fixed point iterations. Figure 5 shows the maximum fuel, compact, and fluid temperatures, along with the eigenvalue, as a function of iteration number for all 10 iterations run. For each iteration, we first run MOOSE heat conduction (which we indicate as iterations A1, A2, and so on), followed by OpenMC (which we indicate as iterations B1, B2, and so on), and finally THM (which we indicate as iterations C1, C2, and so on). In other words, in iteration :
Iteration A represents a MOOSE heat conduction solve using the power and fluid-solid wall temperature from iteration
Iteration B represents an OpenMC solve using the solid temperature from iteration and the fluid temperature and density from iteration
Iteration C represents a THM solve using the fluid-solid wall heat flux from iteration

Figure 5: Convergence in various metrics as a function of iteration number
Figure 6 shows the radially-averaged power from OpenMC as a function of iteration number. There is essentially no change in the axial distribution beyond 6 fixed point iterations, which further confirms that we have obtained a converged solution. The remainder of the depicted results correpond to iteration 6.

Figure 6: Radially-average fission power distribution as a function of iteration number
Figure 7 shows the fission power distribution computed by OpenMC. The inset shows the power distribution on an plane 2.15 meters from the inlet, where the maximum power occurs. Slight azimuthal asymmetries exist due to the finite tally uncertainty. Neutrons reflecting back into the fuel region from the axial reflectors cause local power peaking at the ends of the assembly, while the negative fuel temperature coefficient causes the power distribution to shift towards the reactor inlet where temperatures are lower. The six poison compacts in the corners result in local power depression such that the highest compact powers occur near the center of the assembly.

Figure 7: Fission power predicted by OpenMC; note the use of a separate color scale for the inset.
Figure 8 shows the solid temperature (left) computed by MOOSE and the cell temperature imposed in OpenMC (right). The bottom row shows the temperature on an plane 2.15 meters from the inlet. The insulated boundary conditions, combined with a lower "density" of coolant channels near the lateral faces, result in higher compact temperatures near the assembly peripheries, except in the vicinity of the poison pins where the increased absorption reduces the local power densities. Each OpenMC cell is set to the volume-average temperature from the mesh mirror elements whose centroids mapped to each cell; a similar procedure is used to set cell temperatures and densities for the fluid cells.

Figure 8: Solid temperature predicted by MOOSE (left) and volume-average temperature imposed in OpenMC (right). Note the use of a separate color scale for the insets.
Figure 9 shows the solid temperature computed by MOOSE on several planes with the fluid temperature computed by THM shown as tubes. An inset shows the fluid temperature on the outlet plane. The absence of compacts in the center region results in the lowest fluid temperatures in this region, while the highest fluid temperatures are observed for channels surrounded by 6 compacts that are sufficiently close to the periphery to be affected by the lateral insulated boundary conditions.

Figure 9: Fluid temperature predicted by THM (tubes and inset) and solid temperature predicted by MOOSE (five slices). Note the use of three separate color scales.
Finally, Figure 10 shows the radially-averaged fission distribution and fluid, compact, and graphite temperatures (left); and velocity and pressure (right) as a function of axial position. The negative temperature feedback results in a top-peaked power distribution. The fuel temperature peaks near the mid-plane due to the combined effects of the relatively high power density and the continually-increasing fluid temperature with distance from the inlet. The pressure gradient is nearly constant with axial position. Due to mass conservation, the heating of the fluid results in the velocity increasing with distance from the inlet.

Figure 10: Radially-averaged temperatures, power, pressure, and velocity as a function of position.
References
- INL.
High-Temperature Gas-Cooled Test Reactor Point Design.
Technical Report INL/EXT-16-38296, Idaho National Laboratory, 2016.
URL: https://tinyurl.com/v9a4hym5.[BibTeX]
- A.J. Novak, D. Andrs, P. Shriwise, D. Shaver, P.K. Romano, E. Merzari, and P. Keutelian.
Coupled Monte Carlo and Thermal-Hydraulics Modeling of a Prismatic Gas Reactor Fuel Assembly Using Cardinal.
In Proceedings of Physor. 2021.[BibTeX]
- E. Shemon, K. Mo, Y. Miao, Y. Jung, S. Richards, A. Oaks, and S. Kumar.
MOOSE Framework Enhancements for Meshing Reactor Geometries.
In Proceedings of Physor. 2021.[BibTeX]