Q_prime transfer issues from conduction to subchannel

[garcs2]

Hello,

I'm using heat conduction to compute the linear heat rate using SCMRZPinQPrimeAux. When I attempt to send q_prime using MultiAppGeneralFieldNearestLocationTransfer I get the following warning:

Transfer is projecting from nearest-centroids to nodes. This is likely causing floating point indetermination in the results because multiple centroids are 'nearest' to a node. Please consider using a ProjectionAux to build a nodal source variable (for example linear Lagrange) before transferring�[39m

In addition to this, I am getting in the SC model that there is no q_prime being passed onto the fuel pins (which I see as the inlet and outlet temperatures are equal to the inlet BC temp). Then, I followed this advice of using a ProjectionAux to send the nodal q_prime to SC, but still get the same issue with no heat being transferred. Currently this is what my AuxVariables, AuxKernels, and MultiApp blocks look like:

[AuxVariables]
    [bison_power_density]
        family = L2_LAGRANGE 
        order = FIRST 
        block = 'Fuel'
        initial_condition = '${pow_dens}' #
    []
    [T_inf]
        initial_condition = '${inlet_T_fluid}'
    []
    [bison_Tfuel]
        block = ${fuel_blocks}
    []

    # [bison_Tref]
    #     block = ${extref_blocks}
    # []
    [bison_norm_power_density]
        family = L2_LAGRANGE
        order = FIRST
        block = 'Fuel'
        #initial_condition = 2.01E+03
    []
    [HTC]
        family = MONOMIAL
        order = CONSTANT
        initial_condition = '${ht_coeff}'
    []
    [q_prime]
        family = MONOMIAL
        order = CONSTANT
    []
    [q_prime_node]
        family = LAGRANGE
        order = FIRST
    []
[]

[AuxKernels]
    [norm_Tfuel]
        type = NormalizationAux
        variable = bison_Tfuel
        source_variable = bison_temp
        normal_factor = 1
        execute_on = 'timestep_begin' #check
    []
    # [norm_Tref]
    #     type = NormalizationAux
    #     variable = bison_Tref
    #     source_variable = bison_temp
    #     normal_factor = 1
    #     execute_on = 'timestep_begin' #check
    # []
    [norm_power_density]
        type = NormalizationAux
        variable = bison_norm_power_density
        source_variable = bison_power_density
        normal_factor = 1#1.2658064684
        execute_on = 'timestep_begin' #check
    []
    # [norm_power_linear]
    #     type = NormalizationAux
    #     variable = q_prime
    #     source_variable = bison_power_density
    #     normal_factor = 1.43410377564#1.2658064684
    #     execute_on = 'timestep_begin' #check
    # []   
    [Qprime]
        type = SCMRZPinQPrimeAux
        component = normal
        diffusion_variable = bison_temp
        diffusivity = thermal_conductivity
        variable = q_prime
        boundary = 'fluid_solid_interface'
        execute_on = 'timestep_begin'
    []
    [q_prime_to_node]
        type = ProjectionAux
        v = q_prime
        variable = q_prime_node
        execute_on = 'timestep_begin'
    []
[]
[MultiApps]
    [sc]
      type = FullSolveMultiApp
      #app_type = ThermalHydraulicsApp
      input_files = '/home/garcsamu/Serpent/SNAP-REACTORS-PRIVATE/snapReactors/reactor_models/Wet_Experiment_Models/standard_conditions/sc_test/sc_core.i'
      execute_on =  timestep_end
      bounding_box_padding = '0.1 0.1 0'
      positions = '0 0 -${multi_app_z_pos}'
    []
  []
  
  [Transfers]
    [Power_to_SC]
        type = MultiAppGeneralFieldNearestLocationTransfer
        to_multi_app = sc
        source_variable = q_prime_node
        variable = q_prime
        to_boundaries = right
    []
    # [Q_prime_avg_to_SC]
    #     type = MultiAppGeneralFieldUserObjectTransfer
    #     to_multi_app = sc
    #     source_user_object = Q_prime_avg
    #     variable = q_prime
    #     error_on_miss = true
    #     search_value_conflicts = false
    #     #to_blocks = fuel_pins
    # []
  []

I've doublechecked that the positioning in the MultiApp transfer is correct, so I'm not sure what the issue would be. I would appreciate any insight onto what the potential problem may be!

[GiudGiud]

hello

try setting greedy_search = true in the transfers
this will make sure it's not a bounding box size problem

did you output both exodus and see that they aligned?
you can get the position offset applied to the child app exodus by setting MultiApps/sc/output_in_position = true

[garcs2]

ah I did not know I could get the exodus to have the offset applied, I will try your recommendations and comment back on this, thank you!

[kyriv1980]

why do you set: to_boundaries = right in your q_prime transfer?

[kyriv1980]

n_blocks is not number of cells. Use n_blocks = 1. That should actually be the default value. I think i should fix that to avoid confusion. Also the number of cells in the mesh should be divisible with the number of blocks. https://mooseframework.inl.gov/modules/subchannel/general/subchannel_theory.html

[kyriv1980]

In general for most cases if not all: Use n_blocks = 1

[garcs2]

Ah okay that makes sense, thank you! Using your advice I now have a standalone SC solution, where I've now just removed the unheated portions and only have the heated length, and now get the same solution as before (meaning I don't have to worry about multiapps positioning). It feels to me as though this is now narrowed down to a transfer issue. Note that I am now transferring a nodal power density from heat conduction to SC:

  [Transfers]
    [flux_to_SC]
        type = MultiAppGeneralFieldNearestLocationTransfer
        to_multi_app = sc
        source_variable = power_dens_node
        variable = q_dens
        from_blocks = 'Fuel'
        to_blocks = fuel_pins
        greedy_search = true
        execute_on = timestep_end
    []
  []

I understand that SC takes in a linear heat rate, not a density, but for the purposes of verifying the transfer works I do see that when I run a NoSolveProblem in the SC subapp, q_dens replicates q_dens from the heat conduction parent app, which I verify via Paraview. However, I notice that q_prime is effectively zero, though I use a NormalizationAux to convert q_dens to q_prime:

  [norm_q_pow]
    type = NormalizationAux
    variable = q_prime
    # source_variable = q_prime
    source_variable = q_dens
    normal_factor = 0.000143410377564 # cross_sectional_area
    execute_on = 'timestep_begin' #check
  [] 

However, when I look at the SC_Viz subapp I do see that q_prime does match the values seen in the SC standalone solution. Thus, it seems the NormalizationAux in SC has executed, and transferred that value to SC_Viz (though sometime after the SC exodus is outputted). Note that the transfer from SC -> SC_Viz is executed on 'FINAL'. Thus my question is the following: what should I set the execute_on parameter of the NormalizationAux for it to be executed after the power density is transferred from heat conduction, but before SC begins its solver routine? timestep_begin, linear and initial don't seem to work as when I run the TriSubChannel1PhaseProblem the solver fails.

[kyriv1980]

• You don't need to remove the unheated parts, just make sure that the size is consistent between the SCM model and the pin model.

• The SC_viz just creates a mesh. The multiapp transfers the values from the SCM solution to that mesh for visualization purposes. That means that you do populate q_prime correctly at some point.

Are both models in transient?

Try to do the normalization in the master/main app. I assume that: power_dens_node gets transfered properly so that will solve your issue?

@GiudGiud do you have inputs?

[garcs2]

It seems that moving the normalization in the main app was the trick so thank you! Both models are in steady state.