Re: [cclib-devel] nmo proposal

[Noel O'B. <bao...@gm...>]

On 24/10/06, Adam Tenderholt <a-t...@st...> wrote:
> Some quantum chemistry programs (eg. Jaguar) don't always have the
> same number of alpha orbitals as beta orbitals. Therefore, I propose
> that we change nmo from an integer to a list of integers like
> mocoeffs currently is. This would also mean in these cases, mocoeffs
> should have dimension (1 or 2, nbasis, nbasis) as nmo should always
> be less than or equal to nbasis. Comments?

> If this change is agreed upon, then I say we implement this after the
> 0.6 release so as to keep merging bugfix changes easy; alternatively,
> we could create a 0.8 trunk where these changes can be made.

I would be reluctant to change things so much. I have had similar
issues with GAMESS-UK, and AFAIK there is a switch that can be passed
to Jaguar to make it print out all of the alpha and beta orbitals. Let
us come back to this a little later.


> (Speaking of which, is there a timeframe for the 0.6 release? The ADF
> errors have been fixed as near as I can tell so regression.py passes
> all of the tests and only errors on the one ADF file which is missing
> MO info.)

Indeed, I have to say "well done", Adam. You've put a lot of work into
squashing these bugs and I think we can count on fairly good coverage
of 'log file space', now. The timeframe is as soon as we figure out
what to do about the final error on the ADF file. Check out my email
of 12th Oct reproduced here:
"""
There is now only a single error in regression.py, which is the
problem 1 below. Can we avoid getting a parse error in this case by
refusing to create moenergies, or by filling MOs 1-25 with moenergies
of 9999 (i.e. to indicate a problem). I think that users should be
able to get the energies of the homo and lumo even though there is a
problem with the rest of them. What do you think?
"""

Once we sort this out (whatever way), I will make the final release.

Noel