What is the right way to map the temperature from an external app to the THM

[makeclean]

So, we have a thermo-mechanical problem which has cooling channels running inside of it, we want to use the THM module to model the coolant flow, and ideall pass the solid temperature into the THM SubApp. Its working right now, where we set T_solid to a fixed value inside the THM app, and the temperature is updated correctly, however it isn't clear to me how we should do it properly, I can send the temperature from the parent application with something like;

[MultiApps]
  [thm]
    type = TransientMultiApp
    app_type = ThermalHydraulicsApp
    input_files = 'chimera-thm-steady.i'
    execute_on = 'TIMESTEP_END'
    interpolate_transfers = true
    sub_cycling = true
    max_failures = 10
    detect_steady_state = true
  []
[]

[Transfers]
  [t_to_parent]
    type = MultiAppNearestNodeTransfer
    from_multi_app = thm
    fixed_meshes = true
    source_variable = 'T'
    variable = temp
    target_boundary = 'innerpipe'
  []
  [t_wall_to_child]
    type = MultiAppNearestNodeTransfer
    to_multi_app = thm
    fixed_meshes = true
    source_variable = 'temp'
    variable = 'temp_from_parent'
  []
[]

In the associated SubApp;

  [vel_magnitude]
    type = MooseVariableFVReal
    order = CONSTANT
    family = MONOMIAL
  []
  [temp_from_parent]
    order = FIRST
    family = LAGRANGE
  []
[]

[Functions]
  [t_wall_mat]
    type = ParsedFunction
    expression = 'temp'
    symbol_names = 'temp'
    symbol_values = 'temp_from_parent'
  []
[]

One of the issues, is using a LAGRANGE variable then the temp_from_parent variable isn't a SCALAR variable and thus the SubApp isn't happy.

What is the correct way for one to transfer the temperature data from the boundary which surrounds a set of pipes, to the pipes themselves. The structure and pipes can be seen in the below figure, in the example below the temperature is solved, and then the THM solve happens, and the Temperature, T, is passed back to the main app.

[makeclean]

I did try it with HeatStructureFromFile3D and HeatTransferFromHeatStructure3D1Phase however the coolant channels don't quite line up along a cartesian axis, out of curiosity, does anyone know why thats a requirement? Maybe @joshuahansel ?

[joshuahansel]

Under the hood, we use NearestPointLayeredSideAverage to make the azimuthal averages to correspond to the 1D channel elements. The family of layered average UOs all use this x-y-or-z assumption. I think this was just for ease of implementation. I don't think there is a technical barrier to extending these UOs to allow an arbitrary axis.

I'll answer your other question too shortly.

[GiudGiud]

MeshDivisions might help if you're looking for arbitrary spatial cuts

[joshuahansel]

Do you mean it would help generalize the layered average UOs?

[GiudGiud]

yeah. A mesh division can define any arbritrary region and you can average over these regions. So bent pipe, twisted, anything, can be written into the mesh division and the UO retrieves the index of the bin to perform the average.

The UO:
https://mooseframework.inl.gov/source/vectorpostprocessors/MeshDivisionFunctorReductionVectorPostprocessor.html

For example this binned mesh division can take any functor so really any function of X Y and Z!
https://mooseframework.inl.gov/source/meshdivisions/FunctorBinnedValuesDivision.html

[GiudGiud]

I think the CylindricalGridDivision can do a non-aligned axis already?

[joshuahansel]

Based on my recent experience, for a thermal coupling, I recommend this general strategy:

• compute and apply heat flux in the parent app
• transfer flux to THM
• transfer temperature from THM

I do not recommend using MultiAppNearestNodeTransfer as you have done because I think you might end up coupling to a random-ish node for each 1D channel element (whichever node around the hole happens to be closest). I would use MultiAppGeneralFieldUserObjectTransfer instead, with the UO being one of those layered average ones; however, I think you'll have the same problem you mentioned above (needing to be aligned with x, y, or z).

I might need some help on the recommendation here @GiudGiud.

[jvwilliams23]

I am not sure about that. If we do something similar to LayeredSideDiffusiveFluxAverage, it will just send the flux value averaged over the entire boundary, no?
In the figure in @makeclean's original post, we will have multiple connected flow channels (sorry, i should have mentioned this). Each one will need the flux only of the nearest faces on the boundary. Otherwise, LayeredSideDiffusiveFluxAverage will account for faces in a completely different part of the domain (but still part of the innerpipe boundary).

Pretty much want I want is an aux field that is 0 everywhere except the innerpipe boundary, where I then just have $n \cdot k \nabla T$.
The average of the nearby elements (on the parent app) will then computed within MultiAppGeneralFieldNearestLocationTransfer and sent to our THM like so:

#parent app
[Transfers]
  [temp_from_parent_to_child]
    type = MultiAppGeneralFieldNearestLocationTransferWithDistanceWeightedAverage
    # type = MultiAppGeneralFieldNearestLocationTransfer
    to_multi_app = flow_channel
    distance_weighted_average = true
    source_variable = temp 
    from_boundaries = "innerpipe"
    variable = q_wall 
    num_nearest_points = 200
  []
[]

#THM app 
[Components]
  [hxconn]
    type = HeatTransferFromExternalAppHeatFlux1Phase
    flow_channel = pipe1
    Hw = water-htc-function
    P_hf = 0.1
  []
[]

[jvwilliams23]

I think what I was looking for was DiffusionAuxFlux, found in CARDINAL examples.

[AuxVariables]
  [aux_flux]
    family = MONOMIAL
    order = CONSTANT
  []
[]
 
[AuxKernels]
  [aux_flux]
    type = DiffusionFluxAux
    diffusion_variable = temp
    component = normal
    diffusivity = thermal_conductivity
    variable = aux_flux
    boundary = '1'
  []
[]

[GiudGiud]

I am not sure about that. If we do something similar to LayeredSideDiffusiveFluxAverage, it will just send the flux value averaged over the entire boundary, no?

no it can do layers. It s not the entire integral.

Averaging k grad_T seems dangerous to me.

I would do (to work on sending 3D data to the 1D data if you cannot just evaluate the shape function)

• create a 1D mesh in the 3D domain that is NOT used by the solver
• use the save_in feature on that 1D mesh to keep it in memory
• create a new object: 1DMeshCylindricalEnvellopeDivision that follows the 1D mesh everywhere and forms regularly divided cylindrical regions around the 1D elements (so if the 1D mesh turns, so does the division)
• either use the VPP i mentioned to do the averages / integrals / other reductions in the 3D domain based on the division
• OR create a new VPP that does the surface integration instead, but cutting regions based on the division (I think this is more what you want)
• use the UO transfer

[jvwilliams23]

Thanks @GiudGiud. Quick question, do you think this would work for 1D meshes that have several branches like bifurcations, trifurcations, etc?

[GiudGiud]

Well, we ll have to figure out how to handle the overlapping cylinders/tubes around the 1D elements (even for a T junction).

My thinking is that we will just do 'nearest element' so effectively cuttting at a 45 degree angle for a T junction

[makeclean]

To further muddy the waters, I was looking into the code for HeatTransferFromHeatStructure3D1Phase and it looks like it also has the requirement that all the channels run in the same direction, have the same number of elements, and have the same length - that would definitely not the case here. Does that fall into what you said before, just for the ease of the initial implementation?

[joshuahansel]

Also, the 3D side must have its divisions match up 1-to-1 with the channel divisions.

The implementation is restrictive because it covers the most common setups, and a more general implementation was not worth the development time, given other priorities. If you have a good idea of how the most general case could work in terms of formulation, then it should be doable. Considerations we want to make are things like ensuring that energy is conserved across the transfer and avoiding spurious discretization artifacts.

[jvwilliams23]

@makeclean @joshuahansel I have been thinking of a way to do this for a little bit. Maybe this is a useful jumping off point:

The tricky part of this seems to be mapping the heat flux to THM. If we find something like the maximal inscribed sphere at each node (or element centroid) on the THM, we have a way to find the faces that will contribute heat flux to each THM element (we dilate the sphere a bit to ensure the relevant boundary nodes are contained within the sphere). We then find the weighted mean flux and assign this to the THM element (in a similar way that HeatTransferFromHeatFlux will assign a uniform heat flux to the flow channel).

This is related to finding the centerline/medial axis of a complex geometry (see VMTK documentation).

Does it sound like it would work?

[GiudGiud]

Not a bad idea, but I dont want more people using n-nearest-node with the issue I mentioned so I m not that keen on improving it.

[joshuahansel]

What do you think people should be using in this situation?

[GiudGiud]

[t_wall_to_child]
is the 3D domain overlapping the 1D domain? If so, shape evaluation.
If not, layered average UO but with a custom spatial averaging that follows the pipe. Has not been done but it would be doable with a custom MeshDivision and this VPP
https://mooseframework.inl.gov/source/vectorpostprocessors/MeshDivisionFunctorReductionVectorPostprocessor.html

[t_to_parent]
how big does the target domain have to be? just the cells overlapping? Or should it extrapolate

[GiudGiud]

Just curious if you ended up looking at using a mesh division to do that mapping @jvwilliams23

[jvwilliams23]

Not yet. We stuck with the distance-weighted N nearest-neighbors for now.