CamCASP/Programming/4

From CUC3
Jump to navigation Jump to search

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:

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

BEGIN DF
  Molecule water2
  Type OO
  Print Nothing
END

Begin E1elst
End

Here's why:

  1. Molecule is rotated and MOs rotated to be consistent with molecule. But molecule definition contains rotation (and translation, but this is inconsequential) information.
  2. DF is done correctly.
  3. <math>E^{(1)}_{\rm elst}</math> needs integrals like OOOO,AABB and NUCA,OOBB. These depend on primitive integrals in the auxiliary basis. Consider one of these: S___,_A_B: it is calculated and then rotated if considered necessary. Now, the molecule water2 still has rotation information defined in its rotation field. So the S___,_A_B integral is rotated.

But this is wrong!!! The MOs and molecular geometry were consistent before DF was done. So no subsequent integral needs to be rotated.

How do we get around this?

One way might be as follows:

  • IF the MOs and geometry are consistent, then allow the present molecule to be set as the reference. So the rotation/translation information is reset and the reference (called _orig fields are set to be the current values).
  • This will take care of the present problem.
  • A similar situation arises when molecule are defined using Molecule name. So an error could arise from here too.

I've added a REFERENCE command to the Edit <molecule> ... End block that allows the user to set the current, updated molecule as the reference. Both geometry and orbitals are automatically updated by the REFERENCE command.

This still leaves the last problem: this error can still arise if rotations are used in the Molecule block. --alston 14:21, 11 May 2009 (BST)