kspace seems to have changed other than how it's described

LAMMPS LAMMPS Mailing List Mirror
1

Hi all,

We have an old input script in LJ units with charges that we started using again recently, but now it spends 97% of the time in kspace (it used to work fine in 2011). The 2 Mar 2012 LAMMPS update was related to kspace and it says:
“BACKWARD COMPATIBILITY issues: Specifying a PPPM relative precision such as 1.0e-4 for the kspace_style command will give the same results as before for “real”, “lj”, and “metal” units. However, it will induce a different grid for “si,” “cgs”, and “electron” units. …”

However, we seem to be getting a different grid even though we’re in LJ units.

In older versions of LAMMPS, our kspace grid was 72x72x72, while in the newer version it is 150x150x150. An equivalent grid (and similar performance) can be obtained by using a relative error of 3e-3 instead of the typical 1e-4. Increasing the coul/long cutoff by a factor of 2 also gives the same grid size (with same rel error of 1e-4) but is obviously less efficient.

Am I missing something?

I’ve attached a simple script and smaller input file. Using these, the simulation time is 73% due to kspace using LAMMPS from 12 Feb 2012 and then 95% of time in kspace using LAMMPS from 28 May 2012.

Best,
Lisa

inputtest.lammps (2.07 KB)

LMHinputscript (1.34 KB)

2

Stan can comment.

Do you get the same answer as the old code if you force
the grid to be 72^3 by using the kspace_modify command?

It’s no surprise that Kspace time is now 95% since you
are using an 8x larger grid.

Steve

3

To answer Steve’s question from earlier, it seems if we use the older version of LAMMPS as-is or the newer version with kspace_modify mesh 9 9 9 (for the small test input I sent, this makes it the same mesh size as in the older version), we can get the same energy (looking at Coulomb energy over time coming from the thermo command). For one run with a different spacing of thermo output it happened to be different, but for another it was the same; I imagine this was just due to the system finding a slightly different state (it is coming from an unequilibrated test input file).

We are in agreement that it’s not surprising that the timing changed when the grid was increased 8x :wink:

Lisa

(I didn’t have time to run these today, so thanks to Jon Brown for sending me these results.)