constant torque on rigid body

LAMMPS LAMMPS Mailing List Mirror
1

Dear lammps users,

i need to apply a constant torque on a rigid body made of granular particles.

I've seen that the command "fix addtorque" is performed automatically during a minimization.

Both in the doc page of "minimize" command and in the mail list is clearly stated that "fix rigid" doesn't work during a minimization. Infact, what i see in my simulations is that the rigid body is slowly deformed.

So my questions are:

Is it possible to add a constant torque on a rigid body built with "fix rigid" without using a command that invokes a minimization?

or

Is it possible to build a rigid body of granular particles in a way that works with commands such as "fix addtorque" that invoke a minimization?

Anyone had this trouble in his life?

Thanks in advance,

Andrea Plati

2

Dear lammps users,

i need to apply a constant torque on a rigid body made of granular
particles.

I've seen that the command "fix addtorque" is performed automatically
during a minimization.

Both in the doc page of "minimize" command and in the mail list is
clearly stated that "fix rigid" doesn't work during a minimization.
Infact, what i see in my simulations is that the rigid body is slowly
deformed.

So my questions are:

Is it possible to add a constant torque on a rigid body built with "fix
rigid" without using a command that invokes a minimization?

i don't understand this question. fix addtorque does *NOT* "invoke a
minimization". the statement "The forces due to this fix are imposed
during an energy minimization" is made because not all fixes are
invoked this way. other fixes are invoked only during MD runs, or some
are invoked in both cases. so according to the statement, you should
be able to use fix addtorque during an MD, where you could also use
fix rigid (which is *NOT* invoked during minimization).

or

Is it possible to build a rigid body of granular particles in a way that
works with commands such as "fix addtorque" that invoke a minimization?

again, fix addforce does not invoke minimization. *YOU* do it in your
input file. the only deficiency of using fix addtorque is, that you
have to define a different group for each rigid body, that you want to
add a torque to. a more elegant solution (assuming the torque is the
same for all rigid bodies) would be a new fix addtorque/rigid that
would interface with fix rigid and add the torque directly to the
rigid body (or a corresponding modification of fix rigid) rather than
decomposing the torque into forces on individual particles before fix
rigid converts it into a per-body torque for the rigid body time
integration.

Anyone had this trouble in his life?

i think the main issue here is, that you are misunderstanding what fix
addtorque does and how it can be used.

axel

3

Thank you Axel for the answer,

So you are saying that the statement

"The forces due to this fix are imposed
during an energy minimization"

means "if YOU perform a minimization then that minimization will take in account addtorque" .

Maybe i'm confused because the behaviour that i observe in my rigid body is similar to the one described in the minimize doc page "...the energy minimization will not keep the defined body(s) rigid during the minimization."

Here is the infile in a synthetic version:

the rigid-body is constitued by two rows of grains partially overlapped along the x-axis and the z-axis.

I apply a constant torque respect to the z-axis so i expect that the rows will rotate with an increasing angular velocity without changing their z height and the relative positions between the grains.

On the contrary, what i observe in the dump file is that the z coordinates of the particles change and the rigid body is deformed after some timesteps.

what do you think is going wrong?

Thank

4

Thank you Axel for the answer,

So you are saying that the statement

"The forces due to this fix are imposed
during an energy minimization"

means "if YOU perform a minimization then that minimization will take in
account addtorque" .

yes, not all fixes are invoked during minimization.

Maybe i'm confused because the behaviour that i observe in my rigid body
is similar to the one described in the minimize doc page "...the energy
minimization will not keep the defined body(s) rigid during the
minimization."

please look at the corresponding section of the fix rigid docs, where it says:

These fixes are not invoked during energy minimization.

so when you issue, the "minimize" command, fix rigid will have no
effect. it will only be invoked when using the "run" command.

Here is the infile in a synthetic version:
the rigid-body is constitued by two rows of grains partially overlapped
along the x-axis and the z-axis.

I apply a constant torque respect to the z-axis so i expect that the
rows will rotate with an increasing angular velocity without changing
their z height and the relative positions between the grains.

On the contrary, what i observe in the dump file is that the z
coordinates of the particles change and the rigid body is deformed after
some timesteps.

what do you think is going wrong?

i don't know what is happening here. it works as expected for me with
the following simple input based on the melt example, so i suspect it
is due to something that you don't show us.

lattice fcc 0.8442
region box block -10 10 -10 10 -10 10
create_box 2 box
#region rotate cylinder z 0.0 0.0 7.0 -5.0 5.0
region rotate block -6.0 6.0 -6.0 6.0 -5.0 5.0
create_atoms 2 region rotate
mass * 1.0
velocity all set 0.0 0.0 0.0

pair_style lj/cut 2.5
pair_coeff * * 1.0 1.0 2.5

neighbor 0.3 bin
neigh_modify every 2 delay 2 check yes exclude type 2 2

fix 0 all addtorque 0.0 0.0 100.0
#fix 1 all rigid single
fix 1 all rigid single torque 1 off off on force 1 off off off

#dump id all atom 50 dump.melt

#dump 2 all image 25 image.*.jpg type type &
# axes yes 0.8 0.02 view 60 -30
#dump_modify 2 pad 3

#dump 3 all movie 100 movie.mpg type type &
# axes yes 0.8 0.02 view 60 -30
#dump_modify 3 pad 3

thermo 500
run 10000

axel.

5

Thanks again Axel,

I have solved my problem in a misterious way...

I write the simplest complete version of my script that exhibits the anomalous behaviour that i said to you.

Running this script you can see in the dump file that from time step 255000 on the particles start to change their z coordinate. Another strange thing is that from the first steps a little linear velocity on the z direction of the particles appears. This behaviour is not consistent with the bond imposed in the fix rigid command.

If you uncomment the line:

#variable midPoint equal 0

The effect is just a traslation of the rigid body in the x-y plane up to the origin.

If you run the script in this way the strange behaviour disappears...

It seems like a computational error in the calculation of the z-simmetry axis when the rigid body is not centered in the origin...

My problem is solved but maybe it would be interesting to understand this things

Andrea

6

there is not too much mystery to this and i don't think it is a bug in
the software, but an unfortunate side effect of using floating point
math.

you can access the center of mass properties of the rigid body from
the fix rigid command by f_MovePal[1][X] with X being a number between
1 and 15
from that you can see, that there is no movement of the center of mass
of the rigid body and no drift.
when visualizing the trajectory, you should see, that the object
slowly picks up a second rotation orthogonal to the z axis. that
explains the change in z-coordinates.

now, the cause of this spurious rotation can be explained with the
shortcomings floating point math. for floating point numbers, their
"resolution" depends on their magnitude. every time the value doubles,
the resolution halves. so for particles further away from the origin
the resolution is increasingly less. this is not a big problem most of
the time. however, in this particular case, we are dealing with
numbers that have to cancel each other. this works out for a rigid
object rotating around the origin, but does not, if you translate it.
thus there are tiny residuals and they begin to slowly accumulate in
the angular momentum. this has the usual exponential growth known as
lyapunov instability as smaller deviations are accumulating and
resulting in a growing divergence leading to larger errors and so on.
you can see this effect in the output of the rigid body torque. since
you cancel all force and x/y torque components for the rigid body time
integration, the center of mass remains in place, but the error when
computing the angular momentum is not removed and thus accumulates.

at this moment, i don't have a good idea how to compensate this kind
of error accumulation in the source code short of adding a flag to
explicitly zero out angular momentum components. it is normally not a
problem in typical LAMMPS applications, since you have rigid bodies
interacting with other atoms or rigid bodies, and then those
interactions are much more dominant and cause much larger changes in
the angular momentum, so that this small systematic error does not
matter, even more so, if a thermostat is applied.

hope this explains the mystery,

axel.

7

…incidentally, regarding “fix rigid” and “minimize”, the following LAMMPS discussion may be relevant to you

https://lammps.sandia.gov/threads/msg75967.html