CamCASP/ToDo

CamCASP => To-Do list

CamCASP -- To Do

1. Set up patch system for handling updates.

   Done but awaiting updated examples.

2. Make tests automatic using James' test code.
3. 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.
4. Calculate perturbation matrix - currently in polarizability.f90 - in integrals.f90. At present it still uses Cartesian GTOs.
5. Reduce the time the code spends in disk I/O.
6. Reduce memory usage in the code (esp. DF objects).
7. User's Guide: It's not up-to-date, nor does it contain helpful information about more complex calculations!
8. The basis set parameters in parameter.f90 and gamint.F are not linked, but they should be. DONE --alston 15:27, 12 July 2010 (BST)
9. 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.
10. Make Overlap-Module flexible enough to skip dimer configurations for which the energy fields are zero or '----'.
11. 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
12. Van der Waals radii.

    Here's a comment from Anthony:

    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.

13. Midbond functions.

    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.

14. Third-order energies.
15. 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.

16. 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.
17. 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.