I am trying to model a 3D spouting bed with a complex internal geometry. To simplify the case and get the simulation and mesh parameters honed in I removed the internal geometry and settled the bed. For the base case I got particles to settle by incrementally moving an internal non-permeable boundary down. The DEM velocities were all reasonable, as seen below:
The final geometry is the base case with an additional section connected to the bottom of the domain to form an internal geometry. When the IS placed above the cone (Y=0.84). The settling particles velocity is reasonable.
When the IS is moved down (Y=0.64) the velocities increase gradually as would expected for particles in free fall. But then it jumps an order of magnitude (0.3m/s to 91m/s). These particles is in the middle of the domain. I keep getting particles in ghost cells errors as these high speed ones go straight through my walls.
Increasing the damping constant between DEM particles to try and dissipate the velocities does not work. The spring constant between particles is the default value and the wall is x500 larger, and still get particles in ghost cells.
Any idea why or how these high velocities originate or how I can get rid of it to get the case settled? It seems like its an issue when importing the complex geometry STL.
The default kn may be too low. Maybe the weight of the bed is too much for the soft particles, which triggers an excessive overlap and huge forces, thus large velocities.
Hi Gbotha, you can check the grid size, make sure that the size is bigger than 2RLM_factorparticle diameter when cell-linked (or grid-based) particle neighbor search algorithm is used.
I have a simplified test case where I only modeled the top cone to test the settling, constant and mesh. For this case the particles followed the expected behavior and it settles fine. The geometry with the internal surface is just an extension of the test case in the -y-direction, with the same mesh resolution, particle count and constants. Unsure how can effect the bed so much.
Did you change any of the mesher options? Specifically, have you messed with the default stl_small_angle? I’ve seen a DEM case in the past where a user set that keyword to zero (to avoid losing facets), but that can let malformed facets with a zero angle through. The case ran fine until a particle touched one of those facets, at which point the particles would go nuts.
When decreasing stl_small_angle to 0.0 these mesh artifacts are removed. Increasing the mesh resolution with the default mesher parameters keep giving me bad meshes.
Can you get a good mesh with a non-zero value for stl_small_angle, say O(1.0e-9)? If not, I would try creating a new mesh as a zero value for stl_small_angle will continue to give you trouble.
As a side note – If your STL has a good mesh (no crazy aspect ratios or mal-formed facets), sometimes just shifting your geometry very slightly (0.02*dx, 0.02dy, 0.02dz) can improve the resulting mesh.
The majority of the STL are pretty large triangles. The internal surfaces to have smaller, high aspect ratio facets to capture the geomerty. I will try increasing it.
I re-meshed and used a STL with coarser triangles. With stl_small_angle = 0.1 the particles still behave with irregular high velocities. It seems the happen when the particles move over the internal surface.
Attached the .mfx and output file if that can give any insight, unfortunately I can not share the STL file.
The code does a fairly reasonable job on picking values for the DES grid search parameters (desgridsearch_imax etc.). I leave these undefined most of the time and recommend you unset them.
Reduce the Max steps between neighbor search (neighbor_search_n) from 25 to 5. It could be that a collision is getting missed and a more frequent update will fix that.
Unfortunately, both of these adversely impact time to solution, but hopefully they’ll prove you some stability. I’ll leave the case you provided running overnight, but without the actual case, it’s possible I won’t see what you are experiencing.
Removing the desgridsearch_jmax gives me a fatal error as the DEM grid spacing is just larger than the base. I am setting it equal to the base size, or should i decrease it?
Ill decrease the max steps and see what it does.
I know its difficult troubleshooting without the case.
I made some tweaks to your case last evening and it seemed to run. I’m rerunning it now with fewer modifications. Ignore the watermark. I have a script that generates animations that includes it by default.
The high velocities still appear as soon as the internal surface is lowered below y=0.2. Here is a slice of the mesh at that height. The mesh seems okay?
