cclib-devel — Developer's mailing list

Re: [cclib-devel] problem with utils.py revision 336

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

It might be something to do with SVN. In Windows, SVN adds ^M to everything
(i.e. DOS format). In Linux, it doesn't. But, if you're using cygwin's SVN
on Windows, and then editing with IDLE, it may get weird depending on the
combinations of settings you use.

?


On 14/09/06, Mehdi Bounouar <meh...@ch...> wrote:
>
> On Thu, Sep 14, 2006 at 09:55:30AM +0100, Noel O'Boyle wrote:
> > What exactly is the problem you've been having? I haven't found any
> > problems: I've installed the latest SVN on WinXP, and 147 tests pass
> when I
> > run testall.py (the failures indicate 'things to do') and 58 tests in
> > regression.py.
>
> Hum, then I must have done something. The thing is that the file was in
> DOS format with these "^M" carriage returns. So I don't know what
> happened.
>
> BTW I hope to upload as soon as possible the Molpro parser :-) it is
> written and works (at least for what I in general need) I just have to
> get more confident using svn and generate the data examples.
>
> Mehdi
>

Re: [cclib-devel] problem with utils.py revision 336

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

What exactly is the problem you've been having? I haven't found any
problems: I've installed the latest SVN on WinXP, and 147 tests pass when I
run testall.py (the failures indicate 'things to do') and 58 tests in
regression.py.

On 14/09/06, Noel O'Boyle <bao...@gm...> wrote:
>
> I guess it's something that has a dependency on qt. It'll probably need a
> protected 'import' statement, as in progress/__init__.py. I'll look into it
> as soon as I have a chance. You can locally switch to the earlier revision
> with something like 'svn update -r335' which will allow you to continue for
> the moment
>
> Noel.
>
>
> On 14/09/06, Mehdi Bounouar <meh...@ch...> wrote:
> >
> > Hi,
> >
> > There is apparently something that got messed up with the file
> >
> > src/cclib/parser/utils.py
> >
> > since the last revision 336
> >
> > Windows ? ;-)
> >
> > Mehdi
> >
> > -------------------------------------------------------------------------
> >
> > 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
> >
>
>

Re: [cclib-devel] problem with utils.py revision 336

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

I guess it's something that has a dependency on qt. It'll probably need a
protected 'import' statement, as in progress/__init__.py. I'll look into it
as soon as I have a chance. You can locally switch to the earlier revision
with something like 'svn update -r335' which will allow you to continue for
the moment

Noel.

On 14/09/06, Mehdi Bounouar <meh...@ch...> wrote:
>
> Hi,
>
> There is apparently something that got messed up with the file
>
> src/cclib/parser/utils.py
>
> since the last revision 336
>
> Windows ? ;-)
>
> Mehdi
>
> -------------------------------------------------------------------------
> 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] problem with utils.py revision 336

[<meh...@ch...>]

Hi,

There is apparently something that got messed up with the file 

src/cclib/parser/utils.py

since the last revision 336

Windows ? ;-)

Mehdi

Re: [cclib-devel] New release of cclib

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

Just to let you know that I'm awaiting a reply to the question on big log
files on SVN and in the bug tracker from the sourceforge team.

Also, I've been meaning to update the developer's wiki pages for a while, so
I've started that. Afraid that there's no new information there yet. I've
separated "Parsed data" into that for the released cclib (linked from the
Main page) and that for the development cclib (there's a link to this from
the Development page). I want to expand on the tests section a bit, as well
as do as you suggest and update the "Things to Do".

Noel

On 13/09/06, Adam Tenderholt <a-t...@st...> wrote:
>
> > You're right that they're perhaps not ready for release yet, hence
> > "possible". I'll have to do some more work on them before that. We
> > should also look into the possibility of calculating the
> > exponentials ourselves in C or something, but it should be possible
> > to switch to C from PyQuante, if and when.
> >
> > gbasis works reasonably well. At the moment, it does not pick up on
> > the use of 5D orbitals instead of 6D (or 7F instead of 10F), though.
> >
> > If we ignore the "Possibles", we can get out a release of cclib
> > right away. And concentrate on those, plus any additional parsers/
> > methods for the following release.
> >
> > What you do think?
>
> I think it's ultimately your call since you're most familiar with the
> changes since the 0.5 release.
>
> Also, it may be helpful for you to update the TODO section of the
> wiki so that the rest of us know where we should concentrate our
> efforts.
>
> 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
>

Re: [cclib-devel] New release of cclib

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

> You're right that they're perhaps not ready for release yet, hence  
> "possible". I'll have to do some more work on them before that. We  
> should also look into the possibility of calculating the  
> exponentials ourselves in C or something, but it should be possible  
> to switch to C from PyQuante, if and when.
>
> gbasis works reasonably well. At the moment, it does not pick up on  
> the use of 5D orbitals instead of 6D (or 7F instead of 10F), though.
>
> If we ignore the "Possibles", we can get out a release of cclib  
> right away. And concentrate on those, plus any additional parsers/ 
> methods for the following release.
>
> What you do think?

I think it's ultimately your call since you're most familiar with the  
changes since the 0.5 release.

Also, it may be helpful for you to update the TODO section of the  
wiki so that the rest of us know where we should concentrate our  
efforts.

Adam

Re: [cclib-devel] New release of cclib

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

BTW, if we are including C code, the following might make this easy:

http://heim.ifi.uio.no/~kent-and/software/Instant/doc/Instant.html

On 13/09/06, Noel O'Boyle <bao...@gm...> wrote:
>
> You're right that they're perhaps not ready for release yet, hence
> "possible". I'll have to do some more work on them before that. We should
> also look into the possibility of calculating the exponentials ourselves in
> C or something, but it should be possible to switch to C from PyQuante, if
> and when.
>
> gbasis works reasonably well. At the moment, it does not pick up on the
> use of 5D orbitals instead of 6D (or 7F instead of 10F), though.
>
> If we ignore the "Possibles", we can get out a release of cclib right
> away. And concentrate on those, plus any additional parsers/methods for the
> following release.
>
> What you do think?
>
> Noel
>
>
> On 13/09/06, Adam Tenderholt <a-t...@st...> wrote:
> >
> > > I propose a new release of cclib (0.6) with the following additions:
> > >
> > > Definite:
> > > (1) GAMESS-UK parser
> > > (2) .clean() method for parsers
> > > (3) The basic unit tests
> > > Possible:
> > > (1) gbasis attribute
> > > (2) volume.py
> >
> > How stable and optimized are the gbasis and volume stuff? I think it
> > would be really interesting to have those included, but I don't think
> > we should push them unless they are ready.
> >
> > 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
> >
>
>

Re: [cclib-devel] New release of cclib

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

You're right that they're perhaps not ready for release yet, hence
"possible". I'll have to do some more work on them before that. We should
also look into the possibility of calculating the exponentials ourselves in
C or something, but it should be possible to switch to C from PyQuante, if
and when.

gbasis works reasonably well. At the moment, it does not pick up on the use
of 5D orbitals instead of 6D (or 7F instead of 10F), though.

If we ignore the "Possibles", we can get out a release of cclib right away.
And concentrate on those, plus any additional parsers/methods for the
following release.

What you do think?

Noel

On 13/09/06, Adam Tenderholt <a-t...@st...> wrote:
>
> > I propose a new release of cclib (0.6) with the following additions:
> >
> > Definite:
> > (1) GAMESS-UK parser
> > (2) .clean() method for parsers
> > (3) The basic unit tests
> > Possible:
> > (1) gbasis attribute
> > (2) volume.py
>
> How stable and optimized are the gbasis and volume stuff? I think it
> would be really interesting to have those included, but I don't think
> we should push them unless they are ready.
>
> 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
>

Re: [cclib-devel] New release of cclib

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

> I propose a new release of cclib (0.6) with the following additions:
>
> Definite:
> (1) GAMESS-UK parser
> (2) .clean() method for parsers
> (3) The basic unit tests
> Possible:
> (1) gbasis attribute
> (2) volume.py

How stable and optimized are the gbasis and volume stuff? I think it  
would be really interesting to have those included, but I don't think  
we should push them unless they are ready.

Adam

[cclib-devel] New release of cclib

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

I propose a new release of cclib (0.6) with the following additions:

Definite:
(1) GAMESS-UK parser
(2) .clean() method for parsers
(3) The basic unit tests
Possible:
(1) gbasis attribute
(2) volume.py

Any more suggestions from anyone on what to include?

Regards,
  Noel

Re: [cclib-devel] New developer

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

On Sep 5 2006, Adam Tenderholt wrote:

>> * methods: nothing new in methods except a half-finished volume.py,  
>> which I need to tidy up. On my things to do is to convert the  
>> population functions to have explicit data passed, rather than the  
>> whole parser object. Was thinking about finding common elements  
>> between population methods and abstracting them out, e.g. a  
>> fragments object.
>
>I did try to make the population methods derive from an abstract  
>class that implemented as much as possible. When you say fragments  
>object, do you mean you want a Python object that contains the  
>population information for fragments that are passed to the calculate 
>() method? (It is called calculate(), right?! I honestly haven't  
>looked at it in ages.) As I recall, a Numeric array is returned right  
>now.

I must admit that I haven't looked at it too closely myself - I think I 
should just keep quiet about that until I have a proper look (just talking 
thru my hat again). On the other hand, I do now believe strongly in 
explicit passing of information, although when we first discussed this I 
wasn't sure whether it made any difference. What convinced me in the end 
was writing the bridges where, when you want to make an openbabel molecule 
(for instance) you need to explicitly pass coordinates (as there may be 
several sets in a geometry optimization). In the DOS example, someone might 
only want to calculate the contributions to the HOMO, and they could just 
pass in a Numeric array of the right dimensions, but just containing the 
HOMO.

>> * parsers: I think GAMESS-UK parser is ready for release. Jaguar is  
>> still only half-finished. Check the logs for some small changes to  
>> ADF, Gaussian and GAMESS. Added gbasis attribute, and .clean()  
>> method. We intend to add the cartesian displacement vectors (from a  
>> frequency calculation) and the force constant matrix.
>
>Sounds good.
>
>> * bridges: nothing new. Have learned that the release version of  
>> OpenBabel doesn't include pyopenbabel though, so I should probably  
>> change the OB bridge to use the openbabel module.
>
>Ok. Since you're most familiar with this, I'll let you handle it. ;o)
Sure.

>> * test: have been trying to simplify the tests. Some more work to  
>> do. Going to replace regression.py with ccopen.py. The idea will be  
>> that ccopen.py attempts to guess the type of every test file we  
>> have, parse it, and if necessary, run a regression test. Am also  
>> thinking that life would be simpler if we simply unloaded our large  
>> test files to SVN also. We can zip them up, and teach cclib to open  
>> zipped files (part of the standard Python library, I think). I  
>> think that we shouldn't worry about sourceforge running out of space.
>
>I think you are right that the standard python library contain  
>functions for dealing with zipped files. Is there someone we can  
>contact at sourceforge about svn space limits? I really think we  
>should check just in case...
Will do. And in addition, it would be nice if we could use SF's bug 
tracking system...no more emailing to a gmail account.

BTW, I'm moving all opensource discussions to my gmail account, 
bao...@gm..., so if could you update your address book, that'd be 
great.

>Adam
>
>
>

Re: [cclib-devel] Developer access

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

Hey Mehdi!

Welcome to the team. :o) I've been MIA for a few months because I've  
been quite busy, but I should be around more now. Let me know if you  
have any questions.

Happy developing,

Adam

On Sep 5, 2006, at 6:44 AM, Noel O'Boyle wrote:

> Welcome to the team, Mehdi! You're now a developer on cclib.
>
> Some things you may like to do are:
> (0) Subscribe to ccl...@li... and cclib- 
> us...@li....
> Also it would be good to point your RSS feed reader (e.g. I using  
> Sage/Firefox)
> to the RSS feed on http://cia.navi.cx/stats/project/cclib
> (1) Upload the test files to the SVN respository
> (2) Upload the start of the Molpro parser, making sure that it does  
> not break
> cclib
> (3) Extend the tests ("python testall.py") so that it tests the  
> Molpro parser
> (4) Keep extending the Molpro parser until it passes all of the tests
>
> And don't worry, you're not on your own. We'll help with any  
> difficulties.
> We want the Molpro parser to work too. Keep in touch using cclib- 
> de...@li....
>
> Please keep the following in mind as guidelines:
> (1) Don't break cclib (i.e. run the tests before commiting)
> (2) Log messages are for other people to read, so they should  
> accurately
> reflect whatever you've done
> (3) Commit 'atomic changes'. That is, don't squash two completely  
> different
> changes into one commit.
> (4) Discuss before coding if you're not sure what to do or are  
> considering
> a new feature.
>
> Regards,
>   Noel
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> 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] Developer access

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

Welcome to the team, Mehdi! You're now a developer on cclib.

Some things you may like to do are:
(0) Subscribe to ccl...@li... and cclib-users@lists.=
sourceforge.net.
Also it would be good to point your RSS feed reader (e.g. I using Sage/Fi=
refox)
to the RSS feed on http://cia.navi.cx/stats/project/cclib
(1) Upload the test files to the SVN respository
(2) Upload the start of the Molpro parser, making sure that it does not b=
reak
cclib
(3) Extend the tests ("python testall.py") so that it tests the Molpro pa=
rser
(4) Keep extending the Molpro parser until it passes all of the tests

And don't worry, you're not on your own. We'll help with any difficulties=
.
We want the Molpro parser to work too. Keep in touch using cclib-devel@li=
sts.sourceforge.net.

Please keep the following in mind as guidelines:
(1) Don't break cclib (i.e. run the tests before commiting)
(2) Log messages are for other people to read, so they should accurately
reflect whatever you've done
(3) Commit 'atomic changes'. That is, don't squash two completely differe=
nt
changes into one commit.
(4) Discuss before coding if you're not sure what to do or are considerin=
g
a new feature.

Regards, 
  Noel

Re: [cclib-devel] Log files for cclib

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

On Wed, 2006-08-30 at 20:03 +0100, Nuno A. G. Bandeira wrote:
> Noel O'Boyle wrote:
> 
> > Let's call it OPDOS (overlap population DOS), as this is also widely
> > used by other software. I call it COOP because that is the name in the
> > paper by Hoffmann which has the equations. People will find it difficult
> > to find it in the literature if I change the name.
> 
> His book on solids names it OPWDOS. CACAO names it MOOP which seems more 
> consistent.

I stand corrected. I will consider changing the name. I still think that
MOOP sounds silly, though :-)

> > I will have to discuss this further with you. At the moment my code does
> > not handle SFOs at all, so there is way to figure out this problem.
> > However, it will work for ADF files which have no SFOs (I forget the
> > keywords but there are some examples in the cclib svn repository,
> > viewable online
> > http://svn.sourceforge.net/viewvc/cclib/trunk/data/ADF/basicADF2004.01/).
> 
> Then what does the code do exactly ? Is the basis function info 
> sufficient ? I was always under the impression that the information 
> treated was with the SFO info. Is the code aware of frozen core 
> functions ? Are they treated at all ?

My code works for GAMESS, Jaguar, Gaussian, etc. The DOS is easier to
explain. This is calculated by the following Python expression:

            contrib = MOCoeff * Numeric.dot(MOCoeff,overlap)

where MOCoeff is the matrix of MO coefficients
      overlap is the atomic orbital overlap matrix (S)
      * multiplies the corresponding matrix entries (i.e. not matrix
multiplication)
      Numeric.dot(x,y) is the dot product of x and y (i.e. matrix
multiplication)

and contrib is the matrix giving the contribution of a particular AO to
a particular MO.

Because none of these programs use fragments internally to do anything,
this type of Mulliken population analysis allows users to get
information on the contribution of particular fragment to a particular
MO (by summing over AOs in the fragment).

This type of analysis is subject to the usual Mulliken problems -
negative contributions occur from time to time, esp. in virtual
orbitals; the exact values may be basis set dependent. But it's a lot
better than nothing, when you want to discuss the character of an
orbital.

So if ADF produces MO coeffs in terms of the AOs, and also produces an
AO overlap matrix, my code works. Unfortunately for GaussSum, most ADF
calculations use fragments, and so I need to adapt my code, as cclib
extracts fragment information separate to AO information (which I think
is the correct way to do it).

> > I will have to think some more about the possible numbering system, as I
> > have never used ADF and will need perhaps to discuss this some more with
> > you. I have to admit, however, that this is not a priority as I am about
> > to drop off the net for a few weeks as I change postdocs...again. I am
> > just about to release beta 2 of GaussSum2 which fixes some serious bugs,
> > so that 90% of GaussSum2 is now working. I want to get the other 10%
> > finished as quickly as possible, but I know that it will take some time.
> > 
> 
> I will be in the UK this next week and will come down to London on the 
> 6th. So until the 11th I will be away.
> 
> Have you or anyone had any time to look at the files I sent to you ?
Just checked - I didn't realise you had sent another. Thanks! In future,
it would be a good idea to send an email to
ccl...@li... to let us know that you have sent us
another file. I will look at it as soon as possible, although I must say
that this is my last day at work, so it may take a little while. I'd
appreciate if you could cc all emails to our mailing list, by the way.

Regards,
  Noel

Re: [cclib-devel] contribute to cclib

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

On Tue, 2006-08-29 at 16:21 +0200, Mehdi Bounouar wrote:
> > So you're saying that it's possible to calculate the cartesian
> > displacements from the FCM. How is this done exactly? It's possible that
> > we will extract both, as many output files will only contain the
> > cartesian displacements. However, we will provide (separately) a method
> > to calculate the cartesians from the FCM, if this is possible.

> I have put an attachment that shows how to do this,
> the principle should be correct as the values are close, 
> Note: the cartesian displacements vectors are sometimes of opposite signs.

Thanks for the code. I'll make it into a function and add it to the
algorithms when I get a chance. The opposite signs are an artefact or
are they significant? For visualisation I would say it's not important;
but might this be significant for other uses? Is there some convention
on these things that we should be obeying, e.g. something in that book
by Decius, Cross and Wilson that is covered with dust on my bookshelf?

> > Are you familiar with so-called scaled
> > quantum mechanical (SQM) methods? e.g.
> > http://dx.doi.org/10.1016/j.theochem.2006.03.025
> > It would be nice to extract the information necessary for such a study,
> > and then to implement the method as an algorithm. I remember trying to
> > do this during my PhD but I didn't have access to any software to do
> > this, nor did I have the technical background to be able to do this
> > myself. If the FCM were required for this, I think it would certainly
> > justify extracting it. Do you know what else is needed?
> 
> Honestly, I have no idea :-) but I will try to have a look it.

It's no big deal - I guess we should concentrate on the parser first.
However, it might be interesting as there is no free software available
to do this kind of thing.

BTW, once Adam gets back from holidays we can sort out making you a
developer. Unfortunately, I'm going on holidays for a week this Friday
as well as changing postdocs. But I'd like to get you up and running as
soon as possible, so stay tuned.


> Mehdi

Re: [cclib-devel] contribute to cclib

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

On Tue, 2006-08-29 at 13:26 +0200, Mehdi Bounouar wrote:
> > 
> > We do intend to extract the cartesian displacements for vibrational
> > frequencies - I didn't realise you were talking about this. See:
> > http://sourceforge.net/mailarchive/forum.php?thread_id=29367282&forum_id=48080 for a possible name for this attribute. We intend to add this to the next release, if possible. Are you suggesting something above and beyond this, though?
> 
> Well IMHO I would rather prefer to an option to extract the Force
> constant matrix (FCM), because if I would like to do displacements along a
> vector, I have a problem to trust the outputed vectors (sometimes
> truncated, sometimes even wrong). Also I think having a "unified" parsed 
> FCM, but unified I mean that one does not have to check if it is mass weighted, 
> units etc. 
> Lets say for instance I want to use Molpro because it has nice and quick method 
> to generate to generate a FCM, I could then parse it and use it as a guess for 
> doing a Geom-Opt in GAMESS because I trust the Optimiser Algorithm.
> 
So you're saying that it's possible to calculate the cartesian
displacements from the FCM. How is this done exactly? It's possible that
we will extract both, as many output files will only contain the
cartesian displacements. However, we will provide (separately) a method
to calculate the cartesians from the FCM, if this is possible.

Before you write some specific code, it would be great also if you could
look at the output of the other comp chem packages. Do they already
contain this information? If not, we will have to create further example
input files that *do* contain it. I am about to finish a postdoc in two
days time, after which I will have reduced access to comp chem packages.
Do you have access to any others besides Molpro?

On a different question: looking at the web, I gather you do a lot of
work on vibrational frequencies. Are you familiar with so-called scaled
quantum mechanical (SQM) methods? e.g.
http://dx.doi.org/10.1016/j.theochem.2006.03.025
It would be nice to extract the information necessary for such a study,
and then to implement the method as an algorithm. I remember trying to
do this during my PhD but I didn't have access to any software to do
this, nor did I have the technical background to be able to do this
myself. If the FCM were required for this, I think it would certainly
justify extracting it. Do you know what else is needed?

Regards,
  Noel

Re: [cclib-devel] contribute to cclib

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

On Tue, 2006-08-29 at 12:12 +0200, Mehdi Bounouar wrote:
> > > Also have you considered parsing also first/second order
> > > derivative infomation ? 
> > I would be interested in hearing more about this - for example, how can
> > this information be used? Our goal with cclib is not to extract all
> > possible information, but that information which is useful for
> > algorithms (which cclib also includes) or visualization (by some other
> > software).
> 
> Well, you will need for instance such information as a guess; some QC packages
> implements methods which are not always available in the other 
> (ex: a better optimizers etc), also some people would like to visualize vibrational modes using the
> sowftware of their choice wich would then be possible (I can actually parse a Molpro file
> and produce a molden file containing only the information that I need)

We do intend to extract the cartesian displacements for vibrational
frequencies - I didn't realise you were talking about this. See:
http://sourceforge.net/mailarchive/forum.php?thread_id=29367282&forum_id=48080 for a possible name for this attribute. We intend to add this to the next release, if possible. Are you suggesting something above and beyond this, though?

> Regards,
> 
> Mehdi

Re: [cclib-devel] contribute to cclib

[<meh...@ch...>]

Hi,

Thanks for the quick reply, I will have a look at (1), (2) ... ;-)

But just to answer quickly to this question

> > Also have you considered parsing also first/second order
> > derivative infomation ? 
> I would be interested in hearing more about this - for example, how can
> this information be used? Our goal with cclib is not to extract all
> possible information, but that information which is useful for
> algorithms (which cclib also includes) or visualization (by some other
> software).

Well, you will need for instance such information as a guess; some QC packages
implements methods which are not always available in the other 
(ex: a better optimizers etc), also some people would like to visualize vibrational modes using the
sowftware of their choice wich would then be possible (I can actually parse a Molpro file
and produce a molden file containing only the information that I need)

Regards,

Mehdi

Re: [cclib-devel] contribute to cclib

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

Hello Mehdi,
> 
> I would like to contribute to cclib by writing a parser for
> Molpro (in fact I already started).
> 
Fantastic!

> How can I do that ?
This needs a longer answer. :-)

(1) Have you worked on an open source project before? If not, it might
be a good idea to skim read http://producingoss.com/ .
(2) Have you used SVN before? This is how we store our code. If not, you
might like to read chapters 1-3 of http://svnbook.red-bean.com/ .
(3) To start, check out the latest copy of our code as described under:
http://cclib.sourceforge.net/wiki/index.php/Development#Checking_cclib_out_of_subversion

Adam and myself will need to discuss the addition of a new developer. In
the meanwhile please still continue working on the parser, and we will
be able to merge the changes. Once you are added as a developer, we'll
look over your shoulder for a while as you commit changes to give you
some advice.

In relation to adding a new parser:
(4) We don't have access to Molpro, so you will have to run all of the
test jobs. Look at the 'data' folder on subversion and you will see that
for every comp chem package we have test jobs on divinyl benzene at the
B3LYP/STO-3G level of theory:
(a) a geometry optimization (with SCF convergence information and
geometry optimization convergence information)
(b) a single point energy calculation (with ao overlaps and mo coeffs)
(c) a single point unrestricted energy calculation (with ao overlaps and
mo coeffs)
(d) a vibration frequency calculation with IR information
(e) a vibration frequency calculation with Raman information (if
possible)
(f) a TD-DFT calculation (if possible)

Any additional calculations used to define the parser should not be
added to SVN - there is a different procedure, which I will describe
when you want to do this.

(5) The only way we stay sane is tests. No parser is released until it
passes all of the tests (run testall.py). You will need to add molpro to
the test scripts of course. This implies that every parser needs to
parse the same things, and use the same units (see the wiki for
information).

> Also have you considered parsing also first/second order
> derivative infomation ? 
I would be interested in hearing more about this - for example, how can
this information be used? Our goal with cclib is not to extract all
possible information, but that information which is useful for
algorithms (which cclib also includes) or visualization (by some other
software).

Regards,
 Noel

P.S. Please cc everything to the cclib developers list (usually by
clicking Reply All)

[cclib-devel] [Fwd: Re: Log files for cclib]

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

For the record, Nuno has agreed to put his log files in the public
domain.

-------- Forwarded Message --------
From: Nuno A. G. Bandeira <nun...@fc...>
To: Noel O'Boyle <no...@ca...>
Subject: Re: Log files for cclib
Date: Tue, 22 Aug 2006 15:27:34 +0100
Noel O'Boyle wrote:

> Hello Nuno,
> 
> Thanks for uploading Os3.zip and Os3(CO)12-D3h.zip
> 
> Just to avoid any misunderstanding, can you confirm that you are placing
> these files in the public domain. That is, it will be possible for
> anyone to download these files.

Yes. My work doesn't directly concern those compounds they've been 
studied before. I'm having my eye focused on some of their derivatives.

[cclib-devel] Log files for cclib

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

Hello Nuno,

Thanks for uploading Os3.zip and Os3(CO)12-D3h.zip

Just to avoid any misunderstanding, can you confirm that you are placing
these files in the public domain. That is, it will be possible for
anyone to download these files.

Regards,
  Noel

Re: [cclib-devel] Current situation

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

On Fri, 2006-08-04 at 12:05 -0700, Adam Tenderholt wrote:
> I'm  
> hoping that in about a month I'll be able to get back into research  
> and spending more time with cclib.
Sounds good. I've got some time so I'll continue tinkering and keep you
up to date.

> > Where do you stand with cclib integration into PyMOlyze? I've just  
> > about
> > finished GaussSum2, by throwing out incompatible features :-).
> 
> I was working on porting PyMOlyze to Qt4 first. I think I'm mostly  
> done with that, so adding cclib support should be relatively easy.  
> Hope I didn't just jinx myself. ;o) I do have an experimental version  
> a few people in my lab are using that does Meyer's bond orders  
> through cclib.
For me, as I think I may have mentioned, I see GaussSum2 as the end of a
line, and my only wish is that it continues to work as well as it does
now in future. Hence, cclib.

> > Incidentally, I've figured out how to use Numeric to speedup the COOP
> > calculation:
> > for k in range(nmo):
> >     kcoop = Numeric.outerproduct(MOCoeff[0,k,:], MOCoeff[0,k,:]) *  
> > overlap
> >
> > The code above is only for restricted calculations, but you should be
> > able to get the idea. It gives an array of the COOP of every basis fn
> > with every other one.
> 
> COOP sounds familiar, but I'm not positive. Is it the same thing as  
> Overlap Populations? And do you want to integrate this method into  
> cclib, or should I (eventually) do it?
"Crystal Orbital Overlap Population" (the name from Hoffmann's original
paper...I think I may have the ref somewhere), or what AOMIX calls
"Overlap Population Density of States". I should really get GaussSum2 to
use cclib for the DOS and COOP, but I've been delaying that as I'd like
to discuss some changes to the population methods API. I'll think about
this some more and put it in another email.

> > It would be good to define some goals for the next release of GaussSum
> > and perhaps a timeframe too, although without any pressure for us to
> > keep to it. :-)
> 
> You mean cclib?
Yes :-) 

> > For example, I'd like a new attribute for vibrational displacement
> > vectors. Since people like to look at M.O. vibrations, and  
> > especially if
> > PyMol decides to become interested, we will need to extract this
> > information. As a suggested name, we could use vibdisp - not very  
> > catchy
> > but I cannot think of anything better.
> >
> > I also want to tidy up volume.py, a bit more.
> 
> Both sound like reasonable goals. Definitely add the new parsers. And  
> I think I'd like to add fragment analysis and CDA support like AOMix  
> has. It'd be quite useful for looking at some calculations. Right now  
> I only do such things with ADF, but I prefer Gaussian.
Actually, I was thinking about CDA too. I was looking at Frenking's code
and it's basically some matrix algebra. Fragment analysis would be
cool...I just haven't a clue how it's done.

All of this makes me think we should abstract out a fragment class,
which would be used by all of these methods. Maybe you already have one
for the population methods.

> > On the same note, I'm tired of typing guesstype(). First of all, it's
> > too hard to type, and secondly it's longer than just typing GAMESS or
> > Jaguar or whatever. Is there any shorter name than guesstype than  
> > we can
> > come up with? e.g. cclog, or ccopen, in keeping with the 'cc'  
> > theme. Any
> > ideas?
> 
> ccopen sounds reasonable. Or what about just open? And perhaps we  
> should create a LogFile type like Null or Invalid. When any  
> attributes like parse are called, we can log out with an error.

I'm a bit worried about namespace confusion with the 'open' keyword,
though. I'd be happy to run with ccopen. 

> Adam
> 
> 

[cclib-devel] Current situation

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

Hello Adam,

I've been trying to get Jaguar and GAMESS-UK data files into shape, to
make sure we have all the info we need to complete those parsers. In
addition, we've just gotten a new version of Jaguar installed here, so
I'm running all of the old input files on the new system (it's a major
version or two ahead of Jag4.2 but I forget which).

Have you seen the GAMESS-UK GUI, ccp1gui? It's GPLed and on SF (latest
release June 2006) and uses VTK/Python. It would be good to get in touch
once we get the GAMESS-UK parser finished, as they seem to be interested
in being able to open files from other software too.

Where do you stand with cclib integration into PyMOlyze? I've just about
finished GaussSum2, by throwing out incompatible features :-).

Incidentally, I've figured out how to use Numeric to speedup the COOP
calculation:
for k in range(nmo):
    kcoop = Numeric.outerproduct(MOCoeff[0,k,:], MOCoeff[0,k,:]) * overlap

The code above is only for restricted calculations, but you should be
able to get the idea. It gives an array of the COOP of every basis fn
with every other one.

It would be good to define some goals for the next release of GaussSum
and perhaps a timeframe too, although without any pressure for us to
keep to it. :-)

For example, I'd like a new attribute for vibrational displacement
vectors. Since people like to look at M.O. vibrations, and especially if
PyMol decides to become interested, we will need to extract this
information. As a suggested name, we could use vibdisp - not very catchy
but I cannot think of anything better.

I also want to tidy up volume.py, a bit more.

On the same note, I'm tired of typing guesstype(). First of all, it's
too hard to type, and secondly it's longer than just typing GAMESS or
Jaguar or whatever. Is there any shorter name than guesstype than we can
come up with? e.g. cclog, or ccopen, in keeping with the 'cc' theme. Any
ideas?

BTW, like I said some time ago, I'll be giving a talk on cclib in mid
sept. You can see our name here:
http://www.inf.uni-konstanz.de/complife06/freesoft.html

Regards,
  Noel

[cclib-devel] Volume

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

I've added a module methods/volume.py, which allows users to calculate
the value of an orbital at all points in a cube. I've some more playing
around to do with it, but it seems to work quite well.

If you have all of the dependencies, you can run the file to create the
homo of dvb in about 8 seconds (psyco). Although it's coarse enough,
turning on compute polynormals in mayavi gives quite a smooth image.

So it's not as bad as I first thought. What are the dimensions of the
typical Coarse grid in Gaussian?

Noel

Re: [cclib-devel] pyquante and cclib

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

On Jul 28 2006, Rick Muller wrote:

>Nice! Let me know if I can help with anything.
Don't worry - I'm already thinking of a few questions :-)

>By the way, how are you using mayavi? Did you have to write your own  
>routine to input the cube file, or is that fairly easy?
If you have a Numeric array, you can use pyvtk by Pearu Peterson 
(http://cens.ioc.ee/projects/pyvtk/) to create an input XML file for VTK. 
As an example see the "__main__" section of: 
http://www.redbrick.dcu.ie/~noel/Cube2VTK.txt (which is a G03 cube file 
reader I did about a year ago). Once created, you can use mayavi -d 
myfile.vtk.

It's also possible to interface to VTK directly (it comes with Python 
bindings) but that would be more complicated, although perhaps something 
cclib could think about later.

Mayavi/VTK can also visualise a volume of vectors in some cool ways 
(arrows, flows, and so on). Would it be possible to easily calculate the 
gradient (i.e. separately with respect to x, then y, then z) of the 
electron density at every point in a volume? Would this be useful to 
visualise? I don't think I've ever seen anyone do this though, but I think 
it's related to the atoms in molecules theory.

Noel