Difference between revisions of "CamCASP/Programming/0"

From CUC3
Jump to navigation Jump to search
import>Am592
import>Am592
Line 16: Line 16:
 
What are the errors introduced when we use spherical GTOs in the auxiliary basis?
 
What are the errors introduced when we use spherical GTOs in the auxiliary basis?
   
  +
==Are the JK-tzvpp Aux bases any good?==
  +
* <math>\pi</math>-systems?
  +
* H-bonded systems?
   
 
==CamCASP and truncated MO space==
 
==CamCASP and truncated MO space==

Revision as of 14:30, 3 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?

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.