Abnormal value of "compute vcm/chunk"

Hi,all

When I use the compute vcm/chunk command, I find that its value is greater than the value calculated by variable vcm(group(the chunk),dim). Moreover, the chunkID of each atom in the dump.file is displayed abnormally in the first frame, and are fine in the subsequent frames. What is even more strange is that the kinetic energy of the chunk calculated by compute temp/chunk kecom hardly reflects this difference, that is, its value is almost equal to 0.5*mass(group(the chunk))*vcm(group(the chunk)) ^2 (the units have been converted), that is, the real KE. But when I output the chunkID of each atom in the dump (dump 2) of a run before the run containing the command compute vcm/chunk, everything returns to normal, that is, the value calculated by compute vcm/chunk and the value calculated by variable vcm(group(the chunk), dim) are equal, and the chunkID of each atom is displayed normally in every frame in the dump.file.

Here are test in.file that runs quickly and the test results of the lammps-2022Jun23 compiled by Intel on 28 processors of cpu on MobaXterm.

in.vcmchunktest (4.6 KB)
Si.sw (795 Bytes)
CH.airebo (905.0 KB)
Etest_cell.data (30.0 KB)

test_vcmchunk.txt (336 Bytes)
test_vcmNcell.txt (327 Bytes)
test_slip1.lammpstrj (2.6 MB)
test_chunkNKE.txt (177 Bytes)

When you output c_Nchunk in dump 2 in in.vcmchunktest, everything returns to normal, as I said above.

Another anomaly caused by MSD:
When I delete the part of MSD Origin Recorded in in.vcmchunktest, I get in.vcmchunktest_noMSD.
The result changed and I don’t know why.
Also, there is still a numerical difference between test_noMSD_vcmchunk.txt and test_noMSD_vcmNcell.txt, as mentioned above.

in.vcmchunktest_noMSD (4.2 KB)
test_noMSD_vcmchunk.txt (336 Bytes)
test_noMSD_vcmNcell.txt (324 Bytes)
test_noMSD_slip1.lammpstrj (2.6 MB)
test_noMSD_chunkNKE.txt (177 Bytes)

There was a bug in compute chunk/atom when used with “ids once” that was fixed only last month: fix ids once bug in compute chunk/atom by sjplimp · Pull Request #3699 · lammps/lammps · GitHub

So you need to check with a more recent version of LAMMPS.

OK, so how to explain the change caused by MSD?

Your input deck to too complex and convoluted to make sense of it and I don’t have the time to try and figure out all the details and reconstruct an input deck from it that is suitable for debugging/testing.

Please first update to the latest feature release of LAMMPS and then produce small, simple and fast to run input examples that just demonstrate individual issues with a few commands in the input as possible.

1 Like

Okay, I now know that the problem is not caused by MSD, but by run 2. The test file and result regarding run are as follows (based on the Mar2023 version):

in.run_test (995 Bytes)
Etest_cell.data (30.0 KB)
CH.airebo (905.0 KB)
Si.sw (795 Bytes)

log.test_norun (6.5 KB)

The run leads to changes in atomic data, which may even affect subsequent results, as in my first question.

Why does the run without fix cause atomic data changes which has nothing to do with the number of steps of the run?

You’ve posted the result without run – what does it look like with? I note the initial VCM is very close to zero (as it should be with the default zero momentum) so if you are seeing a difference between two very small numbers it could just be simple floating point error.

1 Like

There is no “change of atomic data”, i.e. the positions of the atoms after the minimization remain unchanged with a “run 0” command.

What the run command does, however, is to trigger a rebuild of the neighbor lists and that causes a reordering of the atoms. Since LAMMPS is using floating point math with finite precision and non-associative operations, you will get results that can differ within the range of available precision of about 5.0e-16 as has been mentioned by @srtee already. This is obviously the case here, since the center of mass velocity should be 0.0 within the limits of floating point math.

I suggest having a good look at these websites/blogs to learn more about this subject:

I see, thank you very much!