Type of issue
As per title: SIGSEGV error occurs when using a mass inlet with SQP particles. Particles from ‘initial conditions’ behave fine, but new ones from mass inlet cause a crash as soon as they touch either the existing particles or the base of the system.
Description
Particles from ‘initial conditions’ behave fine, but new ones from mass inlet cause a crash as soon as they touch either the existing particles or the base of the system. The simulation is the ‘mass inlet with SQP’ with changes to the SQP properties.
I’m running via anaconda on Ubuntu 22.04 LTS.
Attempts to fix the issue
I’ve built the solver with FPE traps commented out, but obviously that doesn’t stop segmentation errors. if I use more than 1 thread on SMP, I get SIGSEGV earlier in the simulation. The more threads I use, the earlier the crash happens. with a single thread, all the initial particles fall and collect on the base of the system, but the solver crashes as soon as a single particle from the inlet comes into contact with anything else.
I’ve tried changing the particle properties (Youngs modulus, friction coefficients etc) without success.
I would try with DMP instead of SMP but no compiler appears when I select DMP in the solver builder. This may be due to issues with mpi support on my local system - I’m getting support locally with this.
I’ve tried attaching the bug report zip file but I’m not sure it finished uploading.
First step in debugging is to run the job in serial mode (single CPU, no SMP or DMP).
Doing this, I get:
Error: There exists a NORMAL particle in a GHOST cell.
Particle may have gone OUT-OF-BOUNDS.
To resolve this issue, please consider:
a) Verify all wall boundary conditions are defined
b) Reducing the value of the variable NEIGHBOR_SEARCH_N (Solids>DEM>Max steps between neighbor search)
c) Increasing the particle and/or wall stiffness (Solids>DEM>Normal spring constant or Young's modulus)
Current particle location (x, y, z coordinates): 0.1017 , -0.1464E-02, 0.1390
Current particle velocity (u, v, w components) : 324.5 , -2282. , -1257.
at simulation time 0.267s (after about 25 minutes of realtime)
This looks like the new datacheck that will come with the 23.3 release. The high velocities indicate you have some particles shooting out of the domain, possibly due to large overlap.
Thanks both. I’ve already tried turning the Young’s modulus up, so the time step is under 1E-6 s. In my most recent test, the log doesn’t report any large overlaps until the timestep where the solver crashes. The initial bed settles fine (even if I make it 4x taller) , it’s just particles coming from the inlet that are causing the problem.
I’m currently trying a similar system with fluid flow (based on the SQP fluidised bed example) and that seems to be behaving much better, even with timesteps of 3E-4 seconds. But I haven’t tried a mass inlet on that yet - I’ll report back when I have.
I cannot explain why the inlet particles behave differently form the initially seeded particles. Looking at the code, it seems that all variables are properly initialized. The only way I could get it to run is to significantly increase the restitution coefficient, above 0.9.
I think there’s something to do with orientation that’s going wrong. I’m just running a test and will post again later. However, if I:
Drop the initial solids fraction to ~1e-5 so there are only a few particles present, and
turn off random orientation for the inlet and
have the SQP orientation a the default (1,0,0,0), then
the particles from the inlet bounce off the base, unless they happen to hit one of the initial particles, in which case the solver either loops or crashes.
If I alter the SQP orientation so the needles are angled partly downwards, they mostly sail through the base and disappear. Occasionally the solver will crash.
It’s definitely not about velocity - I can set the initial particles with a high downward velocity and they behave just fine, even if angled. The sim I’m running just now has 1680 angled needles hitting the base at 2.5 m/s and they’ve all survived, no solver crash, and a mere 30 minutes to simulate 0.075s
needles2_2023-09-29T162459.5_seeds_angled.zip (22.9 MB) needles2_2023-09-29T160915.lots_seeds_angled.zip (18.9 MB)
Here are the files I was just using to test.
The ‘lots_seeds’ file I only ran for 80 ms, but all of the seed particles interacted properly and the number of particles didn’t change from start to end.
The ‘5_seeds’ file only takes a minute or so. The seeds behave fine, but the inlet particles don’t interact with the base, and the solve crashes if they hit a seed.
If I reorient the inlet particles so they’re either vertical or horizontal, they do interact with the base, but the solver crashes again if any of them get knocked over.
Thanks a lot for this detailed analysis. It will take us a little while to get to the bottom of this (no pun intended) but we are definitely interested and will pursue this.
