Page 1 of 1

Meaning of "total charge" in outcar

Posted: Mon Feb 02, 2026 4:50 am
by KWH

I would like help understanding the “total Charge” reported in the OUTCAR file.

As an example of my issue, I am attaching in INCAR, POSCAR, POTCAR and OUTCAR files for a molecular calculation.
The POTCAR file shows 4 electrons for carbon (2s(2) 2p(2). The carbon atoms in the dimer should have nearly 4 electrons but the OUTCAR "total charge" is 2.622. In fact, if one sums all the total charges the result is far less than the total of valence electrons in the PAW_PBE POTCAR indicating a huge charge on a neutral molecule. What is the cause of this discrepancy? Alternately, how are the "total charges" to be interpreted?


Re: Meaning of "total charge" in outcar

Posted: Thu Feb 05, 2026 9:19 am
by andreas.singraber

Hello!

First, the number of valence electrons VASP considers is determined by the POTCAR files (look for the value of ZVAL). In your case, as you mentioned, there are 4 valence electrons for carbon:

Code: Select all

 POTCAR:    PAW_PBE C 08Apr2002
   VRHFIN =C: s2p2
   LEXCH  = PE
   EATOM  =   147.1560 eV,   10.8157 Ry

   TITEL  = PAW_PBE C 08Apr2002
   LULTRA =        F    use ultrasoft PP ?
   IUNSCR =        1    unscreen: 0-lin 1-nonlin 2-no
   RPACOR =    1.200    partial core radius
   POMASS =   12.011; ZVAL   =    4.000    mass and valenz
   RCORE  =    1.500    outmost cutoff radius
   RWIGS  =    1.630; RWIGS  =    0.863    wigner-seitz radius (au A)

However, in the OUTCAR file we find this section you are referring to:

Code: Select all

 total charge

# of ion       s       p       d       tot
------------------------------------------
    1        0.876   1.750   0.000   2.626
    2        0.878   1.744   0.000   2.622
    3        0.885   1.775   0.000   2.660
    4        0.887   1.779   0.000   2.666
    5        0.881   1.747   0.000   2.628
...

I agree that the term "total charge" may be a bit misleading here. Actually, the column "tot" gives you the integrated charge density over a sphere with radius RWIGS (also listed in the POTCAR file) around each ion. The preceding columns correspond to individual contributions from projecting onto spherical harmonics. The actual formula behind these numbers is given on our Wiki here. The default sphere radius will typically leave some space in the simulation box uncovered, hence you will probably always "miss" some charge density outside the spheres. Therefore, it is expected that the individual charges and their sum in this table are typically lower than the number of valence electrons considered. See also the discussion on the RWIGS Wiki page.

Hence, although these numbers do not add up to the total charge in your system, the molecule is not charged with the "missing" charge. The discrepancy is merely expressing that electrons cannot be located and the charge cannot be "assigned" to certain ions.

All the best,
Andreas Singraber


Re: Meaning of "total charge" in outcar

Posted: Fri Feb 06, 2026 9:15 pm
by KWH

Thank you Anders, I suspected this might be the case. May I ask a follow up question? Is the charge in the PARCHG file the total charge or is it a projected charge like the PDOS? That is, will the integral over all k and volume equal the total valence charge?


Re: Meaning of "total charge" in outcar

Posted: Mon Feb 16, 2026 3:18 pm
by andreas.singraber

Hello!

Sorry for the late reply, it took a while to consult my colleagues about this question. I was informed that, yes, if you would sum up all occupied bands and k-points and integrate over all grid points in the PARCHG file you should end up with the total valence charge in the system. Actually, not exactly, but up to a factor, because for technical reasons the values on the grid are stored in such way that you need to divide by the FFT grid and cell volume after integrating (see the Format section on the Wiki).

This is also consistent with the information on the Wiki for the special selection of NBMOD = -1:

  • NBMOD = -1: Use all occupied bands
    This mode writes the charge density of all occupied states to the CHGCAR file, and no PARCHG file is produced. In contrast to producing a CHGCAR file from the WAVECAR input without the partial charges methodology (e.g. by setting LPARD = .FALSE., ALGO = None, and NELM = 1), the augmentation occupancies is not included in the produced CHGCAR file for NBMOD = -1. However, the fine FFT grid's valence charge density is equivalent.

So, in the end, it's probably easiest to check the total charge directly via the CHGCAR file because the PARCHG file is really intended to "cut out" specific parts of the density.

All the best,
Andreas Singraber