Re: [cclib-devel] Release of cclib 0.6b

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

> I've just made a release of cclib 0.6b. I was going to call it  
> cclib 0.6,
> but several regression tests fail. This is a very good way of  
> marking a bug,
> as there's no way to forget about it once there's a failing test.  
> Once all
> tests on the released parsers pass, another release will follow.

The two parser errors are in ADF files. The problems are as follows:

1) dvb_sp_c.adfout: moenergies isn't created because it is missing  
information for MOs 1-25. I'm not sure why this is the case because  
the only difference between its input file and that of dvb_sp.adfout  
is the additional "symmetry NOSYM" keyword.

2) mo_sp.adfout: during my symmetry > c1 changes, this apparently  
broke due to the "symlist" dictionary needed for sorting  
mocoefficents based on energy instead of symmetry. Just as E and T  
symmetry labels are looped through a few times, P, D, and F labels  
should also be looped through. This won't be a trivial fix because  
instead of setting up the symlist dictionary with E:1, E:2, etc.  
based on the number of times through the loop, smarter things will  
have to be added like P:x, P:y, D:z2, etc.

I don't think we should worry too much about problem #1 as there  
isn't enough info for us to parse in this case. However, we should  
probably identify an ADF keyword that fixes the problem and add it to  
the wiki. Problem #2 should be fixed, although I'm not sure of the  
best way. I can think of two ways...

A) Add P, D, and F to the multiple dictionary when MO info is being  
parsed. Also create a function that correctly translates P:x, P:y,  
D:xy, D:z2, etc. to something that matches the P:1, P:2, etc. which  
will be in the symlist dictionary when mocoeffs are parsed.

B) When MO info is being parsed, check for cases of P, D, and F and  
correctly create symlist dictionary keys P:x, P:y, D:z2, etc. No  
changes necessary for the part when mocoeffs are parsed.

While B is more "right" based on the actual names, I think  
implementing it will require more convoluted code than option A  
because of the checked needed to change P into P:x, P:y, P:z  
dictionary keys.

What do you think?

Adam