Difference between revisions of "CamCASP/ToDo"
Jump to navigation
Jump to search
import>Am592 |
import>Ajs1 |
||
| Line 4: | Line 4: | ||
# Set up patch system for handling updates. |
# Set up patch system for handling updates. |
||
| + | #: Done but awaiting updated examples. |
||
# Make tests automatic using James' test code. |
# 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''. |
# 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 '----'. |
# 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''' |
# 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. |
+ | # 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. |
||
| − | There is another issue that needs thinking about. The van der Waals radii are hard-wired into camcasp, |
||
| + | # Midbond functions. |
||
| − | but they're not always appropriate -- particularly for hydrogen-bonded H, where a value of zero is more |
||
| + | #: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. |
||
| − | appropriate. At present a random grid doesn't sample the hydrogen-bonded region properly. Orient deals |
||
| + | # Third-order energies. |
||
| − | 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> |
||
Revision as of 11:25, 20 January 2009
CamCASP => To-Do list
CamCASP -- To Do
- Set up patch system for handling updates.
- Done but awaiting updated examples.
- 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.
- Calculate perturbation matrix - currently in polarizability.f90 - in integrals.f90. At present it still uses Cartesian GTOs.
- Reduce the time the code spends in disk I/O.
- Reduce 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!
- 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 '----'.
- 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:
- 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.
- 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.
- Third-order energies.