KPAR gives different energies from ionic relaxation

[nadelstein]

Hello,
I was testing KPAR=1 versus KPAR=8 for SiO2 ionic relaxation using a system with 16 nodes per core. In both cases I have 144 irreducible k-points. The difference in the final energy using KPAR=8 from 1 is 0.00038 eV, which is more than the ionic convergence limit of 10^-6 eV. The energy differences seem to stem from differences in the forces on the ions. Why are the forces different when using a different KPAR? This does not seem reasonable, so what can be done about it?

Thanks,
N.

POSCAR
Si O2
1.00000000000000
4.8842280671898282 0.0000000000000000 0.0000000000000000
-2.4421140335949141 4.2298655840418933 0.0000000000000000
0.0000000000000000 0.0000000000000000 5.3837153807007505
Si O
3 6
Direct
0.4657981009635542 0.0000000000000000 0.0000000000000000
0.0000000000000001 0.4657981009635542 0.6666666870000029
0.5342019290364484 0.5342019290364483 0.3333333429999996
0.4120224462955118 0.2740193929231772 0.1141440878266975
0.2740193929231774 0.4120224462955119 0.5525225611733021
0.7259806070768228 0.1380030533723418 0.7808107518266950
0.5879775537044882 0.8619969466276584 0.2191892481733050
0.8619969466276586 0.5879775537044882 0.4474774088266952
0.1380030533723417 0.7259806070768227 0.8858559341733042

INCAR
System = SiO2

LORBIT =10
NPAR = 16
#KPAR = 8

ENCUT = 900

PREC = Accurate
NELMIN = 8
NELM = 45
EDIFF = 1E-6
EDIFFG = -0.001
NSW = 200
LREAL=Auto
#ISPIN = 2

POTIM = 0.08
ISMEAR = 0
SIGMA = 0.03
IBRION = 2
ISIF = 3

[PRCKent]

You have an electronic convergence (EDIFF) of 1e-6, but an ionic convergence setting of only 0.001 on the forces (negative EDIFFG). The under 1 meV difference that you find in fact seems very reasonable and likely occurs due to the accumulation of many very small numerical differences over many tens of ionic steps.

I attempted to reproduce your problem with a 4x4x4 k-point grid, running at least 30 ionic steps on my laptop with KPAR=3 compared with KPAR=1, and 3 vs 1 MPI tasks respectively. Energies and forces agree to many decimal places. This does not rule out a KPAR related bug, but I think it is unlikely.

I suggest you restart your runs with tighter convergence settings for the geometry. The differences should gradually go away. If they do not, please try to narrow down your problem further before reporting back. E.g. Use different processor counts, different kpar setttings, and find out how reproducible the problem is. A KPAR related bug would almost certainly be visible on the first ionic step.

-- Paul Kent