DEM particles unrealistic behavior

Dear forum,

I have been struggling for some time to make a case work correctly and I am looking for your support/advice. The case consists in a CGP simulation, with an internal in the center of a bed close to umf conditions. The internal also releases gas in its perimeter. The problem appears at the bed surface, where the particles unrealistically bounce. I know this is a common issue, and I have checked that there are no .stl facets missing and I have reduced neighbor_search_n to 1, but I still see this unrealistic behavior. This also happens for non-slip front and rear walls. I have also tried des_neighbor_search = 1, but the case becomes extremely slow.

I don’t know what else to check to avoid this unrealistic behavior of the particles. Do you have any recommendation? Please see attached the video of the behavior of the particles and the files that generate this behavior, including the .stl geometry.

Thank you very much for your help!


biomasa_geom_new.stl (230.6 KB)
umf_biomass.mfx (18.1 KB)

Hello,

I have continued making some trials which comprise changing the wall-particle spring stiffness, the mesh, and modifying the advanced options in the DEM settings. I am still getting this unrealistic behavior of the particles. Seems as if the collisions between the particles and the internal volume cause this unrealistic high velocity.

Could someone please provide some piece of advice to avoid this?

Thank you!

Are you running on Windows? It runs fine with me on Linux with the DMP solver.

Thank you for the answers. I am running on a linux cluster. DMP solver with 4x9x1 partitions. The case runs smoothly, but there is this unstable behavior of the particles in the vicinity of the internal. Could it be that the DMP partitions are causing this?

That is unlikely, I was using 4x10x1 decomposition. What compile and MPI version are you using? Can you try in debug mode, to see if this makes a difference?

I have compiled in debug model and recreated the model from scratch for Linux. I saw that, when opening the model in the GUI, some of the values were changing, as they were defined in the GUI and then changed manually in the .mfx before running in the cluster. That is: the values in the .mfx attached before are the right ones (the ones corresponding to the video), but if that is opened in a GUI, one ends-up in a different case.

Could you please check if in the case you are running ic_y_n(2) = 0.120? That case seems to be the most unstable, as the bed surface is just on top of the internal. Cases with larger bed heights seem to work better, probably because the high-velocity particles are dumped by the rest of particles in the system.

Apart from that, please see below the output from my compilation in the cluster. I am running now in debug mode. I will see what happens in a couple of hours.

Thank you very much for your help!

– Setting build type to ‘RelWithDebInfo’ as none was specified.
– MFIX build settings summary:
– Build type = RelWithDebInfo
– CMake version = 3.25.1
– Fortran compiler =
– Fortran flags =
– ENABLE_MPI = 1
– ENABLE_OpenMP = OFF
– ENABLE_CTEST = OFF
– ENABLE_COVERAGE = OFF
– The Fortran compiler identification is GNU 11.3.0
– The C compiler identification is GNU 11.3.0
– Detecting Fortran compiler ABI info
– Detecting Fortran compiler ABI info - done
– Check for working Fortran compiler: /apps/GCCcore/11.3.0/bin/f95 - skipped
– Detecting C compiler ABI info
– Detecting C compiler ABI info - done
– Check for working C compiler: /apps/GCCcore/11.3.0/bin/cc - skipped
– Detecting C compile features
– Detecting C compile features - done
– Performing Test ffpe_trap
– Performing Test ffpe_trap - Success
– Performing Test ffpe_summary
– Performing Test ffpe_summary - Success
– Found MPI_C: /apps/OpenMPI/4.1.4-GCC-11.3.0/lib/libmpi.so (found version “3.1”)
– Found MPI_Fortran: /apps/OpenMPI/4.1.4-GCC-11.3.0/lib/libmpi_usempif08.so (found version “3.1”)
– Found MPI: TRUE (found version “3.1”)
– Found Git: /home/edu/.conda/envs/mfix-22.4.1/bin/git (found version “2.39.1”)
– Configuring done
– Generating done
– Build files have been written to: /DATOS/home/edu/build
Build command:

cmake --build . --target install

Hello,
I have checked the simulation run in the debug mode and I still see the unrealistic behavior of particles. Please see attached the resulting video.
Thanks for your help!

Hello,
just for info. I have performed a simulation with ic_y_n(2) = 0.120 in windows (SMP solver) and I am still getting this unstable behavior in the surface of the bed in the region of the internal.

Thank you for your help.

I don’t think particles are actually bouncing unphysically. It looks more like you get large velocities on the side of the cylinder and particles get blown away. Do you have reference data that show the expected behavior?

Hello Jeff,

thank you for your answer. It took me some time. But please see attached again a slightly longer video of the behavior of the particles. I am collecting the reference data to try to show you the expected behavior, but can confirm that the bouncing of the particles seems unphysical. Please note that, in the video, sometimes there is “an explosion” of particles and they get suddenly ejected from the internal cylinder. In fact, this does not occur if, in the simulation, we cover the cylinder with particles. Could it be an issue with the superDEM? I am also investigating the heat transfer behavior of this system (even with this weird bouncing) and I am experiencing some convergence issues. I will open a parallel topic on this regard.

Thank you!

Can you please zoom into the cylinder and color particles by velocity magnitude?

Hi Jeff,
please see attached the video. The velocity scale is 0-1 m/s.
Thank you!

Dear Jeff,

Regarding this point. It looks that both decreasing the particle-wall spring constant and increasing the DEM time step factor seem to reduce the bouncing behavior of the particles. It looks as if the particles can easily penetrate the .stl geometry and they get suddenly ejected by this penetration (especially if the spring constant is big, which creates these huge velocities). For me it is a bit counterintuitive, as I would expect a better behavior with a larger kn_w. I am wondering now on the lower limit of the particle-wall spring constant. The attached video (still a bit short, but the improvement is significant) uses kn_w = 10 and dtsolid_factor = 75. In fact, I increased neighbor_search_n to the default value of 25, as the problem did not seem to come from that side.

Do you think the behavior of the system could be further improved by decreasing the value of kn_w or further increasing dt_solid factor? Is there any practical or theoretical lower limit to kn_w (apart from the possible penetration of the particles into the STL geometry)?

Thank you very much for your help!

Have you tried to lower the restitution coefficient? This may help. kn_w=10 is really low and particles may go through the wall.

Another thing you can try is to drop a layer of particles on the cylinder to see how they bounce. I am still wondering if the energetic bouncing comes from particle-wall or particle-particle interaction.

Dear Jeff,

thank you for the suggestion. That’s how I actually came up with such a low value of kn_w and the fact that dtsolid_factor was improving things. From the tests, I deduced that it was a particle-wall interaction issue. Please see attached the files for the case I used as a trial. It seems that decreasing the restitution coefficient also helps a bit, but I’d have to launch a long case to see the differences.

In any case, even with kn_w=10 I am still seeing some unrealistic bouncing (but no penetration inside the cylinder) and, in fact, there is some air bubble permanently under the cylinder that I don’t know if it is related with such a low value of kn_w.

Any ideas on how to further improve this without using such a low kn_w or dramatically reducing the restitution coefficient?

Thanks!
geometry.stl (1.2 MB)
geometry.stl (1.2 MB)
umf_biomass.mfx (18.2 KB)

Dear Jeff,

I am still working on this regard. I have done several tests and, despite the restitution cofficient seems to help, I still observe this unrealistic behavior of particles. Thus, I believe I’ll have to stick to unrealistic low values of kn_w.

Is there any other possibility (e.g., playing with the resolution of the geometry, or some other parameters) or we shall close this topic?

Thank you very much again for your kind help.