fix rigid

Submitted by cgrohs on Thu, 06/17/2010 - 14:08

Christoph,

What do I do wrong using the "fix/rigid" in a LIGGGHTS simulation? I tried to produce the same input for LAMMPS and LIGGGHTS but I get an error with LIGGGHTS: (Line numbers are on) This input is for LAMMPS; for LIGGGHTS line 9 is commented out and line 10 and 15-19 are uncommented.

Thanks,
Christian

==========
1 # Simple rigid body system
2
3 atom_style granular
4 newton off
5 communicate single vel yes
6 units si
7 neighbor 0.002 bin
8
9 pair_style gran/hertz/history 200000.0 NULL 50.0 NULL 0.5 1
10 #pair_style gran/hertz/history 1 1
11
12 read_data data.rigid2
13 pair_coeff * *
14
15 #fix m1 all property/global youngsModulus peratomtype 2.63e5
16 #fix m2 all property/global poissonsRatio peratomtype 0.27
17 #fix m3 all property/global coefficientRestitution peratomtypepair 1 0.02
18 #fix m4 all property/global coefficientFriction peratomtypepair 1 0.8
19 #fix m6 all property/global cohesionEnergyDensity peratomtypepair 1 30.
20
21 velocity all create 100.0 4928459
22
23 group clump1 id <> 1 9
24 fix 1 all rigid group 1 clump1
25 neigh_modify exclude group clump1 clump1
26
27 thermo 100
28 dump 1 all custom 50 dump.rigid01-1 id type type x y z &
29 ix iy iz vx vy vz fx fy fz omegax omegay omegaz radius
30
31 timestep 0.0001
32 thermo 50
33 run 10000
=======================
1 # LAMMPS data file for rigid bodies
2
3 9 atoms
4 1 atom types
5
6 -12 12 xlo xhi
7 -12 12 ylo yhi
8 -12 12 zlo zhi
9
10
11
12 Atoms
13
14 1 1 0.500 10.2e3 0 0 0
15 2 1 0.500 10.2e3 0 1 0
16 3 1 0.500 10.2e3 0 0.5 0
17 4 1 0.500 10.2e3 0.5 0 0
18 5 1 0.500 10.2e3 0.5 0.5 1
19 6 1 0.500 10.2e3 1 0.5 0
20 7 1 0.500 10.2e3 0.5 1 0
21 8 1 0.500 10.2e3 1 0 0
22 9 1 0.500 10.2e3 1 1 0
==========

Forums:

cstoltz | Thu, 06/17/2010 - 15:48

Christian,

I don't have an answer right off regarding LIGGGHTS, but do want to mention two things wrt using fix_rigid for multisphere particles:

1) Be aware that the fix_rigid command from LAMMPS doesn't accurately calculate the center-of-mass or moment of inertia for a multisphere particle. It just sums the contributions from each sphere without accounting for overlaps.

2) I've used a hybrid granular molecular atom_style to do problems w/ multisphere particles. You can treat each molecule as an individual clumped particle and apply fix_rigid to the molecules. The following is a sample script for packing particles into a box (I only included the first two particles in the data file as it is 15MB in all):

####################################################################
# LAMMPS simulation of packing problem

units si
atom_style hybrid granular molecular
boundary f f f
newton off
#processors 2 2 2
communicate single vel yes

read_data data.configuration.txt
mass * 1.0

####################################################################
# Establish particles
fix 1 all gravity 9.81 vector 0.0 0.0 -1.0
fix 2 all rigid molecule
neigh_modify exclude molecule all

####################################################################

fix 3 all wall/gran 1777777.78 2285714.29 0.5 0.0 0.5 1 xplane -0.15 0.15
fix 4 all wall/gran 1777777.78 2285714.29 0.5 0.0 0.5 1 yplane -0.15 0.15
fix 5 all wall/gran 1777777.78 2285714.29 0.5 0.0 0.5 1 zplane -0.15 NULL
####################################################################

pair_style gran/hertz/history 1777777.78 2285714.29 0.5 0.0 0.5 1
pair_coeff * *

compute 1 all ke
thermo_style custom step atoms c_1
thermo 2500
thermo_modify lost ignore norm no
compute_modify thermo_temp dynamic yes

timestep 0.00004
dump 1 all xyz 2500 trajectory.xyz

run 25000

####################################################################
# LAMMPS data file
LAMMPS data file

210000 atoms

1 atom types

-0.155000000000000 0.155000000000000 xlo xhi
-0.155000000000000 0.155000000000000 ylo yhi
-0.150000000000000 1.200000000000000 zlo zhi

Atoms

1 1 0.01952820 0.14099100 1.10066000 0.01073252 1000.0 1
2 1 0.01811800 0.14345470 1.10433955 0.00536626 1000.0 1
3 1 0.01582400 0.13893684 1.10257229 0.00536626 1000.0 1
4 1 0.01838875 0.14528731 1.09930318 0.00536626 1000.0 1
5 1 0.02296166 0.14121255 1.10378408 0.00536626 1000.0 1
6 1 0.02323240 0.14304516 1.09874771 0.00536626 1000.0 1
7 1 0.02066765 0.13669469 1.10201682 0.00536626 1000.0 1
8 1 0.01609474 0.14076945 1.09753592 0.00536626 1000.0 1
9 1 0.02093840 0.13852730 1.09698045 0.00536626 1000.0 1
10 1 0.01697100 0.14119577 1.10345592 0.00536626 1000.0 1
11 1 0.01825338 0.14437100 1.10182137 0.00536626 1000.0 1
12 1 0.02053983 0.14233362 1.10406181 0.00536626 1000.0 1
13 1 0.02208540 0.14078623 1.09786408 0.00536626 1000.0 1
14 1 0.02080302 0.13761100 1.09949863 0.00536626 1000.0 1
15 1 0.01851657 0.13964838 1.09725819 0.00536626 1000.0 1
16 1 0.02181465 0.13895362 1.10290045 0.00536626 1000.0 1
17 1 0.02309703 0.14212886 1.10126589 0.00536626 1000.0 1
18 1 0.02081058 0.14416623 1.09902545 0.00536626 1000.0 1
19 1 0.01724175 0.14302838 1.09841955 0.00536626 1000.0 1
20 1 0.01595937 0.13985314 1.10005411 0.00536626 1000.0 1
21 1 0.01824582 0.13781577 1.10229455 0.00536626 1000.0 1
22 1 0.02528960 -0.03184420 0.28497200 0.01073252 1000.0 2
23 1 0.02786467 -0.02928741 0.28787534 0.00536626 1000.0 2
24 1 0.02845643 -0.02946160 0.28254466 0.00536626 1000.0 2
25 1 0.02743932 -0.03463526 0.28800288 0.00536626 1000.0 2
26 1 0.02254813 -0.02887894 0.28727181 0.00536626 1000.0 2
27 1 0.02212277 -0.03422680 0.28739934 0.00536626 1000.0 2
28 1 0.02313988 -0.02905314 0.28194112 0.00536626 1000.0 2
29 1 0.02803107 -0.03480946 0.28267219 0.00536626 1000.0 2
30 1 0.02271453 -0.03440099 0.28206866 0.00536626 1000.0 2
31 1 0.02816055 -0.02937451 0.28521000 0.00536626 1000.0 2
32 1 0.02765200 -0.03196134 0.28793911 0.00536626 1000.0 2
33 1 0.02520640 -0.02908318 0.28757358 0.00536626 1000.0 2
34 1 0.02241865 -0.03431389 0.28473400 0.00536626 1000.0 2
35 1 0.02292720 -0.03172706 0.28200489 0.00536626 1000.0 2
36 1 0.02537280 -0.03460522 0.28237042 0.00536626 1000.0 2
37 1 0.02284400 -0.02896604 0.28460647 0.00536626 1000.0 2
38 1 0.02233545 -0.03155287 0.28733558 0.00536626 1000.0 2
39 1 0.02478105 -0.03443103 0.28770111 0.00536626 1000.0 2
40 1 0.02773520 -0.03472236 0.28533753 0.00536626 1000.0 2
41 1 0.02824375 -0.03213553 0.28260842 0.00536626 1000.0 2
42 1 0.02579815 -0.02925737 0.28224289 0.00536626 1000.0 2

Best regards,
Chris

ckloss's picture

ckloss | Thu, 06/17/2010 - 18:13

Hi Christian,

I will have a look. But as Chris already said, the original fix rigid is not 100% valid because of 2 issues:
+ Not possible to define overlapping particles
+ Dampening not accounted for correctly

We have a modified version of fix rigid (that is not yet in the public version) that allows for that, see here:
node/20
Example 2 is with overlapping particles

Best,
Christoph

cgrohs | Fri, 06/18/2010 - 08:21

Chris,
Thanks for the information and for the example -- I'll have a try as soon as possible. I guess you've never tried it with LIGGGHTS?!

Christoph,
Thank you for having a look at the fix_rigid! Regarding the examples (1 and 2): as far as I can see there are only particles in a (eventually bent) row. Is this a limitation of the (not yet published) version of fix_rigid? What I'd like to try would be, e.g., a cluster with particles at the corners of an octahedron. Is this possible?

Regards,
Christian

ckloss's picture

ckloss | Fri, 06/18/2010 - 08:33

>>as far as I can see there are only particles in a (eventually bent) row. Is this a limitation of the (not yet published) version of fix_rigid?

No, in example1 you see particles that are not in a row.

>>What I'd like to try would be, e.g., a cluster with particles at the corners of an octahedron. Is this possible?

Yes

I will come back to you when I found out about fix rigid - I guess this will be a minor issue

Christoph

ckloss's picture

ckloss | Fri, 06/18/2010 - 09:01

Hi Christian,

yes it turned out to be a minor issue - that will be fixed in version 1.1 to be released next week.

best regards,
Christoph

cstoltz | Fri, 06/18/2010 - 12:27

Christian,

I took a brief try at running the code in LIGGGHTS, but the jobs crash out on the first step. I'm not sure what the problem is (something memory related I believe) at this point and haven't tried delving into it in detail yet due to the aforementioned problems with the fix_rigid command.

Best regards,
Chris

ckloss's picture

ckloss | Fri, 06/18/2010 - 13:37

Hi Chris,

this is actually the issue that Christian referred to (which will be fixed in 1.1 next week).

Christoph

thwagner | Wed, 12/15/2010 - 17:59

Hi,

I encounter difficulties in trying to use fix rigid molecule in conjuction with fix spring tether.

I started with the compression example as a template. I want to construct a rigid rod of granular particles that are connected to a spring which pulls at the rod's centre of mass. In addition I want to allow torque only along the z-axis. I exclude the interaction within the rod.

For only one particle attached to the spring the code works.
These are the changes that I made in order to have a rigid body:

===

atom_style hybrid granular molecular
neigh_modify exclude molecule all

mass * 1E-18
set group rod density 2500
set group rod mol 1

fix 1 rod rigid molecule force * on on on torque * off off on
fix 2 rod spring tether ${K} 0.0 0.0 NULL 0.0
fix 3 rod nve/sphere

===

I had to add a dummy mass, but I'm not sure if this is ok. Right after that I set the density and the Mol-ID to the rod atoms.

When I do the run without "fix 3" the rod doesn't move at all. With paraview I visualize the forces on the rod particles all pointing to (x,y) = (0,0)?

When I include "fix 3" in the script, liggghts warns about double time integration as expected. At least the rod moves to (x,y) = (0,0).

It appears, that I have to increase the stiffness of the spring as the mass of the rod depends on the number of particles, is that right?

How do I have to change the input script, so that I can omit the double time integration?

With kind regards,
Thomas Wagner.

ckloss's picture

ckloss | Thu, 12/16/2010 - 14:37

Hi Thomas,

>>I had to add a dummy mass, but I'm not sure if this is ok
This is ok. If you use "hybrid granular soemthing", where the "something" defines masses per-type, to my knowledge the per-particle mass from granular will always overrule this

>>When I do the run without "fix 3" the rod doesn't move at all.
This is indeed unexpected behavior. Which version are you using. There was a bug in an older evrsion related to that

Cheers,
Christoph

thwagner | Fri, 12/17/2010 - 11:16

Dear Christoph,

I'm using liggghts (1.1.10 and 1.2.2 beta) from the git repositories. Both versions return the following version information:

LIGGGHTS 1.1.10 based on lammps-10Mar10

I compiled 1.1.10 on November 15th and the development version on December 9th.

Best regards,
Thomas.