SCM model for the Toshiba 37-pin benchmark

Contact: Mauricio Tano, mauricio.tanoretamales.at.inl.gov

Benchmark Description

The Toshiba 37-pin benchmark is based on liquid sodium experiments conducted by the Toshiba Corporation Nuclear Engineering Laboratory in Japan (Namekawa et al., 1984). Its assembly consists of four outer rings of electrically heated pins. However, the resistances in the electrically heated pins are adapted to reproduce a chopped cosine power distribution in the axial direction. All heating pins are assumed to have the same power distribution. The cross section of the fuel assembly is presented in Figure 1. In this figure the numbering of the pins and the subchannels are described. The analyzed quantity of interest is the temperature distribution at the outlet of the assembly. Due to symmetry, it is enough to analyze the temperature distributions over a symmetry line. In this case, following experiment reported results, we take a south-to-north line in the fuel assembly. This one involves, in south to north ordering, subchannels 72, 49, 32, 20, 10, 4, 3, 2, 1, 7, 14, 26, 39, and 58.

Figure 1: Rod and subchannel positions and numbering adopted for the Toshiba 37-pin benchmark. (a) Position and numbering of the heated pins with the subchannel center indicated with red dots. (b) Center position and numbering of the suchannels.

The characteristics of Toshiba's benchmark are provided in Table 1.

Table 1: Design and operational parameters for Toshiba's 37-pin benchmark.

Experiment Parameter (unit)Value
Number of pins (-)
Rod Pitch (cm)
Rod Diameter (cm)
Wire wrap diameter (cm)
Wire wrap axial pitch (cm)
Flat-to-flat duct distance (cm)
Inlet length (cm)-
Heated length (cm)
Outlet length (cm)-
Outlet pressure (Pa)
Inlet Temperature (K)Experiment dependent
Power profile (-)Chopped cosine (peaking factor )

Three flow configurations with reducing axial mass flow rate are selected for the validation exercise. These configurations are presented in Table 2.

Table 2: Validation cases selected in the Toshiba benchmark

NamingRun IDRod Power (W/cm)Inlet temperature ()Flow rate (m/s)Reynolds number
High flow rate
Medium flow rate
Low flow rate

SCM Input

General Parameters

The general parameters on the experimental conditions are described here below. They set up the boundary conditions for the high-flow-rate test case.



 T_in = 660
# [1e+6 kg/m^2-hour] turns into kg/m^2-sec
mass_flux_in = ${fparse 1e+6 * 37.00 / 36000.*0.5}
P_out = 2.0e5 # Pa

Mesh

The meshing in SCM uses a custom SCMTriSubChannelMeshGenerator. This one generates a mesh of 1D channel segments connected in 3D. The subchannel positions are automatically generated by specifying the number of radial rings, the flat to flat distance of the duct, and the pin pitch. The number of axial cells in which the domain is discretrized is specified by n_cells. For more information about the mesh generator, pelase consult the website documentation on SCM.

[TriSubChannelMesh]
  [subchannel]
    type = SCMTriSubChannelMeshGenerator
    nrings = 4
    n_cells = 20
    flat_to_flat = 0.085
    heated_length = 1.0
    pin_diameter = 0.01
    pitch = 0.012
    dwire = 0.002
    hwire = 0.0833
    spacer_z = '0 0.2 0.4 0.6 0.8'
    spacer_k = '0.1 0.1 0.1 0.1 0.10'
  []
[]
(modules/subchannel/validation/Toshiba_37_pin/toshiba_37_pin.i)

Variables

This block defines the subchannel variables for the SCM solve. All variables must be present at every input for the SCM solver to run.

[AuxVariables<<<{"href": "../../../syntax/AuxVariables/index.html"}>>>]
  [mdot]
  []
  [SumWij]
  []
  [P]
  []
  [DP]
  []
  [h]
  []
  [T]
  []
  [rho]
  []
  [S]
  []
  [w_perim]
  []
  [q_prime]
  []
  [mu]
  []
  [displacement]
  []
[]
(modules/subchannel/validation/Toshiba_37_pin/toshiba_37_pin.i)

FluidProperties

The FluidProperties block specifies the thermophysical properties used in the SCM solve. Sodium properties are used in this case.

[FluidProperties<<<{"href": "../../../syntax/FluidProperties/index.html"}>>>]
  [sodium]
    type = PBSodiumFluidProperties<<<{"description": "Class that provides the methods that realize the equations of state for Liquid Sodium", "href": "../../../source/fluidproperties/PBSodiumFluidProperties.html"}>>>
  []
[]
(modules/subchannel/validation/Toshiba_37_pin/toshiba_37_pin.i)

Problem

The problem type specifies the solver to be used in the SCM solve. The type of problem used in this case is a liquid metal SCM problem that uses sodium fluid properties. The parameters beta and C_T are used are used to model the crossflow and cross enthalpy-fluxes. Different solve procedures can be applied. In this case, we use an implicit, non-segragated solve. For more information about the mesh generator, pelase consult the website documentation on SCM.

[Problem<<<{"href": "../../../syntax/Problem/index.html"}>>>]
  type = TriSubChannel1PhaseProblem
  fp = sodium
  n_blocks = 1
  P_out = 2.0e5
  CT = 1.0
  compute_density = true
  compute_viscosity = true
  compute_power = true
  P_tol = 1.0e-6
  T_tol = 1.0e-3
  implicit = true
  segregated = false
  staggered_pressure = false
  monolithic_thermal = false
  verbose_multiapps = true
  verbose_subchannel = false
[]
(modules/subchannel/validation/Toshiba_37_pin/toshiba_37_pin.i)

Initial Conditions

This block specifies the initial conditions for the AuxVariables utilized in the SCM solve. The linear heat flux initialization requires an external file that defines the relative power per fuel pin. In this case, this file is name "pin_power_profile_37.txt"

[ICs<<<{"href": "../../../syntax/ICs/index.html"}>>>]
  [S_IC]
    type = SCMTriFlowAreaIC<<<{"description": "Computes flow area of subchannels in a triangular lattice arrangement", "href": "../../../source/ics/SCMTriFlowAreaIC.html"}>>>
    variable<<<{"description": "The variable this initial condition is supposed to provide values for."}>>> = S
  []

  [w_perim_IC]
    type = SCMTriWettedPerimIC<<<{"description": "Computes wetted perimeter of subchannels in a triangular lattice arrangement", "href": "../../../source/ics/SCMTriWettedPerimIC.html"}>>>
    variable<<<{"description": "The variable this initial condition is supposed to provide values for."}>>> = w_perim
  []

  [q_prime_IC]
    type = SCMTriPowerIC<<<{"description": "Computes axial power rate (W/m) that goes into the subchannel cells or is assigned to the fuel pins, in a triangular lattice arrangement", "href": "../../../source/ics/SCMTriPowerIC.html"}>>>
    variable<<<{"description": "The variable this initial condition is supposed to provide values for."}>>> = q_prime
    power<<<{"description": "The postprocessor or Real to use for the total power of the subassembly [W]"}>>> = 1.000e5 # W
    filename<<<{"description": "name of radial power profile .txt file (should be a single column) [UnitLess]."}>>> = "pin_power_profile_37.txt"
  []

  [T_ic]
    type = ConstantIC<<<{"description": "Sets a constant field value.", "href": "../../../source/ics/ConstantIC.html"}>>>
    variable<<<{"description": "The variable this initial condition is supposed to provide values for."}>>> = T
    value<<<{"description": "The value to be set in IC"}>>> = ${T_in}
  []

  [P_ic]
    type = ConstantIC<<<{"description": "Sets a constant field value.", "href": "../../../source/ics/ConstantIC.html"}>>>
    variable<<<{"description": "The variable this initial condition is supposed to provide values for."}>>> = P
    value<<<{"description": "The value to be set in IC"}>>> = 0.0
  []

  [DP_ic]
    type = ConstantIC<<<{"description": "Sets a constant field value.", "href": "../../../source/ics/ConstantIC.html"}>>>
    variable<<<{"description": "The variable this initial condition is supposed to provide values for."}>>> = DP
    value<<<{"description": "The value to be set in IC"}>>> = 0.0
  []
  [Viscosity_ic]
    type = ViscosityIC<<<{"description": "Computes viscosity from specified pressure and temperature", "href": "../../../source/ics/ViscosityIC.html"}>>>
    variable<<<{"description": "The variable this initial condition is supposed to provide values for."}>>> = mu
    p<<<{"description": "Pressure [Pa]"}>>> = ${P_out}
    T<<<{"description": "Temperature [K]"}>>> = T
    fp<<<{"description": "Fluid properties user object name"}>>> = sodium
  []

  [rho_ic]
    type = RhoFromPressureTemperatureIC<<<{"description": "Computes the density from pressure and temperature.", "href": "../../../source/ics/RhoFromPressureTemperatureIC.html"}>>>
    variable<<<{"description": "The variable this initial condition is supposed to provide values for."}>>> = rho
    p<<<{"description": "The pressure [Pa]"}>>> = ${P_out}
    T<<<{"description": "The temperature [K]"}>>> = T
    fp<<<{"description": "The name of fluid properties user object."}>>> = sodium
  []

  [h_ic]
    type = SpecificEnthalpyFromPressureTemperatureIC<<<{"description": "Computes the specific enthalpy from pressure and temperature.", "href": "../../../source/ics/SpecificEnthalpyFromPressureTemperatureIC.html"}>>>
    variable<<<{"description": "The variable this initial condition is supposed to provide values for."}>>> = h
    p<<<{"description": "The pressure [Pa]"}>>> = ${P_out}
    T<<<{"description": "The temperature [K]"}>>> = T
    fp<<<{"description": "The name of fluid properties user object."}>>> = sodium
  []

  [mdot_ic]
    type = ConstantIC<<<{"description": "Sets a constant field value.", "href": "../../../source/ics/ConstantIC.html"}>>>
    variable<<<{"description": "The variable this initial condition is supposed to provide values for."}>>> = mdot
    value<<<{"description": "The value to be set in IC"}>>> = 0.0
  []
[]
(modules/subchannel/validation/Toshiba_37_pin/toshiba_37_pin.i)

Auxiliary Kernels

Auxiliary kernels are used to apply the boundary conditions on pressure, temperature, and mass flow rate.

[AuxKernels<<<{"href": "../../../syntax/AuxKernels/index.html"}>>>]
  [T_in_bc]
    type = ConstantAux<<<{"description": "Creates a constant field in the domain.", "href": "../../../source/auxkernels/ConstantAux.html"}>>>
    variable<<<{"description": "The name of the variable that this object applies to"}>>> = T
    boundary<<<{"description": "The list of boundaries (ids or names) from the mesh where this object applies"}>>> = inlet
    value<<<{"description": "Some constant value that can be read from the input file"}>>> = ${T_in}
    execute_on<<<{"description": "The list of flag(s) indicating when this object should be executed. For a description of each flag, see https://mooseframework.inl.gov/source/interfaces/SetupInterface.html."}>>> = 'timestep_begin'
  []
  [mdot_in_bc]
    type = SCMMassFlowRateAux<<<{"description": "Computes mass flow rate from specified mass flux and subchannel cross-sectional area. Can read either PostprocessorValue or Real", "href": "../../../source/auxkernels/SCMMassFlowRateAux.html"}>>>
    variable<<<{"description": "The name of the variable that this object applies to"}>>> = mdot
    boundary<<<{"description": "The list of boundaries (ids or names) from the mesh where this object applies"}>>> = inlet
    area<<<{"description": "Cross sectional area [m^2]"}>>> = S
    mass_flux<<<{"description": "The postprocessor or Real to use for the value of mass_flux"}>>> = ${mass_flux_in}
    execute_on<<<{"description": "The list of flag(s) indicating when this object should be executed. For a description of each flag, see https://mooseframework.inl.gov/source/interfaces/SetupInterface.html."}>>> = 'timestep_begin'
  []
[]
(modules/subchannel/validation/Toshiba_37_pin/toshiba_37_pin.i)

Executioner

The executioner can be Steady or Transient. The tolerances are not used in the SCM problem.

[Executioner<<<{"href": "../../../syntax/Executioner/index.html"}>>>]
  type = Steady
[]
(modules/subchannel/validation/Toshiba_37_pin/toshiba_37_pin.i)

MultiApp system

A MultiApp is used for transfering the SCM solution into a detailed mesh.

[MultiApps<<<{"href": "../../../syntax/MultiApps/index.html"}>>>]
  [viz]
    type = FullSolveMultiApp<<<{"description": "Performs a complete simulation during each execution.", "href": "../../../source/multiapps/FullSolveMultiApp.html"}>>>
    input_files<<<{"description": "The input file for each App.  If this parameter only contains one input file it will be used for all of the Apps.  When using 'positions_from_file' it is also admissable to provide one input_file per file."}>>> = "toshiba_37_pin_viz.i"
    execute_on<<<{"description": "The list of flag(s) indicating when this object should be executed. For a description of each flag, see https://mooseframework.inl.gov/source/interfaces/SetupInterface.html."}>>> = "timestep_end"
  []
[]
(modules/subchannel/validation/Toshiba_37_pin/toshiba_37_pin.i)

A custom transfer, MultiAppDetailedSolutionTransfer, is used for this purpose.

[Transfers<<<{"href": "../../../syntax/Transfers/index.html"}>>>]
  [xfer]
    type = SCMSolutionTransfer<<<{"description": "Transfers subchannel solution from computational mesh onto visualization mesh", "href": "../../../source/transfers/SCMSolutionTransfer.html"}>>>
    to_multi_app<<<{"description": "The name of the MultiApp to transfer the data to"}>>> = viz
    variable<<<{"description": "The auxiliary variables to transfer."}>>> = 'mdot SumWij P DP h T rho mu q_prime S'
  []
[]
(modules/subchannel/validation/Toshiba_37_pin/toshiba_37_pin.i)

The detailed mesh uses a SCMDetailedTriSubChannelMeshGenerator and the solution variables are populated by the transfer.

[MultiApps<<<{"href": "../../../syntax/MultiApps/index.html"}>>>]
  [viz]
    type = FullSolveMultiApp<<<{"description": "Performs a complete simulation during each execution.", "href": "../../../source/multiapps/FullSolveMultiApp.html"}>>>
    input_files<<<{"description": "The input file for each App.  If this parameter only contains one input file it will be used for all of the Apps.  When using 'positions_from_file' it is also admissable to provide one input_file per file."}>>> = "toshiba_37_pin_viz.i"
    execute_on<<<{"description": "The list of flag(s) indicating when this object should be executed. For a description of each flag, see https://mooseframework.inl.gov/source/interfaces/SetupInterface.html."}>>> = "timestep_end"
  []
[]
(modules/subchannel/validation/Toshiba_37_pin/toshiba_37_pin.i)

Results

An example flow distribution for the high flow-rate case is depicted in Figure 2. As graphically observed, a flat temperature profile is obtained in the bulk of the fuel assembly. In this experiment, the ratio of gap-distance to pitch produces a significantly larger mass flow in the outer subchannels as observed in Figure 2a. This causes the outer subchannnels to be significantly colder than the center ones. Thus, the expected temperature distribution is a flat distribution in the central region of the assembly with sharp drops next to the wrapper. Finally, it can be observed in Figures 2a and 2b that due to the significant difference between flow rates at the outer and center subchannel, there is a considerable flow development length in the entry to the fuel assembly. Inlet velocity conditions were unclear in the experiment report (Namekawa et al., 1984) and, hence, uniform mass flow at the inlet was assumed. If the assumption of uniform inlet flow rates turns out to be incorrect, a small deterioration of accuracy of the predicted outlet temperature can be expected. However, we observe that the flow rates fully develop before the outlet of the assembly, which suggests that this initial condition will have little effect over the analyzed temperature distribution at the outlet of the fuel assembly.

Figure 2: Example of simulation results for the high-flow test case in the Toshiba 37-pin benchmark. (a) Distribution of axial mass flow. (b) Distribution of lateral mass flow. (c) Distribution of temperature. (d) Distribution of dynamic viscosity due to heating.

The results obtained for the high-, medium-, and low-flow-rate validation cases are presented in Figure 3. We compare the results obtained with the present code with the ones obtained in the experiments and the SUBAC code (Sun et al., 2018). We have selected SUBAC for the code-to-code comparison since it is to our knowledge the subchannel code for wire-wrapped SFRs, with openly available results, that presented the best agreements between the code predictions and the experiment measurements for the current benchmark.

Figure 3: Comparison of results obtained for Toshiba 37-pin case between experimental measurements, the SUBAC code, and the current code. (a) High mass flow case. (b) Medium mass flow case. (c) Low mass flow case.

As observed in Figure 3, for the high mass flow rate case, the present model predicts results closer to the experimental results than SUBAC. This is expected, since the turbulent cross-flow calibration should still improve the prediction for the present case. However, when comparing the results predicted for the medium- and low-flow-rate cases in Figures 3b and 3c, respectively, we observe that our models over-predict the temperature distributions when compared to SUBAC. Further analysis determined that the more peaked distribution of temperatures predicted by SCM towards the center of the assembly may be produced by an over-prediction of the mixing rates, which yields larger than expected flows in the outer channels.

References

  1. F Namekawa, A Ito, and K Mawatari. Buoyancy effects on wire-wrapped pin bundle heat transfer in an lmfbr fuel assembly. In AIChE symposium series, volume 80, 128–133. 1984.[BibTeX]
  2. RL Sun, DL Zhang, Y Liang, MJ Wang, WX Tian, SZ Qiu, and GH Su. Development of a subchannel analysis code for sfr wire-wrapped fuel assemblies. Progress in Nuclear Energy, 104:327–341, 2018.[BibTeX]