[cclib-devel] Changes

[Noel O'B. <no...@ca...>]

Hello again Adam,

After some thinking, I've taken your suggestion and created a prerelease
branch for cclib-0.5. In this branch, I've removed all references to
Jaguar with the idea being that once all tests pass, it'll be ready for
release (don't worry, I will check with you beforehand).

Continue editing in the trunk, although it would be good if you avoided
major reorganisations at this point. I'm trying to pin down the final
failures in the tests, mainly relating the atomcoords (it's tricky as
the first/final geometries are often treated differently than the
others).

I'll merge the recent trunk changes into the branch, so whatever you do
between now and the release (which I hope will be mid week this week?)
will still be included in the final 0.5 release.

It seems that it is impossible to normalise aonames. For example, for
dvb_sp.out, Gaussian aonames is:
['C1_1S', 'C1_2S', 'C1_2PX', 'C1_2PY', 'C1_2PZ', etc.

but for C_bigbasis.out, Gaussian aonames is:
['C1_1S', 'C1_2S', 'C1_3S', 'C1_4S', 'C1_5S', 'C1_6PX', 'C1_6PY', 'C1_6PZ',

Notice the change from C1_nS to C1_nPX in the first case, but from C1_nS
to C1_(n+1)PX in the second case.

Since GAMESS does not provide the 'n' number, I've been trying to make
it up (see http://cclib.sourceforge.net/wiki/index.php/Aonames) but
since it will be impossible to make it agree with Gaussian (based on the
examples above) I propose to drop 'n' for GAMESS, rather than give a
misleading name for the atomic orbital. What does 'n' refer to anyway??

Regards,
 Noel