Difference between revisions of "CamCASP/Programming/0"
import>Am592 |
import>Am592 |
||
Line 81: | Line 81: | ||
* DF |
* DF |
||
* Transformation code. |
* Transformation code. |
||
+ | * mol%ndim = mol%main%size : both fields need to be modified. |
Revision as of 13:38, 4 March 2009
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.