Overlap between two superquadric particles is too large!

Dear Experts!
I set DEM SQP simulation for non-spherical particles (prolate) with an aspect ratio of 5/4.

  1. Estimated time to complete the sim goes down initially but after running a few hours it goes high. I am unable to understand this trend.

  2. And after 0.02 sec sim, MFiX solver stopped with the message ‘‘overlap between two superquadric particles is too large!’’


    My case file is attached for further insight.
    sqp54.zip (275.2 KB)
    Looking for expert review.

I ran this simulation with MFiX 23.1.1. over the weekend and got to simulation time of t=0.09 without encountering the “Overlap is too large” message.

Here’s a plot of simulation time vs real time:

At the beginning as the particles are settling there are fewer contacts to check, you can see that the slope of the curve is a bit higher. After a while the slope decreases and this is the reason for the increased estimated time to completion. It is not uncommon for the projected time to change significantly over the course of a run, as conditions change (reactions, particle collisions, etc).

I’m seeing a projected time of 28 days to complete this run. So you need to either be very patient, or find a way to make this run on more cores, or possibly find some other way to speed things up (relaxing convergence criteria, reducing number of particles, increasing time step, etc).

1 Like

Can you please upload the file that you were able to run, I want to verify something because my simulation does not even reach this point.
Thanks.

The file that ran was the one that you uploaded in sqp54.zip, I didn’t change anything in the simulation setup.

As discussed I turned off FPE traps by commenting out

//   _gfortran_set_fpe(13);

in gfortran_init.c in the master MFiX source directory. Other than that, no modifications.

Note that there are some random number generators used in MFiX so you won’t always get the same results with the same input - I’ve noticed this quite a bit lately, jobs failing, but in different ways (eg. segfault in one case, DT<DT_MIN in another). I’m working on a way to disable the randomizer (used in initial particle seeding) to get more reproducible results.

1 Like


The user used a quite large Young’s modulus for particles and walls, which is not necessary and caused the slow speed. Reduce it to 1.0*e7.

2 Likes

Dear @gaoxi I set the parameters according to https://doi.org/10.1016/j.cej.2015.04.131. and I am using the same geometry.

One source of difficulty is that the simulation fails in several different ways and the failures are not 100% repeatable. I’m working on finding a way to disable the randomization which is causing this.

In at least some of the runs, I’m seeing this behavior:





For the first millisecond, the particles fall slightly and the gas heats up. But as soon as the particles hit the bottom of the domain (0.0103s) they BLOW UP, going upward with extremely high velocity - leading to a lot of these:

Velocity exceeds limit:   200.00
in cell: I =    4   J =   21   K =    3
 Epg =   1.0000     Ug =   200.01     Vg =   7.9013     Wg =  -16.291
To change the limit, adjust the scale factor MAX_INLET_VEL_FAC.

however this does not happen every time. Here’s a run where I don’t see that:

I think this is due to two factors:

  1. As Xi indicated, the Young’s Modulus is too high, and you should also change neighbor_search_n and neighbor_search_rad_ratio.

  2. The bottom inlet is a mass inlet with constant gas velocity. This means that the pressure will become as high as necessary to achieve this fixed velocity. This leads to unrealistically high pressures when the inlet is completely blocked. Can you use a constant pressure inlet rather than a constant velocity one?

1 Like

Thanks for your insight!
Dear @cgw I am not sured about pressure BC. I set the velocity as mention in paper ( doi of paper mention earlier) as the prolate particles with aspect ratio 5/4 have sphericity about 0.99. More and less just like spherical particles.

@cgw hope you are fine.
I scale down the geometry and take only 13 particles in domain, but problem still same as sim stops at 0.01 sec.

case file attached for your reference.

testrun1.25.zip (80.5 KB)

Besides these particle, I tried different non spherical particles, but problem remain same.

Please use the Hertzian collision model for SQP simulations.

Thanks @jeff.dietiker
When I tried Hertzian Model, the following error prompts at 0.099 sim time.
please guide me further to overcome that problem.
image

case file attached as
testrun1.25_2023-06-08T234943.996273.zip (85.4 KB)

This message means that the inlet velocity has gotten unrealistically large. As mentioned previously this may be due to your use of constant mass flow rather than constant pressure - the pressure will increase to achieve the requested flow rate and this may not be physically realistic.
You can try increasing MAX_INLET_VEL_FAC to get around the checks (as the warning message suggests) but I think it would be better to study your inlet definition and understand why these high velocities occur.

@cgw thankful to your kind suggestion.
I applied Hertzian Model, increase the max_inlet_vel_fac gradually at value of 15 velocity exceeds limit check vanished.
Then I faced interesting thing, at the sim time of 0.018 sec, message generated as “overlap between two superquadric particles is too large!”
Is it possible while applying Hertzian Model, kindly guide me further to over that problem.
case file attached for review.

test1run_2023-06-09T234621.771355.zip (101.9 KB)

The “overlap is too large” message is not a fatal error. Did the case run otherwise?

Finally problem solved. Thanks for kind guidance.
I find new thing.
There was issue with solver.
image

  1. If I run the case with default\mfixsolver.exe, then it runs smoothly but required high time.

  2. If I run the case with build\mfixsolver.bat, then it generated ‘‘overlap is too large’’ and solver terminated.

  3. I build the solver as described in the post Enable parallell in windows - #9 by tyurata

When I use default\mfixsolver.exe, then processors utilization is very low.


How I can speed up the sim while utilizing maximum CPU.