Possible bug reading .cube files

[Patrick Conlin]

The following pertains to VESTA 3.5.7

Gaussian cube files can use either Bohr radii or Angstroms for distance units.  Bohr is the default and most common usage.  VESTA correctly reads cube files written using Bohr, but does not seem to correctly interpret cube files written using Angstrom.

See the following reference for the cube file format:

http://paulbourke.net/dataformats/cube/

Lines [3,5] provide the number of voxels along each axis as well as the lattice vector.  The lattice vector is given as the length of the voxel edge in that direction, so to recover the actual length of the vector it is necessary to evaluate the product

n * dL = L

where n is the number of voxels, dL is the length of the voxel along the axis, and L is the actual vector length.  When reading files written in Bohr, VESTA correctly evaluates this product.  Using the example from the above link,

40 voxels *  0.283459 Bohr = 11.338 Bohr

VESTA uses Angstrom for display, so this value would be converted to 6.0 A. 

Atomic coordinates are given by the last section of the header.  These are always in Cartesian form.  For files in Bohr, VESTA correctly interprets and converts these coordinates to A, so the atoms and lattice are aligned as expected.

However, if the cube file is written in A, there are several issues.

First, VESTA does not evaluate the product n * dL.  Rather, it directly takes the elements dL to be the actual lattice vectors, resulting in an unreasonably small cell.  I do not think that this behavior is intended.

Second, the atomic coordinates are converted as though they are written in Bohr, resulting in a scaling issue.  No conversion factor is applied to the lattice vectors, which are interpreted to be in A from the negative unit flag.

Thank you for your continued development of VESTA,

Patrick