cclib-devel Mailing List for cclib

On Tue, 2006-06-27 at 10:16 -0700, Adam Tenderholt wrote:
> >> Sounds good. Should I still do that for the first logfile, or  
> >> shall  we just archive it?
> > Not sure what you mean by the first logfile.
> 
> The first ADF logfile I emailed to the gmail account. I fixed the  
> bug. Should I reply to my email there?

I think so. Just a line to say it's fixed in whatever revision. Does
this system make sense?

SF has a bug tracker, and an alternative system would be to send the log
files to the gmail account but log a bug in the bug tracker. This has a
system for adding comments and marking bugs as closed and so on. The
original poster gets notified of any changes in the bug status, and an
email gets sent to the developers list simultaneously. Also, every bug
has a number. Our SF ranking would increase and in addition, users can
see that we have a system for dealing with bugs, which is pretty
transparent. The downside is a slight overhead.

> >> Did you mean sourceforge? I thought the idea of using the gmail   
> >> account was have a way to share large data files....
> > It is, but sourceforge also is functionning as a bug tracker in  
> > this instance. It's good to be able to download all of the test  
> > files at once, e.g. for a new developer or for someone who wants  
> > some test files for their own program (e.g. open babel might use  
> > these eventually).
> >
> > In any case, I've discovered releaseforge.sourceforge.net which  
> > makes it a doodle to release files. So I just tar up everything and  
> > make a release every so often with the SVN revision name. Check out  
> > the SF download site in another 8 hours for the first release. You  
> > just unzip it at the 'top level' of the directory structure, and it  
> > makes all of the data folders for you (or overwrites them).
> 
> Ok.
Really - it's no problem. And I meant to say doddle not doodle. :-)

> 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

>> Sounds good. Should I still do that for the first logfile, or  
>> shall  we just archive it?
> Not sure what you mean by the first logfile.

The first ADF logfile I emailed to the gmail account. I fixed the  
bug. Should I reply to my email there?

>> Did you mean sourceforge? I thought the idea of using the gmail   
>> account was have a way to share large data files....
> It is, but sourceforge also is functionning as a bug tracker in  
> this instance. It's good to be able to download all of the test  
> files at once, e.g. for a new developer or for someone who wants  
> some test files for their own program (e.g. open babel might use  
> these eventually).
>
> In any case, I've discovered releaseforge.sourceforge.net which  
> makes it a doodle to release files. So I just tar up everything and  
> make a release every so often with the SVN revision name. Check out  
> the SF download site in another 8 hours for the first release. You  
> just unzip it at the 'top level' of the directory structure, and it  
> makes all of the data folders for you (or overwrites them).

Ok.

Adam

>> (2) Email it to ccl...@go... with the following info:
>> (a) What's the problem? "Breaks parser" is fine, if that's all that we
>> know already.
>> (b) What revision does it have a problem with.
>> (c) Where does the file come from, and confirm that it's public domain
>> [I think we only spoke briefly about this before, but I believe  
>> that we
>> need all test log files to be public domain...are you happy with this
>> for your log files?? I have already asked Joe Townsend, and the AOMIX
>> files are, by nature, public domain]
>> (d) Where will the file be stored in the repository (not sure is this
>> necessary)
>
>I'm definitely ok making any broken log files I make be public domain.
Great.

>> (3) The log message of the revision that fixes the problem should  
>> refer
>> to the name of the problem log file (as well as the usual info).
>> (4) Login to googlemail and reply to the original problem with the  
>> name
>> of the revision that fixes it. This lets us know at a glance (on
>> googlemail) whether a particular log file is still a problem.  
>> (Although
>> we should also know this from regression.py)
>
>Sounds good. Should I still do that for the first logfile, or shall  
>we just archive it?
Not sure what you mean by the first logfile.

>> Somewhere in all of this, preferably after (2), to add a regression  
>> test
>> to regression.py for the problem. This will let the other developer  
>> know
>> that there's a problem that needs to be fixed and also that they are
>> missing a test file in their local repository. I have already added  
>> some
>> broken parser tests for the 4 files in the test repository (haven't  
>> done
>> anything about that second ADF example of yours).
>
>Ok. If it just "breaks" the parser, can the regression just test for  
>completion of the parsing function?
Exactly. Let's keep it simple for these tests or we won't add tests as 
it'll be too much of a chore. If you look at what I've added already you'll 
see that the files that break the parsers are just parsed. For more 
complicated problems, we can be a bit more imaginative depending on the 
problem.

>> I will try to set up an automated procedure to make a .zip of all  
>> of the
>> data files in my local repository (excluding the basic ones), and send
>> it up to sourceforge. I think there are ways to do this, but it will
>> take some time.
>
>Did you mean sourceforge? I thought the idea of using the gmail  
>account was have a way to share large data files....
It is, but sourceforge also is functionning as a bug tracker in this 
instance. It's good to be able to download all of the test files at once, 
e.g. for a new developer or for someone who wants some test files for their 
own program (e.g. open babel might use these eventually).

In any case, I've discovered releaseforge.sourceforge.net which makes it a 
doodle to release files. So I just tar up everything and make a release 
every so often with the SVN revision name. Check out the SF download site 
in another 8 hours for the first release. You just unzip it at the 'top 
level' of the directory structure, and it makes all of the data folders for 
you (or overwrites them).

>> I'll wikify these instructions if they sound reasonable - please  
>> let me
>> know any further ideas.
>>
>> Oh yeah, could you send to google that Gaussian example you said there
>> was a problem with?
>
>If I can find it again, yep. ;o)
Great.
>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

> I've just been doing some tidying up of the tests. I've removed the
> so-called wild folders, and used our new Googlemail system instead.  
> Here
> are some proposed guidelines for dealing with new problem output  
> files:

Excellent

> (0) Give it a unique name (compared to others in the repository)
> (1) gzip it

Make sense. Sorry for not doing that to the first two I uploaded to  
gmail.

> (2) Email it to ccl...@go... with the following info:
> (a) What's the problem? "Breaks parser" is fine, if that's all that we
> know already.
> (b) What revision does it have a problem with.
> (c) Where does the file come from, and confirm that it's public domain
> [I think we only spoke briefly about this before, but I believe  
> that we
> need all test log files to be public domain...are you happy with this
> for your log files?? I have already asked Joe Townsend, and the AOMIX
> files are, by nature, public domain]
> (d) Where will the file be stored in the repository (not sure is this
> necessary)

I'm definitely ok making any broken log files I make be public domain.

> (3) The log message of the revision that fixes the problem should  
> refer
> to the name of the problem log file (as well as the usual info).
> (4) Login to googlemail and reply to the original problem with the  
> name
> of the revision that fixes it. This lets us know at a glance (on
> googlemail) whether a particular log file is still a problem.  
> (Although
> we should also know this from regression.py)

Sounds good. Should I still do that for the first logfile, or shall  
we just archive it?

> Somewhere in all of this, preferably after (2), to add a regression  
> test
> to regression.py for the problem. This will let the other developer  
> know
> that there's a problem that needs to be fixed and also that they are
> missing a test file in their local repository. I have already added  
> some
> broken parser tests for the 4 files in the test repository (haven't  
> done
> anything about that second ADF example of yours).

Ok. If it just "breaks" the parser, can the regression just test for  
completion of the parsing function?

> I will try to set up an automated procedure to make a .zip of all  
> of the
> data files in my local repository (excluding the basic ones), and send
> it up to sourceforge. I think there are ways to do this, but it will
> take some time.

Did you mean sourceforge? I thought the idea of using the gmail  
account was have a way to share large data files....

> I'll wikify these instructions if they sound reasonable - please  
> let me
> know any further ideas.
>
> Oh yeah, could you send to google that Gaussian example you said there
> was a problem with?

If I can find it again, yep. ;o)

Adam

I've just been doing some tidying up of the tests. I've removed the
so-called wild folders, and used our new Googlemail system instead. Here
are some proposed guidelines for dealing with new problem output files:

(0) Give it a unique name (compared to others in the repository)
(1) gzip it
(2) Email it to ccl...@go... with the following info:
(a) What's the problem? "Breaks parser" is fine, if that's all that we
know already.
(b) What revision does it have a problem with.
(c) Where does the file come from, and confirm that it's public domain
[I think we only spoke briefly about this before, but I believe that we
need all test log files to be public domain...are you happy with this
for your log files?? I have already asked Joe Townsend, and the AOMIX
files are, by nature, public domain]
(d) Where will the file be stored in the repository (not sure is this
necessary)
(3) The log message of the revision that fixes the problem should refer
to the name of the problem log file (as well as the usual info).
(4) Login to googlemail and reply to the original problem with the name
of the revision that fixes it. This lets us know at a glance (on
googlemail) whether a particular log file is still a problem. (Although
we should also know this from regression.py)

Somewhere in all of this, preferably after (2), to add a regression test
to regression.py for the problem. This will let the other developer know
that there's a problem that needs to be fixed and also that they are
missing a test file in their local repository. I have already added some
broken parser tests for the 4 files in the test repository (haven't done
anything about that second ADF example of yours).

I will try to set up an automated procedure to make a .zip of all of the
data files in my local repository (excluding the basic ones), and send
it up to sourceforge. I think there are ways to do this, but it will
take some time.

I'll wikify these instructions if they sound reasonable - please let me
know any further ideas.

Oh yeah, could you send to google that Gaussian example you said there
was a problem with?

Regards,
 Noel

On Wed, 2006-06-21 at 16:08 -0700, Adam Tenderholt wrote:
> > Well, I want to use whatever the standard method is. I create the
> > Windows distribution using standard disutils commands:
> > python setup.py sdist    (to create the .tar.gz for Linux)
> > python setup.py bdist_wininst (to create the windows installer)
> >
> > There's no option (at least with the distutils supplied in Linux) to
> > create a Mac installer. I would expect Mac users to just do as Linux
> > users do. I wouldn't worry about anything more.
> 
> I was thinking there was something like bdist_mpkg, but I guess I was  
> wrong. Maybe that's an option for setup.py when py2app is being used.  
> Do you know if the bdist option just byte-compiles the source for  
> that specific plaform? Just curious. Source distribution makes sense  
> as well for Mac since it's pretty easy to fire up a terminal and run  
> python setup.py install. I suspect anyone using cclib on the Mac is  
> going to be savvy enough to manage this step.

  sdist            create a source distribution (tarball, zip file, etc.)
  register         register the distribution with the Python package index
  bdist            create a built (binary) distribution
  bdist_dumb       create a "dumb" built distribution
  bdist_rpm        create an RPM distribution
  bdist_wininst    create an executable installer for MS Windows

The bdist_wininst installs the source as well as compiling on Windows.
The others I don't know anything about. There's also py2exe.

> > Sounds good. The more generic stuff you can put into cclib the better.
> > You should also take a look at Viewmol.
> 
> Viewmol looks promising, esp since it's GPL. That should mean there  
> isn't a problem adapting part of that code and including it in  
> PyMOlyze, provided I leave any copyright statements intact, right?

Ah...I wouldn't be so sure about that. So check it out at Groklaw or
whereever. I think the author would have no problem sharing code with
us/you if you asked nicely - I think he's very involved in OSS, although
not so active with Viewmol anymore.

> > That would be good, but maybe there are ways to do this that aren't
> > KDE-specific. e.g. some sort of python ssh library
> 
> Interesting point, although there are other uses of KIO-slaves like  
> the zip and gz. I can imagine that being somewhat useful if people  
> compress their files after analyzing them, and decide to take another  
> look.
Aha, but don't forget to think about using a python gzip library...it's
somewhere in the standard library, I think.

> > I recommend running ccget on every output file you can find. If you're
> > brave you could try:
> > ccget `find . | grep .out` which would run ccget on every .out file in
> > your directory structure (recursively). You'll soon find out if there
> > are any problems.
> 
> So all my Gaussian files except one worked ok. The one that didn't  
> threw a logging error, so I think it's probably a broken file. I can  
> upload it if you want.
> 
> ADF, unfortunately, had a lot of problems. Several of the files  
> didn't have any attributes to print, which I find odd because I'd  
> expect *something*. A few just completely crapped out with  
> IndexErrors or TypeErrors. Is there a limit to the filesizes we  
> should be uploading? Or should I just put it on a website somewhere  
> for you to access?
Ok, we're going to have to sort this out somehow. I think you're right
that we cannot be putting everything up on SVN. Here are some ideas.

In the short term, we need to share log files easily between us, and
keep track of what log files there are for testing, and write unit tests
for them. If we're not going to use SVN we need to use email, I guess;
we could share a gmail a/c between us, with log files as attachments and
the body explains what the bug is, and which SVN revision the bug occurs
with. We could integrate this with the bug tracker on SF in the medium
term, once we get bug submissions externally; in that case, the body of
the gmail email would only need to be a reference to the bug number.

Every so often we can make a release of example log files, basically a
tar.gz of the Data directory.

I'll send you the gmail account address and password off list.

Regards,
 Noel

> Adam
> 
> 
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel

> Well, I want to use whatever the standard method is. I create the
> Windows distribution using standard disutils commands:
> python setup.py sdist    (to create the .tar.gz for Linux)
> python setup.py bdist_wininst (to create the windows installer)
>
> There's no option (at least with the distutils supplied in Linux) to
> create a Mac installer. I would expect Mac users to just do as Linux
> users do. I wouldn't worry about anything more.

I was thinking there was something like bdist_mpkg, but I guess I was  
wrong. Maybe that's an option for setup.py when py2app is being used.  
Do you know if the bdist option just byte-compiles the source for  
that specific plaform? Just curious. Source distribution makes sense  
as well for Mac since it's pretty easy to fire up a terminal and run  
python setup.py install. I suspect anyone using cclib on the Mac is  
going to be savvy enough to manage this step.

> Sounds good. The more generic stuff you can put into cclib the better.
> You should also take a look at Viewmol.

Viewmol looks promising, esp since it's GPL. That should mean there  
isn't a problem adapting part of that code and including it in  
PyMOlyze, provided I leave any copyright statements intact, right?

> That would be good, but maybe there are ways to do this that aren't
> KDE-specific. e.g. some sort of python ssh library

Interesting point, although there are other uses of KIO-slaves like  
the zip and gz. I can imagine that being somewhat useful if people  
compress their files after analyzing them, and decide to take another  
look.

> There are no known bugs at the moment...right? So nothing to fix. I  
> can
> only think of new features, and they won't be going into cclib 0.5. I
> will probably continue to do some work on the Jaguar parser in  
> prep. for
> the next version, unless we find some bugs with the current parsers.
>
> I recommend running ccget on every output file you can find. If you're
> brave you could try:
> ccget `find . | grep .out` which would run ccget on every .out file in
> your directory structure (recursively). You'll soon find out if there
> are any problems.

So all my Gaussian files except one worked ok. The one that didn't  
threw a logging error, so I think it's probably a broken file. I can  
upload it if you want.

ADF, unfortunately, had a lot of problems. Several of the files  
didn't have any attributes to print, which I find odd because I'd  
expect *something*. A few just completely crapped out with  
IndexErrors or TypeErrors. Is there a limit to the filesizes we  
should be uploading? Or should I just put it on a website somewhere  
for you to access?

Adam

On Tue, 2006-06-20 at 09:08 -0700, Adam Tenderholt wrote:
> > What do you think about getting a final release of 0.5 out there?  
> > I'm on
> > holidays the first week of July, so we should either do it later this
> > week, first thing next week, or after I come back.
> 
> I haven't really worked on cclib recently, so unless you're really  
> anxious to get it out this week, I say we wait until you get back.  
> This will give both of us a bit of time to work on some of the points  
> below, and will allow me time to throw some more files I have at our  
> parsers to see if I can break them.

OK, DOK.

> > This release will be announced on the CCL, GAMESS users, and ADF users
> > lists, so we should be prepared for a large number of hits if nothing
> > else. I haven't received any feedback for any downloaders of the
> > software, and there have been a few if you look at the SF and  
> > cheeseshop
> > download pages.
> 
> What about the Gaussian lists?
Aha, but there's no such thing. Gaussian relies on the volunteer efforts
of Jan and co. at ccl.net to provide user-assisted support. In fact, as
you can see from http://www.ccl.net/cgi-bin/ccl/supporting_members they
have not even contributed to this effort. They could do a bit more to
combat their image as the Microsoft of quantum chemistry.

> I'm not sure I really expect a lot of  
> users since one needs to know be familiar with programming, and  
> chemists with such skills seem to be on the decline...at least that's  
> been my experience here so far. But I'm sure we'll have a handful of  
> really excited people.
Well, I think that would be really good.

> > The ChangeLog is basically some bug fixes to the parsers to deal with
> > AOMIXes examples. Internally, we're going to have changed license  
> > to the
> > LGPL, and the code will have some nice spacing. I need to add some  
> > more
> > stuff about necessary keywords to the wiki. Also, instead of a .zip
> > files for Windows, I will create a binary source distribution for
> > Windows (this is the usual way of distributing Python modules for
> > windows - allows uninstallation using Add/Remove Programs too).
> 
> Ok, sounds good. I can make a Mac OS X package if you want that as well.
Well, I want to use whatever the standard method is. I create the
Windows distribution using standard disutils commands:
python setup.py sdist    (to create the .tar.gz for Linux)
python setup.py bdist_wininst (to create the windows installer)

There's no option (at least with the distutils supplied in Linux) to
create a Mac installer. I would expect Mac users to just do as Linux
users do. I wouldn't worry about anything more.

> > Here's some things that are on my mind to do, not for 0.5final though:
> > 1. Replace the docstring at the start of every .py file with something
> > useful for people looking for information. Currently it's some GPL
> > stuff, which isn't very informative. The idea is that people who type:
> > "help(cclib.parser)" or whatever, find out something useful, not
> > licensing information. We can create documentation for users from  
> > this,
> > using pydoc -w, which creates a html pages with info, or we could cut
> > and paste into the wiki.
> 
> Right. I think we should maintain some license info such as a  
> copyright line and a licensed under the LGPL line with a link to the  
> GNU page. After that, i think we should definitely try and put some  
> more useful help in the docstring.
OK.

> > 2. Could we push the code for progress updating into a function of the
> > progress object? Going through the Gaussian parser for example, the  
> > same
> > code is duplicated in a number of places. In the interest of
> > maintainability, I think it'd be good to just call a method of a the
> > Progress object to update this info.
> 
> I think part of the reason for all of the code is that we wanted 1)  
> to check to make sure there was a progress object, and 2) not call it  
> every single time in the interest of speed. Most of the "actual" code  
> is in the update function of the progress class. We could probably  
> move step!=oldstep into the progress class, but we definitely need  
> the step = inputfile.tell().
Hmmm...I need to think some more about this, and play around with it a
bit...I'll put it on my list of things to think about eventually. :-)

> > 3. I've run out of good ideas, so here's a possibly bad one. Create
> > parsers for 3D surface information. This is actually pretty easy, and
> > would allow pymol for example to read in cube files/TAPE41 files (or
> > whatever) from different programs. It'd also be easy to create bridges
> > to other open source molecular visualisation software (e.g. MayaVi  
> > takes
> > Numeric arrays).
> 
> I actually this this is a good idea, mainly because at some point, I  
> want to create an awesome molden replacement with the following  
> characteristics (called PyMOlyze, since I already have most of part 2):
Sounds good. The more generic stuff you can put into cclib the better.
You should also take a look at Viewmol.

> 1) Easy to use z-matrix and cartesian coordinate editor. Chem3D isn't  
> bad for this, but it's ugly and not cross-platform or open source.
> 
> 2) Population analysis and bond orders
> 
> 3) Easy-to-use command-line interface for converting surfaces (and  
> maybe frequencies) to a povray file for easy rendering and animation.  
> (I currently have a script that isn't very intuitive that calls  
> molden, but it's way slow because it opens the Gaussian log file  
> everytime I want an orbital. That's either my lack-of-understanding  
> or a molden problem.)
> 
> 4) Monitor the progress of the calculation. This would be especially  
> useful if I add optional KDE-bindings that uses KIO-slaves....just  
> browse to the calc machine through FISH or SFTP, open the file, and  
> tada! no more middle step of copying to your computer first. And once  
> KDE is ported to windows and mac, I could completely switch to it  
> (unless it's a pain to build).
That would be good, but maybe there are ways to do this that aren't
KDE-specific. e.g. some sort of python ssh library
> > Oh yes, cclib has been accepted into the Free Software session at
> > CompLife06 http://www.inf.uni-konstanz.de/complife06/freesoft.html  
> > which
> > will be in Cambridge at the end of Sept. I'm not sure how  
> > interested the
> > attendees will be in the software, but there might be a few. There's
> > only 5 minutes to present the software, but 90 minutes of face-to-face
> > discussions afterwards along with all of the other software  
> > presenters.
> 
> Cool! Hopefully there will be some very interested people there.
> 
> Let me know what I should fix to get cclib ready for the release.
There are no known bugs at the moment...right? So nothing to fix. I can
only think of new features, and they won't be going into cclib 0.5. I
will probably continue to do some work on the Jaguar parser in prep. for
the next version, unless we find some bugs with the current parsers.

I recommend running ccget on every output file you can find. If you're
brave you could try:
ccget `find . | grep .out` which would run ccget on every .out file in
your directory structure (recursively). You'll soon find out if there
are any problems.

Noel

> What do you think about getting a final release of 0.5 out there?  
> I'm on
> holidays the first week of July, so we should either do it later this
> week, first thing next week, or after I come back.

I haven't really worked on cclib recently, so unless you're really  
anxious to get it out this week, I say we wait until you get back.  
This will give both of us a bit of time to work on some of the points  
below, and will allow me time to throw some more files I have at our  
parsers to see if I can break them.

> This release will be announced on the CCL, GAMESS users, and ADF users
> lists, so we should be prepared for a large number of hits if nothing
> else. I haven't received any feedback for any downloaders of the
> software, and there have been a few if you look at the SF and  
> cheeseshop
> download pages.

What about the Gaussian lists? I'm not sure I really expect a lot of  
users since one needs to know be familiar with programming, and  
chemists with such skills seem to be on the decline...at least that's  
been my experience here so far. But I'm sure we'll have a handful of  
really excited people.

> The ChangeLog is basically some bug fixes to the parsers to deal with
> AOMIXes examples. Internally, we're going to have changed license  
> to the
> LGPL, and the code will have some nice spacing. I need to add some  
> more
> stuff about necessary keywords to the wiki. Also, instead of a .zip
> files for Windows, I will create a binary source distribution for
> Windows (this is the usual way of distributing Python modules for
> windows - allows uninstallation using Add/Remove Programs too).

Ok, sounds good. I can make a Mac OS X package if you want that as well.

> Here's some things that are on my mind to do, not for 0.5final though:
> 1. Replace the docstring at the start of every .py file with something
> useful for people looking for information. Currently it's some GPL
> stuff, which isn't very informative. The idea is that people who type:
> "help(cclib.parser)" or whatever, find out something useful, not
> licensing information. We can create documentation for users from  
> this,
> using pydoc -w, which creates a html pages with info, or we could cut
> and paste into the wiki.

Right. I think we should maintain some license info such as a  
copyright line and a licensed under the LGPL line with a link to the  
GNU page. After that, i think we should definitely try and put some  
more useful help in the docstring.

> 2. Could we push the code for progress updating into a function of the
> progress object? Going through the Gaussian parser for example, the  
> same
> code is duplicated in a number of places. In the interest of
> maintainability, I think it'd be good to just call a method of a the
> Progress object to update this info.

I think part of the reason for all of the code is that we wanted 1)  
to check to make sure there was a progress object, and 2) not call it  
every single time in the interest of speed. Most of the "actual" code  
is in the update function of the progress class. We could probably  
move step!=oldstep into the progress class, but we definitely need  
the step = inputfile.tell().

> 3. I've run out of good ideas, so here's a possibly bad one. Create
> parsers for 3D surface information. This is actually pretty easy, and
> would allow pymol for example to read in cube files/TAPE41 files (or
> whatever) from different programs. It'd also be easy to create bridges
> to other open source molecular visualisation software (e.g. MayaVi  
> takes
> Numeric arrays).

I actually this this is a good idea, mainly because at some point, I  
want to create an awesome molden replacement with the following  
characteristics (called PyMOlyze, since I already have most of part 2):

1) Easy to use z-matrix and cartesian coordinate editor. Chem3D isn't  
bad for this, but it's ugly and not cross-platform or open source.

2) Population analysis and bond orders

3) Easy-to-use command-line interface for converting surfaces (and  
maybe frequencies) to a povray file for easy rendering and animation.  
(I currently have a script that isn't very intuitive that calls  
molden, but it's way slow because it opens the Gaussian log file  
everytime I want an orbital. That's either my lack-of-understanding  
or a molden problem.)

4) Monitor the progress of the calculation. This would be especially  
useful if I add optional KDE-bindings that uses KIO-slaves....just  
browse to the calc machine through FISH or SFTP, open the file, and  
tada! no more middle step of copying to your computer first. And once  
KDE is ported to windows and mac, I could completely switch to it  
(unless it's a pain to build).

> Oh yes, cclib has been accepted into the Free Software session at
> CompLife06 http://www.inf.uni-konstanz.de/complife06/freesoft.html  
> which
> will be in Cambridge at the end of Sept. I'm not sure how  
> interested the
> attendees will be in the software, but there might be a few. There's
> only 5 minutes to present the software, but 90 minutes of face-to-face
> discussions afterwards along with all of the other software  
> presenters.

Cool! Hopefully there will be some very interested people there.

Let me know what I should fix to get cclib ready for the release.

Adam

Hello Adam,

What do you think about getting a final release of 0.5 out there? I'm on
holidays the first week of July, so we should either do it later this
week, first thing next week, or after I come back.

This release will be announced on the CCL, GAMESS users, and ADF users
lists, so we should be prepared for a large number of hits if nothing
else. I haven't received any feedback for any downloaders of the
software, and there have been a few if you look at the SF and cheeseshop
download pages.

The ChangeLog is basically some bug fixes to the parsers to deal with
AOMIXes examples. Internally, we're going to have changed license to the
LGPL, and the code will have some nice spacing. I need to add some more
stuff about necessary keywords to the wiki. Also, instead of a .zip
files for Windows, I will create a binary source distribution for
Windows (this is the usual way of distributing Python modules for
windows - allows uninstallation using Add/Remove Programs too).

Here's some things that are on my mind to do, not for 0.5final though:
1. Replace the docstring at the start of every .py file with something
useful for people looking for information. Currently it's some GPL
stuff, which isn't very informative. The idea is that people who type:
"help(cclib.parser)" or whatever, find out something useful, not
licensing information. We can create documentation for users from this,
using pydoc -w, which creates a html pages with info, or we could cut
and paste into the wiki.
2. Could we push the code for progress updating into a function of the
progress object? Going through the Gaussian parser for example, the same
code is duplicated in a number of places. In the interest of
maintainability, I think it'd be good to just call a method of a the
Progress object to update this info.
3. I've run out of good ideas, so here's a possibly bad one. Create
parsers for 3D surface information. This is actually pretty easy, and
would allow pymol for example to read in cube files/TAPE41 files (or
whatever) from different programs. It'd also be easy to create bridges
to other open source molecular visualisation software (e.g. MayaVi takes
Numeric arrays).

Oh yes, cclib has been accepted into the Free Software session at
CompLife06 http://www.inf.uni-konstanz.de/complife06/freesoft.html which
will be in Cambridge at the end of Sept. I'm not sure how interested the
attendees will be in the software, but there might be a few. There's
only 5 minutes to present the software, but 90 minutes of face-to-face
discussions afterwards along with all of the other software presenters.

Regards,
 Noel

On Jun 19 2006, Adam Tenderholt wrote:

>> You could interrogate the Qt version, and do different things  
>> depending
>> on the result, e.g.:
>>
>>>>> import qt
>>>>> qt.qVersion()
>> '3.3.4'
>>>>> qt.qVersion().split(".")
>> ['3', '3', '4']
>>
>> qVersion mightn't be the right one, there are also the following:
>>>>> [x for x in qt.__dict__.keys() if x.lower().find("version")>=0]
>> ['PYQT_VERSION_STR', 'QT_VERSION', 'qVersion', 'QT_VERSION_STR',
>> 'PYQT_VERSION']
>
>The problem with this approach is that the module names have changed  
>from qt (Qt 2/3) to PyQt4 (Qt4), and if one is already loaded, it  
>complains when the one tries to load the other. Do you know of an  
>easy way to query the loaded modules, or is dir going to be the  
>easiest way?

You can do this as follows:

import sys
'cclib' in sys.modules.keys() # False
import cclib
'cclib' in sys.modules.keys() # True

But how are you going to use this in practice? What's wrong with a:

try:
    import Qt4
except ImportError:
    try:
        import qt3
    except ImportError:
        pass

or something?

>Adam
>
>P.S. Glad to see you working on the pylint stuff. :o)
It's a bit of a drag, but it means that we'll be safe from the code police. 
They're everywhere now - sometimes I feel like I'm turning into one myself. 
:-)

>
>
>_______________________________________________
>cclib-devel mailing list
>ccl...@li...
>https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

I completely spaced out this thread until after I updated today...

> You could interrogate the Qt version, and do different things  
> depending
> on the result, e.g.:
>
>>>> import qt
>>>> qt.qVersion()
> '3.3.4'
>>>> qt.qVersion().split(".")
> ['3', '3', '4']
>
> qVersion mightn't be the right one, there are also the following:
>>>> [x for x in qt.__dict__.keys() if x.lower().find("version")>=0]
> ['PYQT_VERSION_STR', 'QT_VERSION', 'qVersion', 'QT_VERSION_STR',
> 'PYQT_VERSION']

The problem with this approach is that the module names have changed  
from qt (Qt 2/3) to PyQt4 (Qt4), and if one is already loaded, it  
complains when the one tries to load the other. Do you know of an  
easy way to query the loaded modules, or is dir going to be the  
easiest way?

Adam

P.S. Glad to see you working on the pylint stuff. :o)

I have been looking in more detail at our cheeseshop score, and the low
score (well, it's not too bad) is partly due to an absence of particular
folders (e.g. test/example/doc) and partly due to a low score for code
quality.

The code quality score is calculated by pylint. I was looking into this
yesterday, and today I put up on the wiki (at the end of the Development
page) the HTML output of pylint.

Some of the points are more serious than others (e.g. circular imports
(again!) vs code formatting styles) but I'd like to improve this score
over time, if possible. Not for the sake of it, but it's a way of unit
testing code consistency so that new developers will be able to navigate
around the code pretty easily. For example, I currently use spaces
around '=' in assignments, but not around '==' in expressions. Looking
at the style guidelines recently, I think I should be using spaces
around both. The Python style guidelines are outlined at
http://www.python.org/dev/peps/pep-0008/
which I guess is what pylint is supposed to be checking against.

Don't take the pylint results as being correct, by any means; but it
does seem to say some sensible things, and it'd be good to follow what's
regarded as best practice.

There's a link to pylint on the Development wiki page. There are a
couple of dependencies, but when installed you just type:
pylint --html=y cclib (from a location that does not include a folder
called cclib)

Regards,
  Noel

It's great to get the release out. It's both an exciting and nervous
time, although we should release that a Python parser for comp chem is a
pretty niche market so it's not like we will be overwhelmed with
responses.

cclib is up on SF, Freshmeat and PyPI. I've also emailed GaussSum users
and PyMol users, so we'll see what happens. As we discussed, we'll leave
the CCL list alone until the final 0.5 release.

I've adapted ccget to accept multiple filenames - it's a good way of
testing whether a file is parsed correctly. I tried it on a pile of
GAMESS outputs from a colleague here. It turns out that he uses an older
version of GAMESS so it broke. The usage is something like (I've just
realised that I need to update the usage instructions that ccget prints
out):
	ccget *.log
or if you want to look at a particular attribute(s):
	ccget homos *.log

We need to put in place a system for regression tests for future
breakings of the parser. We already need to include some of the AOMIX
stuff.

I decided not to include the data files in the release - after all, they
are mainly for development and testing purposes. This frees us from
worrying too much about the size of log files. Instead we will include
some example files that the tutorial will work through. I think this
makes more sense.

Regards,
  Noel

cclib 0.5b is now available for download from http://cclib.sf.net.

cclib is an open source library, written in Python, for parsing and
interpreting
the results of computational chemistry packages. It currently parses
output
files from ADF, GAMESS (US), Gaussian, and PC GAMESS. (Support for
Jaguar and
GAMESS UK is being added.)

Among other data, cclib extracts:

    * coordinates
    * atomic orbital information
    * molecular orbital information
    * information on vibrational modes
    * the results of a TD-DFT calculation

(For a complete list see
http://cclib.sf.net/wiki/index.php/Parsed_Data).

cclib also provides some calculation methods for interpreting some
electronic
properties of molecules using analyses such as:

    * Mulliken population analysis
    * Overlap population analysis
    * Calculation of Mayer's bond orders.

For information on how to use cclib, see
      http://cclib.sf.net/wiki/index.php/Using_cclib.

If you need help, find a bug, want new features or have any questions,
please
send an email to our mailing list:
        https://lists.sourceforge.net/lists/listinfo/cclib-users

Regards,

 The cclib development team

> I think that is a great idea. Let me know if you find anything on  
> wiki I should add or update.
I've been getting the announcement email ready and the installation
instructions - you might take a look:
http://cclib.sourceforge.net/wiki/index.php/Announce
http://cclib.sourceforge.net/wiki/index.php/Install
(these are mirrored by ANNOUNCE and INSTALL in the distribution)

Also, we need to add to each of the specifications pages, what keywords
are required for particular packages in order that the log file contains
the right info. E.g. for Gaussian to contain scfvalues, you need to use
#p or something, and this should be on the scfvalue page. This info is
missing across the board, so we should both do a bit on that.

BTW, Do you want to put a hyperlink behind your name on the main cclib
page? Also, do you think our names should be included in the cclib
announcement email?

> Also, have you incorporated it into GaussSum yet? I've begun porting  
> PyMOlyze to Qt4 which is taking a bit longer than I anticipated, and  
> then I'll make it use cclib.
I'm aiming for GaussSum/cclib usability by the next version of cclib,
which I'd hope would be within a month of cclib 0.5 final. I'm taking
the opportunity to do some much needed surgery on the GaussSum code, but
there are entrails all over the place at the moment. :-)

>  Which reminds me: I need to figure out a  
> way to check whether Qt4 or another qt is loaded because the current  
> QtProgress class in cclib.progress gives me errors when I try to use  
> Qt4. Alternatively, we remove it and post the code to the wiki, or I  
> port it to Qt4. What do you think?
You could interrogate the Qt version, and do different things depending
on the result, e.g.:

>>> import qt
>>> qt.qVersion()
'3.3.4'
>>> qt.qVersion().split(".")
['3', '3', '4']

qVersion mightn't be the right one, there are also the following:
>>> [x for x in qt.__dict__.keys() if x.lower().find("version")>=0]
['PYQT_VERSION_STR', 'QT_VERSION', 'qVersion', 'QT_VERSION_STR',
'PYQT_VERSION']

I'm ready to put out a beta release tomorrow, so let me know if there's
anything that you think could be a show stopper. Yippee, almost there!

Noel

> In order to get the ball rolling on a release, while allowing us to  
> find
> any big bugs, I suggest putting out a beta release of 0.5,  
> particularly
> in the light of the problems we found parsing the AOMIX examples. This
> will not be announced on the CCL mailing list, but will be released
> through other low publicity channels: e.g. freshmeat, python  
> cheeseshop
> and I'm thinking of mentioning it to the 15 or so people on the  
> GaussSum
> mailing list.
>
> What do you think? This will allow us to move forward, and hopefully
> give us some feedback before the final release.

I think that is a great idea. Let me know if you find anything on  
wiki I should add or update.

Also, have you incorporated it into GaussSum yet? I've begun porting  
PyMOlyze to Qt4 which is taking a bit longer than I anticipated, and  
then I'll make it use cclib. Which reminds me: I need to figure out a  
way to check whether Qt4 or another qt is loaded because the current  
QtProgress class in cclib.progress gives me errors when I try to use  
Qt4. Alternatively, we remove it and post the code to the wiki, or I  
port it to Qt4. What do you think?

Adam

Dear Adam,

In order to get the ball rolling on a release, while allowing us to find
any big bugs, I suggest putting out a beta release of 0.5, particularly
in the light of the problems we found parsing the AOMIX examples. This
will not be announced on the CCL mailing list, but will be released
through other low publicity channels: e.g. freshmeat, python cheeseshop
and I'm thinking of mentioning it to the 15 or so people on the GaussSum
mailing list.

What do you think? This will allow us to move forward, and hopefully
give us some feedback before the final release.

Regards,
 Noel

Hey Adam,

Regarding openbabel on Windows - I'm afraid no-one has yet got it the 
Python bindings to work, although it compiles fine under Cygwin...I'm 
hoping that there will be more of a push to get it to work after compiling 
with the microsoft compiler, but I don't have time right now to chase this 
up.

In Linux, it works a treat, although I recommend the SVN version of 
openbabel, rather than the latest release, if you want to keep up. I've 
written pyopenbabel, which you can read about here: 
http://openbabel.sourceforge.net/wiki/PythonWrapper#The_pyopenbabel_module

>> ADF, again! Well, I think we gotta deal with this before releasing.
>> Probably right on the testing front though. Remember to upload any
>> examples files that break our parser (assuming there are in the public
>> domain??) with an SVN comment to say what it breaks. I'll check out  
>> the
>> other examples.
>
>Yeah, ADF is troublesome. I would have uploaded it yesterday, but  
>it's a 35 MB file and I figured that was too much. I suppose I could  
>look through it, and see if I can create a smaller file that  
>reproduces the error.

In fairness, both the GAMESS and the Gaussian example break our parsers 
too. :-( Have fixed the GAMESS one, which was pretty easy (who'd have 
thought that GAMESS would spell 'Si', 'SI' or that any random name can be 
used for atom names in the specification of coordinates - it's the atomic 
number that I should have parsed instead). The Gaussian one I was more 
concerned about, as I thought that nothing could break it. However, it 
seems that it was a Gaussian 98 file, and contains one less SCF target than 
Gaussian 03. I'll do that tomorrow...

Regards,
 Noel

>Adam
>
>
>
>
>_______________________________________________
>cclib-devel mailing list
>ccl...@li...
>https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

> Is the information in the wiki correct and up to date regarding the
> mocoeffs? The first index should refer to the MO, and the second to  
> the
> AO, right? Have you verified that the other parsers are doing this  
> also?

Aside from off-by-one errors in one of the description and leaving  
out beta in the other, it was in agreement with my understanding. I  
also updated the wiki. I've verified ADF and Gaussian by printing and  
visually comparing a few rows of the matrix, and GAMESS by comparing  
MPA results with those of ADF/Gaussian.

> I'm happy to release now. I think the parsers are of sufficient  
> quality
> that they are generally useful, and it would be good to get some
> feedback on what people would like. We are going to continue to find
> bugs, but I don't think this should stop us releasing.

Fine point, although I would like another day or so for some more  
testing, just to make sure there are no super-obvious problems.

> See my mail of May25 for more info. I think it's a good idea to  
> support
> other libraries since interoperability is kind of a theme with cclib,
> and it encourages reuse of algorithms. The script is just a simple
> script that will allow users to develop their own. It also is  
> useful to
> prove to users that the thing works in the first place.

Out of curiosity, how stable are the python bindings to openbabel? I  
remember trying to use them at my parents' place (Windows box) over  
Christmas break, but I didn't have much success.

>
> After running "python setup.py install" as root, you can just type:
>      ccget --list myfile.out
> and it will list the extracted information from myfile.out. In Linux,
> python installs scripts to /usr/bin (on my system) and chmods them to
> executable as well as changing the first line (#!) to point to the
> correct location of the python executable. It doesn't work so  
> nicely in
> Windows, but we can worry about that another day.

Sounds good.

> ADF, again! Well, I think we gotta deal with this before releasing.
> Probably right on the testing front though. Remember to upload any
> examples files that break our parser (assuming there are in the public
> domain??) with an SVN comment to say what it breaks. I'll check out  
> the
> other examples.

Yeah, ADF is troublesome. I would have uploaded it yesterday, but  
it's a 35 MB file and I figured that was too much. I suppose I could  
look through it, and see if I can create a smaller file that  
reproduces the error.

Adam

On Tue, 2006-06-06 at 16:30 -0700, Adam Tenderholt wrote:
> I've uploaded and worked on parsing the NOSYM and EPRINT ADF files.
Fantastic.
>  I  
> fixed a pretty major bug in the mocoeffs where the MOs and AOs (ie.  
> rows and columns) were switched. Hopefully this means the ADF parser  
> is more or less ready to go.
Is the information in the wiki correct and up to date regarding the
mocoeffs? The first index should refer to the MO, and the second to the
AO, right? Have you verified that the other parsers are doing this also?

> How's the progress on the other parsers for the 0.5 release coming?
I'm happy to release now. I think the parsers are of sufficient quality
that they are generally useful, and it would be good to get some
feedback on what people would like. We are going to continue to find
bugs, but I don't think this should stop us releasing.

>  I  
> also saw some scripts and bridges to other python libraries.
See my mail of May25 for more info. I think it's a good idea to support
other libraries since interoperability is kind of a theme with cclib,
and it encourages reuse of algorithms. The script is just a simple
script that will allow users to develop their own. It also is useful to
prove to users that the thing works in the first place.

After running "python setup.py install" as root, you can just type:
     ccget --list myfile.out
and it will list the extracted information from myfile.out. In Linux,
python installs scripts to /usr/bin (on my system) and chmods them to
executable as well as changing the first line (#!) to point to the
correct location of the python executable. It doesn't work so nicely in
Windows, but we can worry about that another day.

> Also, we may want to consider testing cclib on the AOMix example  
> files available at http://www.sg-chem.net. I know the ADF example  
> breaks it, but it should be a relatively easy fix.
ADF, again! Well, I think we gotta deal with this before releasing.
Probably right on the testing front though. Remember to upload any
examples files that break our parser (assuming there are in the public
domain??) with an SVN comment to say what it breaks. I'll check out the
other examples.

Regards,
  Noel

Dear Adam,

Hope the California sun is agreeing with you.

I've been going thru the wiki tidying things up. I was thinking about
moenergies and mosyms. Although I originally thought that we should
extract this data for every step of a geometry optimisation, I'm
thinking now that it'd probably be just as good to simply keep the final
moenergies and mosyms. This is partly laziness, but also the fact that
this information is not available by default for GAMESS calculations,
for example, which kind of leads me to think that nobody really wants
it.

This would mean that the description at
http://cclib.sourceforge.net/wiki/index.php/Moenergies
and
http://cclib.sourceforge.net/wiki/index.php/Mosyms
is correct, but that we may have to edit the parsers to make sure that
they don't append these data for every step of a geometry optimisation.

In short: for a completed geo-opt or single-pt calculation mosyms and
moenergies apply to the final step. For a partially complete geo-opt we
don't make any guarantees about what they contain.

What do you think? Sorry to be pedantic, but I'd like to sort this out
before completing the nice table at
http://cclib.sourceforge.net/wiki/index.php/Parsed_Data#Description_of_parsed_data

Regards,
  Noel

I've uploaded and worked on parsing the NOSYM and EPRINT ADF files. I  
fixed a pretty major bug in the mocoeffs where the MOs and AOs (ie.  
rows and columns) were switched. Hopefully this means the ADF parser  
is more or less ready to go.

How's the progress on the other parsers for the 0.5 release coming? I  
also saw some scripts and bridges to other python libraries.

Also, we may want to consider testing cclib on the AOMix example  
files available at http://www.sg-chem.net. I know the ADF example  
breaks it, but it should be a relatively easy fix.

Adam

Here is an example (frrom the CCL list) of a calculation with G03 that
has sigma, pi and delta orbital symmetries - I've never come across
these before in G03, so I'll try to reproduce this calculation, upload
it and make sure that the symmetry names are normalised.

Noel

-------- Forwarded Message --------
From: Yan Zhao yzhao(-)chem.umn.edu <own...@cc...>
Reply-To: CCL Subscribers <che...@cc...>
To: O'Boyle, Noel M -id#39c- <no...@ca...>
Subject: CCL:G: a question aboutTDDFT calculations with G03
Date: Thu, 1 Jun 2006 12:58:04 -0400
Sent to CCL by: Yan Zhao [yzhao-x-chem.umn.edu]
Dear CCLers,

 I have some problems with the TDDFT calculations in Gaussian03.
 I tried doing TDDFT calculations with G03 to test some functionals 
developed in our group. Since I am a beginner of using TDDFT, I did a 
calculation for the CO molecule with PBE0 functional  to reproduce the 
results in Adamo's JCP paper (JCP 111, 2889 (1999)). I can reproduce his 
results for almost all excited states except the highest Rydberg singlet 
state corresponding to the state with an experimental excitation energy 
of 12.4 ev.  In Adamo's paper, PBE0 gives 12.01 ev, but I can not 
extract this excitation energy from my G03 calculations. Moreover I 
failed to reproduce the HCTH and B3LYP results in Tozer and Handy's 
paper (JCP 109 10180 (1998)),  I also failed to reproduce the B97-2 
results in Teale and Tozer's recent paper (JCP 122, 034101 (2005)). They 
are using CADPAC, not G03.  Any suggestions are highly appreciated. The 
following are  my G03 input file and some output information.

Input
**************************************************
#pbe1pbe/6-311++g(d,p) TD=(50-50,Nstates=12) scf=(tight,xqc)

co pbe0

0  1
    C             0        0.000000    0.000000   -0.643075
    O             0        0.000000    0.000000    0.482306
**************************************************

Output
**************************************************
..............
 Orbital symmetries:
       Occupied  (SG) (SG) (SG) (SG) (PI) (PI) (SG)
       Virtual   (PI) (PI) (SG) (SG) (PI) (PI) (SG) (PI) (PI) (SG)
                 (SG) (PI) (PI) (SG) (SG) (SG) (PI) (PI) (DLTA)
                 (DLTA) (SG) (PI) (PI) (SG) (PI) (PI) (DLTA) (DLTA)
                 (SG) (PI) (PI) (SG) (PI) (PI) (SG) (SG) (SG)
    96 initial guesses have been made.
...............
...............

 Excited state symmetry could not be determined.
 Excited State  16:   Triplet-?Sym   11.2347 eV  110.36 nm  f=0.0000
       4 ->  9         0.10254
       7 -> 12         0.44192
       7 -> 13         0.52545
 
 Excited State  17:   Singlet-SG    11.3361 eV  109.37 nm  f=0.1947
       7 -> 11         0.69676
 
 Excited state symmetry could not be determined.
 Excited State  18:   Singlet-?Sym   11.4874 eV  107.93 nm  f=0.0508
       7 -> 12         0.24432
       7 -> 13         0.65817
 
 Excited state symmetry could not be determined.
 Excited State  19:   Singlet-?Sym   11.4874 eV  107.93 nm  f=0.0508
       7 -> 12         0.65817
       7 -> 13        -0.24432
 
 Excited state symmetry could not be determined.
 Excited State  20:   Triplet-?Sym   11.9391 eV  103.85 nm  f=0.0000
       4 ->  8         0.69457
       4 ->  9        -0.11693
       4 -> 12        -0.10390
       7 -> 12        -0.13267
 
 Excited state symmetry could not be determined.
 Excited State  21:   Triplet-?Sym   11.9391 eV  103.85 nm  f=0.0000
       4 ->  8         0.11693
       4 ->  9         0.69457
       4 -> 13        -0.10390
       7 -> 13        -0.13267
 
 Excited state symmetry could not be determined.
 Excited State  22:   Singlet-?Sym   13.1752 eV   94.10 nm  f=0.0665
       5 -> 10         0.69565
       6 -> 10        -0.10395
 
 Excited state symmetry could not be determined.
 Excited State  23:   Singlet-?Sym   13.1752 eV   94.10 nm  f=0.0665
       5 -> 10         0.10395
       6 -> 10         0.69565
 
 Excited state symmetry could not be determined.
 Excited State  24:   Singlet-?Sym   13.1819 eV   94.06 nm  f=0.2280
       4 -> 10        -0.13503
       5 ->  9         0.34048
       5 -> 13         0.22450
       6 ->  8         0.34048
       6 -> 12         0.22449
       7 -> 14        -0.23139

**************************************************



Yan Zhao
Department of Chemistry
University of Minnesota



-= This is automatically added to each message by the mailing script =-
To recover the email address of the author of the message, please change
the strange characters on the top line to the @ sign. You can also
look up the X-Original-From: line in the mail header.

E-mail to subscribers: CHE...@cc... or use:
      http://www.ccl.net/cgi-bin/ccl/send_ccl_message

E-mail to administrators: CHE...@cc... or use
      http://www.ccl.net/cgi-bin/ccl/send_ccl_message

Subscribe/Unsubscribe: 
      http://www.ccl.net/chemistry/sub_unsub.shtml

Before posting, check wait time at: http://www.ccl.net

Job: http://www.ccl.net/jobs 
Conferences: http://server.ccl.net/chemistry/announcements/conferences/

Search Messages: http://www.ccl.net/htdig  (login: ccl, Password: search)

If your mail bounces from CCL with 5.7.1 error, check:
      http://www.ccl.net/spammers.txt

RTFI: http://www.ccl.net/chemistry/aboutccl/instructions/

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+