Dear Developers and users of the bader analysis tool
I dowload the source code and the exec (linux PGF) files some days ago with the motivation to use Bader charge density analysis for CuTe systems with electron density obtained with VASP.
As a first test, I calculated NaCl using the CHGCAR provided in the example, as well as a CHGCAR generated by myself with VASP, using
the INCAR file provide in the example or a modified INCAR file. I did not find any difference in the results for NaCl.
Then, I try to calculate my system, CuTe, in which I found some problems. I obtain exactly the valence chaarge for Cu and Te, i.e., 11 for Cu and 6 for Te or 17 for Cu (taking into account semicore states). However, I was expecting some thing like 8 for Te and 9 or 15 for Cu, or
something in between but not exactly the valence charge values.
I performed several tests, e.g., increase the number of FFT mesh points in the INCAR file. I did not see any change in the results.
Then, I recompile VASP following the suggestion provided in
http://theory.cm.utexas.edu/bader/vasp.php
After recompilation of VASP, I have the following problems:
I can not reprodude the same results for NaCl. Furthermore, the total
charge calculated in the bader program is not exactly the same as
the total valence charge.
CuTe: The total charge obtained by bader is not exactly the total valence charge. There is a difference of 0.50 electron. Hence, I do not believe on my results too much.
I am using the basic command
prompt: Bader
then the code ask for the charge density files. I provide the name and I choose option number 4, i.e., does not calculate any bader volume.
Any comment are welcome.
Bye
Juarez L. F. Da Silva
National Renewable Energy Laboratory
Golden, Colorado, USA
bader analysis for CuTe using VASP
Moderator: moderators
Any comment can be send direct to my e-mail too:
juarez_dasilva@nrel.gov
juarez_dasilva@nrel.gov
The first thing that I would suggest is to download the latest code (v0.21 11/08/06). I don't expect that you will get significantly different results, but it does fix a small bias in the older code.
With so many valance electrons in Te and the Cu_pv potentials, I wouldn't expect problems with the core charges - but it is good to check. It's encouraging that you get the same results with Cu and with Cu_pv.
It sounds like the vasp code modification does not add a significant amount of partial core charge. You should, however, get the same bader charge on each species. In order to calculate this net charge, you need to generate a CHGCAR for a single atom of Cu and of Te (and Cu_pv if you are using that potential). This will give you the valance charge (the number of electrons) associated with each atom. This could be larger than what is reported in the POTCAR, if any partial charge is added. Then, when you do a Bader analysis of the CuTe system, you know the reference valance for each atom, so you can find the overall charge.
I would be very surprised to see a charge transfer of 2e between Cu and Te. You don't even get a full 2e between species with very different electronegativities, such as Mg and O (you get 1.7e). Since Cu and Te have similar electronegativies, I would expect only a small charge transfer from Cu to Te.
With so many valance electrons in Te and the Cu_pv potentials, I wouldn't expect problems with the core charges - but it is good to check. It's encouraging that you get the same results with Cu and with Cu_pv.
It sounds like the vasp code modification does not add a significant amount of partial core charge. You should, however, get the same bader charge on each species. In order to calculate this net charge, you need to generate a CHGCAR for a single atom of Cu and of Te (and Cu_pv if you are using that potential). This will give you the valance charge (the number of electrons) associated with each atom. This could be larger than what is reported in the POTCAR, if any partial charge is added. Then, when you do a Bader analysis of the CuTe system, you know the reference valance for each atom, so you can find the overall charge.
I would be very surprised to see a charge transfer of 2e between Cu and Te. You don't even get a full 2e between species with very different electronegativities, such as Mg and O (you get 1.7e). Since Cu and Te have similar electronegativies, I would expect only a small charge transfer from Cu to Te.
Dear Graeme
Thanks for the comments:
(1) I up date for the new version of the code.
(2) I performed test calculations for several systems in order to understand how does the code works and what can I learn from Bader analysis (all calculations using the standard CHGCAR file, no partial core added).
-- I could reproduce your results for NaCl
-- I could reproduce your results for MH3 system; There is small difference, which I believe that I can remove by increasing the NGF mesh, i.e., 2xNGF_standard. Now, only 1xNGF_standard.
-- I could reproduce your results for NO2 system.
-- I found small problems for Si bulk; I did a test using Si bulk (2 atoms cell) and I could not obtain exactly the number of valence electrons.
There is a very small difference between the two Si atoms, e.g., 0.0547 electrons. I increase the FFT mesh for 3xNGF_standard and this difference decrase to 0.0226. Not happy with that, used a simple cubic cell with 8 atoms, then I could obtain the exact valence charge for Si, i.e., 4.0 and all atoms are equilivalent. Even the code works for non-orthogonal cells, it seems for me that the convergence of the results are better using a orthogonal cell like.
-- My results for CuTe did not change, eg.., Cu 0.0336 and Te -0.0336; high FFT meshes were used and no difference; However, looking your suggestion concerning the electronegativity, these numbers make sence.
I calculated also CdTe and I obtained 0.4273 for Cd and -0.4273 for Te. The difference in electronegativity is larger for this system, hence, I could see a larger charge transfer.
-- The only big problem was found for SiC. For this system, I obtained 0.000 valence charge for C and 8 for Si, which is wrong. I did a test using a hard C PAW potential, howvever, no change in the result. However, the total charge is conserved.
(3) The total electronic charge of the system is not written in any file, from what I could see. It is written in the end of the calculation. For calculations submited in the queue system, this information migh lost.
I would like to say thanks for your effort in providing this code for free to be used in the VASP community.
bye
Juarez
Thanks for the comments:
(1) I up date for the new version of the code.
(2) I performed test calculations for several systems in order to understand how does the code works and what can I learn from Bader analysis (all calculations using the standard CHGCAR file, no partial core added).
-- I could reproduce your results for NaCl
-- I could reproduce your results for MH3 system; There is small difference, which I believe that I can remove by increasing the NGF mesh, i.e., 2xNGF_standard. Now, only 1xNGF_standard.
-- I could reproduce your results for NO2 system.
-- I found small problems for Si bulk; I did a test using Si bulk (2 atoms cell) and I could not obtain exactly the number of valence electrons.
There is a very small difference between the two Si atoms, e.g., 0.0547 electrons. I increase the FFT mesh for 3xNGF_standard and this difference decrase to 0.0226. Not happy with that, used a simple cubic cell with 8 atoms, then I could obtain the exact valence charge for Si, i.e., 4.0 and all atoms are equilivalent. Even the code works for non-orthogonal cells, it seems for me that the convergence of the results are better using a orthogonal cell like.
-- My results for CuTe did not change, eg.., Cu 0.0336 and Te -0.0336; high FFT meshes were used and no difference; However, looking your suggestion concerning the electronegativity, these numbers make sence.
I calculated also CdTe and I obtained 0.4273 for Cd and -0.4273 for Te. The difference in electronegativity is larger for this system, hence, I could see a larger charge transfer.
-- The only big problem was found for SiC. For this system, I obtained 0.000 valence charge for C and 8 for Si, which is wrong. I did a test using a hard C PAW potential, howvever, no change in the result. However, the total charge is conserved.
(3) The total electronic charge of the system is not written in any file, from what I could see. It is written in the end of the calculation. For calculations submited in the queue system, this information migh lost.
I would like to say thanks for your effort in providing this code for free to be used in the VASP community.
bye
Juarez
Thanks for the detailed report. It's good to hear that the new code is working (for the most part).
The small error in the Si numbers is a bit disconcerting. I don't understand why that should be.
Printing the total charge in a file is a good idea. We'll add that.
The Si-C problem is (unfortunately) not surprising. These elements are in the middle of the periodic table, and all valence electrons participate in bonding. If there were more valence electrons, the core would be reproduced, and if there were fewer, there would be a _pv or _sv version of the potentials with core electrons treated explicitly.
The vasp folk have kindly given us some code which should enable us to extract the core charge from the paw potentials. We are currently trying to understand how this works, but I'm hopeful that we will get something working that will eliminate these annoying core charge issues.
The small error in the Si numbers is a bit disconcerting. I don't understand why that should be.
Printing the total charge in a file is a good idea. We'll add that.
The Si-C problem is (unfortunately) not surprising. These elements are in the middle of the periodic table, and all valence electrons participate in bonding. If there were more valence electrons, the core would be reproduced, and if there were fewer, there would be a _pv or _sv version of the potentials with core electrons treated explicitly.
The vasp folk have kindly given us some code which should enable us to extract the core charge from the paw potentials. We are currently trying to understand how this works, but I'm hopeful that we will get something working that will eliminate these annoying core charge issues.