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

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

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?

On 06/10/06, Adam Tenderholt <a-t...@st...> wrote:
> > 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
>
>
> -------------------------------------------------------------------------
> 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
>