Hi all,
compute cluster Ncell cluster/atom 2.5
compute Nchunk Ncell chunk/atom c_cluster compress yes nchunk once ids once
I have small doubt whether c_Nchunk really was calculated only once. My data shows that it may be recalculated at every timestep, according to c_ cluster which is also recalculated at each timestep.
Have you ever encountered a similar problem? Welcome to leave a message.
There is too much context missing here to make an assessment of what you are observing.
If you believe that LAMMPS is not acting according to its documentation, please provide a minimal input deck that can be run quickly and serves no other purpose than to demonstrate the inconsistency that you are observing and explain how it manifests.
We can then take your test input and evaluate it further.
Here’s a minimal working example showing documented behaviour: (v_clust* variables change as atoms move, while v_chunk* variables do not)
atom_style atomic
atom_modify map yes
region box block 0 100 0 100 0 100
create_box 1 box
create_atoms 1 single 10 10 10
create_atoms 1 single 10 10 10.5
create_atoms 1 single 20 20 20
create_atoms 1 single 25 25 25
mass 1 1.0
pair_style lj/cut 3
pair_coeff * * 1 1
compute cluster all cluster/atom 2.5
# clusters are (1 2), 3, 4
compute clchunk all chunk/atom c_cluster compress yes nchunk once ids once
variable clust1 equal c_cluster[1]
variable clust2 equal c_cluster[2]
variable clust3 equal c_cluster[3]
variable clust4 equal c_cluster[4]
variable chunk1 equal c_clchunk[1]
variable chunk2 equal c_clchunk[2]
variable chunk3 equal c_clchunk[3]
variable chunk4 equal c_clchunk[4]
thermo_style custom v_clust1 v_clust2 v_clust3 v_clust4 v_chunk1 v_chunk2 v_chunk3 v_chunk4
thermo 1
run 0 post no
group a2 id 2
displace_atoms a2 move 0 0 4
# now clusters are 1, 2, 3, 4
run 0 post no
group a3 id 3
displace_atoms a3 move 4.5 4.5 4.5
# now clusters are 1, 2, (3 4)
run 0 post no
Thank you very much for your help. This is the result of my run. The abnormal chunkID for 4th atom appears in the last two runs. Leave it alone in time, but one thing is certain: ‘chunk/atom ids once’ is not calculated only once, but changes with the clusterID, as can be seen from the previous three chunkIDs.
clusttest.log (3.9 KB)
Another question about compute invoked:
In the above command (thermo_style haven’t yet been executed), why is compute invoked without ‘run 0’ ?
As described in the same manual:
run 0
variable t equal temp
print “Initial temperature = $t”
run 1000
Run 0 is necessary to invoke compute.
By the way, this is why a minimal working example is very important and helpful.
Your log certainly shows the “wrong” output (my log from the develop branch code shows 1 1 2 3 for the chunk variables, every time). Your log also shows that you were using an older version of LAMMPS. Have you tried replicating this with the latest stable version? (For example, Atomify LAMMPS - a real time simulator in the browser gives the correct output.)
There is a run 0 command in my script (multiple times, in fact), so I am not sure what you are asking. All of the variables and computes in my example script have their values calculated because of and immediately at the end of run 0.
You can inspect the source code for yourself to understand how all this works. Or if you don’t know enough C++ to do so (and I certainly don’t know every single line of code) you can use the scientific method: hypothesize about how changing a line in the script will lead to a difference in the output, and then observe for yourself if you were right. Since the Atomify interface gives the documented result for its stated version (23 Jun 2022, update 1), you don’t even need to compile the code yet (although eventually you will have to).
I can verify that changing the number of processors changes the result of the compute and causes undocumented behavior. I will file a bug report on GitHub.
As you said, I used lammps-23Jun2022 version, and the results are as follows:
for n=14/ n=28, incorrect,
1 1 2 3
1 2 3 0
1 2 3 0
for n=1, correct!
1 1 2 3
1 1 2 3
1 1 2 3
Anyway, I think I basically understand the problem of compute invoke. Thank you for your help!