CFD Online Logo CFD Online URL
Home > Forums > OpenFOAM Running, Solving & CFD

rhoCentralFoam crashing

Register Blogs Members List Search Today's Posts Mark Forums Read

LinkBack Thread Tools Display Modes
Old   October 14, 2010, 21:08
Default rhoCentralFoam crashing
New Member
Join Date: Aug 2010
Posts: 11
Rep Power: 9
guy_smiling is on a distinguished road
Hello all,

I'm having problems with rhoCentralFoam crashing in certain test cases. Most of the time it is working well, but I'm finding that it crashes when there is a large temperature gradient over a short distance. I get the error message:

#0 Foam::error:rintStack(Foam::Ostream&) in "/opt/openfoam171/lib/linux64GccDPOpt/"
#1 Foam::sigFpe::sigFpeHandler(int) in "/opt/openfoam171/lib/linux64GccDPOpt/"
#2 in "/lib/"
#3 Foam::ePsiThermo<Foam:ureMixture<Foam::sutherlan dTransport<Foam::specieThermo<Foam::hConstThermo<F oam:erfectGas> > > > >::calculate() in "/opt/openfoam171/lib/linux64GccDPOpt/"
#4 Foam::ePsiThermo<Foam:ureMixture<Foam::sutherlan dTransport<Foam::specieThermo<Foam::hConstThermo<F oam:erfectGas> > > > >::correct() in "/opt/openfoam171/lib/linux64GccDPOpt/"
in "/opt/openfoam171/applications/bin/linux64GccDPOpt/rhoCentralFoam"
#6 __libc_start_main in "/lib/"
in "/opt/openfoam171/applications/bin/linux64GccDPOpt/rhoCentralFoam"
Floating point exception

Sometimes it seems like there's a temperature spike at one cell (T goes from ~300K to >2500K) but sometimes it seems like the solution has reached a steady state and then it just crashes. Has someone seen this before? How did you fix it?

guy_smiling is offline   Reply With Quote

Old   October 18, 2010, 09:39
Senior Member
Bernhard Linseisen
Join Date: May 2010
Location: Magdeburg/Geneva
Posts: 182
Blog Entries: 1
Rep Power: 9
Linse is on a distinguished road
While I do not remember the particular error message (had too many already with rhoCentralFoam ;-) ), quite often I could overcome failures with modification of the grid-size.

If I look at it from an engineering point of view: What should the solver do if it finds two extremely different values in neighbouring cells? I can imagine that at some point the differences just are too extreme.

If it is possible in matters of computer work-load, at this point I would increase the resolution by a factor of 2, 5 or 10. You should notice from the simulated time if that changes anything in the failure mode.
Another way could be to downscale the problem by a factor of 10 via the "convertToMeters" setting within the blockMeshDict file.

Another thing I usually do in such cases: I look at the solutions just before the failing time-step. Sometimes that already gives a clue on the problem at hand, like too coarse grids or wrongly set boundary conditions...
Linse is offline   Reply With Quote

Old   October 18, 2010, 13:31
New Member
Join Date: Aug 2010
Posts: 11
Rep Power: 9
guy_smiling is on a distinguished road
Hi Bernhard,

Thanks for the reply. What I normally do is start with a coarse mesh so that I can find a steady state solution. And then I refine the mesh (using my own blockMeshDict, not refineMesh because I find that can do things that I don't like) and run this more refined mesh. I keep refining the mesh until I don't see a significant change between iterations.

However, with this particular geometry it seems to run the coarse mesh fine, but then after refining the mesh, instead of reaching a similar solution there are some points where the temperature blows up.

I've looked at those cells where the T is high, and there doesn't seem to be much reason for it (the neighbouring cells are all fine). The cells are close to a junction but they I don't think they are skewed too much. I've also just gone to an even more refined mesh but that seems to give the same results. And I've also found the data points that I think are bad and manually changed the numbers just before blowing up, and then continued the run. This last trick seems to get me somewhere but then I have no confidence in my results.

I guess the thing that I find strange is that the error comes from the thermophysicalProperties lines when solving for rhoE. I was hoping that somehow I can just tell it to not take bad numbers so that it would avoid crashing until things stabilized. Is there a way to do that? I know that you can do
to not make it crap out when it encounters an error, but then I just get NAN and it keeps running.
guy_smiling is offline   Reply With Quote

Old   November 18, 2015, 00:46
Default Let me know if you find something
New Member
Henryk Zaleski
Join Date: Sep 2015
Posts: 3
Rep Power: 4
henryk42 is on a distinguished road
I've just encountered a similar problem. What I'm running is a modified rhoCentralFoam, I added mass transport equation to it but I think my problem is similar: crash when in Thermo.
This is what I noticed:
First, I set the U field to some value, the calculations would crash after a few iterations.
I set the U field to zero: it would run longer
Then, I changed boundary condition velocity to ramp from zero to what I wanted to be:
The calculations ran for much longer before crashing.

The model is a real world model, STEP file meshed with netgen, converted to OpenFoam.
henryk42 is offline   Reply With Quote


rhocentralfoam, thermophysicalproperties

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

Similar Threads
Thread Thread Starter Forum Replies Last Post
Viscous terms in rhoCentralFoam dohnie OpenFOAM Programming & Development 2 March 21, 2012 04:05
Running rhoCentralFoam without specification of Temperature shangzung OpenFOAM Running, Solving & CFD 1 September 17, 2010 08:52
Extremely high Temperature needed to simulate pressurization with rhoCentralFoam shangzung OpenFOAM Running, Solving & CFD 0 August 6, 2010 06:35
Solver crashing with error kasim CFX 6 February 11, 2008 07:17
Ngeom Crashing on Trimmed / Hexahedral Mesh Fr Ted Crilly Siemens 2 October 13, 2005 07:08

All times are GMT -4. The time now is 02:12.