Hi axel and steve,
In the following very simple script, a constant velocity subjected to a rigid group.
The problem is it doesn’t move!
Not necessary to mention that in the main model I have to use “Fix rigid” rather than other ways to make a mobile group rigid.
dimension 2
boundary p s p
atom_style atomic
neighbor 0.3 bin
neigh_modify delay 5
lattice hex 0.9
region box block 0 50 0 22 -0.25 0.25
create_box 1 box
mass 1 1.0
region particle sphere 25 11 0 5
create_atoms 1 region particle
group particle region particle
pair_style lj/cut 2.5
pair_coeff * * 1.0 1.0 2.5
velocity all create 0.1 482748
fix 11 all nve
fix 12 particle rigid/nve single
timestep 0.0025
thermo 1000
dump 3 all movie 500 movie.mpg type type zoom 1.6 adiam 1.5 axes yes 0.05 0.05
run 50000 #relaxation
velocity particle set 1.0 0.0 0.0 sum yes
run 200000 #moving
Hi axel and steve,
In the following very simple script, a constant velocity subjected to a
rigid group.
now *that* is a proper, simple, and convincing proof of a problem.
why not do so right away?
why make me spend the time and energy arguing, and acting like an arrogant
asshole to make you do what is the reasonable thing to do?
with this example, i have quickly identified the origin of this problem.
for the time being, a workaround, is to reissue the exact same fix rigid
command after the second velocity command. i will have to discuss with
steve about how to correctly address this. fortunately, he is in town today.
axel.
That’s actually the documented behavior of the fix rigid command. From
the fix rigid doc page:
The aggregate properties of each rigid body are calculated one time at the start of the first simulation run after these fixes are specified. The properties include the position and velocity of the center-of-mass of the body, its moments of inertia, and its angular momentum. This is done using the properties of the constituent atoms of the body at that point in time (or see the infile keyword option). Thereafter, changing properties of individual atoms in the body will have no effect on a rigid body’s dynamics, unless they affect the pair_styleinteractions that individual particles are part of. For example, you might think you could displace the atoms in a body or add a large velocity to each atom in a body to make it move in a desired direction before a 2nd run is performed, using the set or displace_atoms or velocitycommand. But these commands will not affect the internal attributes of the body, and the position and velocity of individual atoms in the body will be reset when time integration starts.
So you need to use your “velocity” command before the first “run” command, either before or after
the fix rigid command.
Steve
That's actually the documented behavior of the fix rigid command. From
yes, but we should change that, as it is very counterintuitive and
violating the principle of least surprise as it differs from other time
integration fixes. from what i read in the source code comments and learned
from the change history, this behavior was added to handle a rather unusual
case, so i believe the better way to deal with it would be to add a flag
that would enable this behavior, if needed. and restore the previous and
more commonly expected behavior.
axel.
There are many, many things a user might think they can do to one or more atoms within
a rigid body using commands after the rigid body is defined that would
alter the rigid body. E.g.
displace one or more atoms
change the velocity of one or more atoms
change the mass of one or more atoms
etc
None of them will do anything, b/c once
the rigid body is defined its properties are stored
for the body as a whole, internal to fix rigid.
That happens
at the point in time of the first run after the use
of fix rigid. Which gives you time to set
any atom properties you want, even after
using fix rigid, but before the first run.
For some of the properties you can’t easily
re-compute them at later times without careful coding
being added insdie fix rigid (e.g. a new moment of
inertia tensor in the proper reference frame).
What if you displace finite-size atoms so they
now overlap - you can’t re-compute an altered
moment of inertia? What if you manually rotate
the rigid body - you’d have to internally alter
the quaternion. Etc, etc.
If we want to enable certain commands to override
that rule, we’d have to think carefully about it
and document it clearly (what if a user changes
the velocity of half the atoms in a rigid body?).
I don’t see a compelling use case in this example.
Just follow the doc page and set the velocities at
the correct point in the input script. I.e. before
the rigid bodies get “defined”. Or unfix fix
rigid, change atoms (e.g. velocities) however
you wish, then re-use fix rigid to create
new rigid bodies based on the current
atom properties.
Steve
Just read this message more carefully.
Please don’t use this kind of language on the mail list.
If you’re upset send a private message, not a public one.
(but I don’t advise that either)
Thanks,
Steve