LIGGGHTS® - User Forum

Hi,

I am looking for a way to write particle-fluid interaction force of specific particle to a file. Normally I use Fix/print to output other information of atoms such as id,x,y,z or fx,fy,fz by pre-defining variables. However for dragforce, I am confused how to define variable for it.

For example one of my trials and it was failed below.

variable ID equal f_dragforce1[id_of_particle]

The structure of dragforce array might not be the same as those of normal force, fx,fy,fz in which we can point, e.g, fx[id_of_particle].

I'm running a sim on a PBS server, so in order to try to save cluster resources, I'm trying to get my sim to quit when all the particles have drained out. Therefore, I have a run every command that looks like this:

run 20000000 every 500000 "if '$a < 1' then 'quit'"

where $a is my particle count

this only gives me "substitution for illegal variable" errors. I've tried everything I can think of, and I get an error messege every time. What am I missing?

Hi everybody

I am trying to make a complex shape particle by using fix rigid molecule command. I used following scripts in lammps and it run well. but once I wanted excutive it in liggghts I saw this ERROR: Illegal fix property/atom command, not enough arguments (../fix_property_atom.cpp:65)

units si
atom_style sphere
boundary f f f
newton off
communicate single vel yes

fix addMolecule all property/atom mol ghost yes
read_data mybag.rigid fix addMolecule Null Molecules

Hi all,

I am trying to import particle positions through the read_data command. I have 10.000 particles that appear in the first time step and apparently all the input file is set ok.

It starts running and after a while the simulation stops saying the process has been killed.

Is it because there are too many particles to be inserted in 1 timestep? I previously tried to insert them all at once through a fix command but I had the same error message. I tried a different insertion methods (not in 1 timestep) afterwards and worked fine.

I am trying to compile LIGGGHTS with DLAMMPS_VTK switch in windows with cygwin.
I have successfully compiled and vtk6.2.
I am trying to compile the LIGGGHTS with following vtk settings in makefile.ubuntu
VTK_INC = -I/usr/local/include/vtk-6.2
VTK_PATH =
VTK_LIB = -lvtkCommon -lvtkFiltering -lvtkIO

Hi everybody,

I'm currently testing the "pair_style gran model hooke/stiffness", applying a true deformation rate on pairs of particles. I'm expecting, whatever the configuration, to get the theoretical result :
force = kn x indentation

Hello,

Stream of particles are being injected continuously from inlet and they leave the domain through outlet.
I would like to account for all the particles in the domain and even particles which left the domain. (count the particles and save their respective properties such as velocity,density etc.)
Is there a way wherein I can account for the lost particles also and write everything in a file?
I want to plot the average velocity of all the particles in the domain and even lost particles too.

Thank you.

Dear users,

i was suprised when i found in the log file the other time accounts for 68% of the loop time. What is the reason?
How can i do smartly to speed up the simulations?

...
Pair time (%) = 7.30157e-05 (1.02045)
Neigh time (%) = 0.00126994 (17.7483)
Comm time (%) = 0.000835061 (11.6706)
Outpt time (%) = 9.60827e-05 (1.34283)
Other time (%) = 0.00488114 (68.2178)
.....

Cheers,
Zyan

Hi,

I have been trying to install LIGGGHTS 3.1 on Ubuntu 14.04. I have downloaded the latest version and then used the following commands:
make clean-all
make fedora

It works for awhile but then I get the following error:
make[1]: *** No rule to make target `../../lib/gpu/Makefile.lammps'. Stop.
make[1]: Leaving directory `/home/LIGGGHTS-PUBLIC-3.1/LIGGGHTS-PUBLIC/src/Obj_serial'
make: *** [serial] Error 2

I've looked through previous comments for this problem and one issue was not having:
# Path to src files

I am performing a LIGGGHTS simulation with spherical particles moving inside of a pipe around an obstruction. The simulation proceeds fine at first, but once the particles collide with the obstruction, they sometimes accelerate (as if the coefficient of restitution were greater than unity). This seems to be a problem with mesh/surface STL wall specification, as I don't get this sort of behaviour when using planes and cylinders as walls.