Floating-point invalid operation / erroneous arithmetic operation

[kjetilbmoe]

Still here trying to solve a bubbling bed with conical inlet. I found someone with a similar geometry also having similar errors just recently (link below), so that’s why I’m posting this as a potential bug. At the moment I get these errors just before (litterally at the moment) .vtk’s are written, so I’m starting to think this is related. However, I’m not able to see from the error what actually goes wrong. I have been working on simplifying the case, removing phases etc., so perhaps there are some unremoved remains from previous cases that stir things up. Just a thought. (And, perhaps of interest, as a part of my ongoing troubleshooting, I’ve switched to the Crank-Nicholson scheme, which so far yields a somewhat odd DT plot.)

The spouted bed geometry was drawn with 3 boxes in mfix, but did not work

[image] [image] I tried to use three boxes to draw the spouted bed geometry, but the mfix error, there is no specific reason, I think it may be their own entrance and wall boundary condition settings, can anyone help me? Thank you geometry_0003.stl (1.6 MB) spout.mfx (15.1 KB) geometry_0003.stl (1.6 MB) error message： Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: #0 0x7f000e0bf20f in ??? #1 0x7effc1101ea8 in __dg…

[fedora:468600:0:468629] Caught signal 8 (Floating point exception: floating-point invalid operation)
==== backtrace (tid: 468629) ====
 0  /lib64/libucs.so.0(ucs_handle_error+0x2a4) [0x7f4e0e658794]
 1  /lib64/libucs.so.0(+0x2a34d) [0x7f4e0e65c34d]
 2  /lib64/libucs.so.0(+0x2a62a) [0x7f4e0e65c62a]
 3  /home/kjetil/MFiX/3D CSiC/3d_csic_1_2-bedremesh2/mfixsolver.cpython-38-x86_64-linux-gnu.so(__leq_bicgs_mod_MOD_leq_bicgs0+0xc3a) [0x7f4e2da5df5a]
 4  /home/kjetil/MFiX/3D CSiC/3d_csic_1_2-bedremesh2/mfixsolver.cpython-38-x86_64-linux-gnu.so(__leq_bicgs_mod_MOD_leq_bicgs+0xf1) [0x7f4e2da5eb81]
 5  /home/kjetil/MFiX/3D CSiC/3d_csic_1_2-bedremesh2/mfixsolver.cpython-38-x86_64-linux-gnu.so(__solve_lin_eq_mod_MOD_solve_lin_eq+0x676) [0x7f4e2d9013d6]
 6  /home/kjetil/MFiX/3D CSiC/3d_csic_1_2-bedremesh2/mfixsolver.cpython-38-x86_64-linux-gnu.so(__solve_vel_star_mod_MOD_solve_vel_star+0x187c) [0x7f4e2d905aec]
 7  /home/kjetil/MFiX/3D CSiC/3d_csic_1_2-bedremesh2/mfixsolver.cpython-38-x86_64-linux-gnu.so(__iterate_MOD_do_iteration+0xe8) [0x7f4e2d6c72d8]
 8  /home/kjetil/MFiX/3D CSiC/3d_csic_1_2-bedremesh2/mfixsolver.cpython-38-x86_64-linux-gnu.so(run_mfix_+0x2c5) [0x7f4e2d88c515]
 9  /home/kjetil/MFiX/3D CSiC/3d_csic_1_2-bedremesh2/mfixsolver.cpython-38-x86_64-linux-gnu.so(__main_MOD_run_mfix0+0x33) [0x7f4e2d6c9e93]
10  /home/kjetil/MFiX/3D CSiC/3d_csic_1_2-bedremesh2/mfixsolver.cpython-38-x86_64-linux-gnu.so(+0x77bbd) [0x7f4e2d6bdbbd]
11  /home/kjetil/anaconda3/envs/mfix-21.3.2/bin/python3.8(_PyObject_MakeTpCall+0x31e) [0x55929bd2330e]
12  /home/kjetil/anaconda3/envs/mfix-21.3.2/bin/python3.8(_PyEval_EvalFrameDefault+0x53cf) [0x55929bdb96ff]
13  /home/kjetil/anaconda3/envs/mfix-21.3.2/bin/python3.8(_PyFunction_Vectorcall+0x1a6) [0x55929bd97fc6]
14  /home/kjetil/anaconda3/envs/mfix-21.3.2/bin/python3.8(_PyEval_EvalFrameDefault+0xa63) [0x55929bdb4d93]
15  /home/kjetil/anaconda3/envs/mfix-21.3.2/bin/python3.8(_PyFunction_Vectorcall+0x1a6) [0x55929bd97fc6]
16  /home/kjetil/anaconda3/envs/mfix-21.3.2/bin/python3.8(_PyEval_EvalFrameDefault+0xa63) [0x55929bdb4d93]
17  /home/kjetil/anaconda3/envs/mfix-21.3.2/bin/python3.8(_PyFunction_Vectorcall+0x1a6) [0x55929bd97fc6]
18  /home/kjetil/anaconda3/envs/mfix-21.3.2/bin/python3.8(+0x1b0841) [0x55929bd98841]
19  /home/kjetil/anaconda3/envs/mfix-21.3.2/bin/python3.8(PyObject_Call+0x5e) [0x55929bd0d16e]
20  /home/kjetil/anaconda3/envs/mfix-21.3.2/bin/python3.8(+0x253ca9) [0x55929be3bca9]
21  /home/kjetil/anaconda3/envs/mfix-21.3.2/bin/python3.8(+0x1ecea4) [0x55929bdd4ea4]
22  /lib64/libc.so.6(+0x8db17) [0x7f4e86fc1b17]
23  /lib64/libc.so.6(+0x1126c0) [0x7f4e870466c0]
=================================

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x7f4e86f7675f in ???
#1  0x7f4e2da5df5a in __leq_bicgs_mod_MOD_leq_bicgs0
	at /home/kjetil/anaconda3/envs/mfix-21.3.2/share/mfix/src/model/leq_bicgs.f:476
#2  0x7f4e2da5eb80 in __leq_bicgs_mod_MOD_leq_bicgs
	at /home/kjetil/anaconda3/envs/mfix-21.3.2/share/mfix/src/model/leq_bicgs.f:91
#3  0x7f4e2d9013d5 in __solve_lin_eq_mod_MOD_solve_lin_eq
	at /home/kjetil/anaconda3/envs/mfix-21.3.2/share/mfix/src/model/solve_lin_eq.f:165
#4  0x7f4e2d905aeb in v_m_star
	at /home/kjetil/anaconda3/envs/mfix-21.3.2/share/mfix/src/model/solve_vel_star.f:530
#5  0x7f4e2d905aeb in __solve_vel_star_mod_MOD_solve_vel_star
	at /home/kjetil/anaconda3/envs/mfix-21.3.2/share/mfix/src/model/solve_vel_star.f:136
#6  0x7f4e2d6c72d7 in __iterate_MOD_do_iteration
	at /home/kjetil/MFiX/3D CSiC/3d_csic_1_2-bedremesh2/build/pymfix/iterate.f90:255
#7  0x7f4e2d88c514 in run_fluid
	at /home/kjetil/anaconda3/envs/mfix-21.3.2/share/mfix/src/model/mfix.f:188
#8  0x7f4e2d88c514 in run_mfix_
	at /home/kjetil/anaconda3/envs/mfix-21.3.2/share/mfix/src/model/mfix.f:142
#9  0x7f4e2d6c9e92 in __main_MOD_run_mfix0
	at /home/kjetil/MFiX/3D CSiC/3d_csic_1_2-bedremesh2/build/pymfix/main.f90:81
#10  0x7f4e2d6bdbbc in f2py_rout_mfixsolver_main_run_mfix0
	at /home/kjetil/MFiX/3D CSiC/3d_csic_1_2-bedremesh2/build/f2pywrappers/mfixsolvermodule.c:1270

[kjetilbmoe]

Okay - so this is now confirmed, disabling vtk output removes at least this error. At least that’s something. Would be good to know how this can be fixed.

[kjetilbmoe]

The next crash happened when writing SPx files at 1.0 seconds.

[kjetilbmoe]

Sorry for generating what feels like a bit of noise.
However, I have run the 3D TFM tutorial, and this does not reproduce the same errors, so there must be something with my setup or mesh that does this…

[cgw]

Hi Kjetil - no worries at all. If you’re getting segfaults/FPEs out of the solver, we want to know about it. Thanks for sending the reports. I’ll look at this this week as soon as I can.

– Charles

[cgw]

@kjetilbmoe - the FPE you are seeing is happening in the exact same place as in this posting What dose this change mean? - #2 by cgw

Note that in version 21.2 we changed the algorithm used for solving tridiagonal matrix equations. Commenting out the code between lines 186 and 207 in DGTSV.f causes MFiX to revert to the older, slower algorithm. When I tried that, instead of the FPE, I got a message

leq_iksweep 152 0

repeated hundreds of times, followed eventually by

Error from time_step.f:193
DT < DT_MIN.  Recovery not possible!

[kjetilbmoe]

Thanks. Could this be related to the meshing not being uniform, using Y control points to concentrate the mesh in certain regions? This is one common thing for the failing cases.

[kjetilbmoe]

Returning to this error, I have now reproduced this to happen to when writing VTK files. This is also happening just after I restart a run and switching numerics to Superbee from Upwind. It is not reproduced (at the same timestep at least) when numerical scheme is left at Upwind.

Could existing .vtu files in the folder and the VTU_FRAME_INDEX.TXT cause this error?

@cgw