cclib-devel — Developer's mailing list

Re: [cclib-devel] problems

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

On Tue, 2006-05-23 at 18:52 -0700, Adam Tenderholt wrote:
> So I've begun testing the methods, and I've come across problems--- 
> some technical and the rest not:
> 
> 1) We don't have any ADF calcs without symmetry, which means I can't  
> easily determine whether MPA and CSPA work for ADF by comparing to  
> PyMOlyze. Also, since it uses weird fonames, splitting up based on  
> the linear combination atom names is not easily compared to the  
> corresponding info printed in the files.
Can you do MPA on the fragments?
> 2) ADF doesn't parse homos in the dvb_sp_c.adfout file. I haven't  
> looked into it yet.
I'll hopefully look into this as 3-->5 don't require any action on my
part.
> 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.
> 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).
> 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.


> I'll work on 1 by starting an appropriate calc. I can also look at 2,  
> but it'll be awhile before I get there. Hopefully you can fix the rest.
> 
> 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

[cclib-devel] problems

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

So I've begun testing the methods, and I've come across problems--- 
some technical and the rest not:

1) We don't have any ADF calcs without symmetry, which means I can't  
easily determine whether MPA and CSPA work for ADF by comparing to  
PyMOlyze. Also, since it uses weird fonames, splitting up based on  
the linear combination atom names is not easily compared to the  
corresponding info printed in the files.

2) ADF doesn't parse homos in the dvb_sp_c.adfout file. I haven't  
looked into it yet.

3) GAMESS doesn't have two values in homos for it's unrestricted  
calculation.

4) GAMESS chokes on basicGAMESS-UK/dvb_sp.out and dvb_un_sp.out (no  
self.nbasis)

5) I don't have known working MPA or CSPA routines for GAMESS.

I'll work on 1 by starting an appropriate calc. I can also look at 2,  
but it'll be awhile before I get there. Hopefully you can fix the rest.

Adam

Re: [cclib-devel] Re: Prerelease branch

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

On Tue, 2006-05-23 at 09:10 +0100, Noel O'Boyle wrote:
> On Mon, 2006-05-22 at 10:28 -0700, Adam Tenderholt wrote:
> > > (1) I've removed all mention of scfvalues and scftargets from the ADF
> > > parser on the branch (since we don't actually know what's going on)
> > > (2) I've found that ADF has one extra atomcoords compared to geovalues
> > > than either GAMESS or Gaussian, but I cannot figure out why (I guess
> > > that's just the way it is)
> > > (3) The final test that doesn't pass is related to the scfenergies.  
> > > ADF
> > > says something like 140 whereas GAMESS and Gaussian both agree on  
> > > 324 or
> > > so. We need to check whether this difference is due to the use of
> > > different units or what. I think we agreed on eV for these sorts of
> > > energies.
> > 
> > Ok. It seems to me that ADF is a pain. I'm sorry! My guess for the  
> > difference in units is because of the difference in functionals. ADF  
> > doesn't have B3LYP (presumably because it can't do hartree-fock and  
> > therefore hybrid functionals aren't available?), so I just used BLYP.
> 
> Ah, of course - I think you told me that before. So that's the final
> unittest passed!! (on the branch at least :-)

Actually - no it's weirder than that. The Gaussian and GAMESS parsers
are extracting a.u. (I'll change this), but you were correctly
converting the a.u. to eV.

But this makes them even further off: Gaussian -383 a.u. but ADF talks
about energies of about -5.16 hartrees. Since we must assume that in
this instance a.u. == hartree, it's clear that ADF is not on the same
page as other programs. The usual guff applies about it's not absolute
energies that are important but differences in energies, but it's still
weird - they clearly measure energy in entirely different ways.

(Note that I tried BLYP with Gaussian and got about the same energy as
with B3LYP)

I'll fix the Gaussian/GAMESS parsers...

Regards,
 Noel

[cclib-devel] Re: Prerelease branch

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

On Mon, 2006-05-22 at 10:28 -0700, Adam Tenderholt wrote:
> > (1) I've removed all mention of scfvalues and scftargets from the ADF
> > parser on the branch (since we don't actually know what's going on)
> > (2) I've found that ADF has one extra atomcoords compared to geovalues
> > than either GAMESS or Gaussian, but I cannot figure out why (I guess
> > that's just the way it is)
> > (3) The final test that doesn't pass is related to the scfenergies.  
> > ADF
> > says something like 140 whereas GAMESS and Gaussian both agree on  
> > 324 or
> > so. We need to check whether this difference is due to the use of
> > different units or what. I think we agreed on eV for these sorts of
> > energies.
> 
> Ok. It seems to me that ADF is a pain. I'm sorry! My guess for the  
> difference in units is because of the difference in functionals. ADF  
> doesn't have B3LYP (presumably because it can't do hartree-fock and  
> therefore hybrid functionals aren't available?), so I just used BLYP.

Ah, of course - I think you told me that before. So that's the final
unittest passed!! (on the branch at least :-)

Regards,
 Noel

Re: [cclib-devel] methods

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

On Mon, 2006-05-22 at 18:35 -0700, Adam Tenderholt wrote:
> I've committed methods for overlap population and mayer's bond order  
> analyses. Of the (little) testing I've done against known results,  
> these methods produce the correct answers. I've also tested MPA,  
> CSPA, and the density matrix. I'm a little hesitant to say release  
> cclib 0.5 without further testing, which I hope to complete by  
> Wednesday. Feel free to help out if you have time.

I'll add some unittests for some general things.

>  Also, there is a  
> fair amount of code duplication, which I propose not cleaning up  
> until after the release.

That sounds fine - I can try and help move things into Numeric (cf. your
SVN log comment regarding OPA) at that stage too.

> Almost there.... :o)
Cool.

Regards,
 Noel

[cclib-devel] methods

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

I've committed methods for overlap population and mayer's bond order  
analyses. Of the (little) testing I've done against known results,  
these methods produce the correct answers. I've also tested MPA,  
CSPA, and the density matrix. I'm a little hesitant to say release  
cclib 0.5 without further testing, which I hope to complete by  
Wednesday. Feel free to help out if you have time. Also, there is a  
fair amount of code duplication, which I propose not cleaning up  
until after the release.

Almost there.... :o)

Adam

[cclib-devel] Re: Prerelease branch

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

> (1) I've removed all mention of scfvalues and scftargets from the ADF
> parser on the branch (since we don't actually know what's going on)
> (2) I've found that ADF has one extra atomcoords compared to geovalues
> than either GAMESS or Gaussian, but I cannot figure out why (I guess
> that's just the way it is)
> (3) The final test that doesn't pass is related to the scfenergies.  
> ADF
> says something like 140 whereas GAMESS and Gaussian both agree on  
> 324 or
> so. We need to check whether this difference is due to the use of
> different units or what. I think we agreed on eV for these sorts of
> energies.

Ok. It seems to me that ADF is a pain. I'm sorry! My guess for the  
difference in units is because of the difference in functionals. ADF  
doesn't have B3LYP (presumably because it can't do hartree-fock and  
therefore hybrid functionals aren't available?), so I just used BLYP.

> Can you let me know when it would suit you to release 0.5, i.e. what
> state are your population analysers in?

MPA and CSPA should both be finished. I haven't extensively tested  
them, but I did check a few MOs against the results from PyMOlyze and  
they agree. I'm hoping to finish the overlap population analysis  
today. As I recall, the density matrix analysis is finished, which  
means that the Mayer's Bond Orders analysis should be basically  
trivial at this point. I'm shooting for the end of today, but  
factoring in true development times, it'll be Wednesday or so. ;o)
>
> BTW, I've put some info relating to the branch at
> http://cclib.sourceforge.net/wiki/index.php? 
> title=Development&action=submit to keep track of merges.

Ok, sounds good.

Adam

[cclib-devel] Re: Changes

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

> After some thinking, I've taken your suggestion and created a  
> prerelease
> branch for cclib-0.5. In this branch, I've removed all references to
> Jaguar with the idea being that once all tests pass, it'll be ready  
> for
> release (don't worry, I will check with you beforehand).

Sounds good to me.

> Continue editing in the trunk, although it would be good if you  
> avoided
> major reorganisations at this point. I'm trying to pin down the final
> failures in the tests, mainly relating the atomcoords (it's tricky as
> the first/final geometries are often treated differently than the
> others).

I'm not planning on any major reorganizations at this point.

> I'll merge the recent trunk changes into the branch, so whatever  
> you do
> between now and the release (which I hope will be mid week this week?)
> will still be included in the final 0.5 release.

Yeah, I'm shooting for mid this week.

> It seems that it is impossible to normalise aonames. For example, for
> dvb_sp.out, Gaussian aonames is:
> ['C1_1S', 'C1_2S', 'C1_2PX', 'C1_2PY', 'C1_2PZ', etc.
>
> but for C_bigbasis.out, Gaussian aonames is:
> ['C1_1S', 'C1_2S', 'C1_3S', 'C1_4S', 'C1_5S', 'C1_6PX', 'C1_6PY',  
> 'C1_6PZ',
>
> Notice the change from C1_nS to C1_nPX in the first case, but from  
> C1_nS
> to C1_(n+1)PX in the second case.
>
> Since GAMESS does not provide the 'n' number, I've been trying to make
> it up (see http://cclib.sourceforge.net/wiki/index.php/Aonames) but
> since it will be impossible to make it agree with Gaussian (based  
> on the
> examples above) I propose to drop 'n' for GAMESS, rather than give a
> misleading name for the atomic orbital. What does 'n' refer to  
> anyway??

I think the n is dependent on both the quantum number and the quality  
of the basis set (ie. double vs triple zeta), although I don't see  
any real trend. Perhaps the coefficients of the gaussian-type  
functions are the same in the small basis set but different in the  
large basis set which is why they get another number. Just idle  
speculation....

Adam

[cclib-devel] Prerelease branch

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

After a day working at cclib, I've managed to get all but one test
passing on the prerelease branch. 

(1) I've removed all mention of scfvalues and scftargets from the ADF
parser on the branch (since we don't actually know what's going on)
(2) I've found that ADF has one extra atomcoords compared to geovalues
than either GAMESS or Gaussian, but I cannot figure out why (I guess
that's just the way it is)
(3) The final test that doesn't pass is related to the scfenergies. ADF
says something like 140 whereas GAMESS and Gaussian both agree on 324 or
so. We need to check whether this difference is due to the use of
different units or what. I think we agreed on eV for these sorts of
energies.

Can you let me know when it would suit you to release 0.5, i.e. what
state are your population analysers in?

BTW, I've put some info relating to the branch at 
http://cclib.sourceforge.net/wiki/index.php?title=Development&action=submit to keep track of merges.

Regards,
 Noel

[cclib-devel] Changes

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

Hello again Adam,

After some thinking, I've taken your suggestion and created a prerelease
branch for cclib-0.5. In this branch, I've removed all references to
Jaguar with the idea being that once all tests pass, it'll be ready for
release (don't worry, I will check with you beforehand).

Continue editing in the trunk, although it would be good if you avoided
major reorganisations at this point. I'm trying to pin down the final
failures in the tests, mainly relating the atomcoords (it's tricky as
the first/final geometries are often treated differently than the
others).

I'll merge the recent trunk changes into the branch, so whatever you do
between now and the release (which I hope will be mid week this week?)
will still be included in the final 0.5 release.

It seems that it is impossible to normalise aonames. For example, for
dvb_sp.out, Gaussian aonames is:
['C1_1S', 'C1_2S', 'C1_2PX', 'C1_2PY', 'C1_2PZ', etc.

but for C_bigbasis.out, Gaussian aonames is:
['C1_1S', 'C1_2S', 'C1_3S', 'C1_4S', 'C1_5S', 'C1_6PX', 'C1_6PY', 'C1_6PZ',

Notice the change from C1_nS to C1_nPX in the first case, but from C1_nS
to C1_(n+1)PX in the second case.

Since GAMESS does not provide the 'n' number, I've been trying to make
it up (see http://cclib.sourceforge.net/wiki/index.php/Aonames) but
since it will be impossible to make it agree with Gaussian (based on the
examples above) I propose to drop 'n' for GAMESS, rather than give a
misleading name for the atomic orbital. What does 'n' refer to anyway??

Regards,
 Noel

Re: [cclib-devel] parser __init__.py

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

On Fri, 2006-05-19 at 13:31 -0700, Adam Tenderholt wrote:
> I see that the __init__.py file changed because of some weird  
> circular importing problems, and that we can no longer use from  
> cclib.parser import ADF or whatever. What if the init file was  
> changed as follows?
> 
> from adfparser import ADF
> from gaussianparser import Gaussian
> ....
> 
> def guesser(filename):
> 	....
> 	your routines
> 	.....
> 
> 
> I think if it's changed this way, we could still do the from  
> cclib.parser import whatever, and also from cclib.parser import  
> guesser. Do you think this is worth looking into? (I pass it to you  
> because I'm not an __init__.py magic person.)

I've added the 'guesser' to __init__.py. It's called
guesstype(filename). From an example of usage, check out
test/testauto.py.

> 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

[cclib-devel] parser __init__.py

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

I see that the __init__.py file changed because of some weird  
circular importing problems, and that we can no longer use from  
cclib.parser import ADF or whatever. What if the init file was  
changed as follows?

from adfparser import ADF
from gaussianparser import Gaussian
....

def guesser(filename):
	....
	your routines
	.....


I think if it's changed this way, we could still do the from  
cclib.parser import whatever, and also from cclib.parser import  
guesser. Do you think this is worth looking into? (I pass it to you  
because I'm not an __init__.py magic person.)

Adam

Re: [cclib-devel] Re: Progress towards release

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

On Thu, 2006-05-18 at 08:19 -0700, Adam Tenderholt wrote:
> > What's the naming scheme again? Check out the wiki for examples of
> > what's extracted from GAMESS and Gaussian and let me know if this  
> > needs
> > to be improved.
> 
> Ooh, I wasn't thinking of aonames but mosymms. The aonames look fine,  
> although we may want to consider normalizing the GAMESS names at some  
> point.

We'll need a bigger sample though - maybe a one-atom calc on a metal ion
with a massive basis set, like you did with ADF...I'll look into it.

> > I'll try and add a method today that reads the first 10 lines of the
> > file and guesses the identity, how does that sound?
> 
> Sounds good.

It's done now (requires first 20 lines for the test files). Check out
the SVN log though as it involved a couple of rearrangements of imports.

Regards,
 Noel

Re: [cclib-devel] Re: Progress towards release

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

> What's the naming scheme again? Check out the wiki for examples of
> what's extracted from GAMESS and Gaussian and let me know if this  
> needs
> to be improved.

Ooh, I wasn't thinking of aonames but mosymms. The aonames look fine,  
although we may want to consider normalizing the GAMESS names at some  
point.

> I'll try and add a method today that reads the first 10 lines of the
> file and guesses the identity, how does that sound?

Sounds good.

> In PyMOlyze/GaussSum we can flash a box up that asks people to send us
> their log file if it doesn't guess correctly, and they want to help us
> improve it.

Yeah, makes sense. I'll make a note of that.

Adam

Re: [cclib-devel] Re: Progress towards release

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

On Wed, 2006-05-17 at 10:28 -0700, Adam Tenderholt wrote:
> > Well, I wouldn't be too worried about it. A stable release (1.0) is  
> > one
> > thing. A 0.5 or less release is another. We can simply not mention the
> > other parsers. Also, I do not think that maintaining branches is a fun
> > task. It *is* possible though, and with the tests that we have, we can
> > ensure that it still works.
> 
> Ok, that's fine. I suspect there aren't going to be many user of  
> cclib immediately.

If we get a couple of command-line enthusiasts we'll be lucky. We could
try to get BKChem on board too, and any other Python programs in a
similar area. PyQuante too (although I'm not sure how this would work).

> > Yeah, 500 reads and no answers - still waiting.
> 
> That's a lot. I'm surprised nobody has answered yet.
Nobody knows the answer or I didn't phrase it correctly, I guess.

> > So I did I, but there was a question mark in front of the √  
> > in the
> > cclib wiki. Anyway I've looked in this, and into filling the last few
> > checkboxes for GAMESS and Gaussian.
> 
> Oh yeah. I had added that when I noticed that the aonames didn't fit  
> our naming scheme (lowercase u/g). I think it's ok.
What's the naming scheme again? Check out the wiki for examples of
what's extracted from GAMESS and Gaussian and let me know if this needs
to be improved.

> > Wait a second, I was thinking of exactly the same thing! I was  
> > thinking
> > of a method of the Logfile, that either returns an instance of the
> > appropriate parser or returns None.

I'll try and add a method today that reads the first 10 lines of the
file and guesses the identity, how does that sound?

In PyMOlyze/GaussSum we can flash a box up that asks people to send us
their log file if it doesn't guess correctly, and they want to help us
improve it.

Noel

Re: [cclib-devel] Re: Progress towards release

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

> Well, I wouldn't be too worried about it. A stable release (1.0) is  
> one
> thing. A 0.5 or less release is another. We can simply not mention the
> other parsers. Also, I do not think that maintaining branches is a fun
> task. It *is* possible though, and with the tests that we have, we can
> ensure that it still works.

Ok, that's fine. I suspect there aren't going to be many user of  
cclib immediately.

> Yeah, 500 reads and no answers - still waiting.

That's a lot. I'm surprised nobody has answered yet.

> So I did I, but there was a question mark in front of the √  
> in the
> cclib wiki. Anyway I've looked in this, and into filling the last few
> checkboxes for GAMESS and Gaussian.

Oh yeah. I had added that when I noticed that the aonames didn't fit  
our naming scheme (lowercase u/g). I think it's ok.

> Yeah, real life - it does get in the way. I will have some time in the
> evenings next week and would like to get an initial release put  
> together
> and sent off sometime that week. We probably need some more man  
> pages on
> the wiki showing how to use cclib: the parser and the analysers.

I have added a page about using the methods, but it's not too detailed.

> Wait a second, I was thinking of exactly the same thing! I was  
> thinking
> of a method of the Logfile, that either returns an instance of the
> appropriate parser or returns None.

Sounds good.

Adam

Re: [cclib-devel] Re: Progress towards release

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

On Tue, 2006-05-16 at 11:14 -0700, Adam Tenderholt wrote:
> > I'd like to add support for atomcoords to all of the main parsers, and
> > get a release out next week or the week after with good support for  
> > ADF,
> > GAMESS and Gaussian. Once we get Jaguar in shape we can get another
> > release out.
> 
> Sounds reasonable. I agree that it's more important to get an initial  
> release out for relatively stable parsers, and have subsequent  
> releases once we add support for other formats. Do you think we  
> should keep the "broken" parsers in our initial release? I think it  
> makes sense to create a SVN branch, and remove parsers other than  
> ADF, GAMESS, and Gaussian.

Well, I wouldn't be too worried about it. A stable release (1.0) is one
thing. A 0.5 or less release is another. We can simply not mention the
other parsers. Also, I do not think that maintaining branches is a fun
task. It *is* possible though, and with the tests that we have, we can
ensure that it still works.

> > I've posted on the ADF forum regarding the SCF values, and if we  
> > get an
> > answer I'll be able to fix that once and for all (I see it causes a
> > unittest failure too).
> 
> Cool.

Yeah, 500 reads and no answers - still waiting.

> > You or I should do a global rename of nindep to nmo, if you agree.
> 
> I'll take care of it, unless I encounter problems (going to use sed).

Cool.

> > Oh yes, we/I need to get aonames parsed for GAMESS and Gaussian (I  
> > think
> > that's low-hanging fruit, as they say).

> I thought Gaussian had aonames.

So I did I, but there was a question mark in front of the √ in the
cclib wiki. Anyway I've looked in this, and into filling the last few
checkboxes for GAMESS and Gaussian.

> > Is there anything else you would like before a release? We can call it
> > cclib-0.5 or something, what do you think?
> 
> I'd like to finish up the calculation methods, since I'll need those  
> for PyMOlyze if I'm going to use cclib. Might as well kill two birds  
> with one stone.  While we're talking about it, I'm going to implement  
> the following:
> 
> --Methods base class
>    --Population class (implements repartition function which accepts  
> a list of lists)
>       -- MPA (implements calculate, and accepts an optional lists of  
> lists; if absent, does atoms)
>       -- CSPA (same as MPA)
>    -- Overlap population (not a subclass of population because can't  
> have repartition function as the expensive calculation depends on the  
> partitioning)
>    --Density class (implements calculate)
>      --MBO class (mayer's), which implements a calculate that calls  
> Density.calculate()
> 
> I figure that should only take a few hours more work, so I'll try to  
> get to it this week, although no promises. I have to give group  
> meeting, and analyze some new data and calculations.

Yeah, real life - it does get in the way. I will have some time in the
evenings next week and would like to get an initial release put together
and sent off sometime that week. We probably need some more man pages on
the wiki showing how to use cclib: the parser and the analysers.

> Also, it might be nice if we included a routine in the parser that  
> opens a file, tries to determine the file type, and returns an  
> instance of the appropriate class. What do you think?
Wait a second, I was thinking of exactly the same thing! I was thinking
of a method of the Logfile, that either returns an instance of the
appropriate parser or returns None.

> cclib-0.5 sounds fine, and we can increment by 0.1 as we add more  
> parsers.

Cool

> 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

[cclib-devel] Re: Progress towards release

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

> I'd like to add support for atomcoords to all of the main parsers, and
> get a release out next week or the week after with good support for  
> ADF,
> GAMESS and Gaussian. Once we get Jaguar in shape we can get another
> release out.

Sounds reasonable. I agree that it's more important to get an initial  
release out for relatively stable parsers, and have subsequent  
releases once we add support for other formats. Do you think we  
should keep the "broken" parsers in our initial release? I think it  
makes sense to create a SVN branch, and remove parsers other than  
ADF, GAMESS, and Gaussian.

> I've posted on the ADF forum regarding the SCF values, and if we  
> get an
> answer I'll be able to fix that once and for all (I see it causes a
> unittest failure too).

Cool.

> You or I should do a global rename of nindep to nmo, if you agree.

I'll take care of it, unless I encounter problems (going to use sed).

> Oh yes, we/I need to get aonames parsed for GAMESS and Gaussian (I  
> think
> that's low-hanging fruit, as they say).

I thought Gaussian had aonames.

> Is there anything else you would like before a release? We can call it
> cclib-0.5 or something, what do you think?

I'd like to finish up the calculation methods, since I'll need those  
for PyMOlyze if I'm going to use cclib. Might as well kill two birds  
with one stone.  While we're talking about it, I'm going to implement  
the following:

--Methods base class
   --Population class (implements repartition function which accepts  
a list of lists)
      -- MPA (implements calculate, and accepts an optional lists of  
lists; if absent, does atoms)
      -- CSPA (same as MPA)
   -- Overlap population (not a subclass of population because can't  
have repartition function as the expensive calculation depends on the  
partitioning)
   --Density class (implements calculate)
     --MBO class (mayer's), which implements a calculate that calls  
Density.calculate()

I figure that should only take a few hours more work, so I'll try to  
get to it this week, although no promises. I have to give group  
meeting, and analyze some new data and calculations.

Also, it might be nice if we included a routine in the parser that  
opens a file, tries to determine the file type, and returns an  
instance of the appropriate class. What do you think?

cclib-0.5 sounds fine, and we can increment by 0.1 as we add more  
parsers.

Adam

[cclib-devel] Progress towards release

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

It's taking me a while to get an a/c on the Jaguar machine but I would
like to get a release out as soon as possible.

I'd like to add support for atomcoords to all of the main parsers, and
get a release out next week or the week after with good support for ADF,
GAMESS and Gaussian. Once we get Jaguar in shape we can get another
release out.

I've posted on the ADF forum regarding the SCF values, and if we get an
answer I'll be able to fix that once and for all (I see it causes a
unittest failure too).

You or I should do a global rename of nindep to nmo, if you agree.

Oh yes, we/I need to get aonames parsed for GAMESS and Gaussian (I think
that's low-hanging fruit, as they say).

Is there anything else you would like before a release? We can call it
cclib-0.5 or something, what do you think?

Regards,
 Noel

[cclib-devel] Number of MOs

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

Dear Adam,

I think I've been confusing both of us. We use nbasis for the number of 
basis functions (or whatever the MOs are expressed in terms of in the 
mocoeff matrix). So we should use nmos (instead of nindep) for the number 
of molecular orbitals. In most cases nmos equals nbasis, but not always. 
The dimensions of mocoeff are then going to be (alpha/beta) x nmos x 
nbasis.

Regards,
 Noel

[cclib-devel] To Do

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

Okay, I've thrown together a To Do, which is available from the
sidebar. 

You'll notice that I've emphasised the parsers for the official release.
Whatever we've done will be released, but I think that it's important
that the parsers work as well as we can ensure (as this is the selling
point for cclib), and I'm not worried too much about the other parts for
the moment.

I just want to mention nindep. Can you just set this equal to nbasis for
the moment in the ADF parser? nindep is the number of MOs, and its value
is always less than or equal to the number of basis sets (nbasis). I
have come across examples in both Gaussian and GAMESS where one or more
symmetry-adapted basis functions have been removed as they are not
linearly independent. As a result, the key number is nindep, not nbasis.

We can check up the details of this on the ADF forums, although I must
admit that it is a rare occurence (but one which *will* break the
parser).

I appreciate all the work you've been doing on the analysis side too;
especially as you've been continuously integrating cclib with pymolyze.
I'm way behind (just got gausssum set up on svn), but adding new
features to gausssum is not high on my priority list at the moment.

Regards,

 Noel

Re: [cclib-devel] jaguar files

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

I'm onto this - users of Jaguar will need to specify ipvirt = whatever,
or we cannot guarantee any sensible results. This is one of the reasons
I need to rerun my Jaguar calcs.

On Thu, 2006-05-11 at 18:24 -0700, Adam Tenderholt wrote:
> I was thinking back to when I parsed Jaguar files for PyMOlyze, and I  
> remembered that there are cases when the number of alpha MOs is  
> different than beta MOs because it's possible to specify how many  
> virtual orbitals to print (ipvert, i think). I don't remember which  
> is the larger one, but it could mean that one of the mocoefficient  
> matrices have entries of zereos. If this isn't a big deal (I can't  
> think of a reason), then we're ok. Otherwise, we might have to switch  
> to a list of Numeric arrays.
> 
> 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

[cclib-devel] jaguar files

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

I was thinking back to when I parsed Jaguar files for PyMOlyze, and I  
remembered that there are cases when the number of alpha MOs is  
different than beta MOs because it's possible to specify how many  
virtual orbitals to print (ipvert, i think). I don't remember which  
is the larger one, but it could mean that one of the mocoefficient  
matrices have entries of zereos. If this isn't a big deal (I can't  
think of a reason), then we're ok. Otherwise, we might have to switch  
to a list of Numeric arrays.

Adam
  

Re: [cclib-devel] cclib methods/calculations

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

The following have been added to SVN:

1) CSPA, which does a C-squared population analysis. calculate() does  
the analysis, and creates aoresults, atomresults, and atomcharges.  
Also has a partition() function that accepts a list of lists of  
atomic orbital indices. See the wiki for definitions.

2) MPA, which does Mulliken. Same as CSPA.

3) Density, which calculates the density matrix. calculate() creates  
the attribute density.

I've considered making an extra baseclass for CSPA and MPA since they  
are basically similar, but figured it might be silly for just those  
two. If another population analysis method is added (like Lowdin),  
perhaps we can create a PopAnalysis base class. Any comments?

I also thought about having an optional argument to the class  
definition (parer, indices=[], progress = None, logger, logfile) and  
getting rid of the partition function. In this case, the attributes  
after calculate() would be aoresults, atomresults, atomcharges, and  
fragresults. What do you think?

Is this implementation sufficient? If so, I'll start working on the  
Overlap population analysis, and then move onto the Mayer's bond order.

Adam

Re: [cclib-devel] cclib methods/calculations

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

> As a function you could have...
>
> popanalyser 
> (method="Mulliken",aonames=myfile.aonames,aooverlaps=myfile.aooverlap, 
> mocoeffs=myfile.mocoeffs) or just popanalyser 
> (method="Mulliken",parsedfile = myfile)
>
> which behind the scenes calls Mulliken(aooverlaps,mocoeffs) or
> something.

I like the idea of passing a parsed file to it, simply because there  
is less to remember about the order of arguments if there is only 1  
or two arguments. ;o)
>
> Next you need to think about what the popanalysers return: partial
> charges on atoms? pop analyses per MO per AO? How do you handle  
> groups?
> Will they be handled afterwards? e.g.
> mypopanalyser.partition(listofgroups in terms of aonames).
>
> In short, I'm not sure how 'classified' we should/could make this -  
> but
> the object, in this case, would be the result: a partitioning of
> 'electron density' per moorbital per aoorbital. You could have:
>
> mypartition 
> (method="Mulliken",aonames=myfile.aonames,aooverlaps=myfile.aooverlap, 
> mocoeffs=myfile.mocoeffs)
> mypartition.calculate() # per MO per AO
> print mypartition.mocontributions
> print mypartition.partialcharges
> groupcontributions = mypartition.splitintogroups(listofgroups)

This sounds like a good idea, although I think we should keep each  
calculation type as a separate class, and then decide if we want a  
super-function that will call the right method of the class.

I see the base class having the following:

-an instance of a logfile subclass (parsed or not, since checking if  
parsed and calling parse is easy)
-a loglevel
-a logfile

I'll start with calculating the density matrix, array[3] because I  
know how to do that using Numeric as I just did it. ;o) Adapting it  
to a class and giving it progress and logging support shouldn't be  
too hard. Plus, we can check our results as Gaussian prints it in the  
output (I don't think the others do, at least not as a default, which  
is why I didn't suggest parsing it).

Next, I'll work on the SCPA and MPA classes. I figure their calculate  
functions will build an array([3]) for alpha/beta matrices of  
dimension nbasis x nbasis (moresults), an array([3]) for alpha/beta  
matrices of dimension nbasis x natoms (atomresults), and a list of  
atom charges (atomcharges). After that, I'll add a function that  
accepts a list of lists to partition into fragments.

Hopefully these three things won't take more than a few hours since I  
already have most of the pieces.

> I think it's time to make that TODO list :-)

I thought it was your job to start that. ;o)

> Also, we should both be trying to migrate to SVN, as this will make it
> easier to integrate the latest version of cclib into our own projects.
> My initial try failed so I have to do it manually somehow...I'm really
> looking forward to that. :-)

I'm already using SVN since I like it so much better than CVS. I  
briefly looked around to see how to put cclib into my trunk, but I  
didn't see anything. I sorta remember seeing that you can't do an svn  
copy between two different trees, so I didn't try that. Let me know  
what you find.

> BTW, check out http://cia.navi.cx/stats/project/cclib - this was  
> enabled
> by ticking some box on the sourceforge SVN page.

That's impressive. :o)