Difference between revisions of "Known Bugs"

From CUC3
Jump to navigation Jump to search
import>Am592
import>Am592
Line 2: Line 2:
   
   
* '''subroutine compare_geometries'''
+
==subroutine compare_geometries==
   
 
This subroutine is quite primitive and limited in capability. Because of this, there are cases where it fails. Some are:
 
This subroutine is quite primitive and limited in capability. Because of this, there are cases where it fails. Some are:
Line 9: Line 9:
 
--[[User:am592|alston]] 16:29, 19 October 2008 (BST)
 
--[[User:am592|alston]] 16:29, 19 October 2008 (BST)
   
* '''Differences in results with and without rotation of integrals'''
+
==Differences in results with and without rotation of integrals==
   
 
I have noticed that OVERLAP integrals (water dimer vtz/vtz) calculated by rotation of integrals (REDO-DF-ON-ROTATION false) differ by about 1% or less from integrals calculated by repeating the density-fitting.
 
I have noticed that OVERLAP integrals (water dimer vtz/vtz) calculated by rotation of integrals (REDO-DF-ON-ROTATION false) differ by about 1% or less from integrals calculated by repeating the density-fitting.
Line 19: Line 19:
   
 
FIXED. It was a normalization problem. Now the differences are about 0.01%. These are negligible. --[[User:am592|alston]] 14:23, 4 November 2008 (GMT)
 
FIXED. It was a normalization problem. Now the differences are about 0.01%. These are negligible. --[[User:am592|alston]] 14:23, 4 November 2008 (GMT)
  +
  +
==2-index integrals in integrals.F90 and Cartesian bases==
  +
The 2-index integrals in integrals.F90 will not be consistent with DALTON if Cartesian basis functions are used in the main basis. So, if integral_switch = 1, i.e., no density-fitting for some integrals, and you request NUCA,OOBB, then the normalization of the integrals (before transformation from AOs to MOs) needs to be adjusted to be consistent with DALTON. There is no problem if the main basis uses spherical GTOs (which is generally the case), but there is an inconsistency if the main basis uses Cartesian GTOs.
  +
  +
This can be resolved if a call to '''subroutine norm_integrals2''' is made in this case.
  +
  +
See [[CamCASP/Programming/1 | Basis Functions]] for more details.

Revision as of 16:17, 13 May 2009

CamCASP => Known Bugs


subroutine compare_geometries

This subroutine is quite primitive and limited in capability. Because of this, there are cases where it fails. Some are:

  1. If the molecule distorts, all that will be reported is same=F and translation=F. Currently, this is taken to mean the molecule has been rotated, which would be false.
  2. For a diatomic molecule with a centre of symmetry, a rotation about the symmetry axis will result in same=F and translated=T (because the sites are translated by equal distances). This is false.

--alston 16:29, 19 October 2008 (BST)

Differences in results with and without rotation of integrals

I have noticed that OVERLAP integrals (water dimer vtz/vtz) calculated by rotation of integrals (REDO-DF-ON-ROTATION false) differ by about 1% or less from integrals calculated by repeating the density-fitting.

The differences in the total overlap seem to vanish if the molecules are not translated. So does that mean that the integrals calculated in CamCASP are not translationally invariant?

The distributed overlap integrals differ in all cases by 1% or less. --alston 19:16, 30 October 2008 (GMT)

FIXED. It was a normalization problem. Now the differences are about 0.01%. These are negligible. --alston 14:23, 4 November 2008 (GMT)

2-index integrals in integrals.F90 and Cartesian bases

The 2-index integrals in integrals.F90 will not be consistent with DALTON if Cartesian basis functions are used in the main basis. So, if integral_switch = 1, i.e., no density-fitting for some integrals, and you request NUCA,OOBB, then the normalization of the integrals (before transformation from AOs to MOs) needs to be adjusted to be consistent with DALTON. There is no problem if the main basis uses spherical GTOs (which is generally the case), but there is an inconsistency if the main basis uses Cartesian GTOs.

This can be resolved if a call to subroutine norm_integrals2 is made in this case.

See Basis Functions for more details.