cclib-devel — Developer's mailing list

[cclib-devel] Final release of 0.5

[Noel O'B. <no...@ca...>]

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

Re: [cclib-devel] A beta release

[Dr N. O'B. <no...@ca...>]

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
>

Re: [cclib-devel] A beta release

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

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)

[cclib-devel] Removing the lint

[Noel O'B. <no...@ca...>]

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

[cclib-devel] Advertising

[Noel O'B. <no...@ca...>]

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-devel] ANN: cclib-0.5b released

[Noel O'B. <no...@ca...>]

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

Re: [cclib-devel] A beta release

[Noel O'B. <no...@ca...>]

> 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

Re: [cclib-devel] A beta release

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

> 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

[cclib-devel] A beta release

[Noel O'B. <no...@ca...>]

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

Re: [cclib-devel] Some progress

[Dr N. O'B. <no...@ca...>]

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
>

Re: [cclib-devel] Some progress

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

> 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

Re: [cclib-devel] Some progress

[Noel O'B. <no...@ca...>]

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

[cclib-devel] mosyms and moenergies

[Noel O'B. <no...@ca...>]

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

Re: [cclib-devel] Some progress

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

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

[cclib-devel] [Fwd: CCL:G: a question aboutTDDFT calculations with G03]

[Noel O'B. <no...@ca...>]

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/

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

Re: [cclib-devel] Some progress

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

> Hmmm...I see where you're coming from. I forgot that they would all be
> A, so there's no need for the whole list...but aren't the evalues
> printed there also? If so, we need the extra EPRINT info...

Oooh, good point. Should we try to make an array of the evalues if we  
only get a partial list? I'll run  a new single point and  
unrestricted calc for NOSYM and extra EPRINT info and upload it when  
it finished.

> Don't worry about it - real life comes first :-)
>
> By the way, I just got an answer back on the ADF SCF stuff - I'll  
> put it
> up on the wiki - it's more complicated than the manual says!

Ok.

Adam

Re: [cclib-devel] Some progress

[Noel O'B. <no...@ca...>]

On Mon, 2006-05-29 at 18:45 -0700, Adam Tenderholt wrote:
> > I'm currently working on the ADF problem. I think the solution  
> > might be yet
> > more keywords.
> >
> > You see, the problem is that we take the HOMO information from the  
> > section
> > which lists the energies of the all of the irreducible representations
> > together (and I cannot see any other decent option).
> 
> Sorry for not getting back last week. I was/am a bit busy.

> I just looked at this problem. What if we look for a line Symmetry:,  
> and if it's NOSYM, we set a flag to decide whether to get the homo  
> information from the Orbital Energies (per Irrep and Spin)? I can't  
> see why this wouldn't work, and it would keep us from requiring an  
> EPRINT option. If the flag is set, mosyms is,  by definition, just A  
> so we can create an appropriate sized list.

Hmmm...I see where you're coming from. I forgot that they would all be
A, so there's no need for the whole list...but aren't the evalues
printed there also? If so, we need the extra EPRINT info...

> > On a different note, we were discussed how to test the results. You  
> > may
> > want to compare your MPA results with the output from ADF, enabled  
> > by the
> > keywords described at:
> > http://www.scm.com/Doc/Doc2005.01/ADF/ADFUsersGuide/page164.html
> 
> I'll look into this. I don't have the time this week to work on  
> cclib, but we decided to push back the 0.5 release anyways, right?  
> Hopefully we can get it out mid-next week.

Don't worry about it - real life comes first :-)

By the way, I just got an answer back on the ADF SCF stuff - I'll put it
up on the wiki - it's more complicated than the manual says!

Regards,
 Noel

Re: [cclib-devel] Some progress

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

> I'm currently working on the ADF problem. I think the solution  
> might be yet
> more keywords.
>
> You see, the problem is that we take the HOMO information from the  
> section
> which lists the energies of the all of the irreducible representations
> together (and I cannot see any other decent option).

Sorry for not getting back last week. I was/am a bit busy.

I just looked at this problem. What if we look for a line Symmetry:,  
and if it's NOSYM, we set a flag to decide whether to get the homo  
information from the Orbital Energies (per Irrep and Spin)? I can't  
see why this wouldn't work, and it would keep us from requiring an  
EPRINT option. If the flag is set, mosyms is,  by definition, just A  
so we can create an appropriate sized list.

> On a different note, we were discussed how to test the results. You  
> may
> want to compare your MPA results with the output from ADF, enabled  
> by the
> keywords described at:
> http://www.scm.com/Doc/Doc2005.01/ADF/ADFUsersGuide/page164.html

I'll look into this. I don't have the time this week to work on  
cclib, but we decided to push back the 0.5 release anyways, right?  
Hopefully we can get it out mid-next week.

Adam

[cclib-devel] Some progress

[Dr N. O'B. <no...@ca...>]

I'm currently working on the ADF problem. I think the solution might be yet 
more keywords.

You see, the problem is that we take the HOMO information from the section 
which lists the energies of the all of the irreducible representations 
together (and I cannot see any other decent option).

However, for 'nosym' there is no such list - instead there is only the list 
of irreducible representations separately, in this case only 'A' on its 
own. This would be no problem, except that the default is to show only the 
10 highest occupied and 10 lowest unoccupied for each irreducible rep.

Our friend is the EPRINT keyword Eigval, described on: 
http://www.scm.com/Doc/Doc2005.01/ADF/ADFUsersGuide/page162.html. Try 
running dvb_sp_c.adfout again with:

eprint
 eigval 99999 99999
end

Hopefully, this will do the job.

On a different note, we were discussed how to test the results. You may 
want to compare your MPA results with the output from ADF, enabled by the 
keywords described at: 
http://www.scm.com/Doc/Doc2005.01/ADF/ADFUsersGuide/page164.html

Regards,
 Noel

[cclib-devel] Quick update

[Noel O'B. <no...@ca...>]

Oh yeah, I forgot to say - I've finally been issued with a username and
password for the Jaguar PC. So, eventually (i.e. next release) I can
sort that out.

Also, and more importantly as I was beginning to despair, Google finally
picks up on cclib - it's hit three on my PC.

Noel

[cclib-devel] Current status

[Noel O'B. <no...@ca...>]

Hey there Adam,

Looks like it'll be at least the weekend before this is all sorted, but
it's all good - we've made a lot of progress in the last few weeks and
we can be pretty confident in cclib once it's released.

There's a number of items that I've been thinking about adding to cclib,
that are pretty easy to do and would add some value, I think. I've made
some starts on them actually and want to know what you think of them in
general (I'm not crazy about adding them to this release, but wouldn't
mind them in the next one).

One is ccget.py, a simple script that uses cclib to extract information.
You pass it the name of an attribute and a file and it does the rest.
You can also get it to list the available attributes for a particular
file. This is on Subversion in src/scripts, I think.

Another general aim that would be nice would be to promote
interoperability with other Python chemistry libraries. I've already
written some code to make an OpenBabel molecule (which can be used to
create other file formats), and a BioPython.PDB set of Atoms given
atomcoords and atomnos (which can be used to find the rms of two
conformers from each other). Since one of the goals of cclib is to
promote 'interoperability' of algorithms for comp. chem. (e.g. your Pop
Analyses), I think this ties in nicely. I was thinking of putting these
into a cclib.bridge folder, i.e. forming a bridge between different
libraries.

Regards,
 Noel

Re: [cclib-devel] problems

[Dr N. O'B. <no...@ca...>]

Sorry about that error on the unittests. After googling, I found:
http://mail.python.org/pipermail/python-list/2005-November/311235.html

which explains that you always get True when you compare Numeric arrays, 
and you need to use Numeric.equals(a,b) rather than a==b.

In short, I've added an assert called assertArrayEquals based on the above 
webpage and a recipe in the Python Cookbook. This checks the shape, the 
type (e.g. integer, float) and the content of an array.

Needless to say, as you found, there are several failures now....(just when 
they thought it was all over :-)

Regards,
 Noel

Re: [cclib-devel] problems

[Noel O'B. <no...@ca...>]

On Wed, 2006-05-24 at 08:35 -0700, Adam Tenderholt wrote:
> > Can you do MPA on the fragments?
> 
> Yeah, I can but I have no idea if the results are reasonable.
I think the output file contains an MPA for the fragments...if so, it'd
be possible to compare with this.

> >> 3) GAMESS doesn't have two values in homos for it's unrestricted
> >> calculation.
> > I think this problem is related to point 4 (i.e. you mean GAMESS- 
> > UK). If
> > you run testSPun.py you'll see that all tests pass for GAMESS,  
> > including
> > the one that tests the homos.
> 
> It does pass, and I don't understand why. If you add a "print  
> self.data.homos" to the testhomos function, you'll see that Gaussian  
> and ADF have the correct homos array, but the two GAMESS tests don't.
OK - I'm onto it.

> Once we figure out the ADF and GAMESS part, I think we're ready.
Cool.

Re: [cclib-devel] problems

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

> Can you do MPA on the fragments?

Yeah, I can but I have no idea if the results are reasonable.

>> 3) GAMESS doesn't have two values in homos for it's unrestricted
>> calculation.
> I think this problem is related to point 4 (i.e. you mean GAMESS- 
> UK). If
> you run testSPun.py you'll see that all tests pass for GAMESS,  
> including
> the one that tests the homos.

It does pass, and I don't understand why. If you add a "print  
self.data.homos" to the testhomos function, you'll see that Gaussian  
and ADF have the correct homos array, but the two GAMESS tests don't.

>> 4) GAMESS chokes on basicGAMESS-UK/dvb_sp.out and dvb_un_sp.out (no
>> self.nbasis)
> You are (understandably) confusing GAMESS-UK with GAMESS. The only  
> work
> I have done on GAMESS-UK is to create the log files...I was hoping  
> they
> would be similar to those for GAMESS but they're entirely  
> different. The
> two programs share a common ancestor way back, but have diverged
> completely. GAMESS-UK will require a completely new parser and so will
> not be supported in cclib-0.5 (I guess I should edit the cclib.sf.net
> page to remove GAMESS-UK).

Ok, I wasn't sure about GAMESS-UK.

>> 5) I don't have known working MPA or CSPA routines for GAMESS.
> The routines shouldn't be logfile-specific though. Whatever works for
> Gaussian should work for GAMESS.

This is a valid point. I guess if I know the results for Gaussian are  
working, then they have to be working for the rest, provided they do  
indeed correctly parse aooverlaps and mocoeffs (which I think is the  
case).

Once we figure out the ADF and GAMESS part, I think we're ready.

Adam

Re: [cclib-devel] problems

[Noel O'B. <no...@ca...>]

> 2) ADF doesn't parse homos in the dvb_sp_c.adfout file. I haven't  
> looked into it yet.
Can you upload a twin of dvb_sp_c.adfout called dvb_sp_un_c.adfout,
which is the unrestricted version with an odd number of electrons? 

Regards,
 Noel