ISYM >= 0 and LOCPROJ

[hnourse]

There are two issues here when using LOCPROJ (none of the below occurs when not setting the LOCPROJ flags). Tested with VASP 5.4.4 (vasp_std). I am unsure if this is fixed in VASP 6.

1.

file1.zip

When using ISYM >= 0 with automatic k-mesh generation for KPOINTS and NCORE > 1. This particular test is for NCORE = 2, and executed with mpirun -n 2 vasp_std. The error message is:

internal error in GENERATE_KPOINTS_TRANS: number of G-vector changed in star 155 156
internal error in GENERATE_KPOINTS_TRANS: number of G-vector changed in star 171 170

The above error has been documented before for LWANNIER90=.TRUE. forum/viewtopic.php?t=11675 .

2.

file2.zip

When entering all k-points explicitly for KPOINTS. Here KPOINTS is taken from an IBZKPT output with ISYM = -1, no LOCPROJ flags set, and NCORE = 1, executed with mpirun -n 1 vasp_std. This should have the exact same grid as an automatically generated k-mesh with no symmetries. I have also tested using KpLib (ISMEAR = 0) and K-Point Grid Generator (ISMEAR = -5) from http://muellergroup.jhu.edu/K-Points.html. The pertinent error message is:

Your generating k-point grid is not commensurate to the symmetry
of the lattice. This does not sit well in combination with the
PEAD routines, sorry ...
suggested SOLUTIONS:
) if not already the case, use automatic k-point generation
) shift your grid to Gamma (G) (e.g. required for hex or fcc lattice)

3.

file3.zip

An additional test showing that setting the LOCPROJ flags results in PROJCAR outputting the full k-mesh for ISYM >= 0 and NCORE = 1, executed with mpirun -n 1 vasp_std. In this particular test with ISYM = 0 there are 112 k-points in IBZKPT but 216 k-points in PROJCAR.

Occurs for any LORBIT >= 12 (I haven't tested for any others). However, ONLY occurs if LOCPROJ is set. Setting LORBIT without LOCPROJ does not cause any errors (ignoring that the partial charge densities are wrong in VASP 5 for LORBIT as outlined here wiki/index.php/LORBIT, and previously documented here forum/viewtopic.php?f=3&t=306).

The above also occurs when using Hy orbitals.

The above also occurs when using ISMEAR >= 0.

Increasing SYMPREC does not change the error in test 2.

The test system presented here is for NiO. I have also checked that the above occurs for SrVO3.

[hnourse]

To follow up on this:

The reason any of these errors occur is that the pertinent subroutines in locproj.F call USE_FULL_KPOINTS from pead.F and constructs its own k-mesh to calculate the projectors in the full BZ, which will then fail in the cases I pointed out above.

Is there a reason the full k-mesh is required for the projectors? Couldn't KPOINTS be passed to the LPRJ_PROALL routine when called in main.F and electron.F so that the projectors are only constructed for the IBZ? None of the normalizations on the projectors is done by VASP anyway.

The subroutine LPRJ_LDApU also likely only needs KPOINTS passed because the density can be calculated using the appropriate k-weight.

I have done some quick testing with VASP 5.4.4 by making the above modifications and appropriately changing the CALC_OVERLAP_GN subroutine. It's hard to test if this gives the right answer because, as far as I can tell, VASP 5.4.4 still has issues with LORBIT >= 12 and correctly calculating partial densities. I am unsure if this carries over to potential errors in LOCPROJ.

Am I missing something in the logic here for why the full k-mesh is used for LOCPROJ?

[martin.schlipf]

Thank you for reporting this to us. I could reproduce the error with VASP 6 and will investigate further.

Regarding the second point, it may be that the code simply fails to recognize that you use a regular mesh.