CamCASP/Compilation - Revision history

import>Am592 at 14:05, 17 November 2011

2011-11-17T14:05:30Z

← Older revision		Revision as of 14:05, 17 November 2011
Line 3:		Line 3:
	==Compilers to Avoid==		==Compilers to Avoid==
	* IFORT 11.x. Causes instabilities in DALTON and, to a lesser extent in CamCASP. See description of this bug in [[ CamCASP/Bugs/9 \| Errors in Second-order Energies ]]		* IFORT 11.x. Causes instabilities in DALTON and, to a lesser extent in CamCASP. See description of this bug in [[ CamCASP/Bugs/9 \| Errors in Second-order Energies ]]

			==Compilers that Seem OK==
			* Gfortran 4.6.1 : Earlier versions caused a direct file access error in CamCASP when files were larger than a certain undetermined size.
			* Ifort 12.0.5 : Good code for both DALTON and CamCASP.

			==Libraries to Avoid==
			* MKL: Causes memory leaks that effect the rest of CamCASP adversely.

			==Libraries that Seem OK==
			* ATLAS : yet to find a flaw in this library. Recommended. Needs to be built with all LAPACK routines. See notes on the ATLAS page for details of how this is to be done.
			* Goto2 BLAS/LAPACK: No problems. Slightly faster than ATLAS.

import>Am592 at 14:01, 17 November 2011

2011-11-17T14:01:05Z

← Older revision		Revision as of 14:01, 17 November 2011
Line 1:		Line 1:
	[[ CamCASP ]] => Compilation		[[ CamCASP ]] => Compilation

			==Compilers to Avoid==
			* IFORT 11.x. Causes instabilities in DALTON and, to a lesser extent in CamCASP. See description of this bug in [[ CamCASP/Bugs/9 \| Errors in Second-order Energies ]]


	==Notes on compiling CamCASP==		==Notes on compiling CamCASP==

import>Am592: /* Gfortran */

2011-11-14T17:43:15Z

Gfortran

← Older revision		Revision as of 17:43, 14 November 2011
Line 173:		Line 173:
	Where ''patch-sapt-2006-1 happens to be the latest patch at the present time.		Where ''patch-sapt-2006-1 happens to be the latest patch at the present time.

	===Gfortran===		===Gfortran & iFort ===

	For Dalton, the configure script must be edited to allow for the use of gfortran.		For Dalton, the configure script must be edited to allow for the use of gfortran.

import>Am592: /* Ifort */

2010-07-14T10:04:00Z

Ifort

← Older revision		Revision as of 10:04, 14 July 2010
Line 16:		Line 16:
	</pre>		</pre>
	The last line resulted in the segfault. Both types were in memory and had the right dimensions. The copy could be done explicitly through loops and both arrays could be accessed and set to 0.0, but they S_A_A could not be filled using the whole-array operation shown above. Could this be a compiler problem? '''-check bounds''' showed nothing.--[[User:am592\|alston]] 16:00, 13 July 2010 (BST)		The last line resulted in the segfault. Both types were in memory and had the right dimensions. The copy could be done explicitly through loops and both arrays could be accessed and set to 0.0, but they S_A_A could not be filled using the whole-array operation shown above. Could this be a compiler problem? '''-check bounds''' showed nothing.--[[User:am592\|alston]] 16:00, 13 July 2010 (BST)
			* '''-heap-arrays 2048''' seems to be a good choice. Timings for benzene dimer: (real time) 76mins where gfortran takes >110mins. This is a substantial reduction. User time is 68mins, so 8mins is spent in system time (disk!).--[[User:am592\|alston]] 11:04, 14 July 2010 (BST)
			* '''IMPORTANT''': There are small differences in second-order induction and dispersion energies (pol) with ifort. The second-order exchange energies (UC) are the same as those with gfortran and pgf90. What could be different? Looks like the Propagator is not quite the same with ifort. But why? In all cases, the Goto2 library is used for solving the LR-DFT equations.--[[User:am592\|alston]] 11:04, 14 July 2010 (BST)

	===PGF90===		===PGF90===

import>Am592: /* Ifort */

2010-07-13T15:00:17Z

Ifort

@@ Line 4: / Line 4: @@
 ===Ifort===
 * CamCASP 5.5-dev (revision 21014) now compiles with ifort 11.1. This includes all codes in the distribution. CamCASP itself runs almost twice as fast as the corresponding binary from pgf90. I used the Goto2 Lapack/Blas. MKL should probably not be used - it was always unreliable.--[[User:am592|alston]] 14:23, 13 July 2010 (BST)
 ===PGF90===

import>Am592: /* Notes on compiling CamCASP */

2010-07-13T13:23:30Z

Notes on compiling CamCASP

← Older revision		Revision as of 13:23, 13 July 2010
Line 2:		Line 2:

	==Notes on compiling CamCASP==		==Notes on compiling CamCASP==
			===Ifort===
			* CamCASP 5.5-dev (revision 21014) now compiles with ifort 11.1. This includes all codes in the distribution. CamCASP itself runs almost twice as fast as the corresponding binary from pgf90. I used the Goto2 Lapack/Blas. MKL should probably not be used - it was always unreliable.--[[User:am592\|alston]] 14:23, 13 July 2010 (BST)

	===PGF90===		===PGF90===
	By in large, this compiler works with CamCASP.		By in large, this compiler works with CamCASP.

import>Am592: /* 10.x */

2010-05-14T13:25:49Z

10.x

@@ Line 19: / Line 19: @@
 * Comparisons with various compiler versions (8.0.4 and the 10.x series) suggests that they are all produce binaries that are slower than a Gfortran optimized binary, especially for the integrals from gamint.F (though I am inferring this - we do not time calls to gamint.F due to their number!).
 * Curiously the kernel integrals are evaluated in roughly the same time (except for pgf90 8.0.4 which was significantly slower here) with gfortran and pgf90 (10.x) binaries.
 ===Gfortran===

import>Am592: /* 10.x */

2010-05-14T13:18:51Z

10.x

← Older revision		Revision as of 13:18, 14 May 2010
Line 17:		Line 17:

	* Update: The culprit seems to have been the -fastsse flag and not -O3. with -O2 (and no -fastsse) integrals are calculated significantly slower (by around 90%, compared with a gfortran binary).		* Update: The culprit seems to have been the -fastsse flag and not -O3. with -O2 (and no -fastsse) integrals are calculated significantly slower (by around 90%, compared with a gfortran binary).
			* Comparisons with various compiler versions (8.0.4 and the 10.x series) suggests that they are all produce binaries that are slower than a Gfortran optimized binary, especially for the integrals from gamint.F (though I am inferring this - we do not time calls to gamint.F due to their number!).
			* Curiously the kernel integrals are evaluated in roughly the same time (except for pgf90 8.0.4 which was significantly slower here) with gfortran and pgf90 (10.x) binaries.

	===Gfortran===		===Gfortran===

import>Am592: /* 10.x */

2010-05-14T11:31:07Z

10.x

← Older revision		Revision as of 11:31, 14 May 2010
Line 15:		Line 15:
	</pre>		</pre>
	A similar message is printed with dma.F90. I've seen this error with 10.1-4.		A similar message is printed with dma.F90. I've seen this error with 10.1-4.

			* Update: The culprit seems to have been the -fastsse flag and not -O3. with -O2 (and no -fastsse) integrals are calculated significantly slower (by around 90%, compared with a gfortran binary).

	===Gfortran===		===Gfortran===

import>Am592: /* Issues */

2010-05-14T11:10:24Z

Issues

← Older revision		Revision as of 11:10, 14 May 2010
Line 56:		Line 56:
	* Newer versions of gcc (4.4.x onwards - I am not sure, perhaps even 4.3.x) result in a problem writing direct-access files with more than 16384 records. The exact number seems to fluctuate a little, but it is very close to <math>2^{14}</math>. The file gets mangled on either write or read. No other compiler seems to exhibit the problem, and nor did gfortran in mid-2009 when I used an experimental version of gfortran 4.4 or 4.3.		* Newer versions of gcc (4.4.x onwards - I am not sure, perhaps even 4.3.x) result in a problem writing direct-access files with more than 16384 records. The exact number seems to fluctuate a little, but it is very close to <math>2^{14}</math>. The file gets mangled on either write or read. No other compiler seems to exhibit the problem, and nor did gfortran in mid-2009 when I used an experimental version of gfortran 4.4 or 4.3.

	The problem is quite possibly in record_handler.F90: A simple code to write very large direct-access files works without a problem.		The problem is quite possibly in record_handler.F90: A simple code to write very large direct-access files works without a problem. [[CamCASP/CodeExamples/DirectAccess \| Here]] is a copy of the code.

	===Compiling on Mac OS X===		===Compiling on Mac OS X===