Surface-to-surface radiation with PIMPLE + Linear FV + CHT

[PengWei97]

Check these boxes if you have followed the posting rules.

• Q&A General is the most appropriate section for my question
• I have consulted the posting Guidelines on the Discussions front page
• I have searched the Discussions forum and my question has not been asked before
• I have searched the MOOSE website and the documentation does not answer my question
• I have formatted my post following the posting guidelines (screenshots as a last resort, triple back quotes around pasted text)

Question

Hi all,

I have a working conjugate heat transfer case based on:

• PIMPLE (transient)
• Linear FV (for flow + energy)
• CHT coupling

The main input file is: phase2_single_wafer_cht_heatflux.i

All fluid variables (u, v, p, T_fluid) and also the solid temperature are currently defined as: MooseLinearVariableFVReal.

Goal

I want to extend this setup to include surface-to-surface radiation inside the cavity (view factor / radiosity approach).

Issue

From the documentation, the standard S2S radiation workflow is:

• GrayLambertNeumannBC
• ConstantViewFactorSurfaceRadiation (or ViewFactorObjectSurfaceRadiation)
• UnobstructedPlanarViewFactor

However:

• GrayLambertNeumannBC belongs to the standard BCs system
• It expects a nonlinear (FE-style) temperature variable
• My current workflow uses Linear FV temperature variables

Also, the available Linear FV radiation BC: LinearFVFunctorRadiativeBC

only supports boundary-to-ambient radiation $ \sigma \epsilon (T^4 - T_\infty^4) $, not surface-to-surface radiation.

Question

What is the recommended way to include view-factor-based S2S radiation in a:

PIMPLE + Linear FV + CHT workflow?

Possible approaches I’m considering

Option 1: Mixed approach

• Keep fluid: Linear FV + PIMPLE
• Possibly switch solid temperature to FE
• Use existing Gray-Lambert + view factor infrastructure

Concern:

• Not sure how robust/clean the CHT coupling is in a mixed FV–FE setup

Option 2: Extend Linear FV radiation support

Implement something like: LinearFVGrayLambertNeumannBC

Idea: keep existing view-factor / radiosity infrastructure and only add a Linear FV boundary condition to apply radiative heat flux

Questions:
Is this the right missing piece?
Would this be a relatively small extension, or does it require deeper changes?

Would existing objects like: ConstantViewFactorSurfaceRadiation and UnobstructedPlanarViewFactor, work directly with such a BC?

Key clarification

My use case is strictly: surface-to-surface radiation inside a pipe (not radiation to ambient)

Any guidance on the recommended direction would be greatly appreciated.

Thanks!

[GiudGiud]

Hi @PengWei97

S2S for linearFV is under development and currently in this branch
https://github.com/freiler/moose/tree/s2s_linearfv

Feel free to rebase it on devel, to try it out though no guarantees on its performance or results for now

[PengWei97]

Great, thank you. It appears this is already a viable version that doesn't require me to create any additional objects. I'll give it a try tomorrow—thanks again.

Also, do you happen to have any other supplementary resources or advice you could share to help me complete this testing more effectively and efficiently tomorrow?

[GiudGiud]

I'd try to find either benchmarks or analytical solutions to reproduce with surface-2-surface radiations.
I imagine two infinite plates then two nested infinite cylinder (approximated as finite) would be a good start

[PengWei97]

Hi @GiudGiud, I encountered a related issue when extending my CHT case.

I have two input files:

• s4a_single_wafer_cht_heatflux_quartz_tube_rad.i (baseline, no subdomain split/merge)
• s4b_single_wafer_cht_heatflux_quartz_tube_rad.i (with subdomain split → merge → interface reconstruction, to prepare for radiation)

Behavior

For s4a_xx:

• wafer temperature evolves correctly
• the simulation runs without issues

For s4b_xx:

• Wafer temperature remains constant at 0
• however, when running to ~ t ≈ 0.24, the simulation crashes with PETSc error:

[6]PETSC ERROR: --------------------- Error Message --------------------------------------------------------------
[6]PETSC ERROR: Argument out of range
[6]PETSC ERROR: Current value inf. greater than allowed bound 1.79769e+308
[6]PETSC ERROR: WARNING! There are unused option(s) set! Could be the program crashed before usage or a spelling mistake, etc!
[6]PETSC ERROR:   Option left: name:--snes_linesearch_type value: basic source: code
[6]PETSC ERROR:   Option left: name:--snes_monitor_cancel (no value) source: code
[6]PETSC ERROR:   Option left: name:--snes_type value: ksponly source: code
[6]PETSC ERROR:   Option left: name:-i value: s4b_single_wafer_cht_heatflux_quartz_tube_rad.i source: command line
[6]PETSC ERROR: [7]PETSC ERROR: --------------------- Error Message --------------------------------------------------------------
[7]PETSC ERROR: Argument out of range
[7]PETSC ERROR: Current value inf. greater than allowed bound 1.79769e+308
[7]PETSC ERROR: WARNING! There are unused option(s) set! Could be the program crashed before usage or a spelling mistake, etc!
[7]PETSC ERROR:   Option left: name:--snes_linesearch_type value: basic source: code
[7]PETSC ERROR:   Option left: name:--snes_monitor_cancel (no value) source: code
[7]PETSC ERROR:   Option left: name:--snes_type value: ksponly source: code
[7]PETSC ERROR:   Option left: name:-i value: s4b_single_wafer_cht_heatflux_quartz_tube_rad.i source: command line
[7]PETSC ERROR: See https://petsc.org/release/faq/ for trouble shooting.
[7]PETSC ERROR: PETSc Release Version 3.24.5, unknown

(full log omitted for brevity, but it is a typical inf blow-up in SNES)

---

What I changed in s4b

Compared to s4a:

1. Split domains into multiple subdomains (fluid and solids)

2. Created fine-grained interfaces (for future radiation):

   • wafer_top_interface
   • wafer_bottom_interface
   • wafer_lr_interface
   • etc.

3. Merged subdomains back using SubdomainIDGenerator

4. Reconstructed global interfaces:

primary_block = 1
paired_block  = 2
new_boundary  = wafer_interface

Important notes

• I intentionally use the merged interface (wafer_interface) for CHT:

  boundary = wafer_interface
  

  to keep the CHT setup simple and consistent

• I verified the Exodus output:

  • blocks are correct
  • reconstructed interfaces exist and look geometrically correct

• The solution behaves normally at early time, then diverges to inf

Question

Is this kind of instability expected when using:

• SubdomainIDGenerator (merge)
• followed by InterfaceBoundaryGenerator
• with Linear FV + PIMPLE + LinearFVRobinCHTBC

Specifically:

• could the reconstructed interface (wafer_interface) lead to duplicated / inconsistent faces internally?
• or non-conservative flux transfer across the interface?

---

Additional context

If I instead apply CHT directly to the fine-grained interfaces:

boundary = 'wafer_top_interface wafer_bottom_interface wafer_lr_interface'

the simulation appears more stable.

However, I would prefer to use the merged wafer_interface to keep the setup cleaner.

Any suggestions on the correct workflow for:

split → merge → reconstruct interface (for radiation + CHT)

would be greatly appreciated.

[GiudGiud]

Hello

It seems you use SideSetsBetweenSubdomainsGenerator not InterfaceBoundaryGenerator ?

could the reconstructed interface (wafer_interface) lead to duplicated / inconsistent faces internally?

and using SideSetsBetweenSubdomainsGenerator I dont think we can have duplciated or inconsistent faces

or non-conservative flux transfer across the interface?

You might want to check the fluxes with
https://mooseframework.inl.gov/source/postprocessors/BoundaryLinearFVFluxIntegral.html

I think the issue you are hitting is that LinearFV only supports 1 boundary per side at this time.
So you need to be careful to only cover each element side with a single boundary.

We will lift this limitation partially in the future
If you run with the dbg or devel executable you should get an error about this

[PengWei97]

Thanks for the clarification — that helped a lot.

I followed your suggestion and checked the boundary setup more carefully. It turns out the issue is indeed related to the LinearFV limitation that each element side can only belong to one boundary.

In my case, I was reconstructing a merged interface (wafer_interface / tube_interface) while still keeping the fine-grained interfaces (e.g. wafer_top_interface, etc.), which likely caused overlapping boundaries on the same sides.

I have now switched to using only the split interfaces:

wafer_lr_interface
wafer_top_interface
wafer_bottom_interface
tube_top_interface
tube_bottom_interface

and applied CHT BCs one-to-one on each interface.

With this setup, the case runs stably (both in serial and parallel), and the previous PETSc inf blow-up is gone.

I’ll proceed with this approach for now and revisit the merged-interface setup later if needed.

Thanks again for the help!

[PengWei97]

Thanks for the clarification.

I tried enabling radiation on top of my existing Linear FV CHT setup, but when I apply both the radiation BC and the CHT BC on the same interface, I get the following error:

*** ERROR ***
The following occurred in the Executioner of type PIMPLE.

We found multiple or no boundary conditions for solid energy on boundary wafer_lr_interface (ID: 4). Make sure you define exactly one for conjugate heat transfer applications!

If I remove the radiation BC, the case runs normally.

My understanding from GPT's suggestion was:

• keep wafer_interface / tube_interface for CHT
• use split boundaries such as wafer_lr_interface, tube_top_interface, tube_bottom_interface for radiation

But this seems to conflict with the earlier point that, for Linear FV, having two boundary names on the same physical interface can also lead to problems.

So I am a bit confused about the correct way to combine:

1. Linear FV CHT BCs, and
2. surface-to-surface radiation BCs

in the same case.

Should radiation and CHT be applied on the same physical surface in some special way, or is there a recommended workaround for this in the current Linear FV/PIMPLE framework?

I am also attaching my current input file (s5a_xxx.i) for reference.

[GiudGiud]

You have to code a single BC for both heat transfer mechanisms.
LinearFV also only supports one BC per boundary (on top of the previously discussed one boundary per element side)

There should be an example of CHT on the OpenPronghorn website btw.
We have a CHT Robin BC that does diffusion + radiation as well I think that might be a good example