My Community

Hello,
I faced a bug when I performed geometry optimization of a spin-polarized metallic slab with "ALGO=Damped + NBANDS > Default".
"internal error in: rot.F at line: 803
EDWAV: internal error, the gradient is not orthogonal 11 1 1.282e-3
If you are not a developer, you should not encounter this problem.
Please submit a bug report."

All input- and output files are put in a tar file, and VASP.6.4.2 was compiled with the following environment.
Intel oneapi 2023.0.0, AMD E7763, VTSTcode-198

Because I am a very beginner with VASP, I am not sure if it is a bug or my wrong calculation settings.
I hope this report will contribute the community.

P.S.
If I use "ALGO=Normal, NBANDS=Default", there are no bugs. However, the SCF calculation was never converged with dE > 0.1E+03 even after >90 SCF steps.
Are there any strange settings in my calculation?

Best.

Hi,

This is a problem that has already been reported, but it is not really clear what is the reason. A possible explanation may be that the shapes of the density and potential are at some point very unreasonable, leading to technical problems in the minimization algorithm.

A way to avoid the crash is to use ALGO=Conjugate, which however may lead to a very slow convergence of the calculation (according to my test dE decreases quite steadily but slowly, so be patient).

Maybe already enough, is to use ALGO=Conjugate only for the first 80 iterations for instance (you can stop the calculation at any moment with a STOPCAR file) and then continue it with ALGO=Damped.

Concerning ALGO=Normal, you mentioned that dE>0.1E3. How was dE varying? Was it stuck at 0.1E3 or continuing to decrease?

If the mentioned suggestion does not work, another one would be to comment out LDIPOL and IDIPOL in INCAR, and do a few ionic steps with the hope that the error would not appear. Then, restoring LDIPOL and IDIPOL and continuing the calculation would maybe also be ok.

Thank you for your kind responses. I apologize for the late reply.
About the convergence problem with ALGO=Normal, the energy diverged to a negative value, and VASP stopped with an error message (see "Intel" directory in an attached tar file).
However, when I performed the same calculation by VASP compiled with the AOCC compiler, it converged (see "AOCC" directory).
As I mentioned, the calculations were performed on an AMD CPU (AMD E7763), and both compilations passed the test suite.
Are there any compilation issues reported with the combination of the Intel One API and AMD CPU?

Hi,

I could reproduce the problem. The total energy starts to be nonsense (at around the 10th iteration) with the Intel compiler, while everything seems to be fine with the AOCC and GNU compilers (I also used AMD CPUs). I will discuss about that with a colleague, but there is probably low chance that we can do something. So, meanwhile the only solution seems to use the AOCC or GNU compiler.

Thank you for your kind investigation.
I understand. I currently use VASP compiled with AOCC, and I have not met severe problems.
Thank you so much again for your kind support.

@fabien_tran1, has the VASP team uncovered any further ways to avoid this particular error? I am running into it a lot with my current vasp 6.4.2 compile when I am running r2SCAN calculations. These are normal static/relaxation calcs, and I'm already using Algo = Conjugate for all of my calcs.

No, we have not investigated further into this problem. Nevertheless, could you please provide the files of one of your cases (the most simple static one) and specify which compiler was used.