ISYM=-1 and using IBZKPT and WAVECAR in spin-orbit coupling calculations to save costs.

[alpinnovianus]

Hi,

I am doing meta-GGA calculations with spin-orbit coupling (SOC) enabled, and I wonder if I am correct in doing the following cost-saving measures.

It is written in LSORBIT wiki that we should switch off symmetry (ISYM = -1) when doing spin-orbit calculations.
However, this means the computation cost is increased significantly.
Especially when dense mesh is desired.
For example, a 20x20x10 mesh can be reduced to 396 points only with symmetry.
Without symmetry, we'll have to compute ~10 times more points.

how about the following:

• do non-SOC calculation with symmetry enabled and save WAVECAR

• do SOC calculation with symmetry disabled, read WAVECAR from previous run, and use IBZKPT from previous run (396 points) as KPOINTS for SOC calculation

By the way, I wonder if ISYM = -1 is only necessary when we want to read off WAVECAR from previous run?

As in, if I somehow just want to start a SOC calculation without reading WAVECAR from prior non-SOC calculation,
can I switch on the symmetry in my SOC calculation?

[fabien_tran1]

Hi,

The reason why ISYM=-1 is recommended when LSORBIT=.TRUE. is not related to the WAVECAR, but due to physics. When LSORBIT=.TRUE., LNONCOLLINEAR is automatically also set to .TRUE., and if a system is magnetic, then this may increase the possibility to have a ground state that has a symmetry that is lower than the crystallographic symmetry. And if symmetry is applied during the calculation, then this may be a constraint that would prevent to reach the ground state, so that you would miss it and get another state with higher energy, instead.

Does it matter or not depends on your system and which property you want to calculate. As a test you can make two calculations (with reduced number of k-points to make the test quick), one with ISYM=-1 and the other without, and compare the results.

[alpinnovianus]

Hi,

The reason why ISYM=-1 is recommended when LSORBIT=.TRUE. is not related to the WAVECAR, but due to physics. When LSORBIT=.TRUE., LNONCOLLINEAR is automatically also set to .TRUE., and if a system is magnetic, then this may increase the possibility to have a ground state that has a symmetry that is lower than the crystallographic symmetry. And if symmetry is applied during the calculation, then this may be a constraint that would prevent to reach the ground state, so that you would miss it and get another state with higher energy, instead.

Does it matter or not depends on your system and which property you want to calculate. As a test you can make two calculations (with reduced number of k-points to make the test quick), one with ISYM=-1 and the other without, and compare the results.

Thank you for the reply,

Would you please clarify the suggested approach shown in the wiki for LSORBIT?
wiki/index.php/LSORBIT

especially the parts:

"The recommended procedure for the calculation of magnetic anisotropies is therefore:

• Start with a collinear calculation and calculate a WAVECAR and CHGCAR file.

• add LSORBIT, ICHARG, LMAXMIX, SAXIS, NBANDS tags

• VASP reads in the WAVECAR and CHGCAR files, aligns the spin quantization axis parallel to SAXIS, which implies that the magnetic field is now parallel to SAXIS, and performs a non selfconsistent calculation.

...
Be very careful with symmetry. We recommend to switch off symmetry altogether (ISYM=-1), when spin-orbit coupling is selected. Often the k-point set changes from one to the other spin orientation, worsening the transferability of the results (also the WAVECAR file can not be reread properly if the number of k-points changes)"

I think we cannot read the WAVECAR from collinear calculation if ISYM=-1 is only selected in the noncollinear SOC calculation since the number of k-points will change between the two. In the 20x20x10 example, the collinear with symmetry will compute 396 k-points while the noncollinear without symmetry will compute 4000 points.

Hence, are you suggesting that we also set ISYM= -1 even during the collinear run?

We're having difficulties converging non-collinear SOC calculations if we start off with ISYM=-1 directly with regular 20x20x10 mesh.
(without having collinear WAVECAR or using IBZKPT from symmetrized collinear calculation).
Thus, I think it's probably necessary to read the WAVECAR to help with convergence.

[fabien_tran1]

Yes, as you mentioned and as written on the wiki it is necessary to generate WAVECAR from the collinear calculation with ISMY=-1. Otherwise, the number of k-points will change (from collinear to non-collinear) and the WAVECAR can not be read.

Concerning convergence, it is known that it may be very difficult to achieve convergence with MGGA functionals in non-collinear mode. For your case, have you tried the GGA-PBE in non-collinear mode? If the GGA-PBE calculation converges (and without ISMY=-1), then the WAVECAR file could be used to start the MGGA calculation. Have you tried that?

[alpinnovianus]

Yes, as you mentioned and as written on the wiki it is necessary to generate WAVECAR from the collinear calculation with ISMY=-1. Otherwise, the number of k-points will change (from collinear to non-collinear) and the WAVECAR can not be read.

Thank you. I now try the collinear calculation with ISYM = -1.

For your case, have you tried the GGA-PBE in non-collinear mode? If the GGA-PBE calculation converges (and without ISMY=-1), then the WAVECAR file could be used to start the MGGA calculation. Have you tried that?

I have not tried GGA-PBE in noncollinear mode as I did not know this was possible.
Just to double-confirm though, for the noncollinear GGA-PBE calculation you mentioned here,

If the GGA-PBE calculation converges (and without ISMY=-1),

we should set ISYM = -1, right?
(I thought this may be a typo, since you were emphasizing the necessity of switching off symmetry in noncollinear calculations)

Thank you.

[fabien_tran1]

No. My suggestion with GGA-PBE is precisely to avoid the use of the costly ISYM=-1. The idea is to generate WAVECAR with GGA-PBE-noncollinear (a GGA should show less problems to converge than a MGGA) without ISYM=-1, and then start the MGGA-noncollinear calculation (also without ISYM=-1) with the WAVECAR generated by the GGA-PBE-noncollinear calculation. Maybe, starting from the GGA-PBE-noncollinear WAVECAR will solve the convergence problem with MGGA-noncollinear that you reported.

But again, as I mentioned in my first answer, not using ISYM=-1 is a bit dangerous from the physical point of view.