CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Running, Solving & CFD (
-   -   Stability issue while running buoyantFoam (

fandall June 1, 2007 05:01

I'm experiencing some trouble
I'm experiencing some trouble running the buoyantFoam solver. During computation, while the Courant Numbers are still below 1, the following message, even if I employed a smaller timestep, appeared resulting in an interrupt of the computation:

--> FOAM FATAL ERROR : Maximum number of iterations exceeded

From function specieThermo<thermo>::T(scalar f, scalar T0, scalar (specieThermo<thermo>::*F)(const scalar) const, scalar (specieThermo<thermo>::*dFdT)(const scalar) const) const
in file /home/dm2/henry/OpenFOAM/OpenFOAM-1.2/src/thermophysicalModels/specie/lnInclude/ specieThermoI.H at line 83.

FOAM aborting

To me it seems like the scheme for the temperature did not converge anymore. How can I influence the stability of it? The timestep alone doesn't seem to be enough.

My fvSchemes file is identical to the one used in the HotRoom Example Case, using also the same solver parameters for the turbulence model.

Any help is greatly appreciated

eugene June 1, 2007 12:12

Try upwind on h convection. In
Try upwind on h convection. In fact put upwind on everything except div(phi,U) for which you can use linearUpwind cellLimited Gauss linear 1;

linearUpwind with a limiter is from my experience the most stable second order scheme around.

Also, if your mesh has any significant non-orthogonality (check with checkMesh) you should change all the laplacianSchemes entries to "Gauss linear limited 0.333;" and snGradSchemes to "limited 0.333"

At least these are the settings I use and I do quite a bit of buoyant flow calculations on meshes of questionable pedigree.

fandall June 4, 2007 03:20

Wow thanks! Altough I learne
Wow thanks!
Altough I learned about the stability of upwind schemes in my lectures, it didn't occur to me to use them (*D'oh*). I somehow thought this didn't apply to turbulent flow :-) Will surely give it a try.
My mesh is strictly orthogonal, so the laplacianSchemes (all set to Gauss linear) should do fine.

The Problem that I now have is, if I attempt to apply an upwind scheme to the div((mueEff*dev2(grad(U).T()))) term, the following error is put out before the calculation is even started:

--> FOAM FATAL IO ERROR : attempt to read beyond EOF

file: /opt/OpenFOAM/root1.2/run/shaftVentilation//shaftVentilation/system/fvSchemes::d iv((muEff*dev2(grad(U).T()))) at line 46.

From function ITstream::read(token& t)
in file db/IOstreams/Tstreams/ITread.C at line 70.

FOAM exiting

If I leave this term at 'linear', the whole thing is still diverging after a couple hundreds of time steps, seemingly independent of the time step size. And it is still the temperature solution that explodes. :-(

fandall June 4, 2007 03:41

I can't figure out why it show
I can't figure out why it shows this error message. "Attempt to read beyond EOF" means, that it attempts to read beyond the end of the file if I'm not mistaken, but I haven't forgotten a semicolon or anything like that. All I did was exchanging 'linear' with 'upwind' which even has the same number of letters. ?:-S

Please enlighten me

eugene June 4, 2007 06:17

Keep checking, there is either
Keep checking, there is either an keyword entry missing or a punctuation error. Nothing else would cause that error.

fandall June 4, 2007 07:40

I still can't find any errors
I still can't find any errors :-(
I deposited my fvschemes file here:
All the other files in the system folder haven't been altered (except for the 'deltaT' and the 'writeInterval' values in controlDict) and are still the same as found in the hotRoom Example.
My suspicion is, that the scheme definition on line 46 needs additional input if any other interpolation scheme than linear is used, but I have no idea what kind that could be.

eugene June 4, 2007 07:53

What version of Foam are you r
What version of Foam are you running? linearUpwind with a cellLimited limiter is only supported from 1.4.

fandall June 4, 2007 08:01

I'm running Version 1.2 on thi
I'm running Version 1.2 on this machine.
If I try it without the limiter, I still get the same error message...

eugene June 4, 2007 08:06

linearUpwind didnt work very w
linearUpwind didnt work very well in 1.2, so I would switch to GammaV for div(phi,U).

fandall June 4, 2007 08:25

Perhaps I found the missing ar
Perhaps I found the missing argument:
If I want to use an upwind scheme on the term on line 46, it seems that I have to specify to which reference the upwind direction is identified. So I guess this missing reference should be the flux phi e.g.: "div((muEff*dev2(grad(U).T()))) Gauss upwind phi" should specify the correct flow direction. What do you think?

fandall June 4, 2007 08:56

So, setting up every divergenc
So, setting up every divergence scheme with upwind, the last one described as above, I end up with the same explosion of the temperature solution with which I started: The computation runs smoothly for a couple of hundred time steps and then diverges. :-(((
I guess I have to read some more literature about the stability of turbulent flow simulation or this one will never converge...

eugene June 4, 2007 10:17

Given that you are now using t
Given that you are now using the most stable schemes available and are still experiencing divergence, I would hazard a guess that either your initial or boundary conditions are in error. (with boundary conditions being the more likely of the two.)

fandall June 4, 2007 10:29

Thanks for thinking aloud. Out
Thanks for thinking aloud. Out of these two, I would also go for the boundary conditions as the computation runs great for a rather big number of time steps. I'll reconsider my choice of b.c.'s carefully and will update you on any success stories.

Tarak May 9, 2011 11:36

FOAM FATAL ERROR: Maximum number of iterations exceeded

I am getting a similar error too, and don't seem to find an appropriate solution. Can someone please tell if he has managed to solve the issue?


All times are GMT -4. The time now is 16:58.