Nuclear charge needs to be added to the ab initio charge density of the tip (together with the charge of core electrons, unless an all-electron DFT code has been used).
Too wild spikes of charge density near the nucleus should better be avoided for the sake of numerical stability.
How to achieve this? Two solutions have been proposed and (to some extent at least) also implemented:
Using the --Rcore option
Using ddensity (delta-density, the self-consistent minus atomic non-self-consistent density) instead of the full self-consistent electron density for the tip
We should figure out which of these soulution works better (or perhaps propose yet another one?), both in terms of numerical stability and in terms of being substantiated by the physics of the problem.
Moreover, the solution may need to be different for VASP (pseudopotential code, the output density in CHGCAR exactly integrates to the total number of valence electrons) and for FHI-AIMS (all electron code, but the *_total_density.cube, as far as I know, does not have to integrate to the total number of electrons exactly, because of the finite grid that samples the density in the CUBE file).
How to achieve this? Two solutions have been proposed and (to some extent at least) also implemented:
--Rcoreoptionddensity(delta-density, the self-consistent minus atomic non-self-consistent density) instead of the full self-consistent electron density for the tipWe should figure out which of these soulution works better (or perhaps propose yet another one?), both in terms of numerical stability and in terms of being substantiated by the physics of the problem. Moreover, the solution may need to be different for VASP (pseudopotential code, the output density in
CHGCARexactly integrates to the total number of valence electrons) and for FHI-AIMS (all electron code, but the*_total_density.cube, as far as I know, does not have to integrate to the total number of electrons exactly, because of the finite grid that samples the density in the CUBE file).