Dear LAMMPS developers and users,
I am interested in the simulation of a WCA particle fluid, so I have a short LJ cutoff of 1.12. My hope is to use compute cluster/atom to simplify a connectivity analysis. The goal is to be able to try out a range of values for the connectivity shell, i.e., the cutoff for compute cluster/atom (see for example this article).
If I understand correctly (from an old mailing list entry), the compute was written with the idea that only interacting particles should be in a common cluster. Thus, it uses the neighbor list created by the pair style and therefore, cluster cutoffs have to be smaller than the pair style cutoff. However, in general and in my case, “connected” particles do not have to interact.
To find a solution, I looked at compute rdf, which requests its own neighbor list in the lines
auto req = neighbor->add_request(this, NeighConst::REQ_OCCASIONAL);
if (cutflag) req->set_cutoff(mycutneigh);
Can we just proceed similarly for compute cluster/atom or is there something I miss?
Thank you very much for your time.
Victor
Why don’t you just try and see what happens?
… or provide a minimal input deck with expected results, so that somebody else can try to implement and test it.
1 Like
Thank you very much for the response. I have made an effort to safely implement the changes, guided by compute rdf, and attached the source. Compute cluster/atom now requests a neighbor list with the given cutoff, only if needed and hopefully only if it’s safe to so with respect to the communication cutoff.
As a first test, I set up a simple simulation. The attached input file loads in five WCA atoms and attempts to find clusters with a cutoff of 2.0 (>1.12 from WCA). There are two particles in two clusters each and one isolated atom. Only one of the atoms is given a velocity, so it moves away from its partner and collides with the other cluster. The dump file records that this moving particle first leaves its own cluster (step 10) and then joins the new cluster (step 300). Both events correspond to the given cutoff.
I would be very grateful for further feedback.
Victor
Simulation setup and expected results:
five_atoms.dat (231 Bytes)
in.atoms (562 Bytes)
traj.dump (966 Bytes)
Source:
compute_cluster_atom.cpp (6.9 KB)
compute_cluster_atom.h (1.6 KB)
If it works for you, then the (main) problem is solved.
The only reason for me (or other LAMMPS developers) to take a closer look would be that you want to submit it for inclusion in the the LAMMPS distribution.
For this you would need to put your change into a feature branch and then submit it as a pull request on github.
For that you would also need to update the documentation.
If you are unfamiliar with git, github, and pull requests, I can also include the change into a pending pull request of mine with multiple small changes.
Thank you for the response. In general, I believe it would be a valuable improvement of compute cluster/atom. The same changes should probably be made for compute aggregate/atom. I could work on that and the documentation in April and open a pull request. If you prefer to include it beforehand, I of course also agree to your pending pull request with several small changes.
@HrNovember If you feel comfortable submitting a pull request yourself, then this is the preferred procedure of including these kinds of changes. This is how most of LAMMPS came to be.
1 Like
To future readers of this thread: Please note that the source posted above, given it works, is not compatible with neighbor multi. See this question.
1 Like