CamCASP/Notes/2 - Revision history

import>Am592: /* Density-fitting done only once */

2012-05-21T14:48:43Z

Density-fitting done only once

← Older revision		Revision as of 14:48, 21 May 2012
Line 49:		Line 49:

	We must make sure the density-fitting is done in the original, un-rotated (translations don't matter) molecular geometries. To do this, we will make explicit calls to '''DF''' while the molecules are in thier original geometries. (The original geometries could be obtained using the '''EDIT''' module and the RESTORE command. But if you do that, make sure you reset all translational and rotational information too.)		We must make sure the density-fitting is done in the original, un-rotated (translations don't matter) molecular geometries. To do this, we will make explicit calls to '''DF''' while the molecules are in thier original geometries. (The original geometries could be obtained using the '''EDIT''' module and the RESTORE command. But if you do that, make sure you reset all translational and rotational information too.)
	Only then will we make the call to '''ENERGY-SCAN'''. ~~Here's the input file:~~		Only then will we make the call to '''ENERGY-SCAN'''.

			This is no longer needed in the current version of CamCASP. The code now restores the reference geometries to all molecules and performs the density-fitting. --[[User:am592\|alston]] 15:48, 21 May 2012 (BST)

			Here's the input file:

	<pre>		<pre>
Line 59:		Line 63:
	Lambda = 0.0		Lambda = 0.0
	REDO-DF-ON-ROTATION False		REDO-DF-ON-ROTATION False
			! Type OO is sufficient for first order energies and overlaps
			Type OO
	End		End

			! You can now skip these lines with the current CamCASP
			Skip
	Begin DF		Begin DF
	Molecule water1		Molecule water1
Line 69:		Line 77:
	Type NN		Type NN
	End		End
			End-Skip

	Begin Energy-scan		Begin Energy-scan
Line 82:		Line 91:
	NOTES:		NOTES:
	# Since CamCASP can perform integral rotations only with Spherical GTOs, '''the auxiliary basis must use Spherical GTOs''' for this to work. This does mean a small loss in accuracy, as, from our experience, the extra flexibility of the equivalent Cartesian GTOs results in a more accurate density-fitting, and consequently more accurate integrals.		# Since CamCASP can perform integral rotations only with Spherical GTOs, '''the auxiliary basis must use Spherical GTOs''' for this to work. This does mean a small loss in accuracy, as, from our experience, the extra flexibility of the equivalent Cartesian GTOs results in a more accurate density-fitting, and consequently more accurate integrals.
	# Notice we have used '''TYPE NN''' in the '''DF''' calls. This is needed at present. It's a ''feature'' of CamCASP that needs to be removed. I'm not sure if the ''NN'' is always needed. For a scan of first order energies it may not be required. I have to check. It is still true that DF must be done before any of the monomers are rotated. This is because the code assumes that the DF matrices were calculated in the reference geometry of the monomers. --[[User:am592\|alston]] 19:09, 17 May 2012 (BST)
	# This procedure is considerably faster than the above, when the density-fitting is repeated for each dimer geometry. But bear in mind that if we calculate the exchange energies in the '''Energy-Scan''', the speed difference is reduced because the dimer density-fitting is needed for the exchange energies, and this will need to be re-done for each and every dimer configuration.		# This procedure is considerably faster than the above, when the density-fitting is repeated for each dimer geometry. But bear in mind that if we calculate the exchange energies in the '''Energy-Scan''', the speed difference is reduced because the dimer density-fitting is needed for the exchange energies, and this will need to be re-done for each and every dimer configuration.
	# If you are going to calculate exchange energies, and you want a higher accuracy, you might want to consider setting '''REDO-DF-ON-ROTATION''' to TRUE and using '''Cartesian GTOs''' in the auxiliary basis. But bear in mind that both these will add to the computational cost of the calculation.		# If you are going to calculate exchange energies, and you want a higher accuracy, you might want to consider setting '''REDO-DF-ON-ROTATION''' to TRUE and using '''Cartesian GTOs''' in the auxiliary basis. But bear in mind that both these will add to the computational cost of the calculation. In this case you will also want to use a DC auxiliary basis.
	# Potential source of failure: If the monomers are identical and in identical starting geometries then the current version of CamCASP will stop with a ''create_type_molecule'' error. This needs to be fixed. In the meanwhile, a simple fix is to give one molecule an offset. Don't rotate it, just change it's centre to, say, ''(0,0,1)''. This will allow the MOs to be the same, but will stop CamCASP getting confused. --[[User:am592\|alston]] 19:09, 17 May 2012 (BST)

	--[[User:am592\|alston]] 10:42, 25 ~~November~~ ~~2008~~ (~~GMT~~)		--[[User:am592\|alston]] 15:48, 21 May 2012 (BST)

	===Constrained density-fitting===		===Constrained density-fitting===

import>Am592: /* Density-fitting done only once */

2012-05-17T18:09:58Z

Density-fitting done only once

← Older revision		Revision as of 18:09, 17 May 2012
Line 82:		Line 82:
	NOTES:		NOTES:
	# Since CamCASP can perform integral rotations only with Spherical GTOs, '''the auxiliary basis must use Spherical GTOs''' for this to work. This does mean a small loss in accuracy, as, from our experience, the extra flexibility of the equivalent Cartesian GTOs results in a more accurate density-fitting, and consequently more accurate integrals.		# Since CamCASP can perform integral rotations only with Spherical GTOs, '''the auxiliary basis must use Spherical GTOs''' for this to work. This does mean a small loss in accuracy, as, from our experience, the extra flexibility of the equivalent Cartesian GTOs results in a more accurate density-fitting, and consequently more accurate integrals.
	# Notice we have used '''TYPE NN''' in the '''DF''' calls. This is needed at present. It's a ''feature'' of CamCASP that needs to be removed.		# Notice we have used '''TYPE NN''' in the '''DF''' calls. This is needed at present. It's a ''feature'' of CamCASP that needs to be removed. I'm not sure if the ''NN'' is always needed. For a scan of first order energies it may not be required. I have to check. It is still true that DF must be done before any of the monomers are rotated. This is because the code assumes that the DF matrices were calculated in the reference geometry of the monomers. --[[User:am592\|alston]] 19:09, 17 May 2012 (BST)
	# This procedure is considerably faster than the above, when the density-fitting is repeated for each dimer geometry. But bear in mind that if we calculate the exchange energies in the '''Energy-Scan''', the speed difference is reduced because the dimer density-fitting is needed for the exchange energies, and this will need to be re-done for each and every dimer configuration.		# This procedure is considerably faster than the above, when the density-fitting is repeated for each dimer geometry. But bear in mind that if we calculate the exchange energies in the '''Energy-Scan''', the speed difference is reduced because the dimer density-fitting is needed for the exchange energies, and this will need to be re-done for each and every dimer configuration.
	# If you are going to calculate exchange energies, and you want a higher accuracy, you might want to consider setting '''REDO-DF-ON-ROTATION''' to TRUE and using '''Cartesian GTOs''' in the auxiliary basis. But bear in mind that both these will add to the computational cost of the calculation.		# If you are going to calculate exchange energies, and you want a higher accuracy, you might want to consider setting '''REDO-DF-ON-ROTATION''' to TRUE and using '''Cartesian GTOs''' in the auxiliary basis. But bear in mind that both these will add to the computational cost of the calculation.
			# Potential source of failure: If the monomers are identical and in identical starting geometries then the current version of CamCASP will stop with a ''create_type_molecule'' error. This needs to be fixed. In the meanwhile, a simple fix is to give one molecule an offset. Don't rotate it, just change it's centre to, say, ''(0,0,1)''. This will allow the MOs to be the same, but will stop CamCASP getting confused. --[[User:am592\|alston]] 19:09, 17 May 2012 (BST)

	--[[User:am592\|alston]] 10:42, 25 November 2008 (GMT)		--[[User:am592\|alston]] 10:42, 25 November 2008 (GMT)

import>Am592: /* Density-fitting done only once */

2008-11-25T11:11:07Z

Density-fitting done only once

← Older revision		Revision as of 11:11, 25 November 2008
Line 82:		Line 82:
	NOTES:		NOTES:
	# Since CamCASP can perform integral rotations only with Spherical GTOs, '''the auxiliary basis must use Spherical GTOs''' for this to work. This does mean a small loss in accuracy, as, from our experience, the extra flexibility of the equivalent Cartesian GTOs results in a more accurate density-fitting, and consequently more accurate integrals.		# Since CamCASP can perform integral rotations only with Spherical GTOs, '''the auxiliary basis must use Spherical GTOs''' for this to work. This does mean a small loss in accuracy, as, from our experience, the extra flexibility of the equivalent Cartesian GTOs results in a more accurate density-fitting, and consequently more accurate integrals.
	# ~~That should do it.~~ Notice I used '''TYPE NN''' in the '''DF''' calls. This is needed at present.		# Notice we have used '''TYPE NN''' in the '''DF''' calls. This is needed at present. It's a ''feature'' of CamCASP that needs to be removed.
	# This procedure is considerably faster than the above, when the density-fitting is repeated for each dimer geometry. But bear in mind that if we calculate the exchange energies in the '''Energy-Scan''', the speed difference is reduced because the dimer density-fitting is needed for the exchange energies, and this will need to be re-done for each and every dimer configuration.		# This procedure is considerably faster than the above, when the density-fitting is repeated for each dimer geometry. But bear in mind that if we calculate the exchange energies in the '''Energy-Scan''', the speed difference is reduced because the dimer density-fitting is needed for the exchange energies, and this will need to be re-done for each and every dimer configuration.
	# If you are going to calculate exchange energies, and you want a higher accuracy, you might want to consider setting '''REDO-DF-ON-ROTATION''' to TRUE and using '''Cartesian GTOs''' in the auxiliary basis. But bear in mind that both these will add to the computational cost of the calculation.		# If you are going to calculate exchange energies, and you want a higher accuracy, you might want to consider setting '''REDO-DF-ON-ROTATION''' to TRUE and using '''Cartesian GTOs''' in the auxiliary basis. But bear in mind that both these will add to the computational cost of the calculation.

import>Am592: /* Density-fitting done only once */

2008-11-25T10:42:49Z

Density-fitting done only once

← Older revision		Revision as of 10:42, 25 November 2008
Line 80:		Line 80:
	End		End
	</pre>		</pre>
			NOTES:
	~~NOTE:~~ Since CamCASP can perform integral rotations only with Spherical GTOs, '''the auxiliary basis must use Spherical GTOs''' for this to work. This does mean a small loss in accuracy, as, from our experience, the extra flexibility of the equivalent Cartesian GTOs results in a more accurate density-fitting, and consequently more accurate integrals.		# Since CamCASP can perform integral rotations only with Spherical GTOs, '''the auxiliary basis must use Spherical GTOs''' for this to work. This does mean a small loss in accuracy, as, from our experience, the extra flexibility of the equivalent Cartesian GTOs results in a more accurate density-fitting, and consequently more accurate integrals.
		⚫	# That should do it. Notice I used '''TYPE NN''' in the '''DF''' calls. This is needed at present.
			# This procedure is considerably faster than the above, when the density-fitting is repeated for each dimer geometry. But bear in mind that if we calculate the exchange energies in the '''Energy-Scan''', the speed difference is reduced because the dimer density-fitting is needed for the exchange energies, and this will need to be re-done for each and every dimer configuration.
			# If you are going to calculate exchange energies, and you want a higher accuracy, you might want to consider setting '''REDO-DF-ON-ROTATION''' to TRUE and using '''Cartesian GTOs''' in the auxiliary basis. But bear in mind that both these will add to the computational cost of the calculation.

		⚫	--[[User:am592\|alston]] 10:42, 25 November 2008 (GMT)
⚫	That should do it. Notice I used '''TYPE NN''' in the '''DF''' calls. This is needed at present.
⚫	--[[User:am592\|alston]] 17:36, 30 ~~October~~ 2008 (GMT)

	===Constrained density-fitting===		===Constrained density-fitting===

import>Am592: /* Energy scan */

2008-11-25T10:36:15Z

Energy scan

← Older revision		Revision as of 10:36, 25 November 2008
Line 3:		Line 3:
	== Energy scan ==		== Energy scan ==

	This is a very high-level module that uses a lot of the lower-level modules. As a consequence, it is easy to break and has a few ''features''.		This is a very high-level module that uses a lot of the lower-level modules. As a consequence, it is easy to break and has a few ''features''. Some of these are described below.

	===Density-fitting repeated for each dimer===		===Density-fitting repeated for each dimer===

import>Am592: /* Density-fitting done only once */

2008-11-25T10:35:24Z

Density-fitting done only once

← Older revision		Revision as of 10:35, 25 November 2008
Line 53:		Line 53:
	<pre>		<pre>
	MOLECULEs defined as before...		MOLECULEs defined as before...
			...BUT...the Auxiliary basis MUST use Spherical GTOs.

	SET DF		SET DF
Line 79:		Line 80:
	End		End
	</pre>		</pre>
			NOTE: Since CamCASP can perform integral rotations only with Spherical GTOs, '''the auxiliary basis must use Spherical GTOs''' for this to work. This does mean a small loss in accuracy, as, from our experience, the extra flexibility of the equivalent Cartesian GTOs results in a more accurate density-fitting, and consequently more accurate integrals.

	That should do it. Notice I used '''TYPE NN''' in the '''DF''' calls. This is needed at present.		That should do it. Notice I used '''TYPE NN''' in the '''DF''' calls. This is needed at present.
	--[[User:am592\|alston]] 17:36, 30 October 2008 (GMT)		--[[User:am592\|alston]] 17:36, 30 October 2008 (GMT)


	===Constrained density-fitting===		===Constrained density-fitting===

import>Am592 at 18:49, 24 November 2008

2008-11-24T18:49:44Z

← Older revision		Revision as of 18:49, 24 November 2008
Line 5:		Line 5:
	This is a very high-level module that uses a lot of the lower-level modules. As a consequence, it is easy to break and has a few ''features''.		This is a very high-level module that uses a lot of the lower-level modules. As a consequence, it is easy to break and has a few ''features''.

	* '''Density-fitting~~'''~~		===Density-fitting repeated for each dimer===

	If you have set '''REDO-DF-ON-ROTATION''' to TRUE in module '''DF''', then all is well and you don't need to worry about anything. You can call the '''ENERGY-SCAN''' module and should get correct results.		If you have set '''REDO-DF-ON-ROTATION''' to TRUE in module '''DF''', then all is well and you don't need to worry about anything. You can call the '''ENERGY-SCAN''' module and should get correct results.

Line 42:		Line 43:
	# And then the required overlap integrals are calculated by multiplying the DF solution (in rotated geometry) with the '''OVRL XAXB''' integrals that have been also rotated. This results in the wrong integrals.		# And then the required overlap integrals are calculated by multiplying the DF solution (in rotated geometry) with the '''OVRL XAXB''' integrals that have been also rotated. This results in the wrong integrals.


⚫	~~'''~~So what is the correct way to do the energy scan if '''REDO-DF-ON-ROTATION''' is FALSE?~~'''~~
			===Density-fitting done only once===

		⚫	So what is the correct way to do the energy scan if '''REDO-DF-ON-ROTATION''' is FALSE?

	We must make sure the density-fitting is done in the original, un-rotated (translations don't matter) molecular geometries. To do this, we will make explicit calls to '''DF''' while the molecules are in thier original geometries. (The original geometries could be obtained using the '''EDIT''' module and the RESTORE command. But if you do that, make sure you reset all translational and rotational information too.)		We must make sure the density-fitting is done in the original, un-rotated (translations don't matter) molecular geometries. To do this, we will make explicit calls to '''DF''' while the molecules are in thier original geometries. (The original geometries could be obtained using the '''EDIT''' module and the RESTORE command. But if you do that, make sure you reset all translational and rotational information too.)
Line 80:		Line 84:


	* '''Constrained density-fitting~~'''~~		===Constrained density-fitting===

	Yet another problem occurs when constrained DF is used in the energy scan. The way things are done now, the density-overlap integrals can be obtained using constrained DF (see code below), but only if scanned in isolation. That is, you cannot scan both the OVERLAP (with constrained DF) and E1ELST (say). Since E1ELST does not need DF with constraints, the constraint parameters are reset and you get unexpected results.		Yet another problem occurs when constrained DF is used in the energy scan. The way things are done now, the density-overlap integrals can be obtained using constrained DF (see code below), but only if scanned in isolation. That is, you cannot scan both the OVERLAP (with constrained DF) and E1ELST (say). Since E1ELST does not need DF with constraints, the constraint parameters are reset and you get unexpected results.

import>Am592: /* Energy scan */

2008-10-31T09:31:55Z

Energy scan

← Older revision		Revision as of 09:31, 31 October 2008
Line 103:		Line 103:

	Set E1exch		Set E1exch
	Overlap integrals ~~without~~ constraints		Overlap integrals with constraints
	End		End

import>Am592: /* Energy scan */

2008-10-30T19:11:46Z

Energy scan

← Older revision		Revision as of 19:11, 30 October 2008
Line 78:		Line 78:
	That should do it. Notice I used '''TYPE NN''' in the '''DF''' calls. This is needed at present.		That should do it. Notice I used '''TYPE NN''' in the '''DF''' calls. This is needed at present.
	--[[User:am592\|alston]] 17:36, 30 October 2008 (GMT)		--[[User:am592\|alston]] 17:36, 30 October 2008 (GMT)


			* '''Constrained density-fitting'''
			Yet another problem occurs when constrained DF is used in the energy scan. The way things are done now, the density-overlap integrals can be obtained using constrained DF (see code below), but only if scanned in isolation. That is, you cannot scan both the OVERLAP (with constrained DF) and E1ELST (say). Since E1ELST does not need DF with constraints, the constraint parameters are reset and you get unexpected results.

			This can be fixed, but till I do so, do not attempt this.

			To scan just the OVERLAP with constraints use:
			<pre>
			SET DF
			Eta = 0.0
			Lambda = 1000.0 (for example)
			REDO-DF-ON-ROTATION False
			End

			Begin DF
			Molecule water1
			Type NN
			End
			Begin DF
			Molecule water2
			Type NN
			End

			Set E1exch
			Overlap integrals without constraints
			End

			Begin Energy-scan
			Probe water1 with water2
			Energy Overlap
			...
			End
			</pre>
			--[[User:am592\|alston]] 19:11, 30 October 2008 (GMT)

import>Am592 at 17:36, 30 October 2008

2008-10-30T17:36:23Z

← Older revision		Revision as of 17:36, 30 October 2008
Line 2:		Line 2:

	== Energy scan ==		== Energy scan ==

			This is a very high-level module that uses a lot of the lower-level modules. As a consequence, it is easy to break and has a few ''features''.

			* '''Density-fitting'''
			If you have set '''REDO-DF-ON-ROTATION''' to TRUE in module '''DF''', then all is well and you don't need to worry about anything. You can call the '''ENERGY-SCAN''' module and should get correct results.

			However, if you have set '''REDO-DF-ON-ROTATION''' to FALSE, things can go wrong. Consider the following example:
			<pre>
			MOLECULE water1 at 0.0 0.0 0.0
			...
			END
			MOLECULE water2 at 0.0 0.0 0.0
			...
			END

			SET DF
			Eta = 0.0
			Lambda = 0.0
			REDO-DF-ON-ROTATION False
			End

			Begin Energy-scan
			Probe water1 with water2
			Energy Overlap
			Units Bohr Degree
			Points
			5.0 0.0 0.0 90.0 0.0 0.0 1.0
			0.0 0.0 2.0 45.0 0.0 1.0 1.0
			---
			Overlap-file overlap_NOredo
			End

			</pre>
			Here's what happens:
			# The molecules are defined and their MOs are consistent with the defined geometry. So far, so good.
			# In '''ENERGY-SCAN''', water2 is translated (nothing to worry about that) and rotated, but because '''REDO-DF-ON-ROTATION''' is FALSE, the molecular orbitals of water2 are NOT updated. So they are now inconsistent with the molecular geometry.
			# At some stage, the '''DF''' module is called. This module will make the MOs of both molecules consistent with their geometry before performing the DF. That's good. But notice that the DF has been done for the ''rotated'' water2.
			# The overlap integrals in the auxiliary basis set ('''OVRL XAXB''') are calculated and, because '''REDO-DF-ON-ROTATION''' is FALSE, the '''DF-INT''' module (called implicitly) ''rotates'' the integrals to be consistent with what it thinks is the DF solution in the ''original geometry of water2''. Only this is false. As the DF for water2 was done not in the original geometry, but the rotated geometry.
			# And then the required overlap integrals are calculated by multiplying the DF solution (in rotated geometry) with the '''OVRL XAXB''' integrals that have been also rotated. This results in the wrong integrals.

			'''So what is the correct way to do the energy scan if '''REDO-DF-ON-ROTATION''' is FALSE?'''

			We must make sure the density-fitting is done in the original, un-rotated (translations don't matter) molecular geometries. To do this, we will make explicit calls to '''DF''' while the molecules are in thier original geometries. (The original geometries could be obtained using the '''EDIT''' module and the RESTORE command. But if you do that, make sure you reset all translational and rotational information too.)
			Only then will we make the call to '''ENERGY-SCAN'''. Here's the input file:

			<pre>
			MOLECULEs defined as before...

			SET DF
			Eta = 0.0
			Lambda = 0.0
			REDO-DF-ON-ROTATION False
			End

			Begin DF
			Molecule water1
			Type NN
			End
			Begin DF
			Molecule water2
			Type NN
			End

			Begin Energy-scan
			Probe water1 with water2
			Energy Overlap
			Units Bohr Degree
			Points
			5.0 0.0 0.0 90.0 0.0 0.0 1.0
			0.0 0.0 2.0 45.0 0.0 1.0 1.0
			---
			End
			</pre>

			That should do it. Notice I used '''TYPE NN''' in the '''DF''' calls. This is needed at present.
			--[[User:am592\|alston]] 17:36, 30 October 2008 (GMT)