Closed ximik69 closed 6 years ago
Hi Igor,
The CoreDensity output corresponds to the partial core density used for nonlinear core correction in the exchange-correlation interaction within the pseudopotential. Both the Li and Zn GBRV pseudopotentials do not have a partial core correction, and hence JDFTx has no core density to output.
However, this Zn pseudopotential includes semicore electrons as valence i.e. it has 20 electrons counted as valence, while Li has all three electrons counted as valence. Consequently, you will not hav emuch of a core hole in this that would necessitate adding more core electrons for Bader.
By the way, are you using the createVASP script to convert to CHGCAR for the BADER program? Just checking, because that is not yet advertised in the tutorials etc. as far as I can remember.
Best, Shankar
Hi dear Shankar, thank you for the explanations.
As soon as I saw the possibility for calculating atomic charges on jftx.org, I tried to export electron density to CHGCAR using createVASP script and further calculated charges with "bader". I used this sentence from feature list as a manual:) I succeeded, and charges were quite reasonable. But I did these for draft calculations with default fftbox, which was 1 point each 0.125Angstr. . I have heard that recommended point density for charges is 1 point each 0.05 Bohr which is about 0.025 Angstr.
I have also read in manual of bader, that using total density is better for more accurate charges. That's why I asked you. I wasn't sure how much difference could be due to "core hole". I think that biggest source of errors could be different zero flux surfaces and thus different partitioning and final charges. Now i understood,that it could be small enough.
Could I ask, when and where is electron density used in jdftx? Because while trying to increase each dimension of fftbox several times, I drastically increased memory consumption and almost hanged up my notebook due to swapping.
With best wishes, Igor.
Since it is electronic DFT after all, it is used almost everywhere in the code: to calculate exchange-correlation and Hartree energy and potentials, and in the solvation models. For a given plane-wave cutoff, you usually don't gain additional accuracy by making the fftbox finer, so there is no reason to ramp that up for the whole calculation.
So you have two options: 1. do the calculation at a normal fftbox, dump state, load state in a dump-only calculation with high fftbox and dump ElecDensity. 2. Use an external script in python / octave to fourier interpolate the density to a finer grid. (These will be completely equivalent.)
Shankar
Dear Shankar, thank you for the explanations. I'd like to write some draft tutorial about charges. I tested on weekend calculation for CsCl (cubic space group Pm-3m, a=4.126 Angstr) with 16x16x16 k-points and default fftbox 32 32 32, then I increased fftbox to 165 165 165 in order to obtain linear density 1 point each 0.025 Angstr and dumped ElecDensity and CoreDensity. Also I tested coarser grid 1 point each 0.05 Angstr having 8 times less points in fftbox, as well as finer grid 208 208 208 with double number of points, in comparison to reference fftbox 165 165 165.
calculation with fftbox 165 165 165 took 40 minutes, with fftbox 82 82 82 - 6 minutes,
with fftbox 208 208 208 - have not completed after ~7 hours, only one thread of two was working, which is quite strange.
I did Bader analysis only on ElecDensity.
Cs+ and Cl- charges were about +0.82 and -0.82 respectively.
Charge difference between Cs with fftbox 165 165 165 and fftbox 82 82 82 was about 0.006 electron.
As a conclusion I can say that if you want to use JDFTx calculations with default grid, then increase fftbox, load previous results and dump-only ElecDensity and CoreDensity with finer grid, then grid density 1 point each 0.05-0.025 Angstr is close to optimal. I shall also test intermediate values.
Increasing fftbox together with dump-only and cache-projectors no options does not increase memory consumption enormously.
Using finer grid increases computation time enormously. The working time for bader analysis is much lower than new ElecDensity, CoreDensity and energy calculation by JDFTx and could be neglected.
As for me it looks like doing fourier interpolation should be much faster.
What could be interesting to test is bader analysis for total electron density, maybe increasing Ecutoff for calculations.
Best wishes, Igor.
Yes, Fourier interpolation is definitely the way to go. I have added an option to do that directly in the createVASP script in the latest commit on git.
Shankar
Dear Shankar, thanks for so fast code update.
With best wishes, Igor.
Dear Shankar I have uploaded draft of tutorial, I will update it ASAP after further testing.
With best wishes, Igor.
Hello dear Shankar,
how could I obtain CoreDensity and then total electron density from JDFTX? I'd like to calculate atomic charges using "bader" program. The problem is, that if I specify CoreDensity in dump commands, JDFTx does not export this vaues, only ElecDensity and rhoAtom. I am using v. 1.4.0.
I want to try to obtain total density (maybe add CoreDensity and ElecDensity), as this is more accurate data source for bader program. Preliminary calculations from low-res ElecDensity and knowing number of core electrons look quite reasonable Li- atoms have no core density, but Zn have 10 electrons.
My input file is given below.
With best wishes, Igor.
ion-species /src/jdftx-1.4.0/build/pseudopotentials/GBRV/li_pbe_v1.uspp ion-species /src/jdftx-1.4.0/build/pseudopotentials/GBRV/zn_pbe_v1.uspp
U-J for Zn d10 orb 5eV [Ha]
add-U Zn d 0.183745167502
cache-projectors no coords-type lattice
include X.ionpos include X.lattice
for 10*300K
elec-smearing Fermi 0.0095
elec-n-bands 722 converge-empty-states yes
kpoint-folding 1 1 1 # kpoint 0 0 0 1 # gamma-centered k-point mesh
fftbox 320 480 600
dump-only
electronic-minimize \ nIterations 200 \ energyDiffThreshold 1e-8
elec-ex-corr gga-pbe
van-der-waals
density-of-states Total Occupied Total
dump electronic state forces dos dump End DOS CoreDensity ElecDensity State EigStats
All
wavefunction read ../X.wfns 656
initial-state X.$var dump-name X.$var