MSFR Griffin-Pronghorn Transient Model

Transient kernels

The setup of MOOSE variables, kernels, boundary conditions, etc. is similar to the steady-state model. The only difference is that the fluid flow model is using a Transient executioner instead of a Steady one.

The neutronics model can be made transient by simply switching the parameter equation_type = eigenvalue to equation_type = transient in the TransportSystems block,

[TransportSystems]
  particle = neutron
  equation_type = transient
  restart_transport_system = true

  G = 6

  VacuumBoundary = 'outer'

  [diff]
    scheme = CFEM-Diffusion
    n_delay_groups = 6
    external_dnp_variable = 'dnp'
    family = LAGRANGE
    order = FIRST
    fission_source_aux = true
  []
[]

Initialization

The steady-state model will be re-used here in order to initialize the solution for the transient. The MOOSE Framework provides several different methods for initializing one model with the result of another.

• Exodus restart: A simulation can be "restarted" from an output solution saved in an Exodus file.

• Checkpoint restart: A simulation can also be restarted using MOOSE's custom checkpoint file format.

• Initial MultiApp: A simulation can be run from scratch via the MultiApp system, and the resulting solution can then be transferred over to the main application.

This example will use both the Exodus restart. The fluid dynamics app, in particular, will use the Exodus method. Note that the [Mesh] block references an output file created by the steady-state simulation. (An Exodus file might contain just a mesh, or it might contain a mesh and a set of solution fields.) Also note the parameter, use_for_exodus_restart = true:

[Mesh]
  [restart]
    type = FileMeshGenerator
    use_for_exodus_restart = true
    file = '../steady/restart/run_neutronics_out_ns0_restart.e'
  []
[]

With an Exodus restart, we must also specify which variables will be initialized from the input Exodus file. Here, all of the variables are initialized from Exodus. Note the initial_from_file_var parameters in these variables,

[AuxVariables]
  [power_density]
    type = MooseVariableFVReal
    block = 'fuel pump hx'
    initial_from_file_var = 'power_density'
  []
  [fission_source]
    type = MooseVariableFVReal
    initial_from_file_var = 'fission_source'
  []
[]

The Exodus restart method is desirable because it allows the user to run many transient simulations without having to repeatedly re-initialize the solution. However, the Exodus restart method cannot presently be used with Griffin simulations that use the external_dnp_var feature. (See Griffin issue #177.) As a fall-back, the neutronics solution will instead be initialized via the MultiApp approach.

Like the fluids app, the mesh for the neutronics app will be set using the output of the steady-state simulation. This ensures mesh consistency between the steady and transient simulations.

[Mesh]
  [fmg]
    type = FileMeshGenerator
    # when changing restart file, adapt power_scaling postprocessor
    # if not exactly 3e9 -> initial was not completely converged
    file = '../steady/restart/run_neutronics_restart.e'
    use_for_exodus_restart = true
  []
[]

Pump control

Here the partial loss-of-flow event is modeled by reducing the pump force. This is done through the Control system. The following block will modify the relevant parameter at each time step, and it will evaluate the specified function (pump_fun) to find the desired value:

[Controls]
  [pump_control]
    type = RealFunctionControl
    parameter = 'FVKernels/pump/scaling_factor'
    function = 'pump_fun'
    execute_on = 'initial timestep_begin'
  []
[]

The function is defined elsewhere in the input file as,

[Functions]
  [pump_fun]
    type = PiecewiseConstant
    # Transient starts by pump percent reduction on second line
    xy_data = '0.0 1
               2.0 0.5'
    direction = 'left'
  []
[]

Note that a step function is used here. At , the pumping force instantly drops to half its initial value. Note that a more complex model could be implemented by specifying additional points in the function or by using e.g. a PiecewiseLinear or ParsedFunction instead of PiecewiseConstant.