[guy_smiling]

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/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 in "/lib/libc.so.6"
#3 Foam::ePsiThermo<Foam:ureMixture<Foam::sutherlan dTransport<Foam::specieThermo<Foam::hConstThermo<F oam:erfectGas> > > > >::calculate() in "/opt/openfoam171/lib/linux64GccDPOpt/libbasicThermophysicalModels.so"
#4 Foam::ePsiThermo<Foam:ureMixture<Foam::sutherlan dTransport<Foam::specieThermo<Foam::hConstThermo<F oam:erfectGas> > > > >::correct() in "/opt/openfoam171/lib/linux64GccDPOpt/libbasicThermophysicalModels.so"
#5
in "/opt/openfoam171/applications/bin/linux64GccDPOpt/rhoCentralFoam"
#6 __libc_start_main in "/lib/libc.so.6"
#7
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?

Cheers

[Linse]

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...

[guy_smiling]

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
unset FOAM_SIGFPE
to not make it crap out when it encounters an error, but then I just get NAN and it keeps running.

[henryk42]

Hi,
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.