cclib-devel

[cclib-devel] Release of cclib 0.6b

[Noel O'B. <noe...@ma...>]

Dear all

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 b=
ug,
as there's no way to forget about it once there's a failing test. Once al=
l
tests on the released parsers pass, another release will follow.

Regards,
   Noel

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

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
>

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

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

I've had a quick look at this...

1) as you say, there's nothing to do here really...a warning message is
fine.
2) I would tend to go for the more 'right' solution, which you say is B.
This seems also to be the simpler solution (in terms of logic, not
necessarily implementation). However, since you are likely to be doing the
implementation you may want to reconsider. In either case, since as you say
the fix is a bit convoluted, it's probably best to create a function where
you pass in a label, and it returns something or other. This will also make
it easier to doctest (see normalisesym()). To run the doctests, you just
need to run "python adfparser.py".

P.S. The gmail/SF issue appears to be resolved.

Noel

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
>

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

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

> 2) I would tend to go for the more 'right' solution, which you say  
> is B. This seems also to be the simpler solution (in terms of  
> logic, not necessarily implementation). However, since you are  
> likely to be doing the implementation you may want to reconsider.  
> In either case, since as you say the fix is a bit convoluted, it's  
> probably best to create a function where you pass in a label, and  
> it returns something or other. This will also make it easier to  
> doctest (see normalisesym()). To run the doctests, you just need to  
> run "python adfparser.py".

Done. Well mostly. When creating the symlist dictionary, it checks if  
it can be degenerate. If so, passes the label and repeat number to  
normalisedegenerates(). If label is P or D, look up in dictionary  
{'P': {0:"P:x", 1:"P:y",...}, 'D': {0:"D:z2", 1:"D:x2-y2"...}}.  
Otherwise, return label + number. The doctest string may need work  
because I just altered what I found easy, and deleted the rest. ;o)

This means that regression.py now has only one error, which we  
decided was ok because it prints an acceptable error message. Should  
we consider removing it from the regression because of this?

I'm not sure what the one failure in the gaussian parser is due to,  
but I'll look into it in the coming days.

> P.S. The gmail/SF issue appears to be resolved.

Glad to hear.

Adam