SimScale CAE Forum

External convection analysis, correct set up

Hi, I intend to check some theoretical heat transfer concepts about external forced convenction and to get a basic knowhow of thermal cases setup in SimScale, using a test body (inteds to be a kind of “simplified” vehicle body)

First I tried and got some more ore less “sensible” results of external incompressible flow simulation in steady state (k-e).

I jump into using the “natural convective heat transfer” steady-state case (k-e model), and a BC set as far as I currently understand. I used as referece the BC setup of the HVAC car interior in the library.

Inlet frontal face: fixed speed 1m/s and Tª (5ºC)
Outlet (rear) face: custom, P=0, k-e inletoutlet, all rest gradient=0
Side faces: custom, speed=slip, all rest gradient=0
Body walls: noslip with wall functions, fixed Tª (15ºC)
Numerics: same config as car HVAC example.
Model: default values as car HVAC example.
3000 steps

In about 4minutes ends with error “Maximum number of iterations exceeded.” No convergece plot is done.

Obviously something basic is wrong and I would like to find out before trying again. I am using k-e as I understood it is a more stable model to get convergence.

Thanks for commenting

View of velocity field (incompressible k-e)

1 Like

Hi @rarrese ,

do you still face some difficulties in your project or do you want someone who can validate your simulation?

If yes, I will have a look at it as soon as I have time.

Kind regards,



on the first glance, your boundary condition setup makes sense to me. I also had a brief look at the numerical settings and they looked good as well. I’ll have a closer look at it tomorrow and get back to you if I have an idea. @jousefm, if you have any ideas in the meantime, feel free to jump in.



Ok thanks, I just checked the server room cooling example from library and it seems uses a very similar setup. Probably is a dumb thing but can´t find it…the main difference with the library examples is that it is a external flow.

Hello Everyone,

I was just browsing through and was interested in seeing this External convection Heat Transfer topic.
To start with, I have come across this error of " “Maximum number of iterations exceeded” quite a few times for several different reasons.

Well, generally this means that the solver has done about 1000 or so iterations to try to converge the step but was not successful in doing so.

As it could be due to several reasons, I will have to take a deeper look into your shared project and will keep you posted.

Cheers :smile: ,


nice work with the setup. I went through it and found one small yet important issue: you’ve set pressure value to be 0 at the outlet, which results in a zero density. This will get you in trouble at the second solver iteration where boundary conditions are effective. I would suggest to put a physical non-zero pressure and your simulation should be fine. The rest looks good.

As a side note, “Maximum number of iterations exceeded” happens when a physical property is being calculated from field values. If within a default of 1000 iterations the interpolation does not reach a value, you’ll get this error. In your case, zero pressure resulted in a temperature out of the interpolation range.

I hope this helps. Let us know if your simulation works fine now.



nice, good hint! @rarrese, does that solve the problem?



O! Thanks for the hint Babak. I have also come across this error and all I was able to get to know was that it was related to the Temperature, but nothing more. – Really useful piece of information.

It was the 0 pressure. Now it converges.

Maybe it could be included a warning in the “check simulation” option when it detects an incoherent or “not usual” setup?

1 Like

Having problems to load results in paraview, any rule of how much memory do I need? the computer gets collapsed

Not tried yet, just verified it briefly on the web postprocessor…


great that it solved the problem. It’s already tracked as an improvement request. @gholami will either change the default value to non-zero or add a warning. We’ll keep you posted.

@jpola, how many cells has the solution you’re trying to post-process locally?

14E6 volumes, I tried other model with 7E6 but no success either. Paraview will eat all my memory available (4GB).

is there any way of simplifying the model once calculated for postprocessing?
as I see it can be needed a high detail for a correct solution or even for achieving convergence but for general data postprocessing i.e. like pressure drops, flow rates or mean T or flux a simplified result can be enough.

In the browser I can view results for the 7E6 model (really slow) but for 14E6 it blocks the browser.


yes, in this case the 4GB RAM might indeed be the problem. Especially the 14e6 case, from my experience you need significantly more RAM to post-process this. The online post-processor is right now in beta and comes only with limited capabilities and performance, such that this might also not be a viable solution for your right now (however we are working hard on the release version which will be deployed soon to production).

Depending on what exactly you need to extract from the simulation results, the Result Control Items might solve your problem:

simulation result control

They allow you to extract scalar values from the result fields, even during runtime and can help to avoid of lot of 3D post-processing afterwards. Find the documentation on them here:

E.g. to extract the pressure drop, you would apply a surface data item on the patch where the pressure is not fixed and choose the Area Average there - this would give you the average pressure over that face with which you can then compute the pressure drop, without ever looking at the 3D result. Same for flow rates - in that case you would not choose average but Surface integral of the velocity, which would give you the volume flux etc.!

Does that solve your problem until the release of the real post-processing environment?

That info is useful, but will need a workaround or getting more RAM to load the file. 8GB will do it?
Any idea when the updated postprocessor wil be released?

I run into some weird problem. After some tests tried to get back to my first converged simulation, to increase the end time and save it at a better converged step.

I have found that with the same parameters now the case diverges in about 150 iterations. At first tought that I have changed something for sure, but I took the time today to review one by one every single parameter and can confirm that are exactly the same. I did a new case copying the same parameters but no luck, diverges.
what could have happened? Mesh is alos the same.

I did a schematic of the BC, just for reference (they worked correctly before, just in case can get some reccomedation to improve stability).


Convergence plots:
Second:SimulationT from scratch/run5, sane parama than run3
Third: Simulation T 2d/run1

I tried to simplify as a 2D case. I used a 1cell depth mesh, 10mm in z direction. Snappy will subdivide also in z for each level. is there a better (or correct) way to do it?
BC are equal except z faces that are “symmetry” type.
As gravity was in z direction makes no sense using it, so set it to zero.
With this setup the case converges but gives a noisy residual in Z that don´t know how to interpret.

link to project
Comments are welcomed


from the images you post, it seems that you ran the “Run OK” with about 1200 iterations, the “Run NOK” only about 100 iterations. Did you run the “Run NOK” for testing purposes also for 1200 iterations? Does it really diverge? Couldn’t it be that the divergent behavior of k and epsilon is only happening in the beginning? When I look at the “Run OK” it seems that also there both quantities “went up” in the beginning. What do you think?




It blows up at about 150 iterations when starts wiggling. Normally due to “maximun nº iteartions exceeded” that was linked from Babak post to a “non physical” property calculation exception (i.e. BC not sensible). Due to this I posted the schematic of the BC just to check if they makes sense (altough I confirm that previously the sim run was Ok, I can´t see the problem anyway).

I don´t feel too confident with the BC definition. I.e. my intention is to simulate “open space” surrounding a fixed Tª object, with a fixed lengthwise airspeed.

For domain “sides” (zy plane) and “ground” (xy plane) the “slip” condition, fixed Tª and zero gradient for rest can make sense. But for upper face of the domain (“ceiling” in xy plane) maybe makes more sense to use zero gradient for every variable including speed? This would allow some kind of buoyant plume to form if it makes sense due to gravity effect.

The “2d” simplification without gravity seems to converge. Please make any suggestion about how to correctly setup for 2d.
i.e. I used 10mm cell depth in z, could be better to use a 1 (unity) depth?