Large influence of SYMPREC on energies

[MBaeker]

I have a question regarding the SYMPREC-parameter: I have found a case where changing it from the standard 1.e-05 to 1.e-04 changes the energy quite significantly, from
E0= -.79707341E+03 (correct value, as far as I can tell) to
E0= -.79920458E+03

Looking at the OUTCAR (which I cannot upload because it is too large), the only differences I see in the setup (before iteration begins) are:
< SYMPREC = 1.00e-04
> SYMPREC = 1.00e-05
512c512
< Subroutine GETGRP returns: Found 16 space group operations
> Subroutine GETGRP returns: Found 8 space group operations
518d517
< The point group associated with its full space group is D_4h.
542c541
< Subroutine GETGRP returns: Found 16 space group operations
> Subroutine GETGRP returns: Found 8 space group operations
548d546
< The point group associated with its full space group is D_4h.
572c570
< Subroutine GETGRP returns: Found 16 space group operations
> Subroutine GETGRP returns: Found 8 space group operations
578d575
< The point group associated with its full space group is D_4h.
581c578
< Subroutine INISYM returns: Found 16 space group operations
> Subroutine INISYM returns: Found 8 space group operations

When the simulation starts (OSZICARs attached), energies are the same, but then they drift apart significantly.

I do understand that choosing a value of SYMPREC that is too large may force an incorrect symmetry on the charge distribution, but I am puzzled by the effect being so large here and by the fact that the energy with too large SYMPREC value is lower (shouldn't it be higher because there are less DOFs to minimize when we enforce a symmetry?).
I find it also a bit worrying considering that "change SYMPREC" is advice frequently given when a VASP run has trouble with the symmetry.

I've attached the INCAR and POSCAR and the 2 OSZICAR results; I have not attached the POTCAR because I think that's forbidden, the potentials used were
TITEL = PAW_PBE Ni_pv 06Sep2000
TITEL = PAW_PBE Nb_sv 25May2007

[fabien_tran1]

Hi,

As a test, could you please follow these steps (all with NSW=0, i.e. no geometry optimization)?

1) Do a calculation with "SYMPREC = 1.00e-04" and "LWAVE = .TRUE.".

2) In the same directory, do the calculation with "SYMPREC = 1.00e-05". This calculation should start using the WAVECAR file generated at step 1.

Is the energy obtained at step 2 the same as the one that you reported?

[MBaeker]

I tried with two different INCARs, one my standard one, one where I reduce AMIX and set NELMDL to get the initialization right.
In both cases, the job does not converge, the first ends with
| Error EDDDAV: Call to ZHEGV failed. Returncode = 23 1 24 |
| |
| ----> I REFUSE TO CONTINUE WITH THIS SICK JOB ... BYE!!! <----

the second (different mixing and NELMDL set) diverges and gives lots of
WARNING: Sub-Space-Matrix is not hermitian in DAV 60
6.535011242324960E-005
warnings, but with an energy of
DAV: 66 -0.145384783713E+10 -0.94014E+08 -0.32750E+08207888 0.604E+03 0.213E+03
that is probably not surprising.

I attach all slurm outputs:
slurm-9298808.out initial run with SYMPREC 1.e-4
slurm-9298931.out restart with SYMPREC 1e-5 and my usual INCAR parameters
slurm-9299562.out restart (from the first WAVECAR) with SYMPREC 1e-5 and my second try for INCAR parameters.

If there is anything else I can do to clear this up, please tell me.

BTW, I am very sure that from the two runs I posted yesterday, the result with SYMPREC=1.e-4 and the lower energy is incorrect.

[MBaeker]

After playing a bit with the algorithm parameters, I found a set that worked (slowly).
The restart run with SYMPREC 1.e-5 converges to
1 F= -.79705858E+03 E0= -.79706228E+03 d E =0.110951E-01 mag= -36.7115
which is practically the same as the first ionic step with SYMPREC 1.e-5 and no start from a WAVECAR
1 F= -.79705862E+03 E0= -.79706232E+03 d E =-.797059E+03 mag= 36.7112

Slurm-output attached (in the INCAR that is echoed at the beginning I accidentally set both ALGO and IALGO, but as the oputput shows, ALGO=NORMAL was used).

I hope this helps understanding the problem. (I'm still puzzled why the energy of the system with larger SYMPREC and incorrect solution can be lower).

[fabien_tran1]

Even with LDA I can reproduce the problem. It is not logical, and at the moment unclear, why having more symmetry operations (SYMPREC=1E-4) leads to a more negative total energy. We are continuing to investigate the problem.

[MBaeker]

Thanks for keeping me updated.
In the past I have observed a similar case when using a very large value of SYMPREC of 1.e-2 where the simulation converges to a slightly lower energy (40meV).
In case it helps to have another example with finding the problem, I attach the relevant files.

1 F= -.59742908E+03 E0= -.59743434E+03 d E =-.597429E+03 mag= 62.8051 with SYMPREC 1e-2
1 F= -.59698629E+03 E0= -.59699206E+03 d E =-.596986E+03 mag= 62.9000 with SYMPREC 1e-6

[fabien_tran1]

We made some tests and two observations can be mentioned:

1) Doing the calculation with no symmetry imposed (i.e., with ISYM=-1, while SYMPREC does not matter) leads to the same results as with SYMPREC=1.00e-05. This gives us confidence that the calculation with SYMPREC=1.00e-05 is ok.

2) By using ALGO=Conjugate (instead of Normal), we observed that the convergence with SYMPREC=1.00e-04 is not as good as with SYMPREC=1.00e-05.

The very plausible explanation is that using SYMPREC=1.00e-04 leads to additional symmetry operations that are, in the present case, harmful, i.e. they over-symmetrize the electron density, that becomes inconsistent with the orbitals and potential. This is likely to break the variational principle, leading to somehow strange and unreliable results. Thus, increasing the value of SYMPREC should be done with great care and a value of SYMPREC=1.00e-2 that you mentioned in your last message should probably never be used.

[MBaeker]

Thanks for the Tip with using ISYM=-1 to check which symmetry is o.k.

I am still a bit worried by this, not so much for my own simulations, but for automated workflows like custodian or pymatgen, where AFAIK changes in SYMPREC are sometimes used to restart simulations that suffer from symmetry errors.