Divergence on a new computer cluster; Error report when reducing one electron

[can_liu]

Hello,

1. I optimized a slab system using vasp.5.4.1 on the server of our own institution. However, when I tried to do the same calculation using vasp.5.4.4 on a new computer cluster, it diverged. The input files and OUTCAR, OSZICAR, stdout files are uploaded in
   report1 (divergence).zip
   . "runvasp.sh" is the script file to submit the job.

• Then, I tried to solve this problem by reducing one electron from the system. In the previous OUTCAR, NELECT=1281. So I set NELECT=1280 in the INCAR, and calculated again. But VASP reported an error as below:

  | LDIPOL = .TRUE. must be selected only for cubic supercells, since |
  | the quadrupole corrections are currently only implemented for this |
  | specific geometry. |
  | Please change your box, or set LDIPOL=.FALSE. |
  | |
  | ----> I REFUSE TO CONTINUE WITH THIS SICK JOB ..., BYE!!! <---- |

  The input files and OUTCAR, stdout files are in
  report2 (NELECT-1 error).zip
  . I have also tried with LDIPOL=.FALSE. But it still diverged.

Is the problem due to the difference between vasp.5.4.1 and vasp.5.4.4? How can I get converged result?

Thanks.

[martin.schlipf]

As a general disclaimer: If you encounter convergence issues, it is a good idea to check whether you can reproduce them in a smaller cell. Then you spent much less resources to find a solution.

It is possible that your initial mixing is to aggressive. You can reduce the mixing by tweaking the parameters AMIN, AMIX, AMIX_MAG, and BMIX. The description of BMIX mentions some strategies that you can apply. You may want smaller AMIN and larger BMIX.

Some systems also require a larger number of bands then VASP chooses by default. A signature of this is if you observe that the occupations are not vanishingly small for your topmost state.

I'm not sure what your intention with changing the number of electrons was. Also your report seems inconsistent with the produced output. You specified NELM = 60 in the INCAR file, but the OSZICAR contains many more steps.

One more thing: You don't need to try for ~170 iterations if you don't get a reasonable convergence within the first few iterations within the first 15~20 iterations you will typically not converge. You may not be fully converged after these iterations, but you should not see energy jumps of 10000 eV anymore.

[ferenc_karsai]

I ran the first calculation with VASP 6.1.0 and everything works fine.

One important thing: You set LDIPOL=.TRUE. in that case. I think that's a mistake so please retry that calculation without that flag. I also encounter bad behaviour if I set that flag, since it's a non-cubic system.

[can_liu]

Thank you very much for the suggestions.

When moving to the new computer cluster, I have examined calculation with small bulk cells and single molecules, respectively. They all worked well. I have also tried calculating this slab system by removing the adsorbed H atom, or putting a methanol molecule as the adsorbate. They converged well, too. But, as long as there is an extra H atom, the calculation diverged, which is different from the case using vasp.5.4.1 at the institution server. We thought it might be the problem of an extra electron, so tried to reduce the electron number.

I'm sorry for the mistake in the INCAR file. NELM was set as 200, not 60. The other parameters are the same.

[martin.schlipf]

Let me know if you still struggle to converge.

[can_liu]

I retried the calculation without the LDIPOL flag, and it converged well. The energy difference with the previous calculation was less than 0.001 eV. Thank you very much.
I'm puzzled about the LDIPOL flag. Is it that only IDIPOL is needed for the dipole correction on slab calculation? When to use LDIPOL on a non-cubic cell?

[martin.schlipf]

The wiki gives some helpful advice: wiki/wiki/index.php/LDIPOL

First converge without LDIPOL, then switch it on. For charged systems you cannot use LDIPOL unless your system is cubic.
Note that you only need LDIPOL to correct the potential and the forces. The energies can be corrected with IDIPOL.

Here is a more elaborate write-up wiki/index.php/Monopole_Dipole_and_Quad ... orrections

[can_liu]

Thank you for the explanation.

I tried to calculate the same slab system with a dissociated molecule on the surface, using the same INCAR. Then the calculation diverged again. All the files are attached (report3).
Shall I try modulating AMIN and BMIX? But I’m not sure how to do it. According to the instruction of BMIX in vaspwiki, the goal is to get mean eigenvalue approaching 1. But there are many mean eigenvalues in OUTCAR.

[martin.schlipf]

I don't see an attachment to your post.

But there are many mean eigenvalues in OUTCAR.

Look for the following in your OUTCAR file

Code: Select all

 eigenvalues of (default mixing * dielectric matrix)
  average eigenvalue GAMMA=   0.1978
  0.4661  0.0942  0.0332

The second line contains the average eigenvalue, the third line a list of all eigenvalues.

[can_liu]

I'm sorry that the uploading failed. I cannot upload POTCAR, as the system reports "the board attachment quota has been reached". Here are the other files (

report3(no POTCAR).zip

).

There are average eigenvalues in each electronic selfconsistency step since "Iteration 1(6)". Which one to focus on?

[martin.schlipf]

I plotted your data to make it more accessible. What we are looking at in particular are the rms(c) column of the OSZICAR. This describes the error in the charge density and the "average eigenvalue GAMMA=" of the OUTCAR, which is produced by the density mixer.
https://plotly.com/~schlipf/1/
The density mixing only sets in after NELMDL steps, so there is no rms(c) written for the first few iterations.

If you look at the plot, you can see that initially the system is on a good track but then after ~15 iterations it deteriorates and goes on a wrong trajectory. In the branch that goes bad, the average eigenvalues continuously shrink, but they start of from a value larger than 1, so there is no clear-cut answer what would improve the behavior. Here are a couple of suggestions what you can try

1) Reduce AMIN and increase BMIX. This reduces the mixing speed and may avoid the slip of the average eigenvalues below 1.
2) Restart the mixing after ~15 steps. You can do this either by setting NELM = 15 and the restarting from that WAVECAR or by changing MAXMIX in the INCAR file.
3) I noticed that you use LDA+U. Because this is not seen by the mixer it can be better to converge initially without LDA+U and only switch it on after you converged the density once.

[can_liu]

Thank you for your suggestions.

I modified AMIN and BMIX, and found that it could converge in the first iteration with AMIN=0.08 and BMIX=1.1. However, in the second iteration, it diverged again. Please see the attachment:

report5.zip

I cannot upload POTCAR due to the limitation of the forum.

I also tried with the suggestions 2) and 3), but the results were the same. By setting NELM = 15 and restarting from that WAVECAR, it diverged again in the new run. Without LDA+U, it still could not converge.

[martin.schlipf]

You can inspect your output and see that something is going wrong in the mixer between step 8 and 9 of the second iteration.

If you look again at the average eigenvalue GAMMA output, you will see that you get vanishing eigenvalues so that the mixer gets very sensitive.

My first suggestion would be to restart from the second iterations (set NSW = 1 in the first run). There are various ways you can do that:
1) Full restart using WAVECAR and copy CONTCAR to POSCAR.
2) Restart from density (CHGCAR), delete WAVECAR and copy CONTCAR to POSCAR (set ICHARG = 1).
3) Restart from the positions only, delete WAVECAR, do not set ICHARG and copy CONTCAR to POSCAR.

One other thing you can try is to change the number of iterations when the mixer is reset.

[can_liu]

Thank you for the suggestions.
We installed VASP in another way, using intel library with LAPACK instead of scaLAPACK. Then the calculations converged, giving the similar results with those run on our own servers.
Thank you all the same. If we meet this kind of problem again, we will try as you suggested.