Bug when computing dielectric constant for hexagonal lattice
Posted: Sun Nov 20, 2016 11:22 am
Hi,
When computing the dielectric constant for hexagonal GaN I found immediate stop of VASP with the following error message (as many times as number of CPUs):
internal error in GENERATE_KPOINTS_TRANS: number of G-vector changed in star
1569 1570
The INCAR file is:
SYSTEM = GaN PBE0
# parallelization parameters
NCORE = 1 ; KPAR = 4
# scf method
ALGO = A ; TIME=0.03
# precision and integration-related parameters
LREAL=Auto ; ISMEAR = 0 ; SIGMA=0.25
ENCUT=600 ; PREC = Accurate ; EDIFF=1E-5
LASPH = .TRUE. ; ADDGRID = .TRUE. ; LMAXMIX = 4
# computing dielectric constant
LCALCEPS=.TRUE. ; EFIELD PEAD = 0.003 0.003 0.003
# cell relaxation
IBRION= -1 ; NSW= 0
# DOS and other output setup
EMIN= 0.0 ; EMAX = 20.0 ; NEDOS = 2001
LORBIT = 11 ; LORBMOM=.TRUE.
LWAVE=.FALSE.
The KPOINTS file is
Gamma-centered grid
0 #automatic MP grid generation
G
12 12 8
The tail of OUTCAR is
IXMIN= -6 IYMIN= -6 IZMIN= -10
NGX is ok and might be reduce to 26
NGY is ok and might be reduce to 26
NGZ is ok and might be reduce to 42
serial 3D FFT for wavefunctions
parallel 3D FFT for charge:
minimum data exchange during FFTs selected (reduces bandwidth)
The problem only appears with LCALCEPS=.TRUE. . Suppressing KPAR=4 does not alleviate the problem, which however disappears by adding ISYM=-1. The surprising thing is, that the problem does not appear if I make the same calculation for rutile TiO2 (tetragonal) with exactly the same INCAR file as above. And I noticed in the forum that an error related to GENERATE_KPOINTS_TRANS, when using LWANNIER90 on a hexagonal lattice, was also reported on Dec 04, 2013, and the error was said to disappear as well with ISYM=-1.
Of course I may make the computation with ISYM=-1, but why should the problem appear for hexagonal lattice and not for tetragonal one? It seems as if the number of G vectors were computed in two different places when computing epsilon, and the results were not coherent for a hexagonal lattice (compare the two numbers 1569 and 1570 in the error above). I would say that this behaviour should be considered a bug in the code. Decreasing the number of k points to be computed is important especially when one wants to make the calculation with a hybrid functional (which is my case).
Regards,
When computing the dielectric constant for hexagonal GaN I found immediate stop of VASP with the following error message (as many times as number of CPUs):
internal error in GENERATE_KPOINTS_TRANS: number of G-vector changed in star
1569 1570
The INCAR file is:
SYSTEM = GaN PBE0
# parallelization parameters
NCORE = 1 ; KPAR = 4
# scf method
ALGO = A ; TIME=0.03
# precision and integration-related parameters
LREAL=Auto ; ISMEAR = 0 ; SIGMA=0.25
ENCUT=600 ; PREC = Accurate ; EDIFF=1E-5
LASPH = .TRUE. ; ADDGRID = .TRUE. ; LMAXMIX = 4
# computing dielectric constant
LCALCEPS=.TRUE. ; EFIELD PEAD = 0.003 0.003 0.003
# cell relaxation
IBRION= -1 ; NSW= 0
# DOS and other output setup
EMIN= 0.0 ; EMAX = 20.0 ; NEDOS = 2001
LORBIT = 11 ; LORBMOM=.TRUE.
LWAVE=.FALSE.
The KPOINTS file is
Gamma-centered grid
0 #automatic MP grid generation
G
12 12 8
The tail of OUTCAR is
IXMIN= -6 IYMIN= -6 IZMIN= -10
NGX is ok and might be reduce to 26
NGY is ok and might be reduce to 26
NGZ is ok and might be reduce to 42
serial 3D FFT for wavefunctions
parallel 3D FFT for charge:
minimum data exchange during FFTs selected (reduces bandwidth)
The problem only appears with LCALCEPS=.TRUE. . Suppressing KPAR=4 does not alleviate the problem, which however disappears by adding ISYM=-1. The surprising thing is, that the problem does not appear if I make the same calculation for rutile TiO2 (tetragonal) with exactly the same INCAR file as above. And I noticed in the forum that an error related to GENERATE_KPOINTS_TRANS, when using LWANNIER90 on a hexagonal lattice, was also reported on Dec 04, 2013, and the error was said to disappear as well with ISYM=-1.
Of course I may make the computation with ISYM=-1, but why should the problem appear for hexagonal lattice and not for tetragonal one? It seems as if the number of G vectors were computed in two different places when computing epsilon, and the results were not coherent for a hexagonal lattice (compare the two numbers 1569 and 1570 in the error above). I would say that this behaviour should be considered a bug in the code. Decreasing the number of k points to be computed is important especially when one wants to make the calculation with a hybrid functional (which is my case).
Regards,