Bug in electron density cube files from GAPW calculations
ondrej.... at gmail.com
Fri Mar 16 15:16:23 UTC 2012
I would like to come back to an issue that was previously brought up
by Eva Pluharova on Dec 13 2011. As is obvious from the below
description and the attached input, this is a bug. It concerns the
cube files containing electron densities obtained from GAPW
The cube files produced by the print key
CP2K_INPUT / FORCE_EVAL / DFT / PRINT / E_DENSITY_CUBE
with TOTAL_DENSITY on seem to be entirely wrong:
1) They have clear visual artifacts on the first three atoms. This is
indeed order dependent and moves to different atoms if you reorder
them in the input.
2) Even the densities close to other atoms are wrong. The values are
orders of magnitude too high and it does not seem the be a simple
rescaling, as Bader population analysis produces numbers whose ratios
do not match those obtained from the same analysis of a density from a
comparable calculation obtained from other programs or differently
from CP2K (see below).
I attach an input file that shows this problem. It runs in about 20
seconds on 4 cores and produces a ~50 MB cube file of the electronic
density that has the above issues. Without the TOTAL_DENSITY keyword,
the cube file is reasonable and I assume what I get is the soft part
of density. I do realize that including the core electrons will need a
finer grid, but with this grid the problem can be seen and the input
runs faster. Tests with higher cutoffs indicate that a reasonable
result can be obtained in principle, if this problem is fixed.
Specifically, I have printed out cube files of all the MOs and summed
their squares. I would like to get the same result from the
TOTAL_DENSITY keyword. As is obvious, going through MO cube files is
very impractical for systems of interesting size.
Thanks for any attention you give this issue,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1946 bytes
Desc: not available
More information about the CP2K-user