interFoam solver crash
 

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::printStack(Foam::Ostream&) at ??:?
[6] #1 Foam::sigFpe::sigHandler(int) at ??:?
[6] #2 ? in /lib64/libc.so.6
[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/libc.so.6
[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/libc.so.6(+0x35270)[0x7fa06c3f8270]
[7d9dd2473fe8:02138] [ 1] /lib64/libc.so.6(gsignal+0x37)[0x7fa06c3f81f7]
[7d9dd2473fe8:02138] [ 2] /lib64/libc.so.6(+0x35270)[0x7fa06c3f8270]
[7d9dd2473fe8:02138] [ 3] /opt/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam7sumProdIdEEdRKNS_5UListIT_ EES5_+0x25)[0x7fa06d83df55]
[7d9dd2473fe8:02138] [ 4] /opt/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZNK4Foam3PCG5solveERNS_5FieldIdEER KS2_h+0x84a)[0x7fa06d6907da]
[7d9dd2473fe8:02138] [ 5] /opt/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so(_ZN4Foam8fvMatrixIdE15solveSegr egatedERKNS_10dictionaryE+0x120)[0x7fa0703ca760]
[7d9dd2473fe8:02138] [ 6] /opt/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so(_ZN4Foam8fvMatrixIdE24solveSegr egatedOrCoupledERKNS_10dictionaryE+0x27f)[0x7fa06fec884f]
[7d9dd2473fe8:02138] [ 7] /opt/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so(_ZNK4Foam6fvMesh5solveERNS_8fvM atrixIdEERKNS_10dictionaryE+0xf)[0x7fa06fe9016f]
[7d9dd2473fe8:02138] [ 8] interFoam[0x43ea20]
[7d9dd2473fe8:02138] [ 9] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fa06c3e4c05]
[7d9dd2473fe8:02138] [10] interFoam[0x444b32]
[7d9dd2473fe8:02138] *** End of error message ***

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,
Paulo

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

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.

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,


K.

Thank you for suggestion.
Will try to lower CFL number.
Best regards,
Tonnykz