My Community

ear VASP Team,

I am performing temperature-dependent band gap calculations using VASP 6.4.2 and encountered the following error during the SCF cycle:

"Error EDDDAV: Call to ZHEGV failed. Returncode = 1 2 384"

This error occurs when going from a 1x1x1 to a 2x2x2 supercell to check the convergence of bandgap. The issue is resolved when I set ISYM=0, but disabling symmetry significantly increases the calculation time, which I would prefer to avoid.

Could you please advise on how to resolve this issue without setting ISYM=0? I have attached the input files for reference.

Thank you for your assistance.

Hi,

thank you for your concise description. Not using symmetry can indeed significantly increase the computational time.

Could you please share your output files and submission scripts of both, the run with ISYM=0 and symmetry?

Thanks,
Marie-Therese

Dear Marie-Therese,

Please see the attached OUTCAR and submission scripts with and without symmetries.

Regards
Ajitha

Dear aijitha_john,

I apologize for the long waiting time for this reply.

I have a couple of suggestions to try without turning symmetry off:

• Try to switch to a different algorithm for electronic convergence, e.g. ALGO = Fast.

• If your electronic system does still not converge, try to increase your smearing width. SIGMA = 0.05 is quite small.

• In general it is a good idea to follow the advice given in the Troubleshooting electronic convergence article on our wiki.

Other inefficiencies in your calculation could significantly speed up the calculation, even with ISYM = 0:

• If you are using only the Γ point, use the Γ-only version of VASP.

• Please heed the suggestions and warnings printed by VASP in the stdout and the OUTCAR file. In this case, please set NCORE appropriately.

Please note that you have selected the PBE functional by setting GGA = PE in your INCAR file. Not the PBEsol functional as you state in your comment. That would be selected by setting GGA = PS

Let me know if any of these strategies help you to finish your calculation.
Cheers, Michael

Hello aijitha_john,

I typically observe your kind of behaviour if the granularity of the parallelisation does not match the INCAR settings. I'm using the old fashioned NPAR, which I set to twice the number of nodes or even four times as high (not cores. On an AMD machine with 2 CPUs and 128 cores in total). No other parallisation settings in INCAR for me.
However, I only get this error for Davidson, e.g. ALGO = N.

So if you have an electronically well bahaving system you may consider to changing to ALGO=V for two reasons: getting faster and getting rid of the error message. If not, try the suggested NPAR settings. :-)

Good luck

alex

Dear Alex,

Thank you for your suggestion.
But I am running frequency calculations with IBRION = 6 flag and in this case I cannot set NPAR!

In my library of fixes I switch to `ALGO=All` when this error occurs (I think I got this from custodian), so switching away from Normal as alex suggests seems worth a shot.