CamCASP/ToDo - Revision history

import>Am592: /* CamCASP -- To Do */

2010-07-12T14:27:39Z

CamCASP -- To Do

← Older revision		Revision as of 14:27, 12 July 2010
Line 11:		Line 11:
	# Reduce [[ CamCASP/ToDo/Memory \| memory usage]] in the code (esp. DF objects).		# Reduce [[ CamCASP/ToDo/Memory \| memory usage]] in the code (esp. DF objects).
	# '''User's Guide''': It's not up-to-date, nor does it contain helpful information about more complex calculations!		# '''User's Guide''': It's not up-to-date, nor does it contain helpful information about more complex calculations!
	# The basis set parameters in parameter.f90 and gamint.F are not linked, but they should be.		# The basis set parameters in parameter.f90 and gamint.F are not linked, but they should be. DONE --[[User:am592\|alston]] 15:27, 12 July 2010 (BST)
	# Get Energy-Scan to read the grid directly from the energy.dat or overlap.dat files. It can read these files, but doesn't use the grid information for ''another'' scan.		# Get Energy-Scan to read the grid directly from the energy.dat or overlap.dat files. It can read these files, but doesn't use the grid information for ''another'' scan.
	# Make Overlap-Module flexible enough to skip dimer configurations for which the energy fields are zero or '----'.		# Make Overlap-Module flexible enough to skip dimer configurations for which the energy fields are zero or '----'.

import>Am592: /* CamCASP -- To Do */

2009-11-05T11:48:16Z

CamCASP -- To Do

← Older revision		Revision as of 11:48, 5 November 2009
Line 24:		Line 24:
	#: The simplest way to handle this is to set up a one-dimensional array col_base(j) with elements j(j-1)/2, and then a(i,j) maps to a_tri(i+col_base(j)) for j>i.		#: The simplest way to handle this is to set up a one-dimensional array col_base(j) with elements j(j-1)/2, and then a(i,j) maps to a_tri(i+col_base(j)) for j>i.
	# Casimir: the input file should introduce each site's polarizabilities by a line of the form "SITE <name> TYPE <type>". This will allow Casimir to produce the dispersion potential data in terms of types rather than site names, which is how Orient needs them. It will also result in a smaller file. If the cluster file doesn't mention types then "SITE <name> TYPE <name>" should be used.		# Casimir: the input file should introduce each site's polarizabilities by a line of the form "SITE <name> TYPE <type>". This will allow Casimir to produce the dispersion potential data in terms of types rather than site names, which is how Orient needs them. It will also result in a smaller file. If the cluster file doesn't mention types then "SITE <name> TYPE <name>" should be used.
			# Process: Potential BUG: first frequency index should be 0 for static polarizabilities. But I am not sure if this is consistent within the code. In particular, check the WRITE block.

import>Ajs1 at 13:50, 2 June 2009

2009-06-02T13:50:26Z

← Older revision		Revision as of 13:50, 2 June 2009
Line 23:		Line 23:
	# index_mapping.f90 contains integer array uptri_map(n,n) where n = number of orbitals. This array quickly gets very large indeed as n > 6000. So, using -O3 optimization results in all of this array being pre-computed and the camcasp binary grows to >100MB is size only because of this array!!! What can be done?		# index_mapping.f90 contains integer array uptri_map(n,n) where n = number of orbitals. This array quickly gets very large indeed as n > 6000. So, using -O3 optimization results in all of this array being pre-computed and the camcasp binary grows to >100MB is size only because of this array!!! What can be done?
	#: The simplest way to handle this is to set up a one-dimensional array col_base(j) with elements j(j-1)/2, and then a(i,j) maps to a_tri(i+col_base(j)) for j>i.		#: The simplest way to handle this is to set up a one-dimensional array col_base(j) with elements j(j-1)/2, and then a(i,j) maps to a_tri(i+col_base(j)) for j>i.
			# Casimir: the input file should introduce each site's polarizabilities by a line of the form "SITE <name> TYPE <type>". This will allow Casimir to produce the dispersion potential data in terms of types rather than site names, which is how Orient needs them. It will also result in a smaller file. If the cluster file doesn't mention types then "SITE <name> TYPE <name>" should be used.

import>Ajs1 at 11:52, 7 May 2009

2009-05-07T11:52:30Z

← Older revision		Revision as of 11:52, 7 May 2009
Line 22:		Line 22:
	# Third-order energies.		# Third-order energies.
	# index_mapping.f90 contains integer array uptri_map(n,n) where n = number of orbitals. This array quickly gets very large indeed as n > 6000. So, using -O3 optimization results in all of this array being pre-computed and the camcasp binary grows to >100MB is size only because of this array!!! What can be done?		# index_mapping.f90 contains integer array uptri_map(n,n) where n = number of orbitals. This array quickly gets very large indeed as n > 6000. So, using -O3 optimization results in all of this array being pre-computed and the camcasp binary grows to >100MB is size only because of this array!!! What can be done?
			#: The simplest way to handle this is to set up a one-dimensional array col_base(j) with elements j(j-1)/2, and then a(i,j) maps to a_tri(i+col_base(j)) for j>i.

import>Am592: /* CamCASP -- To Do */

2009-02-13T17:34:51Z

CamCASP -- To Do

← Older revision		Revision as of 17:34, 13 February 2009
Line 21:		Line 21:
	#:If they are ''omitted'' in mc+ or dc+ Dalton crashes in an obscure manner. If they are ''included'' in an mc or dc calculation, camcasp crashes in an obscure manner. Cluster needs to check for consistency and flag the error.		#:If they are ''omitted'' in mc+ or dc+ Dalton crashes in an obscure manner. If they are ''included'' in an mc or dc calculation, camcasp crashes in an obscure manner. Cluster needs to check for consistency and flag the error.
	# Third-order energies.		# Third-order energies.
			# index_mapping.f90 contains integer array uptri_map(n,n) where n = number of orbitals. This array quickly gets very large indeed as n > 6000. So, using -O3 optimization results in all of this array being pre-computed and the camcasp binary grows to >100MB is size only because of this array!!! What can be done?

import>Ajs1 at 10:25, 20 January 2009

2009-01-20T10:25:27Z

@@ Line 4: / Line 4: @@
 # Set up patch system for handling updates.
 # Make tests automatic using James' test code.
 # Take examples of energy scans etc. I have on my iLiad and put them here on the Wiki (and, eventually, in the ''User's Guide''.
@@ Line 14: / Line 15: @@
 # Make Overlap-Module flexible enough to skip dimer configurations for which the energy fields are zero or '----'.
 # Allow the number of MOs to be less than the basis size. This is essential when linear dependencies (at the SCF stage) require some MOs to be deleted. At present, we force all MOs to be retained, but this cannot work for large molecules, in fact, it doesn't work for benzene with the d-aug-cc-pVTZ basis. '''URGENT'''
-# Van der Waals radii. Here's a comment from Anthony:
+# Van der Waals radii.

import>Am592: /* CamCASP -- To Do */

2008-12-15T17:48:21Z

CamCASP -- To Do

← Older revision		Revision as of 17:48, 15 December 2008
Line 13:		Line 13:
	# Get Energy-Scan to read the grid directly from the energy.dat or overlap.dat files. It can read these files, but doesn't use the grid information for ''another'' scan.		# Get Energy-Scan to read the grid directly from the energy.dat or overlap.dat files. It can read these files, but doesn't use the grid information for ''another'' scan.
	# Make Overlap-Module flexible enough to skip dimer configurations for which the energy fields are zero or '----'.		# Make Overlap-Module flexible enough to skip dimer configurations for which the energy fields are zero or '----'.
			# Allow the number of MOs to be less than the basis size. This is essential when linear dependencies (at the SCF stage) require some MOs to be deleted. At present, we force all MOs to be retained, but this cannot work for large molecules, in fact, it doesn't work for benzene with the d-aug-cc-pVTZ basis. '''URGENT'''
	# Van der Waals radii. Here's a comment from Anthony:		# Van der Waals radii. Here's a comment from Anthony:
	<pre>		<pre>

import>Am592: /* CamCASP -- To Do */

2008-11-24T18:56:29Z

CamCASP -- To Do

← Older revision		Revision as of 18:56, 24 November 2008
Line 11:		Line 11:
	# '''User's Guide''': It's not up-to-date, nor does it contain helpful information about more complex calculations!		# '''User's Guide''': It's not up-to-date, nor does it contain helpful information about more complex calculations!
	# The basis set parameters in parameter.f90 and gamint.F are not linked, but they should be.		# The basis set parameters in parameter.f90 and gamint.F are not linked, but they should be.
			# Get Energy-Scan to read the grid directly from the energy.dat or overlap.dat files. It can read these files, but doesn't use the grid information for ''another'' scan.
			# Make Overlap-Module flexible enough to skip dimer configurations for which the energy fields are zero or '----'.
	# Van der Waals radii. Here's a comment from Anthony:		# Van der Waals radii. Here's a comment from Anthony:
	<pre>		<pre>

import>Am592: /* CamCASP -- To Do */

2008-11-18T13:51:11Z

CamCASP -- To Do

← Older revision		Revision as of 13:51, 18 November 2008
Line 10:		Line 10:
	# Reduce [[ CamCASP/ToDo/Memory \| memory usage]] in the code (esp. DF objects).		# Reduce [[ CamCASP/ToDo/Memory \| memory usage]] in the code (esp. DF objects).
	# '''User's Guide''': It's not up-to-date, nor does it contain helpful information about more complex calculations!		# '''User's Guide''': It's not up-to-date, nor does it contain helpful information about more complex calculations!
			# The basis set parameters in parameter.f90 and gamint.F are not linked, but they should be.
	# Van der Waals radii. Here's a comment from Anthony:		# Van der Waals radii. Here's a comment from Anthony:
	<pre>		<pre>

import>Am592: /* CamCASP -- To Do */

2008-11-13T11:24:54Z

CamCASP -- To Do

← Older revision		Revision as of 11:24, 13 November 2008
Line 9:		Line 9:
	# Reduce the time the code spends in [[ CamCASP/ToDo/diskIO \| disk I/O]].		# Reduce the time the code spends in [[ CamCASP/ToDo/diskIO \| disk I/O]].
	# Reduce [[ CamCASP/ToDo/Memory \| memory usage]] in the code (esp. DF objects).		# Reduce [[ CamCASP/ToDo/Memory \| memory usage]] in the code (esp. DF objects).
			# '''User's Guide''': It's not up-to-date, nor does it contain helpful information about more complex calculations!
			# Van der Waals radii. Here's a comment from Anthony:
			<pre>
			There is another issue that needs thinking about. The van der Waals radii are hard-wired into camcasp,
			but they're not always appropriate -- particularly for hydrogen-bonded H, where a value of zero is more
			appropriate. At present a random grid doesn't sample the hydrogen-bonded region properly. Orient deals
			with this by associating the radius with an atom type, and assigning a type to each atom. Camcasp could
			do something similar, taking the type from the atomic number by default but allowing a different type to
			be specified. Or maybe you can think of another way of handling it.
			</pre>