My Community

Let me start by saying I'm pretty new to Vasp, so my issues could easily be syntax errors or basic concepts that I am maybe misunderstanding.

My ultimate goal is to calculate a reasonably accurate HSE06 band structure of monoclinic HfO2 while utilizing as many tools as possible to minimize simulation runtime. However, I'm having trouble even doing a basic self-consistent calculation.

My approach to doing this is to start with an HfO2 unit cell (12 atoms) and perform a relaxation (ISIF=3) using GGA to get the minimum-energy lattice parameters and a WAVECAR file. My k-mesh is an 8x8x8 Gamma-centered Monkhorst mesh.

A few starter questions:

From this, I use the CONTCAR and WAVECAR files as inputs into an HSE06 calculation also using ISIF=3. Is this the correct next step?

I am working on a cluster and have attempted using as many as 40 cores (5 nodes) for the HSE06 run. I believe each node offers 16 GB of memory, but attempts to use less than 4 nodes have often crashed seemingly due to lack of memory. How much memory do you think is normal for an HSE06 run to use?

I have also noticed that the Vasp refuses to run if NPAR is not exactly equal to the number of cores being used. This seems to contradictory to the Vasp manual, which recommends using NPAR = sqrt(Number of nodes).


Finally, below are the contents of several files: 1) My GGA INCAR file, 2) My HSE06 POSCAR file, 3) My HSE06 INCAR file, 4) The last lines of my HSE06 OUTCAR file, and 5) My Vasp.log file.

Can anyone help me figure out what I am doing wrong and what could be causing me to get all the different warnings seen in the OUTCAR and Vasp.log? Any help with this, as well as general advice for effective ways to reduce memory usage and runtime, would be greatly appreciated.


####### 1. GGA INCAR file ###########
ISTART = 0
INIWAV = 1
ICHARG = 2

IALGO = 48
NELM = 40
NELMIN = 0
NELMDL = 3
EDIFF = 1E-05

EDIFFG = -1E-04
NSW = 50 # Number of ionic convergence steps
IBRION = 2
ISIF = 3 # All lattice parameters vary
PREC = H
ISPIN = 2
NPAR = 8 # Uses 8 cores per node

RWIGS = 1.924 0.725

LPLANE = .TRUE.
LWAVE = .FALSE.
LCHARG = .FALSE.


########### 2. HSE06 POSCAR File ##########
Monoclinic HfO2 P21c1-c1
5.11940000000000
1.0382734756746705 0.0030795635792026 -0.0828596744890993
0.0036716281579297 1.0260731867865183 0.0845148974051064
-0.0852711735848408 -0.0870860089102080 1.0616310658842181
Hf O
4 8
Direct
0.2723961978704765 0.0316283992356704 0.2042798753061300
0.2724041920570210 0.4683644889681100 0.7043558092873726
0.7276038021295234 0.9683716007643297 0.7957201246938700
0.7275958079429791 0.5316355110318901 0.2956441907126273
0.0661996353151822 0.3140785502209141 0.3631048695583488
0.0662033305287402 0.1859461187400400 0.8630848201028998
0.9338003646848179 0.6859214497790858 0.6368951304416510
0.9337966694712596 0.8140538812599598 0.1369151798971002
0.4506503520606588 0.7551834793982087 0.4819527419817263
0.4506509552156585 0.7447992002954438 0.9819505463784138
0.5493496479393414 0.2448165206017844 0.5180472580182733
0.5493490447843421 0.2552007997045634 0.0180494536215861


########### 3. HSE06 INCAR File ##########
ISTART = 1
ICHARG = 0

LHFCALC = .TRUE.
HFSCREEN = 0.2
ALGO = All
TIME = 0.4
PRECFOCK = Fast

NBANDS = 500
NEDOS = 3000

NELM = 40
NELMIN = 0
NELMDL = 3
EDIFF = 1E-05 # Tolerance for electron convergence

EDIFFG = -1E-04
NSW = 50 # Number of ionic convergence steps
IBRION = 2
ISIF = 3 # All lattice parameters vary
PREC = M
ISPIN = 2
NPAR = 20 # 4 nodes * 5 cores/node

RWIGS = 1.924 0.725

LPLANE = .TRUE.
LWAVE = .TRUE.
LCHARG = .TRUE.


############# Tail of HSE06 OUTCAR file ###########
maximum number of plane-waves: 2781
maximal index in each direction:
IXMAX= 9 IYMAX= 8 IZMAX= 8
IXMIN= -9 IYMIN= -9 IZMIN= -9

WARNING: aliasing errors must be expected set NGX to 38 to avoid them
WARNING: aliasing errors must be expected set NGY to 36 to avoid them
WARNING: aliasing errors must be expected set NGZ to 36 to avoid them
aliasing errors are usually negligible using standard VASP settings
and one can safely disregard these warnings

serial 3D FFT for wavefunctions
parallel 3D FFT for charge:
minimum data exchange during FFTs selected (reduces bandwidth)


total amount of memory used by VASP on root node2080558. kBytes
========================================================================

base : 30000. kBytes
nonl-proj : 210201. kBytes
fftplans : 567. kBytes
grid : 3533. kBytes
one-center: 373. kBytes
HF : 129. kBytes
nonlr-proj: 1195. kBytes
wavefun : 1834560. kBytes

Broyden mixing: mesh for mixing (old mesh)
NGX = 17 NGY = 17 NGZ = 17
(NGX = 42 NGY = 42 NGZ = 48)
gives a total of 4913 points

charge density for first step will be calculated from the start-wavefunctions


--------------------------------------------------------------------------------------------------------


Maximum index for augmentation-charges 199 (set IRDMAX)


--------------------------------------------------------------------------------------------------------


initial charge from wavefunction
FEWALD: cpu time 0.00: real time 0.00
RESPFUN: cpu time 0.00: real time 0.01


########### 5. Vasp.log file ###############
running on 20 nodes
distr: one band on 1 nodes, 20 groups
vasp.5.2.2 15Apr09 complex
POSCAR found type information on POSCAR Hf O
POSCAR found : 2 types and 12 ions
Error reading item 'HFSCREEN' from file INCAR.
LDA part: xc-table for Pade appr. of Perdew
found WAVECAR, reading the header
WAVECAR: different cutoff or change in lattice found
POSCAR, INCAR and KPOINTS ok, starting setup
WARNING: small aliasing (wrap around) errors must be expected
FFT: planning ...( 2 )
reading WAVECAR
the WAVECAR file was read sucessfully
initial charge from wavefunction
entering main loop
N E dE d eps ncg rms ort

Does the calculation automathically stop? or do you just observe nothing happening? In the later case your calculation could hang or just be running (check by logging in on one of the nodes you are running to see if your VASP is useing the resources (check also virt mem, if you run out things slow down immensly).

With regard to speed: do you really need 500 bands and 3000 gridpoints on your dos?
The number of electrons for a 12 atom system is not that high:
8x6=48e (for the O)
4x10=40e(for the Hf_pv, otherwise it's only 16)
--------------
total = 88e = 44 bands
+2x#atoms= 24
--------------------------
bands needed= 68
This means you can easily set NBANDS to 80, still having sufficient additional bands for what you need.

I guess you are not doing a DOS calculation so NEDOS does not need to be defined, the standard grid VASP uses is then sufficient (might even be sufficient if you are interested in the DOS, even so I would suggest using NEDOS in combination with the tags defining the upper and lower boundary of the DOS you are interested in)

Try with these lower settings and grep "kBytes" It should show you how much memory you need per core (now it says ~2Gb...but I'm not sure how correct this is for HSE)

Danny

I can definitely try reducing the size of NBANDS. However, I do plan on eventually running a 2x2x2 or even a 3x3x3 unit cell (96 and 324 atoms, respectively). So either way I'll need to optimize this to run with a high value of NBANDS anyway.

Similarly, I would like to also do DOS calculations once I get the band structure working. But I can definitely try using ENMIN and ENMAX to zoom in on the important parts.

So for now, I'll definitely try reducing NBANDS and eliminating NEDOS to see if it helps, but eventually I'll have to go back to the old numbers anyway.

As for the current calculation: It does automatically stop (it's not just running slowly). In the outputs I posted above, there were several warnings issued:
- Potential aliasing errors related to NGX, NGY, and NGZ (although it also indicates these are probably negligible)
- The vasp.log file also gives an aliasing warning (not sure if it is of the same origin as the warning in the OUTCAR file)
- There is also an error indicating that HFSCREEN could not be read. Since HFSCREEN is an important parameter for HSE06, I imagine that any error with this could cause problems, although I don't know how to fix it.

Finally, I believe I have 16 GB/node of memory, so that should give me 80 GB to work with. If the OUTCAR's value for memory usage is correct (2 GB), I should have more than enough, right?

I'll try redoing the simulations and see what comes up. Any additional advice, especially relating to that "Error reading HFSCREEN" error, would be greatly appreciated.

Thanks!

Your behavior is not reproduced. There is no message
"Error reading item 'HFSCREEN' from file INCAR. "
HSE calculation is running normally.

Ok, so my INCAR file was written properly then? Could this be some artifact of our cluster causing this problem?

Also, any idea why NPAR has been so problematic? The manual says NPAR can take on any value, and recommends NPAR = sqrt(Number of cores). However, I get errors for any value of NPAR not exactly equal to the number of cores.

Shouldnt the LWAVE=.TRUE. instead of false and false intsead of true ?