Float invalid operation in lround

MFiX
,
#1

Hello, everyone！
When running the following case, I encountered a solver crash error at about 3.8 seconds, It indicates that float invalid operation in lround (as shown). But I didn’t find the file lround, I don’t know what it stands for and I don’t know how to modify the case to make it run smoothly, can anyone help me?
Thank you very much!

1721811464490
1721811464490795×355 58.7 KB

b0718.mfx (29.8 KB)
usr_rates.f (4.9 KB)
usr_rates_des.f (5.9 KB)

#2

Please try to build the solver with debug flags to see if it points to where it crashes:

image
image885×461 78 KB

#3

I haven’t reproduced the error yet (the simulation runs pretty slowly) but I did notice the following WARNING:

Warning: Could not find BC.
Check input file to make sure domain boundaries are defined.
DES_POS_NEW:     -0.01940       -0.07859        0.00033
I,J,K:    1   2   9
CLOSEST_PT:     -0.02000       -0.07859        0.00033
NORM_FACE:      1.00000        0.00000        0.00000
Suppressing further warnings.
#4

A few comments:
Building the solver with debug flags set adds extra checks for array bounds, which helps track down out-of-bounds array accesses. But it probably won’t help track down floating-point exceptions (FPE). And it makes the solver run much more slowly.

The real issue here is that on Windows, the FPE code is only able to print out the innermost stack frame. On Linux, we get a full stack trace. This is a longstanding issue with the Windows platform, which I would like to resolve, but at this time we don’t have a good solution.

I ran the case on Linux but it runs extremely slowly -

simtime
simtime1148×510 21.1 KB

it’s been running about 18 hours and has only reached a simulation time of 1.5s … according to your report the crash happens at 3.8s. How long did you have to run the simulation before this happened?

#5

Thank you for your reply. I seem to have been running it for more than two days and it crashed. And is there any way to increase the running speed?

#6

I ran this case on both Linux and Windows. It runs a little faster on Linux.

Linux:

simtime-2
simtime-2972×600 22.9 KB

Windows:

simtime-win
simtime-win1171×600 19 KB

This is running on identical hardware (Lenovo X280).

I have not been able to reproduce the “lround” crash. On Linux, the simulation terminated after about 36 hours, without an error message. Unfortunately, I ran into a known bug in the timekeeping code -

MFiX running, simulation time: 0:00:3.326 elapsed time: 34:29:00
MFiX running, simulation time: 0:00:3.327 elapsed time: 34:30:00
MFiX running, simulation time: 0:00:3.328 elapsed time: 2562082:17:51
MFiX running, simulation time: 0:00:3.329 elapsed time: 2562082:18:00

due to a numerical overflow, the elapsed time jumped from the correct value (34 hours, 30 minutes) to an absurdly high value (about 300 years!) and I believe this triggered the batch time limit - I’m not 100% sure about this. But I reached a simulation time of 3.439 seconds without seeing any FPE errors.

On Windows, the job is still running, I have reached a simulation time of 3.313 s after 42 hours of run time.

Since the lround crash is fairly hard to reproduce, I think the most useful things for me to work on at this point are:

  1. Fix the timekeeping overflow bug
  2. Improve the FPE trap on Windows, to print a full stack trace instead of just the innermost stack frame (this is a bit difficult but maybe I can get it to work)

To make your case run faster, the standard advice is:

  1. Use a coarser mesh
  2. Increase the maxiumum time step
  3. Increase tolerances for convergence
  4. Experiment with different discretization and preconditioning schemes (Numerics pane)
  5. Use more CPUs (this works better on Linux)

I also advise you to look at the WARNINGS printed during the run and take them seriously.

Warning: Could not find BC.
Check input file to make sure domain boundaries are defined.
DES_POS_NEW:     -0.01940       -0.07859        0.00033
I,J,K:    1   2   9
CLOSEST_PT:     -0.02000       -0.07859        0.00033
NORM_FACE:      1.00000        0.00000        0.00000

Hope this helps,
– Charles