DEM-Engine particles passing through boundaries

[Giovanni Bianchi]

Hello everyone!

I am simulating the compression of a granular material with DEM-Engine, and in some cases it seems that some particles pass through the mesh boundary.

I adapted the mixer demo to my case without changing anything in the contact detection parameters.

What am I doing wrong?

Giovanni

[Ruochun Zhang]

Hi Giovanni,

It's hard to say without seeing the script and the rendering. Since you are doing a compression test and DEM is penalty/penetration based, it could be just that there is so much compression that the penetration is too big, so the particles appear to be phasing through the mesh (note that if E is low and the particles are relatively large, then having visible phasing-through can be normal). It could also be that the particles are somehow under a large load (say, being compressed by an invisible boundary without the user's knowledge) and it forces the particles through the mesh. Or maybe the mesh is not oriented correctly (triangle facet normal direction) so the particles approach it from the inner side, and then phase through.

If you put here a rendering of the problem, and if you can, show the script you are using, it should be easy to diagnose.

Thank you,

Ruochun

[Giovanni Bianchi]

Thanks, Rouchun,

I link here the code that I am using and the graphic output I get from the simulation.

I don't know the exact Young modulus of the material I am using, and I am testing different values. I get this problem of particles passing through the mesh only for low values of E; instead, for high values, the simulation crashes, giving the error: " N contacts were active at time xxx on dT, but they are not detected on kT, therefore being removed unexpectedly!".

Giovanni

[Ruochun Zhang]

Hi Giovanni,

Can I also have the two mesh files you are using to test it?

Before I test, I can see the particles you are using are small (0.5mm), and the mesh is stiff and has a high Coefficient of Restitution. This makes contacts with this mesh challenging to resolve and I doubt if 5e-6 as the step size is enough. About the message you got, that should be a warning, but it is a warning when the physics is getting bad so I guess it's close to an error (you can still turn it off by setting the Verbosity from STEP_METRIC to INFO), and this could tie back to my suspicion that the time step size is far from enough.

But if I can get the mesh, I can say for sure.

Ruochun

[Giovanni Bianchi]

Thanks Ruochun,

the mesh is composed of two objects, vasca is fixed, and coperchio is moving. I share only the moving mesh otherwise I exceed the limit of MB.

Thank you very much,

Giovanni

[Ruochun Zhang]

I was able to get this script running fine by simply changing the step size to 2e-6 (it's running now. If things go wrong later on I can let you know). Of course, when you start using true material properties for your particles, this step size may need to be further adjusted. Keep in mind that large E, large CoR and small particle size make the simulation more challenging, and require smaller step sizes. I would guess if you use true material properties for everything in the simulation, then maybe 1e-6 is a good step size to start playing around.

A few comments:

1. You generally just need the verbosity level to be at INFO. If it is at STEP_METRIC, it will try to check if contact pairs are mapped normally between 2 consecutive contact detections but this is usually not needed, and costs time.

2. I saw a warning in the output: a particle may have 0 mass or MOI. This is because your MOI is super small in the simulation (~1-13). It appears to be fine in this case, but you can also consider using a different underlying unit system so the numerics are not so small for masses and MOIs. This is perhaps a minor issue.

3. I suppose you originally got a "too many contacts per sphere" error, and simply changed the tolerance in your subsequent simulations. Usually you do not need to change that threshold: Each sphere having on average more than 100 contacts is indeed strange, don't you think? That is common if the physics went bad in the simulation, and the whole system diverged. Having an error indicating particles moving at a velocity higher than the threshold is also likely linked to it (but this can depend on your unit system: for example the default threshold is 1000, but if your particles are moving at 1000mm/s then perhaps it is not abnormal, and you may want to manually change the threshold). You usually change the physics to make the simulation run, not the thresholds.

Ruochun 

[Ruochun Zhang]

Hi Giovanni,

I took a closer look. While the simulation parameters can affect, I think the main problem is actually the mesh. This is how Rhino thinks of the coperchio mesh:

As you can see, it purple part which is being complained about seems to be connecting parts of this mesh. Rhino also reports this mesh is open rather than closed. This mesh seems to be constructed out of 4 separate pieces, then put together but not properly joined at all. This has left a lot of hanging and degenerate facets, albeit not very visible if you render it. But this is enough and will for sure kill numerical simulations with this mesh.

Another proof is that when I tried to reconstruct the mesh using quadratic elements, Rhino gives cracks and holes in those regions, hinting the original mesh is not properly made:

And these places happen to be where the particle phase-through happened in this simulation. This says something.

I do not know how you obtained the mesh, but if I were to resolve the problem, I'd do this: This object can be made by a revolved solid (main body) and 20 fins generated by a circular pattern. We can make them as CAD objects and properly join them together (using boolean). After a valid solid part is created, we convert it to mesh. This should give a closed and properly conditioned mesh and I am very sure the problem will go away with a correct mesh. I would certainly suggest exploring this path before playing around more with the simulation part of things.

Thank you,

Ruochun

[Giovanni Bianchi]

Thanks a lot, Ruochun,

Your help is really appreciated!

I have generated the mesh with a CAD exactly as you suggested, but something wrong may have happened in the conversion from .stl to .obj. I will create a new mesh for the objects. 

Have a nice weekend,

Giovanni

[Giovanni Bianchi]

Hello Ruochun,

can you help me again with this issue? I checked the mesh, and now it seems to be ok, but I get this error as soon as the mesh gets into contact with the particles.

Bin 14 contains 52524 sphere components, exceeding maximum allowance (32768).
If you want the solver to run despite this, set allowance higher via SetMaxSphereInBin before simulation starts.Bin 20 contains 52524 sphere components, exceeding maximum allowance (32768).
...

...

...

-------- Simulation crashed "potentially" due to too many geometries in a bin --------
Right now, the dT reported (by user-specification or by calculation) max velocity is 0.0130244
------------------------------------
If the velocity is extremely large, then the simulation probably diverged due to encountering large particle velocities.
Decreasing the step size could help, and remember to check if your simulation objects are initially within the domain you specified.
------------------------------------
If the velocity is fair, then perhaps for some reason too many contact geometries appeared in one bin.
Are you using a contact model that promotes large penetrations, so it leads to this?
And if you are using manual bin size, then decreasing the bin size could help.

terminate called after throwing an instance of 'std::runtime_error'
  what():  GPU Assertion: unspecified launch failure. This happened in /home/giovanni/DEM-Engine/src/algorithms/DEMCubContactDetection.cu:384

I cannot understand what is happening because the velocity is small.  I have attached the code and the new mesh.

Best regards,

Giovanni

[Ruochun Zhang]

Hi Giovanni,

This is a more or less interesting case. You called the Scale method on one of your meshes with (0.01, 0.01, -0.01). With that, the current implementation will scale the mass of the mesh to a negative number. I certainly did not take into account the Scale method being called with a negative argument...

In an update which I will push very soon, I'll fix this problem. And in a way, the current implementation warns you about that too (have a look at the first few lines in the output file), but it is actually more for noting there are extremely light particles, rather than a sentry for negative masses. For now, you can fix the problem by calling SetMass and SetMOI again to the meshes (after you Scale), to overwrite the negative mass. It doesn't matter what mass you set the mesh to have, as long as it is magnitudes larger than the particle's.

I'll monitor if this is the entirety of the problem, and follow up if needed. But I suspect this is it.

Thank you,

Ruochun

[Ruochun Zhang]

To add one thing: The reason why the error message is not mentioning it, is that the negative mass somehow causes the velocity of particles to reach (-inf), even though I am querying the magnitude of the velocity. And then the max velocity reduction naturally just picks up a small positive velocity, as the outputted largest velocity. In the end, the error message did not capture the problem which now we know is still about abnormal velocity.

Ruochun

[Giovanni Bianchi]

Thanks again Ruochun,

I fixed the problem with the mass, and now the simulation runs perfectly till the end.

Best wishes,

Giovanni

[Ruochun Zhang]

Hi Giovanni,

It looks to me that the script you gave me would still diverge at some point, but it seems a known issue (large velocity) and I suppose you have to either decrease the step size or make the stiffness lower to relax the physics. The particles in use are indeed very small. But maybe you already resolved it.

Let me know if you need further clarification.

Thank you,

Ruochun