Density of states with k-points in CP2K

[Nicholas Winner]

Hi everyone, 

I know that DOS and points aren't what people first think of when using cp2k, but the functionality does seem to be there in some limited way... 

Anyway, I'm wondering how to properly use it, because my test case doesn't look right. I'm running a point calculation on GaAs with a 16x16x16 Monkhorst-Pack pack grid and then printing the total DOS. I then take the columns from the DOS file (head attached) and plot energy (column 1) against occupation (column 3) using the reported Fermi energy from the output file of ~0.14 Ha. This results in a DOS where the Fermi energy does not line up with the VBM. What's more, if I visually inspect this DOS, the band gap of GaAs is >1eV. While that is closer to the experimental value, the reported band gap using GGA PBE is closer to 0.3eV.  

Questions:

(1) What is the distinction between columns 2 and 3 in the DOS file? They give similar, but not equivalent looking dos plots.

(2) Is the Fermi energy printed in the output file the same as the Fermi energy of the DOS, or is it defined different?

I've attached my input file for reference. Thanks in advance.

 # DOS at iteration step i = 0

    Energy[a.u.]       Density     Occupation

    -0.40682067         0.0009         0.0957

    -0.40582067         0.0015         0.1543

    -0.40482067         0.0000         0.0000

    -0.40382067         0.0000         0.0000

    -0.40282067         0.0034         0.3516

    -0.40182067         0.0026         0.2656

    -0.40082067         0.0038         0.3828

    -0.39982067         0.0000         0.0000

[Sam Broderick]

Hi

It's not clear to me why you are looking at the first step. Did it converge in just one step?

At any rate, you'll notice a difference between &DOS and &PDOS. PDOS returns values per orbital (s, p, d, f). If I understand it correctly, the density is the DOS as a solid state physicist would understand it, and occupation gives you a fractional filling at that energy. Not quite the same thing.

Regards

Sam

[Nicholas Winner]

It is a static calculation, so iteration = 0. I redid the calculation with cell optimization. Didn't seem much of change. Here at the plots using the occupation first and the density second. I set fermi level to be 0, and it doesn't put it anywhere near the VBM like we expect. In the second case it looks like there is a gap, but its too big. 

Any knowledge maybe about the definition of fermi level? Maybe that's where I'm tripping up.

Do you know anything about the fermi level definition?

[Marcella Iannuzzi]

Hi, 

The Fermi energy is not well defined for electronic structures with an energy gap. 

Using the Fermi-Dirac distribution, CP2K sets the Fermi energy somewhere in the middle of the gap.

The histogram calculated by activating PRINT%DOS is just counting the number of eigenvalues falling into each histogram bit.

The partitioning of the histogram in bits is determined from the DELTA_E keyword, the default of this is 0.001.

The final value of the density (sum of states per bit) is then normalised by the number of NMO.  

The column occupation reports the sum of the occupation numbers of the eigenstates with energy falling into the corresponding bit.

For small DELTA_E, there are bits with zero density and zero occupation number. 

Setting DELTA_E to zero, the histogram is replaced by simply the list of eigenvalues. 

When using k-point sampling the procedure is more or less the same, but each contribution to the density as well as each contribution to the occupation are multiplied by the weight of the corresponding k-point. 

Regards

Marcella

[Nicholas Winner]

Thank you Marcella. I am clear about the Fermi level setting now. 

Any ideas as to why calculated gap is so large (first image)? The input file I have attached has pretty reasonable parameters I think:

• multigrain can accommodate all basis functions
• precision settings are above average 
• TZVP basis sets
• Tight MP k-point grid of 16x16x16
• EPS_SCF of 1e-6

Not sure what else could be causing such a large discrepancy without published PBE results. Is it still an issue of interpreting the DOS?

[Nicholas Winner]

Marcella, I looked further and played with delta_e and there is something that seems incorrect to me.

If I let delta_e -> 0 then the density column is equal to 0 everywhere. It looks like this might be due to precision? The column only lists 3 decimal places.

[Marcella Iannuzzi]

For any delta_e do you get all zeros?

And if delta_e = 0?

About the settings, they look fine to me. 

Why are you using a Fermi-Dirac smearing for GaAs, it is not a metal. 

Anyway, this should not change anything with respect to the energy gap.

Have you considered to run the same calculation with multiple cells instead of k-points?  

Regards

Marcella

[Matt Watkins]

FWIW I got a gamma point band gap of ~0.1 eV using 12x12x12 k-points and PBE using mainly default settings from ASE / seeK path.

I didn't compare to the DOS output.

[Nicholas Winner]

I do not get zeros for all delta_e, only when it is below a certain threshold. When I take the default delta_e, it gives an energy gap of ~1.5. When I increase delta_e to .01 the band gap shrinks to ~1. So there is some kind of a binning problem it seems.

I was using Fermi Dirac smearing simply to get CP2K to print out the fermi energy, which it won't do in k-point calculation without it. I could just read off the VBM from the list of eigenvalues, but I try to automate this.

I'm hoping to do this as a kpoint calculation so that I can get a good DOS. While the energy gap is possible with gamma point only, the DOS isn't really. Generally CP2K is used as a gamma-only code for large supercells, but I hope to use it as a slightly more general solver since I like the code and it seems to have most of the functionality needed.

--
You received this message because you are subscribed to the Google Groups "cp2k" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cp2k+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cp2k/b029f99c-f044-498e-a763-39f92341fec0n%40googlegroups.com.

[Matt Watkins]

Think there might be a bug fix for k-points and MPI processes in the works.

[Matt Watkins]

edit - for DOS with k-points and MPI