Question about conjugate heat transfer examples in MOOSE

[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

Dear MOOSE Team,

I am working on a simulation of an enclosed cavity with a heated solid plate and air, involving both conduction and natural convection (conjugate heat transfer).

I would like to ask whether MOOSE provides any official examples or benchmarks for this type of problem (solid–fluid heat transfer coupling in a cavity).

Any suggestions on modules, coupling strategies, or example input files would be greatly appreciated.

Thank you for your help!

Best regards,
Wei Peng

[PengWei97]

My main question

I am currently thinking about two solution strategies.

Option 1: Single application

Use one input file for the whole problem.

Two sub-options:

(1a) Fluid = FV, Solid = FV

This seems more consistent with the current FV-based CHT tools in MOOSE.
I noticed that MOOSE has CHT-related infrastructure and FV heat-transfer boundary conditions such as FVFunctorConvectiveHeatFluxBC, which appears suitable for fluid-solid interface heat exchange.

(1b) Fluid = FV, Solid = FE

This seems physically reasonable, but I am unsure how best to handle the fluid-solid interface in a single application when the fluid temperature is cell-centered FV and the solid temperature is FE-based.

My question here is:

Is FV fluid + FE solid in one application a reasonable path in MOOSE for transient conjugate heat transfer?
If so, what is the recommended treatment of the interface temperature / heat flux continuity?

Option 2: MultiApps + Transfers

Use two separate input files:

one app for the solid conduction problem (possibly FE)
one app for the fluid natural-convection problem (FV)

Then couple them through TransientMultiApp + Transfers, exchanging interface data between the two problems.

From the documentation, MultiApps are intended for loosely-coupled systems, and TransientMultiApp supports transient advancement and optional Picard-style coupling.

So I am wondering:

Is solid FE + fluid FV coupled through MultiApps/Transfers a reasonable strategy for this problem?
If yes, would it be better to transfer interface temperature, heat flux, or both?
Would MultiAppGeometricInterpolationTransfer be the preferred transfer type for this kind of field exchange?

Why I am not planning to use SIMPLE for now

I have also looked at the SIMPLE executioner. However, the documentation presents it specifically for the steady-state incompressible Navier-Stokes equations. My current target problem is transient natural convection with conjugate heat transfer, so at this stage I am leaning toward a transient INSFV-based route instead of SIMPLE.

What I would appreciate guidance on

For this kind of problem, what would you recommend as the better path:

single-app FV-FV transient CHT,
single-app FV fluid + FE solid, or
MultiApps with FE solid + FV fluid and interface transfers?

Also, if MultiApps are recommended, I would appreciate advice on the most robust way to treat the fluid-solid interface in transient simulations.

Thank you very much for any suggestions.

Wei

[GiudGiud]

Hello

A few comments:

Is FV fluid + FE solid in one application a reasonable path in MOOSE for transient conjugate heat transfer?

No this won't work well out of the box. Our best FV solver uses a very different solve technique than the FE solver.
If the problem is quite small on the fluid side you can try it. INSFV + FE or INSFV + FV heat conduction should both work for 2D or small 3D problems.

(1a) Fluid = FV, Solid = FV

Using the LinearFV / PIMPLE-CHT, this would be recommended approach.

I have also looked at the SIMPLE executioner. However, the documentation presents it specifically for the steady-state incompressible Navier-Stokes equations. My current target problem is transient natural convection with conjugate heat transfer, so at this stage I am leaning toward a transient INSFV-based route instead of SIMPLE.

You can use the PIMPLE scheme to run a transient natural convection. The same CHT machinery implemented for SIMPLE works in the PIMPLE executioner.

Is solid FE + fluid FV coupled through MultiApps/Transfers a reasonable strategy for this problem?

Yes though may not be the fastest, it will depend on the FV fluid performance mostly.

If yes, would it be better to transfer interface temperature, heat flux, or both?

All options are possible. In Cardinal I think there are example of Dirichlet-Neumann coupling where the wall temperature and the heat flux are used.
In LinearFV in the NS repo we have examples with Robin DirchletBC where both are used as well.

From the documentation, MultiApps are intended for loosely-coupled systems, and TransientMultiApp supports transient advancement and optional Picard-style coupling.

No that's not accurate, we can couple strongly with MultiApps, you just need to iterate using the fixed point iteration parameters.

Would MultiAppGeometricInterpolationTransfer be the preferred transfer type for this kind of field exchange?

It's not the most accurate option. Geometric interpolation of the heat flux will not be conservative by default. using the MultiAppConservativeTransfer PPs-to-be-preserved parameters, you can set up a renomalization to preserve the heat flux

[PengWei97]

I’d like to make sure I understand your suggestion correctly.

Regarding NSPressurePin:

1. Is this corrector already usable in a PIMPLE / LinearFV setup, or is it mainly tied to the Navier-Stokes module infrastructure?
   Also, is this the same mechanism that is triggered internally when using pin_pressure = true in the executioner, or is that implemented differently?
2. Based on your suggestion, am I correct to understand that the idea would be to follow the same correction mechanism as NSPressurePin, but modify the logic to enforce a mean-zero pressure instead of a single-point pin (e.g., subtracting the domain-averaged pressure each time)?

In other words, rather than adding a constraint to the pressure equation, the idea is to enforce the reference pressure through a correction step during the nonlinear/PIMPLE iterations.

Does that sound like the right direction?

[GiudGiud]

Based on your suggestion, am I correct to understand that the idea would be to follow the same correction mechanism as NSPressurePin, but modify the logic to enforce a mean-zero pressure instead of a single-point pin (e.g., subtracting the domain-averaged pressure each time)?

NSPressurePin already can do a mean-zero pressure approach. See the documentation for it

Is this corrector already usable in a PIMPLE / LinearFV setup, or is it mainly tied to the Navier-Stokes module infrastructure?
Also, is this the same mechanism that is triggered internally when using pin_pressure = true in the executioner, or is that implemented differently?

No it's a different mechanism than pin_pressure=true.
It's used in INSFV but I think it will port with few modifications if not none to LinearFV

[PengWei97]

I made an attempt today, but I was still unsuccessful. Perhaps I should go back and rebuild this test case step by step. My plan is as follows: 1. Within a closed cavity, consider only convection and conduction in the presence of a flow field; 2. Consider pure heat conduction involving the coupling of the flow field, solid domain, and CHT; 3. Consider both heat conduction and convection involving the coupling of the flow field, solid domain, and CHT.

Currently, I have completed the first step—simulating heat conduction and convection based on boundary conditions, considering only the flow field. The input files and results are provided below:

• s1_cavity_fluid_conv_cond_nondim.i

The results appear satisfactory.
However, when transitioning to Step 2, I encountered an issue where the time step (dt) became extremely small. I will describe the details below and would greatly appreciate your guidance.

[GiudGiud]

2. Consider pure heat conduction involving the coupling of the flow field, solid domain, and CHT;

This should work fine?
Do you mean you turn off convection in the flow field in that case?

[PengWei97]

No, actually the result shown in this contour plot corresponds to case 1—meaning I considered only the fluid domain and did not incorporate any coupled solids. In case 1, the energy terms within the fluid domain included LinearFVTimeDerivative, LinearFVEnergyAdvection, and LinearFVDiffusion; in other words, I accounted for both conduction and convection.

However, in case 2—after incorporating the solid domain—when considering conduction alone, the calculated time step (dt) becomes extremely small. This is the specific issue I am seeking advice on, as detailed in the post below.

[PengWei97]

Hi, @GiudGiud and @grmnptr,

I am building a transient fluid–solid CHT test case under the PIMPLE executioner (INSFV), as a bridge case before enabling buoyancy.

• s2_cavity_cht_fluid_solid_cond_nondim.i

Setup (simplified)

• 2D cavity: upper fluid, lower solid
• transient conduction in both regions
• CHT at the interface
• buoyancy turned off → flow is essentially zero
• k_fluid = k_solid = 1
• interface h = 1

What I checked

• Mesh, block partition, and interface are correct
• Boundary conditions are working (verified by switching to simple top/bottom boundaries)
• Temperature fields evolve correctly
• Relaxing absolute tolerances from 1e-8 → 1e-6 increases dt. However, it remains around 1e-7—which is too small. A section of the log output to the terminal is as follows:

...
Iteration 2 Boundary interface flux on solid side -1.67037e-14 flux on fluid side: 1.66996e-14
Aborting as solve did not converge

Solve failed, cutting timestep.

Time Step 99, time = 0.000269277, dt = 2.58728e-07
Iteration 1 Initial residual norms:
 Momentum equation: Component 1 �[32m0�[39m Linear its: 0
 Momentum equation: Component 2 �[32m0�[39m Linear its: 0
 Pressure equation: �[32m0�[39m Linear its: 0
 Advected system: energy_system �[32m0.00124876�[39m Linear its: 2
 Solid energy equation: �[32m0.000218008�[39m Linear its: 1
 Iteration 0 Boundary interface flux on solid side -1.6704e-14 flux on fluid side: 1.67002e-14
 Advected system: energy_system �[32m0.00025041�[39m Linear its: 2
 Solid energy equation: �[32m1.34332e-07�[39m Linear its: 0
 Iteration 1 Boundary interface flux on solid side -1.67122e-14 flux on fluid side: 1.67083e-14
 Advected system: energy_system �[32m5.07966e-05�[39m Linear its: 2
 Solid energy equation: �[32m1.34332e-07�[39m Linear its: 0
 Iteration 2 Boundary interface flux on solid side -1.67204e-14 flux on fluid side: 1.67163e-14
Iteration 2 Initial residual norms:
 Momentum equation: Component 1 �[32m0�[39m Linear its: 0
 Momentum equation: Component 2 �[32m0�[39m Linear its: 0
 Pressure equation: �[32m0�[39m Linear its: 0
 Advected system: energy_system �[32m1.08291e-05�[39m Linear its: 1
 Solid energy equation: �[32m1.34332e-07�[39m Linear its: 0
 Iteration 0 Boundary interface flux on solid side -1.67285e-14 flux on fluid side: 1.67244e-14
 Advected system: energy_system �[32m2.82498e-06�[39m Linear its: 1
 Solid energy equation: �[32m1.34332e-07�[39m Linear its: 0
 Iteration 1 Boundary interface flux on solid side -1.67366e-14 flux on fluid side: 1.67325e-14
 Advected system: energy_system �[32m1.22282e-06�[39m Linear its: 1
 Solid energy equation: �[32m1.34332e-07�[39m Linear its: 0
 Iteration 2 Boundary interface flux on solid side -1.67447e-14 flux on fluid side: 1.67406e-14
Iteration 3 Initial residual norms:
 Momentum equation: Component 1 �[32m0�[39m Linear its: 0
 Momentum equation: Component 2 �[32m0�[39m Linear its: 0
 Pressure equation: �[32m0�[39m Linear its: 0
 Advected system: energy_system �[32m9.02407e-07�[39m Linear its: 1
 Solid energy equation: �[32m1.34332e-07�[39m Linear its: 0
 Iteration 0 Boundary interface flux on solid side -1.67527e-14 flux on fluid side: 1.67487e-14
 Advected system: energy_system �[32m8.38286e-07�[39m Linear its: 1
 Solid energy equation: �[32m1.34332e-07�[39m Linear its: 0
 Iteration 1 Boundary interface flux on solid side -1.67608e-14 flux on fluid side: 1.67568e-14
 Advected system: energy_system �[32m8.25432e-07�[39m Linear its: 1
 Solid energy equation: �[32m1.34332e-07�[39m Linear its: 0
 Iteration 2 Boundary interface flux on solid side -1.67689e-14 flux on fluid side: 1.67649e-14

Postprocessor Values:
+----------------+----------------+----------------+
| time           | dt             | run_time       |
+----------------+----------------+----------------+
:                :                :                :
|   2.642380e-04 |   5.571471e-07 |   2.584234e+01 |
|   2.645723e-04 |   3.342882e-07 |   2.663995e+01 |
|   2.649066e-04 |   3.342882e-07 |   2.676427e+01 |
|   2.653077e-04 |   4.011459e-07 |   2.687508e+01 |
|   2.657891e-04 |   4.813751e-07 |   2.699787e+01 |
|   2.660779e-04 |   2.888250e-07 |   2.779273e+01 |
|   2.663667e-04 |   2.888250e-07 |   2.791506e+01 |
|   2.667133e-04 |   3.465900e-07 |   2.802801e+01 |
|   2.671292e-04 |   4.159080e-07 |   2.815076e+01 |
|   2.676283e-04 |   4.990897e-07 |   2.826195e+01 |
|   2.679278e-04 |   2.994538e-07 |   2.906844e+01 |
|   2.682272e-04 |   2.994538e-07 |   2.918045e+01 |
|   2.685866e-04 |   3.593446e-07 |   2.930424e+01 |
|   2.690178e-04 |   4.312135e-07 |   2.941505e+01 |
|   2.692765e-04 |   2.587281e-07 |   3.022296e+01 |
+----------------+----------------+----------------+


Time Step 100, time = 0.000269535, dt = 2.58728e-07
...

Current issue

The simulation runs, but the adaptive time step stabilizes around ~1e-7:

• momentum/pressure are essentially zero
• fluid energy residual is very small
• solid energy equation seems to control convergence
• dt shows a typical grow–cutback oscillation

Question

For this type of conduction-dominated CHT case under PIMPLE, is it expected that dt remains this small?

More specifically:

• Is dt mainly limited by outer convergence tolerances?
• Or by the way solid_energy_system is handled in PIMPLE?
• Any recommended settings to obtain a larger and smoother dt in this regime?

Thanks for any suggestions!

[PengWei97]

Thank you again for your helpful suggestions.

I performed additional tests based on your recommendations and would like to share a few updated observations:

1. I increased the maximum number of outer iterations (up to 100). This allows more iterations per time step and slightly increases the time step size. However, the total computational cost increases significantly, while the solution behavior remains essentially unchanged. This suggests that the issue is not due to insufficient iteration count.

2. I also tested reducing the number of outer iterations (num_iterations from 20 down to 5) to examine the effect of limiting the iterations per time step. However, this did not improve the time step growth either.

   In this context, I would like to clarify your suggestion:
   “Try to force a minimum number of iterations.”
   Does this refer to ensuring that each time step performs at least a certain number of outer iterations (rather than simply limiting the maximum)?

   In practice, I tried combining num_iterations with continue_on_max_its. This does help increase the time step size effectively, but at later stages the time step can grow quite large (e.g., up to ~690). I am therefore wondering:

   • Could this kind of forced truncation affect the solution accuracy?
   • If so, what would be a recommended way to mitigate this — for example, by choosing a more appropriate value of num_iterations, or by introducing additional control on the time step?

3. I increased max_cht_fpi, but this did not improve convergence. During the CHT fixed-point iterations, the residual of the energy system consistently stagnates around ~1e-6 and does not decrease further.

4. I also tested increasing the CHT tolerance relative to the individual system tolerances. However, in this case, it did not noticeably improve convergence behavior — the energy system residual still plateaus slightly above the specified tolerance.

5. The linear systems are solved very easily (Linear its: 1 in most cases), indicating that the limitation is not coming from the linear solver.

Overall, the behavior appears to be the following:

• The energy system residual (in the fluid region) does not strictly drop below the specified energy_absolute_tolerance,
• but the solution itself (temperature field and interface heat flux) is already stable and physically consistent,
• i.e., it appears to be converged in practice, despite not satisfying the strict residual criterion.

Based on this, I would like to confirm:

• In such diffusion-dominated CHT cases, is it acceptable to stop iterations once the residual reaches a plateau close to the tolerance, even if it does not strictly drop below it?

• Is there a way (or recommended approach) to use a relative convergence criterion for the outer nonlinear/PIMPLE iterations, similar to nl_rel_tol in transient Newton solves?

• Additionally, would tuning PETSc-related options have any effect on this type of residual plateau, or is this mainly governed by the outer coupling strategy?

Thank you again for your guidance — it has been very helpful in understanding the solver behavior.

[GiudGiud]

Could this kind of forced truncation affect the solution accuracy?

Yes and no. For your purpose it's likely setting a high number of iteration and always accepting the solution will suffice to get a 1e-5 or similar accuracy. Which is usually more converged than you actually need.
For creating gold solutions for a test, we like to converge things more and compare converged solutions. This makes it resilient to solver changes such as updates in PETSc.

During the CHT fixed-point iterations, the residual of the energy system consistently stagnates around ~1e-6

Have you tried introducing relaxation? Maybe this will help get it to decrease further.
It consistently stagnates but solving for at least 1 iteration right? If it is saying 0 iterations, the solver is not resolving the system and the residual wont change

The linear systems are solved very easily (Linear its: 1 in most cases), indicating that the limitation is not coming from the linear solver.

This is because they are either already near the convergence criteria you set for linear solves, or because you are using a direct solver (LU preconditioning is essnetially a direct solve)

In such diffusion-dominated CHT cases, is it acceptable to stop iterations once the residual reaches a plateau close to the tolerance, even if it does not strictly drop below it?

If the plateau is low enough yes. All residuals plateau at some point, though for some we reach much lower levels.

Is there a way (or recommended approach) to use a relative convergence criterion for the outer nonlinear/PIMPLE iterations, similar to nl_rel_tol in transient Newton solves?

No we just set the number of iterations num_piso_iterations.

Additionally, would tuning PETSc-related options have any effect on this type of residual plateau, or is this mainly governed by the outer coupling strategy?

You are using LU for all solves right?

[PengWei97]

Hi @GiudGiud,

Apologies for the late reply — I was on holiday for a few days.

Thanks again for your helpful suggestions. I’ve tried a few things and wanted to share some updates:

1. For the first point: using dtmax + continue_on_max_its + num_iterations, the simulation can run stably and the efficiency is acceptable. However, this truncation approach does not really enforce convergence. When dt becomes large, the error accumulates and eventually the run fails with non-physical values (e.g., infinities at the boundary). I will post a representative log shortly.

2. For relaxation: I did try applying it, but the effect is quite limited. Currently only the Advected system: energy_system shows non-zero linear iterations (around 4), while others remain at 0.

3. Regarding linear iterations: I am currently using the default executioner/PETSc settings (no explicit configuration). In your experience, would you recommend tuning the linear solver setup here for this type of PIMPLE-CHT problem?

Thanks again for your guidance — this has been very helpful.

[PengWei97]

I have a follow-up question on this CHT case.

In my fluid–solid coupled heat transfer simulation, the main issue is that the solid energy system shows poor nonlinear residual convergence, while the interface heat flux is already well balanced and the other systems converge relatively well.

My main question is:

For this kind of conjugate heat transfer problem in MOOSE, when the solid energy equation converges poorly, how should I optimize the executioner/coupling settings?

I have already tried increasing max_cht_fpi, but the improvement is limited.
Reducing dt can help, but it also makes the overall simulation much slower.

So I would like to ask:

• Are there recommended executioner settings for this situation?
• Should I mainly tune CHT relaxation parameters, outer iterations, or something else?
• In practice, what is usually the most effective way to improve solid energy convergence without sacrificing too much efficiency?

Thanks a lot for any suggestions.

[GiudGiud]

For the first point: using dtmax + continue_on_max_its + num_iterations, the simulation can run stably and the efficiency is acceptable. However, this truncation approach does not really enforce convergence. When dt becomes large, the error accumulates and eventually the run fails with non-physical values (e.g., infinities at the boundary). I will post a representative log shortly.

We do have more advanced convergence criteria that can be built as needed in the Convergence system, however they are not currently available in the SIMPLE executioner. You have to work with relative/absolute tolerances and number of iterations for now.

For relaxation: I did try applying it, but the effect is quite limited. Currently only the Advected system: energy_system shows non-zero linear iterations (around 4), while others remain at 0.

ok that is good information. This is the fluid energy right? and what are the solver parameters for that equation? (convergence and preconditioning especially)

Regarding linear iterations: I am currently using the default executioner/PETSc settings (no explicit configuration). In your experience, would you recommend tuning the linear solver setup here for this type of PIMPLE-CHT problem?

When debugging I would set everything to LU. Or at least the problematic equation. A direct solve (LU preconditioning ends us being that) should succeed in decreasing the residual to convergence in one iteration.

In my fluid–solid coupled heat transfer simulation, the main issue is that the solid energy system shows poor nonlinear residual convergence, while the interface heat flux is already well balanced and the other systems converge relatively well.

So Advected system: energy_system is the solid? I m not sure of that? Maybe we need to fix some terminology here

For this kind of conjugate heat transfer problem in MOOSE, when the solid energy equation converges poorly, how should I optimize the executioner/coupling settings?

Not sure there are general advice. i would try stronger preconditioning for the solid equation. Either LU or hypre amg if it works. The latter is common for solid heat conduction and works well