CamCASP/Programming/0

CamCASP => Programming => Status

ENERGY-SCAN

What's working:

• REDO_DF_ON_ROTATION = .TRUE.
  • E1elst, E1exch, E2ind(UC),E2exind(UC),E2exdisp(UC),E2disp(UC)
• REDO_DF_ON_ROTATION = .FALSE.
  • ???

What's not working and why:

• REDO_DF_ON_ROTATION = .TRUE.
  • E2ind & E2disp: The DF-FDDS is created correctly for the first dimer configuration, but as it is not updated, it is incorrect for all subsequent configurations.
  • E2exind & E2exdisp: Since these are obtained by scaling E2exind(UC) & E2exdisp(UC) using E2ind & E2disp (and their UC counterparts), these are wrong too.

Cartesian versus Spherical auxiliary basis sets

What are the errors introduced when we use spherical GTOs in the auxiliary basis?

Water dimer

Sadlej/MC PBE0/AC

Work dir: /home/am592/DistProp/systems/water/scans/sadlej_mc

Units: kJ/mol

Water geometry:

MOLECULE water1
  Units Bohr
  ! Vibrationally averaged geom.
  O1          8.0    0.00000000     0.00000000     0.00000000
  H1          1.0   -1.45365196     0.00000000    -1.12168732
  H2          1.0    1.45365196     0.00000000    -1.12168732
END

Dimer geometries used:

     Rx      Ry      Rz      alpha   Nx      Ny      Nz       
    1   7.5489   0.0000   0.0000 180.0000   1.0000   0.0000   0.0000 <--water2 unchanged
    2   6.5478   0.0000   0.0000 180.0000   1.0000   0.0000   0.0000 <--water2 unchanged
    3  -4.8676   0.0000   2.8103 180.0000  -0.7071   0.0000  -0.7071

Since the rotation stays the same for the first two, the Cartesian scan which uses REDO_DF_ON_ROTATION=.TRUE. should get all energies correct for these two geometries. But not for the third. Let's see.

Reference energies are calculated using single point calculations (no energy-scan) with Cartesian GTOs in the aux basis.

Energies -----------Geom 1---------------    ------------Geom2-------------  --------------Geom3------------
         reference         JK-tzvpp          reference          JK-tzvpp      reference          JK-tzvpp
         JK     aTZ     Spherical Cartesian  JK     aTZ    Spherical Cart     JK     aTZ    Spherical  Cart
------------------------------------------------------------------------------------------------------------
REDO-DF                    F         T                      F         T                        F        T
------------------------------------------------------------------------------------------------------------
E1elst   -3.736 -3.610  -3.527    -3.736   -6.897  -6.574  -6.718    -6.897  8.037  8.250  8.087  8.037
E1exch    0.137  0.135   0.129     0.137    1.718   1.722   1.624     1.718  5.369  5.412  1.008  5.368
E2ind    -0.181 -0.203 -37.08     -0.181   -0.556  -0.664 -97.861    -0.556 -0.727 -0.856 -6494. -11.62 
E2exind   0.001  0.002   0.101     0.001    0.026   0.051   3.616     0.026  0.022  0.193  263.1  1.300
E2disp   -0.919 -0.985  -1.263    -0.919   -2.351  -2.490  -3.384    -2.351 -3.334 -3.551 -8.835 -62.95
E2exdisp  0.007  0.011   0.003     0.007    0.054   0.072   0.030     0.054  0.204  0.247  0.744  3.859
============================================================================================================
     

• Cartesian/REDO-DF:
  • E1elst & E1exch are always correct.
  • Second-order energies wrong once molecule is rotated. This was expected. See argument above.
• Spherical/NO-REDO-DF:
  • E1elst & E1exch are always correct.
  • Second-order energies are always wrong. Why?

Are the JK-tzvpp Aux bases any good?

• <math>\pi</math>-systems?
• H-bonded systems?

CamCASP and truncated MO space

When molecules are too long and/or basis sets are too diffuse, DALTON will often need to truncate the MO space to enable the SCF cycle to converge. So the effective number of MOs will be less than the size of the basis used. Since CamCASP assumes these two are equal (though it doesn't need to), this results in errors.

Where do changes need to be made to fix this?

• Reading in MOs.
• Constructing the density-matrix.
• Rotating MOs.
• DF
• Transformation code.
• mol%ndim = mol%main%size : both fields need to be modified.

User-defined MOs

These can be read in ASCII form and this could be ideal for testing the code as we do not need to mess around with the DALTON interface to get this working.

DALTON interface

This needs to be modified to handle MO-space truncation. I have copied it to src/interfaces/ in the CamCASP directory tree. We cannot distribute it, but I will modify this version a lot. It writes integrals we do not need and which just occupy disk space.

When reading the basis data in subroutine readnbas, the basis size and orbital size is printed. I'm not sure what the difference is, but it could be useful if one is the actual size of the MO space and the other is the size of the un-truncated basis.