000_2026-06-12T125714.812202.zip (7.4 MB)
Dear MFiX community,
I am trying to simulate the filling of a box with GSP particles but I’m running into problems with the particles gaining huge velocity.
The simulation is simple, GSP particles falling from top to bottom in a square box. The particles are based on shapes of plastic granulate particles. While I’m experimenting with custom GSP shapes I found this problem to be independent of whether I generate the GSP particle or whether I use the MFiX built in.
Below is a video of the simulation with kn=20000 (as in the hopper tutorial) and the dtSolid_factor=50 which is default.
As you can see the particles are flying all over the place as soon as they come into contact with the wall on the bottom of the domain. Initially I thought this was due to too low stiffness but it seems to be there no matter what stiffness I use. I then thought it was related to the contact search stuff but I have found no combination of neighbor_search_n, factor_rlm, and neighbor_search_rad_ratio that improves the result. If I set neighbor_search_n=1 it still happens. The only solution I have found is setting dtSolid_factor=500, i.e. 500 times the calculated collision time. The video of that is below:
As you can see it works well with only some very infrequent motion that looks unphysical. The problem is that using dtSolid_factor=500 naturally makes the simulation very very slow. And furthermore my gut feeling says that the real issue is something with the contact algorithm (not bug just settings) that is going wrong and using a very small time-step is an expensive way to solve the underlying problem. So that leads me to my question
Questions: Has anyone else had a problem where they need a dtSolid_factor (DEM time-step) of several hundreds when using GSP particles? Is it just how it is or am I missing something? What would you do to investigate this further?
Best Regards,
Simon
As I remember, I used the equivalent diameter to determin the solid time step size, the equivalent diameter is calculated based on the overall volume of the gsp. Most of the time it will be fine but in some special cases, ex. the existence of very small components or very high speed, this time step size is not enough, you will want to have the time step size depending on the smallest component sphere.
Some people prefer to employ component spheres of identical radius, accepting a slight sacrifice in mass conservation or geometric fidelity but that’s not the case in MFIX, that’s one thing you can try.
In mfix built-in generator, we also have a function to remove very small components, I think this will also help to increase solid dt. You might also want to have smaller contact stiffness as well. 20000 is pretty large more than sufficient. Anyway, sometimes it is really a pain to adjust the time step.
Thanks for the answer! That makes a lot of sense. I think the collision time-scale should scale with the component sphere size, so if the time-step is unchanged when more spheres are added to a GSP particle and the individual sphere becomes smaller, that should lead to problems. I guess I should have checked this first but I was just so convinced I was doing something wrong…
For the next person coming across this problem, I created a minimal example where I spawn GSP particles based on a simple superquadratic with 4x1x1, 4x2x2, 4x3x3 spheres. This is a simple way to change component sphere sizes without getting any really small spheres. See images below:
I then spawn the particles from the top falling down in a simple square domain.
I wrote down the DEM time-step for each simulation and it yielded
GSP 4x1x1 - dt_solid=0.414423E-04 s
GSP 4x2x2 - dt_solid=0.366915E-04 s
GSP 4x3x3 - dt_solid=0.366915E-04 s
So the time-step is basicly unchanged despite the component spheres becoming much smaller.
Below is the videos of each of the three cases where its clear that only the 4x1x1 case has a sufficiently small time-step.
If I take the case with 4x2x2 and set dtsolid_factor=100 (2x the default 50) we get a working simulation.
Hopefully, that will be useful for the next person stumbling into this.
Again thank you for the quick response it is simply amazing!
000_2026-06-13T141612.574061.zip (1.2 MB)
