CamCASP/Programming/4 - Revision history

import>Am592: /* BUG: ROTATE-UPDATE MOS-DF */

2009-05-11T13:21:26Z

BUG: ROTATE-UPDATE MOS-DF

← Older revision		Revision as of 13:21, 11 May 2009
Line 81:		Line 81:
	* This will take care of the present problem.		* This will take care of the present problem.
	* A similar situation arises when molecule are defined using '''Molecule''' ''name''. So an error could arise from here too.		* A similar situation arises when molecule are defined using '''Molecule''' ''name''. So an error could arise from here too.

			I've added a '''REFERENCE''' command to the '''Edit <molecule> ... End''' block that allows the user to set the current, updated molecule as the reference. Both geometry and orbitals are automatically updated by the ''REFERENCE'' command.

			This still leaves the last problem: this error can still arise if rotations are used in the '''Molecule''' block.
			--[[User:am592\|alston]] 14:21, 11 May 2009 (BST)

import>Am592: /* BUG: ROTATE-UPDATE MOS-DF */

2009-05-06T10:37:59Z

BUG: ROTATE-UPDATE MOS-DF

← Older revision		Revision as of 10:37, 6 May 2009
Line 76:		Line 76:

	How do we get around this?		How do we get around this?

			One way might be as follows:
			* IF the MOs and geometry are consistent, then allow the present molecule to be set as the reference. So the rotation/translation information is reset and the reference (called ''_orig'' fields are set to be the current values).
			* This will take care of the present problem.
			* A similar situation arises when molecule are defined using '''Molecule''' ''name''. So an error could arise from here too.

import>Am592: /* BUG: ROTATE-UPDATE MOS-DF */

2009-05-06T10:11:47Z

BUG: ROTATE-UPDATE MOS-DF

← Older revision		Revision as of 10:11, 6 May 2009
Line 52:		Line 52:
	===BUG: ROTATE-UPDATE MOS-DF===		===BUG: ROTATE-UPDATE MOS-DF===
	Version 5.4.00 of the code has a bug if the following sequence of commands is used:		Version 5.4.00 of the code has a bug if the following sequence of commands is used:
			<pre>
			Edit water2
			Rotate by 133.12506 degrees about -0.637207 0.637207 -0.433515
			Place on XYZ -3.96012396 -0.00000000 -2.21059917
			Update Geom and MOs
			End

			BEGIN DF
			Molecule water2
			Type OO
			Print Nothing
			END

			Begin E1elst
			End
			</pre>
			Here's why:
			# Molecule is rotated and MOs rotated to be consistent with molecule. But molecule definition contains rotation (and translation, but this is inconsequential) information.
			# DF is done correctly.
			# <math>E^{(1)}_{\rm elst}</math> needs integrals like '''OOOO,AABB''' and '''NUCA,OOBB'''. These depend on primitive integrals in the auxiliary basis. Consider one of these: '''S___,_A_B''': it is calculated and then rotated if considered necessary. Now, the molecule water2 still has rotation information defined in its rotation field. So the '''S___,_A_B''' integral is rotated.

			But this is wrong!!! The MOs and molecular geometry were consistent '''before''' DF was done. So no subsequent integral needs to be rotated.

			How do we get around this?

import>Am592: /* Using the EDIT block */

2009-05-06T10:04:08Z

Using the EDIT block

← Older revision		Revision as of 10:04, 6 May 2009
Line 36:		Line 36:

	== Using the EDIT block ==		== Using the EDIT block ==
			===UPDATE===
	I made the following mistake while trying to rotate one of the molecules manually using the EDIT block. I first used:		I made the following mistake while trying to rotate one of the molecules manually using the EDIT block. I first used:
	Edit water2		Edit water2
Line 48:		Line 49:

	Use only one UPDATE in the EDIT block!!!!!		Use only one UPDATE in the EDIT block!!!!!

			===BUG: ROTATE-UPDATE MOS-DF===
			Version 5.4.00 of the code has a bug if the following sequence of commands is used:

import>Am592: /* DALTON */

2009-05-05T16:10:27Z

DALTON

← Older revision		Revision as of 16:10, 5 May 2009
Line 34:		Line 34:

	Columns are MOs and rows are coefficients of primitive AOs. All AOs are s-functions. So all should be the same. But they are not. Also look at MO 5. It should have no s-component. But it does in the second case. So the MOs calculated for the rotated molecule don't seem quite right.		Columns are MOs and rows are coefficients of primitive AOs. All AOs are s-functions. So all should be the same. But they are not. Also look at MO 5. It should have no s-component. But it does in the second case. So the MOs calculated for the rotated molecule don't seem quite right.

			== Using the EDIT block ==
			I made the following mistake while trying to rotate one of the molecules manually using the EDIT block. I first used:
			Edit water2
			Rotate by 133.12506 degrees about -0.637207 0.637207 -0.433515
			Update
			Show
			Place on XYZ -3.96012396 -0.00000000 -2.21059917
			Update
			Show
			End
			The idea was to see what was done at each step. But this is wrong as UPDATE first '''resets the molecule to the reference geometry'''. So The second UPDATE nullified the first ROTATE. So the moral is

			Use only one UPDATE in the EDIT block!!!!!

import>Am592: /* DALTON */

2009-05-05T16:03:12Z

DALTON

@@ Line 9: / Line 9: @@
 I noticed a discrepancy in the e-e and e-n energies (parts of <math>E^{(1)}_{\rm elst}</math>) when calculated in the following ways:
-# MOs calculated in reference geometry and rotated with molecule.
+# MOs calculated in reference geometry and rotated with molecule. DF is done after rotation of MOs. So no integrals needed rotation.
 # Molecules rotated and MOs calculated in already rotated geometry.
 These should be equivalent. And the MOs should be equivalent and related by a Wigner rotation matrix. This was not the case and I found small, but noticable differences that led to small differences in the e-n energies (there should also be differences in the e-e energies, but I still have to trace other errors here, so cannot be sure).
@@ Line 15: / Line 15: @@
 We should have had the following:
 # Same e-n energies. But these were -4966220.470061 CM-1 and  -4966223.294960 CM-1 for the two methods. The differences are small, but they should not be present. Also, they are small compared with the e-n energy (this was the electrons of the rotated water with the nuclei of the un-rotated partner) but there should be *no* difference! Also, the n-n energy was the same in both cases. So the geometries are identical to a very good precision.
-# In this test, I had used only s-functions in the auxiliary basis. So
+# All MO coefficients of s-functions should be invariant. These were not. Here are some examples:

import>Am592: /* DALTON */

2009-05-05T15:41:52Z

DALTON

← Older revision		Revision as of 15:41, 5 May 2009
Line 12:		Line 12:
	# Molecules rotated and MOs calculated in already rotated geometry.		# Molecules rotated and MOs calculated in already rotated geometry.
	These should be equivalent. And the MOs should be equivalent and related by a Wigner rotation matrix. This was not the case and I found small, but noticable differences that led to small differences in the e-n energies (there should also be differences in the e-e energies, but I still have to trace other errors here, so cannot be sure).		These should be equivalent. And the MOs should be equivalent and related by a Wigner rotation matrix. This was not the case and I found small, but noticable differences that led to small differences in the e-n energies (there should also be differences in the e-e energies, but I still have to trace other errors here, so cannot be sure).

			We should have had the following:
			# Same e-n energies. But these were -4966220.470061 CM-1 and -4966223.294960 CM-1 for the two methods. The differences are small, but they should not be present. Also, they are small compared with the e-n energy (this was the electrons of the rotated water with the nuclei of the un-rotated partner) but there should be no difference! Also, the n-n energy was the same in both cases. So the geometries are identical to a very good precision.
			# In this test, I had used only s-functions in the auxiliary basis. So

import>Am592: /* DALTON */

2009-05-05T15:33:16Z

DALTON

← Older revision		Revision as of 15:33, 5 May 2009
Line 4:		Line 4:

	== DALTON ==		== DALTON ==
	MOs from DALTON don't seem to be rotationally invariant.		MOs from DALTON don't seem to be rotationally invariant. Consider the following example:

			water dimer. Sadlej/PBE0/AC MC basis type. Aux basis: JK-tzvpp. Geom: R=2.4 Ang in min-orientation.

			I noticed a discrepancy in the e-e and e-n energies (parts of <math>E^{(1)}_{\rm elst}</math>) when calculated in the following ways:
			# MOs calculated in reference geometry and rotated with molecule.
			# Molecules rotated and MOs calculated in already rotated geometry.
			These should be equivalent. And the MOs should be equivalent and related by a Wigner rotation matrix. This was not the case and I found small, but noticable differences that led to small differences in the e-n energies (there should also be differences in the e-e energies, but I still have to trace other errors here, so cannot be sure).

import>Am592 at 15:23, 5 May 2009

2009-05-05T15:23:16Z

← Older revision		Revision as of 15:23, 5 May 2009
Line 1:		Line 1:
	[[CamCASP]] => [[CamCASP/Programming \| Programming]] => Rotations		[[CamCASP]] => [[CamCASP/Programming \| Programming]] => Rotations

	The theory of integral and MO rotations has been described in [[ CamCASP/Programming/2 \| ~~Integrals~~ ]]		The theory of integral and MO rotations has been described in [[ CamCASP/Programming/2 \| The DF INTEGRAL module ]]. This is a collection of odds and ends related to rotations.

	== DALTON ==		== DALTON ==

import>Am592 at 15:21, 5 May 2009

2009-05-05T15:21:58Z

← Older revision		Revision as of 15:21, 5 May 2009
Line 1:		Line 1:
	[[CamCASP]] => [[CamCASP/Programming \| Programming]] => Rotations		[[CamCASP]] => [[CamCASP/Programming \| Programming]] => Rotations

	The theory of integral and MO rotations is in		The theory of integral and MO rotations has been described in [[ CamCASP/Programming/2 \| Integrals ]]

	== DALTON ==		== DALTON ==