Difference between revisions of "CamCASP/Programming/4"

From CUC3
Jump to navigation Jump to search
import>Am592
import>Am592
Line 36: Line 36:
   
 
== Using the EDIT block ==
 
== Using the EDIT block ==
  +
===UPDATE===
 
I made the following mistake while trying to rotate one of the molecules manually using the EDIT block. I first used:
 
I made the following mistake while trying to rotate one of the molecules manually using the EDIT block. I first used:
 
Edit water2
 
Edit water2
Line 48: Line 49:
   
 
Use only one UPDATE in the EDIT block!!!!!
 
Use only one UPDATE in the EDIT block!!!!!
  +
  +
===BUG: ROTATE-UPDATE MOS-DF===
  +
Version 5.4.00 of the code has a bug if the following sequence of commands is used:

Revision as of 11:04, 6 May 2009

CamCASP => Programming => Rotations

The theory of integral and MO rotations has been described in The DF INTEGRAL module . This is a collection of odds and ends related to rotations.

DALTON

MOs from DALTON don't seem to be rotationally invariant. Consider the following example:

water dimer. Sadlej/PBE0/AC MC basis type. Aux basis: JK-tzvpp. Geom: R=2.4 Ang in min-orientation.

I noticed a discrepancy in the e-e and e-n energies (parts of <math>E^{(1)}_{\rm elst}</math>) when calculated in the following ways:

  1. MOs calculated in reference geometry and rotated with molecule. DF is done after rotation of MOs. So no integrals needed rotation.
  2. Molecules rotated and MOs calculated in already rotated geometry.

These should be equivalent. And the MOs should be equivalent and related by a Wigner rotation matrix. This was not the case and I found small, but noticable differences that led to small differences in the e-n energies (there should also be differences in the e-e energies, but I still have to trace other errors here, so cannot be sure).

We should have had the following:

  1. Same e-n energies. But these were -4966220.470061 CM-1 and -4966223.294960 CM-1 for the two methods. The differences are small, but they should not be present. Also, they are small compared with the e-n energy (this was the electrons of the rotated water with the nuclei of the un-rotated partner) but there should be *no* difference! Also, the n-n energy was the same in both cases. So the geometries are identical to a very good precision.
  2. All MO coefficients of s-functions should be invariant. These were not. Here are some examples:

Rotated MOs:

           1           2           3           4           5           6
   1 -0.41889617  0.09392291 -0.00000000 -0.03428749 -0.00000000 -0.02592316
   2 -0.66185094  0.23411329 -0.00000000 -0.08566500 -0.00000000 -0.06621631
   3 -0.02169284 -0.49823673 -0.00000000  0.17957929  0.00000000  0.15914437
   4  0.01046006 -0.28963061  0.00000000  0.34404529  0.00000000  0.23181807
   5  0.01031500  0.20293750  0.00000000  0.25439726  0.00000000  0.23891097

MOs calculated in rotated geometry:

          1           2           3           4           5           6
   1 -0.41889616  0.09392286  0.00000000  0.03428733  0.00000029  0.02592417
   2 -0.66185093  0.23411301  0.00000000  0.08566477  0.00000058  0.06621905
   3 -0.02169291 -0.49823536 -0.00000000 -0.17958106  0.00000056 -0.15915432
   4  0.01046008 -0.28963335 -0.00000000 -0.34402498 -0.00001425 -0.23179758
   5  0.01031515  0.20291569 -0.00000000 -0.25431644 -0.00004597 -0.23890003

Columns are MOs and rows are coefficients of primitive AOs. All AOs are s-functions. So all should be the same. But they are not. Also look at MO 5. It should have no s-component. But it does in the second case. So the MOs calculated for the rotated molecule don't seem quite right.

Using the EDIT block

UPDATE

I made the following mistake while trying to rotate one of the molecules manually using the EDIT block. I first used:

 Edit water2
   Rotate by 133.12506 degrees about  -0.637207  0.637207 -0.433515
   Update
   Show
   Place on  XYZ   -3.96012396  -0.00000000  -2.21059917
   Update
   Show
 End

The idea was to see what was done at each step. But this is wrong as UPDATE first resets the molecule to the reference geometry. So The second UPDATE nullified the first ROTATE. So the moral is

Use only one UPDATE in the EDIT block!!!!!

BUG: ROTATE-UPDATE MOS-DF

Version 5.4.00 of the code has a bug if the following sequence of commands is used: