Replace flux transfer in HPMR

[aprilnovak]

The MRAD case currently transfers heat flux from Bison to Sockeye using a nearest node transfer.

This transfer is super slow, and could easily be replaced by a UO transfer. The existing files (i) compute heat flux as a UO and then (ii) convert it into an auxvariable, finally to pass (iii) that auxvariable. The conversion and the very slow nodal-based transfer can be replaced.

Furthermore, by transferring the UO directly, we don't need to manually normalize the flux - the value sent to Sockeye is simply used as-is. The current input files are brittle if one is to change the underlying meshes, since the user would need to be careful to modify the preamble lines at the top of the Bison file.

I also believe there was a minor correction to make in the Sockeye mesh settings - the length of the evaporator is 180, which when divided by 3 equals 60 (not 50). This necessitated a re-gold of the Sockeye standalone test, but which had only very minor differences due to the slightly finer mesh (~1e-5 relative).

[moosebuild]

Job VTB Documentation on 70431b4 wanted to post the following:

View the site here

This comment will be updated on new commits.

[GiudGiud]

Thanks for the patch!
@miaoyinb for awareness.

I ll do the rebase to consolidate with the other PR.

With these changes I think we can consider doing CI on the full multiphysics model in the regular suite. I'll re-assess that.

[miaoyinb]

@aprilnovak Thanks for the patch. I was wondering why normalization (polygonization correction) is not needed for the UO transfer approach. Thanks.

[aprilnovak]

I think a normalization is not required because the Sockeye meshes are 1-D. The "area" with which they multiply the incoming heat flux (to get power) is exact.

[miaoyinb]

I think a normalization is not required because the Sockeye meshes are 1-D. The "area" with which they multiply the incoming heat flux (to get power) is exact.

The Sockeye mesh is 2D-RZ in this case. But you are right that the related calculation in Sockeye is exact.

But the BISON mesh is 3D and the heat pipe is a polygon instead of a perfect circle. That polygon size is also "modified" to preserve volume. The original normalization was meant to correct this difference between the polygonized circles in the 3D mesh and the "idealized" circles in the 2D-RZ mesh.

[aprilnovak]

Thanks, yes I meant 2D-RZ.

Are you saying that the surface area of the cylinders in the BISON mesh does not converge to pi * diameter * H if you were to refine the mesh? (due to some modifications from volume adjustments?)

If that is the case, I'd suggest we add a conservative transfer (to preserve power in BISON and power received in Sockeye) rather than this by-hand modification.

[miaoyinb]

Thanks, yes I meant 2D-RZ.

Are you saying that the surface area of the cylinders in the BISON mesh does not converge to pi * diameter * H if you were to refine the mesh? (due to some modifications from volume adjustments?)

If that is the case, I'd suggest we add a conservative transfer (to preserve power in BISON and power received in Sockeye) rather than this by-hand modification.

It converges to the correct value as the 3D mesh becomes finer and finer. But if the 3D mesh is not infinitely fine, we need this correction factor.

Basically it makes raw_flux * polygon_perimeter = corrected_flux * ideal_circular_perimeter for every z-plane.

[aprilnovak]

I don't think you need the correction factor. You could add this to the flux transfer in the BISON input files instead, and it would re-normalize the heat flux such that the power in the sub-app is identical once accounting for different cylinder areas.

    from_postprocessors_to_be_preserved = 'hp_heat_integral'
    to_postprocessors_to_be_preserved = 'A_int_master_flux'

That power (flux * polygonized cylinder area) may not be exactly identical to the power in the Griffin model, but it never would be with finite elements, because flux conservation is not guaranteed.

[miaoyinb]

I don't think you need the correction factor. You could add this to the flux transfer in the BISON input files instead, and it would re-normalize the heat flux such that the power in the sub-app is identical once accounting for different cylinder areas.

    from_postprocessors_to_be_preserved = 'hp_heat_integral'
    to_postprocessors_to_be_preserved = 'A_int_master_flux'

That power (flux * polygonized cylinder area) may not be exactly identical to the power in the Griffin model, but it never would be with finite elements, because flux conservation is not guaranteed.

I think this will work, thanks.

[aprilnovak]

I'll test this out locally just to be sure, and then I'll update this PR with those changes. Thanks for the discussion.

[aprilnovak]

I actually do not think I can accomplish what I was proposing. For this to work, I need to have a vector postprocessor which computes 192 heat flux values (one on each heat pipe surface sideset). But the only viable option in MOOSE is the NearestPointIntegralVariablePostprocessor, which does not have the correct side restriction I need for heat flux. If I were to use that vector pp, it'd be averaging a bunch of zero values into the quantities sent to my 192 sub-apps (right?)

@zachmprince can you confirm if my understanding is correct? git blame shows that you wrote most of the MultiAppConservativeTransfer, so hoping you can double-check my reasoning :)

[GiudGiud]

We ll want to add our conclusions on this discussion there after
idaholab/moose#23334

[GiudGiud]

I think we can do this now, with an arbitrary MeshDivision object. Then use the VPP-based conservative transfer option with the MeshDivisionFunctorReductionVPP