Re: [cclib-devel] nmo proposal

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

> 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.

I agree with coming back to this a bit later. The reason I bring it  
up now is one of my colleagues often only prints 15 or so virtual  
orbitals because of space reasons---she claims it causes Jaguar to  
crash, but I don't entirely believe her. This creates a problem  
because she often deals with S=2 or S=5/2 systems, so there will be  
an unequal number of alpha and beta orbitals. Let's postpone thinking  
about this for now, but I do think it is a (hopefully minor) change  
we should think about.

> 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:

I feel like I've just been catching up for the all the coding I  
didn't  do during the summer while you were working on the GAMESS  
parsers. :o)

> """
> 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?
> """

I've made the changes. If the file is missing any MO info, it fills  
moenergies with 99999 and mosyms with 'A'. It now passes the  
regression test, although I haven't fully checked whether mocoeffs  
are accurate. Let me know if there is anything else we should do.

Adam