Hi all, I met the error as
 

Hi all,

I met the error as follows when I run buoyantFoam case after I add the Sp() function as my source term in rhoEn. Could anybody help me this matter?

Thanks so much.

The error is:
--> 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/liu/OpenFOAM/OpenFOAM-1.2/src/thermophysicalModels/specie/lnInclude/specie ThermoI.H at line 83.

FOAM aborting

Hi Guoxiang, I have the sam
 

Hi Guoxiang,

I have the same problem, how did u solve it?

thanks,
Rita

My guess, is that your source
 

My guess, is that your source term is triggering a divergent solution, which increases continuously the temperature. Once your T0 goes too high (I am not sure, but something like 5000K is the limit of the implemented thermodynamic properties) you get the error. What you can do very fast, is to modify the maxIter_ from 100 to something larger. Another thing is to modify the tolerance tol_ from 1.0e-4 to something higher (1.0e-3 or so), but this is not a good advice.

If you really need such high temperatures, like Rita, then I think you have to implement yourself the polynomials for the thermodynamic properties of your fluid.

Dragos

Dragos, In which file is th
 

Dragos,

In which file is the maxIter_ value ?... sometimes I think it's necessary increase the maximum of iteration number.
Thanks.
Cesar.

Hi Cesar, grep -r maxIter_
 

Hi Cesar,

grep -r maxIter_ OpenFOAM/OpenFOAM-1.3/src/thermophysicalModels/specie

lnInclude/specieThermo.C:const int specieThermo<thermo>::maxIter_ = 100;
lnInclude/specieThermo.H: static const int maxIter_;
lnInclude/specieThermoI.H: if (iter++ > maxIter_)
thermo/specieThermo/specieThermo.C:const int specieThermo<thermo>::maxIter_ = 100;
thermo/specieThermo/specieThermo.H: static const int maxIter_;
thermo/specieThermo/specieThermoI.H: if (iter++ > maxIter_)


So, you can change the value in: specieThermo.C
It might be a bit different in version 1.2, as you have, but it should be simmilar.
But I suggest to have a check for the residuals first. If they grow, than you have a divergent solution, and increasing the maxIter_ will not help.

Dragos

Hej Dragos, Could u give me
 

Hej Dragos,

Could u give me some hint about implemention the polynomials for the thermodynamic properties of my fluid?


I'm using Buoyancy case for Argon gas with teperature from 300 K upto 20 000K:
--------------------------------------
Name Argon
--------------------------------------
nMoles 1.0
molecularWeight 39.948
deltaH 1.0499e+05
viscosity 3.4079e-5
Pr 0.65
---------------------------------------

Thank u so much,
Rita

Hi Rita, I'm not too much of
 

Hi Rita,
I'm not too much of help here. You can take a look in the OpenFOAM/OpenFOAM-1.3/src/thermophysicalModels for details.
Though, one sugestion I can make: try to use janafThermo instead of hConstThermo, if you have access to janaf tables.

Dragos

Hi Dragos, I have looked in
 

Hi Dragos,

I have looked in it before. It didn't help to much. I'm not familiar with programming in OpenFOAM.
I can't understand where here is introduced the limit of temperature.

Do you have any suggestions?

thank u,
Rita

Maximum number of iterations exceeded
 

Hi same thing I came across too.....


This problem came when I was using the number of interval more than 150 or so, in gambit, the exported mesh to OpenFoam was showing that error message i. e ..Maximum number of iterations exceeded..bla bla.......
before this it was running upto clock time 5 or 6 and than the error message. If I change the mesh intervals, the clock time of getting that massage had been changing accordingly. When I change the mesh intervals in gambit in 100 it worked i.e upto requried time ( ..which I had set in controlDict .....

Conclusion : change (decrease) the mess interval count in gambit. the exported mesh shall let u find the way....

thanks

I was able to solve this problem by using 1st order scheme for temporal discretization

error of maximum no of iteration exceeded ..
 

helo ,
i got the same error of maximum no of iteration exceeded as posted above by many . i tried to solve it by changing residuel, time step etc whatever is suggested above but still m getting the same error . can anybody plz suggust me whr i am wrong ??? thanks in advance .(i am doin my simulation in rhopimple solver )

Hello,

I suppose you might be using second order schemes for temporal discretization, I had this error with 2nd order. When I switched to 1st order (euler) the error never popped up.

Hello Rahul,

I am using chtMultiRegionSimpleFoam and facing the same issue. I have tried changing ddtScheme to "Euler" which is first order implicit scheme. Could you please guide me if I need to change anything else?

Hi,

For me it worked fine only by changing to euler, however I recently changed newton solver to brent solver for temperature calculation and now it works completely fine.

Regards,
Rahul

Hello,

I am also currently having that problem, picture attached below. I have changed the script in thermo.C for the max iterations to a much larger number. I cannot find the specieThermo.C script though. I also have increased the tolerance in the thermo.C script. I believe my script is in Euler form, as it states in the fvSchemes folder. (Is that where I need to change it to Euler or is there another thing I'm missing?) I am also using the function: sonicFoam. As a side note, even when I changed the max iterations and tolerance numbers in the thermo.C script, the program still ended at the exact same time: 2.67835e-05 and produced the same error message. Can anyone help me fix my error?

Thank you so much,
~Michu

Hi Michu,

You can find the the script in here
OpenFOAM-2.2.0/src/thermophysicalModels/specie/thermo/thermo/thermoI.H

In this file Newton solver (Line no. 41 - 88) is utilized to calculate the T. I implemented brent solver and now that problem is solved.

Hello srahul,

Thank you for responding and helping. I am still a little confused.

Previously I changed the ThermoI.H script through the thermophysical Models/specie/lnInclude but when I changed the script in that directory, somehow the script ThermoI.H in the thermophysicalModels/specie/thermo/thermo directory also changed. (Just something weird I noticed).

When I changed line 64: if (iter++ > maxIter_) to this: if (iter++ > 100000000000000000000)
the program still provided the problem shown in my image above.

My coding is a little rusty so sorry if this seems simple, but I thought the problem is the maximum iterations. Do I also have to change line 80: } while (mag(Tnew - Test) > Ttol); in order to fix this problem? Is there something else I should also change?

Thank you for your help,
~Michu

Hi all,

When you make a change in the scripts, do you have to re-load openfoam or something for the changes in the script to take place?

Like if I changed the max temperature from 100 to 100000 in the script. Will that automatically change the way sonicFoam works, or will I have to do something like click a button that says apply update?

Thank you,
~Michu

Response to Max Iterations Exceeded
 

I had this problem also using RhoCentralFoam and this were my remedial options:-

1. Switched ON adjustableTimeStep in the controlDict and choose maxCo as preferred.

2. Reduced the time-Step more with adjustableTImeStep =OFF;

The problem was resolved..

Hi

I've been chasing the same problem for a while and found it popping up with different solvers, different circumstances.
I get the "maximum number of iteration exceeded" error when running constant transport model. When I switch to Suderland, I get a different error but also called from thermo::calculate.
The function that triggers the "maximum number of iteration exceeded" error calculates the temperature field given the value of a thermodynamic function and its derivative vrt temperature using Newton formula.
The thing is, I'm using epsiThermo model with a perfect gas, that means the internal energy, e, is temperature times Cv, the function is linear and the Newton algorithm should get it in one iteration.

Something is wrong here,

Hi Francis,

Thank you for your advice. It also lets me solve my problem.

BR.

Hi,

I am using a Cht K epsion model using Openfoam and I keep getting this error.

I have tried changing the maxiter to 10000 and still get the problem too. Did anyone get to the bottom of this? I completely remade my mesh and still get this same error although I have a few overly skewed faces (64 failed skewness faces) and 900 faces failing nonOrthag check, however due to the geometry even if I used SHM these errors would still occur.

I tried Francis's method and this has't solved it.

I have noticed a sharp (impossible) rise in density in certain regions of the fluid, this was so sharp that it shouted alarm. However I am unfamiliar with this type of modelling so thought I would ask for some advice.

I previously attended the Advanced Openfoam training course and have emailed the guy who ran it (as has my work mate) regarding problems which he encouraged. Unfortunately he does not respond to emails, which has left me a bit discouraged.

Cheers

Hey everyone,

I recently ran into the same issue using the sprayFoam solver with version OF2.4 and an implemented ignition. The error especially ocurrs when I ignite more than one cell and I think it must be due to the Newton solver used to calculate the temperature. Eventually it ocurrs with only one ingiting cell as well though. Has anyone solved this issue so far?

@sahul could you provide the implented brent solver?

Thanks in advance

Moritz

Hi Moritz,

Have you had any luck on this one?

I have noticed that my temperatures are diverging too for no reason. I riginally solved the issue by switching to the plane wall 2d solver, however I have got the error again now.

Maximum number of iterations exceeded
 

I've been having a lot of trouble tracing the source of this error. I know it happens in the thermoI.H file, but I can't trace what is calling that, or figure out any reason why this is happening. I've had no luck trying to fix this on my own for a while now.

The case i am running is a simple wedge (meshed with snappy hex mesh) inside a blockmesh region using rhoCentral foam.

any help would be really appreciated

this is the error log file

for reference, my P/T/U files are here:

p:

T:

U:

Hi Henry,

Most probably your T value is going to negative or extremely high. To see in into T.Eqn file add Info << T.min() << " " << T.min() <<endl;

then you can understand reason.

hope it helps you.

Baris

It looks like that was the problem, but I'm lost as to how to go about solving it. What can I do to prevent T from going out of control like that?

Hey together,

could anyone please explain me how I can compile the thermo files if I want for example some output debugging in the thermoI.H file??? I somehow don't understand where these files are included in any Make/files...

Any help would be sincerely appreciated

Thanks and cheers

moritz

go to the directory that includes the thermoI.H file, and once you edit whatever debugging code you want into that file, type "wclean" and then "wcompile", which should recompile all the files in that directory for you

Hi henry,

I didnt want to do it as root but I guess it is easier. But still it's not giving me the info in my logfile I acutally wrote in the code. Why?

Ok, sorry for the stupid question. You have to compile the whole thermophysical folder if anyone faces the same problem at some point.

Thanks anyway guys!

chtMultiRegionSimpleFoam - Solution suggestion
 

Hello Everybody,

Increasing the Mesh quality by increasing the number of cells solved my divergence problem and no error massage appeared anymore.

- My mesh is created by blockMesh

- chtMultiRegionSimpleFoam has been used as a test

- I left the maximum iterations by 100 (did not followed the suggestion above)

- in my test I gave: runTimeModifiable false

I hope it can helps

Regards

Peter

Dear foamer,

I solved the problem. In my case, the error occurred because of different values for T_common in the therm.dat file. Make sure that all reactants involved in the chemical reactions have the same value for T_common. But I think in the current version this bug is already fixed.

Cheers

Your suggestion is valuable and useful:D. By unify all T_common in chemistry, I solve the problem that the temperature show non-convergence in version 3.0 with reduced chemistry. And I found another post talking about this, which might be helpful to understand the cause.http://www.cfd-online.com/Forums/ope...ombustion.html

Resolved
 

1) Reduce delta T to a order 10000 times lower than the current value.

2) Set Max Courant Number to 1

3) Set ´adjustTimeStep´ to yes

try running the solver again, if it crashes yet again, reduce the delta T even lower then try running again.

This worked for me.

The problem was with higher courant number and that leading to a diverged solution.

Dear Rahul,

We are also struggling with this issue of temperature update using N-R method. Can you share your brent method code implemented in thermoI.H file? We also feel that by using Brent method, this problem can be solved.

Hrushilesh

hi
Did you find a solution to your problem? I'm having the same problem with the compressible solver rhoSimpleFoam.
Thanks in advance!

Hi
I'm having the same ṕroblem you mentioned. Did you manage to solve it? what did you do?
Thanks in advance

Andrea

Hi srahul

I have some questions, How can make the thermoI.H file?
Can you send brent solver text in openFoam?

thanks

My mistake was...
 

Hello Everybody!

chtMultiRegionSimpleFoam has been used here!

I faced the problem also like many of you.

I tried almost everything has been written here without a success...

I increased the number of cells to a very high number (1 000 000) cells for 100 x 100 x 100 mm region(s).

That worked, but the results where very strange.

And I found the mistake I made!

I made the folowing:

- 3D Design FreeCAD then export as stl

- Used blockMesh to make my initial mesh

- In openFoam using snappyMesh to build my final mesh


The dimensions in my stl file were in mm. That means FreeCAD exports the 100...

snappyMesh read this 100 as 100 m instead of the 100 mm exported

My blockMesh mesh is also too big made (factor 1000)...

Reducing the dimensions in factor 1000 bei:

convertToMeters 0.001 in blockMeshDict

AND

in my exported stl file (FreeCAD)

Solved my problem!

Check up the dimensions (in your blockMeshDict as example) is my suggestion here.

Regards

Peter