Problem in the computation of center-of-mass

Hello, Lammps users,

I got a problem when I tried to calculate the center-of-mass of a group of atoms.

The testing system is very simple. A group of atoms are moved at a constant velocity by the command “fix move”, I am interested to monitor the center-of-mass of this group of atoms by both “variable xcm” and “compute com”. The velocity is positive, so the coordinate should always increase, but I found it jumped to a large negative value after a few time steps. For example the coordinate is 9000 now, in the next step it gets -9182, but it is supposed to be 9250. (see the difference between step 360000 and step 370000 in output file).

And, I used

variable V equal 5
variable x equal vdisplace(0.0,$V)
fix 1 bot move variable v_x NULL NULL v_V NULL NULL

to replace the linear style move. v_x does always increase, but " vcm(bot,x)" and " compure 1 bot com " still have the problem.

the output is:

Step Elapsed Rx 1[1] x Vx

310000 310000 7750 7750 7750 5
320000 320000 8000 8000 8000 5
330000 330000 8250 8250 8250 5
340000 340000 8500 8500 8500 5
350000 350000 8750 8750 8750 5
360000 360000 9000 9000 9000 5
370000 370000 -9182 -9182 9250 5
380000 380000 -8932 -8932 9500 5
390000 390000 -8682 -8682 9750 5
400000 400000 -8432 -8432 10000 5
410000 410000 -8182 -8182 10250 5
420000 420000 -7932 -7932 10500 5
430000 430000 -7682 -7682 10750 5
440000 440000 -7432 -7432 11000 5
450000 450000 -7182 -7182 11250 5
460000 460000 -6932 -6932 11500 5
470000 470000 -6682 -6682 11750 5
480000 480000 -6432 -6432 12000 5
490000 490000 -6182 -6182 12250 5
500000 500000 -5932 -5932 12500 5

Best wishes,

Wei

test.in (757 Bytes)

system.data (27 KB)

Hello, Lammps users,

I got a problem when I tried to calculate the center-of-mass of a group of
atoms.

The testing system is very simple. A group of atoms are moved at a constant
velocity by the command "fix move", I am interested to monitor the
center-of-mass of this group of atoms by both "variable xcm" and "compute
com". The velocity is positive, so the coordinate should always increase,
but I found it jumped to a large negative value after a few time steps. For

perhaps you should watch this for some inspiration:

https://www.youtube.com/watch?v=ygE01sOhzz0

example the coordinate is 9000 now, in the next step it gets -9182, but it
is supposed to be 9250. (see the difference between step 360000 and step
370000 in output file).

yes, your image flags wrap around after passing through the box 512 times.

visualize your trajectory *and* plot the box and you see that your
atoms are moving at a ludicrous speed.

And, I used

variable V equal 5
variable x equal vdisplace(0.0,$V)
fix 1 bot move variable v_x NULL NULL v_V NULL NULL

to replace the linear style move. v_x does always increase, but "
vcm(bot,x)" and " compure 1 bot com " still have the problem.

compute com uses the same facility as when accessing the xcm()
function in a variable. so you *should* get the same result.
using both is redundant.

axel.

From Section_start.html of the manual:

The default is -DLAMMPS_SMALLBIG which allows for systems with up to
2^63 atoms and timesteps (about 9 billion billion). The atom limit is
for atomic systems that do not require atom IDs. For molecular
models, which require atom IDs, the limit is 2^31 atoms (about 2
billion). With this setting, image flags are stored in 32-bit
integers, which means for 3 dimensions that atoms can only wrap around
a periodic box at most 512 times. If atoms move through the periodic
box more than this limit, the image flags will “roll over”, e.g. from
511 to -512, which can cause diagnostics like the mean-squared
displacement, as calculated by the “compute msd”_compute_msd.html
command, to be faulty.

To allow for larger molecular systems or larger image flags, compile
with -DLAMMPS_BIGBIG. This enables molecular systems with up to 2^63
atoms (about 9 billion billion). And image flags will not “roll over”
until they reach 2^20 = 1048576.

Steve

Hi, Steve and Axel,

Thank you very much for your help. I compiled lammps again with -DLAMMPS_BIGBIG, now it can work under a ludicrous speed. Awesome !

Thanks again for your time,

Best wishes,

Wei