cclib-devel Mailing List for cclib

> Thanks for the link! Unfortunately, cclib's makeopenbabel (version
> 0.6) doesn't like it so much. I managed to get pyopenbabel installed
> by checking out revision 1593 of the openbabel svn and altering the
> setup.py file to only install pyopenbabel. Unfortunately, it doesn't
> like _openbabel.OBAtom_SetVector(*args). Do you have any insight into
> this?! My guess is I could make it use the SetVector(double, double,
> double).

First of all, makeopenbabel has needed some attention for some time
now. The first thing I did is remove the dependency on pyopenbabel, so
that it just requires the open babel module.

Secondly, there was some weird Numeric stuff going on that caused me
to tear my hair out for a while. SetVector was working with (1.0, 1.0,
1.0) but choking on (coords[0], coords[1], coords[2]). It only
accepted the latter when I converted coords to a list using
coords.tolist(). I still don't know why :-/ I think this code used to
work...it's time for a test routine that runs the doctests, I think.

In short, it should be fixed now.

> Also, it doesn't look like you've tagged cclib 0.6.1. How's that
> coming along?
Sorry - it has been  tagged and released but not publicised (I kind of
ran out of steam, after rushing out the bug fix). I guess you looked
at the instructions page and didn't see anything written there. I
stopped updating that as I feel more confident using log messages to
keep track of what's been merged/branched/etc.

I'll send around a publicity email asap.

BTW, regarding branches - I'm thinking of creating separate branches
for parsers under development. This will cut down on the error
messages we get when we run the tests on the trunk (too many errors
and the tests become meaningless); and also avoid the mistakes I made
when when creating the 0.6 release. Any thoughts?

Noel

Remember that a dictionary doesn't have an explicit ordering, so if
you need ordering a list of fragments is better than a dictionary of
fragments. Apart from that, it sounds fine. 'frags' sounds good also,
although it does remind me of Quake.

I wonder though whether, in the end, reading the equivalent of a
checkpoint file would be a more sensible solution. There is a limit to
how complicated the output file can be while still being parsable.
Since you are likely to be doing the coding, you may want to think
about this long and hard, but it's up to you.

Noel

On 28/11/06, Adam Tenderholt <a-t...@st...> wrote:
> So I think there's another ADF bug. In the dvb_sp.adfout file, the
> atom number in fonames doesn't agree with the atom number in
> atomcoords. As near as I can tell, this is because ADF reorders the
> atoms. This is seen near the GEOMETRY section. The next section is
> FRAGMENTS, and there's not an obvious 1 to 1 mapping between the
> fragment names (also element names) and atoms in the fragment.
>
> As I recall, ADF is the only program that does fragment orbitals
> involving combinations of atomic orbitals. If this is the case, I
> propose we create a dictionary (say 'fragments') to store information
> about which fragment contains which atoms. The value of the
> dictionary is simply a tuple of atomic numbers and atomic coords. I
> propose a dictionary simply because it would make accessing the info
> for a specific fragment easier.
>
> What do you think?
>
> Adam
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

So I think there's another ADF bug. In the dvb_sp.adfout file, the  
atom number in fonames doesn't agree with the atom number in  
atomcoords. As near as I can tell, this is because ADF reorders the  
atoms. This is seen near the GEOMETRY section. The next section is  
FRAGMENTS, and there's not an obvious 1 to 1 mapping between the  
fragment names (also element names) and atoms in the fragment.

As I recall, ADF is the only program that does fragment orbitals  
involving combinations of atomic orbitals. If this is the case, I  
propose we create a dictionary (say 'fragments') to store information  
about which fragment contains which atoms. The value of the  
dictionary is simply a tuple of atomic numbers and atomic coords. I  
propose a dictionary simply because it would make accessing the info  
for a specific fragment easier.

What do you think?

Adam

Well, they're not really coordinates are they, they are delta
coordinates, if you know what I mean. But I see what you mean; vibcart
gives the impression it's coordinates too.

I was also thinking about vibdisp, i.e. vibrational displacement
vectors. Or even vibvects. Maybe one of these is better. What do you
think?

BTW, it's done for GAMESS now too, and I've added testvib.py, to do a
single test of the dimensions. I need to remove the 6 rotations and
translations (i.e. 3N-6) from the list of vibrations for GAMESS,
though.

Noel

On 27/11/06, Adam Tenderholt <a-t...@st...> wrote:
> > Absolutely...it's been on things-to-do for some time...why don't we
> > actually do it? I've started the balling rolling with extracting the
> > 'vibcarts' for Gaussian, plus the wiki entries.
>
> Is there a reason you chose 'vibcarts'? I would have thought
> 'vibcoords' would make more sense as we have 'atomcoords'? Just a
> thought....
>
> Adam
>
>

> Absolutely...it's been on things-to-do for some time...why don't we
> actually do it? I've started the balling rolling with extracting the
> 'vibcarts' for Gaussian, plus the wiki entries.

Is there a reason you chose 'vibcarts'? I would have thought  
'vibcoords' would make more sense as we have 'atomcoords'? Just a  
thought....

Adam

Do we have any plans on parsing the displacement vectors for  
frequency, IR, or Raman calculations? I've recently added some pretty  
interesting stuff to PyMOlyze, and adding support to visualize the  
motions at each frequency would probably be quite simple if this  
information were in cclib.

Adam

I hate reverting stuff, but it's not until you try something out that
you know for sure whether it's a good idea or not. If I was a real SVN
guru, I should be able to think 10 revisions ahead (like those chess
masters). :-)

Have a nice holiday. I'll try and get some of this stuff sorted out
over the next while.

Noel

On 22/11/06, Adam Tenderholt <a-t...@st...> wrote:
> > In your original email below, you say that Jaguar doesn't always have
> > the same number of alpha orbitals as beta orbitals. I think you mean
> > that it doesn't print information on the same number of alpha orbitals
> > as beta orbitals. Just like GAMESS-UK, then, I think - they actually
> > have the same number of alpha and beta orbitals, but just the
> > information on them isn't there (this is speculation, but it is
> > certainly true for other programs).
>
> You are correct: in Jaguar, there are always the same number of alpha
> orbitals as beta orbitals. However, it doesn't always print the same
> number, esp if the ipvert=X option is enabled. In this case, it only
> prints X virtual orbitals which means that if homos[0] != homos[1]
> we'll get a different amount of information for the alpha orbitals
> compared to the beta orbitals.
>
> > If what I say is true, then I don't think it helps to redefine nmo as
> > the orbitals for which there is information in the log file. Instead,
> > we should just relax the constraint that len(moenergies)==nmo, and
> > that len(mocoeffs)==nmo. Instead, len(moenergies) is the number of MOs
> > on which we have M.O. energies, and len(mocoeffs) is the number of MOs
> > for which we have mocoeffs. For unrestricted calcs, we should perhaps
> > move to a list of rank 2 arrays for mocoeffs, which can be of
> > different sizes depending on how orbitals are described in the log
> > file: mocoeff = [ alphamocoeffs, betamocoeffs ].
>
> I would definitely support mocoeffs being a list of rank 2 arrays to
> address the fact that alphamocoeffs and betamocoeffs could be
> different sizes. I think it also means that we should change
> moenergies to reflect something similar (list of rank 1 arrays).
>
> > Overall, what I'm trying to say, is that we are ending up redefining
> > nmo to give a value which we can already find by looking at
> > len(moenergies) or len(mocoeffs). And now that we realise that for
> > GAMESS-UK these values are not always equal to each other, it makes
> > less sense than ever.
>
> I agree with you here. My original suggestion was made because
> alphamocoeffs and betamocoeffs would be different sizes, so i figured
> it was just easier to make the mocoeffs matrix as large as nbasis x
> nbasis, and adjust nmo so that we know which coefficients are "real".
>
> > We've both done some work on this already, but I'm worried that we're
> > following red herrings. I think we can solve the Jaguar problem
> > without doing this. Would the modifications I suggest be sufficient to
> > handle Jaguar files?
>
> In summary, yes, I think we can revert nmo back to it's original
> definition if we change the definition of mocoeffs and moenergies as
> outlined above. Since your the SVN guru, will you revert the nmo
> changes back?
>
> Adam
>
> P.S. I'm on holiday for the next few days without internet.
>
>

> In your original email below, you say that Jaguar doesn't always have
> the same number of alpha orbitals as beta orbitals. I think you mean
> that it doesn't print information on the same number of alpha orbitals
> as beta orbitals. Just like GAMESS-UK, then, I think - they actually
> have the same number of alpha and beta orbitals, but just the
> information on them isn't there (this is speculation, but it is
> certainly true for other programs).

You are correct: in Jaguar, there are always the same number of alpha  
orbitals as beta orbitals. However, it doesn't always print the same  
number, esp if the ipvert=X option is enabled. In this case, it only  
prints X virtual orbitals which means that if homos[0] != homos[1]  
we'll get a different amount of information for the alpha orbitals  
compared to the beta orbitals.

> If what I say is true, then I don't think it helps to redefine nmo as
> the orbitals for which there is information in the log file. Instead,
> we should just relax the constraint that len(moenergies)==nmo, and
> that len(mocoeffs)==nmo. Instead, len(moenergies) is the number of MOs
> on which we have M.O. energies, and len(mocoeffs) is the number of MOs
> for which we have mocoeffs. For unrestricted calcs, we should perhaps
> move to a list of rank 2 arrays for mocoeffs, which can be of
> different sizes depending on how orbitals are described in the log
> file: mocoeff = [ alphamocoeffs, betamocoeffs ].

I would definitely support mocoeffs being a list of rank 2 arrays to  
address the fact that alphamocoeffs and betamocoeffs could be  
different sizes. I think it also means that we should change  
moenergies to reflect something similar (list of rank 1 arrays).

> Overall, what I'm trying to say, is that we are ending up redefining
> nmo to give a value which we can already find by looking at
> len(moenergies) or len(mocoeffs). And now that we realise that for
> GAMESS-UK these values are not always equal to each other, it makes
> less sense than ever.

I agree with you here. My original suggestion was made because  
alphamocoeffs and betamocoeffs would be different sizes, so i figured  
it was just easier to make the mocoeffs matrix as large as nbasis x  
nbasis, and adjust nmo so that we know which coefficients are "real".

> We've both done some work on this already, but I'm worried that we're
> following red herrings. I think we can solve the Jaguar problem
> without doing this. Would the modifications I suggest be sufficient to
> handle Jaguar files?

In summary, yes, I think we can revert nmo back to it's original  
definition if we change the definition of mocoeffs and moenergies as  
outlined above. Since your the SVN guru, will you revert the nmo  
changes back?

Adam

P.S. I'm on holiday for the next few days without internet.

Adam,

I've been thinking about this a bit more and I feel that we've moved
too far from the original problem, especially now that it's becoming
less and less clear what the value of nmo should be in particular
cases.

In your original email below, you say that Jaguar doesn't always have
the same number of alpha orbitals as beta orbitals. I think you mean
that it doesn't print information on the same number of alpha orbitals
as beta orbitals. Just like GAMESS-UK, then, I think - they actually
have the same number of alpha and beta orbitals, but just the
information on them isn't there (this is speculation, but it is
certainly true for other programs).

If what I say is true, then I don't think it helps to redefine nmo as
the orbitals for which there is information in the log file. Instead,
we should just relax the constraint that len(moenergies)==nmo, and
that len(mocoeffs)==nmo. Instead, len(moenergies) is the number of MOs
on which we have M.O. energies, and len(mocoeffs) is the number of MOs
for which we have mocoeffs. For unrestricted calcs, we should perhaps
move to a list of rank 2 arrays for mocoeffs, which can be of
different sizes depending on how orbitals are described in the log
file: mocoeff = [ alphamocoeffs, betamocoeffs ].

Overall, what I'm trying to say, is that we are ending up redefining
nmo to give a value which we can already find by looking at
len(moenergies) or len(mocoeffs). And now that we realise that for
GAMESS-UK these values are not always equal to each other, it makes
less sense than ever.

We've both done some work on this already, but I'm worried that we're
following red herrings. I think we can solve the Jaguar problem
without doing this. Would the modifications I suggest be sufficient to
handle Jaguar files?

Noel

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.
> (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.)
>
> Adam
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

It seems to be working for csjacky (the user who reported the bug)
now. I've created a new release, which is now up on SF (includes two
bug fixes to gaussian parser). I'll update the other distribution
sites today or tomorrow.

Noel

On 21/11/06, Noel O'Boyle <bao...@gm...> wrote:
> Yes - I've caught the Jaguar one now too. All unit tests and
> regression tests now pass (the latter also needed editing to remove a
> reference to Jaguar). I can't believe I missed all of this.
>
> I will send a prerelease to the user as you suggest. But I need to
> take some more time to update the Changelog, as I think I merged
> another bug fix for G03 since 0.6.
>
> The new openlogfile() command uses the extension of the log file to
> determine whether it is a .zip, .bz, .gz or none of the above. I'm not
> sure why the code failed though...even if a filename is passed which
> doesn't have an extension it should still work.
>
> What does this give on your system?
> >>> import os.path
> >>> os.path.splitext("base.ext")
> ('base', '.ext')
> >>> os.path.splitext("base")
> ('base', '')
> >>> "base.ext".rfind(".")
> 4
> >>> "base".rfind(".")
> -1
>
> Was there something strange about the filename you used?
>
> It says "AttributeError: rfind" in your message below. This implies
> that a string was not passed to splitext (I've just been looking at
> the source code...it's only a four line function or so), since all
> strings should have the .rfind() method. How did you call this method?
>
> Noel
>
> On 21/11/06, Adam Tenderholt <a-t...@st...> wrote:
> > > Looks like I messed up making the 0.6 release...I forgot to remove two
> > > references to the molproparser.
> >
> > Did you get the references to jaguarparser as well? I ran into that
> > problem when I removed cclib and tried reinstalling 0.6.
> >
> > Also, I'm having problems with trunk. Looks like it has to do with
> > utils.py and your new extension framework for detecting zipped files,
> > although I'm not positive since ccget seems to be working just fine.
> >
> >    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> > python2.4/site-packages/pymolyze/pymolyze.py", line 128, in open
> >      parser=ccopen(filename,progress,logging.ERROR)
> >    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> > python2.4/site-packages/cclib/parser/utils.py", line 50, in ccopen
> >      inputfile = openlogfile(filename)
> >    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> > python2.4/site-packages/cclib/parser/utils.py", line 29, in openlogfile
> >      extension = os.path.splitext(filename)[1]
> >    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> > python2.4/posixpath.py", line 92, in splitext
> >      i = p.rfind('.')
> > AttributeError: rfind
> >
> > > Of course, it worked for me because molparser.py *is* present on my
> > > system -- I need to uninstall old versions of cclib in future before
> > > trusting that they're fixed. I'd like to get the fix out as soon as
> > > possible, but I'm running short on time today, and I know that I won't
> > > have much time tomorrow. As well as this, I want to make *sure* this
> > > time that everything is fine, so I'm not going to rush out a version.
> >
> > Sounds good to me, although you probably should push a pre-released
> > version to the user who reported this bug as soon as possible so that
> > he can continue working with cclib---I'm guessing this is a
> > relatively minor problem.
> >
> > Adam
> >
> >
> >
>

Yes - I've caught the Jaguar one now too. All unit tests and
regression tests now pass (the latter also needed editing to remove a
reference to Jaguar). I can't believe I missed all of this.

I will send a prerelease to the user as you suggest. But I need to
take some more time to update the Changelog, as I think I merged
another bug fix for G03 since 0.6.

The new openlogfile() command uses the extension of the log file to
determine whether it is a .zip, .bz, .gz or none of the above. I'm not
sure why the code failed though...even if a filename is passed which
doesn't have an extension it should still work.

What does this give on your system?
>>> import os.path
>>> os.path.splitext("base.ext")
('base', '.ext')
>>> os.path.splitext("base")
('base', '')
>>> "base.ext".rfind(".")
4
>>> "base".rfind(".")
-1

Was there something strange about the filename you used?

It says "AttributeError: rfind" in your message below. This implies
that a string was not passed to splitext (I've just been looking at
the source code...it's only a four line function or so), since all
strings should have the .rfind() method. How did you call this method?

Noel

On 21/11/06, Adam Tenderholt <a-t...@st...> wrote:
> > Looks like I messed up making the 0.6 release...I forgot to remove two
> > references to the molproparser.
>
> Did you get the references to jaguarparser as well? I ran into that
> problem when I removed cclib and tried reinstalling 0.6.
>
> Also, I'm having problems with trunk. Looks like it has to do with
> utils.py and your new extension framework for detecting zipped files,
> although I'm not positive since ccget seems to be working just fine.
>
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/pymolyze/pymolyze.py", line 128, in open
>      parser=ccopen(filename,progress,logging.ERROR)
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/cclib/parser/utils.py", line 50, in ccopen
>      inputfile = openlogfile(filename)
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/cclib/parser/utils.py", line 29, in openlogfile
>      extension = os.path.splitext(filename)[1]
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/posixpath.py", line 92, in splitext
>      i = p.rfind('.')
> AttributeError: rfind
>
> > Of course, it worked for me because molparser.py *is* present on my
> > system -- I need to uninstall old versions of cclib in future before
> > trusting that they're fixed. I'd like to get the fix out as soon as
> > possible, but I'm running short on time today, and I know that I won't
> > have much time tomorrow. As well as this, I want to make *sure* this
> > time that everything is fine, so I'm not going to rush out a version.
>
> Sounds good to me, although you probably should push a pre-released
> version to the user who reported this bug as soon as possible so that
> he can continue working with cclib---I'm guessing this is a
> relatively minor problem.
>
> Adam
>
>
>

I just realized I completely misread the email you sent. This is a  
tough call because we really shouldn't say nmo is [60,60] because we  
don't have all that info for the mocoeffs but there are more  
information about moenergies and mosyms above [40,39]. My feeling is  
that nmo should correspond to the number that maximizes information  
(ie. in this case, [40,39]) and that we put a note on the wiki that  
there may be information up to nbasis, but we can't guarantee it's  
existence or accuracy.

Adam

On Nov 19, 2006, at 10:41 AM, Noel O'Boyle wrote:

> Hello Adam,
>
> I'm a bit unsure about what to do with the GAMESS-UK nmo's.
>
> For the unrestricted calculation (for example), there are 60 MOs, and
> there are moenergies and mosyms for all sixty alpha and beta.
>
> However, mocoeffs are only available for the 40 lowest alpha MOs, and
> the 39 lowest beta MOs (that is, by default it provides information on
> the occupied MOs and the 5 lowest unoccupied MOs).
>
> So, is nmo [60,60] or [40,39]? The current definition of nmo doesn't
> make this clear, so we'd better decide one way or another and refine
> the definition.
>
> Regards,
>  Noel

Hey Noel,

> So, is nmo [60,60] or [40,39]? The current definition of nmo doesn't
> make this clear, so we'd better decide one way or another and refine
> the definition.

In this case, nmo should be [40,39] since there are 40 alpha and 39  
beta orbitals. This will allow us to iterate over all of the orbital  
coefficients as follows:

for spin in range(2):

	for i in range(len(nmo[spin]):
		
		for j in range(nbasis):

			print "The coefficient of the %i basis function to the %ith  
molecular orbital of spin %i is %6.3f\"%(j, i, spin, mocoeffs[spin,i,j])


(Apologies for weird word-wrapping that may happen.)

Remember that mocoeffs should be size (1 or 2, nbasis, nbasis) and  
initially filled with zeros. Hope this helps,

Adam

	
>
> Regards,
>   Noel
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

Hello Adam,

I'm a bit unsure about what to do with the GAMESS-UK nmo's.

For the unrestricted calculation (for example), there are 60 MOs, and
there are moenergies and mosyms for all sixty alpha and beta.

However, mocoeffs are only available for the 40 lowest alpha MOs, and
the 39 lowest beta MOs (that is, by default it provides information on
the occupied MOs and the 5 lowest unoccupied MOs).

So, is nmo [60,60] or [40,39]? The current definition of nmo doesn't
make this clear, so we'd better decide one way or another and refine
the definition.

Regards,
  Noel

Hi Adam,

I've just seen that you've released the first version of PyMOlyze that
uses cclib. Congrats!

I've also noticed that cclib, GaussSum and PyMOlyze are all in a row
in the top 10 chemistry projects on sourceforge (or were yesterday).
This is a real case of open source cooperation and promotion of
interoperability leading to benefits above and beyond what we would
have had working on our own in parallel (buzzword alert: "synergy").
We all benefit from the same bug fixes in cclib. As well as that,
other users and programmers benefit in having access to the parsers
and algorithms that we use ourselves.

Three cheers for PyMOlyze, GaussSum and of course, cclib. :-)

Noel

I've just uploaded a small test file (water defined by a z-matrix with
keyword NOSYM) for the r400 bugfix, but it fails to parse on the
current HEAD due to some coreelectrons code looking for natom, which
isn't defined (but should be).

I'm checking in a regression.py with the failing test.

Noel

On 31/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?
> >
> > 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!).

OK - thanks for explaining this in depth - I actually had the wrong
idea. I thought we were going to split everything into two separate
arrays for alpha and beta, e.g. moenergies[0] and moenergies[1] which
would be of lengths nmo[0] and nmo[1] respectively (and similarly for
mocoeffs, mosyms and so on).

I'm happy to make the changes you suggest; I'll start by making some
changes to the wiki which you might doublecheck. I'll put the new
information on the attribute pages under a subheading like
"Development version" or "cclib 0.7" or something, to avoid confusing
users.

BTW, I've merged the zip branch to the HEAD and compressed the
regression files on the web server. See r402.

Regards,
   Noel