[fandall]

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]

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]

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]

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]

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

[fandall]

I still can't find any errors :-(
I deposited my fvschemes file here:
http://n.ethz.ch/student/rohnerth/download/fvSchemes
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]

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

[fandall]

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

[eugene]

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

[fandall]

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]

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]

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]

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]

Hii,

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?

Thanks,
Tarak