Proper cuts off (spin) density (in cube files)

[Krzmbrzl]

I believe that I have found a bug in TurboMole's proper module/program, but I couldn't find a bug tracker, so I am reporting this here.

I have performed a RI-DFT single-point calculation (enabling MARIJ, in case that is relevant). After this calculation has finished, I used the proper command line tool to export the spin density on a grid. For that I started proper, entered the "grid" submenu, changed the "format" to "cub" and then used "dens" to let the program export the electron and spin density on a grid into a cube file.
However, when I then try to plot the spin-density (using either VMD or JMol), I find that the spin density is only exported for about half of my molecule.
Visualizing the cube file in VMD while also plotting the box within which data points exist in the cube file, yields what I have attached to my post. As can be seen, the data box is misaligned relative to the molecule such that most points that were sampled aren't actually of interest and half of my molecule is not contained in the box (and therefore has no data points) as a consequence of this misalignment.

Re-inspecting the output of proper however would suggest that things should work just fine. The molecular geometry that it displays reads

Code: [Select]

              +--------------------------------------------------+
              | Atomic coordinate, charge and isotop information |
              +--------------------------------------------------+

                    atomic coordinates            atom    charge  isotop
          2.90894162   -0.11444406   -0.59222120    c      6.000     0
          1.71438767   -2.46414161   -0.48660457    n      7.000     0
          1.25618375    1.93835405   -0.64621419    n      7.000     0
          5.16253771    0.12971184   -0.56595414    o      8.000     0
          3.16145668   -4.72183170   -0.28818730    c      6.000     0
         -0.77891905   -2.72431791   -0.10507802    n      7.000     0
          2.19055686    4.36614122    0.06343996    c      6.000     0
         -1.29115975    1.64109605   -0.85023552    n      7.000     0
          2.37068374   -6.57343311    1.39525318    c      6.000     0
          5.28275658   -5.09416900   -1.78810024    c      6.000     0
         -2.15436346   -0.70601485   -0.34912284    c      6.000     0
          1.01003152    5.61720770    2.03968494    c      6.000     0
          4.23226359    5.42193197   -1.18881980    c      6.000     0
          0.71068099   -6.24733390    2.54235493    h      1.000     0
          3.71677192   -8.80781359    1.58012658    c      6.000     0
          6.61347088   -7.33739016   -1.58013691    c      6.000     0
          5.88821220   -3.64686487   -3.09372009    h      1.000     0
         -4.89634347   -0.91134061   -0.08781242    c      6.000     0
         -0.59169394    4.76386365    2.98390085    h      1.000     0
          1.86999415    7.98099441    2.74882152    c      6.000     0
          5.08569312    7.77769051   -0.44991143    c      6.000     0
          5.10566159    4.42791334   -2.74249510    h      1.000     0
          3.10457001  -10.24590244    2.90291209    h      1.000     0
          5.84283849   -9.19722821    0.09807200    c      6.000     0
          8.26692397   -7.63034308   -2.75118955    h      1.000     0
         -6.16792696    1.23666245   -0.56382097    n      7.000     0
         -6.10786827   -3.11279744    0.63371595    c      6.000     0
          0.93967664    8.97995421    4.27374818    h      1.000     0
          3.90489497    9.06508575    1.50571608    c      6.000     0
          6.66452526    8.62904451   -1.43599403    h      1.000     0
          6.89736639  -10.94542833    0.25069513    h      1.000     0
         -8.67724751    1.27268804   -0.30321395    c      6.000     0
         -4.99099787   -4.79314998    0.95856320    h      1.000     0
         -8.70581249   -3.07848796    0.90701709    c      6.000     0
          4.56859484   10.92248625    2.05512564    h      1.000     0
         -9.57313371    3.05689816   -0.75498730    h      1.000     0
        -10.00182994   -0.84973638    0.44054951    c      6.000     0
         -9.70784250   -4.77089188    1.47373544    h      1.000     0
        -12.03475134   -0.73933300    0.63211694    h      1.000     0
         -3.98961953    4.07921260   -1.94968922    pt    78.000     0
         -1.42648978    6.96182723   -3.83357192    cl    17.000     0
         -7.37367559    6.44363012   -3.07846852    cl    17.000     0
 
       center of nuclear mass  :   -1.65616936    1.93736147   -1.02091547
       center of nuclear charge:   -1.43192843    1.70404895   -0.90695322

and inside the "grid" settings, it displays

Code: [Select]

current settings:
 ------------------------------------------------------------------------------
 calculation at a grid of  142*  149*   81 points
 
 origin at            0.00000        0.00000        0.00000
 
 normalised grid vectors:
                        x              y              z
  1. vector:         1.00000        0.00000        0.00000
  2. vector:         0.00000        1.00000        0.00000
  3. vector:         0.00000        0.00000        1.00000
 
                     minimum       increment       maximum
  1. vector:       -16.03475        0.20072       12.26692
  2. vector:       -14.94543        0.20181       14.92249
  3. vector:        -7.83357        0.20134        8.27375
 
 ------------------------------------------------------------------------------

if one cross-references this with the displayed molecular geometry, things seem to match as all x-coordinates of my atoms lie in the range [-16, 12], all y-coordinates within [-14, 14] and all z-coordinates within [-7, 8]. So based on what is displayed there, all should match up.
And yet in the output, we can see that somehow the coordinates have been mixed up as there clearly the x-direction covers the smallest range of values, while in proper's output that was the z-direction.

My guess here would be that somewhere within (the grid module of) proper there are different conventions about how to label/order the coordinates and that causes the output to be wrong, even though the input seems fine.

[Krzmbrzl]

Another observation: When I use e.g. "rotate 90 2" inside the "grid" settings, I get a result in which the coordinates between the sampled density and the molecular coordinates seem to be completely decoupled: The molecule is now 100% outside of the data box but still the box contains non-zero density that looks like it only has to be translated in space in order to overlay the actual molecule. That is, I can observe the molecule's structure within the density even though the actual molecule is located at a completely different position in space.

(This observation was made with the total electron density rather than the spin density - I assume that the result for the spin density is the same)

[Krzmbrzl]

Btw: all of this is observed with TurboMole 7.7, but I already had issues with the cube export using TurboMole 7.4.1

[uwe]

Hi,
three are different conventions for cub files, and the format can contain a line that defines how the data is ordered (inner, middle, outer loop: x,y,z or x,z,y). Depending on which software you use to generate and/or visualize the cub files, you might get different results.

For VMD I usually do not ask Turbomole's proper to write the cub file format but use the default plt instead. Then I run the converter plt2cub from here: https://www.turbomole.org/turbomole/utilities/ which always worked for me.