Dear all,
I am applying the code bader to a simple model system, two Zr atoms in a cubic box with a side of 4 A.
To compute the electron density, a Zr pseudpotential is used with 12 valence electrons: two 4s, six 4p, two 4d, and two 5s.
The electron density is written to a Gaussian .cube file whose starting point is (0,0,0).
For the first test, the two Zr atoms are given fractional coordinates of (0,0,0) and (0.5,0.5,0.5).
As expected, bader produces the following output in ACF:
1 0.0000 0.0000 0.0000 11.9945 3.1678 224.5750
2 3.7795 3.7795 3.7795 12.0057 3.1640 218.2087
That is, both Zr atoms are assigned 12 electrons.
For the second test, the two Zr atoms are given fractional coordinates of (0.25,0.25,0.25) and (0.75,0.75,0.75).
The following is produced in ACF:
1 1.8897 1.8897 1.8897 11.9302 2.7616 215.6611
2 5.6692 5.6692 5.6692 12.0700 2.6725 227.1226
That is, only 11.93 electrons are assigned to one of the Zr atoms, while the other one receives 12.07 electrons.
This error does not rapidly reduce if the grid resolution is increased.
In the .cube files, a zero is assigned to the grid points at x=L, y=L, or z=L that are periodically repeated.
Might this error arise from the fact that the zeroed points are not distributed in a more uniform fashion along the sides of the box?
If so, would you be able to recommend a program that reformats the .cube file in order to eliminate this error?
Sincerely,
Yves
Bader charges of two Zr atoms
Moderator: moderators
Re: Bader charges of two Zr atoms
Dear all,
The problem described in "Bader charges of two Zr atoms" appears to be that the .cube file was not formatted correctly.
Correct results can be obtained if the periodically repeated entries at the edges of the box are deleted from the .cube file and not simply set equal to zero.* To quote an earlier posting on Mar 1, 2007:
"Orignally, we set up our CUBE reader using the Gaussian definition in which the first and last grid points are at the box edges.
Thus, the CUBE format had one more grid point for a given box size and grid spacing than a vasp CHGCAR file does.
Currently, however, the code is set up to read cube files in the same way that vasp chgcar files are read - so that the spacing
between grid points times the number of grid points is the cell length... So it does make sense to remove the duplicated last
entries in each dimension."
Once the .cube file is reformatted, bader produces the following ACF.dat entries for two Zr atoms with fractional coordinates of
(0,0,0) and (0.5,0.5,0.5):
1 1.8897 1.8897 1.8897 12.0001 3.1640 215.9480
2 5.6692 5.6692 5.6692 12.0001 3.1640 215.9480
The same output is obtained for two Zr atoms with fractional coordinates of (0.25,0.25,0.25) and (0.75,0.75,0.75):
1 0.0000 0.0000 0.0000 12.0001 3.1640 215.9480
2 3.7795 3.7795 3.7795 12.0001 3.1640 215.9480
That is, both Zr atoms are assigned 12 electrons regardless of their position in the simulation cell.
Note that a Zr pseudpotential was used with 12 valence electrons: two 4s, six 4p, two 4d, and two 5s.
Yves
* For .cube files that have Na, Nb, and Nc points in a-, b-, and c-directions and are periodic such that the grid value at
(1,1,1) is equal to that at (Nx,1,1) is equal to that at (Nx,Ny,1) etc., the number of grid points specified in the header must
be changed from Na, Nb, and Nc to Na-1, Nb-1, and Nc-1, and the number of grid points in the file must be reduced from (Na)(Nb)(Nc)
to (Na-1)(Nb-1)(Nc-1).
The problem described in "Bader charges of two Zr atoms" appears to be that the .cube file was not formatted correctly.
Correct results can be obtained if the periodically repeated entries at the edges of the box are deleted from the .cube file and not simply set equal to zero.* To quote an earlier posting on Mar 1, 2007:
"Orignally, we set up our CUBE reader using the Gaussian definition in which the first and last grid points are at the box edges.
Thus, the CUBE format had one more grid point for a given box size and grid spacing than a vasp CHGCAR file does.
Currently, however, the code is set up to read cube files in the same way that vasp chgcar files are read - so that the spacing
between grid points times the number of grid points is the cell length... So it does make sense to remove the duplicated last
entries in each dimension."
Once the .cube file is reformatted, bader produces the following ACF.dat entries for two Zr atoms with fractional coordinates of
(0,0,0) and (0.5,0.5,0.5):
1 1.8897 1.8897 1.8897 12.0001 3.1640 215.9480
2 5.6692 5.6692 5.6692 12.0001 3.1640 215.9480
The same output is obtained for two Zr atoms with fractional coordinates of (0.25,0.25,0.25) and (0.75,0.75,0.75):
1 0.0000 0.0000 0.0000 12.0001 3.1640 215.9480
2 3.7795 3.7795 3.7795 12.0001 3.1640 215.9480
That is, both Zr atoms are assigned 12 electrons regardless of their position in the simulation cell.
Note that a Zr pseudpotential was used with 12 valence electrons: two 4s, six 4p, two 4d, and two 5s.
Yves
* For .cube files that have Na, Nb, and Nc points in a-, b-, and c-directions and are periodic such that the grid value at
(1,1,1) is equal to that at (Nx,1,1) is equal to that at (Nx,Ny,1) etc., the number of grid points specified in the header must
be changed from Na, Nb, and Nc to Na-1, Nb-1, and Nc-1, and the number of grid points in the file must be reduced from (Na)(Nb)(Nc)
to (Na-1)(Nb-1)(Nc-1).
Re: Bader charges of two Zr atoms
Yves, thanks for the post. This is very good to know.
It seems to us that the cube file format is not entirely well-defined. They are written by several codes, and the precise formatting is not the same. We have seen this issue of periodic vs non-periodic file types (with or without the repeated edge line), but there are also differences in how many columns there are in lines for which a row of data ends. I am still not sure where the grid point lie for the periodic cube files; at the corner of the cell or in the middle. It would be very helpful to the community of people using charge density files to either write down or define a cube-file standard that we could conform to.
It seems to us that the cube file format is not entirely well-defined. They are written by several codes, and the precise formatting is not the same. We have seen this issue of periodic vs non-periodic file types (with or without the repeated edge line), but there are also differences in how many columns there are in lines for which a row of data ends. I am still not sure where the grid point lie for the periodic cube files; at the corner of the cell or in the middle. It would be very helpful to the community of people using charge density files to either write down or define a cube-file standard that we could conform to.