An unusually large number is detected in PROCAR.

[GwanWoo_Kim]

Hello, I am Kim Gwan Woo, a VASP user.
We are continuing our research at Sejong University in Korea using an excellent tool VASP.

I have calculated quite a few structures, and aware that in PROCAR, tot is not always fixed to 1 or less.
But the tot value usually goes up to 1~2. I have attached the file, but I would like to specify the parts of
PROCAR that I believe are problematic.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
band 37 #energy -8.40904955 #occ. 1.00000000

ion s py pz px dxy dyz dz2 dxz x2-y2 tot
1 0.000 0.000 0.000 0.000 0.003 0.007 0.000 0.001 0.001 0.012
2 0.001 0.000 0.000 0.000 0.005 0.022 0.001 0.001 0.026 0.055
3 0.000 0.041 0.000 0.054 0.000 0.000 0.000 0.000 0.000 0.094
4 0.000 0.031 0.003 0.015 0.000 0.000 0.000 0.000 0.000 0.050
5 0.000 0.056 0.000 0.001 0.000 0.000 0.000 0.000 0.000 0.057
6 0.000 0.077 0.002 0.113 0.000 0.000 0.000 0.000 0.000 0.192
7 0.000 0.078 0.002 0.113 0.000 0.000 0.000 0.000 0.000 0.192
8 0.000 0.056 0.000 0.001 0.000 0.000 0.000 0.000 0.000 0.057
9 0.000 0.032 0.003 0.014 0.000 0.000 0.000 0.000 0.000 0.049
10 0.000 0.041 0.000 0.053 0.000 0.000 0.000 0.000 0.000 0.094
tot 0.001 0.410 0.011 0.363 0.008 0.029 0.001 0.002 0.027 0.852
...
band 49 #energy -1.56898845 #occ. 0.00000000

ion s py pz px dxy dyz dz2 dxz x2-y2 tot
1 0.004 0.000 0.000 0.000 0.000 0.001 0.018 0.018 0.001 0.042
2 11.608 0.000 0.000 0.000 0.007 0.002 0.000 0.000 0.000 11.618
3 0.000 0.001 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.001
4 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
5 0.000 0.000 0.003 0.001 0.000 0.000 0.000 0.000 0.004
6 0.000 0.002 0.000 0.001 0.000 0.000 0.000 0.000 0.003
7 0.000 0.002 0.000 0.001 0.000 0.000 0.000 0.000 0.000 0.003
8 0.000 0.000 0.003 0.001 0.000 0.000 0.000 0.000 0.000 0.004
9 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
10 0.000 0.001 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.001
tot 11.613 0.005 0.007 0.005 0.008 0.003 0.018 0.018 0.001 11.677

band 50 #energy 1.29528704 #occ. 0.00000000

ion s py pz px dxy dyz dz2 dxz x2-y2 tot
1 12.378 0.000 0.000 0.000 0.005 0.001 0.001 0.001 0.000 12.386
2 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
3 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
4 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
5 0.000 0.000 0.000 0.000 0.000 0.000 0.000
6 0.000 0.000 0.000 0.000 0.000 0.000 0.000
7 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
8 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
9 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
10 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
tot 12.378 0.000 0.001 0.000 0.005 0.001 0.001 0.001 0.000 12.388
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If we look at PROCAR, we see rates going up to 11, 12.
I'm reporting this because I think it's not just a problem for projection operators.

In the Ef+4.2, 7.5eV band, we found an abnormally large occupancy rate as above.
This was not a result of a specific K-POINT, but a result of almost the entire region.
The calculation result did not come out with PBE, PBE_sv,
and LDA also got the same result when calculated with _pv.
Of course, it is a conduction band, and it is an error in the high energy band from Fermi, but it is a very confusing result.

I don't think this is a problem with any parameters of INCAR (since changing POTCAR with same INCAR solves it).
What could be the problem?
I wonder if it is possible for the occupancy of one orbital to be more than 10.
Can you give me advice on this result?

[christopher_sheldon1]

Dear Kim Gwan Woo,

Thank you for bringing this to our attention. It is not generally possible for a value in PROCAR to be so large as you have found. I have repeated this using only the gamma-point and found the same difference. I will try to work out what is happening and bring it up at a meeting then get back to you.

Best wishes,

Chris

[christopher_sheldon1]

Dear Kim Gwan Woo,

This is an issue with ghost states appearing in your system when using the PBE_pv POTCAR. Cr2F8 is strongly ionic, and this can make these more likely to occur. Specifically, it has an s-character, hence the large s population for these bands. These s-like ghost states are introduced when going from the standard PBE POTCAR (3d54s1 in valence) for Cr and changing to the PBE_pv POTCAR to include p-electrons (3p63d54s1 in valence). They are fixed by including the 3s electrons explicitly with the PBE_sv POTCAR (3s63p63d54s1 in valence):

For the PBE POTCAR, where ++ is a physical state, -- is a ghost state, and the bands in italics are not other physical states. You can see that there are four physical states around where the unphysical ghost states later appear (you can see these as straight lines in a band structure plot).

41 -2.5432 0.00000
42 -1.9806 0.00000 ++
43 0.9938 0.00000 ++
44 1.9034 0.00000 ++
45 2.7177 0.00000 ++
46 4.2872 0.00000

There are two ghost states when using PBE_pv POTCAR (shown in bold):

47 -2.3005 0.00000
48 -1.7136 0.00000 ++
49 -1.5165 0.00000 --
50 1.1649 0.00000 ++
51 1.2461 0.00000 --
52 2.1376 0.00000 ++
53 2.8672 0.00000 ++
54 4.4365 0.00000

and these are not seen when using the PBE_sv POTCAR:

49 -2.1208 0.00000
50 -1.5268 0.00000 ++
51 1.3320 0.00000 ++
52 2.2770 0.00000 ++
53 2.9600 0.00000 ++
54 4.5405 0.00000

For your system, since it is highly ionic, the PBE_pv POTCAR should not be used. It is more appropriate to use the PBE_sv, or the base PBE, which do not encounter these problems. You can find more information about ghost states in Gonze, Stumpf, Scheffler, Phys. Rev. B 44, 8503.

Does this answer your question?

Best wishes,

Chris