I’m doing short NpT simulations with fixed timestep. Surprisingly, the calculation performance of the simulation seems to depend on temperature. Well, it should not, as I have the same number of atoms and the same timestep.
I turned out it is due to the line neighbor 1.0 nsq. When using instead the default bin, the performance also decreases, but only very slightly, as the atoms are more randomly disturbed from the equilibrium positions.
Is this expected for nsq? I’m not using nsq on purpose. I got it from the example/elastic, where it is used. Maybe it should not be used there? I know, it does not use dynamics, but I suspect the same performance problems also during minimize on non-equilibrium samples.
This is for Tungsten, 1500K may seem a lot, but Tungsten is still BCC at these temperatures. Used potential can be found on NIST. I can reproduce the same with different potential as well, just the extent of the performance drop is different.
To reproduce on 2 millions of Tungsten atoms (can be done on less atoms as well, but the drop is smaller):
units metal
boundary p p p
lattice bcc 3.157
region box block -50 50 -50 50 -50 50
create_box 1 box
create_atoms 1 region box
mass 1 183.841
pair_style eam/fs
pair_coeff * * W_MNB_JPCM17.eam.fs W
thermo 100
thermo_style custom step temp pe press vol spcpu cpuremain
thermo_modify norm yes flush yes
neighbor 1.0 nsq
#neighbor 1.0 bin
variable myseed equal 112233
variable mytemp equal 700.0
variable time_step equal 0.001
variable time_eq equal 1000
timestep ${time_step}
velocity all create ${mytemp} ${myseed} mom yes rot yes dist gaussian loop all
fix equil all npt temp ${mytemp} ${mytemp} $(100.0*dt) aniso 0.0 0.0 $(1000.0*dt) drag 0.0 pchain 8 tchain 8 ploop 4 tloop 4
run ${time_eq}
Have you checked the documentation about what the difference between neighbor list style “nsq” is versus the “bin” style? It should explain the difference in performance.
I strongly disagree with that assessment. The MD simulation performance does not only depend on the number of atoms, but also strongly depends on the number of neighbors, which is correlated to the number of atoms within the cutoff. This number is dependent on the density and with an NPT simulation the density should decrease as the temperature increases.
(bin) is almost always faster than the nsq style which scales as (N/P)^2. For unsolvated small molecules in a non-periodic box, the nsq choice can sometimes be faster. Either style should give the same answers.
And:
For small and sparse systems and as a fallback method, LAMMPS also supports neighbor list construction without binning by using a full loop over all i,j atom pairs in a subdomain when using the neighbor nsq command.
The more I’m surprised to find nsq in the official example for elastic, which is mainly for solids and not for unsolvated small molecules nor a sparse system. In the example itself there is solid silicon crystal with periodic boundary conditions.
You are right, the density in my case decreases slowly and smoothly with the increasing temperature due to the thermal expansion. There is no phase change though (no melting). I agree with you and this explains the behavior of bin. But with nsq there is a sudden drop of more than 2x which is surprising and puzzling to me.
Well, that should be the same for bin and nsq, shouldn’t it?
If I understood correctly the default neigh_modify is every = 1, so it anyway rebuilds every step.
It says “small systems” and not just “small molecules”.
There is overhead associated with binning used for neighbor list style “bin” and the number of pairs to compare with either neighbor list build is similar for as long as the sub-domains are of a similar size than 2x the cutoff. For larger subdomains, i.e. large systems, the performance gain of using binning and a stencil is significant, as it is a linear scaling algorithm in contrast to “nsq” which has quadratic scaling.
The elastic example uses only 192 atoms so the cost of quadratic scaling is not significant.
The skin distance is an input parameter and only has a default setting when you don’t use the “neighbor” command at all (which then defaults to “bin”).
BTW: a detailed description about how LAMMPS does domain decomposition and neighbor list builds is in the recent LAMMPS paper and an adapted version of that here: 4.4. Parallel algorithms — LAMMPS documentation
I think I finally understand, what is happening. Thank you both. Actually in NVT the slowdown in nsq is even more pronounced than in NpT. So it is not the change of density in this case. Switching neigh_modify check no triggers the search for neighbors in every step and the performance stops to be temperature dependent. But it is slow, especially with nsq.
