CamCASP/Bugs/9 - Revision history

import>Am592: /* Conclusions & Resolution */

2011-11-17T16:41:06Z

Conclusions & Resolution

← Older revision		Revision as of 16:41, 17 November 2011
Line 331:		Line 331:

	=Conclusions & Resolution=		=Conclusions & Resolution=
			Firstly, the errors we have encountered in second-order energies for systems like pyridine and XVI are not caused by any bug in CamCASP. The problem seems to lie with DALTON and particular choices of compilers. This is good news as it provides a clear way to get on with work: use different compilers! I suggest we include two of these pyridine examples as part of our test suite: one with the ALDA+CHF kernel and another with the ALDAX+CHF.
⚫	~~Mainly~~ from the example in the DALTON section above, we can conclude the following:

		⚫	Secondly, from the example in the DALTON section above, we can conclude the following:
	# '''DALTON''': Compilers can do bad things to both DALTON:		# '''DALTON''': Compilers can do bad things to both DALTON:
	## We see no problem with the IFORT 12.0.5 compiler.		## We see no problem with the IFORT 12.0.5 compiler.

import>Am592: /* Conclusions & Resolution */

2011-11-17T14:14:40Z

Conclusions & Resolution

← Older revision		Revision as of 14:14, 17 November 2011
Line 347:		Line 347:
	# ICC compiled DALTON (DFT code has C-code in it) seems to result in a significantly slower code compared with GCC. This was a real surprise and may need to be looked into more carefully.		# ICC compiled DALTON (DFT code has C-code in it) seems to result in a significantly slower code compared with GCC. This was a real surprise and may need to be looked into more carefully.
	# Gfortran 4.6.1 (on mmp12) compiled CamCASP was able to run the pyridine dimer job successfully. So the file-record error has vanished or we have fixed the bug (I had fixed some undefined variables in record_handler.F90 a few weeks ago). But the code takes longer than IFORT on the Kernel integral calculations. May have to do with the large number of automatically generated arrays associated with that module. This could be fixed.		# Gfortran 4.6.1 (on mmp12) compiled CamCASP was able to run the pyridine dimer job successfully. So the file-record error has vanished or we have fixed the bug (I had fixed some undefined variables in record_handler.F90 a few weeks ago). But the code takes longer than IFORT on the Kernel integral calculations. May have to do with the large number of automatically generated arrays associated with that module. This could be fixed.

			=To Be Done=
			* Include SVD as an option in calculating the DF-FDDS.
			* Re-run CamCASP with gfortran. Check to see if we get less variation in second-order dispersion. Hard to know what to compare with.

	=Runs/tests in progress=		=Runs/tests in progress=

import>Am592: /* Example 2 */

2011-11-17T14:12:54Z

Example 2

← Older revision		Revision as of 14:12, 17 November 2011
Line 326:		Line 326:
	# small differences in MOs (can it be possible given the excellent agreement in ALDA+CHF on the two machines?)		# small differences in MOs (can it be possible given the excellent agreement in ALDA+CHF on the two machines?)
	# an instability in the LU decomposition used to solve the FDDS equations.		# an instability in the LU decomposition used to solve the FDDS equations.
			# IFORT-related numerical precision error in calculation of the Kernel Integrals.

	I think it must be the latter.		I think it must be one or both of the latter two.

	=Conclusions & Resolution=		=Conclusions & Resolution=

import>Am592: /* Runs/tests in progress */

2011-11-17T13:58:11Z

Runs/tests in progress

← Older revision		Revision as of 13:58, 17 November 2011
Line 349:		Line 349:
	=Runs/tests in progress=		=Runs/tests in progress=
	* Tati: ifort 11.x with ATLAS : Done		* Tati: ifort 11.x with ATLAS : Done
	* Tati: gfortran with ATLAS (CamCASP still ifort)		* Tati: gfortran with ATLAS (CamCASP still ifort) : done

import>Am592: /* Conclusions & Resolution */

2011-11-17T13:57:57Z

Conclusions & Resolution

← Older revision		Revision as of 13:57, 17 November 2011
Line 330:		Line 330:

	=Conclusions & Resolution=		=Conclusions & Resolution=
			Mainly from the example in the DALTON section above, we can conclude the following:
	# '''DALTON''': Compilers can do bad things to both DALTON:		# '''DALTON''': Compilers can do bad things to both DALTON:
	## We see no problem with the IFORT 12.0.5 compiler.		## We see no problem with the IFORT 12.0.5 compiler.

import>Am592: /* Conclusions */

2011-11-17T13:57:23Z

Conclusions

@@ Line 329: / Line 329: @@
 I think it must be the latter.
-=Conclusions=
+=Conclusions & Resolution=
 =Runs/tests in progress=

import>Am592: /* Example 2 */

2011-11-17T13:48:13Z

Example 2

@@ Line 286: / Line 286: @@
 ==Example 2==
 The broken symmetry pyridine dimer.
 =Conclusions=

import>Am592: /* DALTON */

2011-11-16T13:19:18Z

DALTON

← Older revision		Revision as of 13:19, 16 November 2011
Line 283:		Line 283:
	=DALTON=		=DALTON=
	Is the problem with DALTON? If so, is it a compiler/library problem?		Is the problem with DALTON? If so, is it a compiler/library problem?

	==ATLAS & Goto2==
	===Example 2===		==Example 2==
	The broken symmetry dimer.		The broken symmetry pyridine dimer.

	=Conclusions=		=Conclusions=

import>Am592: /* DALTON energies */

2011-11-16T12:29:08Z

DALTON energies

← Older revision		Revision as of 12:29, 16 November 2011
Line 148:		Line 148:
	* Basis too diffuse/large. Uses mid-bonds. Perhaps this leads to linear-dependencies and oddities in the MOs. But how does this explain '''PUZZLE 1'''?		* Basis too diffuse/large. Uses mid-bonds. Perhaps this leads to linear-dependencies and oddities in the MOs. But how does this explain '''PUZZLE 1'''?
	* DALTON parameters (in the *.dal files) could be the cause of the problem. We should allow orbital-space truncation by reducing '''.CMOMAX''' and increasing '''.AO DELETE'''.		* DALTON parameters (in the *.dal files) could be the cause of the problem. We should allow orbital-space truncation by reducing '''.CMOMAX''' and increasing '''.AO DELETE'''.
	* Compile on Tati with the new version of ifort and the ATLAS library.		* Compile on Tati with the new version of ifort and the ATLAS library.

			The first two points should have effected runs on both machines. Better try different compilers and libraries.

	===Cross-runs: MOs from Tati with CamCASP on mmp12===		===Cross-runs: MOs from Tati with CamCASP on mmp12===

import>Am592: /* Runs/tests in progress */

2011-11-16T12:26:38Z

Runs/tests in progress

← Older revision		Revision as of 12:26, 16 November 2011
Line 292:		Line 292:

	=Runs/tests in progress=		=Runs/tests in progress=
	* Tati: ifort 11.x with ATLAS		* Tati: ifort 11.x with ATLAS : Done
			* Tati: gfortran with ATLAS (CamCASP still ifort)
	*