Page 1 of 1

internal error in SET_INDPW_FULL: insufficient memory

PostPosted: Wed Dec 06, 2017 10:31 am
by DannyVanpoucke
Dear VASPers,

I have recently run into a problem which got me quite puzzled. In my study I am comparing DFT and DFT+U optimized structures. In a second step, I use a HSE06 calculation to generate accurate electronic structures. Although the structures are visually the same (and have the same reported symmetry), one case(DFT+U optimized) gives me the error:

internal error in SET_INDPW_FULL: insufficient memory

While the other(DFT optimized) runs happily to the end.

Does anyone have any experience with this error? And knows how to resolve it or knows where it come from?

The INCAR file used is this one:
Code: Select all
    SYSTEM = Cr2O3_ZnSub_NUDfree_h221
    ISTART = 0   
    ICHARG = 1
    ISMEAR = 0 
    SIGMA = 0.05
    EDIFF = 1.0E-4
    PREC = Accurate
    ENCUT = 600
    LWAVE = .TRUE.
    ISPIN =  2   
    VOSKOWN = 1
    LASPH = .TRUE.
    IBRION = -1
    NSW = 0     
   NPAR = 2 ; KPAR = 2
      LORBIT = 11
      EMIN = -70 
      EMAX = 35 
      NEDOS = 10500
magnetic properties for HSE06:
    !NUPDOWN = free
    !ISYM = 0
     MAGMOM = 2.0 3*4.0 4*-4.0 4*4.0 4*-4.0 4*4.0 4*-4.0 4*4.0 4*-4.0 4*4.0 4*-4.0 4*4.0 4*-4.0  72*0.0
         LORBIT = 11
         LMAXMIX = 4
    AMIX = 0.2
    BMIX = 0.0001
    AMIX_MAG = 0.8
    BMIX_MAG = 0.0001
HSE06 parameters:
    ALGO = A
    HFSCREEN = 0.2
    AEXX = 0.25
    AGGAX = 0.75
    AGGAC = 1.0
    ALDAC = 1.0
    NKRED = 1

    NELM = 30

Thank you.

Re: internal error in SET_INDPW_FULL: insufficient memory

PostPosted: Fri Dec 08, 2017 11:14 am
by alex
Hi Danny,

it looks like you are running into trouble with the k-point set.
- Do you have a hexagonal cell? Cr2O3 suggests so...
- Did you center the mesh at the gamma point?
Otherwise you might create a HUGE number of k-points, because you are off symmetry with the set.



Re: internal error in SET_INDPW_FULL: insufficient memory

PostPosted: Wed Dec 13, 2017 9:51 am
by DannyVanpoucke
Hi Alex,

Yes, indeed the cell is hexagonal, and yes the k-points are Gamma centered.
The strange thing is that the same calculation for DFT(+U) works fine. (If I would have gotten the same error there I would have been less amazed.)


Re: internal error in SET_INDPW_FULL: insufficient memory

PostPosted: Thu Dec 14, 2017 10:52 am
by alex
Hi Danny,

maybe your HSE06 calculation simply does not fit into your machine. Please allow at least 2GB/process. Better 4GB. You'll see the requirements growing rapidly after the initial iterations are done.

Some other tags I'm puzzled about: NPAR and KPAR. I never used it, because exact exchange calculations did not allow NPAR .le. number of cores. And with KPAR I simply don't know. I'm also using a slightly older version of VASP.



Re: internal error in SET_INDPW_FULL: insufficient memory

PostPosted: Fri Dec 15, 2017 10:11 am
by DannyVanpoucke
Hi Alex,

Indeed memory was one of the first things to check (and I have more than 2gb/core available), however, note that this calculation doesn't even start a first iteration (while an almost identical one runs to the end without issues.). The NPAR and KPAR are set to make sure such a calculation can even run. KPAR (parallelisation over k-points works ridiculously well for hybrids in my experience with VASP), and indeed NPAR is suggested to be set equal to the the number of cores, but I have found it can also be set to 1/node (which give an enormous speedup) and seems to work fine.

Thank you for your suggestions.

PS: I have received a solution of the problem by the vaspmasters. Apparently the symmetry was slightly broken in this system, and the issue gets resolved by setting SYMPREC to a lower value.

Re: internal error in SET_INDPW_FULL: insufficient memory

PostPosted: Sun Dec 24, 2017 7:42 am
by mwistey
SYMPREC does not fix this for me. Nor does more memory--even on a 1.5 TB machine with 20GB per core (!). It doesn't matter whether I set SYMPREC to 1E-3 or 1E-7, nor KPOINTS from 2x2x2 to 3x3x3 (auto generated, including Gamma). It doesn't matter if my system is perfectly symmetric (Ge diamond lattice) or slightly off (1 C atom, 127 Ge atoms). Is this a VASP bug, or am I just missing something obvious?

INCAR is posted below.

ISTART=0 # 1=resume from previous WAVECAR. 0=start from scratch. BandUP says use 0 in step_1.
#INIWAV=1 # always use default 1. (0 would be jellium)
ICHARG=2 #1=read and update CHGCAR (self-consistent). 11=Read CHGCAR *and don't change it* (i.e. nonselfconsistent). ICHARG=2 #2=Take superposition of atomic charge densities but allow to change.
LHFCALC=.TRUE. # By default, this will be PBE0 using PBE pseudopotentials
HFSCREEN=0.2 # this turns on HSE06; HFSCREEN=0 is PBE0
PRECFOCK=Fast # can use Normal or Accurate for higher quality, but cost goes up considerably
#NKRED=2 # speeds up calc, but lower quality; ok for perfect crystals with a gap and enough kpoints, questionably for Ge, so I (CAS) turned it off here (commented out)
#SYMPREC=1E-7 # Tried values from 1E-3 to 1E-7
ISMEAR=0 # 0=Gauss for semi's. -5=tetra (small cells). >0=(metals only).
SIGMA=0.05 # width of smearing, eV.
#ALGO=All # alternative to ALGO/TIME below, which work well for this system
ALGO=Damped # rec'd for small gap systems
LDIAG=.TRUE. # might want to turn this on; see manual
LREAL=.FALSE. # Don't change this for subsequent calcs.
ENCUT=520 # Don't change this for subsequent calcs.
NGX=126 # Prevent aliasing. Based on 12/19/2017 runs.
NSW=0 # If we don't converge in 10 steps, we probably won't
IBRION=-1 #1=update ion positions. #-1=no update but re-optimize e- degrees of freedom each NSW loop. If no ionic update is required use NSW=0 instead.
NELMIN=3 # minumum number of electronic steps
NELM=3 # maximum number of electronic steps unless EDIFF reached
NSIM=4 #
NPAR=28 # CPUs per group. 28 for LEAP, 24 for Comet. 8=sqrt(72) on LEAP himem.
# KPAR=2 # How to parallelize k points
LASYNC=.FALSE. # reduces inter-node communication
LWAVE=.TRUE. # BandUP doesn't need WAVECAR, but VASP doesn't resume a job properly without it; starts over from scratch.