LIGGGHTS® - User Forum

DEM simulation of granular material using original particle size of 1 mm run for a while and then terminate automatically, while the when particle size increased to 5x-10x then simulation run correctly. What could be the reason for this? how this issue can be solved.

Hi everyone,
I'm try to simulae a tumbling mill and I want to estract some data such as the impacts number and the impact energy of the particles;

Hello everyone!
I'm trying to simulate a ball mill and I'm using at the moment a very simple geometry to obtain acceptable computation times since I'm learning now LIGGGHTS. While looking at the documentation page, I read about the possibility to assign variables instead of exact values to both the magnitude and the direction of hte gravity vector and I was thus wondering if there's a way to avoid heavy computation by using this trick instead of moving he mesh.

As a first attempt, I first inserted the particle into my geometry using a classical gravity vector, using:

Hi all,

I have got question about how to compile the 'in.filename' in parallel without copy executable 'lmp_auto' into the same folder. As suggested by the Liggghts documentation that the final step to make it compiled is

"cp lmp_auto ../examples/LIGGGHTS/Tutorials_public/chute_wear
cd ../examples/LIGGGHTS/Tutorials_public/chute_wear
mpirun -np 4 lmp_auto < in.chute_wear"

Hello,

I'm facing a problem in pair_colloid.cpp
I designed a small testcase containing just 2 particles, radius 0.01µm and varying the initial distance between them. They are underlaying DLVO potential by hybrid overlay colloid and yukawa/colloid
For larger initial distances the simulation is working. At a distance of 2µm I get an unspecific error (seems like division by zero). For distances smaller than 2µm I get the error: "Overlapping large/large in pair colloid" (line 187 of pair_colloid.cpp).

Hi, after running :

examples/LIGGGHTS/Tutorials_public/superquadric/in.particle_particle

When I open the dump files in Paraview the variables quad1, qaud2, qaud3, quad4 are missing, while shape x,y,z and blockiness 1,2 are present. I would like to check the initial settings for quad. Does someone know why these values are missing?

(The Liggghts version is 3.8.0 and I used 'make auto' in the src folder then copied the lmp_auto executable to run the code.)

Many thanks, John

This might be a idiot question but I have been stuck for a while. I would like to ask how to assign number of multisphere particles into the insert region. I used the "multisphere_stone_restitution" in LIGGGHTS' example. There are 50 coordinations in the data file, and only 2 clumped particles were created. I wonder how to increase the number of clumped particles ? Should I increase the number of coordination? I read the LIGGGHTS' manual but it does not (or I missed it) mention about this problem.
Thank you for your time.

Hello everyone;
By some reasons, I need to use LIGGGHTS 3.2 to simulate my model. I need to clump the particles to make the irregular shape. I know the function fix particletemplate/multisphere can do that job, but it is only available in LIGGGHTS 3.3 onward. I tried to copy the fix_multisphere in src 3.3 to 3.2, but I could not compile. Can anyone suggest me a solution?
Thank you

Hello everyone,

I am working on liggghts, and I generated a particle packing in the geometry by command insert/stream, after particles become stationary in the bottom, i would like to make the packing position fixed and not be moved anymore. In other words, after packing formed, we treated it as a wall.

I tried the command fix freeze and fix setforce, but the particles not acted force tend to overlap with each other, and it is unexpected.

Do you know how to realize this ?

thanks.

I am simulating shaking grains in the vertical direction and I would like to speed up my simulation. I can use up to 24 cores. Since, the motion is predominantly in the z direction, should I maximize number of cores in this direction? Also, I noticed if I reduced the number of cores and let liggghts decide the optimum distribution, 20 cores make it faster instead of 24. I thought it was counter-intuitive but then again it could just be how liggghts distributes it. What should I do?