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

interFoam solver crash

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

Like Tree2Likes
  • 2 Post By vatavuk

LinkBack Thread Tools Search this Thread Display Modes
Old   May 19, 2019, 16:48
Default interFoam solver crash
New Member
Join Date: Feb 2019
Posts: 15
Rep Power: 3
Kondorfa is on a distinguished road
Hi, when I run the interFoam solver it crashes from time to time. When I restart it, it passes the time where it crashed before. Is there any way to find out if any particular portion of the geometry is resposible for it?

This is the crash message, but I do not know what to learn from it. Can I find out which part of the mesh caused the crash?

[6] #0 Foam::error:rintStack(Foam::Ostream&) at ??:?
[6] #1 Foam::sigFpe::sigHandler(int) at ??:?
[6] #2 ? in /lib64/
[6] #3 double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) at ??:?
[6] #4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
[6] #5 Foam::fvMatrix<double>::solveSegregated(Foam::dict ionary const&) at ??:?
[6] #6 Foam::fvMatrix<double>::solveSegregatedOrCoupled(F oam::dictionary const&) at ??:?
[6] #7 Foam::fvMesh::solve(Foam::fvMatrix<double>&, Foam::dictionary const&) const at ??:?
[6] #8 ? at ??:?
[6] #9 __libc_start_main in /lib64/
[6] #10 ? at ??:?
[7d9dd2473fe8:02138] *** Process received signal ***
[7d9dd2473fe8:02138] Signal: Floating point exception (8)
[7d9dd2473fe8:02138] Signal code: (-6)
[7d9dd2473fe8:02138] Failing at address: 0x3e80000085a
[7d9dd2473fe8:02138] [ 0] /lib64/[0x7fa06c3f8270]
[7d9dd2473fe8:02138] [ 1] /lib64/[0x7fa06c3f81f7]
[7d9dd2473fe8:02138] [ 2] /lib64/[0x7fa06c3f8270]
[7d9dd2473fe8:02138] [ 3] /opt/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/lib/ EES5_+0x25)[0x7fa06d83df55]
[7d9dd2473fe8:02138] [ 4] /opt/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/lib/ KS2_h+0x84a)[0x7fa06d6907da]
[7d9dd2473fe8:02138] [ 5] /opt/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/lib/ egatedERKNS_10dictionaryE+0x120)[0x7fa0703ca760]
[7d9dd2473fe8:02138] [ 6] /opt/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/lib/ egatedOrCoupledERKNS_10dictionaryE+0x27f)[0x7fa06fec884f]
[7d9dd2473fe8:02138] [ 7] /opt/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/lib/ atrixIdEERKNS_10dictionaryE+0xf)[0x7fa06fe9016f]
[7d9dd2473fe8:02138] [ 8] interFoam[0x43ea20]
[7d9dd2473fe8:02138] [ 9] /lib64/[0x7fa06c3e4c05]
[7d9dd2473fe8:02138] [10] interFoam[0x444b32]
[7d9dd2473fe8:02138] *** End of error message ***

Last edited by Kondorfa; May 21, 2019 at 02:55. Reason: adding the crash report
Kondorfa is offline   Reply With Quote

Old   May 22, 2019, 11:30
Senior Member
Paulo Vatavuk
Join Date: Mar 2009
Location: Campinas, Brasil
Posts: 189
Rep Power: 13
vatavuk is on a distinguished road
Hi Kondorfa,

I have been using interFoam for some time and I noticed an error that occurs in some cases. Maybe it is the same error that you are having.

A notable symptom of this error is that delta t becomes very small, less than 10^(-10), and then after a few iterations the solver crashes. Looking at the results just before the solver crashes, it can be noticed that the velocities become very high, sometimes more that 100 m/s, mostly in the air phase. Because the solver recalculates the delta t to keep the Courant number constant the delta t becomes very small (Co=U dt/dx). These very high velocities crash the solver.

To remedy this problem I had to change the boundary conditions of the problem. You can look at the tutorials to help setting the boundary conditions. Here are some things I found important:

Inlet boundary conditions: For p_rgh use the fixedFluxPressure condition.

For Outlet boundary conditions: Normally I use zeroGradient condition for all variables, but sometimes this causes the problem that I described, especially if the flow is changing near the outlet region. A remedy is to modify the boundary condition for U using fixedValue. The value that is used has to be carefully chosen considering mass conservation, otherwise it will cause liquid to accumulate inside the flow domain. The User Guide recommends using the fixedFluxPressure for p_rgh in all boundies, but I found that zeroGrandient works better at the outlet boundary.

Best regards,
konangsh and Kondorfa like this.

Last edited by vatavuk; May 24, 2019 at 09:39.
vatavuk is offline   Reply With Quote

Old   May 24, 2019, 17:03
New Member
Join Date: Feb 2019
Posts: 15
Rep Power: 3
Kondorfa is on a distinguished road
Paulo, Thanks a lot. What you describe is exactly what I can see. Velocities in the air phase of uo to 120 m/s and the delta T- going down and down before the crash. Sometimes, starting from the latest saved time step with sligtly different settings in the controlDictionary helped to over come the time step where the solver previouls crashed. But it does not provide much confidence in the solution doing those "tricks".

What I tried now is to increase the contact angle of the water with the inner surface of the wall of the pipe. From 45 to 135. Thereby the water sticks less to the wall and moves easier along the airflow. Then the air phase does not need to flow with such high velocities around the water droplets sticking to the wall. The computation takes 4 days and I cannot yet see if it works.The issue with the pipe is only one part of the geometry, but apparently the one that causes the trouble. Cross fingers that it works now. I'll let you know.

Best regards,

Kondorfa is offline   Reply With Quote

Old   August 20, 2019, 13:39
New Member
Join Date: Oct 2016
Posts: 28
Rep Power: 6
tonnykz is on a distinguished road
Hello Kondorfa,
Have your results converged to physical solution?

I am interested as I am also struggling with icoReactingMultiphaseInterFoam on domain of size 1cmX0.1cmX0.1cm. It is just air on top of water stratified multiphase flow. But, as for now, no physical results were obtained.
tonnykz is offline   Reply With Quote

Old   August 28, 2019, 16:52
New Member
Join Date: Feb 2019
Posts: 15
Rep Power: 3
Kondorfa is on a distinguished road
Hi tonnykz,
what seemed to work in my case is to lower the maxCo value in the controlDict to values as low as 0.25 or 0.2. But then simulations are really slow.... but it got thorugh conditions were the solver previoulsy crashed ;-)

Best regards,

Kondorfa is offline   Reply With Quote

Old   August 29, 2019, 10:17
New Member
Join Date: Oct 2016
Posts: 28
Rep Power: 6
tonnykz is on a distinguished road
Thank you for suggestion.
Will try to lower CFL number.
Best regards,
tonnykz is offline   Reply With Quote


geometry?, solver crash

Thread Tools Search this Thread
Search this Thread:

Advanced Search
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 Off
Pingbacks are On
Refbacks are On

Similar Threads
Thread Thread Starter Forum Replies Last Post
2D flow around a circular cylinder case with interFoam solver shuoxue OpenFOAM Running, Solving & CFD 2 January 14, 2020 14:23
Hybrid discretisation - blend factor gcoopermax CFX 5 September 23, 2016 09:05
stability of sixDOFmotion solver with interFoam anandsudhi OpenFOAM Running, Solving & CFD 3 December 20, 2015 03:00
printstack with interFoam solver for a simple droplet on a flat plate mebinitap OpenFOAM Running, Solving & CFD 19 October 5, 2013 11:13
interFoam solver needs pdRefCell? openTom OpenFOAM Running, Solving & CFD 2 May 10, 2009 11:20

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