Heat "vanishing" in Navier-Stokes/heat equation 3D simulation

Hi folks,

Relatively new user here. I am working on a 3D simulation of a simple serpentine heat exchanger, shown below:



In this simulation, I have heat transfer fluid flowing in at 176 C through the port at the top right, through the serpentine path, and then out the port at the bottom left. The initial temperature of the heat transfer fluid and all other components in the simulation is 130 C. The problem I am running into is that the heat in the heat transfer fluid seems to "vanish" as it goes around the first bend in the heat transfer fluid path. The temperature on the inside of the curve drops below the initial body temperature, and the hot temperature seems to evaporate out of the wall. There are further weird behaviors further downstream - but I'm most concerned right now about what's going on at this initial bend.

A few notes on the simulation:
[*] There are four distinct bodies in this simulation: 1) the heat transfer fluid (Navier-Stokes and coupled heat equation), 2) the stainless steel serpentine path + connected components (just heat equation), 3) a second heat transfer fluid path, not shown, which is static for the purposes of this simulation (heat equation), and 4) a thermal storage media surrounding the serpentine path (heat equation).
[*] In order to get the system to mesh correctly, I needed to import *just* the thermal storage media and the stainless steel components. I was then able to mesh just those components to successfully generate a 4-body system.
[*] I have coupled the heat equation for the flowing heat transfer fluid domain to the Navier-Stokes equations for this domain by assigning the u, v, and w velocities to be u, v, and w.
[*] I am concerned about the thinness of the walls of the stainless components. I do need to simulate them (because of geometry I can't share here) but I am concerned that they simply don't have enough thickness.
[*] I am running this as a time-dependent simulation. I initially thought that my time resolution was too coarse (1000 s in 100-s increments), and tried 4000 s in 10 s increments over the weekend, but saw fundamentally the same result.

I unfortunately can't share the model file, but I am happy to answer questions about it as much as I can. Thank you all for your support here!

Unfortunately quite hard to give specific advice without looking at the model, as it could be many things. Possibly a too coarse mesh causing numerical diffusion and unphysical solution (for which the remedy would be a finer mesh in affected regions and/or artificial stabilization). You could maybe try the OpenFOAM CFD solver and see if it works/helps.

If possible try to simplify the model into a minimal reproducible example (1 bend for example) with a non-proprietary model/geometry that you can share.

That's totally fair. I was hoping this would be a, "oh, that's a newbie error - do THIS and it will go away" solution - but sounds like it's not, and makes sense that you'd need to see the model to evaluate.

I've created and attached a model of a single bend from the HX, with the proprietary geometry removed. There is still a defect in the simulation, although it's different from my previous model - see the images below at t = 30 and t = 100. I've also attached the original STEP file used to generate this model.





A couple of notes:
- I have the algebraic turbulence model turned on, and the default pressure stabilization = 1 and auto pressure constraint turned on, for the Navier-Stokes domain in the heat transfer fluid body. I don't have any artificial stabilization turned on for any of the heat transfer domains.
- I've tried at a few different levels of mesh refinement, and the phenomenon seems more or less repeatable.
- The velocity and pressure profiles through the tube look correct - it's the temperature probe that looks wonky.
- I did find that some of my internal boundaries were messed up earlier when I ran this model - a number of boundaries between the stainless and the thermal storage media were set to types other than "Continuity". I fixed this and still got the results shown above. I've also verified that in my original model, I did not have this defect - all of the internal boundaries were correctly defined.

I am remembering, from years ago working with a different FEA program, that it was possible to define the element type used in very thin-walled components as a different sort of element - e.g. a beam instead of a plate. Is there a similar technique I can apply here when working with the very thin-walled stainless tube elements in this example?

Here's the files:
STEP File:SPX_Reduced.step
FEA File (too big for upload - had to share to Dropbox): https://www.dropbox.com/scl/fi/uhyprw74n4qr2fh0grt8d/SPX_Reduced_20250902.fea?rlkey=mhx7ve3vf1dcauw0niuqryvw5&st=3m5oeg5z&dl=0

Thanks again for all of your help!

Had a quick look at your model, and firstly neither the velocity or in particular the temperature seem to converge in the attached model. It would be rare to have a good solution if the solver hasn't converged.

As your flow field doesn't depend on the temperature I would suggest first just solving for the flow field, and ensuring that you get a good solution. And then you canseparately solve for the temperature as in the multi simulation heat exchanger example (https://featool.com/model-showcase/06_Multiphysics_09_multi_simulation1/). Using OpenFOAM solver for the flow field with a better turbulence model (k-epsilon/omega) would probably be a good idea. Then you can focus on the temperature field using the pre-computed flow field as input.

Furthermore, if not critical to the simulation I would try to remove the small circles from the geometry, as small details lead to more difficult meshing (and reduced mesh quality). In that case you can probably also split the geometry in half using one symmetry plane (to save mesh elements). You can try using the "Geometry > Defeature Object(s)" functionality (or a dedicated CAD program if it doesn't work).

Unfortunately, shell type elements haven't yet been implemented in any of the available solvers.

Thank you for your help here. I will look at separating flow field + temperature in the multi-simulation example, and will also look at accessing the OpenFOAM solver.

The small circles are unfortunately critical - not for this geometry, but for the full geometry (a non-symmetric 3D geometry, which is also why I can't use a symmetry plane)

How are you seeing that the velocity and temperature don't converge in the model? Are these the def-<n> and rel-<n. statistics that show up during solution? Which should I be looking at for convergence?

<quote author="julianbell">
How are you seeing that the velocity and temperature don't converge in the model? Are these the def-<n> and rel-<n. statistics that show up during solution? Which should I be looking at for convergence?
</quote>

Yes, "def-<dependent variable>" is short for the defect between nonlinear iterations ("Defect stopping criteria" solver setting), and "rel-<dvar>" for the relative changes between iterations (Solution changes stopping criteria) "||u_n+1 - u_n||/||u_n+1||". Both are expected to be << 1 for a converged solution (default solver settings are 1e-6 tolerance).

Got it - thank you!

If I'm using the standard 20 nonlinear iteration count and I'm not reaching the default convergence limit of 1e-06, is it reasonable to increase the nonlinear iteration count? Or should I be able to achieve convergence in 20 iterations if the rest of the simulation is well constructed?

Are there other techniques you can recommend to try to increase the likelihood of convergence?

You can always try to increase the maximum nonlienar iterations. However, typically it won't suddenly start converging if the defects/changes aren't decreasing significantly (which is the case in your simulation). There are some tips for non-linear solver strategy linked below:

https://featool.com/doc/solver#solver_nonlinear_strategy

Well, I tried OpenFOAM this morning, with limited success:

- I was successfully able to run the OpenFOAM solver with a more sophisticated turbulence model on a trivial case (2D rectangle with inlet at one side and outlet at the other). Not saying the results were accurate - just that it ran and produced a reasonable flow field.

- When I tried to do the same thing with the model I linked below, I got the following error message. This is true for k-omega, k-epsilon and Spalart-Allmaras turbulence models, for either steady-state or time-dependent solutions. I've also uploaded a copy of the model in this configuration.


SPX_Reduced_OpenFOAMError.fea

- I then tried turning the turbulence model off and solving with OpenFOAM. The solution begins, but then crashes with the error "Error calling changeDictionary" - see below.



I've read through the OpenFOAM CFD Solver page (https://www.featool.com/doc/openfoam#openfoam_control), and don't see anything obvious indicating why this should be crashing. Looking at the multi-simulation example that you mentioned (https://featool.com/doc/Multiphysics_09_multi_simulation1#tut_mph09), I recognize that I'm not currently separating the two simulations. Is that strictly required? I interpreted the discussion of solving conjugate heat transfer problems to mean that the chtMultiRegionFoam solver could handle this type of problem - am I misunderstanding?

Thank you again for all of your support with this - really appreciate it!

A fluid turbulence model for heat transfer would also be required, for which the UI hasn't been implemented yet (the first error). Not quite yet sure about the second issue, will try to investigate and update.

Technically, it isn't required to decouple the simulations, however it might not be a bad idea to start with the a simpler problem first (only fluid flow), to get that right, before making it more complex.