cclib-devel — Developer's mailing list

Re: [cclib-devel] Data files mistakenly classified as junk

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

I could be wrong, but I thought that they were included in the regression suite.

On 11/06/07, Karol Langner <kar...@kn...> wrote:
> On Monday 11 June 2007 17:54, Noel O'Boyle wrote:
> > Karol,
> >
> > I couldn't help but notice that you junked all of my data files. Well,
> > not all, but some :-)
> >
> > I'll put these on the server instead. These are from the early days of
> > cclib, when we weren't putting things on the server so I didn't know
> > what to do with them. WinGAMESS files are different than those from
> > cclib so they are useful to have.
>
> Sorry :) that was my conclusion, since they aren't used in any tests now.
>
> --
> written by Karol Langner
> Mon Jun 11 18:01:57 CEST 2007
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] Data files mistakenly classified as junk

[Karol L. <kar...@kn...>]

On Monday 11 June 2007 17:54, Noel O'Boyle wrote:
> Karol,
>
> I couldn't help but notice that you junked all of my data files. Well,
> not all, but some :-)
>
> I'll put these on the server instead. These are from the early days of
> cclib, when we weren't putting things on the server so I didn't know
> what to do with them. WinGAMESS files are different than those from
> cclib so they are useful to have.

Sorry :) that was my conclusion, since they aren't used in any tests now.

-- 
written by Karol Langner
Mon Jun 11 18:01:57 CEST 2007

[cclib-devel] Data files mistakenly classified as junk

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

Karol,

I couldn't help but notice that you junked all of my data files. Well,
not all, but some :-)

I'll put these on the server instead. These are from the early days of
cclib, when we weren't putting things on the server so I didn't know
what to do with them. WinGAMESS files are different than those from
cclib so they are useful to have.

Noel

[cclib-devel] test package

[Karol L. <kar...@kn...>]

I added import bridge to the __init__ script of cclib (was there a reason it 
wasn't there?). I also imported test today if possible and some convenienve 
code, so you can now do tests from the interpreter. For now, just 
cclib.test.testall().

I didn't mention it in the commit, but I also added testCC and testTD to 
testall, they were missing out on the action until now.

Karol

-- 
written by Karol Langner
Mon Jun 11 17:43:30 CEST 2007

Re: [cclib-devel] Molpro

[Karol L. <kar...@kn...>]

The parser is pretty mature. How many of the attributes would you say it 
should support in order for it to make in to the next release?

On Monday 11 June 2007 17:32, Noel O'Boyle wrote:
> Unless it going to make the next release, please don't merge it. At
> release time, it's easy for me to make an error trying to remove all
> references to a parser that isn't included.
>
> On 10/06/07, Karol Langner <kar...@kn...> wrote:
> > Is there a reason for not merging the Molpro parser into trunk? Alot of
> > attributes are parsed already, and I am willing to add a few more.

-- 
written by Karol Langner
Mon Jun 11 17:41:24 CEST 2007

Re: [cclib-devel] Molpro

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

Unless it going to make the next release, please don't merge it. At
release time, it's easy for me to make an error trying to remove all
references to a parser that isn't included.

On 10/06/07, Karol Langner <kar...@kn...> wrote:
> Is there a reason for not merging the Molpro parser into trunk? Alot of
> attributes are parsed already, and I am willing to add a few more.
>
> --
> written by Karol Langner
> Sun Jun 10 20:06:46 CEST 2007
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

[cclib-devel] data files and MANIFEST (was Re: cclib debs)

[Karol L. <kar...@kn...>]

On Monday 04 June 2007 13:17, Noel O'Boyle wrote:
> I'm not sure what you mean regarding the data files. They are
> currently installed by default, right?
They weren't, now they are when using 'python setup.py install'.

Also, I added MANIFEST.in which is supposed to automatically take care of 
MANIFEST when building the source distirbution. I'm not removing manifest.py, 
though, because I don't know if  this works also on Windows (someone try?).

-- 
written by Karol Langner
Mon Jun 11 02:00:57 CEST 2007

[cclib-devel] Molpro

[Karol L. <kar...@kn...>]

Is there a reason for not merging the Molpro parser into trunk? Alot of 
attributes are parsed already, and I am willing to add a few more.

-- 
written by Karol Langner
Sun Jun 10 20:06:46 CEST 2007

Re: [cclib-devel] Wiki change

[Karol L. <kar...@kn...>]

On Thursday 07 June 2007 16:31, Noel O'Boyle wrote:
> Karol,
>
> I remember you complaining about the wiki's speed. See if you find it
> any faster now.
>
> (I've been installing another Mediawiki on SF for BlueObelisk)
>
> Noel

I'm not sure, but I still notice slowness at moments. This can also be caused 
by my poor internet connection. though.

I have a suggestion for the wiki: why not put 'Calcualtio methods' on the left 
navigation bar?

Karol

-- 
written by Karol Langner
Sun Jun 10 20:02:56 CEST 2007

Re: [cclib-devel] ...now with TeX support

[Karol L. <kar...@kn...>]

On Friday 08 June 2007 10:55, Noel O'Boyle wrote:
> By copying OpenBabel, I've added tex support to our wiki. Just use the
> <tex> tag (not <math>).
>
> Check out http://cclib.sourceforge.net/wiki/index.php/C_squared
>
> It works by calling cgi-bin/mimetex.cgi, e.g. try
>    http://cclib.sourceforge.net/cgi-bin/mimetex.cgi?x^2
>
> Noel

Well that is very nice. I think in the long run it will be be useful for users 
to have a few equations on some pages.

Karol

-- 
written by Karol Langner
Sun Jun 10 20:01:03 CEST 2007

[cclib-devel] ...now with TeX support

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

By copying OpenBabel, I've added tex support to our wiki. Just use the
<tex> tag (not <math>).

Check out http://cclib.sourceforge.net/wiki/index.php/C_squared

It works by calling cgi-bin/mimetex.cgi, e.g. try
   http://cclib.sourceforge.net/cgi-bin/mimetex.cgi?x^2

Noel

[cclib-devel] Wiki change

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

Karol,

I remember you complaining about the wiki's speed. See if you find it
any faster now.

(I've been installing another Mediawiki on SF for BlueObelisk)

Noel

Re: [cclib-devel] how I use cclib

[Karol L. <kar...@kn...>]

There is another thing I wanted to share/discuss. I have a little thing I use 
to store my output data in XML files, which is something that was brought up 
before. It's not compatible with cclib in its present form, since I have been 
using it with scripts I wrote before I knew about cclib. I would like to base 
it on cclib objects, though. When I do this, maybe it could be a starting 
point for adding a similiar functionality to cclib.

- Karol

-- 
written by Karol Langner
Wed Jun  6 21:25:58 CEST 2007

Re: [cclib-devel] how I use cclib

[Karol L. <kar...@kn...>]

On Wednesday 06 June 2007 10:37, Noel O'Boyle wrote:
> That's nice. Maybe we can put some examples of extending cclib up on
> the wiki.

That's a good idea. This one isn't readily useable by everyone, though, since 
it's for our internal lab code.

> BTW, why do you extract natoms yourself? 

I need to do this, because each EDS output file actually contains three 
calculations - for each monomer and the dimer (like in Morokuma 
decomposition). Every time the nubmer of atoms is different. There are other 
things that should also be modified, but I don't need them for now so I 
haven't done that.

- Karol

-- 
written by Karol Langner
Wed Jun  6 21:18:40 CEST 2007

Re: [cclib-devel] how I use cclib

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

That's nice. Maybe we can put some examples of extending cclib up on
the wiki. BTW, why do you extract natoms yourself?

On 06/06/07, Karol Langner <kar...@kn...> wrote:
> Hi,
>
>  I thought I might share with you how I use cclib in my everyday work now. In
> our lab we have a custom modified version of GAMESS, and I analyze hundreds
> of output files each week. Before, I had to write parsers from scratch to
> gather data. With cclib, it's as easy as writing a class that inherits from
> the GAMESS parser in cclib. See the attached file for an example!
>
> Cheers,
> Karol
>
> --
> written by Karol Langner
> Wed Jun  6 09:51:43 CEST 2007
>
>

Re: [cclib-devel] cclib debs

[Karol L. <kar...@kn...>]

On Monday 04 June 2007 13:17, Noel O'Boyle wrote:
> > > > 4. A testing issue has occured to me while testing the packages. It
> > > > should be possible to run the test suite we have from the Python
> > > > interpreter. I think that adding this is a good idea for the next
> > > > release, together with an option in setup.py to install the test
> > > > scripts and data files. What are you poinions on this?
> > >
> > > Well, I think you should see how this is done for other packages
> > > first. The general recommendation is that "python setup.py test"
> > > should run the tests. But I think you are suggesting something beyond
> > > this.
> >
> > Sure, "python setup.py test" is the standard. I was thinking of something
> > like numpy.test(), which runs the NumPy test suite for the installed
> > package. What are your feelings about something like this? For cclib,
> > that means copying the data files during installation
>
> Sure, go for it - we can probably standardise the tests a bit more
> too. I'm not sure what you mean regarding the data files. They are
> currently installed by default, right?
I don't think so, at least not with my machine:
langner@slim:~$ ls -l apps/python/lib/python2.5/site-packages/cclib
total 24K
drwxr-xr-x 2 langner langner 4.0K 2007-06-05 15:22 bridge
-rw-r--r-- 1 langner langner  247 2007-05-20 01:03 __init__.py
-rw-r--r-- 1 langner langner  479 2007-06-05 15:22 __init__.pyc
drwxr-xr-x 2 langner langner 4.0K 2007-06-05 15:22 method
drwxr-xr-x 2 langner langner 4.0K 2007-06-05 15:22 parser
drwxr-xr-x 2 langner langner 4.0K 2007-06-05 15:22 progress

Did you mean for them to be installed?

> > > I'd actually be more
> > > interested in getting a Python egg together for
> > > ez_setup.py/setuptools. I don't know what the current situation is
> > > with eggs and Debian though.
> >
> > Well, if you have setuptools installed and put this in setup.py:
> > try:
> >     from setuptools import setup
> > except ImportError:
> >     from distutils.core import setup
> > and run "python setup.py bdist_egg", you get ann egg that should be ready
> > to go (I'm attaching it).
>
> OK, so that was easy! Go ahead and commit it, but please make sure
> that our regular distributions are unchanged by this.

OK, I haven't changed any keywords to the call to setup() for now. You can 
build the egg now, though. 

-- 
written by Karol Langner
Tue Jun  5 15:37:20 CEST 2007

Re: [cclib-devel] cclib debs

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

On 04/06/07, Karol Langner <kar...@kn...> wrote:
> On Monday 04 June 2007 11:19, Noel O'Boyle wrote:
> > > 3. Would you be interested in seeing debs of GaussSum and/or PyMOLyze?
> > > I'm not aware if any exist already.
> >
> > GaussSum's already in there.
> Yes, now I see.
>
> > > 4. A testing issue has occured to me while testing the packages. It
> > > should be possible to run the test suite we have from the Python
> > > interpreter. I think that adding this is a good idea for the next
> > > release, together with an option in setup.py to install the test scripts
> > > and data files. What are you poinions on this?
> >
> > Well, I think you should see how this is done for other packages
> > first. The general recommendation is that "python setup.py test"
> > should run the tests. But I think you are suggesting something beyond
> > this.
> Sure, "python setup.py test" is the standard. I was thinking of something like
> numpy.test(), which runs the NumPy test suite for the installed package. What
> are your feelings about something like this? For cclib, that means copying
> the data files during installation
Sure, go for it - we can probably standardise the tests a bit more
too. I'm not sure what you mean regarding the data files. They are
currently installed by default, right?

> > To be honest, I'm not very interested in getting cclib into any of the
> > distributions. Of course, you are welcome to do it. However, since the
> > API has not currently settled, you are going to have problems if some
> > program, e.g. PyMOlyze/GaussSum, starts to depend on it. Basically,
> > you will find it difficult ever to upgrade it if the API changes.
> > Also, cclib has optional dependencies on openbabel, BioPytho, PyQuante
> > (and pyvtk?), which will need to be sorted out. I don't mean to
> > discourage you, but I don't know if it's a good thing to be stuck with
> > a version of cclib in Debian that's 1.5 years out of date, especially
> > when Python packages are pretty easy to install, and cclib has been
> > changing a lot from one release to the next.
> I totally understand, this was more or less the answer I was expecting :), and
> I made these debs mostly out of curiousity.
Sounds like I'm becoming predictable :-)

> > I'd actually be more
> > interested in getting a Python egg together for
> > ez_setup.py/setuptools. I don't know what the current situation is
> > with eggs and Debian though.
> Well, if you have setuptools installed and put this in setup.py:
> try:
>     from setuptools import setup
> except ImportError:
>     from distutils.core import setup
> and run "python setup.py bdist_egg", you get ann egg that should be ready to
> go (I'm attaching it).
OK, so that was easy! Go ahead and commit it, but please make sure
that our regular distributions are unchanged by this.

>Should I add this code along with other stuff
> (dependency info, etc.) to the trunk? As far as Debian is concerned,
> installing the package python-setuptools lets you use eggs.
Sure, go ahead.

> Cheers,
> Karol
>
> --
> written by Karol Langner
> Mon Jun  4 11:42:16 CEST 2007
>
>

Re: [cclib-devel] cclib debs

[Karol L. <kar...@kn...>]

On Monday 04 June 2007 11:19, Noel O'Boyle wrote:
> > 3. Would you be interested in seeing debs of GaussSum and/or PyMOLyze?
> > I'm not aware if any exist already.
>
> GaussSum's already in there.
Yes, now I see.

> > 4. A testing issue has occured to me while testing the packages. It
> > should be possible to run the test suite we have from the Python
> > interpreter. I think that adding this is a good idea for the next
> > release, together with an option in setup.py to install the test scripts
> > and data files. What are you poinions on this?
>
> Well, I think you should see how this is done for other packages
> first. The general recommendation is that "python setup.py test"
> should run the tests. But I think you are suggesting something beyond
> this.
Sure, "python setup.py test" is the standard. I was thinking of something like 
numpy.test(), which runs the NumPy test suite for the installed package. What 
are your feelings about something like this? For cclib, that means copying 
the data files during installation

> To be honest, I'm not very interested in getting cclib into any of the
> distributions. Of course, you are welcome to do it. However, since the
> API has not currently settled, you are going to have problems if some
> program, e.g. PyMOlyze/GaussSum, starts to depend on it. Basically,
> you will find it difficult ever to upgrade it if the API changes.
> Also, cclib has optional dependencies on openbabel, BioPytho, PyQuante
> (and pyvtk?), which will need to be sorted out. I don't mean to
> discourage you, but I don't know if it's a good thing to be stuck with
> a version of cclib in Debian that's 1.5 years out of date, especially
> when Python packages are pretty easy to install, and cclib has been
> changing a lot from one release to the next.
I totally understand, this was more or less the answer I was expecting :), and 
I made these debs mostly out of curiousity.

> I'd actually be more 
> interested in getting a Python egg together for
> ez_setup.py/setuptools. I don't know what the current situation is
> with eggs and Debian though.
Well, if you have setuptools installed and put this in setup.py:
try:
    from setuptools import setup
except ImportError:
    from distutils.core import setup
and run "python setup.py bdist_egg", you get ann egg that should be ready to 
go (I'm attaching it). Should I add this code along with other stuff 
(dependency info, etc.) to the trunk? As far as Debian is concerned, 
installing the package python-setuptools lets you use eggs.

Cheers,
Karol

-- 
written by Karol Langner
Mon Jun  4 11:42:16 CEST 2007

Re: [cclib-devel] cclib debs

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

On 02/06/07, Karol Langner <kar...@kn...> wrote:
> Hi,
>
>  Since I haven't seen any debs of cclib on the web (I have seen queries about
> it) and I have some experience in making them, I've decided to take a shot at
> it. It would be nice to get cclib into the Debian packaging system, and from
> what I gather it can be done pretty quickly. I need to find a bit of time to
> tune things, but I made a quick build today - they install and seem to work
> fine on my Debian etch installation. You can find all the related files here:
> http://www.mml.ch.pwr.wroc.pl/langner/tmp/debs/
>
> Notice that I also built a packages called 'cclib-data', which has the test
> scripts and data files. At the moment, it installs into the same directory as
> cclib, but cannot be accessed from Python.
>
> My question for you are:
>
> 1. Do you use cclib on Debian and would be willing to test these packages?
No.

> 2. Do you have colleagues that use cclib on Debian and would be willing to
> test these packages?
>
> 3. Would you be interested in seeing debs of GaussSum and/or PyMOLyze? I'm not
> aware if any exist already.
GaussSum's already in there.

> 4. A testing issue has occured to me while testing the packages. It should be
> possible to run the test suite we have from the Python interpreter. I think
> that adding this is a good idea for the next release, together with an option
> in setup.py to install the test scripts and data files. What are you poinions
> on this?

Well, I think you should see how this is done for other packages
first. The general recommendation is that "python setup.py test"
should run the tests. But I think you are suggesting something beyond
this.

To be honest, I'm not very interested in getting cclib into any of the
distributions. Of course, you are welcome to do it. However, since the
API has not currently settled, you are going to have problems if some
program, e.g. PyMOlyze/GaussSum, starts to depend on it. Basically,
you will find it difficult ever to upgrade it if the API changes.
Also, cclib has optional dependencies on openbabel, BioPytho, PyQuante
(and pyvtk?), which will need to be sorted out. I don't mean to
discourage you, but I don't know if it's a good thing to be stuck with
a version of cclib in Debian that's 1.5 years out of date, especially
when Python packages are pretty easy to install, and cclib has been
changing a lot from one release to the next. I'd actually be more
interested in getting a Python egg together for
ez_setup.py/setuptools. I don't know what the current situation is
with eggs and Debian though.

> Cheers,
> Karol
>
> --
> written by Karol Langner
> Sat Jun  2 15:44:18 CEST 2007
>

Re: [cclib-devel] broken gaussian file

[Karol L. <kar...@kn...>]

On Tuesday 15 May 2007 11:01, Noel O'Boyle wrote:
> On 07/05/07, Adam Tenderholt <a-t...@st...> wrote:
> > One of my labmates has a Gaussian 98 frequency calculation that cclib
> > chokes on. The issue is the assert nbasis == self.nbasis found on
> > line 532 of the gaussian parser. For some reason, it says it uses 290
> > basis functions at one point and then says there are 292 basis
> > functions. It has the following route section:
> >
> > #P UBP86/LanL2DZ 5D 7F SCF(MaxCycle=500,conver=8) Pop=(NPA) Freq IOP
> > (7/33=1) guess=read geom=check
> >
> > Have we seen this before? I have no idea what's going on and the 7/33
> > IOP doesn't exist in the Gaussian 03 Documentation.
>
> It would be useful to have the actual input file, although I suspect
> that that is not going to help much. Also the original input file for
> the geometry optimisation, e.g. did the geo-opt use exactly the same
> settings for basis set (there is a "guess=read" so it's possible that
> this might have an effect)?
>
> The quick fix for your friend is to remove the second NBasis line from
> the log file (note: I haven't tested this).
>
> The G98 docs are available on the web, but don't contain 7/33.
> However, some googling shows that it is simply related to the output
> of the force constant matrix.
>
> Actually, I now notice that the error occurs in the "Dens" section,
> probably due to "DoDens=T"@3432, and there's a "ToCart=T". The
> following matrix is 292x290 and is referred to as a transformation
> matrix. So it sounds like there's a transformation from something to
> Cartesian, which causes the basis set number to increase from 290 to
> 292. This may be du to NBO or due to the fact that 5D and 7F were used
> up till that point, and they cannot be applied to the density (??).
>
> What to do about this problem I'm not sure...if your colleague had
> used iop(3/33=1,3/36=-1) and pop=full which figure would have been
> used for the matrices? 290 or 292. I think we need to reproduce this
> for dvb, and see what the consequences are for the data that we
> extract.

To sart off, there isn't much information out there about IOP 7/33, I found 
only this one thread on CCL:
http://ccl.net/chemistry/resources/messages/2007/05/23.003-dir/index.html

It would be nice to have the original input file (and the molecule in 
question), but since we don't I made some small tests and reproduced the 
parsing error.

The basis set here is not an issue (I use STO-3G) - it's the combination of 
FREQ and IOP(7/33=1) for heavy atoms that changes the number of basis 
functions when printing the transition dipole moments in a cartesian frame. I 
haven't thought about a fix yet, but now we can at least try to make a 
regression file for this. Find attached: test_Cu2.com/log for the 
input/output files of this test. The output is for Gaussian98 - the same 
thing happens in G03, I checked.

There is a (related) error for the same input combination in the case of 
lighter atoms. Find attached: test_H2.com/log - exactly the same input but H 
instead of Cu. I haven't even looked at this output, but it gives a different 
error when parsed than the test above.

Maybe this will make fixing easier,
Karol

P.S. I esent this mail, 'cause the *.com attachments didn't go through before.

-- 
written by Karol Langner
Fri Jun  1 18:52:10 CEST 2007

Re: [cclib-devel] Lowdin and generalized wavefunction projection population analysis

[Karol L. <kar...@kn...>]

The LPA method I added here does not work with Numeric. I'm not even aware if 
Numeric has a working eigenvalue decomposition (the one in my installation, 
LinearAlgebra.eig, feezes the interpreter or is very slow). So this is the 
only thing currently that doesn't work with Numeric.

- Karol

-- 
written by Karol Langner
Wed May 23 14:41:17 CEST 2007

[cclib-devel] fragcharges

[Karol L. <kar...@kn...>]

Hi all,

 Concerning the fragcharges attribute from the population methods - they 
currently contain the number of electrons on the fragment and not the charge 
on (for example) an atom. Shouldn't we add the nuclear charge for fragments 
on atoms? If not, maybe it would be better to rename the attribute to 
something like "fragpop"?

- Karol

-- 
written by Karol Langner
Wed May 23 14:35:06 CEST 2007

[cclib-devel] Lowdin and generalized wavefunction projection population analysis

[Karol L. <kar...@kn...>]

Having added the LPA module for calculating Lowdin Population Analyses, I 
would like to comment on it a bit. First of all, it's a nice alternative to 
Mulliken charges. Second, it allows the calculation to be done using any 
given exponent over the overlap matrix:

q_{A} = sum_{a in A} (S^{x} P S^{1-x})_{aa}

where a are the atomic orbitals that belong to atom or group A, S is the 
overlap matrix, and P is the density matrix. When x=1.0 or x=0.0, the 
equation simplifies to Mulliken charges. The Lowdin analysis assumes x=0.5 
(default in the new code).

Take a look:

Python 2.5 (r25:51908, Apr 30 2007, 15:03:13)
[GCC 3.4.6 (Debian 3.4.6-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cclib
>>> cclib.__version__
'0.7'
>>> cclib.method.mpa.__revision__
'$Revision: 627 $'
>>> mol = cclib.parser.ccopen("dvb_sp.out")
>>> mol.parse()
[Gaussian dvb_sp.out INFO] Creating attribute charge: 0
[Gaussian dvb_sp.out INFO] Creating attribute mult: 1
[Gaussian dvb_sp.out INFO] Creating attribute atomnos[]
[Gaussian dvb_sp.out INFO] Creating attribute natom: 20
[Gaussian dvb_sp.out INFO] Creating attribute atomcoords[]
[Gaussian dvb_sp.out INFO] Creating attribute nbasis: 60
[Gaussian dvb_sp.out INFO] Creating attribute aooverlaps[]
[Gaussian dvb_sp.out INFO] Creating attribute nmo: 60
[Gaussian dvb_sp.out INFO] Creating attribute scftargets[]
[Gaussian dvb_sp.out INFO] Creating attribute scfvalues[]
[Gaussian dvb_sp.out INFO] Creating attribute scfenergies[]
[Gaussian dvb_sp.out INFO] Creating attribute mosyms[]
[Gaussian dvb_sp.out INFO] Creating attribute homos[]
[Gaussian dvb_sp.out INFO] Creating attribute moenergies[]
[Gaussian dvb_sp.out INFO] Creating attribute aonames[]
[Gaussian dvb_sp.out INFO] Creating attribute mocoeffs[]
[Gaussian dvb_sp.out INFO] Creating attribute coreelectrons[]
[Gaussian dvb_sp.out INFO] Creating attribute coreelectrons[]
>>> mpa = cclib.method.MPA(mol)
>>> lpa = cclib.method.LPA(mol)
>>> mpa.calculate()
[MPA Gaussian log file dvb_sp.out INFO] Creating attribute aoresults: 
[array[2]]
[MPA Gaussian log file dvb_sp.out INFO] Saving partitioned results in 
fragresults: [array[2]]
[MPA Gaussian log file dvb_sp.out INFO] Creating fragcharges: array[1]
True
>>> lpa.calculate()
[LPA Gaussian log file dvb_sp.out INFO] Creating attribute aoresults: 
[array[2]]
[LPA Gaussian log file dvb_sp.out INFO] Saving partitioned results in 
fragresults: [array[2]]
[LPA Gaussian log file dvb_sp.out INFO] Creating fragcharges: array[1]
True
>>> mpa.fragcharges
array([ 6.0045089 ,  6.07712116,  6.07668927,  6.0045089 ,  6.07712116,
        0.92078088,  0.92230013,  0.92078088,  6.07636862,  6.15486853,
        0.92367176,  0.92311728,  0.92066214,  6.07636862,  0.92311728,
        6.15486853,  0.92367176,  0.92066214,  6.07668927,  0.92230013])
>>> lpa.fragcharges
array([ 5.99633692,  6.04422133,  6.04398657,  5.99633692,  6.04422133,
        0.9563139 ,  0.95803503,  0.9563139 ,  6.03894201,  6.09166045,
        0.95680625,  0.95882711,  0.9549591 ,  6.03894201,  0.95882711,
        6.09166045,  0.95680625,  0.9549591 ,  6.04398657,  0.95803503])
>>> lpa.calculate(x=0.0)
[LPA Gaussian log file dvb_sp.out INFO] Creating attribute aoresults: 
[array[2]]
[LPA Gaussian log file dvb_sp.out INFO] Saving partitioned results in 
fragresults: [array[2]]
[LPA Gaussian log file dvb_sp.out INFO] Creating fragcharges: array[1]
True
>>> lpa.fragcharges
array([ 6.0045089 ,  6.07712116,  6.07668927,  6.0045089 ,  6.07712116,
        0.92078088,  0.92230013,  0.92078088,  6.07636862,  6.15486853,
        0.92367176,  0.92311728,  0.92066214,  6.07636862,  0.92311728,
        6.15486853,  0.92367176,  0.92066214,  6.07668927,  0.92230013])

Notice how when x=0.0 is passed the charges are the same as the ones obtained 
using the current MPA class. It might be nice to integrate the two with a 
more general class, but not fully since when 0<x<1 two roots of the overlap 
matrix need to be calculated which takes some time.

- Karol

-- 
written by Karol Langner
Sun May 20 00:31:36 CEST 2007

Re: [cclib-devel] Numeric -> NumPy transition

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

> I can't get bad results from the CSPA method, any way I go, with  
> code before
> the NumPy->Numeric transition, using numpy or Numeric. Can you  
> specify which
> parsed file breaks the method?

I must have accidently chosen the MPA method (in pymolyze) when I was  
doing a quick check because I can't reproduce it either.

Adam

Re: [cclib-devel] Numeric -> NumPy transition

[Karol L. <kar...@kn...>]

On Tuesday 15 May 2007 22:37, Adam Tenderholt wrote:
> The Mulliken and C-squared population analysis are broken with
> revision 624. I haven't really explored it other than noticing that
> the numbers are way off and that it looks like every aoresult for a
> given MO have the same number (~1).

I can't get bad results from the CSPA method, any way I go, with code before 
the NumPy->Numeric transition, using numpy or Numeric. Can you specify which 
parsed file breaks the method?

For example, in all the three following cases:
1) before transition
>>> cclib.method.cspa.__revision__
'$Revision: 549 $'
2) after transition, using Numeric
>>> cclib.method.cspa.__revision__
'$Revision: 616 $'
>>> cclib.method.cspa.numpy.__name__
'Numeric'
3) after transition, using NumPy
>>> cclib.method.cspa.__revision__
'$Revision: 616 $'
>>> cclib.method.cspa.numpy.__name__
'numpy'

I get the same output for basicGaussian03/dvb_sp.out:
>>> a = cclib.parser.ccopen("dvb_sp.out")
>>> a.parse()
[Gaussian dvb_sp.out INFO] Creating attribute atomnos[]
[Gaussian dvb_sp.out INFO] Creating attribute natom: 20
[Gaussian dvb_sp.out INFO] Creating attribute atomcoords[]
[Gaussian dvb_sp.out INFO] Creating attribute nbasis: 60
[Gaussian dvb_sp.out INFO] Creating attribute aooverlaps[x, y]
[Gaussian dvb_sp.out INFO] Creating attribute nmo: 60
[Gaussian dvb_sp.out INFO] Creating attribute scftargets[]
[Gaussian dvb_sp.out INFO] Creating attribute scfvalues
[Gaussian dvb_sp.out INFO] Creating attribute scfenergies[]
[Gaussian dvb_sp.out INFO] Creating attribute mosyms[[]]
[Gaussian dvb_sp.out INFO] Creating attribute homos[]
[Gaussian dvb_sp.out INFO] Creating attribute moenergies
[Gaussian dvb_sp.out INFO] Creating attributes aonames[], mocoeffs[]
[Gaussian dvb_sp.out INFO] Creating attribute coreelectrons[]
>>> b = cclib.method.cspa(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'module' object is not callable
>>> b = cclib.method.CSPA(a)
>>> b.calculate()
[CSPA Gaussian log file dvb_sp.out INFO] Creating attribute aoresults: 
array[3]
[CSPA Gaussian log file dvb_sp.out INFO] Saving partitioned results in 
fragresults: array[3]
[CSPA Gaussian log file dvb_sp.out INFO] Creating fragcharges: array[1]
True
>>> b.fragcharges
array([ 6.15511175,  6.17848707,  6.17201986,  6.15511175,  6.17848707,  
0.80749953,
             0.80896859,  0.80749953,  6.1965754 ,  6.20647677,  0.82826582,
             0.82550176,  0.82109346,  6.1965754 ,  0.82550176,  6.20647677,
             0.82826582,  0.82109346,  6.17201986,  0.80896859])

-- 
written by Karol Langner
Wed May 16 02:17:02 CEST 2007