Difference between revisions of "CamCASP/Bugs/6"
import>Am592 |
import>Am592 |
||
Line 5: | Line 5: | ||
===Error because molecule reference is not correctly set === |
===Error because molecule reference is not correctly set === |
||
− | See [[ CamCASP/Programming/4 | Rotations]] for more on this bug. It is present in 5.4.00 |
+ | See [[ CamCASP/Programming/4 | Rotations]] for more on this bug. It is present in 5.4.00. |
+ | This is such a subtle bug that I'm going to repeat the information here: |
||
+ | Version 5.4.00 of the code has a bug if the following sequence of commands is used: |
||
⚫ | |||
+ | <pre> |
||
⚫ | |||
+ | Edit water2 |
||
− | * The EDIT block is provided with a '''REFERENCE''' command that allows the user to set the reference manually. So, if geometry and orbitals are updated in this block, the REFERENCE command must be called. |
||
+ | 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? |
||
+ | |||
⚫ | |||
+ | * 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 ''ref_'' 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. |
||
+ | |||
+ | 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 bug could also occur because of the way molecules are read. So subroutine set_reference is called when the molecule is created in the MOLECULE block. This does the updating and sets the reference correctly. The molecular rotation and translation fields are then nullified so everything is consistent. |
||
+ | |||
+ | --[[User:am592|alston]] 17:05, 13 May 2009 (BST) |
||
=== Error in <math>E^{(1)}_{\rm elst}</math> when dimer DF is not done === |
=== Error in <math>E^{(1)}_{\rm elst}</math> when dimer DF is not done === |
Latest revision as of 16:05, 13 May 2009
Bugs that arise when rotation are performed
Error because molecule reference is not correctly set
See Rotations for more on this bug. It is present in 5.4.00. This is such a subtle bug that I'm going to repeat the information here:
Version 5.4.00 of the code has a bug if the following sequence of commands is used:
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
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?
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 ref_ 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.
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 bug could also occur because of the way molecules are read. So subroutine set_reference is called when the molecule is created in the MOLECULE block. This does the updating and sets the reference correctly. The molecular rotation and translation fields are then nullified so everything is consistent.
--alston 17:05, 13 May 2009 (BST)
Error in <math>E^{(1)}_{\rm elst}</math> when dimer DF is not done
- Version: 5.4.00 and earlier
- Basis: Spherical auxiliary basis.
- Effects: S___,_A_B and any integral and energy that depends on this.
Whether of not you do the dimer DF should have nothing to do with <math>E^{(1)}_{\rm elst}</math>, but version 5.4.00 of the code has an error in j_matrix.F90 that results in an error if the dimer DF is not done before calculating the electrostatic energy (or any energy that uses the S___,_A_B integrals). This occurred because norm_integrals2 was not called even though it is needed if the auxiliary basis uses shperical GTOs.
FIXED: I've now added code to make the call to norm_integrals2. Seems to work.