Hello， developers!
For the same case, using cylindrical particles with m=2 and n=4 can successfully calculate, but using m=2 and n=6 for a period of time will result in the following error, and I have turned off the detection of floating-point anomalies. Thank you！
If you have turned off floating point exception (FPE) catching, this should not happen.
Can you please tell me what version of MFiX you are running, and how you disabled FPE’s? Please submit a full bug report. Thank you!
Thank you for your reply！@cgw
I closed the floating-point exception as shown in the photo below. Is this correct? Thank you for your help!
Let me check. Disabling FPE here should prevent the system error. But this is a new feature and perhaps it does not work correctly. I will follow up on this.
Thank you for your reply! @cgw
I closed the floating-point exception according to the above operation, but still reported an error. May I ask how to properly close the floating-point exception. Thank you！
Hi @Zhangxutong
I notice a few interesting things running your case n6
First of all, the controls for “Floating point exception traps” do not seem to work correctly. I am seeing FPE backtraces even with these boxes un-checked. As I said above, this is a new feature and hasn’t had much testing, I will work on it for the next release.
Second - I am getting a different error than the one you reported, but only when I run in SMP mode. In SMP mode, shortly after starting the run I see:
Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.
Backtrace for this error:
#0 calc_collision_wall_MOD_calc_dem_force_with_wall_stl._omp_fn.0
at des/calc_collision_wall_mod.f:398
#1 calc_collision_wall_MOD_calc_dem_force_with_wall_stl._omp_fn.0
at des/calc_collision_wall_mod.f:411
#2 GOMP_parallel
at ../../../libgomp/parallel.c:178
#3 calc_collision_wall_MOD_calc_dem_force_with_wall_stl
at des/calc_collision_wall_mod.f:138
#4 sq_calc_force_mod_MOD_calc_force_superdem
at des/sq_calc_force_superdem.f:131
The offending code:
392 ! Calculate the particle/wall overlap.
393 DISTMOD = SQRT(MAX_DISTSQ)
394 if (SuperDEM .and. shape_ll .gt. 0) then
395 OVERLAP_N = DISTMOD
396 NORMAL(:)= - norm_wall(:)
397 else
398 NORMAL(:) = DIST(:)/sqrt(DISTSQ)
399 OVERLAP_N = DES_RADIUS(LL) - DISTMOD
400 endif
The error is happenng at 398 and the debugger tells us that the variable DISTSQ is 0
398 NORMAL(:) = DIST(:)/sqrt(DISTSQ)
(gdb) print distsq
$1 = 0
However I only see this when running in SMP mode.
When you got the xpow exception reported above - were you running SMP, DMP or serial? How many processes/threads? And how long did you have to wait until you saw the exception?
Thanks for the bug reports, we will get this sorted out!
– Charles
How long do you typically have to run the simulation before seeing this error?
Hello！@ cgw
I also want to ask you a question. I wrote the code for outputting kinetic energy in vtp_mod.f file, but I need to save trans_e in an array instead of a scalar. Can you teach me how to write the code? Thank you very much for your help.
FB_SQP_1.zip (30.4 MB)
If you need a fix for this right away:
Activate the mfix environment, and edit the file
$CONDA_PREFIX/share/mfix/src/gfortran_init.c
and remove or comment out line 11: _gfortran_set_fpe(13)
Before:
6 int gfortran_init_() {
7 int opts[] = {68, 511, 1, 1, 1, 63};
8 char *argv[] = {"python", "-m", "mfixgui.pymfix"};
9 _gfortran_set_args(3, argv);
10 _gfortran_set_options(6, opts);
11 _gfortran_set_fpe(13); // default: zero, overflow, invalid
12 return 57;
After:
6 int gfortran_init_() {
7 int opts[] = {68, 511, 1, 1, 1, 63};
8 char *argv[] = {"python", "-m", "mfixgui.pymfix"};
9 _gfortran_set_args(3, argv);
10 _gfortran_set_options(6, opts);
11 return 57;