Error message when including Spin-orbit coupling: BRMIX: very serious problems

[ben_howchen1]

Hi All,
I have an issue where when I turn on spin orbit coupling through the LSORBIT tag the job fails with the error message below. Note that this only happens when I turn on SOC
‘..
DAV: 5 -0.237893224113E+06 -0.23364E+06 -0.22422E+02821720 0.821E+00
BRMIX: very serious problems the old and the new charge density differ old charge density: 182.00000 new 182.74986 0.485E+02
WARNING: Sub-Space-Matrix is not hermitian subr -1.203546222695745E-0021356’

I appreciate this question has been asked many times on this forum however I have systematically tried all the suggestions I have read without any success. Some examples of the things I have tried: Increasing kpoint mesh density (my density is 0.014 A^-1), Symmetry is turned off, PREC = Accurate, increased NBANDS, trying different ALGO tags and different mixing parameters/types.
Is there something I am missing here?
Some of my INPUT tags are as follows:
PREC = Accurate
ENCUT = 800
ALGO = FAST
ADDGRID = .TRUE.
NELMIN = 4
NELM = 100
NELMDL = 0
EDIFF = 10d-5
ISMEAR = 0
SIGMA = 0.2
NBANDS = 1920
NEDOS = 1000
IBRION = -1
ISIF = 3
NSW = 0
ISYM = -1
EDIFFG = 0.001

[martin.schlipf]

Which version of Vasp are you using?

I have fixed an issue like this for the tetrahedron method (ISMEAR = -5) in version 6.1, but I'm not aware of a similar issue for ISMEAR = 0.

If the charge density jumps that indicates that the determination of the Fermi level failed. That way too many or too little states are occupied. The best approaches are to change the smearing method, but again that shouldn't happen for ISMEAR = 0, because the charge over Fermi-energy curve should be continuous and monotonous.

[ben_howchen1]

Thanks for the swift reply.

I am currently using vasp 5.4.4

I will try playing with the ISMEAR and see what happens. Is this problem related to using SOC? because this issue only occurs when i turn SOC on

[martin.schlipf]

While I cannot comment on the particular system at hand. If the problem is related to the one fixed in the newest version, it only depends on the eigenvalues. Because the eigenvalues are different for SOC you may encounter it there, but the reverse could also happen.

[ben_howchen1]

By changing the ISMEAR to -5 i got a different error message
'===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= PID 28765 RUNNING AT compute281
= EXIT CODE: 9
= CLEANING UP REMAINING PROCESSES
= YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
===================================================================================
Intel(R) MPI Library troubleshooting guide:
https://software.intel.com/node/561764
==================================================================================='

I thought it could be a memory issue but even when i increased the RAM the error persisted

[martin.schlipf]

Just to make this clear, there was a bug in Vasp 5.4.4 with the tetrahedron method (ISMEAR = -5). It didn't occur when you followed the instructions in the manual, but for metallic systems with an even Monkhorst-Pack k-point grid, an error message like the one you reported initially can occur.

However, I don't see how this could happen for ISMEAR = 0, because there the Fermi energy should be well defined. If you attach the input files (INCAR, KPOINTS, POSCAR, and POTCAR), I can try to reproduce the issue with the current version.

[ben_howchen1]

hi there,

i've attached my input files in a zip file here. It wouldnt let me upload them as txt files. Thanks for helping me with this

[martin.schlipf]

Sorry I cannot see the attachment?

[ben_howchen1]

Sorry there was a problem with including the POTCAR, i imagine because the file is too large. I've included everything else and the pseudopotentials i have used are: PAW_PBE Ni_pv, PAW_PBE O_s_GW, PAW_PBE Ir_sv_GW and PAW_PBE La_GW

[martin.schlipf]

I ran your calculation on our machine and could not reproduce it.

Either this issue is already fixed in Vasp 6.1 or it depends on your particular parallel setup.