Re: [cclib-devel] nmo proposal

[Adam T. <a-t...@st...>]

>> 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?
>
> Sounds good, except that mocoeffs is *not* currently a list of
> integers. It's a rank 3 array.

Right. Which is why the size of the mocoeffs array should have  
dimension (1 or 2, nbasis, nbasis). Anything not assigned would be  
zero, and it's up to the user of cclib to decide what elements are  
valid based on nmo and nbasis (and spin). I think it's a safe  
assumption that the orbitals we know about run from zero to nmo (even  
in the one ADF case, I think mocoeffs was correct).

> So, how many attributes will we need to change?:
> (1) nmo

Change this to a list. In most cases we've seen, nmo[0] == nmo[1] but  
we're making this change to address the case when nmo[0] != nmo[1].

> (2) mocoeffs

See above.

> (3) moenergies

This should probably be a rank two array with size (1 or 2, nbasis)  
with unassigned elements 99999 like we did with the one ADF file.

> (4) mosyms (maybe, it's fine as it is though)

My guess is for most cases this is fine, although we may want to  
consider size (1 or 2, nbasis) and unassigned elements get A symmetry.

> So we need to...
> (1) update the wiki
> (2) update the unit tests/regression tests
> (3) add any extra tests we need to make sure we're obeying the wiki
> (4) change the code (let's just work off the HEAD revision).

Sounds good.

> And the best part is that I'll even do some of this myself, as I'll
> start to have a bit more free time after next Monday (yippee!).

:o)

Adam