[CPMD-list] Bizzare shapes of CUBEFILE ORBITALS

[Axel Kohlmeyer]

On Fri, 24 Jun 2005, Eung-Gun Kim wrote:

EK> Dear List Subscribers,


EK> I have observed some bizzare behavior when using "&PROP CUBEFILE
EK> ORBITALS."  It can be summarized as follows:
EK> 
EK>   1) Molecular orbitals, whether filled or unfilled, have unphysical shapes,
EK>      which include long, pointed spears.

that usually means, that the data was not sorted properly,
you are mixing two datasets or have a different grid when
generating and when plotting the data.

EK> 
EK>   2) Even when the orbital shape looks "physical," ghost orbitals appear in
EK>      empty space.  These ghosts look like replicas of the real ones. However,
EK>      they are not something CUBECENTER can fix.

again. can have the same reason, this time only the offset
is commensurate with the grid. 

EK>   3) No matter how strange the orbitals are, the electron density as seen in
EK>      the RHO_TOT.cube file looks just fine.  Energies (including the
EK>      electronic band structure) are also fine.
EK> 
EK>   4) Although my sampling may not be thorough, this happens when the orbitals
EK>      are extracted from a k-point calculation.  (The way I extract orbitals at
EK>      a particular k point is as follows: 1) perform optimization using
EK>      KPOINTS MONKHORST-PACK; 2) perform 1 cycle of LANCZOS DIAGO on the
EK>      optimized electron denstity using KPOINTS and the coordinates of
EK>      a k point of interest, 0 0 0 for the gamma point, for instance; and
EK>      3) perform a &PROP calculation.)

hmmm. at least for the density there is a comment, that the CUBEFILE
keyword was not tested at all for k-points. i'd assume, that the
same is true for orbitals. note, that for KPOINTS you have a complex
wavefunction, whereas for gamma point calculations it is real, and thus
needing only have the storage. that may explain your strange cube files.

EK>   4) It does *not* happen all the time.
EK> 
EK>   5) I tested it with both v3.9.1 and v3.9.2, and obtained the same result.
EK> 
EK> What I've seen so far suggests that the bug--if there exists one--may be in the
EK> cubefile-generating routine for ORBITALS.  Would there be a workaround?


you can try to use RHOOUT BANDS with the _negative_ numbers of the 
respective orbitals. from that you'll get a bunch of WAVEFUNCTION.*
files, for the states in question that you can convert to the 
respective cubefiles with cpmd2cube.

with the numerous improvements to cpmd2cube over the 
last years, i'd generally prefer using cpmd2cube. e.g.
for orbitals using the -trim flag can save an enourmous
amount of storage (on disk and in memory when visualizing 
them), provided the cube'd data is not very distributed.

best regards,
	axel.

EK> 
EK> Thanks very much for reading.
EK> 
EK> Regards,
EK> 
EK> EG Kim
EK> _______________________________________________
EK> CPMD-list mailing list
EK> CPMD-list at cpmd.org
EK> http://cpmd.org/mailman/listinfo/cpmd-list
EK> 
EK> 

-- 

=======================================================================
Dr. Axel Kohlmeyer   e-mail: axel.kohlmeyer at theochem.ruhr-uni-bochum.de
Lehrstuhl fuer Theoretische Chemie          Phone: ++49 (0)234/32-26673
Ruhr-Universitaet Bochum - NC 03/53         Fax:   ++49 (0)234/32-14045
D-44780 Bochum  http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.