total charge density (valence + ion)
Posted: Sun Apr 08, 2012 8:07 pm
When I am doing charged defect calculations and relaxing the ions, I would like to look at the total charge density (smoothed out a bit - singularities at the nuclei would not be good).
The ultimate goal is to use the total charge density in a Madelung-energy calculation to correct for the Coulomb interaction between the defect and it's unphysical lattice of copies (there are two recent papers on this by Freysoldt et al., but they suggest only using the electronic defect state charge).
I have adopted the following procedure, and I am wondering whether there might be some pitfalls with it, or whether there is a another way to do this. (Regarding the latter, there are lines one can uncomment in main.F that say they allow the total charge density to be written to the CHGCAR file, by adding the quantity DENCOR to the usual CHTOT. But my preliminary tests indicate this is not giving the true total charge; at least it differs from the results of the procedure I describe below, and it manifestly has the wrong total charge (it still gives the number of valence electrons)).
Here's what I do now:
I read the LOCPOT (generated with LVHAR=.TRUE.). I then FFT it. I take the Laplacian of it by multiplying by the (shifted) magnitude squared of the G vectors, with appropriate scaling, while at the same time multiplying each plane wave by an optional factor that decreases with G^2, to obtain a low pass filter.
I take the inverse FFT, and multiply by some carefully calculated scaling factors to obtain the total charge distribution. If I want, I can add a uniform charge to give the resulting distribution a net charge (nice for visualization, probably not wanted for Madelung type correction calculations). I feel I have been fairly careful in implementing this conversion, and have looked in the VASP code to make sure I know how the files are ordered and where the origin is and so on.
In principle this should get me the correct total charge distribution. I have the following questions
(1) Does this procedure suffer from serious problems resulting from the coarseness of the LOCPOT in the vicinity of the ions?
(2) In the limited testing I have done, the resulting shape of the charge distribution is qualitatively different from the result obtained by the uncommenting of the lines in main.F. (It's not just the total charge that is the problem, there are differences in the shape near the ions (ok - I tested it only on a single F- ion). My question is, does this indicate a problem in my LOCPOTtoCHG code? That is, is uncommenting those three lines really supposed to give the true total charge density (albeit off by a constant that is the number of valence electrons)? What exactly is supposed to physically be in the CHGCAR when those lines are uncommented?
(3) I use LOCPOT from LVHAR=T. Let me know if this does *not* include the (smoothed) electrostatic potential from the core electrons and the nucleus as well as the electron charge density. My looking at the manual and the code lead me to believe that it does include these things through the complicated internal PAW implementation, but I could very well be wrong.
Thank you very much,
David
The ultimate goal is to use the total charge density in a Madelung-energy calculation to correct for the Coulomb interaction between the defect and it's unphysical lattice of copies (there are two recent papers on this by Freysoldt et al., but they suggest only using the electronic defect state charge).
I have adopted the following procedure, and I am wondering whether there might be some pitfalls with it, or whether there is a another way to do this. (Regarding the latter, there are lines one can uncomment in main.F that say they allow the total charge density to be written to the CHGCAR file, by adding the quantity DENCOR to the usual CHTOT. But my preliminary tests indicate this is not giving the true total charge; at least it differs from the results of the procedure I describe below, and it manifestly has the wrong total charge (it still gives the number of valence electrons)).
Here's what I do now:
I read the LOCPOT (generated with LVHAR=.TRUE.). I then FFT it. I take the Laplacian of it by multiplying by the (shifted) magnitude squared of the G vectors, with appropriate scaling, while at the same time multiplying each plane wave by an optional factor that decreases with G^2, to obtain a low pass filter.
I take the inverse FFT, and multiply by some carefully calculated scaling factors to obtain the total charge distribution. If I want, I can add a uniform charge to give the resulting distribution a net charge (nice for visualization, probably not wanted for Madelung type correction calculations). I feel I have been fairly careful in implementing this conversion, and have looked in the VASP code to make sure I know how the files are ordered and where the origin is and so on.
In principle this should get me the correct total charge distribution. I have the following questions
(1) Does this procedure suffer from serious problems resulting from the coarseness of the LOCPOT in the vicinity of the ions?
(2) In the limited testing I have done, the resulting shape of the charge distribution is qualitatively different from the result obtained by the uncommenting of the lines in main.F. (It's not just the total charge that is the problem, there are differences in the shape near the ions (ok - I tested it only on a single F- ion). My question is, does this indicate a problem in my LOCPOTtoCHG code? That is, is uncommenting those three lines really supposed to give the true total charge density (albeit off by a constant that is the number of valence electrons)? What exactly is supposed to physically be in the CHGCAR when those lines are uncommented?
(3) I use LOCPOT from LVHAR=T. Let me know if this does *not* include the (smoothed) electrostatic potential from the core electrons and the nucleus as well as the electron charge density. My looking at the manual and the code lead me to believe that it does include these things through the complicated internal PAW implementation, but I could very well be wrong.
Thank you very much,
David